summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-22PCI: pci-bridge-emul: Fix PCIe bit conflictsJon Derrick
This patch fixes two bit conflicts in the pci-bridge-emul driver: 1. Bit 3 of Device Status (19 of Device Control) is marked as both Write-1-to-Clear and Read-Only. It should be Write-1-to-Clear. The Read-Only and Reserved bitmasks are shifted by 1 bit due to this error. 2. Bit 12 of Slot Control is marked as both Read-Write and Reserved. It should be Read-Write. Link: https://lore.kernel.org/r/20200511162117.6674-2-jonathan.derrick@intel.com Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org>
2020-05-22MAINTAINERS: Add file patterns for rcar PCI device tree bindingsLad Prabhakar
Add file pattern entry for rcar PCI devicetree binding, so that when people run ./scripts/get_maintainer.pl the rcar PCI maintainers could also be listed. Link: https://lore.kernel.org/r/1588854799-13710-9-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2020-05-22PCI: rcar: Add endpoint mode supportLad Prabhakar
Add support for R-Car PCIe controller to work in endpoint mode. Link: https://lore.kernel.org/r/1588854799-13710-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2020-05-22dt-bindings: PCI: rcar: Add bindings for R-Car PCIe endpoint controllerLad Prabhakar
This patch adds the bindings for the R-Car PCIe endpoint driver. Link: https://lore.kernel.org/r/1588854799-13710-7-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2020-05-22PCI: endpoint: Add support to handle multiple base for mapping outbound memoryLad Prabhakar
R-Car PCIe controller has support to map multiple memory regions for mapping the outbound memory in local system also the controller limits single allocation for each region (that is, once a chunk is used from the region it cannot be used to allocate a new one). This features inspires to add support for handling multiple memory bases in endpoint framework. With this patch pci_epc_mem_init() initializes address space for endpoint controller which support single window and pci_epc_multi_mem_init() initializes multiple windows supported by endpoint controller. Link: https://lore.kernel.org/r/1588854799-13710-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-05-21pcmcia: Use CardBus window names (PCI_CB_BRIDGE_IO_0_WINDOW etc) when freeingKrzysztof Wilczynski
Remove the loop used to free CardBus resources and replace it with a yenta_free_res() helper used to release bridge resources explicitly. Link: https://lore.kernel.org/r/20200520183411.1534621-3-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
2020-05-21PCI: Use bridge window names (PCI_BRIDGE_IO_WINDOW etc)Krzysztof Wilczynski
Use bridge resource definitions instead of using the PCI_BRIDGE_RESOURCES constant with an integer offeset. Link: https://lore.kernel.org/r/20200520183411.1534621-2-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-21PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream PortBjorn Helgaas
Except for Endpoints, we enable PTM at enumeration-time. Previously we did not account for the fact that Switch Downstream Ports are not permitted to have a PTM capability; their PTM behavior is controlled by the Upstream Port (PCIe r5.0, sec 7.9.16). Since Downstream Ports don't have a PTM capability, we did not mark them as "ptm_enabled", which meant that pci_enable_ptm() on an Endpoint failed because there was no PTM path to it. Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM enabled. Fixes: eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints") Reported-by: Aditya Paluri <Venkata.AdityaPaluri@synopsys.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-21PCI: shpchp: Make shpchp_unconfigure_device() voidKrzysztof Wilczynski
shpchp_unconfigure_device() always returned 0, so there's no reason for a return value. In addition, remove_board() checked the return value for possible error which is unnecessary. Convert shpchp_unconfigure_device() to a void function and remove the return value check. This addresses the following Coccinelle warning: drivers/pci/hotplug/shpchp_pci.c:66:5-7: Unneeded variable: "rc". Return "0" on line 86 Link: https://lore.kernel.org/r/20200521190457.1066600-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-21PCI/switchtec: Correct bool variable type assignmentKrzysztof Wilczynski
Use "true" instead of 1 to initialize "bool use_dma_mrpc". This resolves the following Coccinelle warning: drivers/pci/switch/switchtec.c:28:12-24: WARNING: Assignment of 0/1 to bool variable Link: https://lore.kernel.org/r/20200521200439.1076672-1-kw@linux.com Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2020-05-21PCI/PME: Fix kernel-doc of pcie_pme_resume() and pcie_pme_remove()Jay Fang
Fix kernel-doc of the "srv" parameter to pcie_pme_resume() and pcie_pme_remove(). Building with W=1 produced these warnings: drivers/pci/pcie/pme.c:414: warning: Function parameter or member 'srv' not described in 'pcie_pme_resume' drivers/pci/pcie/pme.c:437: warning: Function parameter or member 'srv' not described in 'pcie_pme_remove' Link: https://lore.kernel.org/r/1589612414-61682-1-git-send-email-f.fangjian@huawei.com Signed-off-by: Jay Fang <f.fangjian@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-18PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DTKishon Vijay Abraham I
The PCI Bus Binding specification (IEEE Std 1275-1994 Revision 2.1 [1]) defines both Vendor ID and Device ID to be 32-bits. Fix pcie-cadence-host.c driver to read 32-bit Vendor ID and Device ID properties from device tree. [1] -> https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf Link: https://lore.kernel.org/r/20200508130646.23939-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tom Joseph <tjoseph@cadence.com>
2020-05-18PCI: cadence: Remove "cdns,max-outbound-regions" DT propertyKishon Vijay Abraham I
"cdns,max-outbound-regions" device tree property provides the maximum number of outbound regions supported by the Host PCIe controller. However the outbound regions are configured based on what is populated in the "ranges" DT property. Avoid using two properties for configuring outbound regions and use only "ranges" property instead. Link: https://lore.kernel.org/r/20200508130646.23939-3-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Tom Joseph <tjoseph@cadence.com>
2020-05-18dt-bindings: PCI: cadence: Deprecate inbound/outbound specific bindingsKishon Vijay Abraham I
Deprecate cdns,max-outbound-regions and cdns,no-bar-match-nbits for host mode as both these could be derived from "ranges" and "dma-ranges" property. "cdns,max-outbound-regions" property would still be required for EP mode. Link: https://lore.kernel.org/r/20200508130646.23939-2-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Tom Joseph <tjoseph@cadence.com>
2020-05-18dt-bindings: PCI: aardvark: Describe new propertiesMarek Behún
Document the possibility to reference a PHY and reset-gpios and to set max-link-speed property. Link: https://lore.kernel.org/r/20200430080625.26070-10-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org
2020-05-18PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macrosPali Rohár
PCI-E capability macros are already defined in linux/pci_regs.h. Remove their reimplementation in pcie-aardvark. Link: https://lore.kernel.org/r/20200430080625.26070-9-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: aardvark: Add PHY supportMarek Behún
With recent proposed changes for U-Boot it is possible that bootloader won't initialize the PHY for this controller (currently the PHY is initialized regardless whether PCI is used in U-Boot, but with these proposed changes the PHY is initialized only on request). Since the mvebu-a3700-comphy driver by Miquèl Raynal supports enabling PCIe PHY, and since Linux' functionality should be independent on what bootloader did, add code for enabling generic PHY if found in device OF node. The mvebu-a3700-comphy driver does PHY powering via SMC calls to ARM Trusted Firmware. The corresponding code in ARM Trusted Firmware skips one register write which U-Boot does not: step 7 ("Enable TX"), see [1]. Instead ARM Trusted Firmware expects PCIe driver to do this step, probably because the register is in PCIe controller address space, instead of PHY address space. We therefore add this step into the advk_pcie_setup_hw function. [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/marvell/comphy/phy-comphy-3700.c?h=v2.3-rc2#n836 Link: https://lore.kernel.org/r/20200430080625.26070-8-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Miquèl Raynal <miquel.raynal@bootlin.com>
2020-05-18PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG accessPali Rohár
This register is applicable only when the controller is configured for Endpoint mode, which is not the case for the current version of this driver. Attempting to remove this code though caused some ath10k cards to stop working, so for some unknown reason it is needed here. This should be investigated and a comment explaining this should be put before the code, so we add a FIXME comment for now. Link: https://lore.kernel.org/r/20200430080625.26070-7-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: aardvark: Issue PERST via GPIOPali Rohár
Add support for issuing PERST via GPIO specified in 'reset-gpios' property (as described in PCI device tree bindings). Some buggy cards (e.g. Compex WLE900VX or WLE1216) are not detected after reboot when PERST is not issued during driver initialization. If bootloader already enabled link training then issuing PERST has no effect for some buggy cards (e.g. Compex WLE900VX) and these cards are not detected. We therefore clear the LINK_TRAINING_EN register before. It was observed that Compex WLE900VX card needs to be in PERST reset for at least 10ms if bootloader enabled link training. Tested on Turris MOX. Link: https://lore.kernel.org/r/20200430080625.26070-6-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: aardvark: Improve link trainingMarek Behún
Currently the aardvark driver trains link in PCIe gen2 mode. This may cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or even not detected. Moreover when ASPM code tries to retrain link second time, these cards may stop responding and link goes down. If gen1 is used this does not happen. Unconditionally forcing gen1 is not a good solution since it may have performance impact on gen2 cards. To overcome this, read 'max-link-speed' property (as defined in PCI device tree bindings) and use this as max gen mode. Then iteratively try link training at this mode or lower until successful. After successful link training choose final controller gen based on Negotiated Link Speed from Link Status register, which should match card speed. Link: https://lore.kernel.org/r/20200430080625.26070-5-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: of: Zero max-link-speed value is invalidPali Rohár
Interpret zero value of max-link-speed property as invalid, as the device tree bindings documentation specifies. Link: https://lore.kernel.org/r/20200430080625.26070-4-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only ↵Pali Rohár
register Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-18PCI: aardvark: Train link immediately after enabling trainingPali Rohár
Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link training and starting link training causes detection issues with some buggy cards (such as Compex WLE900VX). Move the code which enables link training immediately before the one which starts link traning. This fixes detection issues of Compex WLE900VX card on Turris MOX after cold boot. Link: https://lore.kernel.org/r/20200430080625.26070-2-pali@kernel.org Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...") Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-15PCI/PM: Assume ports without DLL Link Active train links in 100 msMika Westerberg
Kai-Heng Feng reported that it takes a long time (> 1 s) to resume Thunderbolt-connected devices from both runtime suspend and system sleep (s2idle). This was because some Downstream Ports that support > 5 GT/s do not also support Data Link Layer Link Active reporting. Per PCIe r5.0 sec 6.6.1: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not. Previously we tried to wait for Link training to complete, but since there was no DLL Link Active reporting, all we could do was wait the worst-case 1000 ms, then another 100 ms. Instead of using the supported speeds to determine whether to wait for Link training, check whether the port supports DLL Link Active reporting. The Ports in question do not, so we'll wait only the 100 ms required for Ports that support Link speeds <= 5 GT/s. This of course assumes these Ports always train the Link within 100 ms even if they are operating at > 5 GT/s, which is not required by the spec. [bhelgaas: commit log, comment] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/20200514133043.27429-1-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-15PCI/PM: Adjust pcie_wait_for_link_delay() for caller delayBjorn Helgaas
The caller of pcie_wait_for_link_delay() specifies the time to wait after the link becomes active. When the downstream port doesn't support link active reporting, obviously we can't tell when the link becomes active, so we waited the worst-case time (1000 ms) plus 100 ms, ignoring the delay from the caller. Instead, wait for 1000 ms + the delay from the caller. Fixes: 4827d63891b6 ("PCI/PM: Add pcie_wait_for_link_delay()") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-15x86/PCI: Mark Intel C620 MROMs as having non-compliant BARsXiaochun Lee
The Intel C620 Platform Controller Hub has MROM functions that have non-PCI registers (undocumented in the public spec) where BAR 0 is supposed to be, which results in messages like this: pci 0000:00:11.0: [Firmware Bug]: reg 0x30: invalid BAR (can't size) Mark these MROM functions as having non-compliant BARs so we don't try to probe any of them. There are no other BARs on these devices. See the Intel C620 Series Chipset Platform Controller Hub Datasheet, May 2019, Document Number 336067-007US, sec 2.1, 35.5, 35.6. [bhelgaas: commit log, add 0xa26d] Link: https://lore.kernel.org/r/1589513467-17070-1-git-send-email-lixiaochun.2888@163.com Signed-off-by: Xiaochun Lee <lixc17@lenovo.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
2020-05-14PCI: Program MPS for RCiEP devicesAshok Raj
Root Complex Integrated Endpoints (RCiEPs) do not have an upstream bridge, so pci_configure_mps() previously ignored them, which may result in reduced performance. Instead, program the Max_Payload_Size of RCiEPs to the maximum supported value (unless it is limited for the PCIE_BUS_PEER2PEER case). This also affects the subsequent programming of Max_Read_Request_Size because Linux programs MRRS based on the MPS value. Fixes: 9dae3a97297f ("PCI: Move MPS configuration check to pci_configure_device()") Link: https://lore.kernel.org/r/1585343775-4019-1-git-send-email-ashok.raj@intel.com Tested-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
2020-05-14PCI: Fix pci_host_bridge struct device release/free handlingRob Herring
The PCI code has several paths where the struct pci_host_bridge is freed directly. This is wrong because it contains a struct device which is refcounted and should be freed using put_device(). This can result in use-after-free errors. I think this problem has existed since 2012 with commit 7b5436635800 ("PCI: add generic device into pci_host_bridge struct"). It generally hasn't mattered as most host bridge drivers are still built-in and can't unbind. The problem is a struct device should never be freed directly once device_initialize() is called and a ref is held, but that doesn't happen until pci_register_host_bridge(). There's then a window between allocating the host bridge and pci_register_host_bridge() where kfree should be used. This is fragile and requires callers to do the right thing. To fix this, we need to split device_register() into device_initialize() and device_add() calls, so that the host bridge struct is always freed by using a put_device(). devm_pci_alloc_host_bridge() is using devm_kzalloc() to allocate struct pci_host_bridge which will be freed directly. Instead, we can use a custom devres action to call put_device(). Link: https://lore.kernel.org/r/20200513223859.11295-2-robh@kernel.org Reported-by: Anders Roxell <anders.roxell@linaro.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2020-05-14PCI: Fix pci_register_host_bridge() device_register() error handlingRob Herring
If device_register() has an error, we should bail out of pci_register_host_bridge() rather than continuing on. Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
2020-05-14PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port()Yicong Yang
Previously we used pcie_find_root_port() to find a Root Port from a PCIe device and pci_find_pcie_root_port() to find a Root Port from a Conventional PCI device. Unify the two functions and use pcie_find_root_port() to find a Root Port from either a Conventional PCI device or a PCIe device. Then there is no need to distinguish the type of the device. Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # thunderbolt
2020-05-13USB: pci-quirks: Add Raspberry Pi 4 quirkNicolas Saenz Julienne
On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideoCore. Inform VideoCore that VL805 was just reset. Also, as this creates a dependency between USB_PCI and VideoCore's firmware interface, and since USB_PCI can't be set as a module neither this can. Reflect that on the firmware interface Kconfg. Link: https://lore.kernel.org/r/20200505161318.26200-5-nsaenzjulienne@suse.de Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
2020-05-13PCI: brcmstb: Wait for Raspberry Pi's firmware when presentNicolas Saenz Julienne
xHCI's PCI fixup, run at the end of pcie-brcmstb's probe, depends on RPi4's VideoCore firmware interface to be up and running. It's possible for both initializations to race, so make sure it's available prior to starting. Link: https://lore.kernel.org/r/20200505161318.26200-4-nsaenzjulienne@suse.de Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-05-13firmware: raspberrypi: Introduce vl805 init routineNicolas Saenz Julienne
The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip that implements xHCI. After a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's co-processor, VideoCore. RPi4's VideoCore OS contains both the non public firmware load logic and the VL805 firmware blob. The function this patch introduces triggers the aforementioned process. Link: https://lore.kernel.org/r/20200505161318.26200-3-nsaenzjulienne@suse.de Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-05-13soc: bcm2835: Add notify xHCI reset propertyNicolas Saenz Julienne
The property is needed in order to trigger VL805's firmware load. Note that gap between the property introduced and the previous one is due to the properties not being defined. Link: https://lore.kernel.org/r/20200505161318.26200-2-nsaenzjulienne@suse.de Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-05-12PCI: Replace zero-length array with flexible-arrayGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these as a flexible array member [1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that dynamic memory allocations won't be affected by this change: Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero. [1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type [1]. There are some instances of code in which the sizeof() operator is being incorrectly/erroneously applied to zero-length arrays, and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507190544.GA15633@embeddedor Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-05-12PCI: Check for platform_get_irq() failure consistentlyAman Sharma
The platform_get_irq*() interfaces return either a negative error number or a valid IRQ. 0 is not a valid return value, so check for "< 0" to detect failure as recommended by the function documentation. On failure, return the error number from platform_get_irq*() instead of making up a new one. Link: https://lore.kernel.org/r/cover.1583952275.git.amanharitsh123@gmail.com [bhelgaas: commit log, squash into one patch] Signed-off-by: Aman Sharma <amanharitsh123@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Richard Zhu <hongxing.zhu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in> Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>
2020-05-12driver core: platform: Clarify that IRQ 0 is invalidBjorn Helgaas
These interfaces return a negative error number or an IRQ: platform_get_irq() platform_get_irq_optional() platform_get_irq_byname() platform_get_irq_byname_optional() The function comments suggest checking for error like this: irq = platform_get_irq(...); if (irq < 0) return irq; which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0 is invalid. But some callers check for "irq <= 0", and it's not obvious from the source that we never return an IRQ 0. Make this more explicit by updating the comments to say that an IRQ number is always non-zero and adding a WARN() if we ever do return zero. If we do return IRQ 0, it likely indicates a bug in the arch-specific parts of platform_get_irq(). Relevant prior discussion at [1, 2]. [1] https://lore.kernel.org/r/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/ [2] https://lore.kernel.org/r/Pine.LNX.4.64.0701252029570.25027@woody.linux-foundation.org/ Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2020-05-11Documentation: PCI: Give unique labels to sectionsBryce Willey
Make subsection labels more specific to avoid sphinx warnings. Exact warning: Documentation/PCI/endpoint/pci-endpoint.rst:208: WARNING: duplicate label pci/endpoint/pci-endpoint:other apis, other instance in Documentation/PCI/endpoint/pci-endpoint.rst Link: https://lore.kernel.org/r/20200503214926.23748-1-bryce.steven.willey@gmail.com Signed-off-by: Bryce Willey <Bryce.Steven.Willey@gmail.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rob Herring <robh@kernel.org>
2020-05-11MAINTAINERS: correct typo in new NXP LAYERSCAPE GEN4Lukas Bulwahn
Commit 3edeb49525bb ("dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller") includes a new entry in MAINTAINERS, but slipped in a typo in one of the file entries. Hence, since then, ./scripts/get_maintainer.pl --self-test complains: warning: no file matches F: \ drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c Correct the typo in PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER. Link: https://lore.kernel.org/r/20200506052130.5780-1-lukas.bulwahn@gmail.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org>
2020-05-11PCI: hv: Retry PCI bus D0 entry on invalid device stateWei Hu
When kdump is triggered, some PCI devices may have not been shut down cleanly before the kdump kernel starts. This causes the initial attempt to enter D0 state in the kdump kernel to fail with invalid device state returned from Hyper-V host. When this happens, explicitly call hv_pci_bus_exit() and retry to enter the D0 state. Link: https://lore.kernel.org/r/20200507050300.10974-1-weh@microsoft.com Signed-off-by: Wei Hu <weh@microsoft.com> [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-05-11PCI: hv: Fix the PCI HyperV probe failure path to release resource properlyWei Hu
In some error cases in hv_pci_probe(), allocated resources are not freed. Fix this by adding a field to keep track of the high water mark for slots that have resources allocated to them. In case of an error, this high water mark is used to know which slots have resources that must be released. Since slots are numbered starting with zero, a value of -1 indicates no slots have been allocated resources. There may be unused slots in the range between slot 0 and the high water mark slot, but these slots are already ignored by the existing code in the allocate and release loops with the call to get_pcichild_wslot(). Link: https://lore.kernel.org/r/20200507050211.10923-1-weh@microsoft.com Signed-off-by: Wei Hu <weh@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
2020-05-11PCI: brcmstb: Disable L0s component of ASPM if requestedJim Quinlan
Some informal internal experiments has shown that the BrcmSTB ASPM L0s savings may introduce an undesirable noise signal on some customers' boards. In addition, L0s was found lacking in realized power savings, especially relative to the L1 ASPM component. This is BrcmSTB's experience and may not hold for others. At any rate, if the 'aspm-no-l0s' property is present L0s will be disabled. Link: https://lore.kernel.org/r/20200507201544.43432-5-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
2020-05-11dt-bindings: PCI: brcmstb: New prop 'aspm-no-l0s'Jim Quinlan
For various reasons, one may want to disable the ASPM L0s capability. Link: https://lore.kernel.org/r/20200507201544.43432-4-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org>
2020-05-11PCI: brcmstb: Fix window register offset from 4 to 8Jim Quinlan
The outbound memory window registers were being referenced with an incorrect stride offset. This probably wasn't noticed previously as there was likely only one such window employed. Link: https://lore.kernel.org/r/20200507201544.43432-3-james.quinlan@broadcom.com Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
2020-05-11PCI: brcmstb: Don't clk_put() a managed clockJim Quinlan
clk_put() was being invoked on a clock obtained by devm_clk_get_optional(). Link: https://lore.kernel.org/r/20200507201544.43432-2-james.quinlan@broadcom.com Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
2020-05-11PCI: brcmstb: Assert fundamental reset on initializationNicolas Saenz Julienne
While preparing the driver for upstream this detail was missed. If not asserted during the initialization process, devices connected on the bus will not be made aware of the internal reset happening. This, potentially resulting in unexpected behavior. Link: https://lore.kernel.org/r/20200507172020.18000-1-nsaenzjulienne@suse.de Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
2020-05-11PCI: endpoint: Pass page size as argument to pci_epc_mem_init()Lad Prabhakar
pci_epc_mem_init() internally used page size equal to *PAGE_SIZE* to manage the address space so instead just pass the page size as a argument to pci_epc_mem_init(). Also make pci_epc_mem_init() as a C function instead of a macro function in preparation for adding support for pci-epc-mem core to handle multiple windows. Link: https://lore.kernel.org/r/1588854799-13710-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
2020-05-11PCI: rcar: Fix calculating mask for PCIEPAMR registerLad Prabhakar
The mask value was calculated incorrectly for PCIEPAMR register if the size was less than 128 bytes. Fix this issue by adding a check on size. Link: https://lore.kernel.org/r/1588854799-13710-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2020-05-11PCI: rcar: Move shareable code to a common fileLad Prabhakar
Move shareable code to common file pcie-rcar.c and the #defines to pcie-rcar.h so that the common code can be reused with endpoint driver. There are no functional changes with this patch for the host controller driver. Link: https://lore.kernel.org/r/1588854799-13710-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
2020-05-11PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.cLad Prabhakar
This commit renames pcie-rcar.c to pcie-rcar-host.c in preparation for adding support for endpoint mode. CONFIG_PCIE_RCAR is kept so that arm64 defconfig change can be a separate patch. With this patch both config options PCIE_RCAR and PCIE_RCAR_HOST will be available but PCIE_RCAR internally selects PCIE_RCAR_HOST so that bisect builds wont be affected. Link: https://lore.kernel.org/r/1588854799-13710-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-30 09:36:30 +0000