Re: Retirement of CAM_QUIRK_NOSERIAL

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
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.