Hi,
On Wed, Mar 17, 2021 at 10:45 AM Dan Williams wrote:
>
> On Wed, Mar 17, 2021 at 10:20 AM Sathyanarayanan Kuppuswamy Natarajan
> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 17, 2021 at 9:31 AM Dan Williams
> > wrote:
> > >
> >
t seeing that effect in testing?
In our test case, there is a good chance that the LINK UP event is also
filtered. We change the dpc_reset_active status only after we verify
the link is up. So if hotplug handler handles the LINK UP event before
we change the status of dpc_reset_active, then it will not lead to the
issue mentioned by Lukas.
if (!pcie_wait_for_link(pdev, true)) {
pci_info(pdev, "Data Link Layer Link Active not set in
1000 msec\n");
- return PCI_ERS_RESULT_DISCONNECT;
+ status = PCI_ERS_RESULT_DISCONNECT;
}
- return PCI_ERS_RESULT_RECOVERED;
+ atomic_dec_return_release(>dpc_reset_active);
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
From: Kuppuswamy Sathyanarayanan
When hotplug and DPC are both enabled on a Root port or
Downstream Port, during DPC events that cause a DLLSC link
down/up events, such events (DLLSC) must be suppressed to
let the DPC driver own the recovery path.
When DPC is present and enabled, hardware will
From: Kuppuswamy Sathyanarayanan
When hotplug and DPC are both enabled on a Root port or
Downstream Port, during DPC events that cause a DLLSC link
down/up events, such events must be suppressed to let the DPC
driver own the recovery path.
When DPC is present and enabled, hardware will put the
From: Kuppuswamy Sathyanarayanan
Hi All,
Sending a test email to verify my mail server. please ignore it.
--
2.25.1
On Wed, Oct 14, 2020 at 11:43 PM Christoph Hellwig wrote:
>
> On Tue, Oct 13, 2020 at 08:17:39AM -0700, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 10/13/20 4:56 AM, Christoph Hellwig wrote:
> > > You might want to split out pcie_do_fatal_recovery and get rid of the
> > > state argument:
>
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.
Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
struct pci_host_bridge PCIe specific native_* members to "1" is
incorrect. So protect the PCIe specific member initialization
with CONFIG_PCIEPORTBUS.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
From: Kuppuswamy Sathyanarayanan
Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
struct pci_host_bridge PCIe specific native_* members to "1" is
incorrect. So protect the PCIe specific member initialization
with CONFIG_PCIEPORTBUS.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
struct pci_host_bridge PCIe specific native_* members to "1" is
incorrect. So protect the PCIe specific member initialization
with CONFIG_PCIEPORTBUS.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
From: Kuppuswamy Sathyanarayanan
In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.
Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only
From: Kuppuswamy Sathyanarayanan
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. Current fatal error recovery implementation relies
on PCIe hotplug (pciehp) handler for detaching and
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
struct pci_host_bridge PCIe specific native_* members to "1" is
incorrect. So protect the PCIe specific member initialization
with CONFIG_PCIEPORTBUS.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.
Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native
From: Kuppuswamy Sathyanarayanan
Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only
From: Kuppuswamy Sathyanarayanan
In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.
Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.
Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native
From: Kuppuswamy Sathyanarayanan
Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.
Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
From: Kuppuswamy Sathyanarayanan
PCI_ERS_RESULT_NEED_RESET error status implies the device is
requesting a slot reset and a notification about slot reset
completion via ->slot_reset() callback.
But in non-fatal errors case, if report_error_detected() or
report_mmio_enabled() functions requests
From: Kuppuswamy Sathyanarayanan
Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. With current implementation, after successful
fatal error recovery, non-hotplug capable device state won't be
restored properly. You can find related issues in following links.
From: Kuppuswamy Sathyanarayanan
Commit c100beb9ccfb ("PCI/AER: Use only _OSC to determine AER ownership")
removed HEST dependency in determining the AER ownership status. The
following patch set cleansup rest of the HEST table related code from
AER driver.
This patchset also includes some
From: Kuppuswamy Sathyanarayanan
AER is a PCIe Extended Capability. So checking for dev->aer_cap
will implicitly include check for PCIe device. So remove redundant
pci_is_pcie() checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 11 +--
1 file changed, 1
From: Kuppuswamy Sathyanarayanan
pcie_aer_get_firmware_first() includes check for dev->aer_cap.
So remove redundant dev->aer_cap checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
Commit c100beb9ccfb ("PCI/AER: Use only _OSC to determine AER ownership")
removed the dependency of HEST table in determining the status of AER
ownership. But AER driver still uses HEST table parsed result in
verifying the AER ownership status in some of its
From: Kuppuswamy Sathyanarayanan
AER is a PCIe Extended Capability. So checking for dev->aer_cap
will implicitly include check for PCIe device. So remove redundant
pci_is_pcie() checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 11 +--
1 file changed, 1
From: Kuppuswamy Sathyanarayanan
Commit c100beb9ccfb ("PCI/AER: Use only _OSC to determine AER ownership")
removed HEST dependency in determining the AER ownership status. The
following patch set cleansup rest of the HEST table related code from
AER driver.
This patchset also includes some
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
Commit c100beb9ccfb ("PCI/AER: Use only _OSC to determine AER ownership")
removed the dependency of HEST table in determining the status of AER
ownership. But AER driver still uses HEST table parsed result in
verifying the AER ownership status in some of its
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
pcie_aer_get_firmware_first() includes check for dev->aer_cap.
So remove redundant dev->aer_cap checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
From: Kuppuswamy Sathyanarayanan
pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
From: Kuppuswamy Sathyanarayanan
pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native
From: Kuppuswamy Sathyanarayanan
AER is a PCIe Extended Capability. So checking for dev->aer_cap
will implicitly include check for PCIe device. So remove redundant
pci_is_pcie() checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 11 +--
1 file changed, 1
From: Kuppuswamy Sathyanarayanan
Commit e7909188dd4d ("PCI/AER: Use only _OSC to determine AER ownership")
removed the dependency of HEST table in determining the status of AER
ownership. But AER driver still uses HEST table parsed result in
verifying the AER ownership status in some of its
From: Kuppuswamy Sathyanarayanan
pcie_aer_get_firmware_first() includes check for dev->aer_cap.
So remove redundant dev->aer_cap checks.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/aer.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
From: Kuppuswamy Sathyanarayanan
Commit e7909188dd4d ("PCI/AER: Use only _OSC to determine AER ownership")
removed HEST dependency in determining the AER ownership status. The
following patch set cleansup rest of the HEST table related code from
AER driver.
This patchset also includes some
From: Kuppuswamy Sathyanarayanan
If there are non-hotplug capable devices connected to a given
port, then during the fatal error recovery(triggered by DPC or
AER), after calling reset_link() function, we cannot rely on
hotplug handler to detach and re-enumerate the device drivers
in the affected
From: Kuppuswamy Sathyanarayanan
Currently, pci_prg_resp_pasid_required() function reads the
PASID Required bit status from register every time we call
the function. Since PASID Required bit is a read-only value,
instead of reading it from register every time, read it once and
cache it in struct
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, OS must implement following steps
to enable/use EDR feature.
1. OS can use bit 7 of _OSC Control Field to negotiate control over
Downstream Port Containment
From: Kuppuswamy Sathyanarayanan
As per ACPI specification v6.3, sec 5.6.6, Error Disconnect Recover
(EDR) notification used by firmware to let OS know about the DPC event
and permit OS to perform error recovery when processing the EDR
notification. Also, as per PCI firmware specification r3.2
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, OS is responsible for clearing the AER
registers in EDR mode. So clear AER registers in dpc_process_error()
function.
Signed-off-by: Kuppuswamy Sathyanarayanan
From: Kuppuswamy Sathyanarayanan
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") uses
reset_link() to recover from fatal errors. But, if the reset is
successful there is no need to continue the rest of the error recovery
checks. Also, during fatal error recovery, if the initial
From: Kuppuswamy Sathyanarayanan
Currently, in native mode, DPC driver is configured to trigger DPC only
for FATAL errors and hence it only supports port recovery for FATAL
errors. But with Error Disconnect Recover (EDR) support, DPC
configuration is done by firmware, and hence we should expect
From: Kuppuswamy Sathyanarayanan
With Error Disconnect Recover (EDR) support, we need to support
processing DPC event either from DPC IRQ or ACPI EDR event. So create
a wrapper function dpc_process_error() and move common error handling
code in to it. It will be used to process the DPC event in
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, table 4-6, Error Disconnect
Recover (EDR) support allows OS to handle error recovery and
clearing Error Registers even in FF mode. So remove FF mode checks in
From: Kuppuswamy Sathyanarayanan
As per ACPI specification r6.3, sec 5.6.6, when firmware owns Downstream
Port Containment (DPC), its expected to use the "Error Disconnect
Recover" (EDR) notification to alert OSPM of a DPC event and if OS
supports EDR, its expected to handle the software state
From: Kuppuswamy Sathyanarayanan
This patchset adds support for following features:
1. Error Disconnect Recover (EDR) support.
2. _OSC based negotiation support for DPC.
You can find EDR spec in the following link.
https://members.pcisig.com/wg/PCI-SIG/document/12614
Changes since v8:
*
From: Kuppuswamy Sathyanarayanan
Current implementation of ATS, PASID, PRI does not handle VF dependencies
correctly. Following patches addresses this issue.
Changes since v6:
* Removed locking interfaces used in v6.
* Made necessary changes to PRI/PASID enable/disable calls to allow
From: Kuppuswamy Sathyanarayanan
Since pci_prg_resp_pasid_required() function has dependency on both
PASID and PRI, define it only if both CONFIG_PCI_PRI and
CONFIG_PCI_PASID config options are enabled.
Fixes: e5567f5f6762 ("PCI/ATS: Add pci_prg_resp_pasid_required()
interface.")
Signed-off-by:
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable Page Request Interface (PRI) for VF device
in iommu_enable_dev_iotlb(), it always fails because PRI support for
PCIe VF device is currently broken. Current implementation expects
the given PCIe device (PF & VF) to implement PRI
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable PASID for VF device in
iommu_enable_dev_iotlb(), it always fails because PASID support for PCIe
VF device is currently broken in PCIE driver. Current implementation
expects the given PCIe device (PF & VF) to implement PASID capability
From: Kuppuswamy Sathyanarayanan
Currently, PASID capability checks are repeated across all PASID API's.
Instead, cache the capability check result in pci_pasid_init() and use
it in other PASID API's.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/ats.c | 50
From: Kuppuswamy Sathyanarayanan
As per PCIe r4.0, sec 9.3.6, VF must not implement Enhanced Allocation
Capability. So skip pci_ea_init() for virtual devices.
Cc: Ashok Raj
Cc: Keith Busch
Suggested-by: Ashok Raj
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pci.c | 7 +++
From: Kuppuswamy Sathyanarayanan
Currently all VF's needs to be disable their ATS service before
disabling the ATS service in corresponding PF device. But this logic is
incorrect and does not align with the spec. Also it might lead to
some power and performance impact in the system. As per PCIe
From: Kuppuswamy Sathyanarayanan
Currently, PRI capability checks are repeated across all PRI API's.
Instead, cache the capability check result in pci_pri_init() and use it
in other PRI API's.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/ats.c | 56
From: Kuppuswamy Sathyanarayanan
This patchset adds support for following features:
1. Error Disconnect Recover (EDR) support.
2. _OSC based negotiation support for DPC.
You can find EDR spec in the following link.
https://members.pcisig.com/wg/PCI-SIG/document/12614
Changes since v7:
*
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, OS is responsible for clearing the AER
registers in EDR mode. So clear AER registers in dpc_process_error()
function.
Signed-off-by: Kuppuswamy Sathyanarayanan
From: Kuppuswamy Sathyanarayanan
With Error Disconnect Recover (EDR) support, we need to support
processing DPC event either from DPC IRQ or ACPI EDR event. So create
a wrapper function dpc_process_error() and move common error handling
code in to it. It will be used to process the DPC event in
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, OS must implement following steps
to enable/use EDR feature.
1. OS can use bit 7 of _OSC Control Field to negotiate control over
Downstream Port Containment
From: Kuppuswamy Sathyanarayanan
Currently, in native mode, DPC driver is configured to trigger DPC only
for FATAL errors and hence it only supports port recovery for FATAL
errors. But with Error Disconnect Recover (EDR) support, DPC
configuration is done by firmware, and hence we should expect
From: Kuppuswamy Sathyanarayanan
As per ACPI specification r6.3, sec 5.6.6, when firmware owns Downstream
Port Containment (DPC), its expected to use the "Error Disconnect
Recover" (EDR) notification to alert OSPM of a DPC event and if OS
supports EDR, its expected to handle the software state
From: Kuppuswamy Sathyanarayanan
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") uses
reset_link() to recover from fatal errors. But, if the reset is
successful there is no need to continue the rest of the error recovery
checks. Also, during fatal error recovery, if the initial
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, table 4-6, Error Disconnect
Recover (EDR) support allows OS to handle error recovery and
clearing Error Registers even in FF mode. So remove FF mode checks in
From: Kuppuswamy Sathyanarayanan
As per ACPI specification v6.3, sec 5.6.6, Error Disconnect Recover
(EDR) notification used by firmware to let OS know about the DPC event
and permit OS to perform error recovery when processing the EDR
notification. Also, as per PCI firmware specification r3.2
From: Kuppuswamy Sathyanarayanan
As per ACPI specification r6.3, sec 5.6.6, when firmware owns Downstream
Port Containment (DPC), its expected to use the "Error Disconnect
Recover" (EDR) notification to alert OSPM of a DPC event and if OS
supports EDR, its expected to handle the software state
From: Kuppuswamy Sathyanarayanan
As per ACPI specification v6.3, sec 5.6.6, Error Disconnect Recover
(EDR) notification used by firmware to let OS know about the DPC event
and permit OS to perform error recovery when processing the EDR
notification. Also, as per PCI firmware specification r3.2
From: Kuppuswamy Sathyanarayanan
With Error Disconnect Recover (EDR) support, we need to support
processing DPC event either from DPC IRQ or ACPI EDR event. So create
a wrapper function dpc_process_error() and move common error handling
code in to it. It will be used to process the DPC event in
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, table 4-6, Error Disconnect
Recover (EDR) support allows OS to handle error recovery and
clearing Error Registers even in FF mode. So remove FF mode checks in
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, OS is responsible for clearing the AER
registers in EDR mode. So clear AER registers in dpc_process_error()
function.
Signed-off-by: Kuppuswamy Sathyanarayanan
From: Kuppuswamy Sathyanarayanan
Currently, in native mode, DPC driver is configured to trigger DPC only
for FATAL errors and hence it only supports port recovery for FATAL
errors. But with Error Disconnect Recover (EDR) support, DPC
configuration is done by firmware, and hence we should expect
From: Kuppuswamy Sathyanarayanan
As per PCI firmware specification r3.2 Downstream Port Containment
Related Enhancements ECN, sec 4.5.1, OS must implement following steps
to enable/use EDR feature.
1. OS can use bit 7 of _OSC Control Field to negotiate control over
Downstream Port Containment
From: Kuppuswamy Sathyanarayanan
This patchset adds support for following features:
1. Error Disconnect Recover (EDR) support.
2. _OSC based negotiation support for DPC.
You can find EDR spec in the following link.
https://members.pcisig.com/wg/PCI-SIG/document/12614
Changes since v6:
*
From: Kuppuswamy Sathyanarayanan
Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") uses
reset_link() to recover from fatal errors. But, if the reset is
successful there is no need to continue the rest of the error recovery
checks. Also, during fatal error recovery, if the initial
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable Page Request Interface (PRI) for VF device
in iommu_enable_dev_iotlb(), it always fails because PRI support for
PCIe VF device is currently broken. Current implementation expects
the given PCIe device (PF & VF) to implement PRI
From: Kuppuswamy Sathyanarayanan
Currently, PASID capability checks are repeated across all PASID API's.
Instead, cache the capability check result in pci_pasid_init() and use
it in other PASID API's.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/ats.c | 50
From: Kuppuswamy Sathyanarayanan
As per PCIe spec r5.0, sec 9.3.7, in SR-IOV devices, capabilities like
PASID, PRI, VC, etc are shared between PF and its associated VFs. So, to
prevent race conditions between PF/VF while updating configuration
registers of these shared capabilities, a new
From: Kuppuswamy Sathyanarayanan
As per PCIe r4.0, sec 9.3.6, VF must not implement Enhanced Allocation
Capability. So skip pci_ea_init() for virtual devices.
Cc: Ashok Raj
Cc: Keith Busch
Suggested-by: Ashok Raj
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pci.c | 7 +++
From: Kuppuswamy Sathyanarayanan
Currently all VF's needs to be disable their ATS service before
disabling the ATS service in corresponding PF device. But this logic is
incorrect and does not align with the spec. Also it might lead to
some power and performance impact in the system. As per PCIe
From: Kuppuswamy Sathyanarayanan
Currently, PRI capability checks are repeated across all PRI API's.
Instead, cache the capability check result in pci_pri_init() and use it
in other PRI API's.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/ats.c | 56
1 - 100 of 720 matches
Mail list logo
