On Wed, 17 Apr 2013, Andrzej Pietrasiewicz wrote: > 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 ... > 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. It doesn't have to be. You don't actually have to change the address when the attribute is written. In fact, since the network link doesn't exist at this point, there _is_ no address to change. > 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 you still want to persist with this approach, you can do it in a way that doesn't require the network interface to be registered before the gadget is bound. Simply store the strings written to host_addr and dev_addr. Don't try to do anything with them -- in particular, don't try to change the addresses associated with a nonexistent network interface. Then later on, when the gadget is bound and you have registered the network interface, set the address values that were saved earlier. (Of course, when you do this you'll be racing with udev and NetworkManager, which will try to set their own values for the network addresses. That's the price you pay for following this peculiar approach.) 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
