diff options
author | Joel Stanley <[email protected]> | 2021-12-07 14:08:10 +1030 |
---|---|---|
committer | Joel Stanley <[email protected]> | 2022-01-31 15:56:55 +1030 |
commit | d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c (patch) | |
tree | ebf8a1a959d6b82ab705ea188eb34f2bc16b3ce7 /tools/perf/scripts/python/syscall-counts.py | |
parent | e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 (diff) |
fsi: scom: Fix error handling
SCOM error handling is made complex by trying to pass around two bits of
information: the function return code, and a status parameter that
represents the CFAM error status register.
The commit f72ddbe1d7b7 ("fsi: scom: Remove retries") removed the
"hidden" retries in the SCOM driver, in preference of allowing the
calling code (userspace or driver) to decide how to handle a failed
SCOM. However it introduced a bug by attempting to be smart about the
return codes that were "errors" and which were ok to fall through to the
status register parsing.
We get the following errors:
- EINVAL or ENXIO, for indirect scoms where the value is invalid
- EINVAL, where the size or address is incorrect
- EIO or ETIMEOUT, where FSI write failed (aspeed master)
- EAGAIN, where the master detected a crc error (GPIO master only)
- EBUSY, where the bus is disabled (GPIO master in external mode)
In all of these cases we should fail the SCOM read/write and return the
error.
Thanks to Dan Carpenter for the detailed bug report.
Fixes: f72ddbe1d7b7 ("fsi: scom: Remove retries")
Link: https://lists.ozlabs.org/pipermail/linux-fsi/2021-November/000235.html
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Joel Stanley <[email protected]>
Reviewed-by: Eddie James <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joel Stanley <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions