Hi, On Fri, Nov 30, 2012 at 04:24:43PM +0100, Sebastian Andrzej Siewior wrote: > On 11/30/2012 03:46 PM, Felipe Balbi wrote: > >Hi, > > Hi, > > >On Thu, Nov 29, 2012 at 05:43:21PM +0100, Sebastian Andrzej Siewior wrote: > >>|# modprobe dummy_hcd num=2 > >> > >>|# find /sys/kernel/config/ -ls > >> > >>| 557 0 drwxr-xr-x 3 root root 0 Nov 29 17:26 /sys/kernel/config/ > >>| 558 0 drwxr-xr-x 5 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget > >>| 561 0 drwxr-xr-x 4 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget/udcs > >>| 569 0 drwxr-xr-x 2 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget/udcs/dummy_udc.1 > >>| 568 0 drwxr-xr-x 2 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget/udcs/dummy_udc.0 > >>| 560 0 drwxr-xr-x 2 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget/gadgets > >>| 559 0 drwxr-xr-x 2 root root 0 Nov 29 17:26 /sys/kernel/config/usb_gadget/functions > >> > >>| # lsmod > >>| Module Size Used by > >>| dummy_hcd 20287 0 > >>| udc 10219 1 dummy_hcd > >> > >>|# mkdir /sys/kernel/config/usb_gadget/functions/acm.one > > > >I dont think this is enough. It doesn't cope with multiple > >usb configurations. > > > >Or is this just to show how we could probe functions to the framework > >before even binding them to a UDC ??? > > exactly. So you add functions and configure them and you don't have yet > configs. So for configs you need: > > /sys/kernel/config/usb_gadget/gadgets/# mkdir oha > /sys/kernel/config/usb_gadget/gadgets/oha# find > . > ./iSerialNumber > ./iProduct > ./iManufacturer > ./bcdUSB > ./idProduct > ./idVendor > ./bMaxPacketSize0 > ./bDeviceProtocol > ./bDeviceSubClass > ./bDeviceClass > /sys/kernel/config/usb_gadget/gadgets/oha# echo blah > iProduct > /sys/kernel/config/usb_gadget/gadgets/oha# cat iProduct > blah > /sys/kernel/config/usb_gadget/gadgets/oha# mkdir config1 correct. > "oha" is just your gadget. After mkdif config1 you should symlink your > function from /sys/kernel/config/usb_gadget/functions/acm.ttyS0 or what > ever. fair enough. > >Anyway, what I wanted to see was something like: > > > ># mkdir -p /sys/kernel/config/usb_gadget/dwc3.0/gadget0/config0 \ > > /sys/kernel/config/usb_gadget/dwc3.0/gadget0/config1 > > I don't like to put the gadget0 under dwc3.0. What I had in mind was > > ln -sv /sys/kernel/config/usb_gadget/udcs/dwc3.0 > /sys/kernel/config/usb_gadget/gadgets/oha > > so you have a symlink pointing from dwc3.0 to you current active gadget. > > We could have them under the UDC but this way it is easier to move one > gadget from one UDC to another. ahah, now I see your point. Indeed it looks better. > ># echo acm.2,obex.3,msc> \ > > /sys/kernel/config/usb_gadget/dwc3.0/gadget0/config0/functions > > > ># echo ffs,sourcesink> \ > > /sys/kernel/config/usb_gadget/dwc3.0/gadget0/config1/functions > > what is wrong with having the functions within a function folder > configuration? I may things to change like MAC addr or lun or what > ever. I wouldn't let them pop all in one folder. Therefore I suggest to > mkdir the functions. how do you see interfaces showing up in configfs ? How have you thought about it ? /sys/.../usb_gadget/udcs/dwc3.0/config0/f_mass_storage/intf[01] ??? > >Then when you echo the function name to the functions file under the > >configuration, if the function isn't registered, then a try_module_get() > >will tell udev to load it and increment the usage counter. Also, it will > >create files and other directories for every part of the every > >descriptor, but, of course, only strings will be writable, everything > >else is read-only. > > > >This means that the following should allocate and expose a device > >descriptor: > > > ># mkdir /sys/kernel/config/usb_gadget/dwc3.0/gadget.0/ > ># ls /sys/kernel/config/usb_gadget/dwc3.0/gadget.0/ > > > >bLength bDescriptorType bcdUSB > >bDeviceClass bDeviceSubClass bDeviceProtocol > >bMaxPacketSize0 idVendor idProduct > >bcdDevice iManufacturer iProduct > >iSerialNumber bNumConfigurations > > > >likewise the following would allocate and expose a configuration > >descriptor: > > > ># mkdir /sys/kernel/config/usb_gadget/dwc3.0/gadget.0/config0/ > ># ls /sys/kernel/config/usb_gadget/dwc3.0/gadget.0/config0/ > > > > > >bLength bDescriptorType wTotalLength > >bNumInterfaces bConfigurationValue iConfiguration > >bmAttributes bMaxPower > > that is almost what I'm doing right now. almost means different hiarchy > and without the name propwerty. > > >When we echo "function0,function1,...,functionN"> functions file, that > >would create one intf%d directory for each of functions interfaces (in > >order) and one ep$addr directory for each endpoint. > > except for the explicit functions file, I would put directory names for > it. And I would put the explicit interface folder below the function so > we know where it belongs. I see. The problem I have with that is that it's not a USB thing. I'd like to have our configfs interface to mimic the structure of our descriptors as much as possible, so it's easy to correlate. > >Does that make sense to you ??? > > This is mostly what I have so far. > /sys/kernel/config/usb_gadget/udcs/dwc3/ <- pops after modprobe > /sys/kernel/config/usb_gadget/functions/acm.ttyS0/ <- mkdir() instance 0 > /sys/kernel/config/usb_gadget/functions/acm.ttyS1/ <- mkdir() instance 1 > /sys/kernel/config/usb_gadget/gadgets/oha/config.1/ < mkdir() config, > bConfigurationValue 1 > > and in /sys/kernel/config/usb_gadget/gadgets/oha/config.1/ I would a > symlink to /sys/kernel/config/usb_gadget/functions/acm.ttyS0/ > > and in /sys/kernel/config/usb_gadget/udcs/dwc3/ I would add a symlink > to /sys/kernel/config/usb_gadget/gadgets/oha/ > > >It would remove the need to even create > >a functions/$function.$num directory for everybody before being able to > > Please don't mixup the $num with the number of possible functions. > Usually you don't have a limit of many functions you can add. For ACM > there is a hard limit of 4 or 8 or something but that is a different > story. > >use the function. The way you've setup configfs it means that if I'm > >going to use ACM on multiple configurations or even multiple gadgets, I > >will have to know how many of them I will need before hand. > > No. For ACM I plan to have a high upper limit and hide this detail from > you. You only will read a "portnum" file which is RO and says which > port it is so you know which /dev/ttyGSx matches that function. ok good. Makes sense. > >With my approach, however, we could allocate ACM instances on a > >per-configuration/per-gadget basis. The only problem with that is the > >damn struct tty_driver. Maybe we initialize ACM with e.g. 32 ports > >always or we request Greg KH/Alan Cox to help out with ideas for TTY > >dynamic port allocation. > > No, that is actually fine I guess. I would go for a hard limit of lets > say 32ports. That is enough. One instance eats 2xIN ep (bulk, intr) and > 1x out. So with 8 ACM ports you need 16 IN-EPs and that is a USB limit > here you hit. So if we reserve 32 ports we could serve 4 UDCs with > nothing more but serial ports. good enough for the next 10 years I guess :-p > For SS I could imagine to use stream support so we could serve 20ttys > with only 3 endpoints :) yeah. > >Comments ? > > As I said, everything is fully dynamic. The only difference I see here > the hierarchy. Should we separate everything in three folders like I > have now (udcs, functions, gadgets) and symlink pre-configured > functions or not. > > I like the separate folders way because: > - you can unlink the gadget from one udc and link to another > - you can one replace one configured functions with another i.e. unlink > the ACM instance and link NCM instance. All configuration remans as > it. I see the point now. I'm just concerned with the extra functions/ directory under the gadget directory since that's not really a USB thing, but OTOH, neither is the "gadget", so maybe it's something we can live with. The idea of linking/unlinking pre-configured functions does sound very, very nice. -- balbi
Attachment:
signature.asc
Description: Digital signature
