Patch "fsi: scom: Fix error handling" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    fsi: scom: Fix error handling

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     fsi-scom-fix-error-handling.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit c4f2c410f02cc7071c7fadb308b3264f22f0d9ed
Author: Joel Stanley <joel@xxxxxxxxx>
Date:   Tue Dec 7 14:08:10 2021 +1030

    fsi: scom: Fix error handling
    
    [ Upstream commit d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c ]
    
    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@xxxxxxxxxx>
    Signed-off-by: Joel Stanley <joel@xxxxxxxxx>
    Reviewed-by: Eddie James <eajames@xxxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20211207033811.518981-2-joel@xxxxxxxxx
    Signed-off-by: Joel Stanley <joel@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index da1486bb6a14..3b427f7e9027 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -289,7 +289,7 @@ static int put_scom(struct scom_device *scom, uint64_t value,
 	int rc;
 
 	rc = raw_put_scom(scom, value, addr, &status);
-	if (rc == -ENODEV)
+	if (rc)
 		return rc;
 
 	rc = handle_fsi2pib_status(scom, status);
@@ -308,7 +308,7 @@ static int get_scom(struct scom_device *scom, uint64_t *value,
 	int rc;
 
 	rc = raw_get_scom(scom, value, addr, &status);
-	if (rc == -ENODEV)
+	if (rc)
 		return rc;
 
 	rc = handle_fsi2pib_status(scom, status);



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux