On 07/27/2009 06:40 PM, Boaz Harrosh wrote: > On 07/27/2009 06:19 PM, Martin K. Petersen wrote: >>>>>>> "Boaz" == Boaz Harrosh <bharrosh@xxxxxxxxxxx> writes: >> Boaz> Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must >> Boaz> be supported but you are saying it's only SBC2/SPC3. So I guess >> Boaz> there is nothing else we can do. >> >> Yes, EVPD must be supported. USB-ATA bridge firmware writers are >> dyslexic. Film at 11. >> >> What I'm saying is that *our* reason for sending out extended inquiry >> appeared in SBC2 (block limits VPD). So there is no point in asking >> devices older than that. >> >> The fact that this fixes the problem for Tarkan's crappy disk is a >> (quasi-intentional) side effect. My patch simply tries to be >> conservative about asking for those pages. >> >> >> Boaz> What I hate about all this is that in USB the scsi_level is hard >> Boaz> coded at the driver, without actually been able to probe the >> Boaz> device about it. >> >> Huh, what? >> > > Look in drivers/usb/storage::slave_configure > > /* Some devices report a SCSI revision level above 2 but are > * unable to handle the REPORT LUNS command (for which > * support is mandatory at level 3). Since we already have > * a Get-Max-LUN request, we won't lose much by setting the > * revision level down to 2. The only devices that would be > * affected are those with sparse LUNs. */ > if (sdev->scsi_level > SCSI_2) > sdev->sdev_target->scsi_level = > sdev->scsi_level = SCSI_2; > Maybe it should be: if (sdev->scsi_level > SCSI_2 && sdev->scsi_level < SCSI_SPC_2) sdev->sdev_target->scsi_level = sdev->scsi_level = SCSI_2; To account for the devices the comment is talking about. Which seems to be written at the time SCSI_3 was the highest level. > So the scsi_level is hard coded to very low. > Or am I reading this code wrong and it is only triggered for some but not > all devices? > > Boaz > -- Sigh Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
