summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-13dt-bindings: rockchip: Add DesignWare based PCIe controllerSimon Xue
Document DT bindings for PCIe controller found on Rockchip SoC. Link: https://lore.kernel.org/r/20210818093406.157788-1-xxm@rock-chips.com Signed-off-by: Simon Xue <xxm@rock-chips.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2021-10-12PCI: cpqphp: Format if-statement code block correctlyKrzysztof Wilczyński
The code block related to the if-statement in cpqhp_set_irq() is somewhat awkwardly formatted making the code hard to read. Make it readable. No change to functionality intended. Link: https://lore.kernel.org/r/20211013011412.1110829-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12nfp: use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <simon.horman@corigine.com>
2021-10-12mlxsw: pci: Use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
2021-10-12net: marvell: prestera: use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12net: hns3: use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12crypto: hisilicon - use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12powerpc/eeh: Use dev_driver_string() instead of struct pci_dev->driver->nameUwe Kleine-König
Replace pdev->driver->name by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. Move the function nearer its only user and instead of the ?: operator use a normal "if" which is more readable. Link: https://lore.kernel.org/r/20211004125935.2300113-6-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12ssb: Use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
All drivers that use ssb_pcihost_probe(), i.e., b43_pci_bridge_driver and b44_pci_driver, set the pci_driver.name, and __pci_register_driver() sets the struct driver.name member to the same value. Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. Link: https://lore.kernel.org/r/20211004125935.2300113-7-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Büsch <m@bues.ch>
2021-10-12bcma: simplify reference to driver nameUwe Kleine-König
When bcma_host_pci_probe() is called, the PCI driver core has already assigned the device's driver in local_pci_probe(). So dev->driver is always true, and here it points to bcma_pci_bridge_driver, which has .name set to "bcma-pci-bridge". Simplify accordingly. Link: https://lore.kernel.org/r/20211004125935.2300113-5-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12crypto: qat - simplify adf_enable_aer()Uwe Kleine-König
A struct pci_driver is shared across all device instances, so assigning pci_driver.err_handler once per device isn't really sensible. Set adf_driver.err_handler statically instead of in adf_enable_aer(). This removes a use of pci_dev->driver, which is a step toward removing pci_dev->driver altogether. Since adf_enable_aer() returns zero unconditionally, make it a void function. Link: https://lore.kernel.org/r/20211004125935.2300113-10-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12scsi: message: fusion: Remove unused mpt_pci driver .probe() 'id' parameterUwe Kleine-König
The only two drivers don't make use of the id parameter, so drop it. This is a step toward removing pci_dev->driver. Link: https://lore.kernel.org/r/20211004125935.2300113-9-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-12PCI/ERR: Factor out common dev->driver expressionsBjorn Helgaas
Save the struct pci_driver pointer from pdev->driver instead of repeating it several times. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12PCI: Drop pci_device_probe() test of !pci_dev->driverUwe Kleine-König
When the device core calls the .probe() callback for a device, the device is never bound, so pci_dev->driver is always NULL. Remove the unnecessary test of !pci_dev->driver. Link: https://lore.kernel.org/r/20211004125935.2300113-3-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2021-10-12PCI: Drop pci_device_remove() test of pci_dev->driverUwe Kleine-König
When the driver core calls pci_device_remove(), there is a driver bound to the device, so pci_dev->driver is never NULL. Remove the unnecessary test of pci_dev->driver. Link: https://lore.kernel.org/r/20211004125935.2300113-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2021-10-12PCI: Return NULL for to_pci_driver(NULL)Bjorn Helgaas
to_pci_driver() takes a pointer to a struct device_driver and uses container_of() to find the struct pci_driver that contains it. If given a NULL pointer to a struct device_driver, return a NULL pci_driver pointer instead of applying container_of() to NULL. This simplifies callers that would otherwise have to check for a NULL pointer first. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12PCI: Use unsigned to match sscanf("%x") in pci_dev_str_match_path()Krzysztof Wilczyński
Cppcheck warns that pci_dev_str_match_path() passes pointers to signed ints to sscanf("%x"), which expects pointers to *unsigned* ints: invalidScanfArgType_int drivers/pci/pci.c:312 %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'. Declare the variables as unsigned to avoid this issue. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20211008222732.2868493-3-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12PCI: hv: Remove unnecessary use of %hxKrzysztof Wilczyński
"dom_req" is a u16 but varargs automatically promotes it to int, so there's no point in using the %h modifier. Drop it. See cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") and 70eb2275ff8e ("checkpatch: add warning for unnecessary use of %h[xudi] and %hh[xudi]"). Link: https://lore.kernel.org/r/20211008222732.2868493-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-12PCI: vmd: Do not disable MSI-X remapping if interrupt remapping is enabled ↵Adrian Huang
by IOMMU When enabling VMD in BIOS setup (Ice Lake Processor: Whitley platform), the host OS cannot boot successfully with the following error message: nvme nvme0: I/O 12 QID 0 timeout, completion polled nvme nvme0: Shutdown timeout set to 6 seconds DMAR: DRHD: handling fault status reg 2 DMAR: [INTR-REMAP] Request device [0x00:0x00.5] fault index 0xa00 [fault reason 0x25] Blocked a compatibility format interrupt request The request device is the VMD controller: # lspci -s 0000:00.5 -nn 0000:00:00.5 RAID bus controller [0104]: Intel Corporation Volume Management Device NVMe RAID Controller [8086:28c0] (rev 04) `git bisect` points to this offending commit ee81ee84f873 ("PCI: vmd: Disable MSI-X remapping when possible"), which disables VMD MSI remapping. The IOMMU hardware blocks the compatibility format interrupt request because Interrupt Remapping Enable Status (IRES) and Extended Interrupt Mode Enable (EIME) are enabled. Please refer to section "5.1.4 Interrupt-Remapping Hardware Operation" in Intel VT-d spec. To fix the issue, VMD driver still enables the interrupt remapping irrespective of VMD_FEAT_CAN_BYPASS_MSI_REMAP if the IOMMU subsystem enables the interrupt remapping. Test configuration is shown as follows: * Two VMD controllers 1. 8086:28c0 (Whitley's VMD) 2. 8086:201d (Purley's VMD: The issue does not appear in this controller. Just make sure if any side effect occurs.) * w/wo intremap=off Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=214219 Link: https://lore.kernel.org/r/20210901124047.1615-1-adrianhuang0701@gmail.com Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com> Cc: Jon Derrick <jonathan.derrick@intel.com> Cc: Nirmal Patel <nirmal.patel@linux.intel.com> Cc: Joerg Roedel <jroedel@suse.de>
2021-10-12PCI: dwc: Perform host_init() before registering msiBjorn Andersson
On the Qualcomm sc8180x platform the bootloader does something related to PCI that leaves a pending "msi" interrupt, which with the current ordering often fires before init has a chance to enable the clocks that are necessary for the interrupt handler to access the hardware. Move the host_init() call before the registration of the "msi" interrupt handler to ensure the host driver has a chance to enable the clocks. The assignment of the bridge's ops and child_ops is moved along, because at least the TI Keystone driver overwrites these in its host_init callback. Link: https://lore.kernel.org/r/20210823154958.305677-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2021-10-11MAINTAINERS: Add entry for Qualcomm PCIe Endpoint driver and bindingManivannan Sadhasivam
Add MAINTAINERS entry for Qualcomm PCIe Endpoint driver and its devicetree binding. Also fix the PCIe RC entry to cover only the RC driver. Link: https://lore.kernel.org/r/20210920065946.15090-4-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-11PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driverManivannan Sadhasivam
Add driver for Qualcomm PCIe Endpoint controller based on the DesignWare core with added Qualcomm-specific wrapper around the core. The driver support is very basic such that it supports only enumeration, PCIe read/write, and MSI. There is no ASPM and PM support for now but these will be added later. The driver is capable of using the PERST# and WAKE# side-band GPIOs for operation and written on top of the DWC PCI framework. [bhelgaas: wrap a few long lines] Co-developed-by: Siddartha Mohanadoss <smohanad@codeaurora.org> [mani: restructured the driver and fixed several bugs for upstream] Link: https://lore.kernel.org/r/20210920065946.15090-3-manivannan.sadhasivam@linaro.org Signed-off-by: Siddartha Mohanadoss <smohanad@codeaurora.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
2021-10-11PCI/VPD: Add pci_read/write_vpd_any()Heiner Kallweit
In certain cases we need a variant of pci_read_vpd()/pci_write_vpd() that does not check against dev->vpd.len. Such cases are: - Reading VPD if dev->vpd.len isn't set yet (in pci_vpd_size()) - Devices that map non-VPD information to arbitrary places in VPD address space (example: Chelsio T3 EEPROM write-protect flag) Therefore add pci_read_vpd_any() and pci_write_vpd_any() that check against PCI_VPD_MAX_SIZE only. Link: https://lore.kernel.org/r/93ecce28-a158-f02a-d134-8afcaced8efe@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jakub Kicinski <kuba@kernel.org>
2021-10-08PCI: Correct misspelled and remove duplicated wordsKrzysztof Wilczyński
Correct a number of misspelled words and remove any words that were duplicated in the PCI tree. No change to functionality intended. Link: https://lore.kernel.org/r/20211006233827.147328-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-08dt-bindings: PCI: Add Qualcomm PCIe Endpoint controllerManivannan Sadhasivam
Add devicetree binding for Qualcomm PCIe Endpoint controller used in platforms like SDX55. The Endpoint controller is based on the DesignWare core with Qualcomm-specific wrappers. Link: https://lore.kernel.org/r/20210920065946.15090-2-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
2021-10-08PCI: rcar-host: Remove unneeded includesGeert Uytterhoeven
Remove includes that are not needed, to speed up (re)compilation. Most of these are relics from splitting the driver in a host and a common part. [bhelgaas: use driver tag analogous to rcar-ep] Link: https://lore.kernel.org/r/54bed9a0e6991490ddb2b07e5abfaf40a7a62928.1633090577.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
2021-10-08PCI: rcar-ep: Remove unneeded includesGeert Uytterhoeven
Remove includes that are not needed, to speed up (re)compilation. Include <linux/pm_runtime.h>, which is needed, and was included implicitly through <linux/phy/phy.h> before. Most of these are relics from splitting the driver in a host and a common part and adding endpoint support. [bhelgaas: use driver tag consistent with cadence-ep, designware-ep] Link: https://lore.kernel.org/r/7c708841a2bf84f85b14a963271c3e99c8ba38a5.1633090444.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
2021-10-07PCI: vmd: Assign a number to each VMD controllerChunguang Xu
If the system has multiple VMD controllers, the driver does not assign a number to each controller, so when analyzing the interrupt through /proc/interrupts, the names of all controllers are the same, which is not very convenient for problem analysis. Here, try to assign a number to each VMD controller. Link: https://lore.kernel.org/r/1631884404-24141-1-git-send-email-brookxu.cn@gmail.com Signed-off-by: Chunguang Xu <brookxu@tencent.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-10-07PCI: visconti: Remove surplus dev_err() when using platform_get_irq_byname()Krzysztof Wilczyński
There is no need to call the dev_err() function directly to print a custom message when handling an error from either the platform_get_irq() or platform_get_irq_byname() functions as both are going to display an appropriate error message in case of a failure. This change is as per suggestions from Coccinelle, e.g., drivers/pci/controller/dwc/pcie-visconti.c:286:2-9: line 286 is redundant because platform_get_irq() already prints an error Related: https://lore.kernel.org/all/20210310131913.2802385-1-kw@linux.com/ https://lore.kernel.org/all/20200802142601.1635926-1-kw@linux.com/ Link: https://lore.kernel.org/r/20211007122848.3366-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-10-07PCI: dwc: Clean up Kconfig dependencies (PCIE_DW_EP)Andy Shevchenko
The "depends on" Kconfig construct is a no-op in options that are selected and therefore has no effect. Remove it. Clean up the users of PCIE_DW_EP and introduce idiom depends on PCI_ENDPOINT select PCIE_DW_EP for all of them. Link: https://lore.kernel.org/r/20210623140103.47818-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-10-07PCI: dwc: Clean up Kconfig dependencies (PCIE_DW_HOST)Andy Shevchenko
The "depends on" Kconfig construct is a no-op in options that are selected and therefore has no effect. Remove it. Furthermore, there is no need to repeat menu dependencies (PCI). Clean up the users of PCIE_DW_HOST and introduce idiom depends on PCI_MSI_IRQ_DOMAIN select PCIE_DW_HOST for all of them. Link: https://lore.kernel.org/r/20210623140103.47818-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-10-07PCI: aardvark: Fix reporting Data Link Layer Link ActivePali Rohár
Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register on emulated bridge via current LTSSM state. Also correctly indicate DLLLA capability via PCI_EXP_LNKCAP_DLLLARC bit in Link Control Capability register. Link: https://lore.kernel.org/r/20211005180952.6812-14-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-10-07PCI: aardvark: Fix checking for link up via LTSSM statePali Rohár
Current implementation of advk_pcie_link_up() is wrong as it marks also link disabled or hot reset states as link up. Fix it by marking link up only to those states which are defined in PCIe Base specification 3.0, Table 4-14: Link Status Mapped to the LTSSM. To simplify implementation, Define macros for every LTSSM state which aardvark hardware can return in CFG_REG register. Fix also checking for link training according to the same Table 4-14. Define a new function advk_pcie_link_training() for this purpose. Link: https://lore.kernel.org/r/20211005180952.6812-13-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Cc: Remi Pommarel <repk@triplefau.lt>
2021-10-07PCI: aardvark: Fix link trainingPali Rohár
Fix multiple link training issues in aardvark driver. The main reason of these issues was misunderstanding of what certain registers do, since their names and comments were misleading: before commit 96be36dbffac ("PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros"), the pci-aardvark.c driver used custom macros for accessing standard PCIe Root Bridge registers, and misleading comments did not help to understand what the code was really doing. After doing more tests and experiments I've come to the conclusion that the SPEED_GEN register in aardvark sets the PCIe revision / generation compliance and forces maximal link speed. Both GEN3 and GEN2 values set the read-only PCI_EXP_FLAGS_VERS bits (PCIe capabilities version of Root Bridge) to value 2, while GEN1 value sets PCI_EXP_FLAGS_VERS to 1, which matches with PCI Express specifications revisions 3, 2 and 1 respectively. Changing SPEED_GEN also sets the read-only bits PCI_EXP_LNKCAP_SLS and PCI_EXP_LNKCAP2_SLS to corresponding speed. (Note that PCI Express rev 1 specification does not define PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers and when SPEED_GEN is set to GEN1 (which also sets PCI_EXP_FLAGS_VERS set to 1), lspci cannot access PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers.) Changing PCIe link speed can be done via PCI_EXP_LNKCTL2_TLS bits of PCI_EXP_LNKCTL2 register. Armada 3700 Functional Specifications says that the default value of PCI_EXP_LNKCTL2_TLS is based on SPEED_GEN value, but tests showed that the default value is always 8.0 GT/s, independently of speed set by SPEED_GEN. So after setting SPEED_GEN, we must also set value in PCI_EXP_LNKCTL2 register via PCI_EXP_LNKCTL2_TLS bits. Triggering PCI_EXP_LNKCTL_RL bit immediately after setting LINK_TRAINING_EN bit actually doesn't do anything. Tests have shown that a delay is needed after enabling LINK_TRAINING_EN bit. As triggering PCI_EXP_LNKCTL_RL currently does nothing, remove it. Commit 43fc679ced18 ("PCI: aardvark: Improve link training") introduced code which sets SPEED_GEN register based on negotiated link speed from PCI_EXP_LNKSTA_CLS bits of PCI_EXP_LNKSTA register. This code was added to fix detection of Compex WLE900VX (Atheros QCA9880) WiFi GEN1 PCIe cards, as otherwise these cards were "invisible" on PCIe bus (probably because they crashed). But apparently more people reported the same issues with these cards also with other PCIe controllers [1] and I was able to reproduce this issue also with other "noname" WiFi cards based on Atheros QCA9890 chip (with the same PCI vendor/device ids as Atheros QCA9880). So this is not an issue in aardvark but rather an issue in Atheros QCA98xx chips. Also, this issue only exists if the kernel is compiled with PCIe ASPM support, and a generic workaround for this is to change PCIe Bridge to 2.5 GT/s link speed via PCI_EXP_LNKCTL2_TLS_2_5GT bits in PCI_EXP_LNKCTL2 register [2], before triggering PCI_EXP_LNKCTL_RL bit. This workaround also works when SPEED_GEN is set to value GEN2 (5 GT/s). So remove this hack completely in the aardvark driver and always set SPEED_GEN to value from 'max-link-speed' DT property. Fix for Atheros QCA98xx chips is handled separately by patch [2]. These two things (code for triggering PCI_EXP_LNKCTL_RL bit and changing SPEED_GEN value) also explain why commit 6964494582f5 ("PCI: aardvark: Train link immediately after enabling training") somehow fixed detection of those problematic Compex cards with Atheros chips: if triggering link retraining (via PCI_EXP_LNKCTL_RL bit) was done immediately after enabling link training (via LINK_TRAINING_EN), it did nothing. If there was a specific delay, aardvark HW already initialized PCIe link and therefore triggering link retraining caused the above issue. Compex cards triggered link down event and disappeared from the PCIe bus. Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") added 100ms sleep before calling 'Start link training' command and explained that it is a requirement of PCI Express specification. But the code after this 100ms sleep was not doing 'Start link training', rather it triggered PCI_EXP_LNKCTL_RL bit via PCIe Root Bridge to put link into Recovery state. The required delay after fundamental reset is already done in function advk_pcie_wait_for_link() which also checks whether PCIe link is up. So after removing the code which triggers PCI_EXP_LNKCTL_RL bit on PCIe Root Bridge, there is no need to wait 100ms again. Remove the extra msleep() call and update comment about the delay required by the PCI Express specification. According to Marvell Armada 3700 Functional Specifications, Link training should be enabled via aardvark register LINK_TRAINING_EN after selecting PCIe generation and x1 lane. There is no need to disable it prior resetting card via PERST# signal. This disabling code was introduced in commit 5169a9851daa ("PCI: aardvark: Issue PERST via GPIO") as a workaround for some Atheros cards. It turns out that this also is Atheros specific issue and affects any PCIe controller, not only aardvark. Moreover this Atheros issue was triggered by juggling with PCI_EXP_LNKCTL_RL, LINK_TRAINING_EN and SPEED_GEN bits interleaved with sleeps. Now, after removing triggering PCI_EXP_LNKCTL_RL, there is no need to explicitly disable LINK_TRAINING_EN bit. So remove this code too. The problematic Compex cards described in previous git commits are correctly detected in advk_pcie_train_link() function even after applying all these changes. Note that with this patch, and also prior this patch, some NVMe disks which support PCIe GEN3 with 8 GT/s speed are negotiated only at the lowest link speed 2.5 GT/s, independently of SPEED_GEN value. After manually triggering PCI_EXP_LNKCTL_RL bit (e.g. from userspace via setpci), these NVMe disks change link speed to 5 GT/s when SPEED_GEN was configured to GEN2. This issue first needs to be properly investigated. I will send a fix in the future. On the other hand, some other GEN2 PCIe cards with 5 GT/s speed are autonomously by HW autonegotiated at full 5 GT/s speed without need of any software interaction. Armada 3700 Functional Specifications describes the following steps for link training: set SPEED_GEN to GEN2, enable LINK_TRAINING_EN, poll until link training is complete, trigger PCI_EXP_LNKCTL_RL, poll until signal rate is 5 GT/s, poll until link training is complete, enable ASPM L0s. The requirement for triggering PCI_EXP_LNKCTL_RL can be explained by the need to achieve 5 GT/s speed (as changing link speed is done by throw to recovery state entered by PCI_EXP_LNKCTL_RL) or maybe as a part of enabling ASPM L0s (but in this case ASPM L0s should have been enabled prior PCI_EXP_LNKCTL_RL). It is unknown why the original pci-aardvark.c driver was triggering PCI_EXP_LNKCTL_RL bit before waiting for the link to be up. This does not align with neither PCIe base specifications nor with Armada 3700 Functional Specification. (Note that in older versions of aardvark, this bit was called incorrectly PCIE_CORE_LINK_TRAINING, so this may be the reason.) It is also unknown why Armada 3700 Functional Specification says that it is needed to trigger PCI_EXP_LNKCTL_RL for GEN2 mode, as according to PCIe base specification 5 GT/s speed negotiation is supposed to be entirely autonomous, even if initial speed is 2.5 GT/s. [1] - https://lore.kernel.org/linux-pci/87h7l8axqp.fsf@toke.dk/ [2] - https://lore.kernel.org/linux-pci/20210326124326.21163-1-pali@kernel.org/ Link: https://lore.kernel.org/r/20211005180952.6812-12-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org>
2021-10-07PCI: aardvark: Simplify initialization of rootcap on virtual bridgePali Rohár
PCIe config space can be initialized also before pci_bridge_emul_init() call, so move rootcap initialization after PCI config space initialization. This simplifies the function a little since it removes one if (ret < 0) check. Link: https://lore.kernel.org/r/20211005180952.6812-11-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org>
2021-10-07PCI: aardvark: Implement re-issuing config requests on CRS responsePali Rohár
Commit 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") fixed handling of CRS response and when CRSSVE flag was not enabled it marked CRS response as failed transaction (due to simplicity). But pci-aardvark.c driver is already waiting up to the PIO_RETRY_CNT count for PIO config response and so we can with a small change implement re-issuing of config requests as described in PCIe base specification. This change implements re-issuing of config requests when response is CRS. Set upper bound of wait cycles to around PIO_RETRY_CNT, afterwards the transaction is marked as failed and an all-ones value is returned as before. We do this by returning appropriate error codes from function advk_pcie_check_pio_status(). On CRS we return -EAGAIN and caller then reissues transaction. Link: https://lore.kernel.org/r/20211005180952.6812-10-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org>
2021-10-07PCI: aardvark: Deduplicate code in advk_pcie_rd_conf()Marek Behún
Avoid code repetition in advk_pcie_rd_conf() by handling errors with goto jump, as is customary in kernel. Link: https://lore.kernel.org/r/20211005180952.6812-9-kabel@kernel.org Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-10-07PCI: aardvark: Do not unmask unused interruptsPali Rohár
There are lot of undocumented interrupt bits. To prevent unwanted spurious interrupts, fix all *_ALL_MASK macros to define all interrupt bits, so that driver can properly mask all interrupts, including those which are undocumented. Link: https://lore.kernel.org/r/20211005180952.6812-8-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-10-07PCI: aardvark: Do not clear status bits of masked interruptsPali Rohár
The PCIE_ISR1_REG says which interrupts are currently set / active, including those which are masked. The driver currently reads this register and looks if some unmasked interrupts are active, and if not, it clears status bits of _all_ interrupts, including the masked ones. This is incorrect, since, for example, some drivers may poll these bits. Remove this clearing, and also remove this early return statement completely, since it does not change functionality in any way. Link: https://lore.kernel.org/r/20211005180952.6812-7-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-10-07PCI: aardvark: Fix configuring Reference clockPali Rohár
Commit 366697018c9a ("PCI: aardvark: Add PHY support") introduced configuration of PCIe Reference clock via PCIE_CORE_REF_CLK_REG register, but did it incorrectly. PCIe Reference clock differential pair is routed from system board to endpoint card, so on CPU side it has output direction. Therefore it is required to enable transmitting and disable receiving. Default configuration according to Armada 3700 Functional Specifications is enabled receiver part and disabled transmitter. We need this change because otherwise PCIe Reference clock is configured to some undefined state when differential pair is used for both transmitting and receiving. Fix this by disabling receiver part. Link: https://lore.kernel.org/r/20211005180952.6812-6-kabel@kernel.org Fixes: 366697018c9a ("PCI: aardvark: Add PHY support") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-10-07PCI: aardvark: Fix preserving PCI_EXP_RTCTL_CRSSVE flag on emulated bridgePali Rohár
Commit 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") started using CRSSVE flag for handling CRS responses. PCI_EXP_RTCTL_CRSSVE flag is stored only in emulated config space buffer and there is handler for PCI_EXP_RTCTL register. So every read operation from config space automatically clears CRSSVE flag as it is not defined in PCI_EXP_RTCTL read handler. Fix this by reading current CRSSVE bit flag from emulated space buffer and appending it to PCI_EXP_RTCTL read response. Link: https://lore.kernel.org/r/20211005180952.6812-5-kabel@kernel.org Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org>
2021-10-07PCI: aardvark: Don't spam about PIO Response StatusMarek Behún
Use dev_dbg() instead of dev_err() in advk_pcie_check_pio_status(). For example CRS is not an error status, it just says that the request should be retried. Link: https://lore.kernel.org/r/20211005180952.6812-4-kabel@kernel.org Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-10-07PCI: aardvark: Fix PCIe Max Payload Size settingPali Rohár
Change PCIe Max Payload Size setting in PCIe Device Control register to 512 bytes to align with PCIe Link Initialization sequence as defined in Marvell Armada 3700 Functional Specification. According to the specification, maximal Max Payload Size supported by this device is 512 bytes. Without this kernel prints suspicious line: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 16384, max 512) With this change it changes to: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 512, max 512) Link: https://lore.kernel.org/r/20211005180952.6812-3-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org
2021-10-07PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macrosPali Rohár
Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*. Link: https://lore.kernel.org/r/20211005180952.6812-2-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-05PCI: imx6: Remove unused assignment to variable retKrzysztof Wilczyński
Previously, the maximum link speed was set following an "fsl,max-link-speed" property read, and should the read failed, then the PCIe generation was manually set to PCIe Gen1 and thus limiting the link speed to 2.5 GT/s. Code refactoring completed in the commit 39bc5006501c ("PCI: dwc: Centralize link gen setting") changed to the logic that was previously used to limit the maximum link speed leaving behind an unused assignment to a variable "ret". Since the value returned from the of_property_read_u32() and stored in the variable "ret" is never used in any meaningful way, and it's also immediately reassigned in the code that follows, the assignment can be removed. Link: https://lore.kernel.org/r/20211003025439.84783-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-09-30PCI: endpoint: Use sysfs_emit() in "show" functionsKunihiko Hayashi
Convert sprintf() in sysfs "show" functions to sysfs_emit() in order to check for buffer overruns in sysfs outputs. Link: https://lore.kernel.org/r/1630472957-26857-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-09-30PCI: xgene: Use PCI_VENDOR_ID_AMCC macroPali Rohár
Header file linux/pci_ids.h defines AMCC vendor id (0x10e8) macro named PCI_VENDOR_ID_AMCC. So use this macro instead of driver custom macro. Link: https://lore.kernel.org/r/20210927134356.11799-1-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-09-30PCI: dra7xx: Get an optional clockLuca Ceresoli
If the clock is provided externally we need to make sure it is enabled before starting PCI scan. Link: https://lore.kernel.org/r/20210531085934.2662457-5-luca@lucaceresoli.net Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2021-09-30PCI: dra7xx: Remove unused includeLuca Ceresoli
Unused since commit e259c2926c01 ("PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver"). Link: https://lore.kernel.org/r/20210531085934.2662457-4-luca@lucaceresoli.net Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2021-09-30PCI: dra7xx: Make it a kernel moduleLuca Ceresoli
Enable building the driver as a loadable kernel module. Link: https://lore.kernel.org/r/20210531085934.2662457-3-luca@lucaceresoli.net Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
generated by cgit (git 2.34.1) at 2025-09-27 18:40:22 +0000