| Age | Commit message (Collapse) | Author |
|---|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next
Manivannan writes:
MHI Host
--------
- Add SAHARA channel support in the pci_generic driver for Foxconn products.
This allows capturing crashdump (ramdump) using the in-kernel sahara client
driver.
- Add support for devices with no M3 state. Some devices do not support the
M3 power state due to hardware issues. For those devices, MHI bus will now
run the full host-side suspend/resume sequence but skip the device-side
M3/M0 handshake, so any transfer queued by clients during suspend is
deferred until resume.
- Set 'mhi_cntrl->no_m3' flag in the pci_generic driver for the QDU100 device
so that the MHI bus also skips the M3 transition during system suspend.
Earlier, the flag was only used to disable runtime PM, but the system
suspend path was still transitioning the device to M3.
- Fix sys error transition latency by polling for the state transition in
mhi_pm_sys_error_transition() instead of waiting up to 24 seconds for an
interrupt from the device. Since a device that has been reset (e.g., via
AT!RESET) is not guaranteed to raise one.
- Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET in
mhi_soc_reset() so that the reset actually reaches the device before the
caller's post-reset delay begins.
- Fix controller cleanup on EDL sysfs failure in mhi_register_controller().
The error path was leaving the device registered when sysfs_create_file()
failed.
MHI Endpoint
------------
- Add mhi_cntrl->flush_async() callback to drain the in-flight async DMA
read/write operations issued through the MHI controller driver. This is
used by the MHI EP stack before disconnect to avoid UAF where a late DMA
completion could invoke a now-invalid xfer_cb().
- Implement the flush_async() callback in the PCI EPF MHI controller driver
by waiting for the in-flight DMA operations to complete and then flushing
the DMA workqueue. Since I'm the maintainer for this PCI EPF driver, I'm
taking this patch through MHI tree due to dependency.
- Flush the in-flight async transfers before notifying disconnect in
mhi_ep_abort_transfer() to fix a UAF, where a success callback delivered
after the -ENOTCONN notification could reference resources already freed
by the client.
- Fix device refcount leak in the error path of mhi_ep_create_device() when
dev_set_name() or device_add() fails.
Common
------
- Clean up kernel-doc warnings in include/linux/mhi.h.
- Add Jeff Hugo as the Reviewer of MHI bus.
* tag 'mhi-for-v7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi:
PCI: epf-mhi: Implement mhi_cntrl->flush_async() to flush DMA read/write
bus: mhi: ep: Flush async transfers before notifying disconnect in mhi_ep_abort_transfer()
bus: mhi: ep: Add mhi_cntrl->flush_async() callback to flush the async read/write
bus: mhi: Clean up some kernel-doc warnings
bus: mhi: host: Fix controller cleanup on EDL sysfs failure
bus: mhi: pci_generic: Add SAHARA channel support for Foxconn products
bus: mhi: host: pci_generic: Set 'mhi_cntrl->no_m3' flag
bus: mhi: host: Add support for devices with no M3 state
bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET
MAINTAINERS: Add Jeff Hugo as the Reviewer of MHI bus
bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation
bus: mhi: core: Fix sys error transition latency
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Quite a bunch more work, of note:
- iwlwifi: new FW version support
- mt76:
- mt7928 support
- mt7925 NAN support
- mt7996 AP powersave improvements
- rtw89:
- LED support
- RTL8922DE support
- dual-BT coex for RTL8922D
- ath12k: AHB platform MultiPD support
- cfg80211: pre-assign cookies for operations
- mac80211: AQL support for multicast
* tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (403 commits)
wifi: nxpwifi: bound uAP association event IEs to the event buffer
wifi: nxpwifi: detach sync command buffer on interrupted wait
wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()
wifi: rsi: Fix types to appease CFI
wifi: mac80211: skip default WMM setup for AP_VLAN links
wifi: nxpwifi: fix multiple static analysis errors and warnings
wifi: morsemicro: MM81X should be invisible and selected by its users
wifi: nxp: NXPWIFI should be invisible and selected by its users
wifi: cfg80211: stop PMSR before P2P and NAN teardown
wifi: mac80211: disconnect on CSA to channel 0
wifi: brcmfmac: fix P2P action frame handling without device vif
wifi: brcmfmac: Set DMA direction for msgbuf packet IDs
wifi: brcmfmac: validate msgbuf flowring IDs before use
wifi: mac80211: fix RCU usage in peer probing
wifi: mac80211: fix RCU dereference in throughput estimate
wifi: wilc1000: validate monitor transmit frame headers
wifi: mac80211: skip unused probe response countdown offsets
wifi: zd1211rw: reject secondary interfaces to prevent conflicts
wifi: nl80211: clean up color-change beacon data on errors
wifi: mac80211: send TWT teardown to peer after setup TX failure
...
====================
Link: https://patch.msgid.link/20260806121304.190084-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The cadence-plat driver has a single platform driver that can be built-in
or a loadable module, but it calls two separate backend drivers depending
on whether it is a host or endpoint.
If one of the mode is build as built-in and another as loadable module,
we end up with a situation where the built-in pcie-cadence-plat driver
tries to call the modular host or endpoint driver, which causes a link
failure:
ld: error: undefined symbol: cdns_pcie_ep_setup
>>> referenced by pcie-cadence-plat.c
>>> drivers/pci/controller/cadence/pcie-cadence-plat.o:(cdns_plat_pcie_probe) in archive vmlinux.a
ld: error: undefined symbol: cdns_pcie_host_setup
>>> referenced by pcie-cadence-plat.c
>>> drivers/pci/controller/cadence/pcie-cadence-plat.o:(cdns_plat_pcie_probe) in archive vmlinux.a
Fix this by moving the 'select' of PCIE_CADENCE_HOST and PCIE_CADENCE_EP
from the individual PLAT_HOST/PLAT_EP symbols into the common PCIE_CADENCE_PLAT
symbol, conditioned on which backends (modes) are enabled.
Fixes: 611627a4e5e4 ("PCI: cadence: Add module support for platform controller driver")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/linux-next/589ea512-93c6-4e1c-83d7-ba45a0b35843@infradead.org/
Signed-off-by: Aksh Garg <a-garg7@ti.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260805105014.3952686-1-a-garg7@ti.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 de139a339395 ("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 47970b1b2aa6 ("pci:
use security_capable() when checking capablities during config space read")
and converted to the dedicated helper in commit ab0fa82b2df9 ("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 278294798ac9 ("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, the static binary attributes for the PCI legacy I/O port
and ISA memory space files (legacy_io, legacy_io_sparse, legacy_mem and
legacy_mem_sparse) are open-coded, with each definition repeating the
same set of properties and callbacks.
Add two macros for declaring such attributes:
- pci_legacy_resource_io_attr(), for legacy I/O port space (read/write)
- pci_legacy_resource_mem_attr(), for legacy memory space (mmap)
Each macro takes the fixed attribute size as a parameter.
Then replace the open-coded definitions with the newly added macros.
No functional changes intended.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: shorten macros to fit in 80 columns]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260721020427.1541197-4-kwilczynski@kernel.org
|
|
Currently, the static binary attributes for the PCI resource files are
generated with the names dev_resource<N>_io_attr, dev_resource<N>_uc_attr
and dev_resource<N>_wc_attr.
The macros that generate these attributes and the arrays that collect them
already carry the pci_ prefix, as do the sibling legacy I/O and memory
attributes, such as pci_legacy_io_attr. Only the generated variable names
lack it.
Rename the generated variables to pci_dev_resource<N>_io_attr,
pci_dev_resource<N>_uc_attr and pci_dev_resource<N>_wc_attr, and update the
attribute pointer arrays to match.
While at it, re-align the continuation backslashes in the resource
attribute macros to match.
No functional changes intended.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: shorten pci_dev_resource##_bar##_wc_attr to fit in 80 columns]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260721020427.1541197-2-kwilczynski@kernel.org
|
|
Currently, the legacy I/O and memory sysfs handlers do not check
security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and
legacy_mem files unprotected when the kernel is locked down.
Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked
down") added the check to pci_write_config(), pci_mmap_resource(), and
pci_write_resource_io() to prevent userspace from programming DMA-capable
hardware that could be used to modify kernel code, but did not cover the
legacy handlers.
As a result, root can still write arbitrary I/O ports and map the legacy
I/O and memory spaces while the kernel is locked down, which is the same
capability the lockdown is meant to remove.
Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and
pci_mmap_legacy_io().
These generic handlers cover both architectures that define HAVE_PCI_LEGACY
(such as Alpha and PowerPC).
Fixes: eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down")
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: add Link]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260720211541.1509744-1-kwilczynski@kernel.org
|
|
Currently, mmap() of a resourceN file for an I/O BAR fails with -ENODEV on
architectures where arch_can_pci_mmap_io() is 0, such as x86, because the
attribute has no mmap callback there and the error comes from the generic
kernfs dispatch.
This is a side effect of commit e854d8b2a82e ("PCI: Add
arch_can_pci_mmap_io() on architectures which can mmap() I/O space"),
which removed the mmap callback from the I/O resource attribute on
these architectures. Previously the request reached the architecture
mmap code and failed with -EINVAL, and the same commit deliberately
kept -EINVAL for the identical operation on the procfs interface, so
the two PCI userspace interfaces have disagreed ever since.
Add a pci_mmap_resource_io_unsupported() callback that
returns -EINVAL and use it as the mmap handler of the I/O resource
attribute when arch_can_pci_mmap_io() is 0, so the failure is
produced deliberately by PCI code, consistent with the procfs
interface and with the behaviour before e854d8b2a82e.
Architectures where arch_can_pci_mmap_io() is non-zero keep the real
pci_mmap_resource_uc() handler and are unaffected. The mmap() fails
either way. Only the reported error changes from -ENODEV to -EINVAL.
Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space")
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260720204624.1503794-1-kwilczynski@kernel.org
|
|
Currently, the boundary checks in pci_read_config() and pci_write_config()
reject only offsets beyond the effective configuration space size.
An access at an offset exactly equal to that size passes the check, has its
length clamped to zero, and then 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 clamps accesses against the attribute size set
through the bin_size() callback, which reports either 256 or 4096 bytes.
As such, the affected accesses are reads at offset 64 (or 128 for CardBus
devices) through files opened without CAP_SYS_ADMIN, and reads and writes
at the exact configuration space size on devices where a quirk sets a
non-standard size.
Reject accesses at the boundary offset as well, so they return early before
any runtime PM involvement, matching the procfs implementations in
proc_bus_pci_read() and proc_bus_pci_write().
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: tweak commit log, order tags]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260720204356.1501749-1-kwilczynski@kernel.org
|
|
The PCIe link may go down in cases like firmware crashes or unstable
connections. When this occurs, the Root Port must be reset to restore the
functionality. However, the current driver lacks link down handling,
forcing users to reboot the system to recover.
Implement the .reset_root_port() callback for link down handling for the
Rockchip DWC PCIe host controller. The RC is reset, reconfigured, and link
training initiated to recover from the link down event.
This also by extension fixes issues with sysfs-initiated bus resets.
Currently, the endpoint device is non-functional after a sysfs initiated
bus reset (it may link up with downgraded link status). With the link down
handling support, a sysfs initiated bus reset works as intended. Testing
conducted on a ROCK5B board with an M.2 NVMe drive.
Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260727172654.605988-4-cassel@kernel.org
|
|
The PCIe link can go down under circumstances such as the device firmware
crash, link instability, etc. When that happens, the Root Port needs to be
reset to make it operational again. Currently, the driver is not handling
the link down event, so users have to restart the machine to make PCIe link
operational again. Fix it by detecting the link down event and resetting
the Root Port.
Since the Qcom PCIe controllers report the link down event through the
'global' IRQ, enable the link down event by setting PARF_INT_ALL_LINK_DOWN
in the PARF_INT_ALL_MASK register.
In the case of the event, iterate through the available Root Ports and call
pci_host_handle_link_down() API with Root Port 'pci_dev' to let the PCI
core handle the link down condition. Since Qcom PCIe controllers only
support one Root Port per controller instance, the API will be called only
once. But the looping is necessary as there is no PCI API available to
fetch the Root Port instance without the child 'pci_dev'.
The API will internally call the 'pci_host_bridge::reset_root_port()'
callback to reset the Root Port in a platform-specific way. Implement the
callback to reset the Root Port by first resetting the PCIe core, followed
by reinitializing the resources and then finally starting the link again.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-4-53570b92064d@oss.qualcomm.com
|
|
The MSI path in dw_pcie_ep_raise_msi_irq() keeps its outbound iATU window
mapped across writes as a cache. The MSI-X path in
dw_pcie_ep_raise_msix_irq() maps and unmaps a window around every write.
Both use the same local aperture, ep->msi_mem_phys, as the CPU side address
that the iATU translates to the host's MSI or MSI-X target.
If dw_pcie_ep_raise_msi_irq() has cached its mapping and
dw_pcie_ep_raise_msix_irq() is then called, dw_pcie_ep_map_addr() allocates
a fresh outbound window for the MSI-X target. It does not notice that
ep->msi_mem_phys is already mapped by the MSI window, because
dw_pcie_ep_outbound_atu() only looks for a free window and does not
deduplicate by address. The controller now has two iATU windows whose
outbound_addr[] entry equals ep->msi_mem_phys.
When dw_pcie_ep_raise_msix_irq() later calls dw_pcie_ep_unmap_addr() to
tear down its own window, the lookup in dw_pcie_find_index() walks
ob_window_map in ascending index order and returns the first match. That is
the MSI window, since it was mapped first. The MSI window is torn down, the
MSI-X window is left in place, and ep->msi_iatu_mapped is never cleared.
The next MSI writel() therefore takes the cached fast path, writes into an
aperture whose iATU has been disabled, and the interrupt is silently lost.
To fix this issue, unmap the cached MSI iATU in dw_pcie_ep_raise_msix_irq()
before the MSI-X map, and clear ep->msi_iatu_mapped so that the next MSI
writel() reprograms the window. This guarantees that at most one iATU
window maps ep->msi_mem_phys at any time, so the subsequent
dw_pcie_find_index() call unambiguously returns the MSI-X window.
Fixes: 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-pci/20260729051542.DC2741F000E9@smtp.kernel.org/
Link: https://patch.msgid.link/20260730133123.1420413-6-cassel@kernel.org
|
|
The MSI-X path already flushes any posted MSI-X write before tearing down
its iATU mapping. That was added by commit c22533c66cca ("PCI: dwc: ep:
Flush MSI-X write before unmapping its ATU entry") to make sure the write
reaches the Root Complex before the outbound window that translates it
disappears.
The MSI path has the same problem but no equivalent flush. When the
Endpoint driver caches an MSI target address and later observes that the
Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing
iATU entry and reprograms it for the new address. Between the last MSI
writel() and the unmap there may still be a posted write sitting in the
fabric, and unmapping the iATU entry can drop or misroute that write.
Fix this by reading back from the mapped MSI window before the unmap. The
readback drains any posted MSI writes through the same iATU entry that
mapped them, which is the same logic the MSI-X path uses.
Fixes: 468711a40d5d ("PCI: dwc: ep: Refresh MSI Message Address cache on change")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-pci/20260729214859.B9E2B1F00A3A@smtp.kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730133123.1420413-5-cassel@kernel.org
|
|
Ping-Ke Shih says:
==================
rtw-next patches for v7.3
Some random cleanups and fixes on rtlwifi, rtw88 and rtw89. The major
features added to rtw89 are listed:
rtw89:
- add LED support
- update BT-coexistence mechanism to support dual Bluetooth for RTL8922D
- support WiFi 7 chip RTL8922DE
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, several files in the PCI tree print error pointers using
the %ld format specifier together with an explicit PTR_ERR()
conversion, which prints the numeric errno value.
Thus, at every affected call site, use the %pe format specifier, which
exists specifically to print error pointers, and pass the error pointer
directly. With CONFIG_SYMBOLIC_ERRNAME enabled, this prints a symbolic
error name such as -ENOMEM, falling back to the numeric errno value
otherwise. As such, the explicit PTR_ERR() conversion is no longer
needed.
No functional changes intended.
Link: https://patch.msgid.link/20260720210839.1507406-1-kwilczynski@kernel.org
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
|
The PCIe link, when down, needs to be recovered to bring it back. But on
some platforms, that cannot be done in a generic way as link recovery
procedure is platform specific. Add a new pci_host_handle_link_down() that
could be called by the host bridge drivers for a specific Root Port when
the link goes down.
pci_host_handle_link_down() accepts a 'pci_dev' corresponding to the Root
Port that observed the link down event. If CONFIG_PCIEAER is enabled, it
calls pcie_do_recovery() with 'pci_channel_io_frozen' as the state. This
will result in the execution of the AER Fatal error handling code. Since
the link down recovery is pretty much the same as AER Fatal error handling,
reuse pcie_do_recovery() here.
The AER .error_detected() callback will be triggered for all of the
downstream devices, but not for the Root Port itself as there is nothing to
do for the Root Ports in the callbacks. Finally, pci_host_reset_root_port()
will be called for the Root Port, which will reset the Root Port using the
.reset_root_port() callback to recover the link. Once that's done, resume
message will be broadcasted to the bridge and the downstream devices,
indicating successful link recovery.
But if CONFIG_PCIEAER is not enabled in the kernel, only
pci_host_reset_root_port() will be called, which will in turn call
pci_bus_error_reset() to just reset the Root Port as there is no way we
could inform the drivers about link recovery.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-3-53570b92064d@oss.qualcomm.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull pci fixes from Bjorn Helgaas:
- Remove Karthikeyan Mitran from Mobiveil MAINTAINERS PCIe entry since
email bounces (Manivannan Sadhasivam)
- Preserve i.MX6Q, i.MX6QP, and i.MX6SX Root Port MSI/MSI-X
Capabilities when using iMSI-RX to work around hardware defect
(Soeren Moch)
- Reorder i.MX6Q/DL PHY power up to fix boot hang regression (Richard
Zhu)
* tag 'pci-v7.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencing
PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX to work around hardware bug
MAINTAINERS: Drop Karthikeyan Mitran from Mobiveil PCIe entry
|
|
Some host bridge devices require resetting the Root Ports in a platform
specific way to recover them from error conditions such as Fatal AER
errors, Link Down, etc. Introduce pci_host_bridge::reset_root_port()
callback and call it from pcibios_reset_secondary_bus() if available. Also,
save the Root Port config space before reset and restore it afterwards.
The .reset_root_port() callback is responsible for resetting the given Root
Port referenced by the 'pci_dev' pointer in a platform-specific way and
bring it back to the working state if possible. If any error occurs during
the reset operation, relevant errno should be returned.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-2-53570b92064d@oss.qualcomm.com
|
|
Qcom PCIe Root Ports advertise the Attention Button Present (ABP) bit in
the Slot Capabilities register, but the slots have no attention button.
When ABP is set, pcie_enable_notification() in the pciehp driver enables
the Attention Button Pressed interrupt (ABPE) and leaves the Presence
Detect Changed interrupt (PDCE) disabled. As a result, presence detect
changes are never reported, and surprise hot-plug detection that relies on
Presence Detect Changed events does not work.
Clear the Attention Button Present (ABP) bit in the Slot Capabilities
register so pciehp Presence Detect Changed events work.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: say what the patch does in the commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713-b4-clear_abp_0713-v2-2-4f0333a98d4e@oss.qualcomm.com
|
|
The MSI iATU mapping is currently only cleared when the endpoint is
stopped via configfs or when the host updates the MSI address/size.
This avoids redundant iATU reconfiguration every time the endpoint
raises an MSI interrupt.
However, a fundamental reset triggered by PERST# assert/deassert
resets all iATU inbound/outbound registers without going through the
configfs stop path. If the host also retains the same MSI address/size
after PERST# deassert, the driver never clears the stale MSI iATU
mapping. It then continues using this stale mapping to raise the MSI
interrupts, which can cause IOMMU faults and MSI failures on the host.
Fix this by clearing the MSI iATU mapping inside dw_pcie_ep_cleanup(),
which is already called as part of the PERST# assert/deassert sequence.
This unmaps the MSI iATU region and sets the msi_iatu_mapped flag to
false, ensuring that dw_pcie_ep_raise_msi_irq() performs a fresh iATU
mapping on its next invocation, regardless of whether the host changed
the MSI address/size.
Fixes: 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-1-53570b92064d@oss.qualcomm.com
|
|
The MHI core needs to make sure that all the current DMA transactions are
completed before removing the channels. So implement the
mhi_cntrl->flush_async() callback by first making sure all the in-flight
DMA operations are completed and then flushing the DMA workqueue.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
pm_runtime_get_sync() is called in starfive_pcie_probe() without
checking its return value. If runtime resume fails, the driver
proceeds to configure PCIe hardware through regmap_update_bits(),
enable clocks and resets, and power on the PHY, even though the
device may not actually be powered.
pm_runtime_get_sync() also increments the usage counter even when
resume fails, which would leave the counter unbalanced if this
error path were later handled without additional cleanup.
Switch to pm_runtime_resume_and_get(), which balances the usage
counter internally on failure, and bail out of probe before any
hardware is touched if resume does not succeed.
Tested on StarFive VisionFive 2 v1.2A board.
Fixes: 6168efbebace ("PCI: starfive: Enable controller runtime PM before probing host bridge")
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260718153352.661930-1-alitariq45892@gmail.com
|
|
The starfive_pcie_remove() path incorrectly disabled runtime PM
before executing plda_pcie_host_deinit(), which can cause unmanaged
hardware register access in plda_pcie_host_deinit() while power domains or
clocks are disabled.
Fix this by restructuring starfive_pcie_remove() to deinitialize the host
controller first while runtime PM is active, followed by a synchronous
pm_runtime_put_sync() and pm_runtime_disable().
This bug was found in automated AI review by sashiko-bot.
Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller")
Closes: https://lore.kernel.org/linux-pci/20260712180440.423421F000E9@smtp.kernel.org/
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260718133825.445041-1-alitariq45892@gmail.com
|
|
plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but
does not unwind them when later step fails.
If platform_get_irq() or either irq_create_mapping() fails
in plda_init_interrupts(), the domains are never deinitialized. If
irq_create_mapping() fails, port->intx_irq stays initialized.
Hence, remove the IRQ domains in the error path by calling
plda_pcie_irq_domain_deinit().
Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and
msi_irq mappings itself before removing their domains, the msi_irq
mapping failure path can go directly to err_irq_domain_deinit instead of
disposing of port->intx_irq separately first.
This issue was found by automated review of sashiko-bot
Fixes: 4602c370bdf6 ("PCI: microchip: Move IRQ functions to pcie-plda-host.c")
Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions")
Closes: https://lore.kernel.org/linux-pci/20260718120701.DF4111F000E9@smtp.kernel.org/
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260723142824.726655-1-alitariq45892@gmail.com
|
|
plda_pcie_irq_domain_deinit() removes pcie->event_domain via
irq_domain_remove(), but the per-event IRQs mapped from that domain
are requested with devm_request_irq() in plda_init_interrupts(). The
actual free_irq() for a devm-managed IRQ is deferred by devres until
after the calling probe()/remove() function returns.
This means irq_domain_remove() can free the domain's internal data
before the deferred free_irq() for IRQs still mapped into it has run.
When devres later processes that deferred cleanup, it can end up
dereferencing the already-freed domain.
Free each event IRQ explicitly with devm_free_irq() before removing
the domain. This triggers the free immediately and removes the IRQ
from the devres tracking list, so devres will not attempt to free it
a second time later.
Also dispose of the event, INTx, and MSI IRQ mappings with
irq_dispose_mapping() before their owning domains are removed.
Finally, guard the calls to irq_set_chained_handler_and_data() for
pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when
those fields hold a valid (>0) IRQ number.
This is a pre-existing issue, flagged by automated review during work
on an earlier, unrelated patch to this driver.
Build-tested and boot-tested on StarFive VisionFive v1.2A board
Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions")
Closes: https://lore.kernel.org/linux-pci/20260714115343.4D49E1F000E9@smtp.kernel.org/
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260723140434.675512-2-alitariq45892@gmail.com
|
|
Instead of defining the wait values for each driver, use common values
defined in the core pci.h header file. Note that while most drivers use
the usleep_range(), it looks like these were mostly cargo culted and
msleep() is a better choice given the fixed delay that the specification
calls for. Convert all drivers to msleep() and use the existing
definition.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260716-tegra264-pcie-v8-3-23e51589229b@nvidia.com
|
|
Only in a bare metal OS environment, the _OSC control flags like Hotplug,
PME, AER, etc. reflect the physical root bridge capabilities. But in a VM
environment, these flags reflect the hypervisor policy and in most cases,
the hypervisor disables all of these control flags to the guest.
So copying these flags would needlessly disable these features in the VMD
owned Root Ports. Hence, copy the flags only when VMD is running in a bare
metal OS environment.
Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
[mani: commit log and comment rewording]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260713220844.561357-1-nirmal.patel@intel.com
|
|
qcom_pcie_set_slot_nccs() currently only sets the NCCS field in the Slot
Capabilities register. A following patch adds programming of another
field in the same register, so rename the function to
qcom_pcie_set_slot_cap() to reflect that it configures Slot Capabilities
as a whole, not just NCCS.
No functional change intended.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713-b4-clear_abp_0713-v2-1-4f0333a98d4e@oss.qualcomm.com
|
|
commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
introduced a boot hang on i.MX6Q/DL variants by reordering
imx_pcie_host_init() to call imx6q_pcie_enable_ref_clk() (which powered up
the PHY) before imx6q_pcie_core_reset() (which powered it back down).
Before 610fa91d9863, the sequence was:
1. imx_pcie_assert_core_reset() - power down PHY (set TEST_PD), set
REF_CLK_EN
2. imx_pcie_clk_enable() - power up PHY (clear TEST_PD), set REF_CLK_EN
3. Link training starts with PHY powered up (TEST_PD cleared)
4. Link training succeeds
After 610fa91d9863, the sequence became:
1. imx_pcie_clk_enable() - power up PHY (clear TEST_PD), set REF_CLK_EN
2. imx_pcie_assert_core_reset() - power down PHY (set TEST_PD), set
REF_CLK_EN
3. imx_pcie_deassert_core_reset() - does nothing
4. Link training starts with PHY powered down (TEST_PD set)
5. Link training fails and boot hangs when PHY register accesses hang
To fix this:
- Remove TEST_PD PHY power control from imx6q_pcie_enable_ref_clk()
- Remove REF_CLK_EN control from imx6q_pcie_core_reset()
- Add TEST_PD PHY power control to imx6qp_pcie_core_reset(), which
previously relied on imx6q_pcie_enable_ref_clk() to power up the PHY by
clearing TEST_PD
- Clear TEST_PD to power on PHY in imx_pcie_deassert_core_reset()
These changes together ensure the correct sequence:
1. REF_CLK_EN set in clk_enable() (TEST_PD untouched)
2. TEST_PD set in assert_core_reset() (PHY power off)
3. TEST_PD cleared in deassert_core_reset() (PHY power on)
4. Link training starts with proper PHY state
The i.MX6Q/DL PCIe PHY requires approximately 120us between TEST_PD
de-assertion and link training start. Add usleep_range(200, 500) in
imx6q_pcie_core_reset() after clearing TEST_PD to satisfy this requirement.
Add explicit imx_pcie_assert_core_reset() calls in error paths and
host_exit() to ensure no power leak.
Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
Reported-by: Leonardo Costa <leoreis.costa@gmail.com>
Closes: https://lore.kernel.org/lkml/20260629143439.361560-1-leoreis.costa@gmail.com/
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Leonardo Costa <leonardo.costa@toradex.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260728035159.2702021-1-hongxing.zhu@oss.nxp.com
|
|
Dynamic IDs are only guaranteed to be valid when dynids.lock is held,
as remove_id_store() can free the node. Thus, make a copy in
pci_match_device(). Also, clarify that the id parameter is only valid
during probe.
Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/
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-9-3580726844e1@garyguo.net
|
|
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: 3853f9123c18 ("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
|
|
'tc9563_pwrctrl_ports' enum
'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
|
|
DSP3 doesn't support tuning Tx amplitude and DFE settings. Skip the setting
if DT has passed the tuning properties. There is no need to error out the
whole driver because of it.
Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: squash https://lore.kernel.org/all/oefxm7olagbd3dby2npgly7ausiz3g6cvls5igaxdzvlbr3wrv@rjlfebi2p36j]
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-4-ec4286e31331@oss.qualcomm.com
|
|
Backmerge to pull in commit 21fcb222f0d1 ("drm: Remove DRIVER_GEM_GPUVA
feature flag"), which a Tyr patch series depends on.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
tc9563_pwrctrl_disable_port()
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: 4c9c7be47310 ("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: 4c9c7be47310 ("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
|
|
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: 6c2b374d7485 ("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 0d465f23502e ("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 6c2b374d7485 ("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
|
|
Move the vendor and device ID for the existing Spacemit K1 PCIe Root
Complex to include/linux/pci_ids.h. Also add K3's Root Complex device ID
to this header. This is done so that these values can be referenced in
the rtw89 driver to enable 36-bit DMA ability in it for WiFi to function
on the K3 Pico ITX board.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260716-rtw89-spacemit-k3-v2-1-392b577ebf75@oss.tenstorrent.com
|
|
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 f5cd8a929c82 ("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 f5cd8a929c82, 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
|
|
pci_sriov_get_totalvfs() reports a VF count, not an errno-style
status. It returns 0 when SR-IOV is unavailable or the device is not a
PF, and otherwise returns the PF's driver_max_VFs value.
driver_max_VFs is stored as a u16 in struct pci_sriov. It is derived
from the SR-IOV TotalVFs field or from a driver-provided limit, so the
implementation cannot return a negative value.
Change the declaration, CONFIG_PCI_IOV stub, and implementation to
return unsigned int.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Gary Guo <gary@garyguo.net>
Cc: linux-pci@vger.kernel.org
Link: https://lore.kernel.org/all/DJHPRE4TGGT8.BUTMYOF5YE05@nvidia.com/
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Link: https://patch.msgid.link/20260722073913.1807677-2-zhiw@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
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
|
|
These callbacks are sysfs show paths.
Use sysfs_emit() and cpumask_pr_args() to emit the masks.
This prepares for removing cpumap_print_to_pagebuf().
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
