- Add Microchip PCI1008 device ID and include it in NTB DMA alias quirk
(Logan Gunthorpe)
* pci/switchtec:
PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk
PCI: switchtec: Add Microchip PCI1008 device ID
dmaengine: switchtec-dma: Add PCI1008 device ID
- Add hotplug reservation only once (not at each level of the hierarchy) so
bridge windows don't grow more than necessary (Ilpo Järvinen)
* pci/resource:
PCI: Do not add hotplug reservation multiple times
- Take a reference on the I2C adapter in tc9563 to avoid uninterruptible
hang when unloading an I2C module while in-use (Johan Hovold)
- Restrict tc9563 Tx Amplitude, DFE and N_FTS to USP, DSP1 and DSP2 in DT
binding (Manivannan Sadhasivam)
- Fix parsing tc9563 integrated Ethernet MAC Endpoint node (Manivannan
Sadhasivam)
- Power off only tc9563 external-facing ports (DSP1, DSP2), leaving USP and
DSP3 powered up (Manivannan Sadhasivam)
- Skip tc9563 Tx amplitude and DFE tuning for DSP3, which don't support
them (Manivannan Sadhasivam)
- Move integrated MAC Endpoint out of the list of internal ports and
configure it separately (Manivannan Sadhasivam)
* pci/pwrctrl:
PCI/pwrctrl: tc9563: Move Integrated MAC Endpoint out of 'tc9563_pwrctrl_ports' enum
PCI/pwrctrl: tc9563: Rename DSP3 to VDSP
PCI/pwrctrl: tc9563: Skip Tx amplitude and DFE tuning for DSP3
PCI/pwrctrl: tc9563: Power off only the external ports in tc9563_pwrctrl_disable_port()
PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node
dt-bindings: PCI: toshiba,tc9563: Restrict Tx Amplitude, DFE and N_FTS to USP, DSP1 and DSP2
PCI/pwrctrl: tc9563: Take i2c adapter module reference
- Avoid spurious runtime PM wakeup on config space accesses that are
outside config space and fail before reaching PCI (Krzysztof Wilczyński)
- Warn on user-space writes to kernel-exclusive config space regions, as we
already do for sysfs (Krzysztof Wilczyński)
- Check credentials of opener, not reader, for config space reads, as we
already to for sysfs (Krzysztof Wilczyński)
* pci/procfs:
PCI/proc: Use file_ns_capable() when checking config space read access
PCI/proc: Warn on writes to kernel-exclusive config space regions
PCI/proc: Avoid spurious runtime PM wakeup on config space accesses
- Allow probing even without child services so it can do power management
(Brian Norris)
* pci/portdrv:
PCI/portdrv: Allow probing even without child services
- Allow D3 for native hotplug-capable Root Ports on non-x86 platforms (we
avoid D3 for these ports on x86 because some old platforms didn't
validate it) (Manivannan Sadhasivam)
* pci/pm:
PCI: Allow D3 for native hotplug-capable Root Ports on non-x86 platforms
- Pass empty string, not an uninitialized device_class string, to
acpi_bus_generate_netlink_event(), so we can remove device_class
completely in the future (Rafael J. Wysocki)
* pci/hotplug:
PCI: acpiphp_ibm: Do not use uninitialized device_class
- Don't store pci_device_id in agp amd-k7 and via, ata, scsi nsp32, ipack
tpci200, mlxsw since the dynamic ID feature means the ID is only
guaranteed to live during probe (Gary Guo)
- Add pci_match_one_id() to match an ID directly so dynamic ID insertion
doesn't need to make a temporary device for matching (Gary Guo)
- Check for existing ID inside the dynamic ID addition critical section to
avoid a time-of-check vs time-of-use race (Gary Guo)
- Copy device ID to avoid use-after-free when match races with sysfs
dynamic ID removal (Gary Guo)
* pci/enumeration:
PCI: Fix UAF when probe runs concurrent to dyn ID removal
PCI: Fix dyn_id add TOCTOU
PCI: Make pci_match_one_device() match on ID instead of device
agp/amd-k7: Don't rely on address of pci_device_id
agp/via: Don't rely on address of pci_device_id
mlxsw: pci: Don't store pci_device_id
ipack: tpci200: Don't store pci_device_id
scsi: nsp32: Don't store pci_device_id
ata: ata_generic: Don't store pci_device_id
- Allow DPC on all Downstream Ports, not just Root Ports, when OS controls
AER (Darshit Shah)
* pci/dpc:
PCI/DPC: Allow DPC on all Downstream Ports when OS controls AER
- Avoid L0s for Realtek RTS525A, where it causes an AER interrupt storm
(Max Lee)
- Program the same ASPM Control values for every function of multi-function
devices, as recommended by the PCIe spec (Krishna Chaitanya Chundru)
- Avoid ASPM L0s, L1, and L1 PM Substates based on 'aspm-no-l0s',
'aspm-no-l1' [1], and 'aspm-no-l1ss' DT properties (Krishna Chaitanya
Chundru)
* pci/aspm:
PCI/ASPM: Mask ASPM states based on Devicetree properties
PCI/ASPM: Disable/restore ASPM on every function for multi-function devices
PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM disable/restore
PCI/ASPM: Avoid L0s for Realtek RTS525A
- Update mappings of errors to agent & layer (Lukas Wunner)
- Log agent & layer of each individual error when multiple errors detected
(Lukas Wunner)
- Log Error Source only once, not twice in separate messages (Lukas Wunner)
- Emit TLP Log only for unmasked errors (Lukas Wunner)
- Support Advisory Non-Fatal Errors (Lukas Wunner)
* pci/aer:
PCI/AER: Support Advisory Non-Fatal Errors
PCI/AER: Move retrieval of FEP and TLP Log into helper
PCI/AER: Emit TLP Log only for unmasked errors
PCI/AER: Deduplicate logging of Error Source Identification
PCI/AER: Log agent & layer for each individual error
PCI/AER: Fix mapping of errors to agent & layer
Per PCIe r7.0 sec 6.2.4.3, certain Non-Fatal Errors may be signaled using
ERR_COR instead of ERR_NONFATAL. These "Advisory Non-Fatal Errors" are
listed in sec 6.2.7 and explained in detail in sec 6.2.3.2.4.
Advisory Non-Fatal Errors set bits in the Uncorrectable Error Status
Register as well as one bit in the Correctable Error Status Register
(Advisory Non-Fatal Error Status, bit 13). The latter is masked by
default, hence these errors are currently not signaled at all (except on
non-compliant products which choose to unmask the bit).
Unmask Advisory Non-Fatal Errors on device enumeration.
Some Non-Fatal Errors are always Advisory, others may be Advisory at the
discretion of the detecting agent. If multiple errors occur, the agent
may qualify a portion as non-Advisory and signal ERR_NONFATAL in addition
to ERR_COR. In this case, there's no way to determine which Non-Fatal
Error was Advisory. Assume none is to ensure that the Uncorrectable Error
code path is taken to recover from the errors.
Introduce aer_compute_anfe_status() to compute Advisory Non-Fatal Error
bits from AER registers, based on this policy. Use it for Firmware First
error handling in pci_print_aer(), which receives an AER register dump
from the platform (UEFI r2.11 sec N.2.7).
Introduce aer_get_anfe_status() to read AER registers from a device and
feed them to aer_compute_anfe_status(). Use it for native error handling
in aer_get_device_error_info(), which gathers registers from the device
and caches the computed Advisory Non-Fatal Error bits in a new anfe_status
field in struct aer_err_info.
Regardless whether error handling is native or Firmware First, the AER
driver needs to increment error counters, signal a trace event and log
each error. When Advisory Non-Fatal Errors occur, these steps must be
performed for Correctable Errors and for Uncorrectable Errors. Achieve
this through a recursive invocation of aer_print_error() (for native error
handling) and pci_print_aer() (for Firmware First error handling). The
recursive invocation reports the (Advisory) Uncorrectable Errors after
reporting the Correctable Errors.
Note that the First Error Pointer and TLP Prefix Log is only meaningful
for Uncorrectable Errors, but when Advisory Non-Fatal Errors occur,
aer_get_device_error_info() has to populate the first_error and
tlp_header_valid fields in struct aer_err_info for a Correctable Error.
Avoid incorrectly logging those fields for Correctable Errors by amending
__aer_print_error() and aer_print_error() with conditionals.
Sample log output for an Advisory Unsupported Request Error:
pcieport 0001:00:00.4: AER: Multiple Correctable Error messages received, first one from 0001:0e:00.0
idxd 0001:0e:00.0: PCIe Bus Error: severity=Correctable
idxd 0001:0e:00.0: device [8086:1216] error status/mask=00002000/00000000
idxd 0001:0e:00.0: [13] NonFatalErr | |
idxd 0001:0e:00.0: PCIe Bus Error: severity=Uncorrectable (Non-Fatal)
idxd 0001:0e:00.0: device [8086:1216] error status/mask=00100000/00000000
idxd 0001:0e:00.0: [20] UnsupReq | Receiver | Transaction Layer (First)
idxd 0001:0e:00.0: AER: TLP Header (Flit): 0x01000104 0x00000000 0x0000080e 0x0f800001
This commit takes inspiration (but differs significantly) from an earlier
submission by Zhenzhong Duan, which in turn was based on a submission by
Qingshun Wang:
https://lore.kernel.org/r/20240620025857.206647-1-zhenzhong.duan@intel.com/
Prior attempts at supporting Advisory Non-Fatal Errors were submitted by
Yicong Yang and Dio Sun:
https://lore.kernel.org/r/1614689994-10925-1-git-send-email-yangyicong@hisilicon.com/https://lore.kernel.org/r/BJXPR01MB0614C01A9523786117B1F1CBCEC8A@BJXPR01MB0614.CHNPR01.prod.partner.outlook.cn/
Signed-off-by: Lukas Wunner <lukas@wunner.de>
[bhelgaas: fold in https://lore.kernel.org/all/amdnMg_J6T3Sys45@wunner.de,
https://lore.kernel.org/all/120da0565eac0157ffd913423c7cfa66e985ff59.1786800931.git.lukas@wunner.de]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20240620025857.206647-1-zhenzhong.duan@intel.com/
Link: https://lore.kernel.org/r/1614689994-10925-1-git-send-email-yangyicong@hisilicon.com/
Link: https://lore.kernel.org/r/BJXPR01MB0614C01A9523786117B1F1CBCEC8A@BJXPR01MB0614.CHNPR01.prod.partner.outlook.cn/
Link: https://patch.msgid.link/1b62915ffe06ee5b08e846531c42392e5f244337.1784905909.git.lukas@wunner.de
Some platforms require selectively disabling specific ASPM states on a
given PCIe link to avoid link instability or functional failures caused by
board-level connectivity constraints such as PCB routing, connectors,
slots, or external cabling.
Devicetree supports disabling ASPM L0s, L1, and L1 PM Substates via the
'aspm-no-l0s', 'aspm-no-l1' [1], and 'aspm-no-l1ss' [2] properties.
However, the ASPM driver does not currently honor these properties when
initializing the default link state.
When firmware enables L1 PM Substates before the kernel takes over,
masking aspm_support alone is insufficient to disable them in hardware.
pcie_config_aspm_link() guards L1SS configuration behind a check on
aspm_capable, which is derived from aspm_support. Once aspm_support is
masked, pcie_config_aspm_l1ss() is never called, leaving
firmware-enabled L1SS substates active in hardware.
Fix this by introducing pcie_link_has_aspm_override() to check for DT
override properties on either endpoint of the link. In
pcie_aspm_override_default_link_state(), use it to:
- Mask aspm_support, aspm_default, and aspm_enabled for any disabled
state, so software's view of the link stays in sync with what is
actually programmed in hardware. Leaving aspm_enabled stale would make
pcie_aspm_enabled() and the aspm sysfs attributes report a state as
active even after it has been masked, and could cause
pcie_config_aspm_link()'s "already in requested state" check to skip
reprogramming hardware to match.
- Explicitly call pcie_config_aspm_l1ss(link, 0) before masking
aspm_support when firmware has L1SS active and DT requests disabling L1
or L1SS, since pcie_config_aspm_link() will no longer do so once
aspm_capable is derived from the masked aspm_support.
Move the aspm_default initialization and
pcie_aspm_override_default_link_state() call in pcie_aspm_cap_init() to
before the "Restore L0s/L1" block. pcie_aspm_cap_init() disables L1 in
hardware prior to aspm_l1ss_init() and re-enables it only in the restore
block. Calling pcie_config_aspm_l1ss() while L1 is already disabled
satisfies its precondition ("Caller must disable L1 first"), whereas the
previous placement after the restore violated it.
Since the restore block writes back the parent_lnkctl/child_lnkctl snapshot
taken from hardware before the DT override ran, mask the L0s and L1 enable
bits out of that snapshot for any state the override has just disabled in
aspm_support. Otherwise the restore step would unconditionally reprogram
the link back to firmware's original L0s/L1 configuration, defeating the
Devicetree override it is meant to enforce.
Move pcie_config_aspm_l1ss() earlier in the file so it can be called
from pcie_aspm_override_default_link_state().
Link [1]: https://github.com/devicetree-org/dt-schema/pull/188
Link [2]: https://github.com/devicetree-org/dt-schema/pull/190
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260727-aspm-v6-3-2ebb3ee7ef71@oss.qualcomm.com
pcie_aspm_cap_init() disables ASPM L0s/L1 before touching L1SS config, then
restores the pre-existing state afterward. Both steps only ever touched
link->downstream, i.e. function 0 of the downstream component, leaving
sibling functions (>0) on a multi-function device untouched.
This means the "disable" step does not actually disable ASPM link-wide on a
multi-function device: a sibling function can still have L1 enabled even
after this step runs. PCIe r7.0, sec 7.5.3.7, recommends programming the
same ASPM Control value for all functions of a multi-function device, and
pcie_config_aspm_link() already loops over every function on the bus for
exactly this reason.
Loop over every function on linkbus->devices for both the disable and
restore steps, keeping the existing sec 7.5.3.7 ordering (disable
downstream functions before upstream, restore upstream before downstream
functions). The masked pcie_capability_clear_and_set_word() accessor from
the previous commit makes this safe: it only ever touches the ASPM Control
bits, so function-specific bits elsewhere in LNKCTL (e.g. Read Completion
Boundary, CLKREQ Enable) on sibling functions are left untouched.
Fixes: 7447990137 ("PCI/ASPM: Disable L1 before disabling L1 PM Substates")
Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260727-aspm-v6-2-2ebb3ee7ef71@oss.qualcomm.com
Writing a PCI Host Controller driver requires bringing up the Root Complex
hardware and registering it with the PCI core in a specific sequence. Add
a guide describing these steps to help developers write new drivers.
It covers the Root Complex topology and enumeration, and walks through the
driver flow, including resource setup, Configuration Space accessors,
address translation, interrupt handling, Link training, power management,
shutdown and removal, using standard guidelines/best practices.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260803-pci-doc-v1-1-2814f8672cad@oss.qualcomm.com
pcie_aspm_cap_init() disables ASPM L0s/L1 on both ends of the Link
before touching L1SS config, then later restores the LNKCTL state
that was in effect beforehand. Both steps use raw
pcie_capability_write_word() calls: the disable step computes the
new value by hand from a snapshot taken earlier in the function, and
the restore step writes that same snapshot straight back.
Switch both steps to pcie_capability_clear_and_set_word(), masked to
PCI_EXP_LNKCTL_ASPMC, matching the accessor pcie_config_aspm_dev()
already uses elsewhere in this file for the exact same register. This
does a live read-modify-write of just the ASPM Control bits instead of
relying on a stale snapshot for the rest of the word, and is
consistent with how the rest of the file already touches this
register. No functional change.
Fixes: 7447990137 ("PCI/ASPM: Disable L1 before disabling L1 PM Substates")
Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260727-aspm-v6-1-2ebb3ee7ef71@oss.qualcomm.com
Commit eb3b5bf1a8 ("PCI: Whitelist native hotplug ports for runtime D3"),
prevented native hotplug-capable Root Ports from entering D3 citing issues
on old Intel SkyLake Xeon-SP platform.
But there is no reason to restrict D3 for native hotplug-capable Root Ports
on non-x86 platforms. We recently enabled D3 on non hotplug-capable Root
Ports on non-x86 platforms (specifically for DT platforms) in commit
a5fb3ff632 ("PCI: Allow PCI bridges to go to D3Hot on all non-x86"). So
do the same for native hotplug-capable Root Ports as well.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260729165005.896725-1-manivannan.sadhasivam@oss.qualcomm.com
The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
Timer Timeout storm when ASPM L0s is enabled on its link. On an affected
HP ZBook Power 16 inch G11, the Root Port received tens of millions of AER
interrupts from the RTS525A even when the rtsx_pci driver was blacklisted
and the endpoint was not enabled by a driver.
For example:
pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0
rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID)
rtsx_pci 0000:58:00.0: device [10ec:525a] error status/mask=00001000/00006000
rtsx_pci 0000:58:00.0: [12] Timeout
pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0
Testing with OS-native AER control showed that disabling only L0s on the
RTS525A link stops new AER interrupt and counter growth while leaving L1
enabled. Disabling L1, L1 substates, or Clock PM alone did not stop the
storm.
Prevent the broken L0s configuration by removing L0s from the RTS525A
advertised ASPM capability. This avoids enabling the non-working ASPM
state instead of masking the resulting AER Replay Timer Timeout reports.
Signed-off-by: Max Lee <max.lee@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260707021527.639611-1-max.lee@canonical.com
proc_bus_pci_read() decides how much of the config space is readable based
on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling
read(), not the credentials of the process that opened the file.
The sysfs equivalent, pci_read_config(), has checked the credentials of the
opening process since commit de139a3393 ("pci: check caps from sysfs file
open to read device dependent config space"), so a privileged process can
open the config space file and pass the file descriptor to an unprivileged
process (for example, a process running a KVM guest with an assigned
device), which can then read the entire config space. The check was
subsequently routed through the LSM framework in commit 47970b1b2a ("pci:
use security_capable() when checking capablities during config space read")
and converted to the dedicated helper in commit ab0fa82b2d ("pci-sysfs:
use proper file capability helper function").
Thus, the two interfaces check the same capability against different
credentials. Checking the credentials of the task calling read() makes the
outcome depend on who reads rather than who opened, so the restriction is
bypassed whenever a more privileged process reads through the descriptor.
Checking the credentials recorded in file->f_cred settles the decision at
open() time and ties it to the file, where it cannot change with the
caller.
Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in
effect when the file was opened, bringing the procfs interface in line with
the sysfs behaviour.
As a result, a file descriptor opened by a privileged process and passed to
an unprivileged one now allows the entire config space to be read through
procfs, matching sysfs.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260720204145.1500105-1-kwilczynski@kernel.org
Currently, a driver can claim a region of a device's config space as
exclusive using pci_request_config_region_exclusive(), after which a write
to that region originating from user space is expected to emit a warning
and taint the kernel. The check is advisory only, as the write itself is
still allowed to proceed.
Since commit 278294798a ("PCI: Allow drivers to request exclusive config
regions"), the sysfs config space attribute performs this check in
pci_write_config(), but the procfs interface was never updated. A write
performed through /proc/bus/pci/BB/DD.F therefore bypasses the detection
entirely, even though both interfaces offer the same level of access.
Add the same resource_is_exclusive() check to proc_bus_pci_write().
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260729075413.1215821-1-kwilczynski@kernel.org
Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return early
for zero-length configuration space accesses at valid offsets.
Such an access invokes pci_config_pm_runtime_get() and
pci_config_pm_runtime_put() around transfer blocks that do nothing.
This is a problem because pci_config_pm_runtime_get() synchronously resumes
the upstream bridge through pm_runtime_get_sync(), and resumes the device
itself through pm_runtime_resume() when it is in D3cold, only for the
handler to return zero immediately afterwards. Such a spurious wakeup
wastes power and adds needless resume latency.
The sysfs core already returns early for in-range zero-length binary
attribute accesses before pci_read_config() or pci_write_config() is
invoked. In contrast, the VFS forwards zero-length requests to the procfs
callbacks, where they continue into runtime PM handling.
Return early from proc_bus_pci_read() and proc_bus_pci_write() when nbytes
is zero, before any runtime PM involvement.
The value returned to userspace at these offsets remains zero,
so the change is not visible to userspace.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: order tags]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260729075909.1219906-1-kwilczynski@kernel.org
Currently there is a TOCTOU issue in new_id_store() as the dyn ID insertion
in pci_add_dynid() and the pci_match_device() are in separate critical
sections.
Fix this by moving the existing ID check to inside pci_add_dynid() and only
check against the static ID table outside the critical section.
Fixes: 3853f9123c ("PCI: Avoid duplicate IDs in driver dynamic IDs list")
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-8-3580726844e1@garyguo.net
PCI dynamic ID needs to match IDs against a new ID to see if it already
exists. Existing APIs can only match IDs against devices, so the dynamic ID
insertion code creates a temporary device only for matching purposes.
Rename pci_match_one_device() to pci_match_one_id() so it can be used for
this purpose instead; add a pci_id_from_device() helper to make it easy to
convert users.
Similarly, convert pci_match_id() to do_pci_match_id(). But keep the
existing API because there are many users.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-7-3580726844e1@garyguo.net
Address of pci_device_id cannot be relied on due to presence of dynamic ID
and driver_override. Use driver_data instead.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-6-3580726844e1@garyguo.net
Address of pci_device_id cannot be relied on due to presence of dynamic ID
and driver_override. Use driver_data instead.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-5-3580726844e1@garyguo.net
pci_device_id is not guaranteed to live longer than probe due to presence
of dynamic ID. This stored ID is unused so remove it.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-4-3580726844e1@garyguo.net
pci_device_id is not guaranteed to live longer than probe due to presence
of dynamic ID. This stored ID is unused so remove it.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-3-3580726844e1@garyguo.net
pci_device_id is not guaranteed to live longer than probe due to presence
of dynamic ID. All information apart from driver_data can be easily
retrieved from pci_dev, so just store driver_data.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-2-3580726844e1@garyguo.net
pci_device_id is not guaranteed to live longer than probe due to presence
of dynamic ID. All information apart from driver_data can be easily
retrieved from pci_dev, so just store driver_data.
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://patch.msgid.link/20260723-pci_id_fix-v4-1-3580726844e1@garyguo.net
'tc9563_pwrctrl_ports' is supposed to list only the internal ports of the
switch. But it currently lists the integrated MAC Endpoint as well, which
is wrong.
Move it to a separate 'ep_cfg' struct and also configure/parse the ports
and the MAC Endpoint separately.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260725-tc9563-fix-v1-6-ec4286e31331@oss.qualcomm.com
TC9563 Reference Manual calls DSP3 as VDSP (Virtual Downstream Port). Name
it as such to avoid ambiguity.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260725-tc9563-fix-v1-5-ec4286e31331@oss.qualcomm.com
TC9563 supports powering off only the external facing ports like DSP1 and
DSP2. It is not recommended to power off USP and DSP3 as they have fixed
ports/endpoint connected.
Fix tc9563_pwrctrl_disable_port() to power off only DSP1 and DSP2.
Fixes: 4c9c7be473 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260725-tc9563-fix-v1-3-ec4286e31331@oss.qualcomm.com
DSP3 has an integrated Ethernet MAC Endpoint which has its own set of
config registers for configuring settings such as ASPM. The Endpoint device
has two physical functions and those two functions share the same settings.
Parse the Endpoint node under DSP3 instead of parsing both functions. The
existing parsing logic also has one OOB issue as parsing both functions
will result in accessing past the tc9563_pwrctrl->cfg array.
Fixes: 4c9c7be473 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260725-tc9563-fix-v1-2-ec4286e31331@oss.qualcomm.com
TC9563 switch allows configuring Tx Amplitude, DFE and N_FTS settings only
to USP, DSP1 and DSP2 ports. These settings don't apply to DSP3 or the
integrated Ethernet MAC Endpoint.
Restrict these properties and move 'toshiba,tx-amplitude-microvolt' to DSP2
in the example to conform to the binding.
Fixes: 26f3ac8848 ("dt-bindings: PCI: Add binding for Toshiba TC9563 PCIe switch")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20260725-tc9563-fix-v1-1-ec4286e31331@oss.qualcomm.com
When aer_get_device_error_info() gathers information on Uncorrectable
Errors from a device, it reads the First Error Pointer and TLP Prefix/
Header Log and caches them in struct aer_err_info.
Those two fields will also need to be read for Advisory Non-Fatal Errors
(which are signaled as Correctable Errors). Move their retrieval into a
new aer_get_uncor_info() helper for reuse by the imminent Advisory
Non-Fatal Error support.
No functional change intended.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/0f2f037c7ccf099f0c253cbc4ad9be526c68c5af.1784905909.git.lukas@wunner.de
Per PCIe r7.0 sec 6.2.5, the prefix and header of an offending TLP is only
recorded for unmasked Uncorrectable Errors. Yet when the AER driver
determines whether a prefix and header has been logged, it does not take
the Uncorrectable Error Mask Register into account. Fix it.
Fixes: 6c2b374d74 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v2.6.19+
Link: https://patch.msgid.link/2e712b96ba5bfc729d78bfc23f7fb7d285aa3d6d.1784905909.git.lukas@wunner.de
aer_print_source() already logs the Error Source Identification Register:
AER: Multiple Correctable error message received from 0000:b7:02.0
However aer_print_error() subsequently identifies the Error Source once
more by emitting an "Error of this Agent is reported first" message.
The additional message was introduced by commit 0d465f2350 ("PCI: pcie,
aer: fix report of multiple errors") because it deemed the message emitted
by aer_print_source() confusing: When the Multiple ERR_COR Received or
Multiple ERR_FATAL/NONFATAL Received bit in the Root Error Status Register
is set, it doesn't mean that all errors originated from the device in the
Error Source Identification Register. Rather, the errors may have come
from multiple distinct devices. The commit sought to make that clearer.
Achieve the commit's objective by rephrasing the message emitted by
aer_print_source() and drop the additional message logged by
aer_print_error() to reduce dmesg noisiness and simplify the code.
While modifying the log message anyway, fix minor grammatical issues:
Append a plural "s" to "message", add a missing closing brace to "(no
details found" and capitalize "Error" to match the spec.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/3a5d1624d6912db1bc8c4e89e7a6a72ac510f4dc.1784905909.git.lukas@wunner.de
The AER driver maps detected errors to the corresponding agent and layer
per PCIe r7.0 sec 6.2.7 and logs both.
If multiple errors were detected, their agent and layer may differ.
However the AER driver only logs one agent and one layer for all of them,
which seems nonsensical.
Log the agent and layer for each individual error instead.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/d983b813043c518d098e2919161e816b91f15862.1784905909.git.lukas@wunner.de
PCIe r7.0 sec 6.2.7 documents the agent and layer of each Correctable and
Uncorrectable Error. Based on this spec section, the AER driver maps
detected errors to an agent and layer using a set of macros and logs them.
Most errors listed in sec 6.2.7 map to the "Receiver" agent and
"Transaction Layer", so the macros use these as defaults unless an error
maps to something else.
However the macros have not been amended since their introduction in 2006
with commit 6c2b374d74 ("PCI-Express AER implemetation: AER core and
aerdriver"). They are still based on PCIe r1.0 sec 7.2.5 (renumbered to
6.2.7 in PCIe r1.1 and newer).
Amend the macros to map errors introduced since then to the appropriate
agent and layer.
PCIe r2.1 introduced a new "Component" agent and "General" layer for
Internal Errors and Header Log Overflow. Add them to the macros.
Unsupported Request is currently mapped to the "Requester" agent, even
though it is reported by the "Receiver". Fix the incorrect mapping.
Sec 6.2.7 neglects to list an agent for Data Link Protocol Error and
Surprise Down Error. Map the latter to "Component" because PCIe r7.0 sec
3.2.1 states that the error is "associated with the detecting Port". Map
the former to "Receiver" because every occurrence of Data Link Protocol
Error in the spec refers to it being logged in the Receiving Port. I have
had these errata reported to the PCI-SIG Protocol Working Group. (There's
also a layout erratum in the REPLAY_NUM Rollover row wherein columns are
shifted to the left, but that's already corrected in the PCIe r7.1 draft
as of 2026-04-07.)
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aec4820a75e949b332585a08cb1808fda7f40ea4.1784905909.git.lukas@wunner.de
The PCIe port driver fails to probe if it finds no child services,
presumably under the assumption that the driver is not useful in that case.
However, the driver *can* still be useful for power management support --
namely, it still configures the port for runtime PM / D3, which may be
important for allowing a bridge to enter low power modes.
Thus, allow probe to succeed even if no IRQs and no child services are
available. This also mirrors existing behavior for ports that don't support
any portdrv services (PCIe hotplug, AER, DPC, PME, bwctrl), where we'd also
probe successfully.
This change is a bit more important after commit f5cd8a929c ("PCI: dwc:
Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI
controller"), because it's common for some DWC-based systems to:
1. have only the "aer" and "pcie_pme" port services available and
2. not define legacy INTx interrupts properly in their device tree.
After commit f5cd8a929c, such systems may fail pcie_init_service_irqs()
and so exit with -ENODEV.
Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5oajnqdwb33xkcdwk@76vnrx45fsfd/
Signed-off-by: Brian Norris <briannorris@chromium.org>
[bhelgaas: reorder pcie_port_device_register() decls per Lukas]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b3949d8ab2f16ba8244fd3e774@changeid
In nested topologies, hotplug reservations get added multiple times into
the bridge window higher up in the hierarchy. Adding reservations for
intermediate level bridges does not seem very useful because the hotplug is
going to add device at a leaf.
Accounting the hotplug reservation multiple times results in larger than
expected bridge window size that may lead to assignment failures as shown
in this log:
pci_bus 0000:0a: root bus resource [mem 0x10a00000-0x10c00fff window]
pci 0000:0a:00.0: BAR 0 [mem 0x10c00000-0x10c00fff]
pci 0000:0a:00.0: bridge window [mem 0x10a00000-0x10bfffff]
pci 0000:0b:00.0: bridge window [mem 0x10a00000-0x10bfffff]
pci 0000:0c:02.0: bridge window [mem 0x10a00000-0x10bfffff]
pci 0000:0c:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 0d] add_size 200000 add_align 100000
pci 0000:0c:02.0: bridge window [mem 0x00100000-0x000fffff] to [bus 0d] add_size 200000 add_align 100000
pci 0000:0b:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 0c-0d] add_size 200000 add_align 100000
pci 0000:0b:00.0: bridge window [mem 0x00100000-0x000fffff] to [bus 0c-0d] add_size 200000 add_align 100000
pci 0000:0a:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 0b-0d] add_size 400000 add_align 100000
pci 0000:0a:00.0: bridge window [mem 0x00100000-0x000fffff] to [bus 0b-0d] add_size 400000 add_align 100000
pci 0000:0a:00.0: bridge window [mem size 0x00400000]: can't assign; no space
pci 0000:0a:00.0: bridge window [mem size 0x00400000]: failed to assign
pci 0000:0a:00.0: bridge window [mem size 0x00400000 64bit pref]: can't assign; no space
pci 0000:0a:00.0: bridge window [mem size 0x00400000 64bit pref]: failed to assign
The problem stems from calculate_memsize() that calculates size first and
then adds childen size:
size = max(0, 2M) + 2M
Alter the logic to first account for the children size before applying the
hotplug reservation to not add hotplug reservation multiple times on
different levels of a nested topology. As a result, the size calculation
becomes:
size = max(0 + 2M, 2M)
Reported-by: Eric Auger <eauger@redhat.com>
Link: https://lore.kernel.org/linux-pci/f23946f2-06ac-4607-8f2c-3ffbc52b627a@redhat.com/
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260720162416.5771-1-ilpo.jarvinen@linux.intel.com
Nvidia Vera Rubin platforms support PCI peer‑to‑peer transactions. Add
them to the P2P whitelist to enable this functionality.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://patch.msgid.link/20260705-p2p-vr-v1-1-3cd45cab3fb4@nvidia.com
The i2c subsystem currently blocks during adapter deregistration whenever
there are consumers holding a reference.
Switch to using of_get_i2c_adapter_by_node() which also takes a reference
to the adapter module so that an attempt to unload the module while in use
fails gracefully instead of blocking uninterruptibly.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260716132532.1565340-1-johan@kernel.org
Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup
table. Without it, DMA transactions from a PCI1008 switch's NTB function
are not given the correct requester ID alias, which can misdirect them
under an IOMMU.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
Add the Microchip PCI1008 device ID to the core switchtec management
driver's PCI ID table. Without it, the management endpoint on a PCI1008
switch is not bound by this driver, preventing userspace tools from
configuring or monitoring the switch and leaving NTB functionality
unavailable.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
