[SRU][J][PATCH 0/1] [UBUNTU 22.04] s390/pci: Handle PCI error codes other than 0x3a (LP: #2120344)

[Massimiliano Pellizzer]

BugLink: https://bugs.launchpad.net/bugs/2120344

[ Impact ]

s390/pci: Handle PCI error codes other than 0x3a

The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.

[ Fix ]

Backport the following commit from upstream:
- 3cd03ea57e8e s390/pci: Handle PCI error codes other than 0x3a

[ Test Plan ]

Boot the kernel on an IBM Z system with PCI devices bound to drivers that
support error recovery and inject different PCI error codes.
For recoverable errors, check that the device auto-recovers and remains usable.
For 0x2A–0x2C errors, verify they are ignored with no impact.
For permanent failure codes (0x3B, 0x40), confirm the device is correctly marked
as failed.
Use dmesg to validate that recovery paths are triggered as expected and that
unaffected devices continue normal operation.

[ Regression Potential ]

The fix affects how the s390 PCI error handler interprets and reacts to PCI
event codes. A bug here could cause error codes to be misclassified, leading to
incorrect recovery actions.
Users may see devices being driven into recovery even for irrelevant events,
devices left permanently failed when they should have recovered, or recovery
attempts being triggered repeatedly in a loop.