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
"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.
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.
# 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.
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.
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.
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.
For SS I could imagine to use stream support so we could serve 20ttys
with only 3 endpoints :)
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.
Sebastian
--
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
