Message ID | 20191104090151.129140-1-hare@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | Revamp SCSI result values | expand |
On 11/4/19 10:00 AM, Hannes Reinecke wrote: > Hi all, > > the 'result' field in the SCSI command is defined as having > 4 fields. The top byte is declared as a 'driver_byte', where the > driver can signal some internal status back to the midlayer. > However, there is quite a bit of overlap between the driver_byte > and the host_byte, resulting in the driver_byte being used in > very few places, and mostly in legacy drivers. > Additionally, we have _two_ sets of definitions for the > last byte (status byte), which can specified either in SAM terms > or in the linux-specific terms, which are shifted right by one > from the SAM ones. > Needless to say, the linux-specific ones are declared obsolete > for years now. > And to make the confusion complete, both the status byte and > the driver byte have a byte for a valid sense code, resulting > in quite some confusion which of those bits to check. > > This patchset does several things: > - remove the linux-specific status byte definitions, and use > the SAM values throughout > - replace the driver-byte values with either SAM ones (for sense > code checking) or host-byte definitions > - remove the driver-byte definitions > > As usual, comments and reviews are welcome. > > Please note, commit 66cf50e65b18 ("scsi: qla2xxx: fixup incorrect > usage of host_byte") from 5.4/scsi-fixes is a prerequisite for > this patch series. > Martin, ping? I've got another patchset queued for splitting off the 'result' field, which kinda depends on this one... Cheers, Hannes
Hi Hannes, > Martin, ping? > > I've got another patchset queued for splitting off the 'result' field, > which kinda depends on this one... It's a pretty big and intrusive change. And even though we (somewhat unexpectedly) got another week, I still think it's too risky for 5.5. I plan on merging it first thing when the queue for 5.6 opens.
On 11/19/19 4:35 AM, Martin K. Petersen wrote: > > Hi Hannes, > >> Martin, ping? >> >> I've got another patchset queued for splitting off the 'result' field, >> which kinda depends on this one... > > It's a pretty big and intrusive change. And even though we (somewhat > unexpectedly) got another week, I still think it's too risky for 5.5. > > I plan on merging it first thing when the queue for 5.6 opens. > Sure. Just wanted to know if it's worth playing around with the next round of patches (splitting off 'result', thus ending a history of shifting status bytes into wrong places :-) Thanks for the heads-up. Should I do a respin for 5.5? Cheers, Hannes
Hannes,
> Should I do a respin for 5.5?
I suggest you rebase on top of -rc1 once it's out. If you want a bit
more eyes on the series before then, just post on top of current
scsi-queue.