linux-kernel - Re: [RFC 2/2] usb: gadget: composite: parse dt overrides

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jun 2012 22:12:58 -0300
From:	Alexandre Pereira da Silva <aletes.xgr@...il.com>
To:	Rob Herring <robherring2@...il.com>
Cc:	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC 2/2] usb: gadget: composite: parse dt overrides

On Mon, Jun 25, 2012 at 8:49 PM, Rob Herring <robherring2@...il.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@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/