Re: [RFC v3][PATCH 1/2] usb: gadget: Add USB Functions Gadget

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

 



On 10/23/2012 08:54 AM, Felipe Balbi wrote:
Hi,

Hi,

On Mon, Oct 22, 2012 at 04:26:35PM +0200, Sebastian Andrzej Siewior wrote:
after a mkdir config0 you should allocate a struct usb_configuration for this.

|                +->function0
|                    + name (=>  ether)

Here I am not sure if we should name it function0 and have name property
or just put the name of the the directory into usb_get_function() and
request that functions.
I am also not sure if the order of the functions is important. *I* think
that it does not matter if we first expose the serial function and then
the mass storage and next time the other way around. Other opinions?

I don't it should matter, what matters though is which configuration we
expose first.

good.

   What I had in mind was:
   - create a copy of each descriptor. Each descriptor should have a name
     or something different that can be used as an unique identifier.
   - after the copy has been done, the function can request the copy by
     the name and update some fields like the endpoint number in case of
     an endpoint descriptor.
   - configfs could also allow to edit some fields here like the string.

note that the string is a separate descriptor :-) configfs should allow
for a string descriptor to be linked to e.g. the iManufacturer field of
a device descriptor. Maybe a symlink is enough ?

Yes we have two pieces: the id entry in the config/device descriptor
like iSerial or iFunction and the matching entry in struct usb_string.
The id doesn't matter at all so this can be hidden from the user. What
remains is the string entry. Now that I read symlink, this sounds
great. We could have several languages however, we use only one right
now. That means, having something like

/cfg/FancyGadget/Strings
                 +
                 + funcname (identifier)
                       + 0x409
                           + val (mass storage)
                       + 0x40B
                           + val (massamuisti)
                       + 0x416
                           + val (armazenamento de massa)


So now we could symlink iInterface to funcname. So if we do have two
configs, we would end up with one string and so if we want to change
the string we don't have to do it for each config but only once.
I'm not sure if it is clever to have a folder for language id with only
one property val which contains the string. So we could have
/cfg/FancyGadget/Strings/funcname

which is a file and lang_id<blank>value so we would have:

0x409 mass storage
0x40B massamuisti
0x416 armazenamento de massa

and echo "0x409" >> funcname
would remove the entry for langid x0409.

So I like the symlink idea, just not sure about the interface here :)

   - each gadget provides now two sometimes three copies of those
     descriptors. To make things simpler the gadget could provide only
     set of descriptors (for instance only SS) and composite would create
     HS and FS from it if desired.

I don't think that will work. Think about isochronous and interrupt
endpoints where wMaxPacketSize can be whatever we want. I'd rather
allocate 3 sets of descriptors :-s

I've been looking at those. 99% of them are the same. Look at SS
descriptors of mass storage for instance. Now remove the companion
descriptors make wMaxPaketSize max value for the speed and you have HS.
Make the wMaxPacketSize smaller (or wait this is done by the "core"
during allocation) and you have FS.
Interrupt endpoints have an interval for instance. This is always the
same value in "seconds" but the value is different between FS and HS.
This is true for all gadgets except for WebCam (the interval here is
larger on HS than on FS not sure if this is by accident).
wMaxPacketSize is always the same on SS/FS/HS.
Isochronos is a little different they probably remain as-it. Here you
could have descriptors which describe the Video resolution which is
available on HS but on FS.

However we could remove some descriptors and this should make it
simpler. Look at the IAD descriptor which was missing at SS speed in
ECM. I know we can't do it for each gadget but if you could make it
simpler for most gadgets why not?

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


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

  Powered by Linux