#
0a867568 |
|
18-Oct-2023 |
Robert Richter <rrichter@amd.com> |
PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler In Restricted CXL Device (RCD) mode a CXL device is exposed as an RCiEP, but CXL downstream and upstream ports are not enumerated and not visible in the PCIe hierarchy. [1] Protocol and link errors from these non-enumerated ports are signaled as internal AER errors, either Uncorrectable Internal Error (UIE) or Corrected Internal Errors (CIE) via an RCEC. Restricted CXL host (RCH) downstream port-detected errors have the Requester ID of the RCEC set in the RCEC's AER Error Source ID register. A CXL handler must then inspect the error status in various CXL registers residing in the dport's component register space (CXL RAS capability) or the dport's RCRB (PCIe AER extended capability). [2] Errors showing up in the RCEC's error handler must be handled and connected to the CXL subsystem. Implement this by forwarding the error to all CXL devices below the RCEC. Since the entire CXL device is controlled only using PCIe Configuration Space of device 0, function 0, only pass it there [3]. The error handling is limited to currently supported devices with the Memory Device class code set (CXL Type 3 Device, PCI_CLASS_MEMORY_CXL, 502h), handle downstream port errors in the device's cxl_pci driver. Support for other CXL Device Types (e.g. a CXL.cache Device) can be added later. To handle downstream port errors in addition to errors directed to the CXL endpoint device, a handler must also inspect the CXL RAS and PCIe AER capabilities of the CXL downstream port the device is connected to. Since CXL downstream port errors are signaled using internal errors, the handler requires those errors to be unmasked. This is subject of a follow-on patch. The reason for choosing this implementation is that the AER service driver claims the RCEC device, but does not allow it to register a custom specific handler to support CXL. Connecting the RCEC hard-wired with a CXL handler does not work, as the CXL subsystem might not be present all the time. The alternative to add an implementation to the portdrv to allow the registration of a custom RCEC error handler isn't worth doing it as CXL would be its only user. Instead, just check for an CXL RCEC and pass it down to the connected CXL device's error handler. With this approach the code can entirely be implemented in the PCIe AER driver and is independent of the CXL subsystem. The CXL driver only provides the handler. [1] CXL 3.0 spec: 9.11.8 CXL Devices Attached to an RCH [2] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors [3] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices Co-developed-by: Terry Bowman <terry.bowman@amd.com> Signed-off-by: Terry Bowman <terry.bowman@amd.com> Signed-off-by: Robert Richter <rrichter@amd.com> Cc: Oliver O'Halloran <oohall@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-pci@vger.kernel.org Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20231018171713.1883517-18-rrichter@amd.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
#
e67ad935 |
|
15-Nov-2022 |
Albert Zhou <albert.zhou.50@gmail.com> |
PCI: pciehp: Enable by default if USB4 enabled Thunderbolt/USB4 PCIe tunneling depends on native PCIe hotplug. Enable pciehp by default if USB4 is enabled. [bhelgaas: squash, update subject, commit logs, tidy whitespace] Link: https://lore.kernel.org/r/20221115113857.35800-2-albert.zhou.50@gmail.com Link: https://lore.kernel.org/r/20221115113857.35800-3-albert.zhou.50@gmail.com Signed-off-by: Albert Zhou <albert.zhou.50@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
602a4eda |
|
15-Jan-2022 |
Yicong Yang <yangyicong@hisilicon.com> |
PCI/AER: Update aer-inject URL The link to the aer-inject referenced leads to an empty repo and seems no longer used. Replace it with the link mentioned in Documentation/PCI/pcieaer-howto.rst. Link: https://lore.kernel.org/r/20220115104921.21606-1-yangyicong@hisilicon.com Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b4c7d207 |
|
02-Feb-2021 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/LINK: Remove bandwidth notification The PCIe Bandwidth Change Notification feature logs messages when the link bandwidth changes. Some users have reported that these messages occur often enough to significantly reduce NVMe performance. GPUs also seem to generate these messages. We don't know why the link bandwidth changes, but in the reported cases there's no indication that it's caused by hardware failures. Remove the bandwidth change notifications for now. Hopefully we can add this back when we have a better understanding of why this happens and how we can make the messages useful instead of overwhelming. Link: https://lore.kernel.org/r/20200115221008.GA191037@google.com/ Link: https://lore.kernel.org/r/155605909349.3575.13433421148215616375.stgit@gimli.home/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=206197 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
7ecd4a81 |
|
26-Jun-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
PCI: Replace http:// links with https:// Replace http:// links with https:// links. This reduces the likelihood of man-in-the-middle attacks when developers open these links. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. [bhelgaas: also update samsung.com links, drop sourceforge link] Link: https://lore.kernel.org/r/20200627103050.71712-1-grandmaster@al2klimov.de Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8c8ff55b |
|
08-Apr-2020 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/AER: Don't select CONFIG_PCIEAER by default PCIe Advanced Error Reporting (AER) is optional and there's no need for it to be selected by default. Remove the "default y" for CONFIG_PCIEAER. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Russell Currey <ruscur@russell.cc> Cc: Sam Bobroff <sbobroff@linux.ibm.com> Cc: Oliver O'Halloran <oohall@gmail.com>
|
#
ac1c8e35 |
|
23-Mar-2020 |
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> |
PCI/DPC: Add Error Disconnect Recover (EDR) support Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to notify OSPM that a device has been disconnected due to an error condition (ACPI v6.3, sec 5.6.6). OSPM advertises its support for EDR on PCI devices via _OSC (see [1], sec 4.5.1, table 4-4). The OSPM EDR notify handler should invalidate software state associated with disconnected devices and may attempt to recover them. OSPM communicates the status of recovery to the firmware via _OST (sec 6.3.5.2). For PCIe, firmware may use Downstream Port Containment (DPC) to support EDR. Per [1], sec 4.5.1, table 4-6, even if firmware has retained control of DPC, OSPM may read/write DPC control and status registers during the EDR notification processing window, i.e., from the time it receives an EDR notification until it clears the DPC Trigger Status. Note that per [1], sec 4.5.1 and 4.5.2.4, 1. If the OS supports EDR, it should advertise that to firmware by setting OSC_PCI_EDR_SUPPORT in _OSC Support. 2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in _OSC Support. Add an EDR notify handler to attempt recovery. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 [bhelgaas: squash add/enable patches into one] Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Len Brown <lenb@kernel.org>
|
#
9ae05225 |
|
06-Mar-2020 |
Thomas Gleixner <tglx@linutronix.de> |
PCI/AER: Fix the broken interrupt injection The AER error injection mechanism just blindly abuses generic_handle_irq() which is really not meant for consumption by random drivers. The include of linux/irq.h should have been a red flag in the first place. Driver code, unless implementing interrupt chips or low level hypervisor functionality has absolutely no business with that. Invoking generic_handle_irq() from non interrupt handling context can have nasty side effects at least on x86 due to the hardware trainwreck which makes interrupt affinity changes a fragile beast. Sathyanarayanan triggered a NULL pointer dereference in the low level APIC code that way. While the particular pointer could be checked this would only paper over the issue because there are other ways to trigger warnings or silently corrupt state. Invoke the new irq_inject_interrupt() mechanism, which has the necessary sanity checks in place and injects the interrupt via the irq_retrigger() mechanism, which is at least halfways safe vs. the fragile x86 affinity change mechanics. It's safe on x86 as it does not corrupt state, but it still can cause a premature completion of an interrupt affinity change causing the interrupt line to become stale. Very unlikely, but possible. For regular operations this is a non issue as AER error injection is meant for debugging and testing and not for usage on production systems. People using this should better know what they are doing. Fixes: 390e2db82480 ("PCI/AER: Abstract AER interrupt handling") Reported-by: sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: https://lkml.kernel.org/r/20200306130624.098374457@linutronix.de
|
#
87e90283 |
|
05-Oct-2019 |
Heiner Kallweit <hkallweit1@gmail.com> |
PCI/ASPM: Remove PCIEASPM_DEBUG Kconfig option and related code Previously, CONFIG_PCIEASPM_DEBUG enabled "link_state" and "clk_ctl" sysfs files that controlled ASPM. We believe these files were rarely if ever used. We recently added sysfs ASPM controls that are always present, so the debug code is no longer needed. Removing this debug code has been discussed for quite some time, see e.g. [0]. Remove PCIEASPM_DEBUG and the related code. [0] https://lore.kernel.org/lkml/20180727202619.GD173328@bhelgaas-glaptop.roam.corp.google.com/ Link: https://lore.kernel.org/r/ec935d8e-c084-3938-f1d1-748617596b25@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
b6479581 |
|
06-Nov-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove PCIe Kconfig dependencies on PCI drivers/pci/pcie/Kconfig is only sourced by drivers/pci/Kconfig, and only when PCI is defined, so there's no need to depend on PCI again. Remove the unnecessary dependencies. Link: https://lore.kernel.org/r/20191106222420.10216-5-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
|
#
33ce09ef |
|
06-Nov-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/ASPM: Remove dependency on PCIEPORTBUS The ASPM support does not depend on the portdrv, so remove the Kconfig dependency. Link: https://lore.kernel.org/r/20191106222420.10216-4-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
|
#
97a0ac8a |
|
06-Nov-2019 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/PTM: Remove dependency on PCIEPORTBUS The PTM support does not depend on the portdrv, so remove the Kconfig dependency. Link: https://lore.kernel.org/r/20191106222420.10216-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Cc: Jonathan Yong <jonathan.yong@intel.com>
|
#
2078e1e7 |
|
01-May-2019 |
Keith Busch <kbusch@kernel.org> |
PCI/LINK: Add Kconfig option (default off) e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") added dmesg logging whenever a link changes speed or width to a state that is considered degraded. Unfortunately, it cannot differentiate signal integrity-related link changes from those intentionally initiated by an endpoint driver, including drivers that may live in userspace or VMs when making use of vfio-pci. Some GPU drivers actively manage the link state to save power, which generates a stream of messages like this: vfio-pci 0000:07:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:02.0 (capable of 64.000 Gb/s with 5 GT/s x16 link) Since we can't distinguish the intentional changes from the signal integrity issues, leave the reporting turned off by default. Add a Kconfig option to turn it on if desired. Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") Link: https://lore.kernel.org/linux-pci/20190501142942.26972-1-keith.busch@intel.com Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8f55ed3f |
|
05-Mar-2019 |
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> |
PCI: Update PCIEPORTBUS Kconfig help text The Virtual Channel service has been removed and Downstream Port Containment has been added, so update the symbol description to be consistent with the current code. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fe73c23d |
|
18-Oct-2018 |
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> |
PCI: pcie: Remove redundant 'default n' from Kconfig 'default n' is the default value for any bool or tristate Kconfig setting so there is no need to write it explicitly. Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO is not set' for visible symbols") the Kconfig behavior is the same regardless of 'default n' being present or not: ... One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO bool config FOO bool default n With this change, neither of these will generate a '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). That might make it clearer to people that a bare 'default n' is redundant. ... Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
0b15f1e3 |
|
08-Jun-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/AER: Use "PCI Express" consistently in Kconfig text Use "PCI Express" consistently in Kconfig text. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
|
#
4696b828 |
|
08-Jun-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI/AER: Hoist aerdrv.c, aer_inject.c up to drivers/pci/pcie/ Hoist aerdrv.c, aer_inject.c up to drivers/pci/pcie/ so they're next to other PCIe service drivers. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
|
#
eed85ff4 |
|
24-Jan-2018 |
Keith Busch <kbusch@kernel.org> |
PCI/DPC: Enable DPC only if AER is available The "Determination of DPC Control" implementation note in PCIe r4.0, sec 6.1.10, recommends the operating system always link DPC control to the control of AER, as the two functionalities are strongly connected. To avoid conflicts over whether platform firmware or the OS controls DPC, enable DPC only if AER is enabled in the OS, and the device's error handling does not have firmware-first AER handling. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
|
#
7328c8f4 |
|
26-Jan-2018 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Add SPDX GPL-2.0 when no license was specified b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") added SPDX GPL-2.0 to several PCI files that previously contained no license information. Add SPDX GPL-2.0 to all other PCI files that did not contain any license information and hence were under the default GPL version 2 license of the kernel. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b2103ccb |
|
02-Jan-2017 |
Rajat Jain <rajatja@google.com> |
PCI/ASPM: Add support for L1 substates Add support for ASPM L1 substates. For details about L1 substates, see the PCIe r3.1 spec, which includes the ECN below in secs 5.5 and 7.33. Add macros for the 4 new L1 substates, and add a new ASPM "POWER_SUPERSAVE" policy that can be used to enable L1 substates on a system if desired. The new policy is in a sense, a superset of the existing POWERSAVE policy. The 4 policies are now: DEFAULT: Reads and uses whatever ASPM states BIOS enabled PERFORMANCE: Everything except L0 disabled. POWERSAVE: L0s and L1 enabled (but not L1 substates) POWER_SUPERSAVE: L0s + L1 + L1 substates also enabled [bhelgaas: add PCIe r3.1 spec reference] Link: https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
9bb04a0c |
|
11-Jun-2016 |
Jonathan Yong <jonathan.yong@intel.com> |
PCI: Add Precision Time Measurement (PTM) support 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: Bjorn Helgaas <bhelgaas@google.com>
|
#
a4959d8c |
|
06-Jul-2016 |
Keith Busch <kbusch@kernel.org> |
PCI: Remove DPC tristate module option Change the Downstream Port Containment config type from tristate to bool. The driver doesn't automatically load based on any rules, so it needs to be built-in in order to bind to devices it needs to drive. Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
26e51571 |
|
28-Apr-2016 |
Keith Busch <kbusch@kernel.org> |
PCI: Add Downstream Port Containment driver Add driver for the PCI Express Downstream Port Containment extended capability. DPC is an optional capability to contain uncorrectable errors below a port. For more information on DPC, please see PCI Express Base Specification Revision 4, section 7.31, or view the PCI-SIG DPC ECN here: https://pcisig.com/sites/default/files/specification_documents/ECN_DPC_2012-02-09_finalized.pdf When a DPC event is triggered, the hardware disables downstream links, so the DPC driver schedules removal for all devices below this port. This may happen concurrently with a PCIe hotplug driver if enabled. When all downstream devices are removed and the link state transitions to disabled, the DPC driver clears the DPC status and interrupt bits so the link may retrain for a newly connected device. [bhelgaas: clear (not set) DPC_CTL bits on remove, whitespace cleanup] Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Lukas Wunner <lukas@wunner.de>
|
#
cc73176c |
|
14-Mar-2016 |
Andreas Ziegler <andreas.ziegler@fau.de> |
PCI: Cleanup pci/pcie/Kconfig whitespace Clean up style issues in drivers/pci/pcie/Kconfig, in particular all indentation is now done using tabs, not spaces, and the definition of PCIEASPM_DEBUG is now separated from the definition of PCIEASPM with a newline. Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
fbb988be |
|
27-Nov-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PCI core code. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c10cc483 |
|
23-Jul-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: pciehp: Convert pciehp to be builtin only, not modular Convert pciehp to be builtin only, with no module option. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
|
#
d47af0bc |
|
04-Jul-2013 |
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> |
PCI: Rename "PCI Express support" kconfig title The previous option title "PCI Express support" is confusing. The name seems to imply this option is required to get PCIe support, which is not true. Fix it to "PCI Express Port Bus support" which is more accurate. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
05795726 |
|
11-Apr-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove unnecessary dependencies between PME and ACPI PCIe PME doesn't depend on ACPI, so remove the #includes and Kconfig dependency. Based-on-patch-by: Andrew Murray <Andrew.Murray@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
444ee9bd |
|
16-Jan-2013 |
Kees Cook <keescook@chromium.org> |
PCI: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
ad71c962 |
|
03-Feb-2012 |
Matthew Garrett <mjg@redhat.com> |
PCI: pcie: Add support for setting default ASPM policy Distributions may wish to provide different defaults for PCIE ASPM depending on their target audience. Provide a configuration option for choosing the default policy. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d56641c7 |
|
06-Dec-2011 |
P. Christeas <xrg@linux.gr> |
PCI: kconfig: English typo in pci/pcie/Kconfig Just fix this help text. Signed-off-by: P. Christeas <xrg@linux.gr> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6a108a14 |
|
20-Jan-2011 |
David Rientjes <rientjes@google.com> |
kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option is used to configure any non-standard kernel with a much larger scope than only small devices. This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes references to the option throughout the kernel. A new CONFIG_EMBEDDED option is added that automatically selects CONFIG_EXPERT when enabled and can be used in the future to isolate options that should only be considered for embedded systems (RISC architectures, SLOB, etc). Calling the option "EXPERT" more accurately represents its intention: only expert users who understand the impact of the configuration changes they are making should enable it. Reviewed-by: Ingo Molnar <mingo@elte.hu> Acked-by: David Woodhouse <david.woodhouse@intel.com> Signed-off-by: David Rientjes <rientjes@google.com> Cc: Greg KH <gregkh@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jens Axboe <axboe@kernel.dk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robin Holt <holt@sgi.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ea5f9fc5 |
|
22-Jun-2010 |
Matthew Garrett <mjg@redhat.com> |
PCI: Default PCIe ASPM control to on and require !EMBEDDED to disable The CONFIG_PCIEASPM option is confusing and potentially dangerous. ASPM is a hardware mediated feature rather than one under direct OS control, and even if the config option is disabled the system firmware may have turned on ASPM on various bits of hardware. This can cause problems later - various hardware that claims to support ASPM does a poor job of it and may hang or cause other difficulties. The kernel is able to recognise this in many cases and disable the ASPM functionality, but only if CONFIG_PCIEASPM is enabled. Given that in its default configuration this option will either leave the hardware as it was originally or disable hardware functionality that may cause problems, it should by default y. The only reason to disable it ought to be to reduce code size, so make it dependent on CONFIG_EMBEDDED. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: lrodriguez@atheros.com Cc: maximlevitsky@gmail.com Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
c7f48656 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PCI PM: PCIe PME root port service driver PCIe native PME detection mechanism is based on interrupts generated by root ports or event collectors every time a PCIe device sends a PME message upstream. Once a PME message has been sent by an endpoint device and received by its root port (or event collector in the case of root complex integrated endpoints), the Requester ID from the message header is registered in the root port's Root Status register. At the same time, the PME Status bit of the Root Status register is set to indicate that there's a PME to handle. If PCIe PME interrupt is enabled for the root port, it generates an interrupt once the PME Status has been set. After receiving the interrupt, the kernel can identify the PCIe device that generated the PME using the Requester ID from the root port's Root Status register. [For details, see PCI Express Base Specification, Rev. 2.0.] Implement a driver for the PCIe PME root port service working in accordance with the above description. Based on a patch from Shaohua Li <shaohua.li@intel.com>. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
4cfe02fa |
|
22-Apr-2008 |
Jesper Juhl <jesper.juhl@gmail.com> |
PCI Express ASPM support should default to 'No' Running 'make oldconfig' I just noticed that PCIEASPM defaults to 'y' in Kconfig even though the feature is both experimental and the help text recommends that if you are unsure you say 'n'. It seems to me that this really should default to 'n', not 'y' at the moment. The following patch makes that change. Please consider applying. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
7d715a6c |
|
24-Feb-2008 |
Shaohua Li <shaohua.li@intel.com> |
PCI: add PCI Express ASPM support PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: -default, BIOS default setting -powersave, highest power saving mode, enable all available ASPM state and clock power management -performance, highest performance, disable ASPM and clock power management By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. Note: some devices might not work well with aspm, either because chipset issue or device issue. The patch provide API (pci_disable_link_state), driver can disable ASPM for specific device. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
cc3a1378 |
|
02-Feb-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
Revert "PCI: PCIE ASPM support" This reverts commit 6c723d5bd89f03fc3ef627d50f89ade054d2ee3b. It caused build errors on non-x86 platforms, config file confusion, and even some boot errors on some x86-64 boxes. All around, not quite ready for prime-time :( Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6c723d5b |
|
23-Jan-2008 |
Shaohua Li <shaohua.li@intel.com> |
PCI: PCIE ASPM support PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: -default, BIOS default setting -powersave, highest power saving mode, enable all available ASPM state and clock power management -performance, highest performance, disable ASPM and clock power management By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
89913bf7 |
|
09-Aug-2007 |
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> |
pciehp: remove CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE Remove unnecessary CONFIG_HOTPLUG_PCI_PCIE_EVENT_MODE. The CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE option is not needed because polling mechanism can be enabled through 'pciehp_poll_mode' module option. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6c2b374d |
|
31-Jul-2006 |
Zhang, Yanmin <yanmin.zhang@intel.com> |
PCI-Express AER implemetation: AER core and aerdriver Patch 3 implements the core part of PCI-Express AER and aerdrv port service driver. When a root port service device is probed, the aerdrv will call request_irq to register irq handler for AER error interrupt. When a device sends an PCI-Express error message to the root port, the root port will trigger an interrupt, by either MSI or IO-APIC, then kernel would run the irq handler. The handler collects root error status register and schedules a work. The work will call the core part to process the error based on its type (Correctable/non-fatal/fatal). As for Correctable errors, the patch chooses to just clear the correctable error status register of the device. As for the non-fatal error, the patch follows generic PCI error handler rules to call the error callback functions of the endpoint's driver. If the device is a bridge, the patch chooses to broadcast the error to downstream devices. As for the fatal error, the patch resets the pci-express link and follows generic PCI error handler rules to call the error callback functions of the endpoint's driver. If the device is a bridge, the patch chooses to broadcast the error to downstream devices. Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
|