summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2021-12-09PCI/MSI: Split out irqdomain codeThomas Gleixner
Move the irqdomain specific code into its own file. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.817754783@linutronix.de
2021-12-09PCI/MSI: Split out !IRQDOMAIN codeThomas Gleixner
Split out the non irqdomain code into its own file. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.763574089@linutronix.de
2021-12-09PCI/MSI: Split out CONFIG_PCI_MSI independent partThomas Gleixner
These functions are required even when CONFIG_PCI_MSI is not set. Move them to their own file. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.710137730@linutronix.de
2021-12-09PCI/MSI: Move code into a separate directoryThomas Gleixner
msi.c is getting larger and really could do with a splitup. Move it into its own directory to prepare for that. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.655043033@linutronix.de
2021-12-09PCI/MSI: Make msix_update_entries() smarterThomas Gleixner
No need to walk the descriptors and check for each one whether the entries pointer function argument is NULL. Do it once. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.600351129@linutronix.de
2021-12-09PCI/MSI: Cleanup include zooThomas Gleixner
Get rid of the pile of unneeded includes which accumulated over time. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.539281124@linutronix.de
2021-12-09PCI/MSI: Make arch_restore_msi_irqs() less horrible.Thomas Gleixner
Make arch_restore_msi_irqs() return a boolean which indicates whether the core code should restore the MSI message or not. Get rid of the indirection in x86. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # PCI Link: https://lore.kernel.org/r/20211206210224.485668098@linutronix.de
2021-12-09genirq/msi, treewide: Use a named struct for PCI/MSI attributesThomas Gleixner
The unnamed struct sucks and is in the way of further cleanups. Stick the PCI related MSI data into a real data structure and cleanup all users. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211206210224.374863119@linutronix.de
2021-12-09PCI/sysfs: Use pci_irq_vector()Thomas Gleixner
instead of fiddling with MSI descriptors. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.265589103@linutronix.de
2021-12-09PCI/MSI: Remove msi_desc_to_pci_sysdata()Thomas Gleixner
Last user is gone long ago. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210224.210768199@linutronix.de
2021-12-09PCI/MSI: Make pci_msi_domain_write_msg() staticThomas Gleixner
There is no point to have this function public as it is set by the PCI core anyway when a PCI/MSI irqdomain is created. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # PCI Link: https://lore.kernel.org/r/20211206210224.157070464@linutronix.de
2021-12-09PCI/MSI: Fix pci_irq_vector()/pci_irq_get_affinity()Thomas Gleixner
pci_irq_vector() and pci_irq_get_affinity() use the list position to find the MSI-X descriptor at a given index. That's correct for the normal case where the entry number is the same as the list position. But it's wrong for cases where MSI-X was allocated with an entries array describing sparse entry numbers into the hardware message descriptor table. That's inconsistent at best. Make it always check the entry number because that's what the zero base index really means. This change won't break existing users which use a sparse entries array for allocation because these users retrieve the Linux interrupt number from the entries array after allocation and none of them uses pci_irq_vector() or pci_irq_get_affinity(). Fixes: aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210223.929792157@linutronix.de
2021-12-08Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski
Daniel Borkmann says: ==================== bpf 2021-12-08 We've added 12 non-merge commits during the last 22 day(s) which contain a total of 29 files changed, 659 insertions(+), 80 deletions(-). The main changes are: 1) Fix an off-by-two error in packet range markings and also add a batch of new tests for coverage of these corner cases, from Maxim Mikityanskiy. 2) Fix a compilation issue on MIPS JIT for R10000 CPUs, from Johan Almbladh. 3) Fix two functional regressions and a build warning related to BTF kfunc for modules, from Kumar Kartikeya Dwivedi. 4) Fix outdated code and docs regarding BPF's migrate_disable() use on non- PREEMPT_RT kernels, from Sebastian Andrzej Siewior. 5) Add missing includes in order to be able to detangle cgroup vs bpf header dependencies, from Jakub Kicinski. 6) Fix regression in BPF sockmap tests caused by missing detachment of progs from sockets when they are removed from the map, from John Fastabend. 7) Fix a missing "no previous prototype" warning in x86 JIT caused by BPF dispatcher, from Björn Töpel. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Add selftests to cover packet access corner cases bpf: Fix the off-by-two error in range markings treewide: Add missing includes masked by cgroup -> bpf dependency tools/resolve_btfids: Skip unresolved symbol warning for empty BTF sets bpf: Fix bpf_check_mod_kfunc_call for built-in modules bpf: Make CONFIG_DEBUG_INFO_BTF depend upon CONFIG_BPF_SYSCALL mips, bpf: Fix reference to non-existing Kconfig symbol bpf: Make sure bpf_disable_instrumentation() is safe vs preemption. Documentation/locking/locktypes: Update migrate_disable() bits. bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap bpf, sockmap: Attach map progs to psock early for feature probes bpf, x86: Fix "no previous prototype" warning ==================== Link: https://lore.kernel.org/r/20211208155125.11826-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-07PCI: apple: Fix PERST# polarityMarc Zyngier
Now that PERST# is properly defined as active-low in the device tree, fix the driver to correctly drive the line independently of the implied polarity. Suggested-by: Pali Rohár <pali@kernel.org> Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Link: https://lore.kernel.org/r/20211123180636.80558-4-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
2021-12-07PCI: apple: Follow the PCIe specifications when resetting the portMarc Zyngier
While the Apple PCIe driver works correctly when directly booted from the firmware, it fails to initialise when the kernel is booted from a bootloader using PCIe such as u-boot. That's because we're missing a proper reset of the port (we only clear the reset, but never assert it). The PCIe spec requirements are two-fold: - PERST# must be asserted before setting up the clocks and stay asserted for at least 100us (Tperst-clk) - Once PERST# is deasserted, the OS must wait for at least 100ms "from the end of a Conventional Reset" before we can start talking to the devices Implementing this results in a booting system. [bhelgaas: #PERST -> PERST#, update spec references to current] Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Link: https://lore.kernel.org/r/20211123180636.80558-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Pali Rohár <pali@kernel.org> Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-06PCI: pci-bridge-emul: Set PCI_STATUS_CAP_LIST for PCIe devicePali Rohár
Since all PCI Express device Functions are required to implement the PCI Express Capability structure, Capabilities List bit in PCI Status Register must be hardwired to 1b. Capabilities Pointer register (which is already set by pci-bride-emul.c driver) is valid only when Capabilities List is set to 1b. Link: https://lore.kernel.org/r/20211124155944.1290-7-pali@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-12-06PCI: pci-bridge-emul: Correctly set PCIe capabilitiesPali Rohár
Older mvebu hardware provides PCIe Capability structure only in version 1. New mvebu and aardvark hardware provides it in version 2. So do not force version to 2 in pci_bridge_emul_init() and rather allow drivers to set correct version. Drivers need to set version in pcie_conf.cap field without overwriting PCI_CAP_LIST_ID register. Both drivers (mvebu and aardvark) do not provide slot support yet, so do not set PCI_EXP_FLAGS_SLOT flag. Link: https://lore.kernel.org/r/20211124155944.1290-6-pali@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-12-06PCI: pci-bridge-emul: Fix definitions of reserved bitsPali Rohár
Some bits in PCI_EXP registers are reserved for non-root ports. Driver pci-bridge-emul.c implements PCIe Root Port device therefore it should not allow setting reserved bits of registers. Properly define non-reserved bits for all PCI_EXP registers. Link: https://lore.kernel.org/r/20211124155944.1290-5-pali@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-12-06PCI: pci-bridge-emul: Properly mark reserved PCIe bits in PCI config spacePali Rohár
Some bits in PCI config space are reserved when device is PCIe. Properly define behavior of PCI registers for PCIe emulated bridge and ensure that it would not be possible change these reserved bits. Link: https://lore.kernel.org/r/20211124155944.1290-3-pali@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-12-06PCI: pci-bridge-emul: Make expansion ROM Base Address register read-onlyPali Rohár
If expansion ROM is unsupported (which is the case of pci-bridge-emul.c driver) then ROM Base Address register must be implemented as read-only register that return 0 when read, same as for unused Base Address registers. Link: https://lore.kernel.org/r/20211124155944.1290-2-pali@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-12-06PCI: qcom-ep: 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-qcom-ep.c:556:2-9: line 556 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/20211027112931.37182-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-06PCI: apple: Fix REFCLK1 enable/poll logicHector Martin
REFCLK1 has req/ack bits that need to be programmed, just like REFCLK0. Link: https://lore.kernel.org/r/20211117140044.193865-1-marcan@marcan.st Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up") Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org>
2021-12-06PCI: qcom: Use __be16 type to store return value from cpu_to_be16()Manivannan Sadhasivam
cpu_to_be16() returns __be16 value but the driver uses u16 and that's incorrect. Fix it by using __be16 as the data type of bdf_be variable. The issue was spotted by the below sparse warning: sparse warnings: (new ones prefixed by >>) >> drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned short [usertype] bdf_be @@ got restricted __be16 [usertype] @@ drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse: expected unsigned short [usertype] bdf_be drivers/pci/controller/dwc/pcie-qcom.c:1305:30: sparse: got restricted __be16 [usertype] Link: https://lore.kernel.org/r/20211130080924.266116-1-manivannan.sadhasivam@linaro.org Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-12-06PCI: aardvark: Fix checking for MEM resource typePali Rohár
IORESOURCE_MEM_64 is not a resource type but a type flag. Remove incorrect check for type IORESOURCE_MEM_64. Link: https://lore.kernel.org/r/20211125160148.26029-2-kabel@kernel.org Fixes: 64f160e19e92 ("PCI: aardvark: Configure PCIe resources from 'ranges' DT property") 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>
2021-12-04memremap: remove support for external pgmap refcountsChristoph Hellwig
No driver is left using the external pgmap refcount, so remove the code to support it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211028151017.50234-1-hch@lst.de Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-12-03treewide: Add missing includes masked by cgroup -> bpf dependencyJakub Kicinski
cgroup.h (therefore swap.h, therefore half of the universe) includes bpf.h which in turn includes module.h and slab.h. Since we're about to get rid of that dependency we need to clean things up. v2: drop the cpu.h include from cacheinfo.h, it's not necessary and it makes riscv sensitive to ordering of include files. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Krzysztof Wilczyński <kw@linux.com> Acked-by: Peter Chen <peter.chen@kernel.org> Acked-by: SeongJae Park <sj@kernel.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/all/20211120035253.72074-1-kuba@kernel.org/ # v1 Link: https://lore.kernel.org/all/20211120165528.197359-1-kuba@kernel.org/ # cacheinfo discussion Link: https://lore.kernel.org/bpf/20211202203400.1208663-1-kuba@kernel.org
2021-12-02PCI: aardvark: Disable common PHY when unbinding driverPali Rohár
Disable the PCIe PHY when unbinding driver. This should save some power. Link: https://lore.kernel.org/r/20211130172913.9727-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>
2021-12-02PCI: aardvark: Disable link training when unbinding driverPali Rohár
Disable link training circuit in driver unbind sequence. We want to leave link training in the same state as it was before the driver was probed. Link: https://lore.kernel.org/r/20211130172913.9727-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>
2021-12-02PCI: aardvark: Assert PERST# when unbinding driverPali Rohár
Put the PCIe card into reset by asserting PERST# signal when unbinding driver. It doesn't make sense to leave the card working if it can't communicate with the host. This should also save some power. Link: https://lore.kernel.org/r/20211130172913.9727-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>
2021-12-02PCI: aardvark: Fix memory leak in driver unbindPali Rohár
Free config space for emulated root bridge when unbinding driver to fix memory leak. Do it after disabling and masking all interrupts, since aardvark interrupt handler accesses config space of emulated root bridge. Link: https://lore.kernel.org/r/20211130172913.9727-9-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>
2021-12-02PCI: aardvark: Mask all interrupts when unbinding driverPali Rohár
Ensure that no interrupt can be triggered after driver unbind. Link: https://lore.kernel.org/r/20211130172913.9727-8-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>
2021-12-02PCI: aardvark: Disable bus mastering when unbinding driverPali Rohár
Ensure that after driver unbind PCIe cards are not able to forward memory and I/O requests in the upstream direction. Link: https://lore.kernel.org/r/20211130172913.9727-7-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>
2021-12-02PCI: aardvark: Comment actions in driver remove methodPali Rohár
Add two more comments into the advk_pcie_remove() method. Link: https://lore.kernel.org/r/20211130172913.9727-6-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>
2021-12-02PCI: aardvark: Clear all MSIs at setupPali Rohár
We already clear all the other interrupts (ISR0, ISR1, HOST_CTRL_INT). Define a new macro PCIE_MSI_ALL_MASK and do the same clearing for MSIs, to ensure that we don't start receiving spurious interrupts. Use this new mask in advk_pcie_handle_msi(); Link: https://lore.kernel.org/r/20211130172913.9727-5-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>
2021-12-02PCI: aardvark: Add support for DEVCAP2, DEVCTL2, LNKCAP2 and LNKCTL2 ↵Pali Rohár
registers on emulated bridge PCI aardvark hardware supports access to DEVCAP2, DEVCTL2, LNKCAP2 and LNKCTL2 configuration registers of PCIe core via PCIE_CORE_PCIEXP_CAP. Export them via emulated software root bridge. Link: https://lore.kernel.org/r/20211130172913.9727-4-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>
2021-12-02PCI: pci-bridge-emul: Add definitions for missing capabilities registersPali Rohár
pci-bridge-emul driver already allocates buffer for capabilities up to the PCI_EXP_SLTSTA2 register, but does not define bit access behavior for these registers. Add these missing definitions. Link: https://lore.kernel.org/r/20211130172913.9727-3-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>
2021-12-02PCI: pci-bridge-emul: Add description for class_revision fieldPali Rohár
The current assignment to the class_revision member class_revision |= cpu_to_le32(PCI_CLASS_BRIDGE_PCI << 16); can make the reader think that class is at high 16 bits of the member and revision at low 16 bits. In reality, class is at high 24 bits, but the class for PCI Bridge Normal Decode is PCI_CLASS_BRIDGE_PCI << 8. Change the assignment and add a comment to make this clearer. Link: https://lore.kernel.org/r/20211130172913.9727-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>
2021-12-02PCI: dwc: Do not remap invalid resTim Harvey
On imx6 and perhaps others when pcie probes you get a: imx6q-pcie 33800000.pcie: invalid resource This occurs because the atu is not specified in the DT and as such it should not be remapped. Link: https://lore.kernel.org/r/20211101180243.23761-1-tharvey@gateworks.com Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com>
2021-12-01Revert "PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge"Marek Behún
This reverts commit 239edf686c14a9ff926dec2f350289ed7adfefe2. 239edf686c14 ("PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge") added support for the Type 1 Expansion ROM BAR at config offset 0x38, based on the register being listed in the Marvell Armada A3720 spec. But the spec doesn't document it at all for RC mode, and there is no ROM in the SOC, so remove this emulation for now. The PCI bridge which represents aardvark's PCIe Root Port has an Expansion ROM Base Address register at offset 0x30, but its meaning is different than PCI's Expansion ROM BAR register, although the layout is the same. (This is why we thought it does the same thing.) First: there is no ROM (or part of BootROM) in the A3720 SOC dedicated for PCIe Root Port (or controller in RC mode) containing executable code that would initialize the Root Port, suitable for execution in bootloader (this is how Expansion ROM BAR is used on x86). Second: in A3720 spec the register (address 0xD0070030) is not documented at all for Root Complex mode, but similar to other BAR registers, it has an "entangled partner" in register 0xD0075920, which does address translation for the BAR in 0xD0070030: - the BAR register sets the address from the view of PCIe bus - the translation register sets the address from the view of the CPU The other BAR registers also have this entangled partner, and they can be used to: - in RC mode: address-checking on the receive side of the RC (they can define address ranges for memory accesses from remote Endpoints to the RC) - in Endpoint mode: allow the remote CPU to access memory on A3720 The Expansion ROM BAR has only the Endpoint part documented, but from the similarities we think that it can also be used in RC mode in that way. So either Expansion ROM BAR has different meaning (if the hypothesis above is true), or we don't know it's meaning (since it is not documented for RC mode). Remove the register from the emulated bridge accessing functions. [bhelgaas: summarize reason for removal (first paragraph)] Fixes: 239edf686c14 ("PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge") Link: https://lore.kernel.org/r/20211125160148.26029-3-kabel@kernel.org Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pali Rohár <pali@kernel.org>
2021-12-01PCI: mvebu: Remove custom mvebu_pci_host_probe() functionPali Rohár
Now after pci_ioremap_io() usage was replaced by devm_pci_remap_iospace() function, there is no need to use custom mvebu_pci_host_probe() function. Current implementation of mvebu_pci_host_probe() is same as standard PCI core function pci_host_probe(). So replace mvebu_pci_host_probe() call by pci_host_probe() and remove custom mvebu_pci_host_probe() function. Link: https://lore.kernel.org/r/20211124154116.916-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-01PCI: rcar: Check if device is runtime suspended instead of __clk_is_enabled()Marek Vasut
Replace __clk_is_enabled() with pm_runtime_suspended(), as __clk_is_enabled() was checking the wrong bus clock and caused the following build error too: arm-linux-gnueabi-ld: drivers/pci/controller/pcie-rcar-host.o: in function `rcar_pcie_aarch32_abort_handler': pcie-rcar-host.c:(.text+0xdd0): undefined reference to `__clk_is_enabled' Link: https://lore.kernel.org/r/20211115204641.12941-1-marek.vasut@gmail.com Fixes: a115b1bd3af0 ("PCI: rcar: Add L1 link state fix into data abort hook") Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2021-12-01PCI: vmd: Clean up domain before enumerationNirmal Patel
During VT-d pass-through, the VMD driver occasionally fails to enumerate underlying NVMe devices when repetitive reboots are performed in the guest OS. The issue can be resolved by resetting VMD root ports for proper enumeration and triggering secondary bus reset which will also propagate reset through downstream bridges. Link: https://lore.kernel.org/r/20211116221136.85134-1-nirmal.patel@linux.intel.com Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Jon Derrick <jonathan.derrick@linux.dev>
2021-12-01PCI: xilinx-nwl: Simplify code and fix a memory leakChristophe JAILLET
Allocate space for bitmap in struct nwl_msi at probe time instead of dynamically allocating the memory at runtime. This simplifies code (especially error handling paths) and avoid some open-coded arithmetic in allocator arguments. This also fixes a potential memory leak. The bitmap was never freed. It is now part of a managed resource. Link: https://lore.kernel.org/r/5483f10a44b06aad55728576d489adfa16c3be91.1636279388.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-11-30PCI: apple: Enable clock gatingHector Martin
These pokes are not required to make the PCIe port work, but it sounds like this should save some power at least. Link: https://lore.kernel.org/r/20211117141916.197192-1-marcan@marcan.st Tested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org>
2021-11-30PCI: xgene: Fix IB window setupRob Herring
Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") broke PCI support on XGene. The cause is the IB resources are now sorted in address order instead of being in DT dma-ranges order. The result is which inbound registers are used for each region are swapped. I don't know the details about this h/w, but it appears that IB region 0 registers can't handle a size greater than 4GB. In any case, limiting the size for region 0 is enough to get back to the original assignment of dma-ranges to regions. Link: https://lore.kernel.org/all/CA+enf=v9rY_xnZML01oEgKLmvY1NGBUUhnSJaETmXtDtXfaczA@mail.gmail.com/ Link: https://lore.kernel.org/r/20211129173637.303201-1-robh@kernel.org Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") Reported-by: Stéphane Graber <stgraber@ubuntu.com> Tested-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Cc: stable@vger.kernel.org # v5.5+
2021-11-30PCI: mvebu: Replace pci_ioremap_io() usage by devm_pci_remap_iospace()Pali Rohár
Now when ARM architecture code also provides standard PCI core function pci_remap_iospace(), use its devm_pci_remap_iospace() variant in pci-mvebu.c driver instead of old ARM-specific pci_ioremap_io() function. Call devm_pci_remap_iospace() before adding IO resource to host bridge structure, at the place where it should be. Link: https://lore.kernel.org/r/20211124154116.916-3-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-11-29PCI: xgene-msi: Use bitmap_zalloc() when applicableChristophe JAILLET
'xgene_msi->bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Link: https://lore.kernel.org/r/32f3bc1fbfbd6ee0815e565012904758ca9eff7e.1635019243.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-11-29PCI: qcom: Fix an error handling path in 'qcom_pcie_probe()'Christophe JAILLET
If 'of_device_get_match_data()' fails, previous 'pm_runtime_get_sync()/ pm_runtime_enable()' should be undone. To fix it, the easiest is to move this block of code before the memory allocations and the pm_runtime_xxx calls. Link: https://lore.kernel.org/r/4d03c636193f64907c8dacb17fa71ed05fd5f60c.1636220582.git.christophe.jaillet@wanadoo.fr Fixes: b89ff410253d ("PCI: qcom: Replace ops with struct pcie_cfg in pcie match data") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
2021-11-29PCI: mediatek-gen3: Disable DVFSRC voltage requestJianjun Wang
When the DVFSRC (dynamic voltage and frequency scaling resource collector) feature is not implemented, the PCIe hardware will assert a voltage request signal when exit from the L1 PM Substates to request a specific Vcore voltage, but cannot receive the voltage ready signal, which will cause the link to fail to exit the L1 PM Substates. Disable DVFSRC voltage request by default, we need to find a common way to enable it in the future. Link: https://lore.kernel.org/r/20211015063602.29058-1-jianjun.wang@mediatek.com Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192") Tested-by: Qizhong Cheng <qizhong.cheng@mediatek.com> Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-11-24PCI: Convert to device_create_managed_software_node()Heikki Krogerus
In quirk_huawei_pcie_sva(), device_add_properties() is used to inject additional device properties, but there is no device_remove_properties() call anywhere to remove those properties. The assumption is most likely that the device is never removed, and the properties therefore do not also never need to be removed. Even though it is unlikely that the device is ever removed in this case, it is safer to make sure that the properties are also removed if the device ever does get unregistered. To achieve this, instead of adding a separate quirk for the case of device removal where device_remove_properties() is called, using device_create_managed_software_node() instead of device_add_properties(). Both functions create a software node (a type of fwnode) that holds the device properties, which is then assigned to the device very much the same way. The difference between the two functions is, that device_create_managed_software_node() guarantees that the software node (together with the properties) is removed when the device is removed. The function device_add_property() does not guarantee that, so the properties added with it should always be removed with device_remove_properties(). Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>