On Tue, 6 Jun 2017, Felipe Balbi wrote: > Hi, > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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.balbi@xxxxxxxxxxxxxxx> > > > > 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? Well, it wasn't a layering violation back in the days of the original gadget stack. But the design has changed over time, and I take your point. Currently, dummy_hcd uses the following fields from the gadget driver structure: the disconnect, suspend, resume, and setup callbacks, and the max_speed and function values (the last is only for a sysfs entry). It seems reasonable to move all these things into the UDC core. 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
