Quirk for this?

[Warner Losh]

> I understand what you're saying.  If you look in the umass driver, there
> is already a mechanism for quirks as well as a fairly large collection
> of quirks for bad SCSI protocol behavior from devices.  These should all
> move up to CAM, I agree.  However, what exists in CAM right now for
> XPORT-specific support is just a series of 'if' statements scattered
> around cam_xpt.c.  If you moved Warner's quirk up as well as the other
> umass quirks, you're going to quickly make a royal mess out of
> cam_xpt.c.  That's what I want to avoid.  Once we figure out exactly
> what we want out of the XPORT code and get it a little more defined and
> organized, I think we can then start moving the quirks out of the umass
> driver.  Until then, solving Warner's problem via umass.c is easy and
> doesn't complicate the end goal much at all.

I would think that the quriks in the umass driver would be
communicated in a transport neutral way to cam_xpt.c and friends.  ANY
transport could set ANY quirk and the code would just cope.  No need
for the xpt layer to peer into the transport at all (or is that the
'sim' in CAMese).

For the moment, hacking umass is easiest and when the more generic
mechanism comes along, the minor hack that I'm putting in wouldn't be
burdonsome.

Warner

> Scott
> 
> 
> Matthew Jacob wrote:
> > It may be a property specific to USB devices, but the code affected is
> > a property of the end target at the end of a transport, not the
> > transport itself.
> > 
> > On 2/26/07, Scott Long <scottl at samsco.org> wrote:
> >> Matthew Jacob wrote:
> >> >>
> >> >> I took a look at Linux, and they have a quirk for this.  A bunch of
> >> >> cameras have this bug, as do iPods and a few media readers...
> >> >>
> >> >
> >> > So, is your take then we should have a "subtract by N" read capacity 
> >> quirk?
> >>
> >> If it's just a USB property, I'd like to avoid adding a quirk to the CAM
> >> core, especially one that requires multiple arguments.
> >>
> >> Scott
> >>
> >>
> 
>