Bjorn Helgaas [Mon, 25 Nov 2024 19:40:56 +0000 (13:40 -0600)]
Merge branch 'pci/endpoint'
- Add pci_epc_function_is_valid() to avoid repeating common validation
checks (Damien Le Moal)
- Skip attempts to allocate from endpoint controller memory window if the
requested size is larger than the window (Damien Le Moal)
- Add and document pci_epc_mem_map() and pci_epc_mem_unmap() to handle
controller-specific size and alignment constraints, and add test cases to
the endpoint test driver (Damien Le Moal)
- Implement dwc pci_epc_ops.align_addr() so pci_epc_mem_map() can observe
DWC-specific alignment requirements (Damien Le Moal)
- Synchronously cancel command handler work in endpoint test before
cleaning up DMA and BARs (Damien Le Moal)
- Respect endpoint page size in dw_pcie_ep_align_addr() (Niklas Cassel)
- Use dw_pcie_ep_align_addr() in dw_pcie_ep_raise_msi_irq() and
dw_pcie_ep_raise_msix_irq() instead of open coding the equivalent (Niklas
Cassel)
- Remove superfluous 'return' from pci_epf_test_clean_dma_chan() (Wang
Jiang)
- Avoid NULL dereference if Modem Host Interface Endpoint lacks 'mmio' DT
property (Zhongqiu Han)
- Release PCI domain ID of Endpoint controller parent (not controller
itself) and before unregistering the controller, to avoid use-after-free
(Zijun Hu)
- Clear secondary (not primary) EPC in pci_epc_remove_epf() when removing
the secondary controller associated with an NTB (Zijun Hu)
- Fix pci_epc_map map_size kerneldoc (Rick Wertenbroek)
* pci/endpoint:
PCI: endpoint: Fix pci_epc_map map_size kerneldoc string
PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf()
PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy()
PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
PCI: endpoint: Remove surplus return statement from pci_epf_test_clean_dma_chan()
PCI: dwc: ep: Use align addr function for dw_pcie_ep_raise_{msi,msix}_irq()
PCI: endpoint: test: Synchronously cancel command handler work
PCI: dwc: endpoint: Implement the pci_epc_ops::align_addr() operation
PCI: endpoint: test: Use pci_epc_mem_map/unmap()
PCI: endpoint: Update documentation
PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
PCI: endpoint: Improve pci_epc_mem_alloc_addr()
PCI: endpoint: Introduce pci_epc_function_is_valid()
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:56 +0000 (13:40 -0600)]
Merge branch 'pci/dt-bindings'
- Update mediatek-gen3 DT binding to require the exact number of clocks for
each SoC (Fei Shao)
- Add qcom SAR2130P DT binding with an additional clock (Dmitry Baryshkov)
* pci/dt-bindings:
dt-bindings: PCI: snps,dw-pcie: Drop "#interrupt-cells" from example
dt-bindings: PCI: qcom,pcie-sm8550: Add SAR2130P compatible
dt-bindings: PCI: mediatek-gen3: Allow exact number of clocks only
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:56 +0000 (13:40 -0600)]
Merge branch 'pci/virtualization'
- Add ACS quirk for Wangxun FF5xxx NICs, which don't advertise and ACS
capability but do isolate functions as though PCI_ACS_RR and PCI_ACS_CR
were set, so the functions can be in independent IOMMU groups (Mengyuan
Lou)
* pci/virtualization:
PCI: Add ACS quirk for Wangxun FF5xxx NICs
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:55 +0000 (13:40 -0600)]
Merge branch 'pci/tph'
- Add and document TLP Processing Hints (TPH) support so drivers can enable
and disable TPH and the kernel can save/restore TPH configuration (Wei
Huang)
- Add TPH Steering Tag support so drivers can retrieve Steering Tag values
associated with specific CPUs via an ACPI _DSM to direct DMA writes
closer to their consumers (Wei Huang)
* pci/tph:
PCI/TPH: Add TPH documentation
PCI/TPH: Add Steering Tag support
PCI: Add TLP Processing Hints (TPH) support
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:55 +0000 (13:40 -0600)]
Merge branch 'pci/thunderbolt'
- Detect some Thunderbolt chips that are built-in and hence 'trustworthy'
by a heuristic since the 'ExternalFacingPort' and 'usb4-host-interface'
ACPI properties are not quite enough (Esther Shimanovich)
* pci/thunderbolt:
PCI: Detect and trust built-in Thunderbolt chips
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:55 +0000 (13:40 -0600)]
Merge branch 'pci/resource'
- Add resource_set_size() to set resource size when start has already been
set (Ilpo Järvinen)
- Add resource_set_range() helper to set both resource start and size (Ilpo
Järvinen)
- Use IS_ALIGNED() and resource_size() in quirk_s3_64M() instead of
open-coding them (Ilpo Järvinen)
- Add ALIGN_DOWN_IF_NONZERO() to avoid code duplication when distributing
resources across devices (Ilpo Järvinen)
- Improve pdev_sort_resources() warning message to be more specific (Ilpo
Järvinen)
* pci/resource:
PCI: Improve pdev_sort_resources() warning message
PCI: Add ALIGN_DOWN_IF_NONZERO() helper
PCI: Use align and resource helpers, and SZ_* in quirk_s3_64M()
PCI: Use resource_set_{range,size}() helpers
resource: Add resource set range and size helpers
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:54 +0000 (13:40 -0600)]
Merge branch 'pci/reset'
- Add sysfs 'reset_subordinate' to reset hierarchy below bridge (Keith
Busch)
- Warn if we reset a running device where driver didn't register
pci_error_handlers notification callbacks (Keith Busch)
* pci/reset:
PCI: Warn if a running device is unaware of reset
PCI: Add 'reset_subordinate' to reset hierarchy below bridge
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:54 +0000 (13:40 -0600)]
Merge branch 'pci/pwrctl'
- Use of_platform_device_create() instead of of_platform_populate() to
create pwrctl platform devices so we can control it based on the child
nodes (Manivannan Sadhasivam)
- Create pwrctrl platform devices only if there's a relevant power supply
property (Manivannan Sadhasivam)
- Add device link from the pwrctl supplier to the PCI dev to ensure pwrctl
drivers are probed before the PCI dev driver; this avoids a race where
pwrctl could change device power state while the PCI driver was active
(Manivannan Sadhasivam)
- Find pwrctl device for removal with of_find_device_by_node() instead of
searching all children of the parent (Manivannan Sadhasivam)
- Rename 'pwrctl' to 'pwrctrl' to use the same 'ctrl' suffix as 'bwctrl'
and other PCI files to reduce confusion (Bjorn Helgaas)
* pci/pwrctl:
PCI/pwrctrl: Rename pwrctrl functions and structures
PCI/pwrctrl: Rename pwrctl files to pwrctrl
PCI/pwrctl: Remove pwrctl device without iterating over all children of pwrctl parent
PCI/pwrctl: Ensure that pwrctl drivers are probed before PCI client drivers
PCI/pwrctl: Create pwrctl device only if at least one power supply is present
PCI/pwrctl: Use of_platform_device_create() to create pwrctl devices
# Conflicts:
# drivers/pci/bus.c
# drivers/pci/remove.c
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:46 +0000 (13:40 -0600)]
Merge branch 'pci/pm'
- Enable starfive controller runtime PM before probing host bridge (Mayank
Rana)
- Enable runtime power management for host bridges (Krishna chaitanya
chundru)
* pci/pm:
PCI: Enable runtime PM of the host bridge
PCI: starfive: Enable controller runtime PM before probing host bridge
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:46 +0000 (13:40 -0600)]
Merge branch 'pci/of'
- Use PCI bus addresses (not CPU addresses) in 'ranges' properties when
building dynamic DT nodes so systems where the PCI and CPU addresses
space differ work correctly (Andrea della Porta)
* pci/of:
PCI: of_property: Assign PCI instead of CPU bus address to dynamic PCI nodes
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:45 +0000 (13:40 -0600)]
Merge branch 'pci/locking'
- Make pci_stop_dev() and pci_destroy_dev() concurrent safe (Keith Busch)
- Move __pci_walk_bus() mutex up into the caller, which avoids the need for
a parameter to control locking (Keith Busch)
- Simplify __pci_walk_bus() by making it recursive (Keith Busch)
- Unexport pci_walk_bus_locked(), which is only used internally by the PCI
core (Keith Busch)
* pci/locking:
PCI: Unexport pci_walk_bus_locked()
PCI: Convert __pci_walk_bus() to be recursive
PCI: Move __pci_walk_bus() mutex to where we need it
PCI: Make pci_destroy_dev() concurrent safe
PCI: Make pci_stop_dev() concurrent safe
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:45 +0000 (13:40 -0600)]
Merge branch 'pci/hotplug-octeon'
- Add hotplug controller driver for Marvell OCTEON multi-function device
where function 0 has a management console interface to enable/disable and
provision various personalities for the other functions (Shijith Thotton)
* pci/hotplug-octeon:
PCI: hotplug: Add OCTEON PCI hotplug controller driver
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:44 +0000 (13:40 -0600)]
Merge branch 'pci/hotplug'
- Remove unused cpcihp struct cpci_hp_controller_ops.hardware_test
(Guilherme Giacomo Simoes)
- Remove unused cpqphp struct ctrl_dbg.ctrl (Christophe JAILLET)
- Clean up cpqphp PCIBIOS_* return value confusion (Ilpo Järvinen)
- Use pci_bus_read_dev_vendor_id() instead of hand-coded presence detection
in cpqphp (Ilpo Järvinen)
- Simplify cpqphp enumeration, which is already simple-minded and doesn't
handle devices below hot-added bridges (Ilpo Järvinen)
- Retain a reference to the pci_bus for the lifetime of a pci_slot to avoid
a use-after-free when the thunderbolt driver resets USB4 host routers on
boot, causing hotplug remove/add of downstream docks or other devices
(Lukas Wunner)
* pci/hotplug:
PCI: Fix use-after-free of slot->bus on hot remove
PCI: cpqphp: Simplify PCI_ScanBusForNonBridge()
PCI: cpqphp: Use define to read class/revision dword
PCI: cpqphp: Use pci_bus_read_dev_vendor_id() to detect presence
PCI: cpqphp: Fix PCIBIOS_* return value confusion
PCI: cpqphp: Remove unused struct ctrl_dbg.ctrl
PCI: cpcihp: Remove unused struct cpci_hp_controller_ops.hardware_test
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:44 +0000 (13:40 -0600)]
Merge branch 'pci/enumeration'
- Simplify pci_read_bridge_bases() logic (Ilpo Järvinen)
* pci/enumeration:
PCI: Simplify pci_read_bridge_bases() logic
PCI: Move struct pci_bus_resource into bus.c
PCI: Remove unused PCI_SUBTRACTIVE_DECODE
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:44 +0000 (13:40 -0600)]
Merge branch 'pci/driver-remove'
- Convert driver .remove_new() callbacks to .remove() again to finish the
conversion from returning 'int' to being 'void' (Sergio Paracuellos)
* pci/driver-remove:
PCI: acpiphp_ampere_altra: Switch back to struct platform_driver::remove()
PCI: controller: Switch back to struct platform_driver::remove()
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:43 +0000 (13:40 -0600)]
Merge branch 'pci/devm'
- Export pcim_request_all_regions(), a managed interface to request all
BARs (Philipp Stanner)
- Replace pcim_iomap_regions_request_all() with pcim_request_all_regions(),
and pcim_iomap_table()[n] with pcim_iomap(n), in the following drivers:
ahci, crypto qat, crypto octeontx2, intel_th, iwlwifi, ntb idt, serial
rp2, ALSA korg1212 (Philipp Stanner)
- Remove the now unused pcim_iomap_regions_request_all() (Philipp Stanner)
- Export pcim_iounmap_region(), a managed interface to unmap and release a
PCI BAR (Philipp Stanner)
- Replace pcim_iomap_regions(mask) with pcim_iomap_region(n), and
pcim_iounmap_regions(mask) with pcim_iounmap_region(n), in the following
drivers: fpga dfl-pci, block mtip32xx, gpio-merrifield, cavium (Philipp
Stanner)
* pci/devm:
ethernet: cavium: Replace deprecated PCI functions
gpio: Replace deprecated PCI functions
fpga/dfl-pci.c: Replace deprecated PCI functions
PCI: Deprecate pcim_iounmap_regions()
PCI: Make pcim_iounmap_region() a public function
PCI: Remove pcim_iomap_regions_request_all()
ALSA: korg1212: Replace deprecated PCI functions
serial: rp2: Replace deprecated PCI functions
ntb: idt: Replace deprecated PCI functions
wifi: iwlwifi: replace deprecated PCI functions
intel_th: pci: Replace deprecated PCI functions
crypto: marvell - replace deprecated PCI functions
crypto: qat - replace deprecated PCI functions
ata: ahci: Replace deprecated PCI functions
PCI: Make pcim_request_all_regions() a public function
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:43 +0000 (13:40 -0600)]
Merge branch 'pci/doe'
- Wait up to 1 second for DOE Busy bit to clear before writing a request to
the mailbox to avoid failures if the mailbox is still busy from a
previous transfer (Gregory Price)
* pci/doe:
PCI/DOE: Poll DOE Busy bit for up to 1 second in pci_doe_send_req()
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:43 +0000 (13:40 -0600)]
Merge branch 'pci/bwctrl'
- Add read/modify/write locking for Link Control 2, which is used to manage
Link speed (Ilpo Järvinen)
- Cache all supported Link speeds for use by the PCIe bandwidth controller
(Ilpo Järvinen)
- Extract the Link Bandwidth Management Status check into pcie_lbms_seen(),
where it can be shared between the bandwidth controller and quirks that
use it to help retrain failed links (Ilpo Järvinen)
- Re-add Link Bandwidth notification support with updates to address the
reasons it was previously reverted (Alexandru Gagniuc, Ilpo Järvinen)
- Add pcie_set_target_speed() and related functionality to manage PCIe Link
speed based on thermal constraints (Ilpo Järvinen)
- Add a thermal cooling driver to throttle PCIe Links via the existing
thermal management framework (Ilpo Järvinen)
- Add a userspace selftest for the PCIe bandwidth controller (Ilpo
Järvinen)
- Drop duplicate pcie_get_speed_cap(), pcie_get_width_cap() declarations
(Bjorn Helgaas)
* pci/bwctrl:
PCI: Drop duplicate pcie_get_speed_cap(), pcie_get_width_cap() declarations
selftests/pcie_bwctrl: Create selftests
thermal: Add PCIe cooling driver
PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed
PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller
PCI: Abstract LBMS seen check into pcie_lbms_seen()
PCI: Refactor pcie_update_link_speed()
PCI: Store all PCIe Supported Link Speeds
PCI: Protect Link Control 2 Register with RMW locking
Documentation PCI: Reformat RMW ops documentation
Bjorn Helgaas [Mon, 25 Nov 2024 19:40:42 +0000 (13:40 -0600)]
Merge branch 'pci/aspm'
- Disable ASPM L1 before touching L1 PM Substates to follow the spec
closer and avoid a CPU load timeout on some platforms (Ajay Agarwal)
- Set devices below Intel VMD to D0 before enabling ASPM L1 Substates
(Jian-Hong Pan)
* pci/aspm:
PCI: vmd: Set devices to D0 before enabling PM L1 Substates
PCI/ASPM: Add notes about enabling PCI-PM L1SS to pci_enable_link_state(_locked)
PCI/ASPM: Disable L1 before disabling L1 PM Substates
Bjorn Helgaas [Fri, 15 Nov 2024 21:44:28 +0000 (15:44 -0600)]
PCI/pwrctrl: Rename pwrctrl functions and structures
Rename pwrctrl functions and structures from "pwrctl" to "pwrctrl" to match
the similar file renames.
Link: https://lore.kernel.org/r/20241115214428.2061153-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Krzysztof Wilczyński <kw@linux.com>
Bjorn Helgaas [Fri, 15 Nov 2024 21:44:27 +0000 (15:44 -0600)]
PCI/pwrctrl: Rename pwrctl files to pwrctrl
To slightly reduce confusion between "pwrctl" (the power controller and
power sequencing framework) and "bwctrl" (the bandwidth controller),
rename "pwrctl" to "pwrctrl" so they use the same "ctrl" suffix.
Rename drivers/pci/pwrctl/ to drivers/pci/pwrctrl/, including the related
MAINTAINERS, include file (include/linux/pci-pwrctl.h), Makefile, and
Kconfig changes.
This is the minimal rename of files only. A subsequent commit will rename
functions and data structures.
Link: https://lore.kernel.org/r/20241115214428.2061153-2-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Krzysztof Wilczyński <kw@linux.com>
Manivannan Sadhasivam [Fri, 25 Oct 2024 07:54:55 +0000 (13:24 +0530)]
PCI/pwrctl: Remove pwrctl device without iterating over all children of pwrctl parent
There is no need to iterate over all children of the pwrctl device parent
to remove the pwrctl device. Since the pwrctl device associated with the
PCI device can be found using of_find_device_by_node() API, use it directly
instead.
Any pwrctl devices lying around without getting associated with the PCI
devices will be removed once their parent device gets removed.
Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-5-568756156cbe@linaro.org
Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Manivannan Sadhasivam [Fri, 25 Oct 2024 07:54:53 +0000 (13:24 +0530)]
PCI/pwrctl: Ensure that pwrctl drivers are probed before PCI client drivers
As per the kernel device driver model, a pwrctl device is the supplier for
the PCI device, but the device link that enforces the supplier-consumer
relationship was previously created by the pwrctl driver. Therefore, the
driver model didn't prevent probing PCI client drivers before probing the
corresponding pwrctl drivers. This may lead to a race condition if the PCI
device was already powered on by the bootloader (before the pwrctl driver).
If the bootloader did not power on the PCI device, this wouldn't create any
problem as the pwrctl driver will be the one powering on the device, so the
PCI client driver always gets probed afterward. But if the device was
already powered on, then the device will be seen by the PCI core and the
PCI client driver may get probed before its pwrctl driver. This creates a
race condition as the pwrctl driver may change the device power state while
the device is being accessed by the client driver.
One such issue was already reported on the Qcom X13s platform with the WLAN
device and fixed with a hack in the WCN pwrseq driver by
a9aaf1ff88a8
("power: sequencing: request the WLAN enable GPIO as-is").
A cleaner way to fix the above mentioned race condition is to ensure that
the pwrctl drivers are always probed before the client drivers.
If the PCI device is associated with a pwrctl platform device with a power
supply, add a device link between the PCI device and the pwrctl device
before device_attach() in pci_bus_add_device().
Note that there is no need to explicitly remove the device link as that
will be taken care of by the driver core when the PCI device gets removed.
Fixes:
4565d2652a37 ("PCI/pwrctl: Add PCI power control core code")
Fixes:
8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node")
Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-3-568756156cbe@linaro.org
Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[bhelgaas: squash fix from
https://lore.kernel.org/r/
20241120062459.6371-1-manivannan.sadhasivam@linaro.org
for SPARCv9 issue reported by Jonathan Currier <dullfire@yahoo.com>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
[kwilczynski: wrap code to 80 columns]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: stable+noautosel@kernel.org # Depends on power supply check
Manivannan Sadhasivam [Fri, 25 Oct 2024 07:54:52 +0000 (13:24 +0530)]
PCI/pwrctl: Create pwrctl device only if at least one power supply is present
Currently, pwrctl devices are created if the corresponding PCI nodes are
defined in devicetree. But this is not correct, because not all PCI nodes
require pwrctl support. Pwrctl comes into the picture only when the device
requires kernel to manage its power state. This can be determined using the
power supply properties present in the devicetree node of the device.
Add of_pci_supply_present() to check whether the devicetree contains at
least one power supply property for a device. If one is present, create a
pwrctl device for that PCI node.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes:
8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node")
Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-2-568756156cbe@linaro.org
Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[bhelgaas: rename of_pci_is_supply_present() to of_pci_supply_present() for
readability]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: stable+noautosel@kernel.org # Depends on of_platform_device_create() rework
Manivannan Sadhasivam [Fri, 25 Oct 2024 07:54:51 +0000 (13:24 +0530)]
PCI/pwrctl: Use of_platform_device_create() to create pwrctl devices
The of_platform_populate() API creates platform devices by descending
through the children of the parent node. But it provides no control over
the child nodes, which makes it difficult to add checks for the child
nodes in the future.
Use of_platform_device_create() and for_each_child_of_node_scoped() to make
it possible to add checks for each node before creating the platform
device.
Link: https://lore.kernel.org/r/20241025-pci-pwrctl-rework-v2-1-568756156cbe@linaro.org
Tested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Rick Wertenbroek [Thu, 14 Nov 2024 16:10:32 +0000 (17:10 +0100)]
PCI: endpoint: Fix pci_epc_map map_size kerneldoc string
Because some endpoint controllers have requirements on the alignment of
the controller physical memory address that must be used to map a RC PCI
address region, the map PCI start address is not necessarily the desired
PCI base address to be mapped. This can result in map_pci_addr being
lower than pci_addr as documented. This results in map_size covering the
range map_pci_addr..pci_addr+pci_size.
The old text had the pci_addr twice instead of map_pci_addr..pci_addr,
so replace the erroneous kerneldoc string to reflect the actual range.
Link: https://lore.kernel.org/r/20241114161032.3046202-1-rick.wertenbroek@gmail.com
Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Zijun Hu [Thu, 7 Nov 2024 00:53:09 +0000 (08:53 +0800)]
PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf()
In addition to a primary endpoint controller, an endpoint function may be
associated with a secondary endpoint controller, epf->sec_epc, to provide
NTB (non-transparent bridge) functionality.
Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of
epf->sec_epc when removing from the secondary endpoint controller.
Extend the epc->list_lock coverage and clear either epf->epc or
epf->sec_epc as indicated.
Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com
Fixes:
63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF")
Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: stable@vger.kernel.org
Zijun Hu [Thu, 7 Nov 2024 00:53:08 +0000 (08:53 +0800)]
PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy()
pci_epc_destroy() invokes pci_bus_release_domain_nr() to release the PCI
domain ID, but there are two issues:
- 'epc->dev' is passed to pci_bus_release_domain_nr() which was already
freed by device_unregister(), leading to a use-after-free issue.
- Domain ID corresponds to the EPC device parent, so passing 'epc->dev'
is also wrong.
Fix these issues by passing 'epc->dev.parent' to
pci_bus_release_domain_nr() and also do it before device_unregister().
Fixes:
0328947c5032 ("PCI: endpoint: Assign PCI domain number for endpoint controllers")
Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-1-da5b6a99a66f@quicinc.com
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: stable@vger.kernel.org
Zhongqiu Han [Tue, 5 Nov 2024 12:07:35 +0000 (20:07 +0800)]
PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
If platform_get_resource_byname() fails and returns NULL because DT lacks
an 'mmio' property for the MHI endpoint, dereferencing res->start will
cause a NULL pointer access. Add a check to prevent it.
Fixes:
1bf5f25324f7 ("PCI: endpoint: Add PCI Endpoint function driver for MHI bus")
Link: https://lore.kernel.org/r/20241105120735.1240728-1-quic_zhonhan@quicinc.com
Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
[kwilczynski: error message update per the review feedback]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Wang Jiang [Mon, 4 Nov 2024 10:05:14 +0000 (18:05 +0800)]
PCI: endpoint: Remove surplus return statement from pci_epf_test_clean_dma_chan()
Remove a surplus return statement from the void function that has been
added in the commit commit
8353813c88ef ("PCI: endpoint: Enable DMA
tests for endpoints with DMA capabilities").
Especially, as an empty return statements at the end of a void functions
serve little purpose.
This fixes the following checkpatch.pl script warning:
WARNING: void function return statements are not generally useful
#296: FILE: drivers/pci/endpoint/functions/pci-epf-test.c:296:
+ return;
+}
Link: https://lore.kernel.org/r/tencent_F250BEE2A65745A524E2EFE70CF615CA8F06@qq.com
Signed-off-by: Wang Jiang <jiangwang@kylinos.cn>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Niklas Cassel [Thu, 17 Oct 2024 13:20:55 +0000 (15:20 +0200)]
PCI: dwc: ep: Use align addr function for dw_pcie_ep_raise_{msi,msix}_irq()
Use the dw_pcie_ep_align_addr() function to calculate the alignment in
dw_pcie_ep_raise_{msi,msix}_irq() instead of open coding the same.
Link: https://lore.kernel.org/r/20241017132052.4014605-6-cassel@kernel.org
Link: https://lore.kernel.org/r/20241104205144.409236-2-cassel@kernel.org
Tested-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[kwilczynski: squashed patch that fixes memory map sizes]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Bjorn Helgaas [Mon, 11 Nov 2024 20:21:33 +0000 (14:21 -0600)]
PCI: Drop duplicate pcie_get_speed_cap(), pcie_get_width_cap() declarations
6cf57be0f78e ("PCI: Add pcie_get_speed_cap() to find max supported link
speed") and
c70b65fb7f12 ("PCI: Add pcie_get_width_cap() to find max
supported link width") added declarations to drivers/pci/pci.h.
576c7218a154 ("PCI: Export pcie_get_speed_cap and pcie_get_width_cap")
subsequently added duplicates to include/linux/pci.h.
Remove the originals from drivers/pci/pci.h. Both interfaces are used by
amdgpu, so they must be in include/linux/pci.h.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Krzysztof Wilczyński <kw@linux.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:55 +0000 (17:47 +0300)]
selftests/pcie_bwctrl: Create selftests
Create selftests for PCIe BW control through the PCIe cooling device sysfs
interface.
First, the BW control selftest finds the PCIe Port to test with. By
default, the PCIe Port with the highest Link Speed is selected but
another PCIe Port can be provided with -d parameter.
The actual test steps the cur_state of the cooling device one-by-one
from max_state to what the cur_state was initially. The speed change
is confirmed by observing the current_link_speed for the corresponding
PCIe Port.
Link: https://lore.kernel.org/r/20241018144755.7875-10-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:54 +0000 (17:47 +0300)]
thermal: Add PCIe cooling driver
Add a thermal cooling driver to provide path to access PCIe bandwidth
controller using the usual thermal interfaces.
A cooling device is instantiated for controllable PCIe Ports from the
bwctrl service driver.
If registering the cooling device fails, allow bwctrl's probe to succeed
regardless. As cdev in that case contains IS_ERR() pseudo "pointer", clean
that up inside the probe function so the remove side doesn't need to
suddenly make an odd looking IS_ERR() check.
The thermal side state 0 means no throttling, i.e., maximum supported PCIe
Link Speed.
Link: https://lore.kernel.org/r/20241018144755.7875-9-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: dropped data->cdev test per
https://lore.kernel.org/r/ZzRm1SJTwEMRsAr8@wunner.de]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org> # From the cooling device interface perspective
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:53 +0000 (17:47 +0300)]
PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed
Currently, PCIe Link Speeds are adjusted by custom code rather than in a
common function provided in PCI core. The PCIe bandwidth controller
(bwctrl) introduces an in-kernel API, pcie_set_target_speed(), to set PCIe
Link Speed.
Convert Target Speed quirk to use the new API. The Target Speed quirk runs
very early when bwctrl is not yet probed for a Port and can also run later
when bwctrl is already setup for the Port, which requires the per port
mutex (set_speed_mutex) to be only taken if the bwctrl setup is already
complete.
The new API is also intended to be used in an upcoming commit that adds a
thermal cooling device to throttle PCIe bandwidth when thermal thresholds
are reached.
The PCIe bandwidth control procedure is as follows. The highest speed
supported by the Port and the PCIe device which is not higher than the
requested speed is selected and written into the Target Link Speed in the
Link Control 2 Register. Then bandwidth controller retrains the PCIe Link.
Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to
keep track PCIe Link Speed changes. While Bandwidth Notifications should
also be generated when bandwidth controller alters the PCIe Link Speed, a
few platforms do not deliver LMBS interrupt after Link Training as
expected. Thus, after changing the Link Speed, bandwidth controller makes
additional read for the Link Status Register to ensure cur_bus_speed is
consistent with the new PCIe Link Speed.
Link: https://lore.kernel.org/r/20241018144755.7875-8-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: squash devm_mutex_init() error checking from
https://lore.kernel.org/r/
20241030163139.
2111689-1-andriy.shevchenko@linux.intel.com,
drop export of pcie_set_target_speed()]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:52 +0000 (17:47 +0300)]
PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller
This mostly reverts the commit
b4c7d2076b4e ("PCI/LINK: Remove bandwidth
notification"). An upcoming commit extends this driver building PCIe
bandwidth controller on top of it.
PCIe bandwidth notifications were first added in the commit
e8303bb7a75c
("PCI/LINK: Report degraded links via link bandwidth notification") but
later had to be removed. The significant changes compared with the old
bandwidth notification driver include:
1) Don't print the notifications into kernel log, just keep the Link
Speed cached in struct pci_bus updated. While somewhat unfortunate,
the log spam was the source of complaints that eventually lead to
the removal of the bandwidth notifications driver (see the links
below for further information).
2) Besides the Link Bandwidth Management Interrupt, also enable Link
Autonomous Bandwidth Interrupt to cover the other source of bandwidth
changes.
3) Handle Link Speed updates robustly. Refresh the cached Link Speed
when enabling Bandwidth Notification Interrupts, and solve the race
between Link Speed read and LBMS/LABS update in
pcie_bwnotif_irq_thread().
4) Use concurrency safe LNKCTL RMW operations.
5) The driver is now called PCIe bwctrl (bandwidth controller) instead
of just bandwidth notifications because of increased scope and
functionality within the driver.
6) Coexist with the Target Link Speed quirk in pcie_failed_link_retrain().
Provide LBMS counting API for it.
7) Tweaks to variable/functions names for consistency and length reasons.
Bandwidth Notifications enable the cur_bus_speed in the struct pci_bus to
keep track PCIe Link Speed changes.
[bhelgaas: This is based on previous work by Alexandru Gagniuc
<mr.nuke.me@gmail.com>; see
e8303bb7a75c ("PCI/LINK: Report degraded links
via link bandwidth notification")]
Link: https://lore.kernel.org/r/20241018144755.7875-7-ilpo.jarvinen@linux.intel.com
Link: https://lore.kernel.org/all/20190429185611.121751-1-helgaas@kernel.org/
Link: https://lore.kernel.org/linux-pci/20190501142942.26972-1-keith.busch@intel.com/
Link: https://lore.kernel.org/linux-pci/20200115221008.GA191037@google.com/
Suggested-by: Lukas Wunner <lukas@wunner.de> # Building bwctrl on top of bwnotif
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: squash fix to drop IRQF_ONESHOT and convert to hardirq handler:
https://lore.kernel.org/r/
20241115165717.15233-1-ilpo.jarvinen@linux.intel.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Mengyuan Lou [Fri, 15 Nov 2024 02:46:04 +0000 (10:46 +0800)]
PCI: Add ACS quirk for Wangxun FF5xxx NICs
Wangxun FF5xxx NICs are similar to SFxxx, RP1000 and RP2000 NICs. They may
be multi-function devices, but they do not advertise an ACS capability.
But the hardware does isolate FF5xxx functions as though it had an ACS
capability and PCI_ACS_RR and PCI_ACS_CR were set in the ACS Control
register, i.e., all peer-to-peer traffic is directed upstream instead of
being routed internally.
Add ACS quirk for FF5xxx NICs in pci_quirk_wangxun_nic_acs() so the
functions can be in independent IOMMU groups.
Link: https://lore.kernel.org/r/E16053DB2B80E9A5+20241115024604.30493-1-mengyuanlou@net-swift.com
Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Andrea della Porta [Fri, 8 Nov 2024 09:42:56 +0000 (10:42 +0100)]
PCI: of_property: Assign PCI instead of CPU bus address to dynamic PCI nodes
When populating "ranges" property for a PCI bridge or endpoint,
of_pci_prop_ranges() incorrectly uses the CPU address of the resource. In
such PCI nodes, the window should instead be in PCI address space. Call
pci_bus_address() on the resource in order to obtain the PCI bus address.
[Previous discussion at:
https://lore.kernel.org/all/
8b4fa91380fc4754ea80f47330c613e4f6b6592c.
1724159867.git.andrea.porta@suse.com/]
Link: https://lore.kernel.org/r/20241108094256.28933-1-andrea.porta@suse.com
Fixes:
407d1a51921e ("PCI: Create device tree node for bridge")
Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Shijith Thotton [Mon, 11 Nov 2024 13:45:11 +0000 (19:15 +0530)]
PCI: hotplug: Add OCTEON PCI hotplug controller driver
Add a PCI hotplug controller driver for the OCTEON PCIe device. The OCTEON
PCIe device is a multi-function device where function 0 serves as the PCI
hotplug controller.
There is an out-of-band management console interface to firmware running on
function 0 whereby an administrator can disable functions to save power or
enable them with one of several personalities (virtio-net, virtio-crypto,
NVMe, etc) for the other functions. Function 0 initiates hotplug events
handled by this driver when the other functions are enabled or disabled.
+--------------------------------+
| Root Port |
+--------------------------------+
|
PCIe
|
+---------------------------------------------------------------+
| OCTEON PCIe Multifunction Device |
+---------------------------------------------------------------+
| | | |
| | | |
+---------------------+ +----------------+ +-----+ +----------------+
| Function 0 | | Function 1 | | ... | | Function 7 |
| (Hotplug controller)| | (Hotplug slot) | | | | (Hotplug slot) |
+---------------------+ +----------------+ +-----+ +----------------+
|
|
+-------------------------+
| Controller Firmware |
+-------------------------+
The hotplug controller driver enables hotplugging of non-controller
functions within the same device. During probing, the driver removes
the non-controller functions and registers them as PCI hotplug slots.
These slots are added back by the driver, only upon request from the
device firmware.
The controller uses MSI-X interrupts to notify the host of hotplug
events initiated by the OCTEON firmware. Additionally, the driver
allows users to enable or disable individual functions via sysfs slot
entries, as provided by the PCI hotplug framework.
Link: https://lore.kernel.org/r/20241111134523.2796699-1-sthotton@marvell.com
Co-developed-by: Vamsi Attunuru <vattunuru@marvell.com>
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
[bhelgaas: use pci_info() when possible]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Keith Busch [Fri, 25 Oct 2024 22:27:55 +0000 (15:27 -0700)]
PCI: Warn if a running device is unaware of reset
If a reset is issued to a running device with a driver that didn't register
the notification callbacks, the driver may be unaware of this event and
have an inconsistent view of the device's state. Log a warning of this
event because there's nothing else indicating the event occured, which
could be confusing when debugging such situations.
Link: https://lore.kernel.org/r/20241025222755.3756162-2-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Keith Busch [Fri, 25 Oct 2024 22:27:54 +0000 (15:27 -0700)]
PCI: Add 'reset_subordinate' to reset hierarchy below bridge
The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary
Bus Reset on the bridge leading to the device. These only work if the
device is the only device below the bridge.
Add a sysfs 'reset_subordinate' attribute on bridges that can assert
Secondary Bus Reset regardless of how many devices are below the bridge.
This resets all the devices below a bridge in a single command, including
the locking and config space save/restore that reset methods normally do.
This may be the only way to reset devices that don't support other reset
methods (ACPI, FLR, PM reset, etc).
Link: https://lore.kernel.org/r/20241025222755.3756162-1-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
[bhelgaas: commit log, add capable(CAP_SYS_ADMIN) check]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com>
Krishna chaitanya chundru [Mon, 11 Nov 2024 08:41:53 +0000 (14:11 +0530)]
PCI: Enable runtime PM of the host bridge
The controller driver is the parent device of the PCIe host bridge,
PCI-PCI bridge and PCIe endpoint as shown below.
PCIe controller (Top level parent & parent of host bridge)
|
v
PCIe Host bridge (Parent of PCI-PCI bridge)
|
v
PCI-PCI bridge (Parent of endpoint driver)
|
v
PCIe endpoint driver
Now, when the controller device goes to runtime suspend, PM framework will
check the runtime PM state of the child device (host bridge) and will find
it to be disabled. So it will allow the parent (controller device) to go to
runtime suspend. Only if the child device's state was 'active' it will
prevent the parent to get suspended.
It is a property of the runtime PM framework that it can only follow
continuous dependency chains. That is, if there is a device with runtime
PM disabled in a dependency chain, runtime PM cannot be enabled for devices
below it and above it in that chain both at the same time.
Since runtime PM is disabled for host bridge, the state of the child
devices under the host bridge is not taken into account by PM framework for
the top level parent, PCIe controller. So the PM framework allows the
controller driver to enter runtime PM irrespective of the state of the
devices under the host bridge. And this causes the topology breakage and
also possible PM issues like controller driver going to runtime suspend
while the endpoint driver is doing transfers.
Because of the above, in order to enable runtime PM for a PCIe controller
device, one needs to ensure that runtime PM is enabled for all devices in
every dependency chain between it and any PCIe endpoint (as runtime PM is
enabled for PCIe endpoints).
This means that runtime PM needs to be enabled for the host bridge device,
which is present in all of these dependency chains.
After this change, the host bridge device will be runtime-suspended by the
runtime PM framework automatically after suspending its last child and it
will be runtime-resumed automatically before resuming its first child which
will allow the runtime PM framework to track dependencies between the host
bridge device and all of its descendants.
The PM framework expects parent runtime PM to be enabled before enabling
runtime PM of the child. Ensure pm_runtime_enable() is called for the
controller drivers before calling pci_host_probe().
Link: https://lore.kernel.org/r/20241111-runtime_pm-v7-2-9c164eefcd87@quicinc.com
Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Mayank Rana [Mon, 11 Nov 2024 08:41:52 +0000 (14:11 +0530)]
PCI: starfive: Enable controller runtime PM before probing host bridge
A PCI controller device, e.g., StarFive, is parent to PCI host bridge
device. We must enable runtime PM of the controller before enabling runtime
PM of the host bridge, which will happen in pci_host_probe(), to avoid this
warning:
pcie-starfive
940000000.pcie: Enabling runtime PM for inactive device with active children
Fix this issue by enabling StarFive controller device's runtime PM before
calling pci_host_probe() in plda_pcie_host_init().
Link: https://lore.kernel.org/r/20241111-runtime_pm-v7-1-9c164eefcd87@quicinc.com
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Keith Busch [Tue, 22 Oct 2024 22:48:51 +0000 (15:48 -0700)]
PCI: Unexport pci_walk_bus_locked()
There's only one user of pci_walk_bus_locked(), and it's internal to the
PCI core. Unexport it and make it private to drivers/pci/.
Link: https://lore.kernel.org/r/20241022224851.340648-6-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
[bhelgaas: move decl to drivers/pci/pci.h]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:51 +0000 (17:47 +0300)]
PCI: Abstract LBMS seen check into pcie_lbms_seen()
The Target Speed quirk in pcie_failed_link_retrain() uses the presence of
LBMS bit as one of the triggering conditions, effectively monopolizing the
use of that bit. An upcoming change will introduce a PCIe bandwidth
controller which sets up an interrupt to track LBMS. As LBMS will be
cleared by the interrupt handler, the Target Speed quirk will no longer be
able to observe LBMS directly.
As a preparatory step for the change, extract the LBMS seen check from
pcie_failed_link_retrain() into a new function pcie_lmbs_seen().
Link: https://lore.kernel.org/r/20241018144755.7875-6-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:50 +0000 (17:47 +0300)]
PCI: Refactor pcie_update_link_speed()
pcie_update_link_speed() is passed the Link Status register but not all
callers have that value at hand nor need the value.
Refactor pcie_update_link_speed() to include reading the Link Status
register and create __pcie_update_link_speed() which can be used by the
hotplug code that has the register value at hand beforehand (and needs the
value for other purposes).
Link: https://lore.kernel.org/r/20241018144755.7875-5-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:49 +0000 (17:47 +0300)]
PCI: Store all PCIe Supported Link Speeds
The PCIe bandwidth controller added by a subsequent commit will require
selecting PCIe Link Speeds that are lower than the Maximum Link Speed.
The struct pci_bus only stores max_bus_speed. Even if PCIe r6.1 sec 8.2.1
currently disallows gaps in supported Link Speeds, the Implementation Note
in PCIe r6.1 sec 7.5.3.18, recommends determining supported Link Speeds
using the Supported Link Speeds Vector in the Link Capabilities 2 Register
(when available) to "avoid software being confused if a future
specification defines Links that do not require support for all slower
speeds."
Reuse code in pcie_get_speed_cap() to add pcie_get_supported_speeds() to
query the Supported Link Speeds Vector of a PCIe device. The value is taken
directly from the Supported Link Speeds Vector or synthesized from the Max
Link Speed in the Link Capabilities Register when the Link Capabilities 2
Register is not available.
The Supported Link Speeds Vector in the Link Capabilities Register 2
corresponds to the bus below on Root Ports and Downstream Ports, whereas it
corresponds to the bus above on Upstream Ports and Endpoints (PCIe r6.1 sec
7.5.3.18):
Supported Link Speeds Vector - This field indicates the supported Link
speed(s) of the associated Port.
Add supported_speeds into the struct pci_dev that caches the
Supported Link Speeds Vector.
supported_speeds contains a set of Link Speeds only in the case where PCIe
Link Speed can be determined. Root Complex Integrated Endpoints do not have
a well-defined Link Speed because they do not implement either of the Link
Capabilities Registers, which is allowed by PCIe r6.1 sec 7.5.3 (the same
limitation applies to determining cur_bus_speed and max_bus_speed that are
PCI_SPEED_UNKNOWN in such case). This is of no concern from PCIe bandwidth
controller point of view because such devices are not attached into a PCIe
Root Port that could be controlled.
The supported_speeds field keeps the extra reserved zero at the least
significant bit to match the Link Capabilities 2 Register layout.
An attempt was made to store supported_speeds field into the struct pci_bus
as an intersection of both ends of the Link, however, the subordinate
struct pci_bus is not available early enough. The Target Speed quirk (in
pcie_failed_link_retrain()) can run either during initial scan or later,
requiring it to use the API provided by the PCIe bandwidth controller to
set the Target Link Speed in order to co-exist with the bandwidth
controller. When the Target Speed quirk is calling the bandwidth controller
during initial scan, the struct pci_bus is not yet initialized. As such,
storing supported_speeds into the struct pci_bus is not viable.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20241018144755.7875-4-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
[bhelgaas: move pcie_get_supported_speeds() decl to drivers/pci/pci.h]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Keith Busch [Tue, 22 Oct 2024 22:48:50 +0000 (15:48 -0700)]
PCI: Convert __pci_walk_bus() to be recursive
The original implementation of __pci_walk_bus() chose a non-recursive walk,
presumably as a precaution on stack use. We do recursive bus walking in
other places though. For example:
pci_bus_resettable()
pci_stop_bus_device()
pci_remove_bus_device()
pci_bus_allocate_dev_resources()
So recursive pci bus walking is well tested and safe, and is easier to
follow.
Convert __pci_walk_bus() to be recursive to make it easier to introduce
finer grain locking in the future.
Link: https://lore.kernel.org/r/20241022224851.340648-5-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Keith Busch [Tue, 22 Oct 2024 22:48:49 +0000 (15:48 -0700)]
PCI: Move __pci_walk_bus() mutex to where we need it
Simplify __pci_walk_bus() by moving the pci_bus_sem mutex into
pci_walk_bus(), the only place it is needed, and removing the parameter
that told __pci_walk_bus() whether to acquire the mutex.
Link: https://lore.kernel.org/r/20241022224851.340648-4-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Keith Busch [Tue, 22 Oct 2024 22:48:48 +0000 (15:48 -0700)]
PCI: Make pci_destroy_dev() concurrent safe
Use an atomic flag instead of the racy check against the device's kobj
parent. We shouldn't be poking into device implementation details at this
level anyway.
Link: https://lore.kernel.org/r/20241022224851.340648-3-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Keith Busch [Tue, 22 Oct 2024 22:48:47 +0000 (15:48 -0700)]
PCI: Make pci_stop_dev() concurrent safe
Use the atomic ADDED flag to ensure concurrent callers can't attempt to
stop the device multiple times. Callers should currently all be holding the
pci_rescan_remove_lock, so there shouldn't be an existing race. But that
global lock can cause lock dependency issues, so this is preparing to
reduce reliance on that lock by using the existing existing atomic bit ops.
Link: https://lore.kernel.org/r/20241022224851.340648-2-kbusch@meta.com
Signed-off-by: Keith Busch <kbusch@kernel.org>
[bhelgaas: squash https://lore.kernel.org/r/
20241111180659.
3321671-1-kbusch@meta.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Philipp Stanner [Wed, 16 Oct 2024 09:49:09 +0000 (11:49 +0200)]
ethernet: cavium: Replace deprecated PCI functions
pcim_iomap_regions() and pcim_iomap_table() have been deprecated by
the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace the deprecated PCI functions with their successors.
Link: https://lore.kernel.org/r/20241016094911.24818-8-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Philipp Stanner [Wed, 16 Oct 2024 09:49:08 +0000 (11:49 +0200)]
gpio: Replace deprecated PCI functions
pcim_iomap_regions() and pcim_iomap_table() have been deprecated by the
PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace those functions with calls to pcim_iomap_region().
Link: https://lore.kernel.org/r/20241016094911.24818-7-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Philipp Stanner [Wed, 16 Oct 2024 09:49:06 +0000 (11:49 +0200)]
fpga/dfl-pci.c: Replace deprecated PCI functions
pcim_iomap_regions() and pcim_iomap_table() have been deprecated by the
PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Port dfl-pci.c to the successor, pcim_iomap_region().
Consistently, replace pcim_iounmap_regions() with pcim_iounmap_region().
Link: https://lore.kernel.org/r/20241016094911.24818-5-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Xu Yilun <yilun.xu@intel.com>
Philipp Stanner [Wed, 16 Oct 2024 09:49:05 +0000 (11:49 +0200)]
PCI: Deprecate pcim_iounmap_regions()
pcim_ioumap_region() has recently been made a public function and does
not have the disadvantage of having to deal with the legacy iomap table,
as pcim_iounmap_regions() does.
Deprecate pcim_iounmap_regions().
Link: https://lore.kernel.org/r/20241016094911.24818-4-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Esther Shimanovich [Tue, 10 Sep 2024 17:57:45 +0000 (17:57 +0000)]
PCI: Detect and trust built-in Thunderbolt chips
Some computers with CPUs that lack Thunderbolt features use discrete
Thunderbolt chips to add Thunderbolt functionality. These Thunderbolt
chips are located within the chassis; between the Root Port labeled
ExternalFacingPort and the USB-C port.
These Thunderbolt PCIe devices should be labeled as fixed and trusted, as
they are built into the computer. Otherwise, security policies that rely on
those flags may have unintended results, such as preventing USB-C ports
from enumerating.
Detect the above scenario through the process of elimination.
1) Integrated Thunderbolt host controllers already have Thunderbolt
implemented, so anything outside their external facing Root Port is
removable and untrusted.
Detect them using the following properties:
- Most integrated host controllers have the "usb4-host-interface"
ACPI property, as described here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#mapping-native-protocols-pcie-displayport-tunneled-through-usb4-to-usb4-host-routers
- Integrated Thunderbolt PCIe Root Ports before Alder Lake do not
have the "usb4-host-interface" ACPI property. Identify those by
their PCI IDs instead.
2) If a Root Port does not have integrated Thunderbolt capabilities, but
has the "ExternalFacingPort" ACPI property, that means the
manufacturer has opted to use a discrete Thunderbolt host controller
that is built into the computer.
This host controller can be identified by virtue of being located
directly below an external-facing Root Port that lacks integrated
Thunderbolt. Label it as trusted and fixed.
Everything downstream from it is untrusted and removable.
The "ExternalFacingPort" ACPI property is described here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Link: https://lore.kernel.org/r/20240910-trust-tbt-fix-v5-1-7a7a42a5f496@chromium.org
Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Esther Shimanovich <eshimanovich@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Jian-Hong Pan [Tue, 1 Oct 2024 08:34:38 +0000 (16:34 +0800)]
PCI: vmd: Set devices to D0 before enabling PM L1 Substates
The remapped PCIe Root Port and the child device have PM L1 Substates
capability, but they are disabled originally.
Here is a failed example on ASUS
B1400CEAE:
Capabilities: [900 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
PortCommonModeRestoreTime=32us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=101376ns
L1SubCtl2: T_PwrOn=50us
Enable PCI-PM L1 PM Substates for devices below VMD while they are in D0
(see PCIe r6.0, sec 5.5.4).
Link: https://lore.kernel.org/r/20241001083438.10070-4-jhp@endlessos.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Jian-Hong Pan [Tue, 1 Oct 2024 08:34:40 +0000 (16:34 +0800)]
PCI/ASPM: Add notes about enabling PCI-PM L1SS to pci_enable_link_state(_locked)
According to "PCIe r6.0, sec 5.5.4", add note about D0 requirement in
pci_enable_link_state() kernel-doc.
Link: https://lore.kernel.org/r/20241001083438.10070-6-jhp@endlessos.org
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Rob Herring (Arm) [Tue, 5 Nov 2024 21:32:16 +0000 (15:32 -0600)]
dt-bindings: PCI: snps,dw-pcie: Drop "#interrupt-cells" from example
"#interrupt-cells" is not valid without a corresponding "interrupt-map"
or "interrupt-controller" property. As the example has neither, drop
"#interrupt-cells".
This fixes a dtc interrupt_provider warning.
Link: https://lore.kernel.org/r/20241105213217.442809-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Damien Le Moal [Thu, 17 Oct 2024 01:06:48 +0000 (10:06 +0900)]
PCI: endpoint: test: Synchronously cancel command handler work
Use cancel_delayed_work_sync() in pci_epf_test_epc_deinit() to ensure
that the command handler is really stopped before proceeding with DMA
and BAR cleanup.
The same change is also done in pci_epf_test_link_down() to ensure that
the link down handling completes with the command handler fully stopped.
Link: https://lore.kernel.org/r/20241017010648.189889-1-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Damien Le Moal [Sat, 12 Oct 2024 11:32:46 +0000 (20:32 +0900)]
PCI: dwc: endpoint: Implement the pci_epc_ops::align_addr() operation
The function dw_pcie_prog_outbound_atu() used to program outbound ATU
entries for mapping RC PCI addresses to local CPU addresses does not
allow PCI addresses that are not aligned to the value of region_align
of struct dw_pcie. This value is determined from the iATU hardware
registers during probing of the iATU (done by dw_pcie_iatu_detect()).
This value is thus valid for all DWC PCIe controllers, and valid
regardless of the hardware configuration used when synthesizing the
DWC PCIe controller.
Implement the ->align_addr() endpoint controller operation to allow
this mapping alignment to be transparently handled by endpoint function
drivers through the function pci_epc_mem_map().
Link: https://lore.kernel.org/linux-pci/20241012113246.95634-7-dlemoal@kernel.org
Link: https://lore.kernel.org/linux-pci/20241015090712.112674-1-dlemoal@kernel.org
Link: https://lore.kernel.org/linux-pci/20241017132052.4014605-5-cassel@kernel.org
Co-developed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
[mani: squashed the patch that changed phy_addr_t to u64]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: squashed patch that updated the pci_size variable]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Dmitry Baryshkov [Thu, 17 Oct 2024 18:04:47 +0000 (21:04 +0300)]
dt-bindings: PCI: qcom,pcie-sm8550: Add SAR2130P compatible
On the Qualcomm SAR2130P platform the PCIe host is compatible with the
DWC controller present on the SM8550 platorm, just using one additional
clock.
Link: https://lore.kernel.org/r/20241017-sar2130p-pci-v1-1-5b95e63d9624@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Lukas Wunner [Thu, 10 Oct 2024 17:10:34 +0000 (19:10 +0200)]
PCI: Fix use-after-free of slot->bus on hot remove
Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.
Since commit
0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and
commit
59a54c5f3dbd ("thunderbolt: Reset topology created by the boot
firmware"), USB4 v2 and v1 Host Routers are reset on probe of the
thunderbolt driver.
The reset clears the Presence Detect State and Data Link Layer Link Active
bits at the USB4 Host Router's Root Port and thus causes hot removal of the
dock.
The crash occurs when pciehp is unbound from one of the dock's Downstream
Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The
pci_slot contains a pointer to the pci_bus below the Downstream Port, but
a reference on that pci_bus is never acquired. The pci_bus is destroyed
before the pci_slot, so a use-after-free ensues when pci_slot_release()
accesses slot->bus.
In principle this should not happen because pci_stop_bus_device() unbinds
pciehp (and therefore destroys the pci_slot) before the pci_bus is
destroyed by pci_remove_bus_device().
However the stacktrace provided by Dennis shows that pciehp is unbound from
pci_remove_bus_device() instead of pci_stop_bus_device(). To understand
the significance of this, one needs to know that the PCI core uses a two
step process to remove a portion of the hierarchy: It first unbinds all
drivers in the sub-hierarchy in pci_stop_bus_device() and then actually
removes the devices in pci_remove_bus_device(). There is no precaution to
prevent driver binding in-between pci_stop_bus_device() and
pci_remove_bus_device().
In Dennis' case, it seems removal of the hierarchy by pciehp races with
driver binding by pci_bus_add_devices(). pciehp is bound to the
Downstream Port after pci_stop_bus_device() has run, so it is unbound by
pci_remove_bus_device() instead of pci_stop_bus_device(). Because the
pci_bus has already been destroyed at that point, accesses to it result in
a use-after-free.
One might conclude that driver binding needs to be prevented after
pci_stop_bus_device() has run. However it seems risky that pci_slot points
to pci_bus without holding a reference. Solely relying on correct ordering
of driver unbind versus pci_bus destruction is certainly not defensive
programming.
If pci_slot has a need to access data in pci_bus, it ought to acquire a
reference. Amend pci_create_slot() accordingly. Dennis reports that the
crash is not reproducible with this change.
Abridged stacktrace:
pcieport 0000:00:07.0: PME: Signaling with IRQ 156
pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
pci_bus 0000:20: dev 00, created physical slot 12
pcieport 0000:00:07.0: pciehp: Slot(12): Card not present
...
pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1
RIP: 0010:dev_driver_string+0x12/0x40
pci_destroy_slot
pciehp_remove
pcie_port_remove_service
device_release_driver_internal
bus_remove_device
device_del
device_unregister
remove_iter
device_for_each_child
pcie_portdrv_remove
pci_device_remove
device_release_driver_internal
bus_remove_device
device_del
pci_remove_bus_device (recursive invocation)
pci_remove_bus_device
pciehp_unconfigure_device
pciehp_disable_slot
pciehp_handle_presence_or_link_change
pciehp_ist
Link: https://lore.kernel.org/r/4bfd4c0e976c1776cd08e76603903b338cf25729.1728579288.git.lukas@wunner.de
Reported-by: Dennis Wassenberg <Dennis.Wassenberg@secunet.com>
Closes: https://lore.kernel.org/r/
6de4b45ff2b32dd91a805ec02ec8ec73ef411bf6.camel@secunet.com/
Tested-by: Dennis Wassenberg <Dennis.Wassenberg@secunet.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org
Philipp Stanner [Wed, 16 Oct 2024 09:49:04 +0000 (11:49 +0200)]
PCI: Make pcim_iounmap_region() a public function
The function pcim_iounmap_regions() is problematic because it uses a
bitmask mechanism to release / iounmap multiple BARs at once. It, thus,
prevents getting rid of the problematic iomap table mechanism which was
deprecated in commit
e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()").
pcim_iounmap_region() does not have that problem. Make it public as the
successor of pcim_iounmap_regions().
Link: https://lore.kernel.org/r/20241016094911.24818-3-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Philipp Stanner [Wed, 30 Oct 2024 11:27:43 +0000 (12:27 +0100)]
PCI: Remove pcim_iomap_regions_request_all()
pcim_iomap_regions_request_all() have been deprecated in
commit
e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(),
pcim_iomap_regions_request_all()").
All users of this function have been ported to other interfaces by now.
Remove pcim_iomap_regions_request_all().
Link: https://lore.kernel.org/r/20241030112743.104395-11-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Philipp Stanner [Wed, 30 Oct 2024 11:27:42 +0000 (12:27 +0100)]
ALSA: korg1212: Replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-10-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Philipp Stanner [Wed, 30 Oct 2024 11:27:41 +0000 (12:27 +0100)]
serial: rp2: Replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-9-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Philipp Stanner [Wed, 30 Oct 2024 11:27:40 +0000 (12:27 +0100)]
ntb: idt: Replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-8-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Philipp Stanner [Wed, 30 Oct 2024 11:27:39 +0000 (12:27 +0100)]
wifi: iwlwifi: replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-7-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kalle Valo <kvalo@kernel.org>
Philipp Stanner [Wed, 30 Oct 2024 11:27:38 +0000 (12:27 +0100)]
intel_th: pci: Replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-6-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Philipp Stanner [Wed, 30 Oct 2024 11:27:37 +0000 (12:27 +0100)]
crypto: marvell - replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-5-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Bharat Bhushan <bbhushan2@marvell.com>
Philipp Stanner [Wed, 30 Oct 2024 11:27:36 +0000 (12:27 +0100)]
crypto: qat - replace deprecated PCI functions
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-4-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Philipp Stanner [Wed, 30 Oct 2024 11:27:35 +0000 (12:27 +0100)]
ata: ahci: Replace deprecated PCI functions
pcim_iomap_regions_request_all() and pcim_iomap_table() have been
deprecated by the PCI subsystem in commit
e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-3-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Damien Le Moal <dlemoal@kernel.org>
Philipp Stanner [Wed, 30 Oct 2024 11:27:34 +0000 (12:27 +0100)]
PCI: Make pcim_request_all_regions() a public function
In order to remove the deprecated function
pcim_iomap_regions_request_all(), a few drivers need an interface to
request all BARs a PCI device offers.
Make pcim_request_all_regions() a public interface.
Link: https://lore.kernel.org/r/20241030112743.104395-2-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:48 +0000 (17:47 +0300)]
PCI: Protect Link Control 2 Register with RMW locking
The PCIe Bandwidth Controller performs RMW accesses the Link Control 2
Register which can occur concurrently to other sources of Link Control 2
Register writes. Therefore, add Link Control 2 Register among the PCI
Express Capability Registers that need RMW locking.
Link: https://lore.kernel.org/r/20241018144755.7875-3-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: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 18 Oct 2024 14:47:47 +0000 (17:47 +0300)]
Documentation PCI: Reformat RMW ops documentation
Extract the list of RMW protected PCIe Capability registers into a
bullet list to make them easier to pick up on a glance. An upcoming
change is going to add one more register among them so it will be much
cleaner to have them as bullets.
Link: https://lore.kernel.org/r/20241018144755.7875-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: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ajay Agarwal [Mon, 7 Oct 2024 03:29:17 +0000 (08:59 +0530)]
PCI/ASPM: Disable L1 before disabling L1 PM Substates
PCIe r6.2, sec 5.5.4, requires that:
If setting either or both of the enable bits for ASPM L1 PM Substates,
both ports must be configured as described in this section while ASPM L1
is disabled.
Previously, pcie_config_aspm_l1ss() assumed that "setting enable bits"
meant "setting them to 1", and it configured L1SS as follows:
- Clear L1SS enable bits
- Disable L1
- Configure L1SS enable bits as required
- Enable L1 if required
With this sequence, when disabling L1SS on an ARM A-core with a Synopsys
DesignWare PCIe core, the CPU occasionally hangs when reading
PCI_L1SS_CTL1, leading to a reboot when the CPU watchdog expires.
Move the L1 disable to the caller (pcie_config_aspm_link(), where L1 was
already enabled) so L1 is always disabled while updating the L1SS bits:
- Disable L1
- Clear L1SS enable bits
- Configure L1SS enable bits as required
- Enable L1 if required
Change pcie_aspm_cap_init() similarly.
Link: https://lore.kernel.org/r/20241007032917.872262-1-ajayagarwal@google.com
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
[bhelgaas: comments, commit log, compute L1SS setting before config access]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Ilpo Järvinen [Tue, 22 Oct 2024 09:11:40 +0000 (12:11 +0300)]
PCI: cpqphp: Simplify PCI_ScanBusForNonBridge()
PCI_ScanBusForNonBridge() has two loops, one to search for non-bridges and
a second to look for bridges. The second loop has hints in a debug print it
should do recursion for buses underneath the bridge, but no recursion is
attempted.
Since the second loop is quite useless in its current form, just eliminate
it. This code hasn't been touched for very long time so either it's unused
or the missing parts are not important enough for anyone to attempt to add
them.
Leave only a warning print and comment about the missing recursion for the
unlikely case that somebody comes across the lack of functionality. In any
case, search whether an endpoint exists downstream of a bridge sounds
generic enough to belong to core so if the functionality is to be extended
it should probably be moved into PCI core.
Link: https://lore.kernel.org/r/20241022091140.3504-5-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Ilpo Järvinen [Tue, 22 Oct 2024 09:11:39 +0000 (12:11 +0300)]
PCI: cpqphp: Use define to read class/revision dword
Replace literal 0x08 with PCI_CLASS_REVISION.
Link: https://lore.kernel.org/r/20241022091140.3504-4-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Ilpo Järvinen [Tue, 22 Oct 2024 09:11:38 +0000 (12:11 +0300)]
PCI: cpqphp: Use pci_bus_read_dev_vendor_id() to detect presence
The intent of the first part in PCI_RefinedAccessConfig() is to read Vendor
ID register and detect presence of the device that way.
Remove PCI_RefinedAccessConfig() (which was not named very helpfully to
begin with) and replace the call with pci_bus_read_dev_vendor_id() + read
config because it makes the logic more obvious at the caller side.
Link: https://lore.kernel.org/r/20241022091140.3504-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Ilpo Järvinen [Tue, 22 Oct 2024 09:11:37 +0000 (12:11 +0300)]
PCI: cpqphp: Fix PCIBIOS_* return value confusion
Code in and related to PCI_RefinedAccessConfig() has three types of return
type confusion:
- PCI_RefinedAccessConfig() tests pci_bus_read_config_dword() return value
against -1.
- PCI_RefinedAccessConfig() returns both -1 and PCIBIOS_* return codes.
- Callers of PCI_RefinedAccessConfig() only test for -1.
Make PCI_RefinedAccessConfig() return PCIBIOS_* codes consistently and
adapt callers accordingly.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/r/20241022091140.3504-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>
Wei Huang [Wed, 2 Oct 2024 16:59:52 +0000 (11:59 -0500)]
PCI/TPH: Add TPH documentation
Add a document for the TPH feature, including description of "notph" kernel
parameter and the API interface.
Co-developed-by: Eric Van Tassell <Eric.VanTassell@amd.com>
Link: https://lore.kernel.org/r/20241002165954.128085-4-wei.huang2@amd.com
Signed-off-by: Eric Van Tassell <Eric.VanTassell@amd.com>
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
Ilpo Järvinen [Thu, 17 Oct 2024 09:55:45 +0000 (12:55 +0300)]
PCI: Improve pdev_sort_resources() warning message
Use pci_resource_name() helper in pdev_sort_resources() to print resources
in user-friendly format. Also replace the vague "bogus alignment" with a
more precise explanation of the problem.
Link: https://lore.kernel.org/r/20241017095545.1424-1-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: Philipp Stanner <pstanner@redhat.com>
Christophe JAILLET [Sat, 12 Oct 2024 19:53:42 +0000 (21:53 +0200)]
PCI: cpqphp: Remove unused struct ctrl_dbg.ctrl
'ctrl' is unused; remove it to save a few bytes when the structure is
allocated.
Link: https://lore.kernel.org/r/551d0cdaabcf69fcd09a565475c428e09c61e1a3.1728762751.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Guilherme Giacomo Simoes [Mon, 14 Oct 2024 13:19:17 +0000 (10:19 -0300)]
PCI: cpcihp: Remove unused struct cpci_hp_controller_ops.hardware_test
The 'hardware_test' field in struct cpci_hp_controller_ops is unused;
remove it to reduce resource consumption.
Link: https://lore.kernel.org/r/20241014131917.324667-1-trintaeoitogc@gmail.com
Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
[bhelgas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Ilpo Järvinen [Thu, 17 Oct 2024 14:11:10 +0000 (17:11 +0300)]
PCI: Simplify pci_read_bridge_bases() logic
Use reverse logic combined with return and continue to significantly
reduce indentation level in pci_read_bridge_bases().
Link: https://lore.kernel.org/r/20241017141111.44612-3-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Thu, 17 Oct 2024 14:11:09 +0000 (17:11 +0300)]
PCI: Move struct pci_bus_resource into bus.c
The struct pci_bus_resource is only used in bus.c, so move it there.
Link: https://lore.kernel.org/r/20241017141111.44612-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Thu, 17 Oct 2024 14:11:08 +0000 (17:11 +0300)]
PCI: Remove unused PCI_SUBTRACTIVE_DECODE
2fe2abf896c1 ("PCI: augment bus resource table with a list") added
PCI_SUBTRACTIVE_DECODE which is put into the struct pci_bus_resource flags
field but is never read. There seems to never have been users for it.
Remove both PCI_SUBTRACTIVE_DECODE and the flags field from the struct
pci_bus_resource.
Link: https://lore.kernel.org/r/20241017141111.44612-1-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Damien Le Moal [Sat, 12 Oct 2024 11:32:45 +0000 (20:32 +0900)]
PCI: endpoint: test: Use pci_epc_mem_map/unmap()
Modify the endpoint test driver to use the functions pci_epc_mem_map()
and pci_epc_mem_unmap() for the read, write and copy tests. For each
test case, the transfer (dma or mmio) are executed in a loop to ensure
that potentially partial mappings returned by pci_epc_mem_map() are
correctly handled.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20241012113246.95634-6-dlemoal@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Damien Le Moal [Sat, 12 Oct 2024 11:32:44 +0000 (20:32 +0900)]
PCI: endpoint: Update documentation
Document the new functions pci_epc_mem_map() and pci_epc_mem_unmap().
Also add the documentation for the functions pci_epc_map_addr() and
pci_epc_unmap_addr() that were missing.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20241012113246.95634-5-dlemoal@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Damien Le Moal [Sat, 12 Oct 2024 11:32:43 +0000 (20:32 +0900)]
PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
Some endpoint controllers have requirements on the alignment of the
controller physical memory address that must be used to map a RC PCI
address region. For instance, the endpoint controller of the RK3399 SoC
uses at most the lower 20 bits of a physical memory address region as
the lower bits of a RC PCI address region. For mapping a PCI address
region of size bytes starting from pci_addr, the exact number of
address bits used is the number of address bits changing in the address
range [pci_addr..pci_addr + size - 1]. For this example, this creates
the following constraints:
1) The offset into the controller physical memory allocated for a
mapping depends on the mapping size *and* the starting PCI address
for the mapping.
2) A mapping size cannot exceed the controller windows size (1MB) minus
the offset needed into the allocated physical memory, which can end
up being a smaller size than the desired mapping size.
Handling these constraints independently of the controller being used
in an endpoint function driver is not possible with the current EPC
API as only the ->align field in struct pci_epc_features is provided
but used for BAR (inbound ATU mappings) mapping only. A new API is
needed for function drivers to discover mapping constraints and handle
non-static requirements based on the RC PCI address range to access.
Introduce the endpoint controller operation ->align_addr() to allow
the EPC core functions to obtain the size and the offset into a
controller address region that must be allocated and mapped to access
a RC PCI address region. The size of the mapping provided by the
align_addr() operation can then be used as the size argument for the
function pci_epc_mem_alloc_addr() and the offset into the allocated
controller memory provided can be used to correctly handle data
transfers. For endpoint controllers that have PCI address alignment
constraints, the align_addr() operation may indicate upon return an
effective PCI address mapping size that is smaller (but not 0) than the
requested PCI address region size.
The controller ->align_addr() operation is optional: controllers that
do not have any alignment constraints for mapping RC PCI address regions
do not need to implement this operation. For such controllers, it is
always assumed that the mapping size is equal to the requested size of
the PCI region and that the mapping offset is 0.
The function pci_epc_mem_map() is introduced to use this new controller
operation (if it is defined) to handle controller memory allocation and
mapping to a RC PCI address region in endpoint function drivers.
This function first uses the ->align_addr() controller operation to
determine the controller memory address size (and offset into) needed
for mapping an RC PCI address region. The result of this operation is
used to allocate a controller physical memory region using
pci_epc_mem_alloc_addr() and then to map that memory to the RC PCI
address space with pci_epc_map_addr().
Since ->align_addr() () may indicate that not all of a RC PCI address
region can be mapped, pci_epc_mem_map() may only partially map the RC
PCI address region specified. It is the responsibility of the caller
(an endpoint function driver) to handle such smaller mapping by
repeatedly using pci_epc_mem_map() over the desried PCI address range.
The counterpart of pci_epc_mem_map() to unmap and free a mapped
controller memory address region is pci_epc_mem_unmap().
Both functions operate using the new struct pci_epc_map data structure.
This new structure represents a mapping PCI address, mapping effective
size, the size of the controller memory needed for the mapping as well
as the physical and virtual CPU addresses of the mapping (phys_base and
virt_base fields). For convenience, the physical and virtual CPU
addresses within that mapping to use to access the target RC PCI address
region are also provided (phys_addr and virt_addr fields).
Endpoint function drivers can use struct pci_epc_map to access the
mapped RC PCI address region using the ->virt_addr and ->pci_size
fields.
Co-developed-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20241012113246.95634-4-dlemoal@kernel.org
[mani: squashed the patch that changed phy_addr_t to u64]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Gregory Price [Fri, 4 Oct 2024 16:28:28 +0000 (12:28 -0400)]
PCI/DOE: Poll DOE Busy bit for up to 1 second in pci_doe_send_req()
During initial device probe, the PCI DOE busy bit for some CXL devices may
be left set for a longer period than expected by the current driver logic.
Despite local comments stating DOE Busy is unlikely to be detected, it
appears commonly specifically during boot when CXL devices are being
probed.
The symptom was messages like this:
endpoint6: DOE failed -EBUSY
produced by cxl_cdat_get_length() or cxl_cdat_read_table().
This was observed on a single socket AMD platform with 2 CXL memory
expanders attached to the single socket. It was not the case that
concurrent accesses were being made, as validated by monitoring mailbox
commands on the device side.
This behavior has been observed with multiple CXL memory expanders from
different vendors - so it appears unrelated to the model.
In all observed tests, only a small period of the retry window is actually
used - typically only a handful of loop iterations.
Polling on the PCI DOE Busy Bit for (at max) one PCI DOE timeout interval
(1 second), resolves this issue cleanly.
Per PCIe r6.2 sec 6.30.3, the DOE Busy Bit being cleared does not raise an
interrupt, so polling is the best option in this scenario.
Subsequent code in doe_statemachine_work() and abort paths also wait for up
to 1 PCI DOE timeout interval, so this order of (potential) additional
delay is presumed acceptable.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/20241004162828.314-1-gourry@gourry.net
Signed-off-by: Gregory Price <gourry@gourry.net>
[bhelgaas: fix nits and add error message to commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Damien Le Moal [Sat, 12 Oct 2024 11:32:42 +0000 (20:32 +0900)]
PCI: endpoint: Improve pci_epc_mem_alloc_addr()
There is no point in attempting to allocate memory from an endpoint
controller memory window if the requested size is larger than the memory
window size. Add a check to skip bitmap_find_free_region() calls for
such case. This check can be done without the mem->lock mutex held as
memory window sizes are constant and never modified at runtime.
Also change the final return to return NULL to simplify the code.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20241012113246.95634-3-dlemoal@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Damien Le Moal [Sat, 12 Oct 2024 11:32:41 +0000 (20:32 +0900)]
PCI: endpoint: Introduce pci_epc_function_is_valid()
Introduce the epc core helper function pci_epc_function_is_valid() to
verify that an epc pointer, a physical function number and a virtual
function number are all valid. This avoids repeating the code pattern:
if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
return err;
if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
return err;
in many functions of the endpoint controller core code.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20241012113246.95634-2-dlemoal@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Ilpo Järvinen [Fri, 14 Jun 2024 10:06:06 +0000 (13:06 +0300)]
PCI: Add ALIGN_DOWN_IF_NONZERO() helper
pci_bus_distribute_available_resources() performs alignment in case of
non-zero alignment requirement on three occasions.
Add ALIGN_DOWN_IF_NONZERO() helper to avoid coding the non-zero check three
times.
Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240614100606.15830-5-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 14 Jun 2024 10:06:05 +0000 (13:06 +0300)]
PCI: Use align and resource helpers, and SZ_* in quirk_s3_64M()
Use IS_ALIGNED(), resource_size(), and SZ_* defines in quirk_s3_64M().
Link: https://lore.kernel.org/r/20240614100606.15830-4-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 14 Jun 2024 10:06:04 +0000 (13:06 +0300)]
PCI: Use resource_set_{range,size}() helpers
Convert open-coded resource size calculations to use
resource_set_{range,size}() helpers.
While at it, use SZ_* for size parameter where appropriate which makes the
intent of code more obvious.
Also, cast sizes to resource_size_t, not u64.
Link: https://lore.kernel.org/r/20240614100606.15830-3-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ilpo Järvinen [Fri, 14 Jun 2024 10:06:03 +0000 (13:06 +0300)]
resource: Add resource set range and size helpers
Setting the end address for a resource with a given size lacks a helper and
is therefore coded manually unlike the getter side which has a helper for
resource size calculation. Also, almost all callsites that calculate the
end address for a resource also set the start address right before it like
this:
res->start = start_addr;
res->end = res->start + size - 1;
Add resource_set_range(res, start_addr, size) that sets the start address
and calculates the end address to simplify this often repeated fragment.
Also add resource_set_size() for the cases where setting the start address
of the resource is not necessary but mention in its kerneldoc that
resource_set_range() is preferred when setting both addresses.
Link: https://lore.kernel.org/r/20240614100606.15830-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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Sergio Paracuellos [Fri, 27 Sep 2024 09:24:49 +0000 (11:24 +0200)]
PCI: acpiphp_ampere_altra: Switch back to struct platform_driver::remove()
After commit
0edb555a65d1 ("platform: Make platform_driver::remove() return
void") .remove() is (again) the right callback to implement for platform
drivers.
Convert all PCI controller drivers to use .remove(), with the eventual goal
to drop struct platform_driver::remove_new(). As .remove() and
.remove_new() have the same prototypes, conversion is done by just changing
the structure member name in the driver initializer.
Link: https://lore.kernel.org/r/20240927092449.44628-1-sergio.paracuellos@gmail.com
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Sergio Paracuellos [Mon, 23 Sep 2024 06:57:06 +0000 (08:57 +0200)]
PCI: controller: Switch back to struct platform_driver::remove()
After commit
0edb555a65d1 ("platform: Make platform_driver::remove() return
void") .remove() is (again) the right callback to implement for platform
drivers.
Convert all PCI controller drivers to use .remove(), with the eventual goal
to drop struct platform_driver::remove_new(). As .remove() and .remove_new()
have the same prototypes, conversion is done by just changing the structure
member name in the driver initializer.
Link: https://lore.kernel.org/r/20240923065706.728769-1-sergio.paracuellos@gmail.com
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
[bhelgaas: add pcie-xilinx-nwl.c and tidy whitespace per Uwe Kleine-König:
https://lore.kernel.org/r/tdxrmmqyzcufupnwkdbg7lwgadizm7v3lxjirykijbml7x54ze@upbdzycdsilm]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>