| Message ID | 1565896263-26277-1-git-send-email-eajames@linux.ibm.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | [dev-5.2] fsi: scom: Don't abort operations for minor errors | expand |
On Thu, 15 Aug 2019 at 19:11, Eddie James <eajames@linux.ibm.com> wrote: > > The scom driver currently fails out of operations if certain system > errors are flagged in the status register; system checkstop, special > attention, or recoverable error. These errors won't impact the ability > of the scom engine to perform operations, so the driver should continue > under these conditions. > Also, don't do a PIB reset for these conditions, since it won't help. > > Signed-off-by: Eddie James <eajames@linux.ibm.com> Jeremy, can you have a look a this one please? > --- > drivers/fsi/fsi-scom.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c > index 343153d..004dc03 100644 > --- a/drivers/fsi/fsi-scom.c > +++ b/drivers/fsi/fsi-scom.c > @@ -38,8 +38,7 @@ > #define SCOM_STATUS_PIB_RESP_MASK 0x00007000 > #define SCOM_STATUS_PIB_RESP_SHIFT 12 > > -#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_ERR_SUMMARY | \ > - SCOM_STATUS_PROTECTION | \ > +#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_PROTECTION | \ > SCOM_STATUS_PARITY | \ > SCOM_STATUS_PIB_ABORT | \ > SCOM_STATUS_PIB_RESP_MASK) > @@ -251,11 +250,6 @@ static int handle_fsi2pib_status(struct scom_device *scom, uint32_t status) > /* Return -EBUSY on PIB abort to force a retry */ > if (status & SCOM_STATUS_PIB_ABORT) > return -EBUSY; > - if (status & SCOM_STATUS_ERR_SUMMARY) { > - fsi_device_write(scom->fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy, > - sizeof(uint32_t)); > - return -EIO; > - } > return 0; > } > > -- > 1.8.3.1 >
Hi Joel & Eddie, > > The scom driver currently fails out of operations if certain system > > errors are flagged in the status register; system checkstop, special > > attention, or recoverable error. These errors won't impact the > > ability > > of the scom engine to perform operations, so the driver should > > continue > > under these conditions. > > Also, don't do a PIB reset for these conditions, since it won't > > help. OK, that makes sense to me. Provided the scom engine is in a working state when SCOM_STATUS_ERR_SUMMARY is set, then I think we're good. On that assumption: Acked-by: Jeremy Kerr <jk@ozlabs.org> Cheers, Jeremy
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c index 343153d..004dc03 100644 --- a/drivers/fsi/fsi-scom.c +++ b/drivers/fsi/fsi-scom.c @@ -38,8 +38,7 @@ #define SCOM_STATUS_PIB_RESP_MASK 0x00007000 #define SCOM_STATUS_PIB_RESP_SHIFT 12 -#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_ERR_SUMMARY | \ - SCOM_STATUS_PROTECTION | \ +#define SCOM_STATUS_ANY_ERR (SCOM_STATUS_PROTECTION | \ SCOM_STATUS_PARITY | \ SCOM_STATUS_PIB_ABORT | \ SCOM_STATUS_PIB_RESP_MASK) @@ -251,11 +250,6 @@ static int handle_fsi2pib_status(struct scom_device *scom, uint32_t status) /* Return -EBUSY on PIB abort to force a retry */ if (status & SCOM_STATUS_PIB_ABORT) return -EBUSY; - if (status & SCOM_STATUS_ERR_SUMMARY) { - fsi_device_write(scom->fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy, - sizeof(uint32_t)); - return -EIO; - } return 0; }
The scom driver currently fails out of operations if certain system errors are flagged in the status register; system checkstop, special attention, or recoverable error. These errors won't impact the ability of the scom engine to perform operations, so the driver should continue under these conditions. Also, don't do a PIB reset for these conditions, since it won't help. Signed-off-by: Eddie James <eajames@linux.ibm.com> --- drivers/fsi/fsi-scom.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)