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? 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. > > > 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. 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
