Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48 |
|
#
294c1e4f |
| 24-Aug-2023 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Simplify pcie_capability_clear_and_set_word() control flow
Return early for errors in pcie_capability_clear_and_set_word_unlocked() and pcie_capability_clear_and_set_dword() to simplify the con
PCI: Simplify pcie_capability_clear_and_set_word() control flow
Return early for errors in pcie_capability_clear_and_set_word_unlocked() and pcie_capability_clear_and_set_dword() to simplify the control flow.
No functional change intended.
Link: https://lore.kernel.org/r/20230824193712.542167-13-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
Revision tags: v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
5e70d0ac |
| 17-Jul-2023 |
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> |
PCI: Add locking to RMW PCI Express Capability Register accessors
Many places in the kernel write the Link Control and Root Control PCI Express Capability Registers without proper concurrency contro
PCI: Add locking to RMW PCI Express Capability Register accessors
Many places in the kernel write the Link Control and Root Control PCI Express Capability Registers without proper concurrency control and this could result in losing the changes one of the writers intended to make.
Add pcie_cap_lock spinlock into the struct pci_dev and use it to protect bit changes made in the RMW capability accessors. Protect only a selected set of registers by differentiating the RMW accessor internally to locked/unlocked variants using a wrapper which has the same signature as pcie_capability_clear_and_set_word(). As the Capability Register (pos) given to the wrapper is always a constant, the compiler should be able to simplify all the dead-code away.
So far only the Link Control Register (ASPM, hotplug, link retraining, various drivers) and the Root Control Register (AER & PME) seem to require RMW locking.
Suggested-by: Lukas Wunner <lukas@wunner.de> Fixes: c7f486567c1d ("PCI PM: PCIe PME root port service driver") Fixes: f12eb72a268b ("PCI/ASPM: Use PCI Express Capability accessors") Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") Fixes: affa48de8417 ("staging/rdma/hfi1: Add support for enabling/disabling PCIe ASPM") Fixes: 849a9366cba9 ("misc: rtsx: Add support new chip rts5228 mmc: rtsx: Add support MMC_CAP2_NO_MMC") Fixes: 3d1e7aa80d1c ("misc: rtsx: Use pcie_capability_clear_and_set_word() for PCI_EXP_LNKCTL") Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261") Fixes: 3df4fce739e2 ("misc: rtsx: separate aspm mode into MODE_REG and MODE_CFG") Fixes: 121e9c6b5c4c ("misc: rtsx: modify and fix init_hw function") Fixes: 19f3bd548f27 ("mfd: rtsx: Remove LCTLR defination") Fixes: 773ccdfd9cc6 ("mfd: rtsx: Read vendor setting from config space") Fixes: 8275b77a1513 ("mfd: rts5249: Add support for RTS5250S power saving") Fixes: 5da4e04ae480 ("misc: rtsx: Add support for RTS5260") Fixes: 0f49bfbd0f2e ("tg3: Use PCI Express Capability accessors") Fixes: 5e7dfd0fb94a ("tg3: Prevent corruption at 10 / 100Mbps w CLKREQ") Fixes: b726e493e8dc ("r8169: sync existing 8168 device hardware start sequences with vendor driver") Fixes: e6de30d63eb1 ("r8169: more 8168dp support.") Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards") Fixes: 6f461f6c7c96 ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata") Fixes: 1eae4eb2a1c7 ("e1000e: Disable L1 ASPM power savings for 82573 mobile variants") Fixes: 8060e169e02f ("ath9k: Enable extended synch for AR9485 to fix L0s recovery issue") Fixes: 69ce674bfa69 ("ath9k: do btcoex ASPM disabling at initialization time") Fixes: f37f05503575 ("mt76: mt76x2e: disable pcie_aspm by default") Link: https://lore.kernel.org/r/20230717120503.15276-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: "Rafael J. Wysocki" <rafael@kernel.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
503fa236 |
| 17-Sep-2022 |
Maciej W. Rozycki <macro@orcam.me.uk> |
PCI: Access Link 2 registers only for devices with Links
PCIe r2.0, sec 7.8 added Link Capabilities/Status/Control 2 registers to the PCIe Capability with Capability Version 2.
Previously we assume
PCI: Access Link 2 registers only for devices with Links
PCIe r2.0, sec 7.8 added Link Capabilities/Status/Control 2 registers to the PCIe Capability with Capability Version 2.
Previously we assumed these registers were implemented for all PCIe Capabilities of version 2 or greater, but in fact they are only implemented for devices with Links.
Update pcie_capability_reg_implemented() to check whether the device has a Link.
[bhelgaas: commit log, squash export] Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057070.2275@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209100057300.2275@angie.orcam.me.uk Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57 |
|
#
92c45b63 |
| 05-Aug-2020 |
Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> |
PCI: Reduce warnings on possible RW1C corruption
For hardware that only supports 32-bit writes to PCI there is the possibility of clearing RW1C (write-one-to-clear) bits. A rate-limited messages was
PCI: Reduce warnings on possible RW1C corruption
For hardware that only supports 32-bit writes to PCI there is the possibility of clearing RW1C (write-one-to-clear) bits. A rate-limited messages was introduced by fb2659230120, but rate-limiting is not the best choice here. Some devices may not show the warnings they should if another device has just produced a bunch of warnings. Also, the number of messages can be a nuisance on devices which are otherwise working fine.
Change the ratelimit to a single warning per bus. This ensures no bus is 'starved' of emitting a warning and also that there isn't a continuous stream of warnings. It would be preferable to have a warning per device, but the pci_dev structure is not available here, and a lookup from devfn would be far too slow.
Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit config writes") Link: https://lore.kernel.org/r/20200806041455.11070-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Scott Branden <scott.branden@broadcom.com>
show more ...
|
#
289e3ea3 |
| 18-Nov-2021 |
Naveen Naidu <naveennaidu479@gmail.com> |
PCI: Use PCI_ERROR_RESPONSE to identify config read errors
Include PCI_ERROR_RESPONSE along with 0xFFFF and 0xFFFFFFFF in the comment about identifying config read errors. This makes checks for conf
PCI: Use PCI_ERROR_RESPONSE to identify config read errors
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>
show more ...
|
#
316df706 |
| 18-Nov-2021 |
Naveen Naidu <naveennaidu479@gmail.com> |
PCI: Drop error data fabrication when config read fails
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
PCI: Drop error data fabrication when config read fails
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>
show more ...
|
#
9bc9310c |
| 18-Nov-2021 |
Naveen Naidu <naveennaidu479@gmail.com> |
PCI: Use PCI_SET_ERROR_RESPONSE() for disconnected devices
A config read from a PCI device that doesn't exist or doesn't respond causes a PCI error. There's no real data to return to satisfy the CPU
PCI: Use PCI_SET_ERROR_RESPONSE() for disconnected devices
A config read from a PCI device that doesn't exist or doesn't respond causes a PCI error. There's no real data to return to satisfy the CPU read, so most hardware fabricates ~0 data.
Use PCI_SET_ERROR_RESPONSE() to set the error response when we think the device has already been disconnected.
This helps unify PCI error response checking and make error checks consistent and easier to find.
Link: https://lore.kernel.org/r/29db0a6874716db80757e4e3cdd03562f13eb0cb.1637243717.git.naveennaidu479@gmail.com Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
f4f7eb43 |
| 18-Nov-2021 |
Naveen Naidu <naveennaidu479@gmail.com> |
PCI: Set error response data when config read fails
When a PCI config read fails, most PCI host bridges fabricate ~0 data to complete the CPU read. But some host bridges do not; their drivers may o
PCI: Set error response data when config read fails
When a PCI config read fails, most PCI host bridges fabricate ~0 data to complete the CPU read. But some host bridges do not; their drivers may only return an error from the pci_ops.read() method.
In PCI_OP_READ() and PCI_USER_READ_CONFIG(), use PCI_SET_ERROR_RESPONSE() to set the data value to indicate an error when pci_ops.read() fails.
This means the host bridge driver no longer needs to fabricate error data when they detect errors.
This makes error response fabrication consistent and helps in removal of a lot of repeated code.
Suggested-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/4188fc5465631ce0d472d1423de3d9fb2f09b8ff.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> Reviewed-by: Pali Rohár <pali@kernel.org>
show more ...
|
#
e37d2697 |
| 05-Aug-2020 |
Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> |
PCI: Reduce warnings on possible RW1C corruption
[ Upstream commit 92c45b63ce22c8898aa41806e8d6692bcd577510 ]
For hardware that only supports 32-bit writes to PCI there is the possibility of cleari
PCI: Reduce warnings on possible RW1C corruption
[ Upstream commit 92c45b63ce22c8898aa41806e8d6692bcd577510 ]
For hardware that only supports 32-bit writes to PCI there is the possibility of clearing RW1C (write-one-to-clear) bits. A rate-limited messages was introduced by fb2659230120, but rate-limiting is not the best choice here. Some devices may not show the warnings they should if another device has just produced a bunch of warnings. Also, the number of messages can be a nuisance on devices which are otherwise working fine.
Change the ratelimit to a single warning per bus. This ensures no bus is 'starved' of emitting a warning and also that there isn't a continuous stream of warnings. It would be preferable to have a warning per device, but the pci_dev structure is not available here, and a lookup from devfn would be far too slow.
Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit config writes") Link: https://lore.kernel.org/r/20200806041455.11070-1-mark.tomlinson@alliedtelesis.co.nz Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7 |
|
#
2a7e32d0 |
| 25-Jun-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix pci_cfg_wait queue locking problem
The pci_cfg_wait queue is used to prevent user-space config accesses to devices while they are recovering from reset.
Previously we used these operations
PCI: Fix pci_cfg_wait queue locking problem
The pci_cfg_wait queue is used to prevent user-space config accesses to devices while they are recovering from reset.
Previously we used these operations on pci_cfg_wait:
__add_wait_queue(&pci_cfg_wait, ...) __remove_wait_queue(&pci_cfg_wait, ...) wake_up_all(&pci_cfg_wait)
The wake_up acquires the wait queue lock, but the add and remove do not.
Originally these were all protected by the pci_lock, but cdcb33f98244 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock"), moved wake_up_all() outside pci_lock, so it could race with add/remove operations, which caused occasional kernel panics, e.g., during vfio-pci hotplug/unplug testing:
Unable to handle kernel read from unreadable memory at virtual address ffff802dac469000
Resolve this by using wait_event() instead of __add_wait_queue() and __remove_wait_queue(). The wait queue lock is held by both wait_event() and wake_up_all(), so it provides mutual exclusion.
Fixes: cdcb33f98244 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock") Link: https://lore.kernel.org/linux-pci/79827f2f-9b43-4411-1376-b9063b67aee3@huawei.com/T/#u Based-on: https://lore.kernel.org/linux-pci/20191210031527.40136-1-zhengxiang9@huawei.com/ Based-on-patch-by: Xiang Zheng <zhengxiang9@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Xiang Zheng <zhengxiang9@huawei.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Biaoxiang Ye <yebiaoxiang@huawei.com>
show more ...
|
Revision tags: v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47 |
|
#
b9153581 |
| 15-Jun-2020 |
Bolarinwa Olayemi Saheed <refactormyself@gmail.com> |
PCI: Align PCIe capability and PCI accessor return values
The PCI config accessors (pci_read_config_word(), et al) return PCIBIOS_SUCCESSFUL (zero) or positive error values like PCIBIOS_FUNC_NOT_SUP
PCI: Align PCIe capability and PCI accessor return values
The PCI config accessors (pci_read_config_word(), et al) return PCIBIOS_SUCCESSFUL (zero) or positive error values like PCIBIOS_FUNC_NOT_SUPPORTED.
The PCIe capability accessors similarly return PCIBIOS errors, but in addition, they can return -EINVAL. This makes it harder than it should be to check for errors.
Return PCIBIOS_BAD_REGISTER_NUMBER instead of -EINVAL in all PCIe capability accessors.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com> Link: https://lore.kernel.org/r/20200615073225.24061-9-refactormyself@gmail.com Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
af65d1ad |
| 18-Oct-2019 |
Patel, Mayurkumar <mayurkumar.patel@intel.com> |
PCI/AER: Save AER Capability for suspend/resume
Previously we did not save and restore the AER configuration on suspend/resume, so the configuration may be lost after resume.
Save the AER configura
PCI/AER: Save AER Capability for suspend/resume
Previously we did not save and restore the AER configuration on suspend/resume, so the configuration may be lost after resume.
Save the AER configuration during suspend and restore it during resume.
[bhelgaas: commit log] Link: https://lore.kernel.org/r/92EBB4272BF81E4089A7126EC1E7B28492C3B007@IRSMSX101.ger.corp.intel.com Signed-off-by: Mayurkumar Patel <mayurkumar.patel@intel.com> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
984998e3 |
| 22-Aug-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Make pcie_downstream_port() available outside of access.c
pcie_downstream_port() is useful in other places where code needs to determine whether the PCIe port is downstream so make it available
PCI: Make pcie_downstream_port() available outside of access.c
pcie_downstream_port() is useful in other places where code needs to determine whether the PCIe port is downstream so make it available outside of access.c.
Link: https://lore.kernel.org/r/20190822085553.62697-1-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
show more ...
|
Revision tags: v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9 |
|
#
5180fd91 |
| 18-Sep-2018 |
Keith Busch <keith.busch@intel.com> |
PCI: Uninline PCI bus accessors for better ftracing
The PCI bus config accessors could be inlined into other accessor functions, which makes it so they can't be traced. Force them to never be inlin
PCI: Uninline PCI bus accessors for better ftracing
The PCI bus config accessors could be inlined into other accessor functions, which makes it so they can't be traced. Force them to never be inlined so that ftrace can hook into these functions.
Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16 |
|
#
df62ab5e |
| 09-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Tidy comments
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended.
Signed-off-by: Bjorn Helg
PCI: Tidy comments
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
f0eb77ae |
| 19-Mar-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/VPD: Move VPD access code to vpd.c
Move the VPD-related code from access.c to vpd.c. The goal is to encapsulate all the VPD code and structures in vpd.c.
No functional change intended.
Signed
PCI/VPD: Move VPD access code to vpd.c
Move the VPD-related code from access.c to vpd.c. The goal is to encapsulate all the VPD code and structures in vpd.c.
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v4.15 |
|
#
7328c8f4 |
| 26-Jan-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add SPDX GPL-2.0 when no license was specified
b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") added SPDX GPL-2.0 to several PCI files that previo
PCI: Add SPDX GPL-2.0 when no license was specified
b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") added SPDX GPL-2.0 to several PCI files that previously contained no license information.
Add SPDX GPL-2.0 to all other PCI files that did not contain any license information and hence were under the default GPL version 2 license of the kernel.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
7506dc79 |
| 18-Jan-2018 |
Frederick Lawler <fred@fredlawl.com> |
PCI: Add wrappers for dev_printk()
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended.
Signed-off-by: Frederick Lawler <fred@fredlawl.
PCI: Add wrappers for dev_printk()
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended.
Signed-off-by: Frederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4 |
|
#
714fe383 |
| 16-Mar-2017 |
Thomas Gleixner <tglx@linutronix.de> |
PCI: Provide Kconfig option for lockless config space accessors
The generic PCI configuration space accessors are globally serialized via pci_lock. On larger systems this causes massive lock content
PCI: Provide Kconfig option for lockless config space accessors
The generic PCI configuration space accessors are globally serialized via pci_lock. On larger systems this causes massive lock contention when the configuration space has to be accessed frequently. One such access pattern is the Intel Uncore performance counter unit.
Provide a kernel config option which can be selected by an architecture when the low level PCI configuration space accessors in the architecture use their own serialization or can operate completely lockless.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <helgaas@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/20170316215057.205961140@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
show more ...
|
#
449e2f9e |
| 23-May-2017 |
Brian Norris <briannorris@chromium.org> |
PCI: Make error code types consistent in pci_{read,write}_config_*
Callers normally treat the config space accessors as returning PCBIOS_* error codes, not Linux error codes (or they don't look at t
PCI: Make error code types consistent in pci_{read,write}_config_*
Callers normally treat the config space accessors as returning PCBIOS_* error codes, not Linux error codes (or they don't look at them at all). We have pcibios_err_to_errno() in case the error code needs to be translated.
Fixes: 4b1038834739 ("PCI: Don't attempt config access to disconnected devices") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
show more ...
|
#
9b70ae49 |
| 19-Apr-2017 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Include PCI-to-PCIe bridges as "Downstream Ports"
A PCI/PCI-X to PCI Express bridge, sometimes referred to as a "reverse bridge", is a bridge with conventional PCI or PCI-X on its primary side
PCI: Include PCI-to-PCIe bridges as "Downstream Ports"
A PCI/PCI-X to PCI Express bridge, sometimes referred to as a "reverse bridge", is a bridge with conventional PCI or PCI-X on its primary side and a PCI Express Port on its secondary (downstream) side.
That PCIe Port is a Downstream Port and could be connected to a slot, just like a Root Port or a Switch Downstream Port. Make pcie_downstream_port() return true for them, so we can access the Slot registers in the PCIe capability.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
0b131b13 |
| 27-Mar-2017 |
Brian Norris <briannorris@chromium.org> |
PCI: Fix typo pci_cfg_access_lock() comment
There is no pci_cfg_access_unlocked(). I think the author meant pci_cfg_access_unlock().
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-of
PCI: Fix typo pci_cfg_access_lock() comment
There is no pci_cfg_access_unlocked(). I think the author meant pci_cfg_access_unlock().
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
#
4b103883 |
| 29-Mar-2017 |
Keith Busch <keith.busch@intel.com> |
PCI: Don't attempt config access to disconnected devices
If we've detected the PCI device is disconnected, there is no need to attempt to access its config space since we know the operation will fa
PCI: Don't attempt config access to disconnected devices
If we've detected the PCI device is disconnected, there is no need to attempt to access its config space since we know the operation will fail. Make all the config reads and writes return -ENODEV error immediately when in such a state.
If a caller requests a config read to a disconnected device, return a data value of all 1's. This is the same as what hardware is expected to return when accessing a removed device, but software can do this faster without relying on hardware.
Tested-by: Krishna Dhulipala <krishnad@fb.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Wei Zhang <wzhang@fb.com>
show more ...
|
Revision tags: v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
d3881e50 |
| 07-Feb-2017 |
Keith Busch <keith.busch@intel.com> |
PCI: Export PCI device config accessors
Replace the inline PCI device config read and write accessors with exported functions. This is preparing for these functions to make use of private data.
Te
PCI: Export PCI device config accessors
Replace the inline PCI device config read and write accessors with exported functions. This is preparing for these functions to make use of private data.
Tested-by: Krishna Dhulipala <krishnad@fb.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Wei Zhang <wzhang@fb.com>
show more ...
|
#
174cd4b1 |
| 02-Feb-2017 |
Ingo Molnar <mingo@kernel.org> |
sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
Fix up affected files that include this signal functionality via sched.h.
Acked-by
sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
Fix up affected files that include this signal functionality via sched.h.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|