summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-02PCI: aardvark: Assert PERST# when unbinding driverPali Rohár
Put the PCIe card into reset by asserting PERST# signal when unbinding driver. It doesn't make sense to leave the card working if it can't communicate with the host. This should also save some power. Link: https://lore.kernel.org/r/20211130172913.9727-10-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Fix memory leak in driver unbindPali Rohár
Free config space for emulated root bridge when unbinding driver to fix memory leak. Do it after disabling and masking all interrupts, since aardvark interrupt handler accesses config space of emulated root bridge. Link: https://lore.kernel.org/r/20211130172913.9727-9-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Mask all interrupts when unbinding driverPali Rohár
Ensure that no interrupt can be triggered after driver unbind. Link: https://lore.kernel.org/r/20211130172913.9727-8-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Disable bus mastering when unbinding driverPali Rohár
Ensure that after driver unbind PCIe cards are not able to forward memory and I/O requests in the upstream direction. Link: https://lore.kernel.org/r/20211130172913.9727-7-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Comment actions in driver remove methodPali Rohár
Add two more comments into the advk_pcie_remove() method. Link: https://lore.kernel.org/r/20211130172913.9727-6-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Clear all MSIs at setupPali Rohár
We already clear all the other interrupts (ISR0, ISR1, HOST_CTRL_INT). Define a new macro PCIE_MSI_ALL_MASK and do the same clearing for MSIs, to ensure that we don't start receiving spurious interrupts. Use this new mask in advk_pcie_handle_msi(); Link: https://lore.kernel.org/r/20211130172913.9727-5-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: aardvark: Add support for DEVCAP2, DEVCTL2, LNKCAP2 and LNKCTL2 ↵Pali Rohár
registers on emulated bridge PCI aardvark hardware supports access to DEVCAP2, DEVCTL2, LNKCAP2 and LNKCTL2 configuration registers of PCIe core via PCIE_CORE_PCIEXP_CAP. Export them via emulated software root bridge. Link: https://lore.kernel.org/r/20211130172913.9727-4-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: pci-bridge-emul: Add definitions for missing capabilities registersPali Rohár
pci-bridge-emul driver already allocates buffer for capabilities up to the PCI_EXP_SLTSTA2 register, but does not define bit access behavior for these registers. Add these missing definitions. Link: https://lore.kernel.org/r/20211130172913.9727-3-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: pci-bridge-emul: Add description for class_revision fieldPali Rohár
The current assignment to the class_revision member class_revision |= cpu_to_le32(PCI_CLASS_BRIDGE_PCI << 16); can make the reader think that class is at high 16 bits of the member and revision at low 16 bits. In reality, class is at high 24 bits, but the class for PCI Bridge Normal Decode is PCI_CLASS_BRIDGE_PCI << 8. Change the assignment and add a comment to make this clearer. Link: https://lore.kernel.org/r/20211130172913.9727-2-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-02PCI: dwc: Do not remap invalid resTim Harvey
On imx6 and perhaps others when pcie probes you get a: imx6q-pcie 33800000.pcie: invalid resource This occurs because the atu is not specified in the DT and as such it should not be remapped. Link: https://lore.kernel.org/r/20211101180243.23761-1-tharvey@gateworks.com Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Cc: Richard Zhu <hongxing.zhu@nxp.com>
2021-12-01PCI: mvebu: Remove custom mvebu_pci_host_probe() functionPali Rohár
Now after pci_ioremap_io() usage was replaced by devm_pci_remap_iospace() function, there is no need to use custom mvebu_pci_host_probe() function. Current implementation of mvebu_pci_host_probe() is same as standard PCI core function pci_host_probe(). So replace mvebu_pci_host_probe() call by pci_host_probe() and remove custom mvebu_pci_host_probe() function. Link: https://lore.kernel.org/r/20211124154116.916-4-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-12-01PCI: rcar: Check if device is runtime suspended instead of __clk_is_enabled()Marek Vasut
Replace __clk_is_enabled() with pm_runtime_suspended(), as __clk_is_enabled() was checking the wrong bus clock and caused the following build error too: arm-linux-gnueabi-ld: drivers/pci/controller/pcie-rcar-host.o: in function `rcar_pcie_aarch32_abort_handler': pcie-rcar-host.c:(.text+0xdd0): undefined reference to `__clk_is_enabled' Link: https://lore.kernel.org/r/20211115204641.12941-1-marek.vasut@gmail.com Fixes: a115b1bd3af0 ("PCI: rcar: Add L1 link state fix into data abort hook") Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Randy Dunlap <rdunlap@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2021-12-01PCI: vmd: Clean up domain before enumerationNirmal Patel
During VT-d pass-through, the VMD driver occasionally fails to enumerate underlying NVMe devices when repetitive reboots are performed in the guest OS. The issue can be resolved by resetting VMD root ports for proper enumeration and triggering secondary bus reset which will also propagate reset through downstream bridges. Link: https://lore.kernel.org/r/20211116221136.85134-1-nirmal.patel@linux.intel.com Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Jon Derrick <jonathan.derrick@linux.dev>
2021-12-01PCI: xilinx-nwl: Simplify code and fix a memory leakChristophe JAILLET
Allocate space for bitmap in struct nwl_msi at probe time instead of dynamically allocating the memory at runtime. This simplifies code (especially error handling paths) and avoid some open-coded arithmetic in allocator arguments. This also fixes a potential memory leak. The bitmap was never freed. It is now part of a managed resource. Link: https://lore.kernel.org/r/5483f10a44b06aad55728576d489adfa16c3be91.1636279388.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-11-30PCI: apple: Enable clock gatingHector Martin
These pokes are not required to make the PCIe port work, but it sounds like this should save some power at least. Link: https://lore.kernel.org/r/20211117141916.197192-1-marcan@marcan.st Tested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org>
2021-11-30PCI: xgene: Fix IB window setupRob Herring
Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") broke PCI support on XGene. The cause is the IB resources are now sorted in address order instead of being in DT dma-ranges order. The result is which inbound registers are used for each region are swapped. I don't know the details about this h/w, but it appears that IB region 0 registers can't handle a size greater than 4GB. In any case, limiting the size for region 0 is enough to get back to the original assignment of dma-ranges to regions. Link: https://lore.kernel.org/all/CA+enf=v9rY_xnZML01oEgKLmvY1NGBUUhnSJaETmXtDtXfaczA@mail.gmail.com/ Link: https://lore.kernel.org/r/20211129173637.303201-1-robh@kernel.org Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") Reported-by: Stéphane Graber <stgraber@ubuntu.com> Tested-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Cc: stable@vger.kernel.org # v5.5+
2021-11-30PCI: mvebu: Replace pci_ioremap_io() usage by devm_pci_remap_iospace()Pali Rohár
Now when ARM architecture code also provides standard PCI core function pci_remap_iospace(), use its devm_pci_remap_iospace() variant in pci-mvebu.c driver instead of old ARM-specific pci_ioremap_io() function. Call devm_pci_remap_iospace() before adding IO resource to host bridge structure, at the place where it should be. Link: https://lore.kernel.org/r/20211124154116.916-3-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-11-30arm: ioremap: Implement standard PCI function pci_remap_iospace()Pali Rohár
pci_remap_iospace() is standard PCI core function. Architecture code can reimplement default core implementation if needs custom arch specific functionality. ARM needs custom implementation due to pci_ioremap_set_mem_type() hook which allows ARM platforms to change mem type for iospace. Implement this pci_remap_iospace() function for ARM architecture to correctly handle pci_ioremap_set_mem_type() hook, which allows usage of this standard PCI core function also for platforms which needs different mem type (e.g. Marvell Armada 375, 38x and 39x). Link: https://lore.kernel.org/r/20211124154116.916-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-29PCI: xgene-msi: Use bitmap_zalloc() when applicableChristophe JAILLET
'xgene_msi->bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Link: https://lore.kernel.org/r/32f3bc1fbfbd6ee0815e565012904758ca9eff7e.1635019243.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
2021-11-29PCI: qcom: Fix an error handling path in 'qcom_pcie_probe()'Christophe JAILLET
If 'of_device_get_match_data()' fails, previous 'pm_runtime_get_sync()/ pm_runtime_enable()' should be undone. To fix it, the easiest is to move this block of code before the memory allocations and the pm_runtime_xxx calls. Link: https://lore.kernel.org/r/4d03c636193f64907c8dacb17fa71ed05fd5f60c.1636220582.git.christophe.jaillet@wanadoo.fr Fixes: b89ff410253d ("PCI: qcom: Replace ops with struct pcie_cfg in pcie match data") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
2021-11-29PCI: mediatek-gen3: Disable DVFSRC voltage requestJianjun Wang
When the DVFSRC (dynamic voltage and frequency scaling resource collector) feature is not implemented, the PCIe hardware will assert a voltage request signal when exit from the L1 PM Substates to request a specific Vcore voltage, but cannot receive the voltage ready signal, which will cause the link to fail to exit the L1 PM Substates. Disable DVFSRC voltage request by default, we need to find a common way to enable it in the future. Link: https://lore.kernel.org/r/20211015063602.29058-1-jianjun.wang@mediatek.com Fixes: d3bf75b579b9 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192") Tested-by: Qizhong Cheng <qizhong.cheng@mediatek.com> Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-11-19PCI/ASPM: Remove struct aspm_latencySaheed O. Bolarinwa
The struct aspm_latency is now used only inside pcie_aspm_check_latency(). Replace struct aspm_latency variables with u32 variables and remove struct aspm_latency. Link: https://lore.kernel.org/r/20211119193732.12343-5-refactormyself@gmail.com Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2021-11-19PCI/ASPM: Stop caching device L0s, L1 acceptable exit latenciesSaheed O. Bolarinwa
Previously we calculated the device's acceptable L0s and L1 exit latencies in pcie_aspm_cap_init() and cached them in struct pcie_link_state. These values are only used in pcie_aspm_check_latency() where they are compared with the actual exit latencies of the link. This path is used when removing or changing the D state of the device, so it's relatively low frequency. To reduce the amount of per-link data we store, remove the acceptable[] arrays from struct pcie_link_state and calculate them directly from the already-cached Device Capabilities register when needed. [bhelgaas: use endpoint->devcap instead of reading it again] Link: https://lore.kernel.org/r/20211119193732.12343-4-refactormyself@gmail.com Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-19PCI/ASPM: Stop caching link L0s, L1 exit latenciesSaheed O. Bolarinwa
Previously we calculated the upstream and downstream L0s and L1 exit latencies of the link in pcie_aspm_cap_init() and cached them in struct pcie_link_state.latency_*. These values are only used in pcie_aspm_check_latency() where they are compared with the acceptable latencies on the link. This path is used when removing or changing the D state of the device, so it's relatively low frequency. To reduce the amount of per-link data we store, remove the latency_* entries from struct pcie_link_state and calculate the latencies directly where they are needed. Link: https://lore.kernel.org/r/20211119193732.12343-3-refactormyself@gmail.com Signed-off-by: Saheed O. Bolarinwa <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-19PCI/ASPM: Move pci_function_0() upwardBolarinwa O. Saheed
Move pci_function_0() earlier so we can use it from other functions. Link: https://lore.kernel.org/r/20211119193732.12343-2-refactormyself@gmail.com Signed-off-by: Bolarinwa O. Saheed <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2021-11-19PCI: pciehp: Fix infinite loop in IRQ handler upon power faultLukas Wunner
The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214989 Link: https://lore.kernel.org/linux-pci/DM8PR11MB5702255A6A92F735D90A4446868B9@DM8PR11MB5702.namprd11.prod.outlook.com Fixes: 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race") Link: https://lore.kernel.org/r/66eaeef31d4997ceea357ad93259f290ededecfd.1637187226.git.lukas@wunner.de Reported-by: Joseph Bao <joseph.bao@intel.com> Tested-by: Joseph Bao <joseph.bao@intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.19+ Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
2021-11-19PCI/switchtec: Declare local state_names[] as staticKelvin Cao
The local state_names[] array is constant and need not be allocated and populated each time we enter stuser_set_state(). Declare it as static. See the link below for the discussion. https://lore.kernel.org/r/20211014141859.11444-1-kelvin.cao@microchip.com/ [bhelgaas: simplify commit log] Suggested-by: Krzysztof Wilczyński <kw@linux.com> Link: https://lore.kernel.org/r/20211119003803.2333-3-kelvin.cao@microchip.com Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2021-11-19PCI/switchtec: Add Gen4 automotive device IDsKelvin Cao
Advertise support of the Gen4 automotive variants in module's device ID table and add the same IDs to the list of switchtec quirks. Link: https://lore.kernel.org/r/20211119003803.2333-2-kelvin.cao@microchip.com Signed-off-by: Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2021-11-18PCI: xgene: Use PCI_ERROR_RESPONSE to identify config read errorsNaveen Naidu
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment about identifying config read errors. This makes checks for config read errors easier to find. Comment change only. Link: https://lore.kernel.org/r/388b9733bd55394581c447be9f3df42ca2c9759c.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: hv: Use PCI_ERROR_RESPONSE to identify config read errorsNaveen Naidu
Include PCI_ERROR_RESPONSE along with 0xFFFFFFFF in the comment about identifying config read errors. This makes checks for config read errors easier to find. Comment change only. Link: https://lore.kernel.org/r/12124f41cab7d8aa944de05f85d9567bfe157704.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: keystone: Use PCI_ERROR_RESPONSE to identify config read errorsNaveen Naidu
Include PCI_ERROR_RESPONSE along with 0xffffffff in the comment about identifying config read errors. This makes checks for config read errors easier to find. Comment change only. Link: https://lore.kernel.org/r/6ae6b071d92052dc511407513e2a7c0035aff9e7.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: Use PCI_ERROR_RESPONSE to identify config read errorsNaveen Naidu
Include PCI_ERROR_RESPONSE along with 0xFFFF and 0xFFFFFFFF in the comment about identifying config read errors. This makes checks for config read errors easier to find. Comment change only. Link: https://lore.kernel.org/r/866e2db544df45af70df7e64659bf02e03998ae3.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Link: https://lore.kernel.org/r/b12005c0d57bb9d4c8b486724d078b7bd92f8321.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI/PME: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Compile tested only. Link: https://lore.kernel.org/r/679ce049bccf10df3ca9ef4918ee2c3235afdaea.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI/DPC: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Compile tested only. Link: https://lore.kernel.org/r/9b0632f1f183432149f495cf12bdd5a72cc597a4.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: pciehp: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Compile tested only. Link: https://lore.kernel.org/r/e185b052fbfd530df703a36dd31126cb870eed95.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lukas Wunner <lukas@wunner.de>
2021-11-18PCI: vmd: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Link: https://lore.kernel.org/r/ed01cad87a2e35f3865275b5fb34290817a1ebf8.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Derrick <jonathan.derrick@linux.dev>
2021-11-18PCI/ERR: Use PCI_POSSIBLE_ERROR() to check config readsNaveen Naidu
When config pci_ops.read() can detect failed PCI transactions, the data returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff). Obviously a successful PCI config read may *also* return that data if a config register happens to contain ~0, so it doesn't definitively indicate an error unless we know the register cannot contain ~0. Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Link: https://lore.kernel.org/r/f4d18d470cb90f9cb52ea155b01528ba2e76e8d6.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: rockchip-host: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/50f9a6fa16521a86cb24d2f27c1f66eb3568cb9a.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: rcar-host: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/83540eb3ae76a0d28bbe03d69d685a6d549b456b.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-11-18PCI: altera: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/ed5020e5b008b28c33a90c9c1670cef2393d3b7e.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: mvebu: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/f30264b137b1282ffda34d336e8060bb13d60b98.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: aardvark: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/335014f2b44cdf24ed1e37cb7c88f6c5de896cc2.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pali Rohár <pali@kernel.org>
2021-11-18PCI: kirin: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/f87e22bc09a471d2cf15ad05dfd6432f57739aed.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: histb: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/7da7ea760abc5f85cad6e9b0d3e59eebd93f50d3.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: exynos: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/765c2f27d85fcee4eb137023dc0a8f864eee9e36.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: mediatek: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/666127469482f9ca177805ff52aeb7bccb26e4c9.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: iproc: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/b95defa3db834789a4207df5d6b0216c8b610524.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: thunder: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/22f471b638276422926c49f3d42ac41bc7b28b3d.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-11-18PCI: Drop error data fabrication when config read failsNaveen Naidu
If config pci_ops.read() methods return failure, the PCI_OP_READ() and PCI_USER_READ_CONFIG() wrappers use PCI_SET_ERROR_RESPONSE() to set the data value, so there's no need to set it in the pci_ops.read() methods themselves. Drop the unnecessary data value fabrication when pci_ops.read() fails. Link: https://lore.kernel.org/r/1b2edb060cf19b45f70645b331e6c08c9ba798c0.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring <robh@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-22 23:09:22 +0000