On 14-08-20 03:15 PM, Alan Stern wrote:
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?
Perhaps we could add another bit flag in struct
scsi_host_template such as:
unsigned int transport_says_dont_scsi2_lun_cmd:1;
then drivers/usb/storage/scsiglue.c could set that
bit in its usb_stor_host_template and
drivers/scsi/scsi.c could take heed (and not mask
cmd->cmnd[1] with the LUN).
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html