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@xxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
