Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> writes:
> On 08/27/2012 03:51 PM, Michal Nazarewicz wrote:
>>> 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.
> not only usb_string_ids_tab iterates() but also the lookup code.
Lookup is done afterwards though, so it's not an issue, but that's
beside the point.
>>> 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.
> No scary but as same as all other gadgets. If I pick idx 0-2 for
> Serial/Product/MFR than I patch all gadgets the same way except for
> g_ffs.
> SERIAL = 0 I would add [i + 1]. Adding one more member…
Yes, with serial == 0 g_ffs gets a bit tricky, but all that it would
really need is
#define GFFS_FIRST_FFS_STRING_IDX 3
and than the loop would have [i + GFFS_FIRST_FFS_STRING_IDX]
>> 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.
>
> I see. So we either use the default serial which is provided by the
> gadget _or_ overwrite desc.iSerial with num.id in case the module
> parameter is used?
I would actually consider doing the following:
- first, if module parameter is given, overwrite [num].s,
- than, if [num].s is not empty, overwrite desc.iSerial with [num].id.
This way, gadget would set [num].s to whatever they want as the default
and if user does not provide module parameter, that would be used. With
module parameter, this gadget's default is overwritten and what user
specifies is used.
Furthermore, for manufacturer if [num+1].s is empty, overwrite it with
a gadget's default; and for product, if [num+2].s is empty, overwrite it
with driver->name.
--
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:
pgpN6nkUt5ELa.pgp
Description: PGP signature
