On Tue, 19 Aug 2014, Christoph Hellwig wrote:
> On Thu, Aug 07, 2014 at 11:58:37AM -0400, Alan Stern wrote:
> > > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote:
> > > > > I doubt either of them forces users to hack up flags for these cases.
> > > >
> > > > Why was this change needed in the first place? There's no explanation
> > > > in the patch itself.
> > >
> > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT?
> >
> > No, the patch that started this Bugzilla entry. Tiziano says it is
> > needed in order to send vendor-specific commands that use the LUN bits
> > in CDB[1].
>
> Yes, I'd really like to know the exact scenario. What kind of command
> is this and who sends it?
I don't know what the command is, but Tiziano is sending it via the
SCSI-generic (sg) interface.
In the meantime, I have made a little progress with Windows. It turns
out there are two reasons my earlier test didn't work:
I didn't bother to set up a valid serial number for the test
device, and Windows wants to see the serial number.
Windows wants at least one of the logical units to be
removable.
After those issues were fixed, the host did recognize both logical
units. I tested with two devices, one reporting an ANSI SCSI level of
0 and the other 2. In both cases, Windows 7 does _not_ stick the LUN
value into the high bits of CDB[1].
This suggests that we shouldn't be doing that either, for USB
mass-storage devices. But I'm reluctant to change it because of the
possibility of regressions, not to mention the fact that it would
violate the SCSI spec.
Suggestions?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
