On Mon, 2 Feb 2015, Matthieu CASTET wrote: > Le Mon, 2 Feb 2015 15:39:47 +0200, > Mathias Nyman <mathias.ny...@linux.intel.com> a �crit : > > So apparently there were some devices that started working after the > > 512byte was forced? > > I wasn't involved in this at the time so I don't know the details, perhaps > > Alan remembers? > > > > As the patch says, USB2 specs say HS bulk endpoints only supports 512 bytes > > max packet size. > > > > USB2 spec section 5.8.3 Bulk Transfer Packet Size Constraints: > > > > "All Host Controllers are required to have support for 8-, 16-, 32-, and > > 64-byte maximum packet sizes for > > full-speed bulk endpoints and 512 bytes for high-speed bulk endpoints. No > > Host Controller is required to > > support larger or smaller maximum packet sizes." > > > > Or maybe that can be interpreted as 8-, 16-, 32-, 64, AND 512 bytes > > supported for HS bulk endpoints?
I don't think so, but I agree the spec could have been more clear about this. > > I'm otherwise ok with adding the other max packet sizes as well, just > > worried about the original patch. > > Are we going to break something that the original patch once fixed > > > > -Mathias > > If ehci driver allows to support others sizes, there may have some > devices that use it for HS. There are some examples. In all the cases I know about, the bogus maxpacket size doesn't matter because the device never sends or receives a message on that endpoint requiring more than one packet. > Do you know if the windows driver allows this ? > > Looking from ehci driver [1] it seems to be the case. > > > Instead of forbid value smaller than 512, can we have a list of > controllers that can't handle it and make it works on others ? That's not a bad idea. If we can create such a list somehow... > Does windows xhci driver allow value different of 512 for HS ? Kazimierz says that the driver in Windows 7 does not allow it. So perhaps it doesn't matter much what we do in Linux. Regarding the e4f47e3675e6 commit ( USB: xHCI: override bogus bulk wMaxPacketSize values), it's hard to say exactly what happened. The patch allowed a device to work, but the device had its bulk maxpacket values set to 8! I don't know if the device's descriptors were simply wrong, or if the user's xHCI controller was unable to handle a maxpacket size different from 512. However, if we change the driver now, that user's device is likely to stop working, which would be a regression. On the whole, I think the best approach is to redesign Kazimierz's device. Changing the endpoints in question from bulk to interrupt could help, for example. Unless he wants to continue producing devices that won't work under Windows 7... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
