On Wed, Apr 30, 2014 at 03:41:48PM -0400, Alan Stern wrote: > On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > > > Now say you want to use that gadget driver which is deferred, you unload > > > > first gadget driver and then nothing happens because you have no way to > > > > tell that gadget driver that you want it to bind to the UDC which is now > > > > available. > > > > > > > > see the problem ? > > > > > > This is the sort of thing that could be fixed by creating a "gadget" > > > bus type. The user would be able to force a gadget to bind to a UDC > > > by writing to the appropriate sysfs file. > > > > > > Of course, I suppose you could always implement the same sort of > > > functionality with a special-purpose sysfs file, without going to all > > > the effort of adding a new bus type. > > > > Maybe the bus type is what we need to do, something along the lines of > > i2c_bus_type, perhaps ? > > Maybe -- I don't know how the i2c bus type works. But the general idea > is simple enough: Each UDC automatically gets a child device > (representing controller's external interface to the USB bus, as > opposed to its internal interface to an ordinary bus such as PCI or > platform), and each each gadget driver gets registered as a driver on > the gadget bus. > > Thus, when a UDC driver registers a controller with udc-core, the core > could dynamically allocate a struct usb_udc_device, which would be > little more than a wrapper around a struct device. The core would > register this device on the gadget bus, on behalf of the UDC driver, as > a child of the actual UDC device. Then binding of gadget drivers to > UDCs would be handled in the same way as binding of any other driver to > a device. > > For example, if you had a net2280 card in your computer, the net2280 > driver would bind to the card's PCI device, and udc-core would create a > corresponding usb_gadget device, with a name like "udc-1" -- the full > path would be something like > > /sys/devices/pci0000:00/0000:00:1e.0/0000:01:00.0/udc-1 > > where 0000:01:00.0 is the PCI device corresponding to the net2280 card. > > When a gadget driver registers itself with udc-core, the core would add > the usb_gadget_driver structure to the gadget bus. Then the ordinary > device core mechanism would try to probe each unbound usb_udc_device > with the new gadget driver. This automatic binding might not be what > you want, especially if you have multiple device controllers in the > system or multiple gadget drivers built into the kernel, but the user > could always change the bindings by writing to sysfs files. > > > The difficulty will be with matching a gadget driver to a particular > > UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to > > dummy ? > > The automatic binding could easily get annoying, but we could disable > it (perhaps by adding a special flag to the bus_type structure). > > At any rate, let's say the dwc3 UDC is registered as > /sys/bus/gadget/devices/udc-1 and the dummy UDC is registered as > /sys/bus/gadget/devices/udc-2. Then you could set up the bindings you > want by doing: > > echo udc-1 >/sys/bus/gadget/drivers/g_zero/bind > echo udc-2 >/sys/bus/gadget/drivers/g_mass_storage/bind > > > Or maybe we load gadgets to the bus and always bind through configfs ?!? > > Maybe. That certainly would be more suitable if the gadget driver > needs to be configured specially for the UDC when it binds. sounds good. Too bad GSoC is gone, this would've been a great way to get someone working on the gadget framework :-) Maybe next year... > > dunno, anyway back to Tracepoints... > > Are tracepoints really a good way to dump all the data structures > associated with a driver? I thought they were meant more for > monitoring particular events as they occur. Zhang never wanted to dump *all* data structures just some of their addresses. I'm augmenting that with tracing events (reset, resume, link state change, transfer not ready, etc) as they occur. Trace then allows us to enable each one of these events on demand, which is pretty neat. I'll also add a trace event for register accesses which can *really* help with odd cases (e.g. hibernation) which are very hard to implement and debug. It can also serve as a good way of comunicating with RTL Engineers as they wouldn't really understand anything higher level than a sequence of register accesses. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
