On Friday, April 12, 2013 7:58 PM Alan Stern wrote: > On Fri, 12 Apr 2013, Andrzej Pietrasiewicz wrote: > > > > > 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. > > Now I'm confused. You say that function drivers don't get bound until the > host has enumerated the gadget and installed the gadget's configuration. > But if the functions start out being unbound, how can the gadget respond > to a Get-Config-Descriptor request during enumeration? The functions' > descriptors -- in particular, the endpoint descriptors -- have to be known > by that time. How can they be known before the function is bound to USB? > Errr... please disregard this argument. I wanted to say something different. Please see below. > But this is getting off the main topic... > > > 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. > > "Discoverability" is a pretty vague term. Is e100 discoverable? > > If e100 worked the way you describe f_ncm, first you would tell the kernel > to load the e100 driver, and afterward you would tell the kernel which > Ethernet card to bind to e100. In between, how do you find out what > interface name will be associated with this Ethernet card? > Answer: You can't. Not until after the binding is set up. > > Why should f_ncm be any different? > > Suppose for the sake of argument that f_ncm could be bound to several > different types of transport, not just USB. An interface name like "usb0" > would be appropriate only when the driver was bound to a USB transport. > So before the binding takes place, how can f_ncm know what type of > transport will be used and thus what sort of interface name would be > appropriate? > > You could improve the discoverability by providing a readonly configfs > attribute that would contain the interface name _after_ the binding to the > transport is finished and the interface has been registered. But this > shouldn't be necessary; nowadays naming of network interfaces is all > handled by udev anyway. Udev is not mandatory, though. > > > > > 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. > > Surely plugging an Ethernet cable into a socket on a network card is > analagous to plugging a USB cable into a socket on a UDC. There's no > trouble configuring a USB-based network interface before the USB cable is > plugged in. > > > > 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. > > I'm really asking whether it is necessary to provide a network interface > name in configfs before the function driver is bound to a transport. > Actually there is more to it than just the interface name. The procedure of setting a gadget up with configfs is like this: 1) create the gadget directory 2) create functions directories corresponding to functions to be used by the gadget 3) create configurations directories Anytime before 4) below echo some parameters to configfs attributes Why before 4)? Because it would be good if configfs' state reflected the state of the system. A function can be associated with more than one configuration, but once a function is associated with a configuration (symlink), I think it would be desirable for the function's attributes to remain unmodifiable (writing to them results in EBUSY). Otherwise, a function which is in a given state can be associated with one configuration, then the function's state can be changed and the function can be associated with another configuration. 4) create symbolic links in configurations' directories, pointing to appropriate functions' directories 5) In the gadget directory echo <udc_name> > UDC Now, what you suggest is that a net device is registered only at step 5) above. But changing a device address is possible only _after_ the device is registered. Which is in contradiction with the assumptions above. And in practice you would have a directory structure like this: . . . ./functions ./functions/ncm.usb0 ./functions/ncm.usb0/ifname ./functions/ncm.usb0/qmult ./functions/ncm.usb0/host_addr ./functions/ncm.usb0/dev_addr . . . Where ifname, qmult and host_addr can be written to before the gadget is bound, but writing to dev_addr in such a situation would result in ENODEV. If, on the other hand, the net device is registered at the moment of ./functions/ncm.usb0 creation, access to all attributes is consistent. But for this to happen, a parent must be known, and - as it is now - it is not known until the gadget is bound. Hence the patch we are discussing. Andrzej -- 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
