Hi, Alan Stern <st...@rowland.harvard.edu> writes: > On Tue, 6 Jun 2017, Felipe Balbi wrote: > >> Sometimes, the gadget driver we want to run has max_speed lower than >> what the UDC supports. In such situations, UDC might want to make sure >> we don't try to connect on speeds not supported by the gadget >> driver (e.g. super-speed capable dwc3 with high-speed capable g_midi) >> because that will just fail. >> >> In order to make sure this situation never happens, we introduce a new >> optional ->udc_set_speed() method which can be implemented by >> interested UDC drivers. >> >> Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com> > > dummy-hcd already checks for this in its dummy_pullup() routine. > Should other UDC drivers copy this approach?
sounds like a layer violation to me :-s You're basically relying on the fact the the UDC (dummy, dwc3, chipidea, musb, etc) have access to a pointer to the usb_gadget_driver currently running. If that changes - and it's not too farfectched of a change, since UDC doesn't need to know which gadget driver is running - dummy may break. I would rather patch dummy a bit to implement ->udc_set_speed(). What do you think? -- balbi -- 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
