[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MWHPR21MB159365DE648C8911E6AA53D2D70F9@MWHPR21MB1593.namprd21.prod.outlook.com>
Date: Wed, 16 Jun 2021 20:10:50 +0000
From: Michael Kelley <mikelley@...rosoft.com>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
CC: KY Srinivasan <kys@...rosoft.com>, Long Li <longli@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: [PATCH 1/3] scsi: storvsc: Miscellaneous code cleanups
From: Martin K. Petersen <martin.petersen@...cle.com> Sent: Wednesday, June 16, 2021 1:07 PM
>
> > Unfortunately, it's not quite right. The line of code in question
> > needs to be
> >
> > if ((vstor_packet->vm_srb.scsi_status & 0xFF) == SAM_STAT_CHECK_CONDITION &&
>
> > The status_byte() helper was doing the masking as well as the right
> > shift, so the masking will need to be open coded.
>
> CHECK_CONDITION is obsolete so no shifting is required for the SAM
> status. And as far as I can tell vm_srb.scsi_status is a u8:
>
> struct vmscsi_request {
> u16 length;
> u8 srb_status;
> u8 scsi_status;
> [...]
>
Indeed, you are right! I was trying to preserve the masking with 0xFF
from the original code before my patch, but that masking was
spurious. :-( So yes, it's good.
Thanks,
Michael
Powered by blists - more mailing lists