On Fri, 14 Oct 2011, Felipe Balbi wrote: > On Thu, Oct 13, 2011 at 09:42:40PM -0400, Alan Stern wrote: > > On Thu, 13 Oct 2011, Paul Zimmerman wrote: > > > > > The latest USB-IF CV tester checks for a valid length for this > > > request. > > > > That's dumb. The BOT spec doesn't say anything about what a device > > should do if it receives a request with wLength > 1. Therefore it's > > wrong to say that a device is non-compliant with the spec if it replies > > to such requests. > > > > If anything, this should be a test of the host, not of the device. > > After all, it's the host's fault if wLength is set to the wrong value. > > > > Instead of changing this, I'd prefer to complain to the USB-IF. > > It's the same with SetAddress command. A SetAddress() on Configured > state has unspecified answer, nevertheless USB-IF is very, very bad at > changing those Command Verifier tools and every time I have tried > reporting a bug (either on Windows Stack or Command Verifier Stack) they > always reply with the same stock answer: "Other devices have passed > certification on the same setup, so why can't you?" > > That means the USB Certified sticker has nothing to do with being > compliant with the Spec, rather being compliant with Windows. > > On top of all that, if we don't apply this there will be a big number of > Linux devices which will have to keep this patch on their own out of > tree queue just to pass certification. > > Do we want that ? I think it's far better to apply this patch, but mark > it as host-side quirk or something. The host stack has quirks for > out-of-spec devices, why can't the device stack have quirk for > out-of-spec hosts ? All right, I withdraw any objection to the patch. However, I'd like to point out that this isn't a quirk for out-of-spec hosts; the existing code already works perfectly well with hosts that send these out-of-spec requests. Rather, it's a quirk for an out-of-spec CV test. 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
