[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <op.vfjkfho27p4s8u@pikus>
Date: Thu, 08 Jul 2010 22:27:07 +0200
From: Michał Nazarewicz <m.nazarewicz@...sung.com>
To: Greg KH <greg@...ah.com>, David Brownell <david-b@...bell.net>
Cc: linux-usb@...r.kernel.org, Alan Stern <stern@...land.harvard.edu>,
Kyungmin Park <kyungmin.park@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org,
Dries Van Puymbroeck <Dries.VanPuymbroeck@...imo.com>,
mina86@...a86.com
Subject: Re: [PATCHv2 1/2] USB: gadget: mass/file storage: set serial number
On Thu, 08 Jul 2010 22:20:11 +0200, David Brownell <david-b@...bell.net> wrote:
>> > Can it be made to do so only when the gadget
>> > hasn't been provided with one already? Serial
>> > number module options are standard parts of the
>> > composite gadget framework...
>>
>> I don't see a way for the gadget to know whether user gave
>> the iSerialNumber
>> parameter (other then reading the iSerialNumber variable
>> but I consider that ugly).
>
> Uglier still is the current patch overriding
> that explicitly-given parameter.
How does it override explicitly-given parameter? I don't follow...
All it does is add a iSerialNumber. Without this patch the
explicitly-given parameter won't even work:
if (cdev->desc.iSerialNumber && iSerialNumber)
string_override(composite->strings,
cdev->desc.iSerialNumber, iSerialNumber);
Composite checks if iSerialNumber is allocated and overrides the
string only if it is. Without my patch, the string ID is never
allocated.
Also, the overriding is performed *after* composite device's bind
callback is called so there is no way for the bind callback to
override explicitly-given parameter.
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists