linux-kernel - RE: [PATCH 2/2] hwmon (occ): Retry for checksum failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Apr 2022 09:10:22 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Guenter Roeck' <linux@...ck-us.net>,
        Eddie James <eajames@...ux.ibm.com>
CC:     "linux-fsi@...ts.ozlabs.org" <linux-fsi@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "joel@....id.au" <joel@....id.au>, "jk@...abs.org" <jk@...abs.org>,
        "alistair@...ple.id.au" <alistair@...ple.id.au>
Subject: RE: [PATCH 2/2] hwmon (occ): Retry for checksum failure

From: Guenter Roeck
> Sent: 24 April 2022 18:18
> 
> On Mon, Mar 21, 2022 at 10:31:12AM -0500, Eddie James wrote:
> > Due to the OCC communication design with a shared SRAM area,
> > checkum errors are expected due to corrupted buffer from OCC
> > communications with other system components. Therefore, retry
> > the command twice in the event of a checksum failure.
> >
> > Signed-off-by: Eddie James <eajames@...ux.ibm.com>
> 
> I assume this will be applied together with patch 1 of the series.
> 
> Acked-by: Guenter Roeck <linux@...ck-us.net>
> 
> Guenter
> 
> > ---
> >  drivers/hwmon/occ/p9_sbe.c | 28 ++++++++++++++++++----------
> >  1 file changed, 18 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
> > index 49b13cc01073..7f4c3f979c54 100644
> > --- a/drivers/hwmon/occ/p9_sbe.c
> > +++ b/drivers/hwmon/occ/p9_sbe.c
> > @@ -84,17 +84,25 @@ static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd, size_t len)
> >  	struct p9_sbe_occ *ctx = to_p9_sbe_occ(occ);
> >  	size_t resp_len = sizeof(*resp);
> >  	int rc;
> > -
> > -	rc = fsi_occ_submit(ctx->sbe, cmd, len, resp, &resp_len);
> > -	if (rc < 0) {
> > -		if (resp_len) {
> > -			if (p9_sbe_occ_save_ffdc(ctx, resp, resp_len))
> > -				sysfs_notify(&occ->bus_dev->kobj, NULL,
> > -					     bin_attr_ffdc.attr.name);
> > +	int tries = 0;
> > +
> > +	do {

Why not use a for() loop?

> > +		rc = fsi_occ_submit(ctx->sbe, cmd, len, resp, &resp_len);
> > +		if (rc < 0) {
> > +			if (resp_len) {
> > +				if (p9_sbe_occ_save_ffdc(ctx, resp, resp_len))
> > +					sysfs_notify(&occ->bus_dev->kobj, NULL,
> > +						     bin_attr_ffdc.attr.name);
> > +
> > +				return rc;
> > +			} else if (rc != -EBADE) {
> > +				return rc;
> > +			}

No need for else after return.

> > +			/* retry twice for checksum failures */
> > +		} else {
> > +			break;

I'd break on the success path after testing (rc >= 0).
Saves a level of indent.

> >  		}
> > -
> > -		return rc;
> > -	}
> > +	} while (++tries < 3);
> >
> >  	switch (resp->return_status) {
> >  	case OCC_RESP_CMD_IN_PRG:

Probably end up with something like:
	for (tries = 0; tries < 3; tries++) {
		rc = ...;
		if (rc >= 0)
			break;
		if (resp_len) {
			...
			return rc;
		}
		if (rc != -EBADE)
			return rc;
	}

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)