<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/pci/pcie/err.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-03-07T23:58:07Z</updated>
<entry>
<title>PCI/AER: Block runtime suspend when handling errors</title>
<updated>2024-03-07T23:58:07Z</updated>
<author>
<name>Stanislaw Gruszka</name>
</author>
<published>2024-02-12T12:01:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=002bf2fbc00e5c4b95fb167287e2ae7d1973281e'/>
<id>urn:sha1:002bf2fbc00e5c4b95fb167287e2ae7d1973281e</id>
<content type='text'>
PM runtime can be done simultaneously with AER error handling.  Avoid that
by using pm_runtime_get_sync() before and pm_runtime_put() after reset in
pcie_do_recovery() for all recovering devices.

pm_runtime_get_sync() will increase dev-&gt;power.usage_count counter to
prevent any possible future request to runtime suspend a device.  It will
also resume a device, if it was previously in D3hot state.

I tested with igc device by doing simultaneous aer_inject and rpm
suspend/resume via /sys/bus/pci/devices/PCI_ID/power/control and can
reproduce:

  igc 0000:02:00.0: not ready 65535ms after bus reset; giving up
  pcieport 0000:00:1c.2: AER: Root Port link has been reset (-25)
  pcieport 0000:00:1c.2: AER: subordinate device reset failed
  pcieport 0000:00:1c.2: AER: device recovery failed
  igc 0000:02:00.0: Unable to change power state from D3hot to D0, device inaccessible

The problem disappears when this patch is applied.

Link: https://lore.kernel.org/r/20240212120135.146068-1-stanislaw.gruszka@linux.intel.com
Signed-off-by: Stanislaw Gruszka &lt;stanislaw.gruszka@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Recognize disconnected devices in report_error_detected()</title>
<updated>2022-06-08T20:08:40Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2022-06-01T07:40:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5e69a33c5cec019dd8ca46e31749c6dc78f7cbf3'/>
<id>urn:sha1:5e69a33c5cec019dd8ca46e31749c6dc78f7cbf3</id>
<content type='text'>
When a device is already unplugged by pciehp by the time the AER handler is
invoked, the PCIe device will already be in the pci_channel_io_perm_failure
state.  In that case simply return PCI_ERS_RESULT_DISCONNECT instead of
trying to do a state transition that will fail.

Also untangle the state transition failure from the lack of methods to
improve the debugging output in case it happens again.

Link: https://lore.kernel.org/r/20220601074024.3481035-1-hch@lst.de
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "PCI: Use to_pci_driver() instead of pci_dev-&gt;driver"</title>
<updated>2021-11-11T19:36:22Z</updated>
<author>
<name>Bjorn Helgaas</name>
</author>
<published>2021-11-10T18:03:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e0217c5ba10d7bf640f038b2feae58e630f2f958'/>
<id>urn:sha1:e0217c5ba10d7bf640f038b2feae58e630f2f958</id>
<content type='text'>
This reverts commit 2a4d9408c9e8b6f6fc150c66f3fef755c9e20d4a.

Robert reported a NULL pointer dereference caused by the PCI core
(local_pci_probe()) calling the i2c_designware_pci driver's
.runtime_resume() method before the .probe() method.  i2c_dw_pci_resume()
depends on initialization done by i2c_dw_pci_probe().

Prior to 2a4d9408c9e8 ("PCI: Use to_pci_driver() instead of
pci_dev-&gt;driver"), pci_pm_runtime_resume() avoided calling the
.runtime_resume() method because pci_dev-&gt;driver had not been set yet.

2a4d9408c9e8 and b5f9c644eb1b ("PCI: Remove struct pci_dev-&gt;driver"),
removed pci_dev-&gt;driver, replacing it by device-&gt;driver, which *has* been
set by this time, so pci_pm_runtime_resume() called the .runtime_resume()
method when it previously had not.

Fixes: 2a4d9408c9e8 ("PCI: Use to_pci_driver() instead of pci_dev-&gt;driver")
Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/
Reported-by: Robert Święcki &lt;robert@swiecki.net&gt;
Tested-by: Robert Święcki &lt;robert@swiecki.net&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
<entry>
<title>PCI: Use to_pci_driver() instead of pci_dev-&gt;driver</title>
<updated>2021-10-18T14:20:15Z</updated>
<author>
<name>Uwe Kleine-König</name>
</author>
<published>2021-10-12T21:11:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2a4d9408c9e8b6f6fc150c66f3fef755c9e20d4a'/>
<id>urn:sha1:2a4d9408c9e8b6f6fc150c66f3fef755c9e20d4a</id>
<content type='text'>
Struct pci_driver contains a struct device_driver, so for PCI devices, it's
easy to convert a device_driver * to a pci_driver * with to_pci_driver().
The device_driver * is in struct device, so we don't need to also keep
track of the pci_driver * in struct pci_dev.

Replace pci_dev-&gt;driver with to_pci_driver().  This is a step toward
removing pci_dev-&gt;driver.

[bhelgaas: split to separate patch]
Link: https://lore.kernel.org/r/20211004125935.2300113-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Factor out common dev-&gt;driver expressions</title>
<updated>2021-10-12T22:37:15Z</updated>
<author>
<name>Bjorn Helgaas</name>
</author>
<published>2021-10-12T22:20:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=171d149ce8d11f7fafbd4f338f14d472a153c3d4'/>
<id>urn:sha1:171d149ce8d11f7fafbd4f338f14d472a153c3d4</id>
<content type='text'>
Save the struct pci_driver pointer from pdev-&gt;driver instead of repeating
it several times.  No functional change.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Retain status from error notification</title>
<updated>2021-02-23T23:10:42Z</updated>
<author>
<name>Keith Busch</name>
</author>
<published>2021-01-04T23:02:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=387c72cdd7fb6bef650fb078d0f6ae9682abf631'/>
<id>urn:sha1:387c72cdd7fb6bef650fb078d0f6ae9682abf631</id>
<content type='text'>
Overwriting the frozen detected status with the result of the link reset
loses the NEED_RESET result that drivers are depending on for error
handling to report the .slot_reset() callback. Retain this status so
that subsequent error handling has the correct flow.

Link: https://lore.kernel.org/r/20210104230300.1277180-4-kbusch@kernel.org
Reported-by: Hinko Kocevar &lt;hinko.kocevar@ess.eu&gt;
Tested-by: Hedi Berriche &lt;hedi.berriche@hpe.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Acked-by: Hedi Berriche &lt;hedi.berriche@hpe.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Clear status of the reporting device</title>
<updated>2021-02-23T23:10:10Z</updated>
<author>
<name>Keith Busch</name>
</author>
<published>2021-01-04T23:02:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7d7cbeaba5b7aea8e1e4eb988d6b5e7cb3c34490'/>
<id>urn:sha1:7d7cbeaba5b7aea8e1e4eb988d6b5e7cb3c34490</id>
<content type='text'>
Error handling operates on the first Downstream Port above the detected
error, but the error may have been reported by a downstream device.
Clear the AER status of the device that reported the error rather than
the first Downstream Port.

Link: https://lore.kernel.org/r/20210104230300.1277180-2-kbusch@kernel.org
Tested-by: Hedi Berriche &lt;hedi.berriche@hpe.com&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Acked-by: Hedi Berriche &lt;hedi.berriche@hpe.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Recover from RCiEP AER errors</title>
<updated>2020-12-05T21:26:02Z</updated>
<author>
<name>Qiuxu Zhuo</name>
</author>
<published>2020-11-21T00:10:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5790862255028c831761e13014ee87a06df828f1'/>
<id>urn:sha1:5790862255028c831761e13014ee87a06df828f1</id>
<content type='text'>
Add support for handling AER errors detected by Root Complex Integrated
Endpoints (RCiEPs).  These errors are signaled to software natively via a
Root Complex Event Collector (RCEC) or non-natively via ACPI APEI if the
platform retains control of AER or uses a non-standard RCEC-like device.

When recovering from RCiEP errors, the Root Error Command and Status
registers are in the AER Capability of an associated RCEC (if any), not in
a Root Port.  In the non-native case, the platform is responsible for those
registers and we can't touch them.

[bhelgaas: commit log, etc]
Co-developed-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Link: https://lore.kernel.org/r/20201121001036.8560-13-sean.v.kelley@intel.com
Signed-off-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Signed-off-by: Qiuxu Zhuo &lt;qiuxu.zhuo@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Recover from RCEC AER errors</title>
<updated>2020-12-05T21:25:58Z</updated>
<author>
<name>Sean V Kelley</name>
</author>
<published>2020-12-02T17:26:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a175102b0a82fc57853a9e611c42d1d6172e5180'/>
<id>urn:sha1:a175102b0a82fc57853a9e611c42d1d6172e5180</id>
<content type='text'>
A Root Complex Event Collector (RCEC) collects and signals AER errors that
were detected by Root Complex Integrated Endpoints (RCiEPs), but it may
also signal errors it detects itself.  This is analogous to errors detected
and signaled by a Root Port.

Update the AER service driver to claim RCECs in addition to Root Ports.
Add support for handling RCEC-detected AER errors.  This does not
include handling RCiEP-detected errors that are signaled by the RCEC.

Note that we expect these errors only from the native AER and APEI paths,
not from DPC or EDR.

[bhelgaas: split from combined RCEC/RCiEP patch, commit log]
Signed-off-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
<entry>
<title>PCI/ERR: Clear AER status only when we control AER</title>
<updated>2020-12-04T17:18:58Z</updated>
<author>
<name>Sean V Kelley</name>
</author>
<published>2020-11-24T16:55:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aa344bc8b727b47b4350b59d8166216a3f351e55'/>
<id>urn:sha1:aa344bc8b727b47b4350b59d8166216a3f351e55</id>
<content type='text'>
In some cases a bridge may not exist as the hardware controlling may be
handled only by firmware and so is not visible to the OS. This scenario is
also possible in future use cases involving non-native use of RCECs by
firmware. In this scenario, we expect the platform to retain control of the
bridge and to clear error status itself.

Clear error status only when the OS has native control of AER.

Signed-off-by: Sean V Kelley &lt;sean.v.kelley@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
</entry>
</feed>
