On Wed, 11 Apr 2012, Norman Diamond wrote: > > It sounds like you are suggesting that we have a new quirk, > > something like TEST_CAPACITY.� When this quirk is present, we could > > attempt to read the last block when the drive (or media) is first > > detected, thereby determining whether the reported capacity needs > > to be adjusted. > > Yes, that is what I've been suggesting for a while. But at this > moment I might have a better suggestion, discussed below. Or it > might be better to combine the two ideas. > > > The existing FIX_CAPACITY and CAPACITY_HEURISTICS quirk entries > > could be changed to TEST_CAPACITY as people report the results of > > their testing.� However this would be a very slow process. > > FIX_CAPACITY will still be necessary in cases where a bridge is known > to have both problems, always overreporting and crashing when tested > for overreporting. I think these cases will be a small minority > though. Your naive faith in the high quality of the firmware in low-cost consumer electronic devices is touching, but sadly misplaced. Besides, your initial conclusion is wrong. FIX_CAPACITY will apply well in cases where a bridge is known to have the overreporting bug. Even if the bridge doesn't crash when asked to read beyond the end of the drive, there's no reason to do such a test if we know in advance what the answer will be. The only real reason for the new TEST_CAPACITY flag would be to handle cases where some devices get the capacity wrong and others with the same IDs get it right. This means that initially only two quirk entries would require the TEST_CAPACITY flag: the one for your device and the single entry that currently uses CAPACITY_HEURISTICS. > Now, I think that most of the existing FIX_CAPACITY cases probably > should be changed to CAPACITY_HEURISTICS. This will be simpler and > quicker, though not maximally accurate by itself. Definitely NOT! One of the most important rules we have in kernel development is that we do not break existing systems. It is known that there are devices which overreport and for which the actual number of blocks is odd; we cannot take the chance of changing any existing entries without positive evidence that it is safe to do so. > In drivers/scsi/sd.c, fix_capacity always causes a decrement but > guess_capacity guesses an even number. > > So one thing to do for the Prolific bridge in unusual_devs.h is to > use US_FL_CAPACITY_HEURISTICS instead of US_FL_FIX_CAPACITY. Not all disks have an even number of blocks. That heuristic really isn't a very good one -- its only benefit is that it works okay for the one case where it is currently used. > I also think that if the reported capacity is a multiple of 63 then > it is very likely to be accurate and should not be decremented. > Furthermore if the capacity is a multiple of 126 (i.e. even as in the > current heuristic, and a multiple of 63) then US_FL_FIX_CAPACITY is > almost certainly wrong. Of course that 63 is artificial but it is > very common and the reason is well known. You seem to be ignoring the fact that we aren't just talking about USB-(S)ATA bridges. The same driver also handles things like flash drives and card readers. For example, I just plugged in my music player. It has both an internal flash memory and a memory card slot, and it reports their capacities correctly. But the flash memory has 7683072 blocks and the memory card has 3842048 blocks; neither of these numbers is divisible by 63. Therefore relying on it isn't particularly safe. Alan Stern -- 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
