#
17423360 |
| 23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume
4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") restored the L1 PM Substates Capability after resume, which
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume
4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") restored the L1 PM Substates Capability after resume, which reduced power consumption by making the ASPM L1.x states work after resume.
a7152be79b62 ("Revert "PCI/ASPM: Save L1 PM Substates Capability for suspend/resume"") reverted 4ff116d0d5fd because resume failed on some systems, so power consumption after resume increased again.
a7152be79b62 mentioned that we restore L1 PM substate configuration even though ASPM L1 may already be enabled. This is due the fact that the pci_restore_aspm_l1ss_state() was called before pci_restore_pcie_state().
Save and restore the L1 PM Substates Capability, following PCIe r6.1, sec 5.5.4 more closely by:
1) Do not restore ASPM configuration in pci_restore_pcie_state() but do that after PCIe capability is restored in pci_restore_aspm_state() following PCIe r6.1, sec 5.5.4.
2) If BIOS reenables L1SS, particularly L1.2, we need to clear the enables in the right order, downstream before upstream. Defer restoring the L1SS config until we are at the downstream component. Then update the config for both ends of the link in the prescribed order.
3) Program ASPM L1 PM substate configuration before L1 enables.
4) Program ASPM L1 PM substate enables last, after rest of the fields in the capability are programmed.
[bhelgaas: commit log, squash L1SS-related patches, do both LNKCTL restores in pci_restore_pcie_state()]
Link: https://lore.kernel.org/r/20240128233212.1139663-3-david.e.box@linux.intel.com Link: https://lore.kernel.org/r/20240128233212.1139663-4-david.e.box@linux.intel.com Link: https://lore.kernel.org/r/20240223205851.114931-5-helgaas@kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217321 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216782 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877 Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Co-developed-by: David E. Box <david.e.box@linux.intel.com> Reported-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Tasev Nikola <tasev.stefanoska@skynet.be> # Asus UX305FA Cc: Mark Enriquez <enriquezmark36@gmail.com> Cc: Thomas Witt <kernel@witt.link> Cc: Werner Sembach <wse@tuxedocomputers.com> Cc: Vidya Sagar <vidyas@nvidia.com>
show more ...
|
#
fa84f443 |
| 23-Feb-2024 |
David E. Box <david.e.box@linux.intel.com> |
PCI/ASPM: Move pci_configure_ltr() to aspm.c
The Latency Tolerance Reporting (LTR) mechanism supports the ASPM L1.2 state and is only configured when CONFIG_PCIEASPM is set.
Move pci_configure_ltr(
PCI/ASPM: Move pci_configure_ltr() to aspm.c
The Latency Tolerance Reporting (LTR) mechanism supports the ASPM L1.2 state and is only configured when CONFIG_PCIEASPM is set.
Move pci_configure_ltr() and pci_bridge_reconfigure_ltr() into aspm.c since they only build when CONFIG_PCIEASPM is set. No functional change intended.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240128233212.1139663-2-david.e.box@linux.intel.com [bhelgaas: commit log, split build change from function moves] Link: https://lore.kernel.org/r/20240223205851.114931-2-helgaas@kernel.org Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
be9c3a4c |
| 30-Oct-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y
It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actuall
PCI/sysfs: Compile pci-sysfs.c only if CONFIG_SYSFS=y
It is possible to enable CONFIG_PCI but disable CONFIG_SYSFS and for space-constrained devices such as routers, such a configuration may actually make sense.
However pci-sysfs.c is compiled even if CONFIG_SYSFS is disabled, unnecessarily increasing the kernel's size.
To rectify that:
* Move pci_mmap_fits() to mmap.c. It is not only needed by pci-sysfs.c, but also proc.c.
* Move pci_dev_type to probe.c and make it private. It references pci_dev_attr_groups in pci-sysfs.c. Make that public instead for consistency with pci_dev_groups, pcibus_groups and pci_bus_groups, which are likewise public and referenced by struct definitions in pci-driver.c and probe.c.
* Define pci_dev_groups, pci_dev_attr_groups, pcibus_groups and pci_bus_groups to NULL if CONFIG_SYSFS is disabled. Provide empty static inlines for pci_{create,remove}_legacy_files() and pci_{create,remove}_sysfs_dev_files().
Result:
vmlinux size is reduced by 122996 bytes in my arm 32-bit test build.
Link: https://lore.kernel.org/r/85ca95ae8e4d57ccf082c5c069b8b21eb141846e.1698668982.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
95140c2f |
| 22-Nov-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Log bridge info when first enumerating bridge
Log bridge secondary/subordinate bus and window information at the same time we log the bridge BARs, just after discovering the bridge and before s
PCI: Log bridge info when first enumerating bridge
Log bridge secondary/subordinate bus and window information at the same time we log the bridge BARs, just after discovering the bridge and before scanning the bridge's secondary bus. This logs the bridge and downstream devices in a more logical order:
- pci 0000:00:01.0: [8086:1901] type 01 class 0x060400 - pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200 - pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff] - pci 0000:00:01.0: PCI bridge to [bus 01] - pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
+ pci 0000:00:01.0: [8086:1901] type 01 class 0x060400 + pci 0000:00:01.0: PCI bridge to [bus 01] + pci 0000:00:01.0: bridge window [io 0xe000-0xefff] + pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200 + pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff]
Note that we read the windows into a temporary struct resource that is thrown away, not into the resources in the struct pci_bus.
The windows may be adjusted after we know what downstream devices require, and those adjustments are logged as they are made.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
63c6ebb2 |
| 04-Dec-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Log bridge windows conditionally
Previously pci_read_bridge_io(), pci_read_bridge_mmio(), and pci_read_bridge_mmio_pref() unconditionally logged the bridge window resource. A future change wil
PCI: Log bridge windows conditionally
Previously pci_read_bridge_io(), pci_read_bridge_mmio(), and pci_read_bridge_mmio_pref() unconditionally logged the bridge window resource. A future change will call these functions earlier and more often. Add a "log" parameter so callers can control whether to generate the log message. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
281e1f13 |
| 22-Nov-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Supply bridge device, not secondary bus, to read window details
Previously we logged information about devices *below* the bridge before logging information about the bridge itself, e.g.,
pc
PCI: Supply bridge device, not secondary bus, to read window details
Previously we logged information about devices *below* the bridge before logging information about the bridge itself, e.g.,
pci 0000:00:01.0: [8086:1901] type 01 class 0x060400 pci 0000:01:00.0: [10de:13b6] type 00 class 0x030200 pci 0000:01:00.0: reg 0x10: [mem 0xec000000-0xecffffff] pci 0000:00:01.0: PCI bridge to [bus 01] pci 0000:00:01.0: bridge window [io 0xe000-0xefff]
This is partly because the bridge windows are read in this path:
pci_scan_child_bus_extend for (devfn = 0; devfn < 256; devfn += 8) pci_scan_slot(bus, devfn) # scan below bridge pcibios_fixup_bus(bus) pci_read_bridge_bases(bus) # read bridge windows pci_read_bridge_io(bus)
Remove the assumption that the secondary (child) pci_bus already exists by passing in the bridge device (instead of the pci_bus) and a resource pointer when reading bridge windows. A future change can use this to log the bridge details before we enumerate the devices below the bridge.
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
6f32099a |
| 04-Dec-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Move pci_read_bridge_windows() below individual window accessors
Move pci_read_bridge_windows() below the functions that read the I/O, memory, and prefetchable memory windows, so pci_read_bridg
PCI: Move pci_read_bridge_windows() below individual window accessors
Move pci_read_bridge_windows() below the functions that read the I/O, memory, and prefetchable memory windows, so pci_read_bridge_windows() can use them in the future. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
dc4e6f21 |
| 06-Nov-2021 |
Puranjay Mohan <puranjay12@gmail.com> |
PCI: Use resource names in PCI log messages
Use the pci_resource_name() to get the name of the resource and use it while printing log messages.
[bhelgaas: rename to match struct resource * names, a
PCI: Use resource names in PCI log messages
Use the pci_resource_name() to get the name of the resource and use it while printing log messages.
[bhelgaas: rename to match struct resource * names, also use names in other BAR messages] Link: https://lore.kernel.org/r/20211106112606.192563-3-puranjay12@gmail.com Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
35259ff1 |
| 10-Nov-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Log device type during enumeration
Log the device type when enumeration a device. Sample output changes:
- pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 + pci 0000:00:00.0: [8086:1
PCI: Log device type during enumeration
Log the device type when enumeration a device. Sample output changes:
- pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 + pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 conventional PCI endpoint
- pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400 + pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400 PCIe Root Port
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
e0f0a16f |
| 10-Oct-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use FIELD_GET()
Use FIELD_GET() and FIELD_PREP() to remove dependences on the field position, i.e., the shift value. No functional change intended.
Link: https://lore.kernel.org/r/20231010204
PCI: Use FIELD_GET()
Use FIELD_GET() and FIELD_PREP() to remove dependences on the field position, i.e., the shift value. No functional change intended.
Link: https://lore.kernel.org/r/20231010204436.1000644-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
show more ...
|
#
d15f1805 |
| 11-Sep-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Do error check on own line to split long "if" conditions
Placing PCI error code check inside "if" condition usually results in need to split lines. Combined with additional conditions the "if"
PCI: Do error check on own line to split long "if" conditions
Placing PCI error code check inside "if" condition usually results in need to split lines. Combined with additional conditions the "if" condition becomes messy.
Convert to the usual error handling pattern with an additional variable to improve code readability. In addition, reverse the logic in pci_find_vsec_capability() to get rid of &&.
No functional changes intended.
Link: https://lore.kernel.org/r/20230911125354.25501-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: PCI_POSSIBLE_ERROR()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
8ec9c1d5 |
| 06-Sep-2023 |
Ross Lagerwall <ross.lagerwall@citrix.com> |
PCI: Free released resource after coalescing
release_resource() doesn't actually free the resource or resource list entry so free the resource list entry to avoid a leak.
Closes: https://lore.kerne
PCI: Free released resource after coalescing
release_resource() doesn't actually free the resource or resource list entry so free the resource list entry to avoid a leak.
Closes: https://lore.kernel.org/r/878r9sga1t.fsf@kernel.org/ Fixes: e54223275ba1 ("PCI: Release resource invalidated by coalescing") Link: https://lore.kernel.org/r/20230906110846.225369-1-ross.lagerwall@citrix.com Reported-by: Kalle Valo <kvalo@kernel.org> Tested-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.16+
show more ...
|
#
86b4ad7d |
| 24-Aug-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix typos in docs and comments
Fix typos in docs and comments.
Link: https://lore.kernel.org/r/20230824193712.542167-11-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Re
PCI: Fix typos in docs and comments
Fix typos in docs and comments.
Link: https://lore.kernel.org/r/20230824193712.542167-11-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
#
5e70d0ac |
| 17-Jul-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Add locking to RMW PCI Express Capability Register accessors
Many places in the kernel write the Link Control and Root Control PCI Express Capability Registers without proper concurrency contro
PCI: Add locking to RMW PCI Express Capability Register accessors
Many places in the kernel write the Link Control and Root Control PCI Express Capability Registers without proper concurrency control and this could result in losing the changes one of the writers intended to make.
Add pcie_cap_lock spinlock into the struct pci_dev and use it to protect bit changes made in the RMW capability accessors. Protect only a selected set of registers by differentiating the RMW accessor internally to locked/unlocked variants using a wrapper which has the same signature as pcie_capability_clear_and_set_word(). As the Capability Register (pos) given to the wrapper is always a constant, the compiler should be able to simplify all the dead-code away.
So far only the Link Control Register (ASPM, hotplug, link retraining, various drivers) and the Root Control Register (AER & PME) seem to require RMW locking.
Suggested-by: Lukas Wunner <lukas@wunner.de> Fixes: c7f486567c1d ("PCI PM: PCIe PME root port service driver") Fixes: f12eb72a268b ("PCI/ASPM: Use PCI Express Capability accessors") Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") Fixes: affa48de8417 ("staging/rdma/hfi1: Add support for enabling/disabling PCIe ASPM") Fixes: 849a9366cba9 ("misc: rtsx: Add support new chip rts5228 mmc: rtsx: Add support MMC_CAP2_NO_MMC") Fixes: 3d1e7aa80d1c ("misc: rtsx: Use pcie_capability_clear_and_set_word() for PCI_EXP_LNKCTL") Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261") Fixes: 3df4fce739e2 ("misc: rtsx: separate aspm mode into MODE_REG and MODE_CFG") Fixes: 121e9c6b5c4c ("misc: rtsx: modify and fix init_hw function") Fixes: 19f3bd548f27 ("mfd: rtsx: Remove LCTLR defination") Fixes: 773ccdfd9cc6 ("mfd: rtsx: Read vendor setting from config space") Fixes: 8275b77a1513 ("mfd: rts5249: Add support for RTS5250S power saving") Fixes: 5da4e04ae480 ("misc: rtsx: Add support for RTS5260") Fixes: 0f49bfbd0f2e ("tg3: Use PCI Express Capability accessors") Fixes: 5e7dfd0fb94a ("tg3: Prevent corruption at 10 / 100Mbps w CLKREQ") Fixes: b726e493e8dc ("r8169: sync existing 8168 device hardware start sequences with vendor driver") Fixes: e6de30d63eb1 ("r8169: more 8168dp support.") Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards") Fixes: 6f461f6c7c96 ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata") Fixes: 1eae4eb2a1c7 ("e1000e: Disable L1 ASPM power savings for 82573 mobile variants") Fixes: 8060e169e02f ("ath9k: Enable extended synch for AR9485 to fix L0s recovery issue") Fixes: 69ce674bfa69 ("ath9k: do btcoex ASPM disabling at initialization time") Fixes: f37f05503575 ("mt76: mt76x2e: disable pcie_aspm by default") Link: https://lore.kernel.org/r/20230717120503.15276-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: "Rafael J. Wysocki" <rafael@kernel.org>
show more ...
|
#
c925cfaf |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
PCI: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that me
PCI: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Link: https://lore.kernel.org/r/20230714174827.4061572-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
a89c8224 |
| 11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Work around PCIe link training failures
Attempt to handle cases such as with a downstream port of the ASMedia ASM2824 PCIe switch where link training never completes and the link continues swit
PCI: Work around PCIe link training failures
Attempt to handle cases such as with a downstream port of the ASMedia ASM2824 PCIe switch where link training never completes and the link continues switching between speeds indefinitely with the data link layer never reaching the active state.
It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the switches should negotiate a link speed of 5.0GT/s, falling back to 2.5GT/s if necessary.
Instead the link continues oscillating between the two speeds, at the rate of 34-35 times per second, with link training reported repeatedly active ~84% of the time. Limiting the target link speed to 2.5GT/s with the upstream ASM2824 device makes the two switches communicate correctly. Removing the speed restriction afterwards makes the two devices switch to 5.0GT/s then.
Make use of these observations and detect the inability to train the link by checking for the Data Link Layer Link Active status bit being off while the Link Bandwidth Management Status indicating that hardware has changed the link speed or width in an attempt to correct unreliable link operation.
Restrict the speed to 2.5GT/s then with the Target Link Speed field, request a retrain and wait 200ms for the data link to go up. If this is successful, lift the restriction, letting the devices negotiate a higher speed.
Also check for a 2.5GT/s speed restriction the firmware may have already arranged and lift it too with ports of devices known to continue working afterwards (currently only ASM2824), that already report their data link being up.
[bhelgaas: reorder and squash stubs from https://lore.kernel.org/r/alpine.DEB.2.21.2306111619570.64925@angie.orcam.me.uk to avoid adding stubs that do nothing] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203022037020.56670@angie.orcam.me.uk/ Link: https://source.denx.de/u-boot/u-boot/-/commit/a398a51ccc68 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310038540.59226@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
42adbdc7 |
| 11-Jun-2023 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Initialize dev->link_active_reporting earlier
Determine whether Data Link Layer Link Active Reporting is available before calling any fixups so that the cached value can be used there and later
PCI: Initialize dev->link_active_reporting earlier
Determine whether Data Link Layer Link Active Reporting is available before calling any fixups so that the cached value can be used there and later on.
[bhelgaas: move to set_pcie_port_type() where other PCIe init is done] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310122210.59226@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
e5422327 |
| 25-May-2023 |
Ross Lagerwall <ross.lagerwall@citrix.com> |
PCI: Release resource invalidated by coalescing
When contiguous windows are coalesced by pci_register_host_bridge(), the second resource is expanded to include the first, and the first is invalidate
PCI: Release resource invalidated by coalescing
When contiguous windows are coalesced by pci_register_host_bridge(), the second resource is expanded to include the first, and the first is invalidated and consequently not added to the bus. However, it remains in the resource hierarchy. For example, these windows:
fec00000-fec7ffff : PCI Bus 0000:00 fec80000-fecbffff : PCI Bus 0000:00
are coalesced into this, where the first resource remains in the tree with start/end zeroed out:
00000000-00000000 : PCI Bus 0000:00 fec00000-fecbffff : PCI Bus 0000:00
In some cases (e.g. the Xen scratch region), this causes future calls to allocate_resource() to choose an inappropriate location which the caller cannot handle.
Fix by releasing the zeroed-out resource and removing it from the resource hierarchy.
[bhelgaas: commit log] Fixes: 7c3855c423b1 ("PCI: Coalesce host bridge contiguous apertures") Link: https://lore.kernel.org/r/20230525153248.712779-1-ross.lagerwall@citrix.com Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v5.16+
show more ...
|
#
0d21e71a |
| 19-Apr-2023 |
Rob Herring <robh@kernel.org> |
PCI: Restrict device disabled status check to DT
Commit 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") checked the firmware device status for both DT and ACPI devices. That caused a r
PCI: Restrict device disabled status check to DT
Commit 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") checked the firmware device status for both DT and ACPI devices. That caused a regression in some ACPI systems. The exact reason isn't clear. It's possibly a firmware bug. For now, at least, refactor the check to be for DT based systems only.
Note that the original implementation leaked a refcount which is now correctly handled.
[bhelgaas: Per ACPI r6.5, sec 6.3.7, for devices on an enumerable bus, _STA must return with bit[0] ("device is present") set]
Link: https://lore.kernel.org/all/m2fs9lgndw.fsf@gmail.com/ Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/r/20230419193513.708818-1-robh@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217317 Reported-by: Donald Hunter <donald.hunter@gmail.com> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Donald Hunter <donald.hunter@gmail.com> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Binbin Zhou <zhoubinbin@loongson.cn> Cc: Liu Peibao <liupeibao@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn>
show more ...
|
#
ac048403 |
| 11-Mar-2023 |
Lukas Wunner <lukas@wunner.de> |
PCI/DOE: Create mailboxes on device enumeration
Currently a DOE instance cannot be shared by multiple drivers because each driver creates its own pci_doe_mb struct for a given DOE instance. For the
PCI/DOE: Create mailboxes on device enumeration
Currently a DOE instance cannot be shared by multiple drivers because each driver creates its own pci_doe_mb struct for a given DOE instance. For the same reason a DOE instance cannot be shared between the PCI core and a driver.
Moreover, finding out which protocols a DOE instance supports requires creating a pci_doe_mb for it. If a device has multiple DOE instances, a driver looking for a specific protocol may need to create a pci_doe_mb for each of the device's DOE instances and then destroy those which do not support the desired protocol. That's obviously an inefficient way to do things.
Overcome these issues by creating mailboxes in the PCI core on device enumeration.
Provide a pci_find_doe_mailbox() API call to allow drivers to get a pci_doe_mb for a given (pci_dev, vendor, protocol) triple. This API is modeled after pci_find_capability() and can later be amended with a pci_find_next_doe_mailbox() call to iterate over all mailboxes of a given pci_dev which support a specific protocol.
On removal, destroy the mailboxes in pci_destroy_dev(), after the driver is unbound. This allows drivers to use DOE in their ->remove() hook.
On surprise removal, cancel ongoing DOE exchanges and prevent new ones from being scheduled. Thereby ensure that a hot-removed device doesn't needlessly wait for a running exchange to time out.
Tested-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ming Li <ming4.li@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/40a6f973f72ef283d79dd55e7e6fddc7481199af.1678543498.git.lukas@wunner.de Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
02992064 |
| 04-Apr-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PCI: Make pci_bus_for_each_resource() index optional
Refactor pci_bus_for_each_resource() in the same way as pci_dev_for_each_resource(). This allows the index to be hidden inside the implementation
PCI: Make pci_bus_for_each_resource() index optional
Refactor pci_bus_for_each_resource() in the same way as pci_dev_for_each_resource(). This allows the index to be hidden inside the implementation so the caller can omit it when it's not used otherwise.
No functional changes intended.
Link: https://lore.kernel.org/r/20230330162434.35055-6-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
#
9d8ba74a |
| 10-Feb-2023 |
Geert Uytterhoeven <geert+renesas@glider.be> |
PCI: Fix dropping valid root bus resources with .end = zero
On r8a7791/koelsch:
kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak unrefe
PCI: Fix dropping valid root bus resources with .end = zero
On r8a7791/koelsch:
kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak unreferenced object 0xc3a34e00 (size 64): comm "swapper/0", pid 1, jiffies 4294937460 (age 199.080s) hex dump (first 32 bytes): b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00 .]...].......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<fe3aa979>] __kmalloc+0xf0/0x140 [<34bd6bc0>] resource_list_create_entry+0x18/0x38 [<767046bc>] pci_add_resource_offset+0x20/0x68 [<b3f3edf2>] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390
When coalescing two resources for a contiguous aperture, the second resource is enlarged to cover the full contiguous range, while the first resource is marked invalid. This invalidation is done by clearing the flags, start, and end members.
When adding the initial resources to the bus later, invalid resources are skipped. Unfortunately, the check for an invalid resource considers only the end member, causing false positives.
E.g. on r8a7791/koelsch, root bus resource 0 ("bus 00") is skipped, and no longer registered with pci_bus_insert_busn_res() (causing the memory leak), nor printed:
pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges: pci-rcar-gen2 ee090000.pci: MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000 pci-rcar-gen2 ee090000.pci: PCI: revision 11 pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00 -pci_bus 0000:00: root bus resource [bus 00] pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]
Fix this by only skipping resources where all of the flags, start, and end members are zero.
Fixes: 7c3855c423b17f6c ("PCI: Coalesce host bridge contiguous apertures") Link: https://lore.kernel.org/r/da0fcd5e86c74239be79c7cb03651c0fce31b515.1676036673.git.geert+renesas@glider.be Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
show more ...
|
#
6fffbc7a |
| 10-Feb-2023 |
Rob Herring <robh@kernel.org> |
PCI: Honor firmware's device disabled status
If a device has a firmware node (DT/ACPI), and the device is marked disabled, that is currently ignored. Add a check for this condition and bail out crea
PCI: Honor firmware's device disabled status
If a device has a firmware node (DT/ACPI), and the device is marked disabled, that is currently ignored. Add a check for this condition and bail out creating the pci_dev.
This assumes the config space for the device can still be accessed because they already have by this point in order to identify the device.
Link: https://lore.kernel.org/r/20230210164351.2687475-1-robh@kernel.org Tested-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Liu Peibao <liupeibao@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn>
show more ...
|
#
589c3357 |
| 12-Dec-2022 |
Ira Weiny <ira.weiny@intel.com> |
PCI/CXL: Export native CXL error reporting control
CXL _OSC Error Reporting Control is used by the OS to determine if Firmware has control of various CXL error reporting capabilities including the e
PCI/CXL: Export native CXL error reporting control
CXL _OSC Error Reporting Control is used by the OS to determine if Firmware has control of various CXL error reporting capabilities including the event logs.
Expose the result of negotiating CXL Error Reporting Control in struct pci_host_bridge for consumption by the CXL drivers.
Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: linux-pci@vger.kernel.org Cc: linux-acpi@vger.kernel.org Signed-off-by: Ira Weiny <ira.weiny@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/r/20221212070627.1372402-2-ira.weiny@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
#
a474d3fb |
| 11-Nov-2022 |
Thomas Gleixner <tglx@linutronix.de> |
PCI/MSI: Get rid of PCI_MSI_IRQ_DOMAIN
What a zoo:
PCI_MSI select GENERIC_MSI_IRQ
PCI_MSI_IRQ_DOMAIN def_bool y depends on PCI_MSI select GENERIC_MSI_IRQ_DOMAIN
Ergo PCI_MSI en
PCI/MSI: Get rid of PCI_MSI_IRQ_DOMAIN
What a zoo:
PCI_MSI select GENERIC_MSI_IRQ
PCI_MSI_IRQ_DOMAIN def_bool y depends on PCI_MSI select GENERIC_MSI_IRQ_DOMAIN
Ergo PCI_MSI enables PCI_MSI_IRQ_DOMAIN which in turn selects GENERIC_MSI_IRQ_DOMAIN. So all the dependencies on PCI_MSI_IRQ_DOMAIN are just an indirection to PCI_MSI.
Match the reality and just admit that PCI_MSI requires GENERIC_MSI_IRQ_DOMAIN.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20221111122014.467556921@linutronix.de
show more ...
|