summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2019-04-12PCI: endpoint: Fix a potential NULL pointer dereferenceKangjie Lu
In case alloc_workqueue() fails, return -ENOMEM to avoid potential NULL pointer dereferences. Signed-off-by: Kangjie Lu <kjlu@umn.edu> [lorenzo.pieralisi@arm.com: commit log and code update] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-12PCI/AER: Change pci_aer_init() stub to return voidJisheng Zhang
Commit 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") changed pci_aer_init() to return "void", but didn't change the stub for when CONFIG_PCIEAER isn't enabled. Change the stub to match. Fixes: 60ed982a4e78 ("PCI/AER: Move internal declarations to drivers/pci/pci.h") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.19+
2019-04-11PCI: OF: Support "external-facing" propertyJean-Philippe Brucker
Set the "untrusted" attribute to any PCIe port that has an "external-facing" device tree property. Any device downstream of this port will inherit the attribute and have only the strictest IOMMU protection. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-04-11PCI: Mark AMD Stoney Radeon R7 GPU ATS as brokenNikolai Kostrigin
ATS is broken on the Radeon R7 GPU (at least for Stoney Ridge based laptop) and causes IOMMU stalls and system failure. Disable ATS on these devices to make them usable again with IOMMU enabled. Thanks to Joerg Roedel <jroedel@suse.de> for help. [bhelgaas: In the email thread mentioned below, Alex suspects the real problem is in sbios or iommu, so it may affect only certain systems, and it may affect other devices in those systems as well. However, per Joerg we lack the ability to debug further, so this quirk is the best we can do for now.] Link: https://bugzilla.kernel.org/show_bug.cgi?id=194521 Link: https://lore.kernel.org/lkml/20190408103725.30426-1-nickel@altlinux.org Fixes: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken") Signed-off-by: Nikolai Kostrigin <nickel@altlinux.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Joerg Roedel <jroedel@suse.de> CC: stable@vger.kernel.org
2019-04-11PCI: keystone: Use platform_get_resource_byname() to get memory resourcesKishon Vijay Abraham I
Use platform_get_resource_byname() instead of platform_get_resource() which uses an index to get memory resources. While at that get the memory resource defined specifically for configuration space instead of deriving the configuration space address from dbics address space. Since the pci-keystone driver has never worked in the mainline kernel, DT backward compatibility is not an issue. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-11PCI: keystone: Perform host initialization in a single functionKishon Vijay Abraham I
No functional change. Instead of having two functions ks_pcie_add_pcie_port() and ks_pcie_dw_host_init() for initializing host, have a single function to perform all the host initialization. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-11PCI: keystone: Cleanup error_irq configurationKishon Vijay Abraham I
pci-keystone driver uses irq_of_parse_and_map() to get irq number of error_irq. Use platform_get_irq() instead and move platform_get_irq() and request_irq() of error_irq from ks_pcie_add_pcie_port to ks_pcie_probe since error_irq is common to both RC mode and EP mode. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-11PCI: keystone: Add start_link()/stop_link() dw_pcie_opsKishon Vijay Abraham I
Add start_link()/stop_link() dw_pcie_ops and invoke ks_pcie_start_link() directly from host_init. start_link()/stop_link() ops are required for adding EP mode support. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-11PCI: mediatek: Get optional clocks with devm_clk_get_optional()Chunfeng Yun
Update the driver to use devm_clk_get_optional() to claim optional clocks instead of devm_clk_get(). Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Ryder Lee <ryder.lee@mediatek.com> Acked-by: Honghui Zhang <honghui.zhang@mediatek.com> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Honghui Zhang <honghui.zhang@mediatek.com>
2019-04-10PCI: rpaphp: Get/put device node reference during slot alloc/deallocTyrel Datwyler
When allocating the slot structure we store a pointer to the associated device_node. We really should be incrementing the reference count, so add an of_node_get() during slot alloc and an of_node_put() during slot dealloc. Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-04-10PCI: rpadlpar: Fix leaked device_node references in add/remove pathsTyrel Datwyler
The find_dlpar_node() helper returns a device node with its reference incremented. Both the add and remove paths use this helper for find the appropriate node, but fail to release the reference when done. Annotate the find_dlpar_node() helper with a comment about the incremented reference count and call of_node_put() on the obtained device_node in the add and remove paths. Also, fixup a reference leak in the find_vio_slot() helper where we fail to call of_node_put() on the vdevice node after we iterate over its children. Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-04-10PCI: pciehp: Ignore Link State Changes after powering off a slotSergey Miroshnichenko
During a safe hot remove, the OS powers off the slot, which may cause a Data Link Layer State Changed event. The slot has already been set to OFF_STATE, so that event results in re-enabling the device, making it impossible to safely remove it. Clear out the Presence Detect Changed and Data Link Layer State Changed events when the disabled slot has settled down. It is still possible to re-enable the device if it remains in the slot after pressing the Attention Button by pressing it again. Fixes the problem that Micah reported below: an NVMe drive power button may not actually turn off the drive. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203237 Reported-by: Micah Parrish <micah.parrish@hpe.com> Tested-by: Micah Parrish <micah.parrish@hpe.com> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com> [bhelgaas: changelog, add bugzilla URL] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v4.19+
2019-04-09treewide: Switch printk users from %pf and %pF to %ps and %pS, respectivelySakari Ailus
%pF and %pf are functionally equivalent to %pS and %ps conversion specifiers. The former are deprecated, therefore switch the current users to use the preferred variant. The changes have been produced by the following command: git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \ while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done And verifying the result. Link: http://lkml.kernel.org/r/20190325193229.23390-1-sakari.ailus@linux.intel.com Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: sparclinux@vger.kernel.org Cc: linux-um@lists.infradead.org Cc: xen-devel@lists.xenproject.org Cc: linux-acpi@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-nvdimm@lists.01.org Cc: linux-pci@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-btrfs@vger.kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net Cc: linux-mm@kvack.org Cc: ceph-devel@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: David Sterba <dsterba@suse.com> (for btrfs) Acked-by: Mike Rapoport <rppt@linux.ibm.com> (for mm/memblock.c) Acked-by: Bjorn Helgaas <bhelgaas@google.com> (for drivers/pci) Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2019-04-06PCI: Rework pcie_retrain_link() wait loopStefan Mätje
Transform wait code to a "do {} while (time_before())" loop as recommended by reviewer. No functional change intended. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-04-06PCI: Work around Pericom PCIe-to-PCI bridge Retrain Link erratumStefan Mätje
Due to an erratum in some Pericom PCIe-to-PCI bridges in reverse mode (conventional PCI on primary side, PCIe on downstream side), the Retrain Link bit needs to be cleared manually to allow the link training to complete successfully. If it is not cleared manually, the link training is continuously restarted and no devices below the PCI-to-PCIe bridge can be accessed. That means drivers for devices below the bridge will be loaded but won't work and may even crash because the driver is only reading 0xffff. See the Pericom Errata Sheet PI7C9X111SLB_errata_rev1.2_102711.pdf for details. Devices known as affected so far are: PI7C9X110, PI7C9X111SL, PI7C9X130. Add a new flag, clear_retrain_link, in struct pci_dev. Quirks for affected devices set this bit. Note that pcie_retrain_link() lives in aspm.c because that's currently the only place we use it, but this erratum is not specific to ASPM, and we may retrain links for other reasons in the future. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> [bhelgaas: apply regardless of CONFIG_PCIEASPM] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> CC: stable@vger.kernel.org
2019-04-06PCI: Factor out pcie_retrain_link() functionStefan Mätje
Factor out pcie_retrain_link() to use for Pericom Retrain Link quirk. No functional change intended. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> CC: stable@vger.kernel.org
2019-04-05PCI: Init PCIe feature bits for managed host bridge allocJean-Philippe Brucker
Two functions allocate a host bridge: devm_pci_alloc_host_bridge() and pci_alloc_host_bridge(). At the moment, only the unmanaged one initializes the PCIe feature bits, which prevents from using features such as hotplug or AER on some systems, when booting with device tree. Make the initialization code common. Fixes: 02bfeb484230 ("PCI/portdrv: Simplify PCIe feature permission checking") Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.17+
2019-04-05PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controllerAndre Przywara
There is a Marvell 88SE9170 PCIe SATA controller I found on a board here. Some quick testing with the ARM SMMU enabled reveals that it suffers from the same requester ID mixup problems as the other Marvell chips listed already. Add the PCI vendor/device ID to the list of chips which need the workaround. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org
2019-04-04PCI: dwc: Remove default MSI initialization for platform specific MSI chipsKishon Vijay Abraham I
Platforms which populate msi_host_init() have their own MSI controller logic. Writing to MSI control registers on platforms which do not use Designware's MSI controller logic might have side effects. To be safe, do not write to MSI control registers if the platform uses its own MSI controller logic instead of Designware's MSI one. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: dwc: Remove Keystone specific dw_pcie_host_opsKishon Vijay Abraham I
Now that Keystone started using its own msi_irq_chip, remove Keystone specific callback functions defined in dw_pcie_host_ops. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: keystone: Use Keystone specific msi_irq_chipKishon Vijay Abraham I
Use Keystone specific msi_irq_chip to configure the MSI controller logic in the PCIe keystone wrapper instead of using the default Designware msi_irq chip (dw_pci_msi_bottom_irq_chip) with callback functions for configuring the Keystone MSI controller. This will help to remove Keystone specific callback functions added in dw_pcie_host_ops. Move the default msi_irq_chip assignment to dw_pcie_host_init since platforms that doesn't use the default msi_irq_chip will assign msi_irq_chip in the msi_host_init() callback. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: dwc: Add support to use non default msi_irq_chipKishon Vijay Abraham I
Platforms using DesignWare IP use dw_pci_msi_bottom_irq_chip for configuring the MSI controller logic within the DesignWare IP. However certain platforms like Keystone (K2G) which uses DesignWare IP have their own MSI controller logic. For handling such platforms, the irqchip ops use msi_irq_ack(), msi_set_irq(), msi_clear_irq() callback functions. Add support to use different msi_irq_chip with default set to dw_pci_msi_bottom_irq_chip. This is in preparation to get rid of msi_irq_ack(), msi_set_irq(), msi_clear_irq() and other Keystone specific dw_pcie_host_ops. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: keystone: Cleanup ks_pcie_msi_irq_handler()Kishon Vijay Abraham I
ks_pcie_msi_irq_handler() invokes ks_pcie_handle_msi_irq() for handling the interrupts. Having two functions for handling the interrupt was used when keystone PCIe driver was implemented using two files but with commit b492aca35c98 ("PCI: keystone: Merge pci-keystone-dw.c and pci-keystone.c"), which merged the keystone PCIe driver to use a single file, two functions for handling the interrupt handler are not required. Handle MSI interrupt in a single interrupt handler here. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: keystone: Use hwirq to get the MSI IRQ number offsetKishon Vijay Abraham I
ks_pcie_msi_irq_handler() uses 'virq' to get the IRQ number offset. This offset is used to get the correct MSI_IRQ_STATUS register corresponding to the IRQ line that raised the interrupt. There is no guarantee that 'virq' assigned for consecutive hardware IRQ will be contiguous and this might get us an incorrect IRQ number offset. Fix it here by using 'hwirq' to get the IRQ number offset. Since we don't store the 'virq' numbers of all the IRQ numbers, stop checking if irq count is greater than MAX_MSI_HOST_IRQS and remove MAX_MSI_HOST_IRQS. Link: https://lkml.kernel.org/r/bb081d21-7c03-0357-4294-7e92d95d838c@arm.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: keystone: Add separate functions for configuring MSI and legacy interruptKishon Vijay Abraham I
ks_pcie_get_irq_controller_info() is used to configure both MSI and legacy interrupt. This will prevent MSI or legacy interrupt specific intializations. Add separate functions to configure MSI and legacy interrupts. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: keystone: Cleanup interrupt related macrosKishon Vijay Abraham I
No functional change. Change both MSI interrupt and legacy interrupt related macros to take an additional argument in order to return the correct register offset. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-04PCI: rcar: Do not shadow the 'irq' variableWolfram Sang
The sparse tool rightfully detects: drivers/pci/controller/pcie-rcar.c:741:30: warning: symbol 'irq' shadows an earlier one Fix it now to avoid future surprises and for good coding style. No functional change intended. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> [lorenzo.pieralisi@arm.com: commit log refactoring] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-04PCI: rcar: Fix a potential NULL pointer dereferenceKangjie Lu
In case __get_free_pages() fails and returns NULL, fix the return value to -ENOMEM and release resources to avoid dereferencing a NULL pointer. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-04PCI: rcar: Fix 64bit MSI message address handlingMarek Vasut
The MSI message address in the RC address space can be 64 bit. The R-Car PCIe RC supports such a 64bit MSI message address as well. The code currently uses virt_to_phys(__get_free_pages()) to obtain a reserved page for the MSI message address, and the return value of which can be a 64 bit physical address on 64 bit system. However, the driver only programs PCIEMSIALR register with the bottom 32 bits of the virt_to_phys(__get_free_pages()) return value and does not program the top 32 bits into PCIEMSIAUR, but rather programs the PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car SoCs, however may fail on new 64 bit R-Car SoCs. Since from a PCIe controller perspective, an inbound MSI is a memory write to a special address (in case of this controller, defined by the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but never hits the DRAM _and_ because allocation of an MSI by a PCIe card driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot cause memory corruption or other issues. There is however the possibility that if virt_to_phys(__get_free_pages()) returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed to 0x0 _and_ if the system had physical RAM at the address matching the value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a physical address matching the value of PCIEMSIALR and a remote write to such a buffer by a PCIe card would trigger a spurious MSI. Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar") Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-04-04PCI: rcar: Clean up debug messagesMarek Vasut
Drop useless casts from debug messages, they are no longer needed due to the data type cleanup. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-04-04PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n)Marek Vasut
Replace (8 * n) with (BITS_PER_BYTE * n) to make bit shift operations consistent. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-04-04PCI: rcar: Replace various variable types with unsigned ones for register valuesMarek Vasut
Replace various variable types with u32 or unsigned int type for variables holding register values, since the registers are 32bit. Note that rcar_pcie_msi_irq() still uses various variable types because both find_first_bit() and __fls() require various variable types as an argument. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-04-04PCI: rcar: Replace unsigned long with u32/unsigned int in register accessorsMarek Vasut
Replace unsigned long with u32 and unsigned int in register accessor functions, since they access 32bit registers. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-04-04PCI: rcar: Clean up remaining macros defining bitsMarek Vasut
Replace macros using constants with BIT()s instead, no functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org
2019-04-03PCI: iproc: Allow outbound configuration for 32-bit I/O regionSrinath Mannam
The IProc host controller has I/O memory windows allocated in the AXI memory map that can be used to address PCI I/O memory space. Mapping from AXI memory windows to PCI outbound memory windows is carried out in the host controller through OARR/OMAP registers pairs that permit to define power of two region size AXI<->PCI mappings, the smallest of which is 128MB. Current code enables AXI memory window to PCI outbound memory window mapping only for AXI windows matching one of the OARR/OMAP window sizes, that are SoC dependent and the smallest of which is 128MB. Some SoCs implementing the IProc host controller have a 32-bit AXI memory window into PCI I/O memory space, eg: Base address | Size ----------------------------- (1) 0x42000000 | 0x2000000 (2) 0x400000000 | 0x80000000 but its size (32MB - (1) above) is smaller than the smallest AXI<->PCI region size provided by OARR (128MB), so the current driver rejects mappings for the 32-bit region making the IProc host controller driver unusable on 32-bit systems. However, there is no reason why the 32-bit I/O memory window cannot be enabled by mapping it through an OARR/OMAP region bigger in size (ie 32-bit AXI window size is 32MB but can be mapped using a 128MB OARR/OMAP region). Allow outbound window configuration of I/O memory windows that are smaller in size than the host controller OARR/OMAP region, so that the 32-bit AXI memory window can actually be enabled, making the IProc host controller operational on 32-bit systems. Link: https://lore.kernel.org/linux-pci/1551415936-30174-3-git-send-email-srinath.mannam@broadcom.com/ Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com> Signed-off-by: Ray Jui <ray.jui@broadcom.com> [lorenzo.pieralisi@arm.com: rewrote the commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Scott Branden <scott.branden@broadcom.com>
2019-04-03PCI: iproc: Add CRS check in config readSrinath Mannam
The IPROC PCIe host controller implementation returns CFG_RETRY_STATUS (0xffff0001) data when it receives a CRS completion, regardless of the address of the read or the CRS Software Visibility Enable bit. As a workaround the driver retries in software any read that returns CFG_RETRY_STATUS even though, for reads of registers that are not Vendor ID, the register value can correspond to CFG_RETRY_STATUS; this situation would cause a timeout and failure of reading a valid register value. IPROC PCIe host controller PAXB v2 has a register to show config read status flags like SC, UR, CRS and CA. Using this status flag, an extra check is added to confirm the CRS using status flags before reissuing a config read, fixing the issue. Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> [lorenzo.pieralisi@arm.com: rewrote commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Scott Branden <scott.branden@broadcom.com>
2019-04-01PCI: mediatek: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_get_next_child() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. irq_domain_add_linear() also calls of_node_get() to increase refcount, so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/pcie-mediatek.c:577:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 567, but without a corresponding object release within this function. ./drivers/pci/controller/pcie-mediatek.c:583:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 567, but without a corresponding object release within this function. ./drivers/pci/controller/pcie-mediatek.c:586:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 567, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Honghui Zhang <honghui.zhang@mediatek.com> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-pci@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org
2019-04-01PCI: iproc: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_parse_phandle() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. iproc_msi_init() also calls of_node_get() to increase refcount: proc_msi_init() -> iproc_msi_alloc_domains() -> pci_msi_create_irq_domain() -> msi_create_irq_domain() -> irq_domain_create_linear() -> __irq_domain_add() so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/pcie-iproc.c:1323:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1299, but without a corresponding object release within this function. ./drivers/pci/controller/pcie-iproc.c:1330:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1299, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org
2019-04-01PCI: aardvark: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_get_next_child() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. irq_domain_add_linear() also calls of_node_get() to increase refcount, so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/pci-aardvark.c:826:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 798, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org
2019-04-01PCI: rockchip: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_get_child_by_name() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. irq_domain_add_linear() also calls of_node_get() to increase refcount, so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/pcie-rockchip-host.c:729:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 718, but without a corresponding object release within this function. ./drivers/pci/controller/pcie-rockchip-host.c:732:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 718, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-pci@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org
2019-04-01PCI: dwc: layerscape: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_parse_phandle() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pci/controller/dwc/pci-layerscape.c:204:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 198, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Minghuan Lian <minghuan.Lian@nxp.com> Cc: Mingkai Hu <mingkai.hu@nxp.com> Cc: Roy Zang <roy.zang@nxp.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org
2019-03-29PCI: uniphier: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_get_child_by_name() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. irq_domain_add_linear() also calls of_node_get() to increase refcount, so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/dwc/pcie-uniphier.c:283:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function. ./drivers/pci/controller/dwc/pcie-uniphier.c:290:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function. ./drivers/pci/controller/dwc/pcie-uniphier.c:296:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: linux-pci@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org
2019-03-29PCI: dwc: pci-dra7xx: Fix a leaked reference by adding missing of_node_put()Wen Yang
The call to of_get_next_child() returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. irq_domain_add_linear() also calls of_node_get() to increase refcount, so irq_domain will not be affected when it is released. Detected by coccinelle with the following warnings: ./drivers/pci/controller/dwc/pci-dra7xx.c:252:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 241, but without a corresponding object release within this function. ./drivers/pci/controller/dwc/pci-dra7xx.c:255:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 241, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-omap@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-03-29PCI: xilinx: Check for __get_free_pages() failureKangjie Lu
If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer dereference. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
2019-03-26PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessaryDexuan Cui
When we hot-remove a device, usually the host sends us a PCI_EJECT message, and a PCI_BUS_RELATIONS message with bus_rel->device_count == 0. When we execute the quick hot-add/hot-remove test, the host may not send us the PCI_EJECT message if the guest has not fully finished the initialization by sending the PCI_RESOURCES_ASSIGNED* message to the host, so it's potentially unsafe to only depend on the pci_destroy_slot() in hv_eject_device_work() because the code path create_root_hv_pci_bus() -> hv_pci_assign_slots() is not called in this case. Note: in this case, the host still sends the guest a PCI_BUS_RELATIONS message with bus_rel->device_count == 0. In the quick hot-add/hot-remove test, we can have such a race before the code path pci_devices_present_work() -> new_pcichild_device() adds the new device into the hbus->children list, we may have already received the PCI_EJECT message, and since the tasklet handler hv_pci_onchannelcallback() may fail to find the "hpdev" by calling get_pcichild_wslot(hbus, dev_message->wslot.slot) hv_pci_eject_device() is not called; Later, by continuing execution create_root_hv_pci_bus() -> hv_pci_assign_slots() creates the slot and the PCI_BUS_RELATIONS message with bus_rel->device_count == 0 removes the device from hbus->children, and we end up being unable to remove the slot in hv_pci_remove() -> hv_pci_remove_slots() Remove the slot in pci_devices_present_work() when the device is removed to address this race. pci_devices_present_work() and hv_eject_device_work() run in the singled-threaded hbus->wq, so there is not a double-remove issue for the slot. We cannot offload hv_pci_eject_device() from hv_pci_onchannelcallback() to the workqueue, because we need the hv_pci_onchannelcallback() synchronously call hv_pci_eject_device() to poll the channel ringbuffer to work around the "hangs in hv_compose_msi_msg()" issue fixed in commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui <decui@microsoft.com> [lorenzo.pieralisi@arm.com: rewritten commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Cc: stable@vger.kernel.org
2019-03-26PCI: hv: Add hv_pci_remove_slots() when we unload the driverDexuan Cui
When we unload the pci-hyperv host controller driver, the host does not send us a PCI_EJECT message. In this case we also need to make sure the sysfs PCI slot directory is removed, otherwise a command on a slot file eg: "cat /sys/bus/pci/slots/2/address" will trigger a "BUG: unable to handle kernel paging request" and, if we unload/reload the driver several times we would end up with stale slot entries in PCI slot directories in /sys/bus/pci/slots/ root@localhost:~# ls -rtl /sys/bus/pci/slots/ total 0 drwxr-xr-x 2 root root 0 Feb 7 10:49 2 drwxr-xr-x 2 root root 0 Feb 7 10:49 2-1 drwxr-xr-x 2 root root 0 Feb 7 10:51 2-2 Add the missing code to remove the PCI slot and fix the current behaviour. Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui <decui@microsoft.com> [lorenzo.pieralisi@arm.com: reformatted the log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Cc: stable@vger.kernel.org
2019-03-26PCI: hv: Fix a memory leak in hv_eject_device_work()Dexuan Cui
When a device is created in new_pcichild_device(), hpdev->refs is set to 2 (i.e. the initial value of 1 plus the get_pcichild()). When we hot remove the device from the host, in a Linux VM we first call hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and then schedules a work of hv_eject_device_work(), so hpdev->refs becomes 3 (let's ignore the paired get/put_pcichild() in other places). But in hv_eject_device_work(), currently we only call put_pcichild() twice, meaning the 'hpdev' struct can't be freed in put_pcichild(). Add one put_pcichild() to fix the memory leak. The device can also be removed when we run "rmmod pci-hyperv". On this path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()), hpdev->refs is 2, and we do correctly call put_pcichild() twice in pci_devices_present_work(). Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui <decui@microsoft.com> [lorenzo.pieralisi@arm.com: commit log rework] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Cc: stable@vger.kernel.org
2019-03-26PCI: rcar: Add the initialization of PCIe link in resume_noirq()Kazufumi Ikeda
Reestablish the PCIe link very early in the resume process in case it went down to prevent PCI accesses from hanging the bus. Such accesses can happen early in the PCI resume process, as early as the SUSPEND_RESUME_NOIRQ step, thus the link must be reestablished in the driver resume_noirq() callback. Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar") Signed-off-by: Kazufumi Ikeda <kaz-ikeda@xc.jp.nec.com> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> [lorenzo.pieralisi@arm.com: reformatted commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-renesas-soc@vger.kernel.org
2019-03-25PCI/LINK: Deduplicate bandwidth reports for multi-function devicesLukas Wunner
If a multi-function device's bandwidth is already limited when it is enumerated, a message is logged only for function 0. By contrast, when downtraining occurs after enumeration, a message is logged for all functions. That's because the former uses pcie_report_downtraining(), whereas the latter uses __pcie_print_link_status() (which doesn't filter functions != 0). I am seeing this happen on a MacBookPro9,1 with a GPU (function 0) and an integrated HDA controller (function 1). Avoid this incongruence by calling pcie_report_downtraining() in both cases. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alexandru Gagniuc <alex.gagniuc@dellteam.com>
2019-03-25PCI/LINK: Clear bandwidth notification interrupt before enabling itLukas Wunner
When booting a MacBookPro9,1, duplicate link downtraining messages are logged for the devices directly attached to the two CPU-internal Root Ports of the Core i7 3615QM: Once on device enumeration and once on enablement of the bandwidth notification interrupt on the Root Ports. Duplicate messages do not occur with Root Ports on the PCH and Downstream Ports on the Thunderbolt controller: Only a single message is logged for these, namely on device enumeration. The reason for the duplicate messages is a stale interrupt in the Link Status register of the 3615QM's internal Root Ports. Avoid by clearing the interrupt before enabling it. An alternative approach would be to clear the interrupt already on device enumeration or to report link downtraining only if the speed has changed. That way, link downtraining occurring between device enumeration and enablement of the bandwidth notification interrupt could be caught. However clearing stale interrupts before enabling them is a standard operating procedure for any driver and keeping the two steps in one place makes the code easier to follow. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alexandru Gagniuc <alex.gagniuc@dellteam.com>