lkml.org 
[lkml]   [2012]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC 2/2] usb: gadget: composite: parse dt overrides
From
On Mon, Jun 25, 2012 at 8:49 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 06/25/2012 03:23 PM, Alexandre Pereira da Silva wrote:
>> Grab the devicetree node properties to override VendorId, ProductId,
>> bcdDevice, Manucacturer, Product and SerialNumber
>>
>> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
>> ---
>>  drivers/usb/gadget/composite.c |   31 +++++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>
> Are these bindings documented? I think they should be less generic.
> Perhaps prefixed with 'usb-'.

Not yet, I will in the final series. This was just to see it had big
issues because the final one needs to change lots of files.
I will add some prefix to them.

About the documentation, should I include it in all of the controllers
bindings or should I add a common file to describe the gadget drivers
binding?

>>
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index 390749b..f3b480e 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -17,6 +17,7 @@
>>  #include <linux/module.h>
>>  #include <linux/device.h>
>>  #include <linux/utsname.h>
>> +#include <linux/of.h>
>>
>>  #include <linux/usb/composite.h>
>>  #include <asm/unaligned.h>
>> @@ -1423,6 +1424,7 @@ static int composite_bind(struct usb_gadget *gadget)
>>  {
>>       struct usb_composite_dev        *cdev;
>>       int                             status = -ENOMEM;
>> +     struct device_node              *np = gadget->dev.of_node;
>>
>>       cdev = kzalloc(sizeof *cdev, GFP_KERNEL);
>>       if (!cdev)
>> @@ -1470,6 +1472,35 @@ static int composite_bind(struct usb_gadget *gadget)
>>
>>       cdev->desc = *composite->dev;
>>
>> +     /* grab overrides from devicetree */
>
> Reading the code, it looks more like the DT entries are defaults rather
> than overrides.

Actually, it's mixed. The DT overrides the hard coded defaults. And
module parameters can override both. I think the safest path is to
keep them like this, so a DT would not break existing code.

>> +     if (np) {
>> +             u32 reg;
>> +
>> +             if (!idVendor &&
>> +                     of_property_read_u32(np, "vendor_id", &reg) == 0)
>> +                     idVendor = reg;
>
> if (!idVendor)
>        of_property_read_u32(np, "vendor_id", &idVendor);
>
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-06-26 04:01    [W:0.075 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site