On Sun, 2010-04-04 at 16:52 +0200, Hans de Goede wrote: > Hi All, > > First let me introduce the buggy device in question I'm trying to > get to work. I've been putting a lot of work in making cheap picture frames > work with Linux. These are usual keychain models with a 1.1", 1.5", 1.8" > or 2.4" display, using a proprietary USB protocol to put pictures on them. > > I've succeeded in getting models with the Appotech ax203 (2 usb-id's), ax206 > (1 usb-id) and Sitronix st2205 chips (1 usb id many different models) working, > libgphoto2 svn now has code to upload pictures to these devices. > > But there are still some loose ends to tie up wrt to the Appotech devices. > All 3 variants of these devices present themselves as a USB mass storage > attached cdrom. And in all 3 the cdrom emulation is buggy. Although they work > they are showing repeated usb resets, causing delays accessing the device, > related to commands send to the cdrom. I've managed to make the usb resets > largely go away by telling hal to not probe them for media changes (hal-info > patch send upstream). > > But one of the variants (usb id 1908:1320) still hits a usb-reset when > drivers/scsi/sr.c does a READ_CAPACITY from get_sector_size(). After the initial > READ_CAPACITY failure and the usb reset, the second READ_CAPACITY succeeds. > > This device bug causes a circa 5 second long delay between plugging in the device > and being able to use it. I've been looking at fixing this and the most elegant > solutions seems to be to use the scsi blacklist BLIST_NO_ULD_ATTACH flag. This will > stop the sr driver from connecting at all (which means one cannot access the > windows software on the emulated cdrom under Linux, which I believe is not > any loss). > > There are 3 ways to get this flag set: > > 1) Add these devices to the static blacklist in > drivers/scsi/scsi_devinfo.c > > Reading the comments there, this does not seem to be something which is > wanted. > > 2) Introduce a new US_FL_NO_ULD_ATTACH flag for drivers/usb/storage/unusal_devs.h > which will set the scsi blacklist flag (I have not checked yet if this > is possible, but I think it will). > > 3) Use a udev rule to dynamically add an entry to the blacklist in > drivers/scsi/scsi_devinfo.c > > Reading the comment in drivers/scsi/scsi_devinfo.c, the maintainers of this > file want to move the keeping of the blacklist to userspace and this would > match that. The hope in this comment never really materialised. The whether you want to use scsi_devinfo.c or unusual_devs.h for a no attach flag depends mainly on how you recognise the device. If the inquiry strings are definitive, go the SCSI route. If you can only really do it by the USB dev id matching, then go the unusual_devs.h route. James > Note that an alternative solution would be to simply live with the 5 second delay, > with as added bonus that the windows software can be accessed under Linux. > > In case it wasn't clear I'm looking for input on how to best handle this. Please keep > me CC-ed as I'm not subscribed to either list. > > Regards, > > Hans > > -- > 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 -- 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
