On Tue, Jan 11, 2011 at 9:33 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 11 Jan 2011, Matthieu CASTET wrote: > >> Hi, >> >> Any news/comments on this ? >> >> With effort to make generic arm kernel >> (https://wiki.ubuntu.com/Specs/ARMSingleKernel) this could be really useful. >> >> Also it could be usefull on x86 to support more than one pci udc driver. That would be a good idea to me. We shouldn't introduce the limit of having only one UDC, even if this is true on most platforms. Also please take care of possible mutliple OTG tranceivers that are likely attached to these UDCs. >> >> Matthieu >> >> Matthieu CASTET a Ãcrit : >> > Hello, >> > >> > I seems there no work on UDC Class anymore. So I repost my multi udc patch. >> > >> > >> > Even if the usb gadget framework is limited to work with one driver, it >> > could be useful to have a kernel build with more than driver. >> > This allow to make generic kernel that work with different udc controller. >> > >> > After looking at the current code, the only blocker to do that is >> > usb_gadget_register_driver/usb_gadget_unregister_driver function that >> > are declared in each driver. >> > >> > For avoiding that I propose to do a redirection for these functions. >> > At probe time the driver register them >> > (usb_gadget_register/usb_gadget_unregister), and >> > usb_gadget_register_driver/usb_gadget_unregister_driver call these callback. >> > We pass pass struct *usb_gadget in >> > usb_gadget_register/usb_gadget_unregister for flexibility (we can latter >> > do a more complex dispatcher). >> > >> > the implementation is provided in multi_udc_core.diff. >> > >> > The driver conversion is quite easy and we don't need to port all the >> > driver at one time. >> > >> > multi_udc_driver.diff is port for ci13xxx_udc.c and net2280.c > > It's okay with me. ÂAssuming you make the appropriate changes in all > the other UDCs, of course. > > 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
