aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2020-05-22PCI: pci-bridge-emul: Eliminate the 'reserved' memberJon Derrick1-17/+13
Per PCIe 5.0 r1.0, Terms and Acronyms, Page 80: Reserved register fields must be read only and must return 0 (all 0's for multi-bit fields) when read. Reserved encodings for register and packet fields must not be used. Any implementation dependence on a Reserved field value or encoding will result in an implementation that is not PCI Express-compliant. This patch ensures reads will return 0 for any bit not in the Read-Only, Read-Write, or Write-1-to-Clear bitmasks. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jon Derrick <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-05-22PCI: pci-bridge-emul: Update for PCIe 5.0 r1.0Jon Derrick1-15/+16
Add missing bits from PCIe 4.0 and updates for PCIe 5.0 r1.0. PCIe 4.0: Device Status bit 6 - W1C - Emergency Power Reduction Detected Link Control bits 15:14 - RW - DRS Signaling Control Slot Control bit 13 - RW - Auto Slow Power Limit Disable PCIe 5.0: Slot Control bit 14 - RW - In-Band PD Disable Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jon Derrick <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-05-22PCI: pci-bridge-emul: Fix Root Cap/Status commentJon Derrick1-1/+5
The upper 16-bits of Root Control contain the Root Capabilities register. The code instead describes the Root Status register in the upper 16-bits, although it uses the correct bit definition for Root Capabilities, and for Root Status in the next definition. Fix this comment and add a comment describing the Root Status register. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jon Derrick <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-05-22PCI: pci-bridge-emul: Fix PCIe bit conflictsJon Derrick1-3/+3
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/[email protected] Signed-off-by: Jon Derrick <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-05-22PCI: rcar: Add endpoint mode supportLad Prabhakar4-0/+581
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2020-05-22PCI: endpoint: Add support to handle multiple base for mapping outbound memoryLad Prabhakar2-69/+146
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-05-21PCI: Use bridge window names (PCI_BRIDGE_IO_WINDOW etc)Krzysztof Wilczynski1-53/+61
Use bridge resource definitions instead of using the PCI_BRIDGE_RESOURCES constant with an integer offeset. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Wilczynski <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-21PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream PortBjorn Helgaas1-5/+17
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 <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-21PCI: shpchp: Make shpchp_unconfigure_device() voidKrzysztof Wilczynski3-7/+3
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/[email protected] Signed-off-by: Krzysztof Wilczynski <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-21PCI/switchtec: Correct bool variable type assignmentKrzysztof Wilczynski1-1/+1
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/[email protected] Signed-off-by: Krzysztof Wilczynski <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]>
2020-05-21PCI/PME: Fix kernel-doc of pcie_pme_resume() and pcie_pme_remove()Jay Fang1-2/+2
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/[email protected] Signed-off-by: Jay Fang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-20s390/pci: create links between PFs and VFsNiklas Schnelle1-3/+0
On s390 PCI Virtual Functions (VFs) are scanned by firmware and are made available to Linux via the hot-plug interface. As such the common code path of doing the scan directly using the parent Physical Function (PF) is not used and fenced off with the no_vf_scan attribute. Even if the partition created the VFs itself e.g. using the sriov_numvfs attribute of a PF, the PF/VF links thus need to be established after the fact. To do this when a VF is plugged we scan through all functions on the same zbus and test whether they are the parent PF in which case we establish the necessary links. With these links established there is now no more need to fence off pci_iov_remove_virtfn() for pdev->no_vf_scan as the common code now works fine. Signed-off-by: Niklas Schnelle <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Pierre Morel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vasily Gorbik <[email protected]>
2020-05-20PCI/IOV: Introduce pci_iov_sysfs_link() functionNiklas Schnelle1-11/+25
Currently pci_iov_add_virtfn() scans the SR-IOV BARs, adds the VF to the bus and also creates the sysfs links between the newly added VF and its parent PF. With pdev->no_vf_scan fencing off the entire pci_iov_add_virtfn() call s390 as the sole pdev->no_vf_scan user thus ends up missing these sysfs links which are required for example by QEMU/libvirt. Instead of duplicating the code refactor pci_iov_add_virtfn() to make sysfs link creation callable separately. Signed-off-by: Niklas Schnelle <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Pierre Morel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vasily Gorbik <[email protected]>
2020-05-18PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DTKishon Vijay Abraham I2-4/+4
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/[email protected] Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Tom Joseph <[email protected]>
2020-05-18PCI: cadence: Remove "cdns,max-outbound-regions" DT propertyKishon Vijay Abraham I2-8/+0
"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/[email protected] Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Tom Joseph <[email protected]>
2020-05-18PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macrosPali Rohár1-23/+18
PCI-E capability macros are already defined in linux/pci_regs.h. Remove their reimplementation in pcie-aardvark. Link: https://lore.kernel.org/r/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: aardvark: Add PHY supportMarek Behún1-0/+69
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/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]> Cc: Miquèl Raynal <[email protected]>
2020-05-18PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG accessPali Rohár1-0/+7
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/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: aardvark: Issue PERST via GPIOPali Rohár1-1/+42
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/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: aardvark: Improve link trainingMarek Behún1-25/+89
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/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Marek Behún <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: of: Zero max-link-speed value is invalidPali Rohár1-1/+1
Interpret zero value of max-link-speed property as invalid, as the device tree bindings documentation specifies. Link: https://lore.kernel.org/r/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only ↵Pali Rohár1-4/+0
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/[email protected] Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-18PCI: aardvark: Train link immediately after enabling trainingPali Rohár1-6/+9
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/[email protected] Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...") Tested-by: Tomasz Maciej Nowak <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Thomas Petazzoni <[email protected]>
2020-05-15PCI/PM: Assume ports without DLL Link Active train links in 100 msMika Westerberg1-9/+21
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/[email protected] Reported-by: Kai-Heng Feng <[email protected]> Tested-by: Kai-Heng Feng <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-15PCI/PM: Adjust pcie_wait_for_link_delay() for caller delayBjorn Helgaas1-2/+2
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 <[email protected]>
2020-05-14PCI: Program MPS for RCiEP devicesAshok Raj1-1/+21
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/[email protected] Tested-by: Dave Jiang <[email protected]> Signed-off-by: Ashok Raj <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected]
2020-05-14PCI: Fix pci_host_bridge struct device release/free handlingRob Herring2-18/+20
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/[email protected] Reported-by: Anders Roxell <[email protected]> Tested-by: Anders Roxell <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lorenzo Pieralisi <[email protected]> Acked-by: Arnd Bergmann <[email protected]>
2020-05-14PCI: Fix pci_register_host_bridge() device_register() error handlingRob Herring1-2/+3
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/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]>
2020-05-14PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port()Yicong Yang4-27/+3
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/[email protected] Signed-off-by: Yicong Yang <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Kalle Valo <[email protected]> # wireless Acked-by: Mika Westerberg <[email protected]> # thunderbolt
2020-05-13PCI: brcmstb: Wait for Raspberry Pi's firmware when presentNicolas Saenz Julienne1-0/+17
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/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Rob Herring <[email protected]>
2020-05-12PCI: Replace zero-length array with flexible-arrayGustavo A. R. Silva1-1/+1
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 <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2020-05-12PCI: Check for platform_get_irq() failure consistentlyAman Sharma7-10/+16
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/[email protected] [bhelgaas: commit log, squash into one patch] Signed-off-by: Aman Sharma <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: Richard Zhu <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Karthikeyan Mitran <[email protected]> Cc: Hou Zhiqiang <[email protected]> Cc: Thomas Petazzoni <[email protected]> Cc: Ryder Lee <[email protected]> Cc: Marc Gonzalez <[email protected]>
2020-05-11PCI: hv: Retry PCI bus D0 entry on invalid device stateWei Hu1-2/+38
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/[email protected] Signed-off-by: Wei Hu <[email protected]> [[email protected]: commit log] Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2020-05-11PCI: hv: Fix the PCI HyperV probe failure path to release resource properlyWei Hu1-4/+16
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/[email protected] Signed-off-by: Wei Hu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Michael Kelley <[email protected]>
2020-05-11PCI: brcmstb: Disable L0s component of ASPM if requestedJim Quinlan1-1/+13
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/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Nicolas Saenz Julienne <[email protected]>
2020-05-11PCI: brcmstb: Fix window register offset from 4 to 8Jim Quinlan1-2/+2
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/[email protected] Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Nicolas Saenz Julienne <[email protected]>
2020-05-11PCI: brcmstb: Don't clk_put() a managed clockJim Quinlan1-1/+0
clk_put() was being invoked on a clock obtained by devm_clk_get_optional(). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jim Quinlan <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Florian Fainelli <[email protected]> Acked-by: Nicolas Saenz Julienne <[email protected]>
2020-05-11PCI: brcmstb: Assert fundamental reset on initializationNicolas Saenz Julienne1-0/+1
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/[email protected] Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Florian Fainelli <[email protected]>
2020-05-11PCI: endpoint: Pass page size as argument to pci_epc_mem_init()Lad Prabhakar3-2/+9
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]>
2020-05-11PCI: rcar: Fix calculating mask for PCIEPAMR registerLad Prabhakar1-1/+4
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2020-05-11PCI: rcar: Move shareable code to a common fileLad Prabhakar4-293/+361
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2020-05-11PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.cLad Prabhakar3-1/+11
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 <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>
2020-05-11PCI: tegra: Fix reporting GPIO error valuePali Rohár1-2/+2
Error code is stored in rp->reset_gpio and not in err variable. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-05-09ACPI: hotplug: PCI: Use the new acpi_evaluate_reg() helperHans de Goede1-10/+3
Use the new acpi_evaluate_reg() helper in the acpiphp_glue.c code. Acked-by: Bjorn Helgaas <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-05-08PCI: Avoid Pericom USB controller OHCI/EHCI PME# defectKai-Heng Feng1-0/+13
Both Pericom OHCI and EHCI devices advertise PME# support from all power states: 06:00.0 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] (rev 01) (prog-if 10 [OHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB OHCI Controller [12d8:400e] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) 06:00.2 USB controller [0c03]: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] (rev 01) (prog-if 20 [EHCI]) Subsystem: Pericom Semiconductor PI7C9X442SL USB EHCI Controller [12d8:400f] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) But testing shows that it's unreliable: there is a 20% chance PME# won't be asserted when a USB device is plugged. Remove PME support for both devices to make USB plugging work reliably. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205981 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: [email protected]
2020-05-07PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X BridgesKai-Heng Feng1-10/+0
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for Linux to enable ASPM, but for some undocumented reason, it didn't enable ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge. Remove this exclusion so we can enable ASPM on these links. The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001 PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the Intel SoC to enter deeper Package C-states, which is a significant power savings. [bhelgaas: commit log] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2020-05-07PCI: rcar: Add suspend/resumeKazufumi Ikeda1-15/+75
Add suspend/resume support for rcar. The resume handler reprograms the hardware based on the software state kept in specific device structures, so there is no need to save registers on suspend. Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kazufumi Ikeda <[email protected]> Signed-off-by: Gaku Inami <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Phil Edworthy <[email protected]> Cc: Simon Horman <[email protected]> Cc: Wolfram Sang <[email protected]> Cc: [email protected]
2020-05-07PCI: rcar: Fix incorrect programming of OB windowsAndrew Murray1-4/+5
The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between a CPU address (which is determined by the window number 'x') and a programmed PCI address - Thus allowing the controller to translate CPU accesses into PCI accesses. However the existing code incorrectly writes the CPU address - lets fix this by writing the PCI address instead. For memory transactions, existing DT users describe a 1:1 identity mapping and thus this change should have no effect. However the same isn't true for I/O. Link: https://lore.kernel.org/r/[email protected] Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver") Tested-by: Marek Vasut <[email protected]> Signed-off-by: Andrew Murray <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Marek Vasut <[email protected]>
2020-05-07PCI: host-generic: Eliminate pci_host_common_probe wrappersRob Herring6-42/+24
Most ECAM host drivers are just different pci_ecam_ops which can be DT match table data. That's already the case in some cases, but let's do that for all the ECAM drivers. Then we can use of_device_get_match_data() in pci_host_common_probe() and eliminate the probe wrapper functions and use pci_host_common_probe() directly for probe. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Cc: Zhou Wang <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Andrew Murray <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Robert Richter <[email protected]> Cc: Marc Gonzalez <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: [email protected] Cc: [email protected]
2020-05-05PCI: altera: Clean up indentation issue on a return statementColin Ian King1-1/+1
A return statment is indented incorrectly, remove extraneous space. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.