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:	Thu, 29 Jul 2010 15:21:18 -0700 (PDT)
From:	David Brownell <david-b@...bell.net>
To:	Greg KH <greg@...ah.com>,
	Michal Nazarewicz <m.nazarewicz@...sung.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Dries Van Puymbroeck <Dries.VanPuymbroeck@...imo.com>,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCHv5 2/3] USB: gadget: Use new composite features in some gadgets



--- On Wed, 7/28/10, Michal Nazarewicz <m.nazarewicz@...sung.com> wrote:

> From: Michal Nazarewicz <m.nazarewicz@...sung.com>
> Subject: [PATCHv5 2/3] USB: gadget: Use new composite features in some gadgets

NAK


Let's have one patch per gadget or function driver.
WITH a good explanation of what's changed in each.

What I see is a whole lot of random changes that
don't make ANY sense as one combined patch.  Plus,
some look quite dubious...


> use the new features of composite framework.  Because
> it
> handles default strings there is no longer the need for
> the
> gadgets drivers to handle many of the strings.

The gadgets should always identify the same, and
thus handle their strings -- *unless* module params
are applied by users to override those defaults.
The reason to use the module params is because a
product wants to be a *different* gadget, which
must be possible but won't be routine.  It
suffices to be different instances (serial #s)
in most routine usage.

> 
> This also adds the "needs_serial" to Mass Storage
> Gadget and

When the mass-storage only patch gets sent, I'll
want to see Alan's ack.

> Multifunction Composite Gadget which makes composite issue
> a warning if user space has not provided iSerialNumber parameter.
> 
>  
>  
> -static unsigned short gfs_vendor_id    =
> 0x0525;    /* XXX NetChip */
> -static unsigned short gfs_product_id   =
> 0xa4ac;    /* XXX */

Look -- you can't assign NetChip numbers!!!  I
personally have a handful of them, and if I didn't
assign them, they CANNOT be used.  That XXX
makes me think you (or someone) just randomly
picked a (broken) number.  The original file
storage gadget had a correctly assigned number.
If you're using anything else, fix it; there are
numbers Greg can assign from Linux Foundation's
USB-IF membership.

Comments like "XXX" need explanations, too...
if the intent is to seem like the file storage
gadget, just say so.


>  
> -    /* Vendor and product id can be
> overridden by module parameters.  */
> -    /* .idVendor   
>     = cpu_to_le16(gfs_vendor_id), */
> -    /* .idProduct   
>     = cpu_to_le16(gfs_product_id), */


Again, screwey.  Use the standard IDs unless
they get overridden.  Don't require them to be
overridden ... they were assigned in the first
place to be safe.  Module overrides are for folk
who put out their own products and want them to be
visibly different from  the generic Linux ones,
and thus need to manage their own USB-IF vid/pid
codes

What you're doing is changing the whole model so
there's no longer a standard "this is what Linux
does by default" -- and *requiring* a lot more
pain and suffering from folk configuring gadgets.
PLUS ... almost ensuring they'll get it wrong.  Not
anything vaguely like an improvement.


> -    /* .bcdDevice   
>     = f(hardware) */
> -    /* .iManufacturer    =
> DYNAMIC */
> -    /* .iProduct   
>     = DYNAMIC */
> -    /* NO SERIAL NUMBER */
> -    .bNumConfigurations    =
> 1,
> +    .idVendor   
>     = cpu_to_le16(0x0525),
> +    .idProduct   
>     = cpu_to_le16(0xa4ac),

Same as above.  You've broken ID management.
Use the (correct) symbols, not magic numbers.

Do you not understand how fundamental proper
management of vendor and product IDs is????












--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ