Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

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.

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

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

Did you try to set the AVOID_RESET_QUIRK attribute? This was originally targeted at those mode-switching devices, but might be useful in this case too.

Josua Dietze

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Thanks for the hint. although not really what I was looking for this has prompted me to investigate this issue further as I was not completely happy with the NO_ULD_ATTACH solution.

After turning on full debugging in the usb-storage driver it turns out the out enabling of US_FL_SANE_SENSE was the culprit, when I explicitly specify US_FL_BAD_SENSE, thus disabling the auto enabling of SANE_SENSE, things are much better, the first 2 READ_CAPACITY calls still fail (stalled endpoint), but no longer result in a full device reset.

I'll do a patch adding these devices to unusual_devs.h with the US_FL_BAD_SENSE quirk tomorrow.

Thanks all for your input.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html