- 03 Oct, 2016 2 commits
-
-
Bjorn Helgaas authored
* pci/enumeration: PCI: tegra: Fix pci_remap_iospace() failure path PCI: generic: Fix pci_remap_iospace() failure path PCI: rcar: Fix pci_remap_iospace() failure path PCI: versatile: Fix pci_remap_iospace() failure path PCI: designware: Fix pci_remap_iospace() failure path PCI: aardvark: Fix pci_remap_iospace() failure path
-
Bjorn Helgaas authored
* pci/aer: PCI/AER: Fix aer_probe() kernel-doc comment PCI/AER: Cache capability position PCI/AER: Avoid memory allocation in interrupt handling path ACPI / APEI: Send correct severity to calculate AER severity PCI/AER: Remove duplicate AER severity translation PCI/AER: Remove aerdriver.forceload kernel parameter PCI/AER: Remove aerdriver.nosourceid kernel parameter x86/PCI: VMD: Add quirk for AER to ignore source ID PCI/AER: Add bus flag to skip source ID matching Conflicts: drivers/pci/probe.c
-
- 30 Sep, 2016 1 commit
-
-
Cao jin authored
0516c8bc ("PCI: PCIe portdrv: Simplily probe callback of service drivers") removed the "id" argument of aer_probe() but neglected to remove the kernel-doc comment. Update the comment. [bhelgaas: changelog] Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 27 Sep, 2016 2 commits
-
-
Keith Busch authored
Save the position of the error reporting capability so it doesn't need to be rediscovered during error handling. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Jon Derrick authored
When handling AER events, we previously allocated a struct aer_err_info, processed the error, and freed the struct. But aer_isr_one_error() is serialized by rpc_mutex, so we never need more than one copy of the struct, and the struct is only about 70 bytes, so we're not saving much by allocating it dynamically. Embed a struct aer_err_info directly in struct aer_rpc, which is allocated at probe-time by aer_probe(). [bhelgaas: changelog] Suggested-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
-
- 20 Sep, 2016 2 commits
-
-
Tyler Baicar authored
Currently the AER severity is calculated by calling cper_severity_to_aer(), but the parameter sent is actually the GHES severity. This causes the AER severity to be incorrect. Fix the parameter to be the CPER severity instead of the GHES severity. Signed-off-by:
Tyler Baicar <tbaicar@codeaurora.org> Signed-off-by:
Borislav Petkov <bp@suse.de>
-
Tyler Baicar authored
Currently the AER severity is being translated twice in the code flow for PCIe errors. It is first translated in ghes_do_proc() before calling into the AER driver. Then it is translated again when the AER driver calls cper_print_aer(). This causes the severity that is used in cper_print_aer() to be incorrect. Remove the second translation that is in cper_print_aer() since this function is already receiving the correct AER severity. Signed-off-by:
-
- 14 Sep, 2016 2 commits
-
-
Bjorn Helgaas authored
Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must not use AER unless _OSC is present and _OSC grants AER control to the OS. The aerdriver.forceload kernel parameter was a way to enable Linux AER support on ACPI systems that lack _OSC or fail to grant control the the OS. Enabling Linux AER support when the firmware doesn't want us to is a recipe for problems, e.g., the firmware might be handling AER itself. Remove the aerdriver.forceload kernel parameter and related supporting code. Signed-off-by: -
Bjorn Helgaas authored
The aerdriver.nosourceid kernel parameter was intended for working around broken chipsets don't supply the source ID for AER events. We recently added PCI_BUS_FLAGS_NO_AERSID, which can be set by quirks for the same purpose. Remove the aerdriver.nosourceid kernel parameter. For anything other than debugging, asking users to find and use kernel parameters is a poor user experience. Instead, we should add PCI_BUS_FLAGS_NO_AERSID quirks for any hardware that needs it. Signed-off-by:
-
- 06 Sep, 2016 8 commits
-
-
Jon Derrick authored
VMD root ports change all source ids to the VMD device ID. To find the sender of the AER notification, we need to scan all child devices for the AER sender, rather than relying on the source ID from the message. Signed-off-by:
-
Jon Derrick authored
Allow root port buses to choose to skip source id matching when finding the faulting device. Certain root port devices may return an incorrect source ID and recommend to scan child device registers for AER notifications. Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI tegra host bridge driver adds the PCI IO resource retrieved from firmware to the host bridge resource windows even if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Add the PCI host bridge driver pci_remap_iospace() failure path and do not add the corresponding PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, fixing the issue. Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one") Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI common host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers") Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI rcar host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI versatile host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver") Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI designware host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic") Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridge's memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI aardvark host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by:
-
- 01 Sep, 2016 2 commits
-
-
Bjorn Helgaas authored
* pci/ptm: PCI: Add PTM clock granularity information PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints PCI: Add Precision Time Measurement (PTM) support
-
Bjorn Helgaas authored
* pci/demodularize: PCI: pciehp: Make explicitly non-modular PCI: hotplug: Make core explicitly non-modular PCI: xilinx-nwl: Make explicitly non-modular PCI: xilinx: Make explicitly non-modular PCI: qcom: Make explicitly non-modular PCI: dra7xx: Make explicitly non-modular PCI/AER: Make explicitly non-modular PCI/PME: Make explicitly non-modular PCI: Make DPC explicitly non-modular PCI: generic: Make explicitly non-modular PCI: exynos: Make explicitly non-modular PCI: designware: Make explicitly non-modular PCI: spear: Make explicitly non-modular PCI: portdrv: Make explicitly non-modular PCI: imx6: Make explicitly non-modular PCI: altera: Make explicitly non-modular PCI: altera: Make MSI explicitly non-modular
-
- 25 Aug, 2016 1 commit
-
-
Bjorn Helgaas authored
The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective Granularity field: This provides information relating to the expected accuracy of the PTM clock, but does not otherwise affect the PTM mechanism. Set the Effective Granularity based on the PTM Root and any intervening PTM Time Sources. This does not set Effective Granularity for Root Complex Integrated Endpoints because I don't know how to figure out clock granularity for them. The spec says: ... system software must set [Effective Granularity] to the value reported in the Local Clock Granularity field by the associated PTM Time Source. but I don't know how to identify the associated PTM Time Source. Normally it's the upstream bridge, but an integrated endpoint has no upstream bridge. Signed-off-by:
-
- 24 Aug, 2016 10 commits
-
-
Paul Gortmaker authored
This code is not being built as a module by anyone: obj-$(CONFIG_HOTPLUG_PCI_PCIE) += pciehp.o pciehp-objs := pciehp_core.o \ drivers/pci/pcie/Kconfig:config HOTPLUG_PCI_PCIE drivers/pci/pcie/Kconfig: bool "PCI Express Hotplug driver" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, module_init() translates to device_initcall(). One could argue that we should use subsys_initcall() here, but for now we stick with runtime equivalence. We delete module.h but we keep the moduleparam.h include, since we are keeping the module_param() that the file has as-is for now. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: obj-$(CONFIG_HOTPLUG_PCI) += pci_hotplug.o [...] pci_hotplug-objs := pci_hotplug_core.o drivers/pci/hotplug/Kconfig:menuconfig HOTPLUG_PCI drivers/pci/hotplug/Kconfig: bool "Support for PCI Hotplug" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Remove orphaned exit function in cpci_hotplug_core.c. Note that for non-modular code, module_init() translates to device_initcall(). One could argue that we should use subsys_initcall() here, but for now we stick with runtime equivalence. We would delete module.h and just keep the moduleparam.h include (since the file does use module_param), but there is a try_module_get and module_put pairing that prevents us from doing that. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_XILINX_NWL drivers/pci/host/Kconfig: bool "NWL PCIe Core" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Explicitly disallow driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. Delete several functions only used by the remove function. Note that for non-modular code, builtin_platform_driver() uses the same init level priority as module_platform_driver(), so this doesn't change init ordering. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_XILINX drivers/pci/host/Kconfig: bool "Xilinx AXI PCIe host bridge support" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, builtin_platform_driver() uses the same init level priority as module_platform_driver(), so this doesn't change init ordering. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_QCOM drivers/pci/host/Kconfig: bool "Qualcomm PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and builtin_platform_driver() uses the same init level priority as module_platform_driver(), so this doesn't change init ordering. Explicitly disallow driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCI_DRA7XX drivers/pci/host/Kconfig: bool "TI DRA7xx PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and builtin_platform_driver_probe() uses the same init level priority as module_platform_driver_probe(), so this doesn't change init ordering. Explicitly disallow driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: obj-$(CONFIG_PCIEAER) += aerdriver.o aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o drivers/pci/pcie/aer/Kconfig:config PCIEAER drivers/pci/pcie/aer/Kconfig: bool "Root Port Advanced Error Reporting support" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, module_init() translates to device_initcall(). [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: config PCIE_PME def_bool y depends on PCIEPORTBUS && PM Remove traces of modularity so that when reading the driver there is no doubt it is builtin-only. Also delete the .remove function, since that doesn't seem to have a sensible use case. With "normal" endpoint drivers, we have in the past set the suppress_bind_attrs bit to make it clear that the use of ".remove" in a builtin driver was deleted, but here for PCI, it seems overkill to jump through the pcie_port_service_driver and into the struct device_driver in order to finally try and do something similar with the bind setting. Note that for non-modular code, module_init() translates to device_initcall(). Signed-off-by: -
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/pcie/Kconfig:config PCIE_DPC drivers/pci/pcie/Kconfig: bool "PCIe Downstream Port Containment support" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, module_init() translates to device_initcall(). [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCI_HOST_COMMON drivers/pci/host/Kconfig: bool Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Signed-off-by:
-
- 23 Aug, 2016 7 commits
-
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCI_EXYNOS drivers/pci/host/Kconfig: bool "Samsung Exynos PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op. [bhelgaas: changelog] Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> CC: Jingoo Han <jingoohan1@gmail.com> CC: Kukjin Kim <kgene@kernel.org>
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_DW drivers/pci/host/Kconfig: bool Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_SPEAR13XX drivers/pci/host/Kconfig: bool "STMicroelectronics SPEAr PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and module_init() translates to device_initcall(). [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: pcieportdrv-y := portdrv_core.o portdrv_pci.o portdrv_bus.o obj-$(CONFIG_PCIEPORTBUS) += pcieportdrv.o drivers/pci/pcie/Kconfig:config PCIEPORTBUS drivers/pci/pcie/Kconfig: bool "PCI Express Port Bus support" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and module_init() translates to device_initcall(). [bhelgaas: changelog, remove unused DRIVER_* macros] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCI_IMX6 drivers/pci/host/Kconfig: bool "Freescale i.MX6 PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and module_init() translates to device_initcall(). [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_ALTERA drivers/pci/host/Kconfig: bool "Altera PCIe controller" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and module_init() translates to device_initcall(). [bhelgaas: changelog] Signed-off-by:
-
Paul Gortmaker authored
This code is not being built as a module by anyone: drivers/pci/host/Kconfig:config PCIE_ALTERA_MSI drivers/pci/host/Kconfig: bool "Altera PCIe MSI feature" Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(), etc., so that when reading the driver there is no doubt it is builtin-only. The information is preserved in comments at the top of the file. [bhelgaas: changelog] Signed-off-by:
-
- 18 Aug, 2016 1 commit
-
-
Bjorn Helgaas authored
Add an pci_enable_ptm() interface so drivers can enable PTM. The PCI core enables PTM on PTM Roots and switches automatically, but we don't enable PTM on endpoints unless a driver requests it. Signed-off-by:
-
- 15 Aug, 2016 1 commit
-
-
Jonathan Yong authored
Add Precision Time Measurement (PTM) support (see PCIe r3.1, sec 6.22). Enable PTM on PTM Root devices and switch ports. This does not enable PTM on endpoints. There currently are no PTM-capable devices on the market, but it is expected to be supported by the Intel Apollo Lake platform. [bhelgaas: complete rework] Signed-off-by:
Jonathan Yong <jonathan.yong@intel.com> Signed-off-by:
-
- 08 Aug, 2016 1 commit
-
-
Linus Torvalds authored
-
