kernel/linux.git/include/linux/pci-ecam.h, branch v6.6.132

PCI: loongson: Add ACPI init support

2022-07-14T20:25:36+00:00

Loongson PCH (LS7A chipset) will be used by both MIPS-based and LoongArch- based Loongson processors. MIPS-based Loongson uses FDT, while LoongArch- based Loongson uses ACPI. Add ACPI init support for the driver in pci-loongson.c because it is currently FDT-only. LoongArch is a new RISC ISA, mainline support will come soon, and documentations are here (in translation): https://github.com/loongson/LoongArch-Documentation Link: https://lore.kernel.org/r/20220714124216.1489304-4-chenhuacai@loongson.cn Signed-off-by: Huacai Chen Signed-off-by: Bjorn Helgaas

PCI: Dynamically map ECAM regions

2021-06-16T22:20:40+00:00

Attempting to boot 32-bit ARM kernels under QEMU's 3.x virt models fails when we have more than 512M of RAM in the model as we run out of vmalloc space for the PCI ECAM regions. This failure will be silent when running libvirt, as the console in that situation is a PCI device. In this configuration, the kernel maps the whole ECAM, which QEMU sets up for 256 buses, even when maybe only seven buses are in use. Each bus uses 1M of ECAM space, and ioremap() adds an additional guard page between allocations. The kernel vmap allocator will align these regions to 512K, resulting in each mapping eating 1.5M of vmalloc space. This means we need 384M of vmalloc space just to map all of these, which is very wasteful of resources. Fix this by only mapping the ECAM for buses we are going to be using. In my setups, this is around seven buses in most guests, which is 10.5M of vmalloc space - way smaller than the 384M that would otherwise be required. This also means that the kernel can boot without forcing extra RAM into highmem with the vmalloc= argument, or decreasing the virtual RAM available to the guest. Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/r/E1lhCAV-0002yb-50@rmk-PC.armlinux.org.uk Signed-off-by: Russell King Signed-off-by: Bjorn Helgaas Reviewed-by: Arnd Bergmann

PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata

2021-04-16T16:34:17+00:00

The PCIe controller in Tegra194 SoC is not ECAM-compliant. With the current hardware design, ECAM can be enabled only for one controller (the C5 controller) with bus numbers starting from 160 instead of 0. A different approach is taken to avoid this abnormal way of enabling ECAM for just one controller but to enable configuration space access for all the other controllers. In this approach, ops are added through MCFG quirk mechanism which access the configuration spaces by dynamically programming iATU (internal AddressTranslation Unit) to generate respective configuration accesses just like the way it is done in DesignWare core sub-system. This issue is specific to Tegra194 and it would be fixed in the future generations of Tegra SoCs. Link: https://lore.kernel.org/r/20210416134537.19474-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar Signed-off-by: Bjorn Helgaas

PCI: Unify ECAM constants in native PCI Express drivers

2020-12-10T20:55:49+00:00

Add ECAM-related constants to provide a set of standard constants defining memory address shift values to the byte-level address that can be used to access the PCI Express Configuration Space, and then move native PCI Express controller drivers to use the newly introduced definitions retiring driver-specific ones. Refactor pci_ecam_map_bus() function to use newly added constants so that limits to the bus, device function and offset (now limited to 4K as per the specification) are in place to prevent the defective or malicious caller from supplying incorrect configuration offset and thus targeting the wrong device when accessing extended configuration space. This refactor also allows for the ".bus_shift" initialisers to be dropped when the user is not using a custom value as a default value will be used as per the PCI Express Specification. Thanks to Qian Cai , Michael Walle , and Vladimir Oltean for reporting a pci_ecam_create() issue with .bus_shift and to Vladimir for proposing the fix. [bhelgaas: incorporate Vladimir's fix, update commit log] Suggested-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20201129230743.3006978-2-kw@linux.com Tested-by: Michael Walle Signed-off-by: Krzysztof Wilczyński Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Derrick Reviewed-by: Bjorn Helgaas

PCI/ACPI: Add Ampere Altra SOC MCFG quirk

2020-09-17T17:27:43+00:00

Ampere Altra SOC supports only 32-bit ECAM reads. Add an MCFG quirk for the platform. Link: https://lore.kernel.org/r/1596751055-12316-1-git-send-email-tuanphan@os.amperecomputing.com Signed-off-by: Tuan Phan Signed-off-by: Bjorn Helgaas

PCI: host-generic: Eliminate pci_host_common_probe wrappers

2020-05-07T08:29:43+00:00

Most ECAM host drivers are just different pci_ecam_ops which can be DT match table data. That's already the case in some cases, but let's do that for all the ECAM drivers. Then we can use of_device_get_match_data() in pci_host_common_probe() and eliminate the probe wrapper functions and use pci_host_common_probe() directly for probe. Link: https://lore.kernel.org/r/20200409234923.21598-4-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Acked-by: Bjorn Helgaas Cc: Zhou Wang Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: Will Deacon Cc: Robert Richter Cc: Marc Gonzalez Cc: Mans Rullgard Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org

PCI: host-generic: Support building as modules

2020-05-01T15:29:27+00:00

Enable building host-generic and its host-common dependency as a module. Link: https://lore.kernel.org/r/20200409234923.21598-3-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Acked-by: Will Deacon Acked-by: Bjorn Helgaas Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: Will Deacon Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org

PCI: Constify struct pci_ecam_ops

2020-05-01T15:28:59+00:00

struct pci_ecam_ops is typically DT match table data which is defined to be const. It's also best practice for ops structs to be const. Ideally, we'd make struct pci_ops const as well, but that becomes pretty invasive, so for now we just cast it where needed. Link: https://lore.kernel.org/r/20200409234923.21598-2-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Acked-by: Bjorn Helgaas Acked-by: Catalin Marinas Cc: Catalin Marinas Cc: Will Deacon Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Jonathan Chocron Cc: Zhou Wang Cc: Robert Richter Cc: Toan Le Cc: Marc Gonzalez Cc: Mans Rullgard Cc: linux-acpi@vger.kernel.org

PCI: al: Add Amazon Annapurna Labs PCIe host controller driver

2019-04-25T21:33:07+00:00

Add driver for Amazon's Annapurna Labs PCIe host controller. The controller is based on DesignWare's IP. The controller doesn't support accessing the Root Port's config space via ECAM, so we obtain its base address via an AMZN0001 device. Furthermore, the DesignWare PCIe controller doesn't filter out config transactions sent to devices 1 and up on its bus, so they are filtered by the driver. All subordinate buses do support ECAM access. Implementing specific PCI config access functions involves: - Adding an init function to obtain the Root Port's base address from an AMZN0001 device. - Adding a new entry in the MCFG quirk array. [bhelgaas: Note that there is no Kconfig option for this driver because it is only intended for use with the generic ACPI host bridge driver. This driver is only needed because the DesignWare IP doesn't completely support ECAM access to the root bus.] Link: https://lore.kernel.org/lkml/1553774276-24675-1-git-send-email-jonnyc@amazon.com Co-developed-by: Vladimir Aerov Signed-off-by: Jonathan Chocron Signed-off-by: Vladimir Aerov Signed-off-by: Bjorn Helgaas Reviewed-by: David Woodhouse Reviewed-by: Benjamin Herrenschmidt Acked-by: Lorenzo Pieralisi

PCI: Add support for unbinding the generic PCI host controller

2018-05-30T16:35:23+00:00

Add support for unbinding the generic PCI host controller. This is particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. Signed-off-by: Jan Kiszka Signed-off-by: Bjorn Helgaas CC: Will Deacon CC: Lorenzo Pieralisi