- 02 6月, 2018 3 次提交
-
-
由 Mika Westerberg 提交于
The SHPC driver now must be builtin (it cannot be a module). If it is present, request SHPC control immediately when adding the ACPI host bridge. This is similar to how we handle native PCIe hotplug via pciehp. Suggested-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Previously pciehp_is_native() returned true for any PCI device in a hierarchy where _OSC says we can use pciehp. This is incorrect because bridges without PCI_EXP_SLTCAP_HPC capability should be managed by acpiphp instead. Improve pciehp_is_native() to return true only when PCI_EXP_SLTCAP_HPC is set and the pciehp driver is present. In any other case return false to let acpiphp handle those. Suggested-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: remove NULL pointer check] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Rename host->native_hotplug to host->native_pcie_hotplug to make room for a similar flag for SHPC hotplug. Suggested-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> [bhelgaas: split to separate patch] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 26 5月, 2018 1 次提交
-
-
由 Bjorn Helgaas 提交于
In some cases pcie_get_minimum_link() returned misleading information because it found the slowest link and the narrowest link without considering the total bandwidth of the link. For example, consider a path with these two links: - 16.0 GT/s x1 link (16.0 * 10^9 * 128 / 130) * 1 / 8 = 1969 MB/s - 2.5 GT/s x16 link ( 2.5 * 10^9 * 8 / 10) * 16 / 8 = 4000 MB/s The available bandwidth of the path is limited by the 16 GT/s link to about 1969 MB/s, but pcie_get_minimum_link() returned 2.5 GT/s x1, which corresponds to only 250 MB/s. Callers should use pcie_print_link_status() instead, or pcie_bandwidth_available() if they need more detailed information. Remove pcie_get_minimum_link() since there are no callers left. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 5月, 2018 1 次提交
-
-
由 Oza Pawandeep 提交于
Move the error reporting callbacks from aerdrv_core.c to err.c, where they can be used by DPC in addition to AER. As part of aerdrv_core.c, these callbacks were built under CONFIG_PCIEAER. Moving them to the new err.c means they will now be built under CONFIG_PCIEPORTBUS, so adjust the definition of pci_uevent_ers() to match. Signed-off-by: NOza Pawandeep <poza@codeaurora.org> [bhelgaas: in reset_link(), initialize "driver" even if CONFIG_PCIEAER is unset, update pci_uevent_ers() #ifdef wrapper] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 16 5月, 2018 1 次提交
-
-
由 Jan Kiszka 提交于
The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr(). Since they are defined in the same file, pci_get_new_domain_nr() can be made static, which also simplifies preprocessor conditionals. No functional change intended. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 11 5月, 2018 1 次提交
-
-
由 Gil Kupfer 提交于
Adds a "pci=noats" boot parameter. When supplied, all ATS related functions fail immediately and the IOMMU is configured to not use device-IOTLB. Any function that checks for ATS capabilities directly against the devices should also check this flag. Currently, such functions exist only in IOMMU drivers, and they are covered by this patch. The motivation behind this patch is the existence of malicious devices. Lots of research has been done about how to use the IOMMU as protection from such devices. When ATS is supported, any I/O device can access any physical address by faking device-IOTLB entries. Adding the ability to ignore these entries lets sysadmins enhance system security. Signed-off-by: NGil Kupfer <gilkup@cs.technion.ac.il> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJoerg Roedel <jroedel@suse.de>
-
- 09 5月, 2018 1 次提交
-
-
由 Christoph Hellwig 提交于
This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so remove it. Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 5月, 2018 2 次提交
-
-
由 Gilles Buloz 提交于
Even if a device supports extended config space, i.e., it is a PCI-X Mode 2 or a PCI Express device, the extended space may not be accessible if there's a conventional PCI bus in the path to it. We currently figure that out in pci_cfg_space_size() by reading the first dword of extended config space. On most platforms that returns ~0 data if the space is inaccessible, but it may set error bits in PCI status registers, and on some platforms it causes exceptions that we currently don't recover from. For example, a PCIe-to-conventional PCI bridge treats config transactions with a non-zero Extended Register Address as an Unsupported Request on PCIe and a received Master-Abort on the destination bus (see PCI Express to PCI/PCI-X Bridge spec, r1.0, sec 4.1.3). A sample case is a LS1043A CPU (NXP QorIQ Layerscape) platform with the following bus topology: LS1043 PCIe Root Port -> PEX8112 PCIe-to-PCI bridge (doesn't support ext cfg on PCI side) -> PMC slot connector (for legacy PMC modules) With a PMC module topology as follows: PMC connector -> PCI-to-PCIe bridge -> PCIe switch (4 ports) -> 4 PCIe devices (one on each port) The PCIe devices on the PMC module support extended config space, but we can't reach it because the PEX8112 can't generate accesses to the extended space on its secondary bus. Attempts to access it cause Unsupported Request errors, which result in synchronous aborts on this platform. To avoid these errors, check whether bridges are capable of generating extended config space addresses on their secondary interfaces. If they can't, we restrict devices below the bridge to only the 256-byte PCI-compatible config space. Signed-off-by: NGilles Buloz <gilles.buloz@kontron.com> [bhelgaas: changelog, rework patch so bus_flags testing is all in pci_bridge_child_ext_cfg_accessible()] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Several PCIe hotplug controllers have errata that mean they do not set the Command Completed bit unless writes to the Slot Command register change "Control" bits. Command Completed is never set for writes that only change software notification "Enable" bits. This results in timeouts like this: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago) When this erratum is present, avoid these timeouts by marking commands "completed" immediately unless they change the "Control" bits. Here's the text of the Intel erratum CF118. We assume this applies to all Intel parts: CF118 PCIe Slot Status Register Command Completed bit not always updated on any configuration write to the Slot Control Register Problem: For PCIe root ports (devices 0 - 10) supporting hot-plug, the Slot Status Register (offset AAh) Command Completed (bit[4]) status is updated under the following condition: IOH will set Command Completed bit after delivering the new commands written in the Slot Controller register (offset A8h) to VPP. The IOH detects new commands written in Slot Control register by checking the change of value for Power Controller Control (bit[10]), Power Indicator Control (bits[9:8]), Attention Indicator Control (bits[7:6]), or Electromechanical Interlock Control (bit[11]) fields. Any other configuration writes to the Slot Control register without changing the values of these fields will not cause Command Completed bit to be set. The PCIe Base Specification Revision 2.0 or later describes the “Slot Control Register” in section 7.8.10, as follows (Reference section 7.8.10, Slot Control Register, Offset 18h). In hot-plug capable Downstream Ports, a write to the Slot Control register must cause a hot-plug command to be generated (see Section 6.7.3.2 for details on hot-plug commands). A write to the Slot Control register in a Downstream Port that is not hotplug capable must not cause a hot-plug command to be executed. The PCIe Spec intended that every write to the Slot Control Register is a command and expected a command complete status to abstract the VPP implementation specific nuances from the OS software. IOH PCIe Slot Control Register implementation is not fully conforming to the PCIe Specification in this respect. Implication: Software checking on the Command Completed status after writing to the Slot Control register may time out. Workaround: Software can read the Slot Control register and compare the existing and new values to determine if it should check the Command Completed status after writing to the Slot Control register. Per Sinan, the Qualcomm QDF2400 controller also does not set the Command Completed bit unless writes to the Slot Command register change "Control" bits. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Link: https://lkml.kernel.org/r/8770820b-85a0-172b-7230-3a44524e6c9f@molgen.mpg.de Reported-by: Paul Menzel <pmenzel+linux-pci@molgen.mpg.de> # Lenovo X60 Tested-by: Paul Menzel <pmenzel+linux-pci@molgen.mpg.de> # Lenovo X60 Signed-off-by: Sinan Kaya <okaya@codeaurora.org> # Qcom quirk Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
- 25 4月, 2018 1 次提交
-
-
由 Alexander Duyck 提交于
SR-IOV (Single Root I/O Virtualization) is an optional PCIe capability (see PCIe r4.0, sec 9). A PCIe Function with the SR-IOV capability is referred to as a PF (Physical Function). If SR-IOV is enabled on the PF, several VFs (Virtual Functions) may be created. The VFs can be individually assigned to virtual machines, which allows them to share a single hardware device while being isolated from each other. Some SR-IOV devices have resources such as queues and interrupts that must be set up in the PF before enabling the VFs, so they require a PF driver to do that. Other SR-IOV devices don't require any PF setup before enabling VFs. Add a pci_sriov_configure_simple() interface so PF drivers for such devices can use it without repeating the VF-enabling code. Tested-by: NMark Rustad <mark.d.rustad@intel.com> Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> [bhelgaas: changelog, comment] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NGreg Rose <gvrose8192@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de>:wq
-
- 23 4月, 2018 1 次提交
-
-
由 Bjorn Helgaas 提交于
Per the PCI Firmware spec r3.2, sec 4.5, an ACPI-based OS should use _OSC to request control of Latency Tolerance Reporting (LTR) before using it. Request control of LTR, and if the platform does not grant control, don't use it. N.B. If the hardware supports LTR and the ASPM L1.2 substate but the BIOS doesn't support LTR in _OSC, we previously would enable ASPM L1.2. This patch will prevent us from enabling ASPM L1.2 in that case. It does not prevent us from enabling PCI-PM L1.2, since that doesn't depend on LTR. See PCIe r40, sec 5.5.1, for the L1 PM substate entry conditions. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 4月, 2018 1 次提交
-
-
由 Gabriele Paoloni 提交于
In preparation for having the PCI MMIO helpers use the new generic I/O space management (logical PIO) we need to add the fwnode handler as an extra input parameter. Changes the signature of pci_register_io_range() and its callers as needed. Tested-by: Ndann frazier <dann.frazier@canonical.com> Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Acked-by: NRob Herring <robh@kernel.org>
-
- 03 4月, 2018 2 次提交
-
-
由 Tal Gilboa 提交于
Add pcie_print_link_status(). This logs the current settings of the link (speed, width, and total available bandwidth). If the device is capable of more bandwidth but is limited by a slower upstream link, we include information about the link that limits the device's performance. The user may be able to move the device to a different slot for better performance. This provides a unified method for all PCI devices to report status and issues, instead of each device reporting in a different way, using different code. Signed-off-by: NTal Gilboa <talgi@mellanox.com> [bhelgaas: changelog, reword log messages, print device capabilities when not limited, print bandwidth in Gb/s] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Tal Gilboa 提交于
Add pcie_bandwidth_available() to compute the bandwidth available to a device. This may be limited by the device itself or by a slower upstream link leading to the device. The available bandwidth at each link along the path is computed as: link_width * link_speed * (1 - encoding_overhead) 2.5 and 5.0 GT/s links use 8b/10b encoding, which reduces the raw bandwidth available by 20%; 8.0 GT/s and faster links use 128b/130b encoding, which reduces it by about 1.5%. The result is in Mb/s, i.e., megabits/second, of raw bandwidth. Also return the device with the slowest link and the speed and width of that link. Signed-off-by: NTal Gilboa <talgi@mellanox.com> [bhelgaas: changelog, leave pcie_get_minimum_link() alone for now, return bw directly, use pci_upstream_bridge(), check "next_bw <= bw" to find uppermost limiting device, return speed/width of the limiting device] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 01 4月, 2018 1 次提交
-
-
由 Mathieu Malaterre 提交于
Add missing prototypes for: resource_size_t pcibios_default_alignment(void); int pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs); int pcibios_sriov_disable(struct pci_dev *pdev); This fixes the following warnings treated as errors when using W=1: arch/powerpc/kernel/pci-common.c:236:17: error: no previous prototype for ‘pcibios_default_alignment’ [-Werror=missing-prototypes] arch/powerpc/kernel/pci-common.c:253:5: error: no previous prototype for ‘pcibios_sriov_enable’ [-Werror=missing-prototypes] arch/powerpc/kernel/pci-common.c:261:5: error: no previous prototype for ‘pcibios_sriov_disable’ [-Werror=missing-prototypes] Also, commit 978d2d68 ("PCI: Add pcibios_iov_resource_alignment() interface") added a new function but the prototype was located in the main header instead of the CONFIG_PCI_IOV specific section. Move this function next to the newly added ones. Signed-off-by: NMathieu Malaterre <malat@debian.org> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
-
- 31 3月, 2018 3 次提交
-
-
由 Bjørn Mork 提交于
Simply move these inline functions outside the ifdef instead of duplicating them as stubs in the !OF case. The struct device of_node field does not depend on OF. This also fixes the missing stubbed pci_bus_to_OF_node(). Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
-
由 Bjorn Helgaas 提交于
"pcie_ports_auto" is only used inside the PCIe port driver itself, so move it from include/linux/pci.h to portdrv.h so it's not visible to the whole kernel. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the platform firmware or the OS, so the host bridge driver may have to request permission from the platform before using them. On ACPI systems, this is done by negotiate_os_control() in acpi_pci_root_add(). The PCIe port driver later uses pcie_port_platform_notify() and pcie_port_acpi_setup() to figure out whether it can use these features. But all we need is a single bit for each service, so these interfaces are needlessly complicated. Simplify this by adding bits in the struct pci_host_bridge to show when the OS has permission to use each feature: + unsigned int native_aer:1; /* OS may use PCIe AER */ + unsigned int native_hotplug:1; /* OS may use PCIe hotplug */ + unsigned int native_pme:1; /* OS may use PCIe PME */ These are set when we create a host bridge, and the host bridge driver can clear the bits corresponding to any feature the platform doesn't want us to use. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 3月, 2018 1 次提交
-
-
由 Jay Fang 提交于
PCIe 4.0 defines the 16.0 GT/s link speed. Links can run at that speed without any Linux changes, but previously their sysfs "max_link_speed" and "current_link_speed" files contained "Unknown speed", not the expected "16.0 GT/s". Add decoding for the new 16 GT/s link speed. Signed-off-by: NJay Fang <f.fangjian@huawei.com> [bhelgaas: add PCI_EXP_LNKCAP2_SLS_16_0GB] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NDongdong Liu <liudongdong3@huawei.com>
-
- 14 3月, 2018 1 次提交
-
-
由 Lukas Wunner 提交于
There are PCI devices which are power-manageable by a nonstandard means, such as a custom ACPI method. One example are discrete GPUs in hybrid graphics laptops, another are Thunderbolt controllers in Macs. Such devices can't be put into D3cold with pci_set_power_state() because pci_platform_power_transition() fails with -ENODEV. Instead they're put into D3hot by pci_set_power_state() and subsequently into D3cold by invoking the nonstandard means. However as a consequence the cached current_state is incorrectly left at D3hot. What we need to do is walk the hierarchy below such a PCI device on powerdown and update the current_state to D3cold. On powerup the PCI device itself and the hierarchy below it is in D0uninitialized, so we need to walk the hierarchy again and wake all devices, causing them to be put into D0active and then letting them autosuspend as they see fit. To this end make pci_wakeup_bus() & pci_bus_set_current_state() public so PCI drivers don't have to reinvent the wheel. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Link: https://patchwork.freedesktop.org/patch/msgid/2962443259e7faec577274b4ef8c54aad66f9a94.1520068884.git.lukas@wunner.de
-
- 05 3月, 2018 1 次提交
-
-
由 Sinan Kaya 提交于
Add a return value to pci_reset_bridge_secondary_bus() so we can return an error if the device doesn't become ready after the reset. Signed-off-by: NSinan Kaya <okaya@codeaurora.org> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
- 28 2月, 2018 1 次提交
-
-
由 Sinan Kaya 提交于
pci_flr_wait() and pci_af_flr() functions assume graceful return even though the device is inaccessible under error conditions. Return -ENOTTY in error cases so that __pci_reset_function_locked() can try other reset types if AF_FLR/FLR reset fails. Signed-off-by: NSinan Kaya <okaya@codeaurora.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
- 23 2月, 2018 1 次提交
-
-
由 Michael Ellerman 提交于
There's no reason pci_uevent_ers() needs to be inline in pci.h, so move it out to a C file. Given it's used by AER the obvious location would be somewhere in drivers/pci/pcie/aer, but because it's also used by powerpc EEH code unfortunately that doesn't work in the case where EEH is enabled but PCIEPORTBUS is not. So for now put it in pci-driver.c, next to pci_uevent(), with an appropriate #ifdef so it's not built if AER and EEH are both disabled. While we're moving it also fix up the kernel doc comment for @pdev to be accurate. Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org> Reviewed-by: NBryant G. Ly <bryantly@linux.vnet.ibm.com>
-
- 16 2月, 2018 1 次提交
-
-
由 Sinan Kaya 提交于
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Now that all users of pci_get_bus_and_slot() switched to pci_get_domain_bus_and_slot(), it is now safe to remove this function. Signed-off-by: NSinan Kaya <okaya@codeaurora.org> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
-
- 31 1月, 2018 2 次提交
-
-
由 Cyrille Pitchen 提交于
This patchs moves generic source code from drivers/pci/host/pci-host-common.c into drivers/pci/probe.c. Indeed the extracted lines of code were duplicated by many host controller drivers. Regrouping them into a generic function gives a change to properly share this code without introducing a useless dependency to PCI_HOST_COMMON, which selects PCI_ECAM when not needed by most host controller drivers. Signed-off-by: NCyrille Pitchen <cyrille.pitchen@free-electrons.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Cyrille Pitchen 提交于
The patch moves the gen_pci_parse_request_of_pci_ranges() function from drivers/pci/host/pci-host-common.c into drivers/pci/of.c to easily share common source code between PCI host drivers. Signed-off-by: NCyrille Pitchen <cyrille.pitchen@free-electrons.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 27 1月, 2018 1 次提交
-
-
由 Bryant G. Ly 提交于
Devices can go offline when erors reported. This patch adds a change to the kernel object and lets udev know of error. When device resumes, a change is also set reporting device as online. Therefore, EEH and AER events are better propagated to user space for PCI devices in all arches. Signed-off-by: NBryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by: NJuan J. Alvarez <jjalvare@linux.vnet.ibm.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRussell Currey <ruscur@russell.cc> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 24 1月, 2018 1 次提交
-
-
由 Jay Cornwall 提交于
The Atomic Operations feature (PCIe r4.0, sec 6.15) allows atomic transctions to be requested by, routed through and completed by PCIe components. Routing and completion do not require software support. Component support for each is detectable via the DEVCAP2 register. A Requester may use AtomicOps only if its PCI_EXP_DEVCTL2_ATOMIC_REQ is set. This should be set only if the Completer and all intermediate routing elements support AtomicOps. A concrete example is the AMD Fiji-class GPU (which is capable of making AtomicOp requests), below a PLX 8747 switch (advertising AtomicOp routing) with a Haswell host bridge (advertising AtomicOp completion support). Add pci_enable_atomic_ops_to_root() for per-device control over AtomicOp requests. This checks to be sure the Root Port supports completion of the desired AtomicOp sizes and the path to the Root Port supports routing the AtomicOps. Signed-off-by: NJay Cornwall <Jay.Cornwall@amd.com> Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com> [bhelgaas: changelog, comments, whitespace] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 20 1月, 2018 1 次提交
-
-
由 Niklas Cassel 提交于
Some hardware can operate in either "host" or "endpoint" mode, which means there can be both a host bridge driver and an endpoint driver for the same device. Those drivers share a lot of code, so sometimes they live in the same source file. The host bridge driver requires CONFIG_PCI=y because it enumerates PCI devices below the bridge using the PCI core. The endpoint driver does not require CONFIG_PCI=y because it runs in an embedded kernel on the other side of the device, e.g., on an adapter card. pci-dra7xx.c contains both host and endpoint drivers. If we select only the endpoint driver (CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y), the unneeded host driver is still compiled. It references pci_irqd_intx_xlate(), which is not present when CONFIG_PCI=n, which causes this error: drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared here (not in a function) Add a dummy pci_irqd_intx_xlate() for the CONFIG_PCI=n case. [bhelgaas: changelog] Signed-off-by: NNiklas Cassel <niklas.cassel@axis.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 19 1月, 2018 1 次提交
-
-
由 Frederick Lawler 提交于
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by: NFrederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 19 12月, 2017 2 次提交
-
-
由 Bjorn Helgaas 提交于
Clean up whitespace, capitalization, etc. in comments. No functional change intended. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Enable Latency Tolerance Reporting (LTR). Note that LTR must be enabled in the Root Port first, and must not be enabled in any downstream device unless the Root Port and all intermediate Switches also support LTR. See PCIe r3.1, sec 6.18. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NVidya Sagar <vidyas@nvidia.com>
-
- 14 12月, 2017 1 次提交
-
-
由 Heiner Kallweit 提交于
Add pcim_set_mwi(), a device-managed version of pci_set_mwi(). First user is the Realtek r8169 driver. Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 12月, 2017 1 次提交
-
-
由 Bryant G. Ly 提交于
Add a pci_vf_drivers_autoprobe() interface. Setting autoprobe to false on the PF prevents drivers from binding to VFs when they are enabled. Signed-off-by: NBryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by: NJuan J. Alvarez <jjalvare@linux.vnet.ibm.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRussell Currey <ruscur@russell.cc> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 07 12月, 2017 1 次提交
-
-
由 Randy Dunlap 提交于
The coretemp driver build fails when CONFIG_PCI is not enabled because it uses a function that does not have a stub for that config case, so add the function stub. ../drivers/hwmon/coretemp.c: In function 'adjust_tjmax': ../drivers/hwmon/coretemp.c:250:9: error: implicit declaration of function 'pci_get_domain_bus_and_slot' [-Werror=implicit-function-declaration] struct pci_dev *host_bridge = pci_get_domain_bus_and_slot(0, 0, devfn); ../drivers/hwmon/coretemp.c:250:32: warning: initialization makes pointer from integer without a cast [enabled by default] struct pci_dev *host_bridge = pci_get_domain_bus_and_slot(0, 0, devfn); Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> [bhelgaas: identical patch also by Arnd Bergmann <arnd@arndb.de>] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NGuenter Roeck <linux@roeck-us.net>
-
- 24 11月, 2017 1 次提交
-
-
由 Bjorn Helgaas 提交于
There are no in-tree callers of ht_create_irq(), the driver interface for HyperTransport interrupts, left. Remove the unused entry point and all the supporting code. See 8b955b0d ("[PATCH] Initial generic hypertransport interrupt support"). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-pci@vger.kernel.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Link: https://lkml.kernel.org/r/20171122221337.3877.23362.stgit@bhelgaas-glaptop.roam.corp.google.com
-
- 07 11月, 2017 1 次提交
-
-
由 Andy Shevchenko 提交于
The following pattern is often used: list_for_each_entry(dev, &bus->devices, bus_list) { if (pci_is_bridge(dev)) { ... } } Add a for_each_pci_bridge() helper to make that code easier to write and read by reducing indentation level. It also saves one or few lines of code in each occurrence. Convert PCI core parts here at the same time. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> [bhelgaas: fold in http://lkml.kernel.org/r/20171013165352.25550-1-andriy.shevchenko@linux.intel.com] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 06 11月, 2017 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Replace the PCI-specific flag PCI_DEV_FLAGS_NEEDS_RESUME with the PM core's DPM_FLAG_NEVER_SKIP one everywhere and drop it. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-