Re: [RFC v2] usb/gadget: the start of the configfs interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Nov 30, 2012 at 04:07:22PM +0100, Michal Nazarewicz wrote:
> On Fri, Nov 30 2012, Felipe Balbi wrote:
> > 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 ???
> 
> This loads function without even creating a gadget.  This would allow
> the same function to be used in several different gadgets.

why would you load a function before it's actually needed ? We could end
up with users who will just load the function and never actually need
them which will consume memory for no reason.

> > 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
> >
> > # 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
> 
> I think that the idea expressed here was so far to use (symbolic) links
> to bind functions to configurations.

I understood that much, thank you ;-)

> > 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/
> 
> Again, so far it seems everyone on the list thought to rather link
> a gadget to UDC via symlinking and keep UDCs and gadgets in separate
> directories.
> 
> > Does that make sense to you ??? It would remove the need to even
> > create a functions/$function.$num directory for everybody before being
> > able to 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.
> 
> Not necessarily.  If you are not interested in sharing functions between
> gadgets, all you have to do is use unique prefix for the functions, for

how do you know how many tty ports u_serial needs to create beforehand ?
You just don't know... Granted, my approach will have the same
limitation.

But anyway, the point is that sharing functions can be a bit dangerous I
guess. We need to have separate instances for each user IMHO. What if
you have a system with 2 UDCs then you link the same acm.blah-0 to both
UDCs and try to transfer on both of them at the same time ?

If you have separate instances that wouldn't be an issue at all.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux