aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'pci/sparc'Bjorn Helgaas2018-04-04
|\ | | | | | | | | | | | | | | | | | | - support arbitrary PCI host bridge offsets on sparc (Yinghai Lu) - remove System and Video ROM reservations on sparc (Bjorn Helgaas) * pci/sparc: sparc/PCI: Stop reserving System ROM and Video ROM in PCI space sparc/PCI: Support arbitrary host bridge address offset
| * sparc/PCI: Stop reserving System ROM and Video ROM in PCI spaceBjorn Helgaas2018-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, pci_register_legacy_regions() reserved PCI address space under every PCI host bridge for the System ROM and the Video ROM, but these regions are not part of PCI address space. Previously, pci_register_legacy_regions() reserved the following areas of PCI address space under every PCI host bridge: [bus 0xa0000-0xbffff] Video RAM area (VGA frame buffer) [bus 0xc0000-0xc7fff] Video ROM [bus 0xf0000-0xfffff] System ROM It does need to reserve the [bus 0xa0000-0xbffff] region (at least if there's a possibility of a VGA device below the bridge) because VGA devices can respond to that even if they don't describe it with a BAR. But the Video ROM and System ROM areas don't seem necessary because they are not areas that legacy PCI devices respond to. They appear to be copied from x86, where they describe areas of system memory that depend on BIOS conventions. On x86, BIOS copies the option ROM of the primary VGA device to RAM at 0xc0000, and the 0xf0000-0xfffff region is reserved for the motherboard BIOS. Neither of these things applies to sparc. Stop reserving the System ROM and Video ROM regions in PCI space. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net>
| * sparc/PCI: Support arbitrary host bridge address offsetYinghai Lu2018-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for arbitrary bus address offset. Previously we ignored the child (PCI) address in the "ranges" property and assumed it was always zero. That means every host bridge window mapped to PCI bus address zero, e.g., pci_bus 0000:00: root bus resource [mem 0x2000000000000-0x200007fffffff] (bus address [0x00000000-0x7fffffff]) But some systems have host bridge windows with non-zero child addresses, so parse the child address and compute the offset between the parent (CPU) and child (PCI) addresses. This allows windows like these: /pci@305: PCI MEM [mem 0x2000000100000-0x200007effffff] offset 2000000000000 pci_sun4v f02ae7f8: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [mem 0x2000000100000-0x200007effffff] (bus address [0x00100000-0x7effffff]) [bhelgaas: changelog] Tested-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org
* | Merge branch 'pci/resource-mmap'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | - use generic pci_mmap_resource_range() instead of powerpc and xtensa arch-specific versions (David Woodhouse) * pci/resource-mmap: xtensa/PCI: Use generic pci_mmap_resource_range() powerpc/pci: Use generic pci_mmap_resource_range()
| * | xtensa/PCI: Use generic pci_mmap_resource_range()David Woodhouse2018-02-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Remove the xtensa-specific pci_mmap_page_range() and use the generic pci_mmap_resource_range() instead. Xtensa can mmap I/O port space, so supply the xtensa-specific pci_iobar_pfn() required to make that work. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com>
| * | powerpc/pci: Use generic pci_mmap_resource_range()David Woodhouse2018-02-28
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Remove the powerpc-specific pci_mmap_page_range() and use the generic pci_mmap_resource_range() instead. Powerpc can mmap I/O port space, so supply the powerpc-specific pci_iobar_pfn() required to make that work. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
* | Merge branch 'pci/portdrv'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - move pcieport_if.h to drivers/pci/pcie/ to encapsulate it (Frederick Lawler) - merge pcieport_if.h into portdrv.h (Bjorn Helgaas) - move workaround for BIOS PME issue from portdrv to PCI core (Bjorn Helgaas) - completely disable portdrv with "pcie_ports=compat" (Bjorn Helgaas) - remove portdrv link order dependency (Bjorn Helgaas) - remove support for unused VC portdrv service (Bjorn Helgaas) - simplify portdrv feature permission checking (Bjorn Helgaas) - remove "pcie_hp=nomsi" parameter (use "pci=nomsi" instead) (Bjorn Helgaas) - remove unnecessary "pcie_ports=auto" parameter (Bjorn Helgaas) - use cached AER capability offset (Frederick Lawler) - don't enable DPC if BIOS hasn't granted AER control (Mika Westerberg) - rename pcie-dpc.c to dpc.c (Bjorn Helgaas) * pci/portdrv: PCI/DPC: Rename from pcie-dpc.c to dpc.c PCI/DPC: Do not enable DPC if AER control is not allowed by the BIOS PCI/AER: Use cached AER Capability offset PCI/portdrv: Rename and reverse sense of pcie_ports_auto PCI/portdrv: Encapsulate pcie_ports_auto inside the port driver PCI/portdrv: Remove unnecessary "pcie_ports=auto" parameter PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter PCI/portdrv: Remove unnecessary include of <linux/pci-aspm.h> PCI/portdrv: Simplify PCIe feature permission checking PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC PCI/portdrv: Remove pcie_port_bus_type link order dependency PCI/portdrv: Disable port driver in compat mode PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver PCI/PM: Move pcie_clear_root_pme_status() to core PCI/portdrv: Merge pcieport_if.h into portdrv.h PCI/portdrv: Move pcieport_if.h to drivers/pci/pcie/ Conflicts: drivers/pci/pcie/Makefile drivers/pci/pcie/portdrv.h
| * | PCI/DPC: Rename from pcie-dpc.c to dpc.cBjorn Helgaas2018-03-31
| | | | | | | | | | | | | | | | | | Rename pcie-dpc.c to dpc.c. The path "drivers/pci/pcie/pcie-dpc.c" has more occurrences of "pci" than necessary. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/DPC: Do not enable DPC if AER control is not allowed by the BIOSMika Westerberg2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit eed85ff4c0da ("PCI/DPC: Enable DPC only if AER is available") made DPC control dependent whether AER is enabled in the OS. However, it does not take into account situations where BIOS has not given OS control of AER: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: platform does not support [AER] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] I think here it is better not to enable DPC even if the capability is available because then it would be against what "Determination of DPC Control" note in PCIe 4.0 sec 6.1.10 recommends. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
| * | PCI/AER: Use cached AER Capability offsetFrederick Lawler2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace pci_find_ext_capability(..., PCI_EXT_CAP_ID_ERR) calls with pci_dev->aer_cap. pci_dev->aer_cap is initialized in pci_init_capabilities(), which happens before any of these users of the AER Capability. Signed-off-by: Frederick Lawler <fred@fredlawl.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/portdrv: Rename and reverse sense of pcie_ports_autoBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The platform may restrict the OS's use of PCIe services, e.g., via the ACPI _OSC method. The user may use "pcie_ports=native" to force the port driver to use PCIe services even if the platform asked us not to. The "pcie_ports=native" parameter determines the setting of pcie_ports_auto. Rename this to pcie_ports_native and reverse the sense to simplify the code. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/portdrv: Encapsulate pcie_ports_auto inside the port driverBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | "pcie_ports_auto" is only used inside the PCIe port driver itself, so move it from include/linux/pci.h to portdrv.h so it's not visible to the whole kernel. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/portdrv: Remove unnecessary "pcie_ports=auto" parameterBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "pcie_ports=auto" parameter set pcie_ports_disabled and pcie_ports_auto to their compiled-in defaults, so specifying the parameter is the same as not using it at all. Remove the "pcie_ports=auto" parameter and update the documentation. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameterBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7570a333d8b0 ("PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver") added the "pcie_hp=nomsi" kernel parameter to work around this error on shutdown: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 1081, comm: reboot Not tainted 3.2.0 #1 ... Disabling IRQ #16 This happened on an unspecified system (possibly involving the Integrated Device Technology, Inc. Device 807f bridge) where "an un-wanted interrupt is generated when PCI driver switches from MSI/MSI-X to INTx while shutting down the device." The implication was that the device was buggy, but it is normal for a device to use INTx after MSI/MSI-X have been disabled. The only problem was that the driver was still attached and it wasn't prepared for INTx interrupts. Prarit Bhargava fixed this issue with fda78d7a0ead ("PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()"). There is no automated way to set this parameter, so it's not very useful for distributions or end users. It's really only useful for debugging, and we have "pci=nomsi" for that purpose. Revert 7570a333d8b0 to remove the "pcie_hp=nomsi" parameter. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> CC: Prarit Bhargava <prarit@redhat.com>
| * | PCI/portdrv: Remove unnecessary include of <linux/pci-aspm.h>Bjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | portdrv_pci.c doesn't use anything from <linux/pci-aspm.h>. Remove the include of it. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | PCI/portdrv: Simplify PCIe feature permission checkingBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the platform firmware or the OS, so the host bridge driver may have to request permission from the platform before using them. On ACPI systems, this is done by negotiate_os_control() in acpi_pci_root_add(). The PCIe port driver later uses pcie_port_platform_notify() and pcie_port_acpi_setup() to figure out whether it can use these features. But all we need is a single bit for each service, so these interfaces are needlessly complicated. Simplify this by adding bits in the struct pci_host_bridge to show when the OS has permission to use each feature: + unsigned int native_aer:1; /* OS may use PCIe AER */ + unsigned int native_hotplug:1; /* OS may use PCIe hotplug */ + unsigned int native_pme:1; /* OS may use PCIe PME */ These are set when we create a host bridge, and the host bridge driver can clear the bits corresponding to any feature the platform doesn't want us to use. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VCBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No driver registers for PCIE_PORT_SERVICE_VC, so remove it. This removes the VC "service" files from /sys/bus/pci_express/devices, e.g., 0000:07:00.0:pcie108, 0000:08:04.0:pcie208 (all the files that contained "8" as the last digit of the "pcieXXX" part). The port driver created these files for PCIe port devices that have a VC Capability. Since this reduces PCIE_PORT_DEVICE_MAXSERVICES and moves DPC down into the spot where VC used to be, the DPC sysfs files will now be named "pcieXX8". I don't think there's anything useful userspace can do with those files, so I hope nobody cares about these filenames. There is no VC driver that calls pcie_port_service_register(), so there never was a /sys/bus/pci_express/drivers/vc directory. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
| * | PCI/portdrv: Remove pcie_port_bus_type link order dependencyBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pcie_port_bus_type must be registered before drivers that depend on it can be registered. Those drivers include: pcied_init() # PCIe native hotplug driver aer_service_init() # AER driver dpc_service_init() # DPC driver pcie_pme_service_init() # PME driver Previously we registered pcie_port_bus_type from pcie_portdrv_init(), a device_initcall. The callers of pcie_port_service_register() (above) are also device_initcalls. This is fragile because the device_initcall ordering depends on link order, which is not explicit. Register pcie_port_bus_type from pci_driver_init() along with pci_bus_type. This removes the link order dependency between portdrv and the pciehp, AER, DPC, and PCIe PME drivers. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
| * | PCI/portdrv: Disable port driver in compat modeBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "pcie_ports=compat" kernel parameter sets pcie_ports_disabled, which is intended to disable the PCIe port driver. But even when it was disabled, we registered pcie_portdriver so we could work around a BIOS PME issue (see fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system resume")). Registering the driver meant that the pcie_portdrv_probe() path called pci_enable_device(), pci_save_state(), pm_runtime_set_autosuspend_delay(), pm_runtime_use_autosuspend(), etc., even when the driver was disabled. We've since moved the BIOS PME workaround from the port driver to the core, so stop registering the PCIe port driver in compat mode. This means "pcie_ports=compat" will now be basically the same as turning off CONFIG_PCIEPORTBUS completely. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | PCI/PM: Clear PCIe PME Status bit for Root Complex Event CollectorsBjorn Helgaas2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per PCIe r4.0, sec 6.1.6, Root Complex Event Collectors can generate PME interrupts on behalf of Root Complex Integrated Endpoints. Linux does not currently enable PME interrupts from RC Event Collectors, but fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system resume") suggests PME interrupts may be enabled by the platform for ACPI- based runtime wakeup. Clear the PCIe PME Status bit for Root Complex Event Collectors during resume, just like we already do for Root Ports. If the BIOS enables PME interrupts for an event collector and neglects to clear the status bit on resume, this change should fix the same bug as fe31e69740ed (PMEs not working after waking from a sleep state), but for Root Complex Integrated Endpoints. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driverBjorn Helgaas2018-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system resume") added a .resume_noirq() callback to the PCIe port driver to clear the PME Status bit during resume to work around a BIOS issue. The BIOS evidently enabled PME interrupts for ACPI-based runtime wakeups but did not clear the PME Status bit during resume, which meant PMEs after resume did not trigger interrupts because PME Status did not transition from cleared to set. The fix was in the PCIe port driver, so it worked when CONFIG_PCIEPORTBUS was set. But I think we *always* want the fix because the platform may use PME interrupts even if Linux is built without the PCIe port driver. Move the fix from the port driver to the PCI core so we can work around this "PME doesn't work after waking from a sleep state" issue regardless of CONFIG_PCIEPORTBUS. [bhelgaas: folded in warning fix from Arnd Bergmann <arnd@arndb.de>: https://lkml.kernel.org/r/20180328134747.2062348-1-arnd@arndb.de] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI/PM: Move pcie_clear_root_pme_status() to coreBjorn Helgaas2018-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Move pcie_clear_root_pme_status() from the port driver to the PCI core so it will be available even when the port driver isn't present. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
| * | PCI/portdrv: Merge pcieport_if.h into portdrv.hBjorn Helgaas2018-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pcieport_if.h contained the interfaces to register port service driver, e.g., pcie_port_service_register(). portdrv.h contained internal data structures of the port driver. I don't think it's worth keeping those files separate, since both headers and their users are all inside the PCI core. Merge pcieport_if.h directly in drivers/pci/pcie/portdrv.h and update the users to include that instead. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
| * | PCI/portdrv: Move pcieport_if.h to drivers/pci/pcie/Frederick Lawler2018-02-22
| |/ | | | | | | | | | | | | | | | | | | Move pcieport_if.h from include/linux to drivers/pci/pcie/pcieport_if.h because the interfaces there are only used by the PCI core. Replace all uses of #include<linux/pcieport_if.h> with relative paths to the new file location, e.g., #include "../pcieport_if.h" Signed-off-by: Frederick Lawler <fred@fredlawl.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
* | Merge branch 'pci/msi'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | - don't set up INTx if MSI or MSI-X is enabled to align cris, frv, ia64, and mn10300 with x86 (Bjorn Helgaas) * pci/msi: PCI/MSI: Don't set up INTx if MSI or MSI-X is enabled
| * | PCI/MSI: Don't set up INTx if MSI or MSI-X is enabledBjorn Helgaas2018-03-13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If MSI or MSI-X is enabled, the device uses that. It uses INTx only if both MSI and MSI-X are disabled (see PCIe r4.0, sec 7.7.1.2), so if a device already has MSI or MSI-X enabled, there's no need to set up its legacy INTx interrupt. bba6f6fc68e7 ("[PATCH] MSI-X: fix resume crash") changed the cris, frv, x86, and ia64 arches to skip INTx setup when MSI is enabled. The cris and frv arches have since been removed. 16cf0ebc35dd ("x86/PCI: Do not use interrupt links for devices using MSI-X") extended that by changing x86 to also skip INTx setup when MSI-X is enabled. Change ia64 to skip INTx setup when either MSI or MSI-X is enabled by applying the logic from 16cf0ebc35dd to ia64 as well as x86. Tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
* | Merge branch 'pci/misc'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - use PCI_EXP_DEVCTL2_COMP_TIMEOUT in rapidio/tsi721 (Bjorn Helgaas) - remove possible NULL pointer dereference in of_pci_bus_find_domain_nr() (Shawn Lin) - report quirk timings with dev_info (Bjorn Helgaas) - report quirks that take longer than 10ms (Bjorn Helgaas) - add and use Altera Vendor ID (Johannes Thumshirn) - tidy Makefiles and comments (Bjorn Helgaas) * pci/misc: PCI: Always define the of_node helpers PCI: Tidy comments PCI: Tidy Makefiles mcb: Add Altera PCI ID to mcb-pci PCI: Add Altera vendor ID PCI: Report quirks that take more than 10ms PCI: Report quirk timings with pci_info() instead of pr_debug() PCI: Fix NULL pointer dereference in of_pci_bus_find_domain_nr() rapidio/tsi721: use PCI_EXP_DEVCTL2_COMP_TIMEOUT macro
| * | PCI: Always define the of_node helpersBjørn Mork2018-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simply move these inline functions outside the ifdef instead of duplicating them as stubs in the !OF case. The struct device of_node field does not depend on OF. This also fixes the missing stubbed pci_bus_to_OF_node(). Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
| * | PCI: Tidy commentsBjorn Helgaas2018-03-19
| | | | | | | | | | | | | | | | | | | | | Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI: Tidy MakefilesBjorn Helgaas2018-03-19
| | | | | | | | | | | | | | | | | | Indent things so they line up neatly and remove extra blank lines and superfluous comments. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | mcb: Add Altera PCI ID to mcb-pciJohannes Thumshirn2018-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some older PCI-attached MEN FPGAs use an Altera PCI Vendor ID instead of the MEN one. Add it to the PCI ID table so the driver automatically attaches to it. Reported-by: Ben Turner <ben.turner@21net.com> Tested-by: Ben Turner <ben.turner@21net.com> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Andreas Geißler <andreas.geissler@men.de>
| * | PCI: Add Altera vendor IDJohannes Thumshirn2018-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the Altera PCI Vendor id to pci_ids.h and remove the private definitions from xillybus_pcie.c and altera-cvp.c. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Eli Billauer <eli.billauer@gmail.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Anatolij Gustschin <agust@denx.de>
| * | PCI: Report quirks that take more than 10msBjorn Helgaas2018-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With "initcall_debug", we report how long every PCI quirk took. Even without "initcall_debug", report the runtime of any quirk that takes longer than 10ms. This is to make it easier to notice quirks that slow down boot. This was motivated by a report from Paul Menzel that PCI final quirks took half a second at boot. Link: https://lkml.kernel.org/r/44cada166e42007d27b4c3e3aa0744d7@molgen.mpg.de Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI: Report quirk timings with pci_info() instead of pr_debug()Bjorn Helgaas2018-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With "initcall_debug", we report how long every PCI quirk took. Previously we used pr_debug(), which means you have to figure out how to enable debug output. Log these timings using pci_info() instead so it doesn't depend on DEBUG, CONFIG_DYNAMIC_DEBUG, etc. Also, don't log anything at all unless "initcall_debug" is specified. This matches what we do in do_one_initcall_debug(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI: Fix NULL pointer dereference in of_pci_bus_find_domain_nr()Shawn Lin2018-03-01
| | | | | | | | | | | | | | | | | | | | | If the "parent" pointer passed to of_pci_bus_find_domain_nr() is NULL, don't dereference it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | rapidio/tsi721: use PCI_EXP_DEVCTL2_COMP_TIMEOUT macroBjorn Helgaas2018-02-15
| |/ | | | | | | | | | | | | Use the existing PCI_EXP_DEVCTL2_COMP_TIMEOUT macro instead of hard-coding the PCIe Completion Timeout Value mask. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alexandre Bounine <alexandre.bounine@idt.com>
* | Merge branch 'pci/lpc'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - add support for PCI I/O port space that's neither directly accessible via CPU in/out instructions nor directly mapped into CPU physical memory space (Zhichang Yuan) - add support for HiSilicon Hip06/Hip07 LPC I/O space (Zhichang Yuan, John Garry) * pci/lpc: MAINTAINERS: Add John Garry as maintainer for HiSilicon LPC driver HISI LPC: Add ACPI support ACPI / scan: Do not enumerate Indirect IO host children ACPI / scan: Rename acpi_is_serial_bus_slave() for more general use HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings of: Add missing I/O range exception for indirect-IO devices PCI: Apply the new generic I/O management on PCI IO hosts PCI: Add fwnode handler as input param of pci_register_io_range() PCI: Remove __weak tag from pci_register_io_range() lib: Add generic PIO mapping method
| * | MAINTAINERS: Add John Garry as maintainer for HiSilicon LPC driverJohn Garry2018-04-04
| | | | | | | | | | | | | | | | | | | | | Add John Garry as maintainer for drivers/bus/hisi_lpc.c, the HiSilicon LPC driver. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | HISI LPC: Add ACPI supportJohn Garry2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the previous patches, this patch supports the LPC host on Hip06/Hip07 for ACPI FW. It is the responsibility of the LPC host driver to enumerate the child devices, as the ACPI scan code will not enumerate children of "indirect IO" hosts. The ACPI table for the LPC host controller and the child devices is in the following format: Device (LPC0) { Name (_HID, "HISI0191") // HiSi LPC Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xa01b0000, 0x1000) }) } Device (LPC0.IPMI) { Name (_HID, "IPI0001") Name (LORS, ResourceTemplate() { QWordIO ( ResourceConsumer, MinNotFixed, // _MIF MaxNotFixed, // _MAF PosDecode, EntireRange, 0x0, // _GRA 0xe4, // _MIN 0x3fff, // _MAX 0x0, // _TRA 0x04, // _LEN , , BTIO ) }) Since the IO resources of the child devices need to be translated from LPC bus addresses to logical PIO addresses, and we shouldn't modify the resources of the devices generated in the FW scan, a per-child MFD is created as a substitute. The MFD IO resources will be the translated bus addresses of the ACPI child. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
| * | ACPI / scan: Do not enumerate Indirect IO host childrenJohn Garry2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Through the logical PIO framework, systems which otherwise have no IO space access to legacy ISA/LPC devices may access these devices through so-called "indirect IO" method. In this, IO space accesses for non-PCI hosts are redirected to a host LLDD to manually generate the IO space (bus) accesses. Hosts are able to register a region in logical PIO space to map to its bus address range. Indirect IO child devices have an associated host-specific bus address. Special translation is required to map between a logical PIO address for a device and its host bus address. Since in the ACPI tables the child device IO resources would be the host-specific values, it is required the ACPI scan code should not enumerate these devices, and that this should be the responsibility of the host driver so that it can "fixup" the resources so that they map to the appropriate logical PIO addresses. To avoid enumerating these child devices, add a check from acpi_device_enumeration_by_parent() as to whether the parent for a device is a member of a known list of "indirect IO" hosts. For now, the HiSilicon LPC host controller ID is added. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / scan: Rename acpi_is_serial_bus_slave() for more general useJohn Garry2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the ACPI scan has special handling for serial bus slaves, in that it makes it the responsibility of the slave device's parent to enumerate the device. To support other types of slave devices which require the same special handling but where the bus is not strictly a serial bus, such as devices on the HiSilicon LPC controller bus, rename acpi_is_serial_bus_slave() to acpi_device_enumeration_by_parent(), so that the name can fit the wider purpose. Also rename the associated device flag acpi_device_flags.serial_bus_slave to .enumeration_by_parent. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindingsZhichang Yuan2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The low-pin-count (LPC) interface of Hip06/Hip07 accesses I/O port space of peripherals. Implement the LPC host controller driver which performs the I/O operations on the underlying hardware. We don't want to touch existing drivers such as ipmi-bt, so this driver applies the indirect-IO introduced in the previous patch after registering an indirect-IO node to the indirect-IO devices list which will be searched by the I/O accessors to retrieve the host-local I/O port. The driver config is set as a bool instead of a tristate. The reason here is that, by the very nature of the driver providing a logical PIO range, it does not make sense to have this driver as a loadable module. Another more specific reason is that the Huawei D03 board which includes Hip06 SoC requires the LPC bus for UART console, so should be built in. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zou Rongrong <zourongrong@huawei.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org> # dts part
| * | of: Add missing I/O range exception for indirect-IO devicesZhichang Yuan2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are some special ISA/LPC devices that work on a specific I/O range where it is not correct to specify a 'ranges' property in the DTS parent node as CPU addresses translated from DTS node are only for memory space on some architectures, such as ARM64. Without the parent 'ranges' property, of_translate_address() returns an error. Here we add special handling for this case. During the OF address translation, some checking will be performed to identify whether the device node is registered as indirect-IO. If it is, the I/O translation will be done in a different way from that one of PCI MMIO. In this way, the I/O 'reg' property of the special ISA/LPC devices will be parsed correctly. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> # earlier draft Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
| * | PCI: Apply the new generic I/O management on PCI IO hostsZhichang Yuan2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After introducing the new generic I/O space management (Logical PIO), the original PCI MMIO relevant helpers need to be updated based on the new interfaces defined in logical PIO. Adapt the corresponding code to match the changes introduced by logical PIO. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> # earlier draft Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
| * | PCI: Add fwnode handler as input param of pci_register_io_range()Gabriele Paoloni2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for having the PCI MMIO helpers use the new generic I/O space management (logical PIO) we need to add the fwnode handler as an extra input parameter. Changes the signature of pci_register_io_range() and its callers as needed. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Rob Herring <robh@kernel.org>
| * | PCI: Remove __weak tag from pci_register_io_range()Gabriele Paoloni2018-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | pci_register_io_range() has only one definition, so there is no need for the __weak attribute. Remove it. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
| * | lib: Add generic PIO mapping methodZhichang Yuan2018-03-21
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 41f8bba7f555 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for PCI I/O space mapped into CPU physical memory space. With that support, the I/O ranges configured for PCI/PCIe hosts on some architectures can be mapped to logical PIO and converted easily between CPU address and the corresponding logical PIO. Based on this, PCI I/O port space can be accessed via in/out accessors that use memory read/write. But on some platforms, there are bus hosts that access I/O port space with host-local I/O port addresses rather than memory addresses. Add a more generic I/O mapping method to support those devices. With this patch, both the CPU addresses and the host-local port can be mapped into the logical PIO space with different logical/fake PIOs. After this, all the I/O accesses to either PCI MMIO devices or host-local I/O peripherals can be unified into the existing I/O accessors defined in asm-generic/io.h and be redirected to the right device-specific hooks based on the input logical PIO. Tested-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> [bhelgaas: remove -EFAULT return from logic_pio_register_range() per https://lkml.kernel.org/r/20180403143909.GA21171@ulmo, fix NULL pointer checking per https://lkml.kernel.org/r/20180403211505.GA29612@embeddedor.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
* | Merge branch 'pci/hotplug'Bjorn Helgaas2018-04-04
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - fix possible cpqphp NULL pointer dereference (Shawn Lin) - rescan more of the hierarchy on ACPI hotplug to fix Thunderbolt/xHCI hotplug (Mika Westerberg) * pci/hotplug: ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status() PCI: cpqphp: Fix possible NULL pointer dereference
| * | ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status()Mika Westerberg2018-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mike Lothian reported that plugging in a USB-C device does not work properly in his Dell Alienware system. This system has an Intel Alpine Ridge Thunderbolt controller providing USB-C functionality. In these systems the USB controller (xHCI) is hotplugged whenever a device is connected to the port using ACPI-based hotplug. The ACPI description of the root port in question is as follows: Device (RP01) { Name (_ADR, 0x001C0000) Device (PXSX) { Name (_ADR, 0x02) Method (_RMV, 0, NotSerialized) { // ... } } Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01) but that seems to be incorrect because device 0 is the upstream port of the Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge itself). When we get ACPI Notify() to the root port resulting from connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0, function 2 which of course always returns 0xffffffff because there is no such function and we never find the device. In Windows this works fine. Now, since we get ACPI Notify() to the root port and not to the PXSX device we should actually start our scan from there as well and not from the non-existent PXSX device. Fix this by checking presence of the slot itself (function 0) if we fail to do that otherwise. While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is the recommended way to read Device and Vendor IDs of devices on PCI buses. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198557 Reported-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org
| * | PCI: cpqphp: Fix possible NULL pointer dereferenceShawn Lin2018-02-28
| |/ | | | | | | | | | | Check io_node for NULL before dereferencing it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-30 16:16:22 -0400