Re: [PATCH] storage: Widen bcdDevice range for SanDisk SDDR-31 quirk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 7 Jun 2018, Alan Stern wrote:
> On Thu, 7 Jun 2018, Mark Knibbs wrote:
> > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> > was only applied for bcdDevice 0x0009 but later firmware needs it too.
> >
> > The later firmware has bcdDevice 0x0022. On the assumption that any even
> > later firmware (if it exists) has the same problem I have widened the
> > bcdDevice range to 0x0000 to 0x00FF. (That would allow a patched firmware
> > which doesn't have the bug to use e.g. bcdDevice 0x0122.)
>
> That's not a very convincing argument. Either assume that all future devices
> will need the quirk, or don't make any assumptions and just bump the range up
> to 0x0022. In any case, there's no good reason for selecting 0x00FF as a
> cut-off point. We don't have any control over what bcdDevice values the vendor
> assigns to its firmwares. If they do go to the trouble of fixing the READ
> CAPACITY bug, what makes you think they would change the bcdDevice value to 
> something above 0x0100? Finally, 0x00FF is not a valid bcdDevice value. These
> are binary-coded decimal numbers, ranging up to 0x9999. (I know we have a bunch
> of entries set to 0xFFFF; they aren't valid either but at least they make a
> clear point.) So, I would accept a patch where the upper limit was set to any
> of 0x0022, 0x9999, or 0xFFFF. But 0x00FF just seems weird.

The SDDR-31 is long-discontinued and no longer supported by SanDisk. Given that
both known firmware versions have the READ CAPACITY bug, it's very unlikely any
fixed official firmware exists. But if it does, its bcdDevice value would
probably be 0x0099 or less.

I chose 0x00FF as upper value rather than 0x9999/0xFFFF because it should be
feasible to modify the 0x0022 firmware to fix that bug. 0x00FF would allow
the modified firmware to report e.g. 0x0122, so the quirk would not be
misapplied to it. (And 0x00FF instead of 0x0099 because devices which
report non-BCD values for bcdDevice exist.)

I'll re-send the patch with upper value 0x0022 then.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux