On Thursday, April 11, 2013 5:00 PM Alan Stern wrote: > On Thu, 11 Apr 2013, Andrzej Pietrasiewicz wrote: > > > This adds a new sysfs root device to serve as a replacement for > > devices which are available only when a gadget is being bound. > > > > It is motivated by adding configfs support to USB Ethernet functions. > > When configfs is there, we would like to be able to mkdir some > > function directory, e.g.: > > > > $ mkdir functions/ecm.usb0 > > > > and have the usb0 available in the system (albeit in an unconfigured, > > or default state) at this very point, which is _way_ before the gadget > > What do you mean by "available in the system"?
I mean that it is registered with register_netdev. So if $ ifconfig -a is issued we get e.g. usb0 Link encap:Ethernet HWaddr 12:f3:12:23:c3:e7 (...) > > > is actually bound. However, this poses a chicken and egg problem. > > In order for the interface to appear in the system, it needs to be > > What interface are you talking about? Is it a USB interface, a network > interface, a programming interface, a user interface, or some other sort > of interface? > The usb0 from the example above. > > registered with register_netdev. But in order to register it, its > > parent device must be known and it becomes known only later during > > gadget's bind. > > Why must this happen before the gadget driver is bound? What can't it > happen after the driver is bound and before the gadget is connected to a > host? > I am not sure if I understand you well, but bounding the driver happens after the gadget is connected to a host, not the other way round. That is, the USB device is enumerated, configuration is selected, functions (e.g. f_ncm) are bound to USB. Only at this moment is the parent device known in the g_ncm.ko. Discoverability is one of the key ideas of configfs, this is what Joel Becker, configfs' author says. So once userspace creates the ncm.usb0 function, it wants to know what will be the interface name associated with it. The only way to know it is to have the network device registered with register_netdev and this requires providing the parent device. > > This patch adds a /sys/devices/usb_gadget root device, which is > > registered during module_init of libcomposite, so it is available at > > any time for all libcomposite users and is used as a parent device for > > USB Ethernet devices instead of the gadget->dev. > > I can't understand the reasoning here. It's like saying I should be able > to configure the network settings for my ethernet controller before the > e100 driver is bound to it. > I think the analogy is incorrect. The equivalent of e100 driver is the f_ncm driver which is loaded at the very moment the ncm.usb0 directory is created. The binding I am talking about refers to "connecting" the f_ncm to the underlying transport infrastructure, which is USB and it looks to me more like plugging an Ethernet cable to a socket in a network card. > Are you sure this is necessary? I assume you are questioning the changing of the parent device of the network device. In order to achieve the goals stated above I think it is necessary, because the network device needs to have a parent device and I am not sure if net core allows setting it later, after the device is registered. > > Alan Stern Andrzej -- 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
