[PATCH 0/3] SCSI & usb-storage: new flags for VPD pages and REPORT LUNS

[PATCH 0/3] SCSI & usb-storage: new flags for VPD pages and REPORT LUNS

[Alan Stern]

James and Greg:

Perry Wagle reports that his new USB-ESATA drives don't work properly 
because they don't like getting the LUN bits in the second byte of the 
command string.  We set those bits only because usb-storage adjusts the 
SCSI revision level for all devices to SCSI-2; the drives themselves 
report a value of 0x06 (which would be SCSI-7).

The reason for mangling the scsi_level value was that some USB devices 
reported SCSI-3 but couldn't handle some of the mandatory features: VPD 
pages and the REPORT LUNS command.  It's now clear that instead of 
abusing scsi_level, we should have separate flags for the individual 
features we need to control.

That's what this patch series does.  The first merely corrects an 
existing typo in the definition of struct scsi_target.  The second adds 
the new flags and makes usb-storage use them.  The third takes this 
opportunity to do a little code clean-up in usb-storage.

The changes are more or less equally divided between SCSI and
usb-storage.  James, if they look okay to you and you don't mind taking
them through your tree, that would be fine.  Or if you prefer, I'm sure
Greg won't mind taking them.

Although this should be quite safe, there is a small possibility that
it will mess up some buggy device that has been working okay up to now.  
If necessary, we can always add another blacklist flag to usb-storage
to treat such devices in the old way -- setting scsi_level to SCSI_2.  
However, because of this possibility I'm not going to send these
patches to the stable tree.

Alan Stern

Re: [PATCH 0/3] SCSI & usb-storage: new flags for VPD pages and REPORT LUNS

[Greg KH]

On Tue, Jan 10, 2012 at 01:42:40PM -0500, Alan Stern wrote:
> James and Greg:
> 
> Perry Wagle reports that his new USB-ESATA drives don't work properly 
> because they don't like getting the LUN bits in the second byte of the 
> command string.  We set those bits only because usb-storage adjusts the 
> SCSI revision level for all devices to SCSI-2; the drives themselves 
> report a value of 0x06 (which would be SCSI-7).
> 
> The reason for mangling the scsi_level value was that some USB devices 
> reported SCSI-3 but couldn't handle some of the mandatory features: VPD 
> pages and the REPORT LUNS command.  It's now clear that instead of 
> abusing scsi_level, we should have separate flags for the individual 
> features we need to control.
> 
> That's what this patch series does.  The first merely corrects an 
> existing typo in the definition of struct scsi_target.  The second adds 
> the new flags and makes usb-storage use them.  The third takes this 
> opportunity to do a little code clean-up in usb-storage.
> 
> The changes are more or less equally divided between SCSI and
> usb-storage.  James, if they look okay to you and you don't mind taking
> them through your tree, that would be fine.  Or if you prefer, I'm sure
> Greg won't mind taking them.

I'll be glad to take these, James, any objection?

thanks,

greg k-h

RE: [usb-storage] Re: [PATCH 0/3] SCSI & usb-storage: new flags for VPD pages and REPORT LUNS

[Daniel Taylor]

 

> -----Original Message-----
> From: usb-storage@lists.one-eyed-alien.net 
> [mailto:usb-storage@lists.one-eyed-alien.net] On Behalf Of Greg KH
> Sent: Tuesday, January 24, 2012 12:01 PM
> To: Alan Stern; James Bottomley
> Cc: Matthew Dharm; Perry Wagle; USB Storage list; SCSI 
> development list
> Subject: [usb-storage] Re: [PATCH 0/3] SCSI & usb-storage: 
> new flags for VPD pages and REPORT LUNS
> 
> On Tue, Jan 10, 2012 at 01:42:40PM -0500, Alan Stern wrote:
> > James and Greg:
> > 
> > Perry Wagle reports that his new USB-ESATA drives don't 
> work properly 
> > because they don't like getting the LUN bits in the second 
> byte of the 
> > command string.  We set those bits only because usb-storage 
> adjusts the 
> > SCSI revision level for all devices to SCSI-2; the drives 
> themselves 
> > report a value of 0x06 (which would be SCSI-7).
> > 
> > The reason for mangling the scsi_level value was that some 
> USB devices 
> > reported SCSI-3 but couldn't handle some of the mandatory 
> features: VPD 
> > pages and the REPORT LUNS command.  It's now clear that instead of 
> > abusing scsi_level, we should have separate flags for the 
> individual 
> > features we need to control.
> > 
> > That's what this patch series does.  The first merely corrects an 
> > existing typo in the definition of struct scsi_target.  The 
> second adds 
> > the new flags and makes usb-storage use them.  The third takes this 
> > opportunity to do a little code clean-up in usb-storage.
> > 
> > The changes are more or less equally divided between SCSI and
> > usb-storage.  James, if they look okay to you and you don't 
> mind taking
> > them through your tree, that would be fine.  Or if you 
> prefer, I'm sure
> > Greg won't mind taking them.
> 
> I'll be glad to take these, James, any objection?
> 
> thanks,
> 
> greg k-h

I handled this a bit differently, for our old 2.6.32 kernel, based on
discussions on this list with Matthew Dharm back in April 2011.

I changed the scsi_level entry in /sys to be read/write, rather than
read-only.  This allows a ussr-space white-list handler to fixup
drives that are known to work.

The gist of the discussion was whether the kernel should keep a white
or black list for every drive on the planet to handle the scsi_level
change/no-change or that user space could have the database and either
apply it manually or automatically through udevd.  Matthew expressed
a preference for user space to manage the information.

I can't find the patch set for these flag changes in my local email
archive, but can we have controls for these available in user-space?

Thanks,

Dan

> 
> -- 
> You received this message because you are subscribed to the 
> Google Groups "USB Mass Storage on Linux" group.
> To post to this group, send email to 
> usb-storage@lists.one-eyed-alien.net.
> To unsubscribe from this group, send email to 
> usb-storage+unsubscribe@lists.one-eyed-alien.net.
> For more options, visit this group at 
> http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-
> storage/?hl=en.
> 
> 

RE: [usb-storage] Re: [PATCH 0/3] SCSI & usb-storage: new flags for VPD pages and REPORT LUNS

[Alan Stern]

On Wed, 25 Jan 2012, Daniel Taylor wrote:

> I handled this a bit differently, for our old 2.6.32 kernel, based on
> discussions on this list with Matthew Dharm back in April 2011.
> 
> I changed the scsi_level entry in /sys to be read/write, rather than
> read-only.  This allows a ussr-space white-list handler to fixup
> drives that are known to work.
> 
> The gist of the discussion was whether the kernel should keep a white
> or black list for every drive on the planet to handle the scsi_level
> change/no-change or that user space could have the database and either
> apply it manually or automatically through udevd.  Matthew expressed
> a preference for user space to manage the information.
> 
> I can't find the patch set for these flag changes in my local email
> archive, but can we have controls for these available in user-space?

Is this really workable in practice?  The scsi_level value is used when 
scanning for LUNs and partitions, which doesn't give userspace much 
time to change the value.

Can you explain the reason why you need to change the scsi_level value?

Alan Stern