lkml.org 
[lkml]   [2017]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
From
Date
On Wed, 2017-02-08 at 16:17 +0100, Richard Leitner wrote:
> On 02/08/2017 02:59 PM, Greg KH wrote:
> > On Wed, Feb 08, 2017 at 03:21:08PM +0200, Andy Shevchenko wrote:
> > > On Wed, 2017-02-08 at 09:52 +0100, Richard Leitner wrote:
> > > > From: Richard Leitner <dev@g0hl1n.net>
> > >
> > > If you want to fix the above you have to fix your Git
> > > configuration.
>
> My git config is fine, just cherry-picked it from a remote and forgot
> I
> committed it from another computer with another git config ;-)
> Will fix that in v5 for sure!

OK!

> > > > +++ b/drivers/usb/misc/usb251xb.c
> > > > @@ -0,0 +1,674 @@
> > > > +#include <linux/i2c.h>
> > > > +#include <linux/gpio.h>
> > > > +#include <linux/delay.h>
> > > > +#include <linux/slab.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of_gpio.h>
> > > > +#include <linux/of_device.h>
> > > > +#include <linux/nls.h>
> > >
> > > Alphabetical order?
> >
> > Ick, no, who cares, really.  It's whatever order the author wants,
> > don't
> > be so picky.

That's why question mark. If author thinks it's good idea (our case,
btw) then it takes, otherwise I'm okay with it.

>
> Ok :-)
> But somehow you're right Andy, alphabetical order seems to look better
> here (will do that in v5).
>

> >
> > > > +#define DRIVER_NAME "usb251xb"
> > > > +#define DRIVER_DESC "Microchip USB 2.0 Hi-Speed Hub Controller"
> > > > +#define DRIVER_VERSION "1.0"
> > >
> > > Is it my MUA, or all above indentations are broken?
> >
> > What do you mean?
>
> Should the strings be aligned, like the following?
> #define DRIVER_NAME     "usb251xb"
> #define DRIVER_DESC     "Microchip USB .."
> #define DRIVER_VERSION "1.0"

Yep, tab vs. space indentation.



> > > Above doesn't make much sense. Why not to use
> > >
> > > > BIT(bit) 
> > >
> > > and
> > >
> > > & ~BIT(bit)
> > >
> > > in place?
> >
> > I thought we already had functions to do this for you.  Don't write
> > new
> > ones "by hand" either wya.
>
> Which functions do you mean? I only found set_bit() and clear_bit()
> from
> atomic_ops. But those operate on "unsigned long" variables. From the
> documentation:
> Native atomic bit operations are defined to operate
> on objects aligned to the size of an "unsigned long"
> C data type, and are least of that size.

__set_bit(), __clear_bit() -- non-atomic variants, but you are right,
that (unsigned long) exactly the point I didn't propose them.


> > > > + /* the first data byte transferred tells the
> > > > hub how
> > > > many data
> > > > +  * bytes will follow (byte count)
> > > > +  */
> > >
> > > I'm not sure this is good formatted comment for USB subsystem.
> >
> > Looks fine to me, why do you think it is incorrect?

I would do like

/*
* The multi-line
* comment.
*/

Capital letter, period at the end, first empty line (unlike in net
subsystem).

> >
> > > > + /* the following parameters are currently not exposed
> > > > to
> > > > devicetree, but
> > > > +  * may be as soon as needed
> > > > +  */
> > >
> > > Style of multi-line comment.
> >
> > Nope, it's fine.
> >
> > > > +#else /* CONFIG_OF */
> > > > +static int usb251xb_get_ofdata(struct usb251xb *hub,
> > > > +        struct usb251xb_data *data)
> > > > +{
> > > > + return 0;
> > > > +}
> > > > +#endif /* CONFIG_OF */
> > >
> > > I don't think it's a good idea to have those ugly #ifdef.
> >
> > How can it be removed?

__maybe_unused for function, device_property_*() instead of
of_property_*() calls.

Something like that. But if you are insisting this is *only* OF
available hardware or we don't care, I'll not object.

--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

\
 
 \ /
  Last update: 2017-02-08 17:50    [W:0.089 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site