On Wed, 5 Nov 2003, Stephane GALLES wrote: > Hi all, > > I was trying to find the unusual_devs.h entry for my > usb-storage camera that did not work out of the box > and I found a behavior of the usb-storage/SCSI > drivers that I do not understand... > > So, I was doing my tests with a 2.6-test9, in verbose mode > for usb-storage, and I found that the first INQUIRY failed > for the camera. OK, big deal, one more buggy camera... but ...
This can be fixed easily enough by creating an entry for your camera in unusual_devs.h with the FIX_INQUIRY flag set. In fact, that's the reason for a lot of the entries in that file... > ...what suprised me was that their was no usb-storage > dmesg to tell me that the initial probing failed... That's because it wasn't usb-storage doing the probing; it was scsi_scan_host(). And it's normal for such probes to fail. Each time a new host is detected, the scsi layer tries to probe for all possible targets. Only the probes that succeed result in the creation of a new scsi device structure. > And something by far worst, a usb-storage message said 'new usb-storage > device' > and their was a new entry in /proc/bus/scsi/storage, meaning that from > usb-storage > driver point of view, everything's OK. That's correct. From the point of view of usb-storage, everything _was_ OK. It was able to communicate with the device, send commands, and get replies with no difficulty. > In the same time, no new entry in /proc/scsi/scsi and of course, no > new SCSI device. Right, because the probe failed. > So, I looked at the code... My understanding of the SCSI layer is > very light, but it seems that the final registration into the SCSI layer > is made in the scsi_scan_host function, that as no return status. > > So when the scsi_scan_host function internally fails (it is the case > with my camera, no host is found actually) Remember: scsi_scan_host() didn't fail. It did exactly what it was supposed to do. It was your camera that failed, by not providing the correct response to the INQUIRY command. > the usb-storage driver > thinks that everything's OK (It only tests the value returned by the > scsi_add_host function, but all the work is done in scsi_scan_host). Again, that's right. scsi_scan_host() _can't_ fail in the sense you mean. The worst that can happen is that it might not detect a non-compliant device (that's what happened to you). But it's normal for devices not to exist at various target addresses, so that can't be considered a failure. > So, what have I missed ? I've checked how the other drivers used > the scsi_scan_function, and it is always the same thing. You haven't missed anything. > I found out that in 2.6-test1 the scsi_scan_host function was > called by the scsi_add_host function itself, but even in this case, > nothing more was checked by scsi_add_host... > > Any rational explanation ? Is it normal that the usb-storage layer > can not be informed that the managed host was not found by the > underlaying layer ? You mean the managed device, not the managed host. If we wanted, we could add code to the usb-storage driver that would check after calling scsi_add_host() to see if the device had been detected. But if it hadn't been, usb-storage wouldn't be able to do anything about it, so there's really no point in checking. A better, more general solution would be to have usb-storage automatically check the result from every INQUIRY command -- or at least from the first INQUIRY command sent to each new device. Depending on how it fails, usb-storage could set the FIX_INQUIRY flag and then make up its usual fake response. That would remove the need to have a special entry in unusual_devs.h, which would be a Good Thing since lots of USB devices share this particular flaw. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
