- 11 9月, 2018 2 次提交
-
-
由 Gustavo A. R. Silva 提交于
p.port can is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/pci/switch/switchtec.c:912 ioctl_port_to_pff() warn: potential spectre issue 'pcfg->dsp_pff_inst_id' [r] Fix this by sanitizing p.port before using it to index pcfg->dsp_pff_inst_id Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLogan Gunthorpe <logang@deltatee.com> Cc: stable@vger.kernel.org
-
由 Mika Westerberg 提交于
This reverts f154a718 ("PCI: Add ACS quirk for Intel 300 series"). It turns out that erratum "PCH PCIe* Controller Root Port (ACSCTLR) Appear As Read Only" has been fixed in 300 series chipsets, even though the datasheet [1] claims otherwise. To make ACS work properly on 300 series root ports, revert the faulty commit. [1] https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/300-series-c240-series-chipset-pch-spec-update.pdf Fixes: f154a718 ("PCI: Add ACS quirk for Intel 300 series") Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v4.18+
-
- 23 8月, 2018 1 次提交
-
-
由 Ard Biesheuvel 提交于
Allow the PCI quirk tables to be emitted in a way that avoids absolute references to the hook functions. This reduces the size of the entries, and, more importantly, makes them invariant under runtime relocation (e.g., for KASLR) Link: http://lkml.kernel.org/r/20180704083651.24360-6-ard.biesheuvel@linaro.orgAcked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NMichael Ellerman <mpe@ellerman.id.au> Acked-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morris <james.morris@microsoft.com> Cc: James Morris <jmorris@namei.org> Cc: Jessica Yu <jeyu@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nicolas Pitre <nico@linaro.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Garnier <thgarnie@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 8月, 2018 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 26112ddc (PCI / ACPI / PM: Resume bridges w/o drivers on suspend-to-RAM) attempted to fix a functional regression resulting from commit c62ec461 (PM / core: Fix direct_complete handling for devices with no callbacks) by resuming PCI bridges without drivers (that is, "parallel PCI" ones) during system-wide suspend if the target system state is not ACPI S0 (working state). That turns out insufficient, however, as it is reported that, at least in one case, the platform firmware gets confused if a PCIe root port is suspended before entering the ACPI S3 sleep state. That issue was exposed by commit 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed PCIe ports to stay in runtime suspend during system-wide suspend (which is OK for suspend-to-idle, but turns out to be problematic otherwise). For this reason, drop the driver check from acpi_pci_need_resume() and resume all bridges (including PCIe ports with drivers) during system-wide suspend if the target system state is not ACPI S0. [If the target system state is ACPI S0, it means suspend-to-idle and the platform firmware is not going to be invoked to actually suspend the system, so there is no need to resume the bridges in that case.] Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675Reported-by: Nteika kazura <teika@gmx.com> Tested-by: Nteika kazura <teika@gmx.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc (PCI / ACPI / PM: Resume bridges ...) Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 8月, 2018 1 次提交
-
-
由 Alexandru Gagniuc 提交于
If the platform requests Firmware-First error handling, firmware is responsible for reading and clearing AER status bits. If OSPM also clears them, we may miss errors. See ACPI v6.2, sec 18.3.2.5 and 18.4. This race is mostly of theoretical significance, as it is not easy to reasonably demonstrate it in testing. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> [bhelgaas: add similar guards to pci_cleanup_aer_uncorrect_error_status() and pci_aer_clear_fatal_status()] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 15 8月, 2018 3 次提交
-
-
由 Jakub Kicinski 提交于
Like the NFP4000 and NFP6000, the NFP5000 as an erratum where reading/ writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP5000's PF's config space size to 0x600 bytes as is already done for the NFP4000 and NFP6000. The NFP5000's VF is 0x6003 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NTony Egan <tony.egan@netronome.com>
-
由 Heiner Kallweit 提交于
If flag IRQCHIP_ONESHOT_SAFE isn't set for an irqchip and we have a threaded interrupt with no primary handler, flag IRQF_ONESHOT needs to be set for the interrupt, causing some overhead in the threaded interrupt handler. For more detailed explanation also check following comment in __setup_irq(): The interrupt was requested with handler = NULL, so we use the default primary handler for it. But it does not have the oneshot flag set. In combination with level interrupts this is deadly, because the default primary handler just wakes the thread, then the irq lines is reenabled, but the device still has the level irq asserted. Rinse and repeat.... While this works for edge type interrupts, we play it safe and reject unconditionally because we can't say for sure which type this interrupt really has. The type flags are unreliable as the underlying chip implementation can override them. Another comment in __setup_irq() gives a hint already that this overhead can be avoided for PCI-MSI: Some irq chips like MSI based interrupts are per se one shot safe. Check the chip flags, so we can avoid the unmask dance at the end of the threaded handler for those. Following this let's mark all PCI-MSI irqchips as oneshot-safe. See also discussion here: https://lkml.kernel.org/r/alpine.DEB.2.21.1808032136490.1658@nanos.tec.linutronix.deSigned-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bert Kenward 提交于
Previously we checked the timeout before checking the VPD access completion bit. On a very heavily loaded system this can cause VPD access to timeout. Check the completion bit before checking the timeout. Signed-off-by: NBert Kenward <bkenward@solarflare.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 14 8月, 2018 3 次提交
-
-
由 Myron Stowe 提交于
In commit 27d868b5 ("PCI: Set MPS to match upstream bridge"), we made sure every device's MPS setting matches its upstream bridge, making it more likely that a hot-added device will work in a system with an optimized MPS configuration. Recently I've started encountering systems where the endpoint device's MPSS capability is less than its Root Port's current MPS value, thus the endpoint is not capable of matching its upstream bridge's MPS setting (see: bugzilla via "Link:" below). This leaves the system vulnerable - the upstream Root Port could respond with larger TLPs than the device can handle, and the device will consider them to be 'Malformed'. One could use the "pci=pcie_bus_safe" kernel parameter to work around the issue, but that forces a user to supply a kernel parameter to get the system to function reliably and may end up limiting MPS settings of other unrelated, sub-topologies which could benefit from maintaining their larger values. Augment Keith's approach to include tuning down a Root Port's MPS setting when its hot-added endpoint device is not capable of matching it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJon Mason <jdmason@kudzu.us> Cc: Keith Busch <keith.busch@intel.com> Cc: Sinan Kaya <okaya@kernel.org> Cc: Dongdong Liu <liudongdong3@huawei.com>
-
由 Myron Stowe 提交于
PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for VFs. Just prior to the table it states: "PF and VF functionality is defined in Section 7.5.3.4 except where noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting applies to the VF." All of which implies that with respect to Max_Payload_Size Supported (MPSS), MPS, and MRRS values, we should not be paying any attention to the VF's fields, but rather only to the PF's. Only looking at the PF's fields also logically makes sense as it's the sole physical interface to the PCIe bus. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527 Fixes: 27d868b5 ("PCI: Set MPS to match upstream bridge") Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # 4.3+ Cc: Keith Busch <keith.busch@intel.com> Cc: Sinan Kaya <okaya@kernel.org> Cc: Dongdong Liu <liudongdong3@huawei.com> Cc: Jon Mason <jdmason@kudzu.us>
-
由 Bjorn Helgaas 提交于
Add function 1 DMA alias quirk for Marvell 88SS9183 PCIe SSD Controller. Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c134Reported-and-tested-by: NFelix Blüthner <f.bluethner@mailbox.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 8月, 2018 1 次提交
-
-
由 Alexandru Gagniuc 提交于
When both ends of a PCIe Link are capable of a higher bandwidth than is currently in use, the Link is said to be "downtrained". A downtrained Link may indicate hardware or configuration problems in the system, but it's hard to identify such Links from userspace. Refactor pcie_print_link_status() so it continues to always print PCIe bandwidth information, as several NIC drivers desire. Add a new internal __pcie_print_link_status() to emit a message only when a device's bandwidth is constrained by the fabric and call it from the PCI core for all devices, which identifies all downtrained Links. It also emits messages for a few cases that are technically not downtrained, such as a x4 device in an open-ended x1 slot. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> [bhelgaas: changelog, move __pcie_print_link_status() declaration to drivers/pci/, rename pcie_check_upstream_link() to pcie_report_downtraining()] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 10 8月, 2018 10 次提交
-
-
由 Logan Gunthorpe 提交于
Intel Sunrise Point PCH hardware has an implementation of the ACS bits that does not comply with the PCIe standard. Add a device-specific quirk, pci_quirk_disable_intel_spt_pch_acs_redir() to disable ACS Redirection on this system. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: changelog, split to separate patch] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Logan Gunthorpe 提交于
Intel Sunrise Point (SPT) PCH hardware has an implementation of the ACS bits that does not comply with the PCIe standard. To deal with this we need device-specific quirks to disable ACS redirection. Add a new pci_dev_specific_disable_acs_redir() quirk and a new .disable_acs_redir() function pointer for use by non-compliant devices. No functional change intended. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: split to separate patch, move pci_dev_specific_disable_acs_redir() declarations to drivers/pci/pci.h] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Logan Gunthorpe 提交于
Convert the search for device-specific ACS enable quirks from searching a NULL-terminated array to iterating through the array, which is always fixed-size anyway. No functional change intended. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: changelog, split to separate patch for reviewability] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Logan Gunthorpe 提交于
To support peer-to-peer traffic on a segment of the PCI hierarchy, we must disable the ACS redirect bits for select PCI bridges. The bridges must be selected before the devices are discovered by the kernel and the IOMMU groups created. Therefore, add a kernel command line parameter to specify devices which must have their ACS bits disabled. The new parameter takes a list of devices separated by a semicolon. Each device specified will have its ACS redirect bits disabled. This is similar to the existing 'resource_alignment' parameter. The ACS Request P2P Request Redirect, P2P Completion Redirect and P2P Egress Control bits are disabled, which is sufficient to always allow passing P2P traffic uninterrupted. The bits are set after the kernel (optionally) enables the ACS bits itself. It is also done regardless of whether the kernel or platform firmware sets the bits. If the user tries to disable the ACS redirect for a device without the ACS capability, print a warning to dmesg. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: reorder to add the generic code first and move the device-specific quirk to subsequent patches] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NStephen Bates <sbates@raithlin.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NChristian König <christian.koenig@amd.com>
-
由 Logan Gunthorpe 提交于
When specifying PCI devices on the kernel command line using a bus/device/function address, bus numbers can change when adding or replacing a device, changing motherboard firmware, or applying kernel parameters like "pci=assign-buses". When bus numbers change, it's likely the command line tweak will be applied to the wrong device. Therefore, it is useful to be able to specify devices with a base bus number and the path of devfns needed to get to it, similar to the "device scope" structure in the Intel VT-d spec, Section 8.3.1. Thus, we add an option to specify devices in the following format: [<domain>:]<bus>:<device>.<func>[/<device>.<func>]* The path can be any segment within the PCI hierarchy of any length and determined through the use of 'lspci -t'. When specified this way, it is less likely that a renumbered bus will result in a valid device specification and the tweak won't be applied to the wrong device. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: use "device" instead of "slot" in documentation since that's the usual language in the PCI specs] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NStephen Bates <sbates@raithlin.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NChristian König <christian.koenig@amd.com>
-
由 Logan Gunthorpe 提交于
Separate out the code to match a PCI device with a string (typically originating from a kernel parameter) from the pci_specified_resource_alignment() function into its own helper function. While we are at it, this change fixes the kernel style of the function (fixing a number of long lines and extra parentheses). Additionally, make the analogous change to the kernel parameter documentation: Separate the description of how to specify a PCI device into its own section at the head of the "pci=" parameter. This patch should have no functional alterations. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> [bhelgaas: use "device" instead of "slot" in documentation since that's the usual language in the PCI specs] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NStephen Bates <sbates@raithlin.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NChristian König <christian.koenig@amd.com>
-
由 Bjorn Helgaas 提交于
Move declarations for these functions: pci_dev_specific_acs_enabled() pci_dev_specific_enable_acs() from include/linux/pci.h to drivers/pci/pci.h because nothing outside the PCI core needs to use them. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alex Williamson 提交于
Add a device-specific reset for Intel DC P3700 NVMe device which exhibits a timeout failure in drivers waiting for the ready status to update after NVMe enable if the driver interacts with the device too soon after FLR. As this has been observed in device assignment scenarios, resolve this with a device-specific reset quirk to add an additional, heuristically determined, delay after the FLR completes. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1592654Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alex Williamson 提交于
The Samsung SM961/PM961 (960 EVO) sometimes fails to return from FLR with the PCI config space reading back as -1. A reproducible instance of this behavior is resolved by clearing the enable bit in the NVMe configuration register and waiting for the ready status to clear (disabling the NVMe controller) prior to FLR. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1542494Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alex Williamson 提交于
pcie_flr() suggests pcie_has_flr() to ensure that PCIe FLR support is present prior to calling. pcie_flr() is exported while pcie_has_flr() is not. Resolve this. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 8月, 2018 6 次提交
-
-
由 Thomas Petazzoni 提交于
This comment has been there since the driver was introduced, but seems to be a leftover from previous iterations of the driver. Indeed, we do not lookup in a list to find the register ranges that matches the given port/lane, as the "reg" property is in each sub-node representing a PCI port. There is no lookup involved at all. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Thomas Petazzoni 提交于
Rather than using the ARM-specific pci_common_init_dev() API, use the pci_host_bridge logic directly. Unfortunately, we can't use devm_of_pci_get_host_bridge_resources(), because the DT binding for describing PCIe apertures for this PCI controller is a bit special, and we cannot retrieve them from the 'ranges' property. Therefore, we still have some special code to handle this. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Thomas Petazzoni 提交于
Instead of hardcoding the remapping of IO_SPACE_LIMIT - SZ_64K, use resource_size(). However, we cannot use just IO_SPACE_LIMIT, because pci_ioremap_io() has a bug and doesn't allow remapping the last 64 KB before IO_SPACE_LIMIT, so we ensure that we do not exceed this limit. When the pci_ioremap_io() issue is fixed, this work around can be dropped. Note that this workaround already existed, since we were mapping only up to IO_SPACE_LIMIT - SZ_64K. Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> [lorenzo.pieralisi@arm.com: tweaked the commit log] Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Thomas Petazzoni 提交于
If there is no PCI I/O aperture configured in the Device Tree, it does not make sense to create the virtual mapping for the PCI I/O space, since we will anyway not create the MBus window that will allow to access it. Therefore, do the pci_ioremap_io() only if necessary. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Thomas Petazzoni 提交于
pcie->realio.end should be the address of last byte of the area, therefore using resource_size() of another resource is not correct, we must substract 1 to get the address of the last byte. Fixes: 11be6547 ("PCI: mvebu: Adapt to the new device tree layout") Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Thomas Petazzoni 提交于
This is already done earlier in mvebu_pcie_probe(). Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 07 8月, 2018 2 次提交
-
-
由 Bjorn Helgaas 提交于
Several PCI core files include pci-aspm.h even though they don't need anything provided by that file. Remove the unnecessary includes of it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NSinan Kaya <okaya@kernel.org>
-
由 Andy Shevchenko 提交于
The sysfs_match_string() helper returns index of the matching string in an array. Use it in pcie_aspm_set_policy() to simplify the code. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> [bhelgaas: squash sysfs_match_string() fix into original patch for issue Reported-by: Heiner Kallweit <hkallweit1@gmail.com>] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 06 8月, 2018 1 次提交
-
-
由 Christoph Hellwig 提交于
There isn't a hard dependency of the Xilinx AXI-PCIe host bridge on any architecture. For example: at SiFive we map RISC-V cores to Xilinx FPGAs and connect the Xilinx IP via a TileLink adapter, so the RISC-V Linux port will need to be able to enable PCIE_XILINX in order to have PCIe support. This patch decouples the PCIE_XILINX support from ARCH. Instead it just depends on OF, which is the only true dependency. Signed-off-by: NPalmer Dabbelt <palmer@dabbelt.com> [hch: switch to OF instead of OF_PCI now that the latter is gone] Signed-off-by: NChristoph Hellwig <hch@lst.de> [lorenzo.pieralisi@arm.com: trimmed the commit log] Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 05 8月, 2018 1 次提交
-
-
由 Nicolai Stange 提交于
The next patch in this series will have to make the definition of irq_cpustat_t available to entering_irq(). Inclusion of asm/hardirq.h into asm/apic.h would cause circular header dependencies like asm/smp.h asm/apic.h asm/hardirq.h linux/irq.h linux/topology.h linux/smp.h asm/smp.h or linux/gfp.h linux/mmzone.h asm/mmzone.h asm/mmzone_64.h asm/smp.h asm/apic.h asm/hardirq.h linux/irq.h linux/irqdesc.h linux/kobject.h linux/sysfs.h linux/kernfs.h linux/idr.h linux/gfp.h and others. This causes compilation errors because of the header guards becoming effective in the second inclusion: symbols/macros that had been defined before wouldn't be available to intermediate headers in the #include chain anymore. A possible workaround would be to move the definition of irq_cpustat_t into its own header and include that from both, asm/hardirq.h and asm/apic.h. However, this wouldn't solve the real problem, namely asm/harirq.h unnecessarily pulling in all the linux/irq.h cruft: nothing in asm/hardirq.h itself requires it. Also, note that there are some other archs, like e.g. arm64, which don't have that #include in their asm/hardirq.h. Remove the linux/irq.h #include from x86' asm/hardirq.h. Fix resulting compilation errors by adding appropriate #includes to *.c files as needed. Note that some of these *.c files could be cleaned up a bit wrt. to their set of #includes, but that should better be done from separate patches, if at all. Signed-off-by: NNicolai Stange <nstange@suse.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 01 8月, 2018 8 次提交
-
-
由 Bjorn Helgaas 提交于
PCI_EXP_AER_FLAGS was defined twice (with identical definitions), once under #ifdef CONFIG_ACPI_APEI, and again at the top level. This looks like my merge error from these commits: fd3362cb ("PCI/AER: Squash aerdrv_core.c into aerdrv.c") 41cbc9eb ("PCI/AER: Squash ecrc.c into aerdrv.c") Remove the duplicate PCI_EXP_AER_FLAGS definition. Fixes: 41cbc9eb ("PCI/AER: Squash ecrc.c into aerdrv.c") Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NOza Pawandeep <poza@codeaurora.org>
-
由 Lukas Wunner 提交于
On driver probe and on resume from system sleep, pciehp checks the Presence Detect State bit in the Slot Status register to bring up an occupied slot or bring down an unoccupied slot. Both code paths are identical, so deduplicate them per Mika's request. On probe, an additional check is performed to disable power of an unoccupied slot. This can e.g. happen if power was enabled by BIOS. It cannot happen once pciehp has taken control, hence is not necessary on resume: The Slot Control register is set to the same value that it had on suspend by pci_restore_state(), so if the slot was occupied, power is enabled and if it wasn't, power is disabled. Should occupancy have changed during the system sleep transition, power is adjusted by bringing up or down the slot per the paragraph above. To allow for deduplication of the presence check, move the power check to pcie_init(). This seems safer anyway, because right now it is performed while interrupts are already enabled, and although I can't think of a scenario where pciehp_power_off_slot() and the IRQ thread collide, it does feel brittle. However this means that pcie_init() may now write to the Slot Control register before the IRQ is requested. If both the CCIE and HPIE bits happen to be set, pcie_wait_cmd() will wait for an interrupt (instead of polling the Command Completed bit) and eventually emit a timeout message. Additionally, if a level-triggered INTx interrupt is used, the user may see a spurious interrupt splat. Avoid by disabling interrupts before disabling power. (Normally the HPIE and CCIE bits should be clear on probe, but conceivably they may already have been set e.g. by BIOS.) Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Lukas Wunner 提交于
Per Mika's request, add an explicit break to the last case of switch statements everywhere in pciehp to be more defensive towards future amendments. Per Gustavo's request, mark all non-empty implicit fallthroughs with a comment to silence warnings triggered by -Wimplicit-fallthrough=2. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
-
由 Hari Vyas 提交于
When a PCI device is detected, pdev->is_added is set to 1 and proc and sysfs entries are created. When the device is removed, pdev->is_added is checked for one and then device is detached with clearing of proc and sys entries and at end, pdev->is_added is set to 0. is_added and is_busmaster are bit fields in pci_dev structure sharing same memory location. A strange issue was observed with multiple removal and rescan of a PCIe NVMe device using sysfs commands where is_added flag was observed as zero instead of one while removing device and proc,sys entries are not cleared. This causes issue in later device addition with warning message "proc_dir_entry" already registered. Debugging revealed a race condition between the PCI core setting the is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue setting the is_busmaster bit in pci_set_master(). As these fields are not handled atomically, that clears the is_added bit. Move the is_added bit to a separate private flag variable and use atomic functions to set and retrieve the device addition state. This avoids the race because is_added no longer shares a memory location with is_busmaster. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283Signed-off-by: NHari Vyas <hari.vyas@broadcom.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NLukas Wunner <lukas@wunner.de> Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Lukas Wunner 提交于
Thunderbolt controllers can be runtime suspended to D3cold to save ~1.5W. This requires that runtime D3 is allowed on its PCIe ports, so whitelist them. The 2015 BIOS cutoff that we've instituted for runtime D3 on PCIe ports is unnecessary on Thunderbolt because we know that even the oldest controller, Light Ridge (2010), is able to suspend its ports to D3 just fine -- specifically including its hotplug ports. And the power saving should be afforded to machines even if their BIOS predates 2015. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Andreas Noever <andreas.noever@gmail.com>
-
由 Lukas Wunner 提交于
Previously we blacklisted PCIe hotplug ports for runtime D3 because: (a) Ports handled by the firmware must not be transitioned to D3 by the OS behind the firmware's back: https://bugzilla.kernel.org/show_bug.cgi?id=53811 (b) Ports handled natively by the OS lacked runtime D3 support in the pciehp driver. We've just rectified the latter, so allow users to manually enable and test it by passing pcie_port_pm=force on the command line. Vendors are thus put in a position to validate hotplug ports for runtime D3 and perhaps we can someday enable it by default, but with a BIOS cutoff date. Ashok Raj tested runtime D3 on hotplug ports of a SkyLake Xeon-SP in 2017 and encountered Hardware Error NMIs, so this feature clearly cannot be enabled for everyone yet: https://lkml.kernel.org/r/20170503180426.GA4058@otc-nc-03 While at it, remove an erroneous code comment I added with 97a90aee ("PCI: Consolidate conditions to allow runtime PM on PCIe ports") which claims that parents of a hotplug port must stay awake lest interrupts cannot be delivered. That has turned out to be wrong at least for Thunderbolt hotplug ports. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Yinghai Lu <yinghai@kernel.org>
-
由 Lukas Wunner 提交于
When performing a function reset via sysfs, the device's config space is accessed in places such as pcie_flr() and its MMIO space is accessed e.g. in reset_ivb_igd(), so ensure accessibility by resuming the device to D0. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Yinghai Lu <yinghai@kernel.org>
-
由 Lukas Wunner 提交于
Ensure accessibility of a hotplug port's config space when accessed via sysfs by resuming its parent to D0. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Yinghai Lu <yinghai@kernel.org>
-