Alan Stern wrote: > On Mon, 16 Apr 2012, Norman Diamond wrote: >> Alan Stern wrote: >>> On Fri, 13 Apr 2012, Norman Diamond wrote: >>>> You THOUGHT you knew in advance that a particular bridge is known to have the overreporting but, where in fact in some secret revisions it doesn't and in some secret revisions we're not quite sure, missing a log and missing a test sample for further testing. How can we be sure that other bridge manufacturers don't also make secret revisions? >>> >>> In fact we don't know. But that's not a good enough reason to risk breaking existing systems. When we encounter bridges whose behavior has changed, we can update the quirk entries. >> >> That's not a good enough reason to cause known breakage in newer existing systems, but I agree that updating the quirk entries helps solve it. >> >>> (Even that isn't as cautious as I'd like. If the device behavior has changed then maybe the old devices won't handle reading beyond the end of the drive. But I can't think of anything safer.) >> >> Well, if the reported capacity isn't a multiple of 63 and if no existing partition includes the last reported block then it seems comparatively safe to decrement the reported size, but as you pointed out, we can't really be sure what the existing partitions are (non-DOS tables etc.). But a multiple of 63 still seems like a relatively safe heuristic, comparatively speaking. But not always, as you pointed out, and as I'll detail below. > > At this point I'm not sure what you want to do. Would you like the quirks entry for your bridge changed to CAPACITY_HEURISTICS instead of FIX_CAPACITY? That's the easiest thing to do quickly. Come on, the purpose of our discussion should be to figure out what is best to do, not what I want. I agree that an easy quick change looks like it will help a bit, but we should still figure out the best change too. Yes it does look like changing this bridge to CAPACITY_HEURISTICS from FIX_CAPACITY is likely to help a bit. I think that heuristics should also accept multiples of 63 even if the total is odd. This doesn't solve everything but will probably help more. I think that handling of FIX_CAPACITY should check for multiples of 63 and report the apparent likelihood that FIX_CAPACITY probably wasn't the right setting for the bridge (if it's a bridge). This doesn't solve everything but will probably help more. The addition of TEST_CAPACITY doesn't solve everything but will probably help more. -- 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
