Cc: Adrian Bunk <bunk@...>, Adrian Bunk <bunk@...>, Greg KH <gregkh@...>, Andrew Morton <akpm@...>, Kernel development list <linux-kernel@...>, USB development list <linux-usb-devel@...>, Oliver Neukum <oneukum@...>, Matthew Dharm <mdharm-usb@...>
I don't just suspect -- I know for a fact that we do. Partly because
of laziness and partly because of not being able to verify that an
entry is no longer needed.
In general I agree. However there are some problems for which nobody
has been able to come up with another solution. See below.
Yes, none of those USB_QUIRK_NO_AUTOSUSPEND entries are needed any
more. They can all be removed and handed over to the HAL people as a
starting point.
You have concentrated your attention on the list for usb-storage,
but the usbhid driver also has an impressively long quirks list.
That's true now, but it wasn't always. Until the last year or so,
cdrecord wouldn't work properly with USB CD drives having a 64-sector
limit unless the user added a particular command-line argument.
In fact, setting max_sectors down to 64 is probably overkill -- 120
ought to be enough. But there may have been one or two oddball devices
that really did have a 32-KB limit, and better safe than sorry. At one
point an engineer from Genesys said their devices did, although they do
seem to work perfectly well with 64-KB transfers (and that's what
Windows gives them).
Windows does indeed ignore the residue field, as far as I can tell.
But this is a rather tricky thing. The USB mass-storage spec
specifically says that one way a device can signal a short transfer is
to pad the data with 0s to the requested length and then set the
residue to indicate how much of the data is valid. If we ignore the
residue then we run a risk of misinterpreting the 0s as valid data.
Now in practice this doesn't matter much because short transfers of
block data (READ_10) generally involve other errors that would show up
anyway, and for non-block data (MODE SENSE) the padding probably
wouldn't matter. Still it seems like a dangerous sort of thing to do,
which is why I have resisted it.
(And by the way, there _definitely_ are devices which use this
signalling method. In fact, Linux contains a driver that does it.)
This is another hard case. No, we aren't doing anything wrong. If
there are any patterns we haven't seen, we aren't aware of them. :-)
You might think that if a device claims to have an odd number of
sectors then it must be wrong, but this turns out not to be true.
Why doesn't Windows need this? For all we know, it does. Has anybody
ever tried forcing Windows to read the sector beyond the end of one of
these buggy devices?
For one reason or another, Linux supports filesystems/partitioning
schemes which do need to access the last sector (EFI GUID, md, maybe
others). Some devices are so buggy that trying to read the nonexistent
"last" sector causes them to lock up, requiring a power cycle.
Obviously we can't probe for this sort of behavior. (There was one
report of a device which _could_ read its last sector correctly, but
only if the transfer was exactly 1 sector long! Attempts to read two
sectors starting from the second-to-last sector would cause it to
crash.)
There's a straightforward solution: Never try to use the last sector --
in effect, assume every device has the FIX_CAPACITY flag set. Doing
this universally could cause data loss, however, so again I have been
opposed to it.
This is almost certainly a case where lots of the entries are no longer
needed. But it isn't easy to tell which ones can safely be removed.
The problem here isn't that the device reports impossible values --
what happens is that it responds to commands for any LUN, causing the
kernel to think it is really multiple devices.
This will work in some cases, but not in others. In particular, it
won't work when the values have to known at device-detection time.
Once the sysfs files have been set up and the user can put in the
correct values, it's already too late.
Still, I agree that we can get rid of MAX_SECTORS_64. Similarly,
FIX_INQUIRY shouldn't be needed, since any device which does need it
would fail to work under Windows. However the really popular flags are
the ones which would be hardest to remove.
Alan Stern
-
