Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

[Hans de Goede]

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

Re: Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

[James Bottomley]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

[Josua Dietze]

Hans de Goede schrieb:

> 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.


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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add US_FL_NO_ULD_ATTACH usb mass storage unusal dev flag ?

[Hans de Goede]

Hi,

On 04/04/2010 08:56 PM, Josua Dietze wrote:
> Hans de Goede schrieb:
>
>> 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.
>
>
> 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.
>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html