On Wed, Jun 29, 2011 at 8:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > >> > if we >> > > remove the #ifdef above we also need to update the gadget drivers to >> > provide >> > > HS descriptors without stipulating their addition on the >> > > gadget_is_dual_speed(). > > No we don't. At the time a gadget driver is compiled, if it is known > that the available UDCs don't support high-speed operation, there's no > reason for the gadget driver to include high-speed descriptors. ... but we can tag such descriptors __initdata. No? > >> > > The above seems to me like the complete solution. > > CONFIG_USB_GADGET_DUALSPEED is present so that gadget drivers can > conserve space by omitting descriptors if it is known they will never > be used. This has very little to do with max_speed. Again __initdata ? > >> > Perhaps gadget drivers should rely on the 'is_dualspeed' flag provided >> > by the UDC ? >> >> You're right. Actually there is a comment in the implementation of gadget_is_dualspeed() that sais that "run time test should check g->is_dualspeed" although right now the return value from that function is according to #ifdef CONFIG_USB_GADGET_DUALSPEED. So what needs to be modified is the gadget_is_dualspeed() function and not the gadget drivers. > > No, gadget drivers shouldn't need to look at is_dualspeed, except > perhaps if they want to avoid sending device-qualifier and other-speed > descriptors to the host in situations where the current UDC hardware > doesn't support high-speed operation. IMHO having to send device-qualifier and other-speed descriptors does sound pointless if the underlying UDC doesn't provide relevant support. Regards, Jassi -- 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
