Searched hist:d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c (Results 1 – 1 of 1) sorted by relevance
/linux/drivers/fsi/ |
H A D | fsi-scom.c | diff d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c Tue Dec 07 04:38:10 CET 2021 Joel Stanley <joel@jms.id.au> 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 <dan.carpenter@oracle.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20211207033811.518981-2-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
|