Message ID | f08d265c12ebf185c0e1dbbfe0a3f86de4907194.1572606437.git.matti.vaittinen@fi.rohmeurope.com |
---|---|
State | Not Applicable |
Headers | show |
Series | Support ROHM BD71828 PMIC | expand |
Hi Matti! Good initiative (and I will see a ton of janitorial patches as a result of this...) On Fri, Nov 1, 2019 at 12:50 PM Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> wrote: > At least for me it is difficult to remember the meaning of GPIO > direction values. Define GPIO_IN and GPIO_OUT so that occasional > GPIO contributors would not need to always check the meaning of > hard coded values 1 and 0. > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> (...) > +#define GPIO_IN 1 > +#define GPIO_OUT 0 Please spell it out or people will be confused: GPIO_LINE_DIRECTION_IN GPIO_LINE_DIRECTION_OUT Yours, Linus Walleij
Hello Linus, On Sun, 2019-11-03 at 23:30 +0100, Linus Walleij wrote: > Hi Matti! > > Good initiative (and I will see a ton of janitorial patches as a > result of this...) Yep. I think I might pull this change out of the RFC and send it separately. I can also do some conversions for existing drivers - but I won't probably be able to do all of the drivers. I see no way of doing any search and replace scripting here - this conversion is going to be manual work :/ > > On Fri, Nov 1, 2019 at 12:50 PM Matti Vaittinen > <matti.vaittinen@fi.rohmeurope.com> wrote: > > > At least for me it is difficult to remember the meaning of GPIO > > direction values. Define GPIO_IN and GPIO_OUT so that occasional > > GPIO contributors would not need to always check the meaning of > > hard coded values 1 and 0. > > > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > (...) > > +#define GPIO_IN 1 > > +#define GPIO_OUT 0 > > Please spell it out or people will be confused: > > GPIO_LINE_DIRECTION_IN > GPIO_LINE_DIRECTION_OUT Right. Besides the 0Day test suite did already spot a few redefinition problems when some drivers do define GPIO_IN and/or GPIO_OUT... So I'll change the defines to what you suggest here. Br, Matti Vaittinen
Hello All, On Sun, 2019-11-03 at 23:30 +0100, Linus Walleij wrote: > Hi Matti! > > Good initiative (and I will see a ton of janitorial patches as a > result of this...) I have somewhere near 62 patches waiting to be sent =) They're pretty small but I'd appreciate thorough review as they're mostly untested... Do you mind receiving them all in one go? Or do you think I should send the series in smaller chuncks? > On Fri, Nov 1, 2019 at 12:50 PM Matti Vaittinen > <matti.vaittinen@fi.rohmeurope.com> wrote: > > > At least for me it is difficult to remember the meaning of GPIO > > direction values. Define GPIO_IN and GPIO_OUT so that occasional > > GPIO contributors would not need to always check the meaning of > > hard coded values 1 and 0. > > > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > (...) > > +#define GPIO_IN 1 > > +#define GPIO_OUT 0 > > Please spell it out or people will be confused: > > GPIO_LINE_DIRECTION_IN > GPIO_LINE_DIRECTION_OUT > > Yours, > Linus Walleij
On Mon, Nov 4, 2019 at 4:48 PM Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> wrote: > > Good initiative (and I will see a ton of janitorial patches as a > > result of this...) > > I have somewhere near 62 patches waiting to be sent =) They're pretty > small but I'd appreciate thorough review as they're mostly untested... > Do you mind receiving them all in one go? Or do you think I should send > the series in smaller chuncks? I would be fine with one patch introducing the defines and then one big patch switching everybody and their dog over to using these definitions. I usually keep to a patch being "one technical step" and it is clearly (IMO) one step to introduce the defines and one step to make use of it in all legacy drivers. It's late in the kernel cycle but this particular part (the defines and switching over old driver to use it) I'd be happy to merge for v5.5. Yours, Linus Walleij
Hello Linus, On Tue, 2019-11-05 at 16:05 +0100, Linus Walleij wrote: > On Mon, Nov 4, 2019 at 4:48 PM Vaittinen, Matti > <Matti.Vaittinen@fi.rohmeurope.com> wrote: > > > > Good initiative (and I will see a ton of janitorial patches as a > > > result of this...) > > > > I have somewhere near 62 patches waiting to be sent =) They're > > pretty > > small but I'd appreciate thorough review as they're mostly > > untested... > > Do you mind receiving them all in one go? Or do you think I should > > send > > the series in smaller chuncks? > > I would be fine with one patch introducing the defines and then > one big patch switching everybody and their dog over to using > these definitions. > > I usually keep to a patch being "one technical step" and it is > clearly (IMO) one step to introduce the defines and one step > to make use of it in all legacy drivers. > > It's late in the kernel cycle but this particular part (the defines > and switching over old driver to use it) I'd be happy > to merge for v5.5. I'll prepare one patch for defines and one large patch for driver changes on top of GPIO tree then. I'll leave out the last one 62/62 - it can be applied later if it is considered a good idea - I'd appreciate if you / Bartosz had the time to check it though. > > Yours, > Linus Walleij
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h index 5dd9c982e2cb..e83d3f519507 100644 --- a/include/linux/gpio/driver.h +++ b/include/linux/gpio/driver.h @@ -22,6 +22,9 @@ enum gpio_lookup_flags; struct gpio_chip; +#define GPIO_IN 1 +#define GPIO_OUT 0 + /** * struct gpio_irq_chip - GPIO interrupt controller */
At least for me it is difficult to remember the meaning of GPIO direction values. Define GPIO_IN and GPIO_OUT so that occasional GPIO contributors would not need to always check the meaning of hard coded values 1 and 0. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> --- Changes since v2 - new patch include/linux/gpio/driver.h | 3 +++ 1 file changed, 3 insertions(+)