summaryrefslogtreecommitdiff
path: root/fs/dcache.c
diff options
context:
space:
mode:
authorJoel Stanley <joel@jms.id.au>2021-12-07 06:38:10 +0300
committerJoel Stanley <joel@jms.id.au>2022-01-31 08:26:55 +0300
commitd46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c (patch)
treeebf8a1a959d6b82ab705ea188eb34f2bc16b3ce7 /fs/dcache.c
parente783362eb54cd99b2cac8b3a9aeac942e6f6ac07 (diff)
downloadlinux-d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c.tar.xz
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>
Diffstat (limited to 'fs/dcache.c')
0 files changed, 0 insertions, 0 deletions