summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2024-07-12PCI: Extend ACS configurabilityVidya Sagar
PCIe ACS settings control the level of isolation and the possible P2P paths between devices. With greater isolation the kernel will create smaller iommu_groups and with less isolation there is more HW that can achieve P2P transfers. From a virtualization perspective all devices in the same iommu_group must be assigned to the same VM as they lack security isolation. There is no way for the kernel to automatically know the correct ACS settings for any given system and workload. Existing command line options (e.g., disable_acs_redir) allow only for large scale change, disabling all isolation, but this is not sufficient for more complex cases. Add a kernel command-line option 'config_acs' to directly control all the ACS bits for specific devices, which allows the operator to setup the right level of isolation to achieve the desired P2P configuration. The definition is future proof; when new ACS bits are added to the spec the open syntax can be extended. ACS needs to be setup early in the kernel boot as the ACS settings affect how iommu_groups are formed. iommu_group formation is a one time event during initial device discovery, so changing ACS bits after kernel boot can result in an inaccurate view of the iommu_groups compared to the current isolation configuration. ACS applies to PCIe Downstream Ports and multi-function devices. The default ACS settings are strict and deny any direct traffic between two functions. This results in the smallest iommu_group the HW can support. Frequently these values result in slow or non-working P2PDMA. ACS offers a range of security choices controlling how traffic is allowed to go directly between two devices. Some popular choices: - Full prevention - Translated requests can be direct, with various options - Asymmetric direct traffic, A can reach B but not the reverse - All traffic can be direct Along with some other less common ones for special topologies. The intention is that this option would be used with expert knowledge of the HW capability and workload to achieve the desired configuration. Link: https://lore.kernel.org/r/20240625153150.159310-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [bhelgaas: add example, tidy printk formats] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-12PCI: Add missing bridge lock to pci_bus_lock()Dan Williams
One of the true positives that the cfg_access_lock lockdep effort identified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: <TASK> ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120 Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything *but* the bridge itself. For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge); to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock(). Link: https://lore.kernel.org/r/171711747501.1628941.15217746952476635316.stgit@dwillia2-xfh.jf.intel.com Reported-by: Imre Deak <imre.deak@intel.com> Closes: http://lore.kernel.org/r/6657833b3b5ae_14984b29437@dwillia2-xfh.jf.intel.com.notmuch Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Keith Busch <kbusch@kernel.org> [bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Kalle Valo <kvalo@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
2024-07-11PCI: Add managed pcim_iomap_range()Philipp Stanner
The only managed mapping function currently is pcim_iomap() which doesn't allow for mapping an area starting at a certain offset, which many drivers want. Add pcim_iomap_range() as an exported function. Link: https://lore.kernel.org/r/20240613115032.29098-13-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-11PCI: Remove legacy pcim_release()Philipp Stanner
Thanks to preceding cleanup steps, pcim_release() is now not needed anymore and can be replaced by pcim_disable_device(), which is the exact counterpart to pcim_enable_device(). This permits removing further parts of the old PCI devres implementation. Replace pcim_release() with pcim_disable_device(). Remove the now unused function get_pci_dr(). Remove the struct pci_devres from pci.h. Link: https://lore.kernel.org/r/20240613115032.29098-12-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-11PCI: Add managed pcim_intx()Philipp Stanner
pci_intx() is a "hybrid" function, i.e., it is managed if pcim_enable_device() has been called, but unmanaged otherwise. Add pcim_intx(), which is always managed, and implement pci_intx() using it. Remove the now-unused struct pci_devres.orig_intx and .restore_intx and find_pci_dr(). Link: https://lore.kernel.org/r/20240613115032.29098-11-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> [kwilczynski: squashed in https://lore.kernel.org/r/426645d40776198e0fcc942f4a6cac4433c7a9aa.camel@redhat.com to fix problem reported and tested by Ashish Kalra <Ashish.Kalra@amd.com>: https://lore.kernel.org/r/20240708214656.4721-1-Ashish.Kalra@amd.com https://lore.kernel.org/r/8c4634e9-4f02-4c54-9c89-d75e2f4bf026@amd.com/] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: vmd: Create domain symlink before pci_bus_add_devices()Jiwei Sun
The vmd driver creates a "domain" symlink in sysfs for each VMD bridge. Previously this symlink was created after pci_bus_add_devices() added devices below the VMD bridge and emitted udev events to announce them to userspace. This led to a race between userspace consumers of the udev events and the kernel creation of the symlink. One such consumer is mdadm, which assembles block devices into a RAID array, and for devices below a VMD bridge, mdadm depends on the "domain" symlink. If mdadm loses the race, it may be unable to assemble a RAID array, which may cause a boot failure or other issues, with complaints like this: (udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: Unable to get real path for '/sys/bus/pci/drivers/vmd/0000:c7:00.5/domain/device'' (udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: /dev/nvme1n1 is not attached to Intel(R) RAID controller.' (udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: No OROM/EFI properties for /dev/nvme1n1' (udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: no RAID superblock on /dev/nvme1n1.' (udev-worker)[2149]: nvme1n1: Process '/sbin/mdadm -I /dev/nvme1n1' failed with exit code 1. This symptom prevents the OS from booting successfully. After a NVMe disk is probed/added by the nvme driver, udevd invokes mdadm to detect if there is a mdraid associated with this NVMe disk, and mdadm determines if a NVMe device is connected to a particular VMD domain by checking the "domain" symlink. For example: Thread A Thread B Thread mdadm vmd_enable_domain pci_bus_add_devices __driver_probe_device ... work_on_cpu schedule_work_on : wakeup Thread B nvme_probe : wakeup scan_work to scan nvme disk and add nvme disk then wakeup udevd : udevd executes mdadm command flush_work main : wait for nvme_probe done ... __driver_probe_device find_driver_devices : probe next nvme device : 1) Detect domain symlink ... 2) Find domain symlink ... from vmd sysfs ... 3) Domain symlink not ... created yet; failed sysfs_create_link : create domain symlink Create the VMD "domain" symlink before invoking pci_bus_add_devices() to avoid this race. Suggested-by: Adrian Huang <ahuang12@lenovo.com> Link: https://lore.kernel.org/linux-pci/20240605124844.24293-1-sjiwei@163.com Signed-off-by: Jiwei Sun <sunjw10@lenovo.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Nirmal Patel <nirmal.patel@linux.intel.com>
2024-07-10PCI: qcom: Prevent use of uninitialized data in qcom_pcie_suspend_noirq()Dan Carpenter
Smatch complains that "ret" could be uninitialized if "pcie->icc_mem" is NULL and "pm_suspend_target_state == PM_SUSPEND_MEM". Silence this warning by initializing ret to zero. Fixes: 78b5f6f8855e ("PCI: qcom: Add OPP support to scale performance") Link: https://lore.kernel.org/linux-pci/20240708180539.1447307-4-dan.carpenter@linaro.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-10PCI: qcom: Prevent potential error pointer dereferenceDan Carpenter
Only call dev_pm_opp_put() if dev_pm_opp_find_freq_exact() succeeds; otherwise it leads to an error pointer dereference. Fixes: 78b5f6f8855e ("PCI: qcom: Add OPP support to scale performance") Link: https://lore.kernel.org/linux-pci/20240708180539.1447307-3-dan.carpenter@linaro.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-10PCI: qcom: Fix missing error code in qcom_pcie_probe()Dan Carpenter
Return a negative error code if dev_pm_opp_find_freq_floor() fails; don't return success. Fixes: 78b5f6f8855e ("PCI: qcom: Add OPP support to scale performance") Link: https://lore.kernel.org/linux-pci/20240708180539.1447307-2-dan.carpenter@linaro.org Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-10PCI: Give pcim_set_mwi() its own devres cleanup callbackPhilipp Stanner
Managing pci_set_mwi() with devres can easily be done with its own callback, without the necessity to store any state about it in a device-related struct. Remove the MWI state from struct pci_devres. Give pcim_set_mwi() a separate devres cleanup callback. Link: https://lore.kernel.org/r/20240613115032.29098-10-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Move struct pci_devres.pinned bit to struct pci_devPhilipp Stanner
The bit describing whether the PCI device is currently pinned is stored in struct pci_devres. To clean up and simplify the PCI devres API, it's better if this information is stored in struct pci_dev. This will later permit simplifying pcim_enable_device(). Move the 'pinned' boolean bit to struct pci_dev. Restructure bits in struct pci_dev so the pm / pme fields are next to each other. Link: https://lore.kernel.org/r/20240613115032.29098-9-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Remove struct pci_devres.enabled status bitPhilipp Stanner
The struct pci_devres has a separate boolean to track whether a device is enabled. That, however, can easily be tracked in an agnostic manner through the function pci_is_enabled(). Using it allows for simplifying the PCI devres implementation. Replace the separate 'enabled' status bit from struct pci_devres with calls to pci_is_enabled() at the appropriate places. Link: https://lore.kernel.org/r/20240613115032.29098-8-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Document hybrid devres hazardsPhilipp Stanner
These functions: pci_request_region() pci_request_regions() pci_request_regions_exclusive() pci_request_selected_regions() pci_request_selected_regions_exclusive() pci_intx() are "hybrid" functions that are managed if pcim_enable_device() has been called, but unmanaged otherwise. This is confusing and has already caused a bug (in 8558de401b5f ("drm/vboxvideo: use managed pci functions")) because users believe all PCI functions, such as pci_iomap_range(), can become managed that way, which is not the case. Add comments to the relevant functions' docstrings that warn users about this behavior. Link: https://lore.kernel.org/r/20240613115032.29098-7-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Add managed pcim_request_region()Philipp Stanner
These existing functions: pci_request_region() pci_request_selected_regions() pci_request_selected_regions_exclusive() are "hybrid" functions built on __pci_request_region() and are managed if pcim_enable_device() has been called, but unmanaged otherwise. Add these new functions: pcim_request_region() pcim_request_region_exclusive() These are *always* managed and use the new pcim_addr_devres tracking infrastructure instead of find_pci_dr() and struct pci_devres.region_mask. Implement the hybrid functions using the new "pure" functions and remove struct pci_devres.region_mask, which is no longer needed. Link: https://lore.kernel.org/r/20240613115032.29098-6-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()Philipp Stanner
Deprecate pcim_iomap_table(). It returns a pointer to a table of ioremapped BARs, or NULL if it fails. This makes uses like this: addr = pcim_iomap_table(pdev)[0]; problematic because it causes a NULL pointer dereference on failure. Callers should use pcim_iomap() instead. Deprecate pcim_iomap_regions_request_all() because it is built on __pci_request_region() and is managed if pcim_enable_device() has been called, but unmanaged otherwise, which is prone to errors. Callers should either use pcim_iomap_regions() to request and map BARs, or use pcim_request_region() followed by pcim_iomap(). Link: https://lore.kernel.org/r/20240613115032.29098-5-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log, sphinx markup] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Add managed partial-BAR request and map infrastructurePhilipp Stanner
The pcim_iomap_devres table tracks entire-BAR mappings, so we can't use it to build a managed version of pci_iomap_range(), which maps partial BARs. Add struct pcim_addr_devres, which can track request and mapping of both entire BARs and partial BARs. Add the following internal devres functions based on struct pcim_addr_devres: pcim_iomap_region() # request & map entire BAR pcim_iounmap_region() # unmap & release entire BAR pcim_request_region() # request entire BAR pcim_release_region() # release entire BAR pcim_request_all_regions() # request all entire BARs pcim_release_all_regions() # release all entire BARs Rework the following public interfaces using the new infrastructure listed above: pcim_iomap() # map partial BAR pcim_iounmap() # unmap partial BAR pcim_iomap_regions() # request & map specified BARs pcim_iomap_regions_request_all() # request all BARs, map specified BARs pcim_iounmap_regions() # unmap & release specified BARs Link: https://lore.kernel.org/r/20240613115032.29098-4-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Add devres helpers for iomap tablePhilipp Stanner
The pcim_iomap_devres.table administrated by pcim_iomap_table() has its entries set and unset at several places throughout devres.c using manual iterations which are effectively code duplications. Add pcim_add_mapping_to_legacy_table() and pcim_remove_mapping_from_legacy_table() helper functions and use them where possible. Link: https://lore.kernel.org/r/20240613115032.29098-3-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-10PCI: Add and use devres helper for bit masksPhilipp Stanner
The current devres implementation uses manual shift operations to check whether a bit in a mask is set. The code can be made more readable by writing a small helper function for that. Implement mask_contains_bar() and use it where applicable. Link: https://lore.kernel.org/r/20240613115032.29098-2-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-09PCI: dw-rockchip: Use pci_epc_init_notify() directlyNiklas Cassel
A previous commit ("PCI: dwc: ep: Remove dw_pcie_ep_init_notify() wrapper") removed the dw_pcie_ep_init_notify() wrapper and changed the DWC glue drivers to instead use pci_epc_init_notify() directly. The endpoint support for the dw-rockchip had not been merged at that point in time, so the previous commit wrapper") did not update dw-rockchip. Do the same change for dw-rockchip, so that the driver will not try to use a function that has now been removed. Link: https://lore.kernel.org/linux-pci/20240622132024.2927799-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2024-07-09PCI: dw-rockchip: Add endpoint mode supportNiklas Cassel
The PCIe controller in rk3568 and rk3588 can operate in endpoint mode. This endpoint mode support heavily leverages the existing code in pcie-designware-ep.c. Add support for endpoint mode to the existing pcie-dw-rockchip glue driver. [kwilczynski: squash with patch adding the PCI_ENDPOINT dependency] Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-10-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dw-rockchip: Refactor the driver to prepare for EP modeNiklas Cassel
Refactor the driver to prepare for EP mode. Add of-match data to the existing compatible, and explicitly define it as DW_PCIE_RC_TYPE. This way, we will be able to add EP mode in a follow-up commit in a much less intrusive way, which makes the follow-up commit much easier to review. No functional change intended. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-9-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dw-rockchip: Add rockchip_pcie_get_ltssm() helperNiklas Cassel
Add a rockchip_pcie_ltssm() helper function that reads the LTSSM status. This helper will be used in additional places in follow-up commits. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-8-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dw-rockchip: Fix weird indentationNiklas Cassel
Fix the indentation of rockchip_pcie_{readl,writel}_apb() parameters to match the opening parenthesis. Link: https://lore.kernel.org/linux-pci/20240607-rockchip-pcie-ep-v1-v5-7-0a042d6b0049@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dw-rockchip: Fix initial PERST# GPIO valueNiklas Cassel
PERST# is active low according to the PCIe specification. However, the existing pcie-dw-rockchip.c driver does: gpiod_set_value(..., 0); msleep(100); gpiod_set_value(..., 1); when asserting + deasserting PERST#. This is of course wrong, but because all the device trees for this compatible string have also incorrectly marked this GPIO as ACTIVE_HIGH: $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3568* $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3588* The actual toggling of PERST# is correct, and we cannot change it anyway, since that would break device tree compatibility. However, this driver does request the GPIO to be initialized as GPIOD_OUT_HIGH, which does cause a silly sequence where PERST# gets toggled back and forth for no good reason. Fix this by requesting the GPIO to be initialized as GPIOD_OUT_LOW (which for this driver means PERST# asserted). This will avoid an unnecessary signal change where PERST# gets deasserted (by devm_gpiod_get_optional()) and then gets asserted (by rockchip_pcie_start_link()) just a few instructions later. Before patch, debug prints on EP side, when booting RC: [ 845.606810] pci: PERST# asserted by host! [ 852.483985] pci: PERST# de-asserted by host! [ 852.503041] pci: PERST# asserted by host! [ 852.610318] pci: PERST# de-asserted by host! After patch, debug prints on EP side, when booting RC: [ 125.107921] pci: PERST# asserted by host! [ 132.111429] pci: PERST# de-asserted by host! This extra, very short, PERST# assertion + deassertion has been reported to cause issues with certain WLAN controllers, e.g. RTL8822CE. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Link: https://lore.kernel.org/linux-pci/20240417164227.398901-1-cassel@kernel.org Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Jianfeng Liu <liujianfeng1994@gmail.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: stable@vger.kernel.org # v5.15+
2024-07-09PCI: dw-rockchip: Add error messages in .probe() error pathsUwe Kleine-König
Drivers that silently fail to probe provide a bad user experience and make it unnecessarily hard to debug such a failure. Fix it by using dev_err_probe() instead of a plain return. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240227141256.413055-2-ukleinek@debian.org Signed-off-by: Uwe Kleine-König <ukleinek@debian.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Jesper Nilsson <jesper.nilsson@axis.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpioManivannan Sadhasivam
Rockchip platforms use 'GPIO_ACTIVE_HIGH' flag in the devicetree definition for ep_gpio. This means, whatever the logical value set by the driver for the ep_gpio, physical line will output the same logic level. For instance, gpiod_set_value_cansleep(rockchip->ep_gpio, 0); --> Level low gpiod_set_value_cansleep(rockchip->ep_gpio, 1); --> Level high But while requesting the ep_gpio, GPIOD_OUT_HIGH flag is currently used. Now, this also causes the physical line to output 'high' creating trouble for endpoint devices during host reboot. When host reboot happens, the ep_gpio will initially output 'low' due to the GPIO getting reset to its POR value. Then during host controller probe, it will output 'high' due to GPIOD_OUT_HIGH flag. Then during rockchip_pcie_host_init_port(), it will first output 'low' and then 'high' indicating the completion of controller initialization. On the endpoint side, each output 'low' of ep_gpio is accounted for PERST# assert and 'high' for PERST# deassert. With the above mentioned flow during host reboot, endpoint will witness below state changes for PERST#: (1) PERST# assert - GPIO POR state (2) PERST# deassert - GPIOD_OUT_HIGH while requesting GPIO (3) PERST# assert - rockchip_pcie_host_init_port() (4) PERST# deassert - rockchip_pcie_host_init_port() Now the time interval between (2) and (3) is very short as both happen during the driver probe(), and this results in a race in the endpoint. Because, before completing the PERST# deassertion in (2), endpoint got another PERST# assert in (3). A proper way to fix this issue is to change the GPIOD_OUT_HIGH flag in (2) to GPIOD_OUT_LOW. Because the usual convention is to request the GPIO with a state corresponding to its 'initial/default' value and let the driver change the state of the GPIO when required. As per that, the ep_gpio should be requested with GPIOD_OUT_LOW as it corresponds to the POR value of '0' (PERST# assert in the endpoint). Then the driver can change the state of the ep_gpio later in rockchip_pcie_host_init_port() as per the initialization sequence. This fixes the firmware crash issue in Qcom based modems connected to Rockpro64 based board. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Closes: https://lore.kernel.org/mhi/20240402045647.GG2933@thinkpad/ Link: https://lore.kernel.org/linux-pci/20240416-pci-rockchip-perst-fix-v1-1-4800b1d4d954@linaro.org Reported-by: Slark Xiao <slark_xiao@163.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Cc: stable@vger.kernel.org # v4.9
2024-07-09PCI: rockchip-host: Wait 100ms after reset before starting configurationDamien Le Moal
PCIe r6.0, sec 6.6.1, states that the host should wait for at least 100 msec from the end of a conventional reset (PERST# is de-asserted) before sending a configuration request to ensure that the device is able to respond with a "Request Retry Status" completion. Add the PCIE_T_RRS_READY_MS macro to define this wait time and modify rockchip_pcie_host_init_port() to add this 100ms sleep after deasserting PERST# using the ep_gpio GPIO. Link: https://lore.kernel.org/linux-pci/20240413004120.1099089-3-dlemoal@kernel.org Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handlingDamien Le Moal
PCIe CEM r5.1, sec 2.9.2, mandates that the PERST# signal must remain asserted for at least 100 usec (Tperst-clk) after the PCIe reference clock becomes stable (if a reference clock is supplied), and for at least 100 msec after the power is stable (Tpvperl, defined by the macro PCIE_T_PVPERL_MS). Modify rockchip_pcie_host_init_port() to satisfy these constraints by adding a sleep period before deasserting PERST# using the ep_gpio GPIO. Since Tperst-clk is the shorter wait time, add an msleep() call for the longer PCIE_T_PVPERL_MS milliseconds to handle both timing requirements. Link: https://lore.kernel.org/linux-pci/20240413004120.1099089-2-dlemoal@kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: dwc: ep: Enforce DWC specific 64-bit BAR limitationNiklas Cassel
From the DWC EP databook 5.96a, section "3.5.7.1.4 General Rules for BAR Setup (Fixed Mask or Programmable Mask Schemes Only)": "Any pair (for example BARs 0 and 1) can be configured as one 64-bit BAR, two 32-bit BARs, or one 32-bit BAR." "BAR pairs cannot overlap to form a 64-bit BAR. For example, you cannot combine BARs 1 and 2 to form a 64-bit BAR." While this limitation does exist in some other PCI endpoint controllers, e.g. cdns_pcie_ep_set_bar(), the limitation does not appear to be defined in the PCIe specification itself, thus add an explicit check for this in dw_pcie_ep_set_bar() (rather than pci_epc_set_bar()). Link: https://lore.kernel.org/linux-pci/20240528134839.8817-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: layerscape-ep: Use the generic dw_pcie_ep_linkdown() API to handle Link ↵Manivannan Sadhasivam
Down event Now that dw_pcie_ep_linkdown() is available, use it. This also handles the reinitialization of DWC non-sticky registers in addition to sending the notification to EPF drivers. Closes: https://lore.kernel.org/linux-pci/20240528195539.GA458945@bhelgaas Link: https://lore.kernel.org/linux-pci/20240606-pci-deinit-v1-5-4395534520dc@linaro.org Reported-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: qcom-ep: Use the generic dw_pcie_ep_linkdown() API to handle Link Down ↵Manivannan Sadhasivam
event Now that the generic dw_pcie_ep_linkdown() API is available, use it. This also handles the reinitialization of DWC non-sticky registers in addition to sending the notification to EPF drivers. Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-9-22832d0d456f@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: dwc: ep: Remove dw_pcie_ep_init_notify() wrapperManivannan Sadhasivam
Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify() directly, so this wrapper provides no benefit to the glue drivers. Remove it and call pci_epc_init_notify() directly from glue drivers. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Link: https://lore.kernel.org/linux-pci/20240606-pci-deinit-v1-1-4395534520dc@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down eventManivannan Sadhasivam
Per PCIe r6.0, sec 5.2, a Link Down event can happen under any of the following circumstances: 1. Fundamental/Hot reset 2. Link disable transmission by upstream component 3. Moving from L2/L3 to L0 In those cases, Link Down causes some non-sticky DWC registers to lose the state (like REBAR, etc.), so drivers need to reinitialize them to function properly once the link comes back again. This is not a problem for drivers supporting PERST# IRQ, since they can reinitialize the registers in the PERST# IRQ callback. But for the drivers not supporting PERST#, there is no way they can reinitialize the registers other than relying on Link Down IRQ received when the link goes down. So add a DWC generic API dw_pcie_ep_linkdown() that reinitializes the non-sticky registers and also notifies the EPF drivers about link going down. This API can also be used by the drivers supporting PERST# to handle the scenario (2) mentioned above. NOTE: For the sake of code organization, move the dw_pcie_ep_linkup() definition just above dw_pcie_ep_linkdown(). Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-8-22832d0d456f@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: update spec citation] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: dwc: Add generic MSG TLP support for sending PME_Turn_Off when system ↵Frank Li
suspend Instead of relying on the vendor specific implementations to send the PME_Turn_Off message, introduce a generic way of sending the message using the MSG TLP. This is achieved by reserving a region for MSG TLP of size 'pci->region_align', at the end of the first IORESOURCE_MEM window of the host bridge. And then sending the PME_Turn_Off message during system suspend with the help of iATU. The reason for reserving the MSG TLP region at the end of the IORESOURCE_MEM is to avoid generating holes in between, because when the region is allocated using allocate_resource(), memory will be allocated from the start of the window. Later, if memory gets allocated for an endpoint of size bigger than 'region_align', there will be a hole between MSG TLP region and endpoint memory. This generic implementation is optional for the glue drivers and can be overridden by a custom 'pme_turn_off' callback. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-5-a54265c39742@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: Add PCIE_MSG_CODE_PME_TURN_OFF message macroFrank Li
Add PCIE_MSG_CODE_PME_TURN_OFF macros to enable a PCIe host driver to send PME_Turn_Off messages. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-4-a54265c39742@nxp.com Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: Add PCIE_MSG_CODE_ASSERT_INTx message macrosYoshihiro Shimoda
Add "Message Routing" and "INTx Mechanism Messages" macros to enable a PCIe driver to send messages for INTx Interrupt Signaling. Values from PCIe r6.1, sec 2.2.8 and 2.2.8.1. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-1-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2024-07-09PCI: dwc: Add outbound MSG TLPs supportYoshihiro Shimoda
Add "code" and "routing" into struct dw_pcie_ob_atu_cfg for triggering INTx IRQs by iATU in the PCIe endpoint mode in near the future. PCIE_ATU_INHIBIT_PAYLOAD is set to issue TLP type of Msg instead of MsgD. This implementation supports the data-less messages only for now. Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-3-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2024-07-09PCI: dwc: Consolidate args of dw_pcie_prog_outbound_atu() into a structureYoshihiro Shimoda
This is a preparation before adding the Msg-type outbound iATU mapping. The respective update will require two more arguments added to __dw_pcie_prog_outbound_atu(). That will make the already complicated function prototype even more hard to comprehend accepting _eight_ arguments. To prevent that and keep the code more-or-less readable, move all the outbound iATU-related arguments to a new config structure: struct dw_pcie_ob_atu_cfg, and pass a pointer to dw_pcie_prog_outbound_atu(). The structure should be locally defined and populated with the outbound iATU settings implied by the caller context. As a result of this change there is no longer need in having the two distinctive methods for the Host and Endpoint outbound iATU setups since the code can directly call the dw_pcie_prog_outbound_atu() method with the config structure populated, so drop dw_pcie_prog_ep_outbound_atu(). [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240418-pme_msg-v8-2-a54265c39742@nxp.com Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
2024-07-09PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slotFrank Li
When PERST# assert and deassert happens on the PERST# supported platforms, both iATU0 and iATU6 will map inbound window to BAR0. DMA will access the area that was previously allocated (iATU0) for BAR0, instead of the new area (iATU6) for BAR0. Right now, this isn't an issue because both iATU0 and iATU6 should translate inbound accesses to BAR0 to the same allocated memory area. However, having two separate inbound mappings for the same BAR is a disaster waiting to happen. The mappings between PCI BAR and iATU inbound window are maintained in the dw_pcie_ep::bar_to_atu[] array. While allocating a new inbound iATU map for a BAR, dw_pcie_ep_inbound_atu() API checks for the availability of the existing mapping in the array and if it is not found (i.e., value in the array indexed by the BAR is found to be 0), it allocates a new map value using find_first_zero_bit(). The issue is the existing logic failed to consider the fact that the map value '0' is a valid value for BAR0, so find_first_zero_bit() will return '0' as the map value for BAR0 (note that it returns the first zero bit position). Due to this, when PERST# assert + deassert happens on the PERST# supported platforms, the inbound window allocation restarts from BAR0 and the existing logic to find the BAR mapping will return '6' for BAR0 instead of '0' due to the fact that it considers '0' as an invalid map value. Fix this issue by always incrementing the map value before assigning to bar_to_atu[] array and then decrementing it while fetching. This will make sure that the map value '0' always represents the invalid mapping." Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Closes: https://lore.kernel.org/linux-pci/ZXsRp+Lzg3x%2Fnhk3@x1-carbon/ Link: https://lore.kernel.org/linux-pci/20240412160841.925927-1-Frank.Li@nxp.com Reported-by: Niklas Cassel <Niklas.Cassel@wdc.com> Tested-by: Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
2024-07-09PCI: dwc: Use msleep() in dw_pcie_wait_for_link()Konrad Dybcio
According to [1], msleep should be used for large sleeps, such as the 100-ish ms one in this function. Comply with the guide and use it. [1] https://docs.kernel.org/timers/timers-howto.html [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240215-topic-pci_sleep-v2-1-79334884546b@linaro.org Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: kirin: Convert to use agnostic GPIO APIAndy Shevchenko
The of_gpio.h legacy API is going to be removed. In preparation for that, convert the driver to the agnostic API. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240506142142.4042810-6-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org>
2024-07-09PCI: kirin: Convert kirin_pcie_parse_port() to scoped iteratorJavier Carrasco
Convert loops in kirin_pcie_parse_port() to use the _scoped() version of for_each_available_child_of_node() so the refcounts of children are implicitly decremented when the loop is exited. No functional change intended here, but it will make future error exits from these loops easier. Link: https://lore.kernel.org/linux-pci/20240609-pcie-kirin-memleak-v1-1-62b45b879576@gmail.com Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: move to GPIO series to avoid bisection hole, commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-07-09PCI: qcom: Add OPP support to scale performanceKrishna chaitanya chundru
QCOM Resource Power Manager-hardened (RPMh) is a hardware block which maintains hardware state of a regulator by performing max aggregation of the requests made by all of the clients. PCIe controller can operate on different RPMh performance state of power domain based on the speed of the link. And this performance state varies from target to target, like some controllers support GEN3 in NOM (Nominal) voltage corner, while some other supports GEN3 in low SVS (static voltage scaling). The SoC can be more power efficient if we scale the performance state based on the aggregate PCIe link bandwidth. Add Operating Performance Points (OPP) support to vote for RPMh state based on the aggregate link bandwidth. OPP can handle ICC bw voting also, so move ICC bw voting through OPP framework if OPP entries are present. As we are moving ICC voting as part of OPP, don't initialize ICC if OPP is supported. Before PCIe link is initialized vote for highest OPP in the OPP table, so that we are voting for maximum voltage corner for the link to come up in maximum supported speed. Link: https://lore.kernel.org/linux-pci/20240619-opp_support-v15-4-aa769a2173a3@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: wrap comments to fit in 80 columns] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: Bring the PCIe speed to MBps logic to new pcie_dev_speed_mbps()Krishna chaitanya chundru
Bring the switch case in pcie_link_speed_mbps() to new function to the header file so that it can be used in other places like in controller driver. Link: https://lore.kernel.org/linux-pci/20240619-opp_support-v15-3-aa769a2173a3@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: qcom: Add ICC bandwidth vote for CPU to PCIe pathKrishna chaitanya chundru
To access the host controller registers of the host controller and the endpoint BAR/config space, the CPU-PCIe ICC (interconnect) path should be voted otherwise it may lead to NoC (Network on chip) timeout. We are surviving because of other driver voting for this path. As there is less access on this path compared to PCIe to mem path add minimum vote i.e 1KBps bandwidth always which is sufficient enough to keep the path active and is recommended by HW team. During S2RAM (Suspend-to-RAM), the DBI access can happen very late (while disabling the boot CPU). So do not disable the CPU-PCIe interconnect path during S2RAM as that may lead to NoC error. Link: https://lore.kernel.org/linux-pci/20240619-opp_support-v15-1-aa769a2173a3@quicinc.com Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: qcom-ep: Disable resources unconditionally during PERST# assertManivannan Sadhasivam
All EP specific resources are enabled during PERST# deassert. As a counter operation, all resources should be disabled during PERST# assert. There is no point in skipping that if the link was not enabled. This will also result in enablement of the resources twice if PERST# got deasserted again. So remove the check from qcom_pcie_perst_assert() and disable all the resources unconditionally. Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-1-22832d0d456f@linaro.org Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
2024-07-09PCI: qcom-ep: Override NO_SNOOP attribute for SA8775P EPMrinmay Sarkar
Due to some hardware changes, SA8775P has set the NO_SNOOP attribute in its TLP for all the PCIe controllers. NO_SNOOP attribute when set, the requester is indicating that no cache coherency issues exist for the addressed memory on the host i.e., memory is not cached. But in reality, requester cannot assume this unless there is a complete control/visibility over the addressed memory on the host. And worst case, if the memory is cached on the host, it may lead to memory corruption issues. It should be noted that the caching of memory on the host is not solely dependent on the NO_SNOOP attribute in TLP. So to avoid the corruption, this patch overrides the NO_SNOOP attribute by setting the PCIE_PARF_NO_SNOOP_OVERIDE register. This patch is not needed for other upstream supported platforms since they do not set NO_SNOOP attribute by default. Link: https://lore.kernel.org/linux-pci/1710166298-27144-3-git-send-email-quic_msarkar@quicinc.com Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-09PCI: qcom: Override NO_SNOOP attribute for SA8775P RCMrinmay Sarkar
Due to some hardware changes, SA8775P has set the NO_SNOOP attribute in its TLP for all the PCIe controllers. NO_SNOOP attribute when set, the requester is indicating that no cache coherency issue exist for the addressed memory on the endpoint i.e., memory is not cached. But in reality, requester cannot assume this unless there is a complete control/visibility over the addressed memory on the endpoint. And worst case, if the memory is cached on the endpoint, it may lead to memory corruption issues. It should be noted that the caching of memory on the endpoint is not solely dependent on the NO_SNOOP attribute in TLP. So to avoid the corruption, this patch overrides the NO_SNOOP attribute by setting the PCIE_PARF_NO_SNOOP_OVERIDE register. This patch is not needed for other upstream supported platforms since they do not set NO_SNOOP attribute by default. 8775 has IP version 1.34.0 so introduce a new cfg(cfg_1_34_0) for this platform. Assign override_no_snoop flag into struct qcom_pcie_cfg and set it true in cfg_1_34_0 and enable cache snooping if this particular flag is true. Link: https://lore.kernel.org/linux-pci/1710166298-27144-2-git-send-email-quic_msarkar@quicinc.com Signed-off-by: Mrinmay Sarkar <quic_msarkar@quicinc.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> [bhelgaas: wrap comments to fit in 80 columns] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2024-07-08PCI: of_property: Add interrupt-controller property in PCI device nodesHerve Codina
PCI devices and bridges DT nodes created during the PCI scan are created with the interrupt-map property set to handle interrupts. In order to set this interrupt-map property at a specific level, a phandle to the parent interrupt controller is needed. On systems that are not fully described by a device-tree, the parent interrupt controller may be unavailable (i.e. not described by the device-tree). As mentioned in the [1], avoiding the use of the interrupt-map property and considering a PCI device as an interrupt controller itself avoid the use of a parent interrupt phandle. In that case, the PCI device itself as an interrupt controller is responsible for routing the interrupts described in the device-tree world (DT overlay) to the PCI interrupts. Add the 'interrupt-controller' property in the PCI device DT node. [1]: https://lore.kernel.org/lkml/CAL_Jsq+je7+9ATR=B6jXHjEJHjn24vQFs4Tvi9=vhDeK9n42Aw@mail.gmail.com/ Signed-off-by: Herve Codina <herve.codina@bootlin.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20240527161450.326615-18-herve.codina@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-07-08PCI/pwrctl: only call of_platform_populate() if CONFIG_OF is enabledBert Karwatzki
If of_platform_populate() is called when CONFIG_OF is not defined this leads to spurious error messages of the following type: pci 0000:00:01.1: failed to populate child OF nodes (-19) pci 0000:00:02.1: failed to populate child OF nodes (-19) Fixes: 8fb18619d910 ("PCI/pwrctl: Create platform devices for child OF nodes of the port node") Signed-off-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/all/20240702173255.39932-1-superm1@kernel.org/ Reviewed-by: Lukas Wunner <lukas@wunner.de> Acked-by: Krzysztof Wilczyński <kw@linux.com> Reported-by: Praveenkumar Patil <PraveenKumar.Patil@amd.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20240707183829.41519-1-spasswolf@web.de Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
generated by cgit (git 2.34.1) at 2025-07-15 15:29:44 +0000