Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> writes:
> On 08/25/2012 12:07 AM, Michal Nazarewicz wrote:
>>> --- a/drivers/usb/gadget/acm_ms.c
>>> +++ b/drivers/usb/gadget/acm_ms.c
>>> @@ -92,12 +92,14 @@ static const struct usb_descriptor_header *otg_desc[] = {
>>>
>>> #define STRING_MANUFACTURER_IDX 0
>>> #define STRING_PRODUCT_IDX 1
>>> +#define STRING_PRODUCT_SERIAL 2
>>>
>>> static char manufacturer[50];
>>>
>>> static struct usb_string strings_dev[] = {
>>> [STRING_MANUFACTURER_IDX].s = manufacturer,
>>> [STRING_PRODUCT_IDX].s = DRIVER_DESC,
>>> + [STRING_PRODUCT_SERIAL].s = "",
>>> { } /* end of list */
>>> };
>>>
>>> @@ -205,6 +207,11 @@ static int __init acm_ms_bind(struct usb_composite_dev *cdev)
>>> goto fail1;
>>>
>>> USB_GADGET_COMPOSITE_OVERWRITE_OPTIONS(device_desc);
>>> + if (iSerialNumber) {
>>> + strings_dev[STRING_PRODUCT_SERIAL].s = iSerialNumber;
>>> + device_desc.iSerialNumber =
>>> + strings_dev[STRING_PRODUCT_SERIAL].id;
>>> + }
>>
>> Could we instead have USB_GADGET_COMPOSITE_OVERWRITE_OPTIONS handle
>> this?
>
> Everything is possible.
>
>> This could be achieved by passing strings_dev and STRING_PRODUCT_SERIAL
>> to the macro. It could also take care of "" initialisation if module
>> parameter was not given.
>
> Argh. And for product and manuf you add another two variable to the
> macro.
Right...
> And how do you achieve the "" initialization? This macro is
> evaluated after the id has been assigned.
Ah, right, I've forgotten that usb_string_ids_tab iterates till it finds
a NULL pointer.
> What I could live with is to add the string_dev variable to the macro
> and enforce all Serial/Manu/Product index to be the same. The idea died
> once I saw g_ffs. So?
Uh? What's so scary about g_ffs? You just need to add GFFS_SERIAL_IDX
at the beginning rather than end of the enum which will make it zero.
Alternatively, you could make the macro take string_dev and index of
serial string with requirement that serial string is followed by
manufacturer and product.
I feel this would be less intrusive to existing gadgets as it would keep
the ids the way they are and only add some new strings at the end of the
tables.
With this approach, I think it would also be beneficial to create a
USB_GADGET_COMPOSITE_STRINGS(num) macro (or something) as so:
#define USB_GADGET_COMPOSITE_STIRNGS(num) \
{ [num ].s = "" }, /* serial */ \
{ [num+1].s = "" }, /* manufacturer */ \
{ [num+2].s = "" }, /* product */
This way, gadgets would just add one index to strings, say
USB_COMPOSITE_STRINGS_IDX, invoke
USB_GADGET_COMPOSITE_STIRNGS(USB_COMPOSITE_STRINGS_IDX) at the end of
their string_dev and pass string_dev and USB_COMPOSITE_STRINGS_IDX as
two more arguments to USB_GADGET_COMPOSITE_OVERWRITE_OPTIONS.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo--Attachment:
pgpVgoh3HZR0_.pgp
Description: PGP signature
