On Wed, Jan 4, 2012 at 7:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 4 Jan 2012, Matthew Dharm wrote: >> >> 1) Reasonably correct (i.e. 1 or 2) >> 2) Reports 0 (which, when -1'ed, yields a rev of 0xff). I actually >> had an argument with a vendor who insisted this was "correct" because >> the device didn't really support all the required SCSI commands; it's >> difficult to say he was wrong. > > I'm not sure what the story is here... But note that the SCSI layer > doesn't increment the reported revision value if it indicates > pre-SCSI-2, i.e., SCSI_UNKNOWN or SCSI_1 (0 or 1 without CCS). Sorry, wasn't clear. The increment/decrement thing I was recalling was part of the process of mapping the returned data to a value which is printed in /proc/scsi/scsi and dmesg buffers. But, my primary point was about devices returning SCSI_UNKNOWN, which of course is moot because.... > All that stuff about forcing the level to be at least SCSI-2 was > removed in 2007, by commit f3f4906516a084bbd9aa3da7592e6b029fe78f5b > (usb-storage: SCSI level fixes). What Oliver and I have been talking > about is rather the code added by commit > a4e628328ec60873fec9d506d682155391f589ce (USB Storage: wedge SCSI > revision at 2 for usb-storage devices) in 2005 and later modified by > that other commit, which prevents the level from ever going higher than > SCSI-2. You were right; I was mis-remembering here. Too many interations of this code in the past, and frankly 2007 was 2 daytime-jobs ago for me. So, I guess the situation really comes down to this: The current code prevents anyone from reporting anything higher than SCSI_2, but lower values are allowed. Here, we have a device that needs to report higher than SCSI_2. Allowing reporting of values higher than SCSI_2 may cause issues with READ_CAPACITY (but we have an unusual_devs flag for that case), REPORT_LUNS (handled by your patch by globally blocking REPORT_LUNS for all usb-storage devices), reading VPD pages, and possible st_mod logic. Hrm... do we have any idea how devices respond to reading various VPD pages? I'm not really concerned about st_mod. There are just too few USB tape devices out there anymore. Any complaints we get could be dealt with on a device-by-device basis with special flags, if necessary. BUT, without some assurances that devices won't fall over when asked for VPD pages, I'm hesitant to go forward. How about this: what if you change the name of the flag from "no_report_luns" to "likely_braindead_target" (you can pick a different name if you want) and then use that to block REPORT_LUNS as well as the enhanced VPD retrieval? With this plan, devices reporting higher than SCSI_2 will get commands formatted the way they want (no LUN bit-stuffing), but will also not get commands that we're not positive they will accept. The flip side is to go forward with your patch as planned, and if the VPD issue becomes a problem, then add in a separate "don't get VPD pages" flag later. Unless this VPD data is *really* important, I would be inclined to not issue the command. A userspace tool could always issue the command if the user wanted the info, and thus they accept the responsibility for killing their device (until reset). Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
