Retirement of CAM_QUIRK_NOSERIAL

[Scott Long]

Ulrich Spoerlein wrote:
> On Sun, 16.09.2007 at 11:48:00 -0600, Scott Long wrote:
>> Ulrich Spoerlein wrote:
>>> On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote:
>>>> All,
>>>>
>>>> The attached patch should make CAM behave properly with regard to
>>>> probing device serial numbers only when the device advertises that
>>>> it supports it.  It will hopefully eliminate the need for the 
>>>> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated 
>>>> legacy problem that may or may not be possible to fix).  This should
>>>> especially benefit USB-UMASS devices, where the console output should
>>>> be less noisy.  It might even make more devices work out-of-the-box.
>>> While this patch is working fine with my USB/FW HDD enclosure, it breaks
>>> my MP3 USB stick
>>> kernel: umass0: <Samsung YP-U2, class 0/0, rev 2.00/10.01, addr 8> on uhub5
>>> kernel: umass0: BBB reset failed, IOERROR
>>> kernel: umass0: BBB bulk-in clear stall failed, IOERROR
>>> kernel: umass0: BBB bulk-out clear stall failed, IOERROR
>> Is this a regression of something that works without the patch, or is
>> it something that has never worked?  What happens if you use the
>> NO_INQUIRY_EVPD quirk instead?
> 
> Ok, I played around a bit and with your patch applied, I have to
> *remove* the quirk for my Samsung device, then it starts attaching
> again. That's a good thing, right? :)
> 
> umass0: <Samsung YP-U2, class 0/0, rev 2.00/10.01, addr 2> on uhub3
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <Samsung YP-U2 0100> Removable Direct Access SCSI-4 device 
> da0: 40.000MB/s transfers
> da0: 999MB (511616 2048 byte sectors: 64H 32S/T 249C)
> 
> There are only two other devices right now, that require a SHUTTLE_INIT
> quirk, perhaps they are broken by your patch, too. 
> 
> Btw, why are there devices in umass.c with NO_QUIRKS set? Shouldn't
> those entries be removed?
> 
> Cheers,
> Ulrich Spoerlein

So where does this stand?  Is my patch still a regression for you?

Scott