Quirk for this?

[Scott Long]

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.

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