linux-kernel - Re: [PATCH v4 0/3] gpio: gpio-regmap: Support few custom operations

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]

Message-ID: <15d9e565021c115eec268c7fca810799eb503a90.camel@fi.rohmeurope.com>
Date:   Fri, 28 May 2021 06:33:15 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "linus.walleij@...aro.org" <linus.walleij@...aro.org>
CC:     linux-power <linux-power@...rohmeurope.com>,
        "bcm-kernel-feedback-list@...adcom.com" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michael@...le.cc" <michael@...le.cc>,
        "noltari@...il.com" <noltari@...il.com>,
        "jonas.gorski@...il.com" <jonas.gorski@...il.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 0/3] gpio: gpio-regmap: Support few custom operations

On Fri, 2021-05-28 at 02:53 +0200, Linus Walleij wrote:
> On Thu, May 27, 2021 at 8:32 AM Matti Vaittinen
> <matti.vaittinen@...rohmeurope.com> wrote:
> 
> > I think that the disagreement boils down to few styling issues -
> > and
> > one more pragmatic one. And only what comes to how we allow
> > implementing the IC specific call-backs for these more complex HW
> > specific cases. "Styling" boils down to providing getter-functions
> > for
> > well-defined gpio_regmap properties like regmap, device and fwnode
> > pointers Vs. exposing these in a well-defined structure as function
> > parameters.
> 
> Just do it the way the maintainer likes it I guess? Michael wrote
> the driver so do it in his fashion.

This is fair game I'd say. If there is no compromise - then it should
really be in a maintainer's fashion or not at all.

> 
> > So
> > at the end of the day it's fair to go on in a way Michael and You
> > find
> > easiest to maintain.
> 
> What makes things easy for me to maintain is active and happy
> driver maintainers, so it is paramount that the file looks to Michael
> like something he wants to keep maintaining. This removes work
> from me and Bartosz.

I agree. When someone takes care of a driver, he should be happy with
it. Period. And thanks to Michael for writing this driver and reviewing
the patches. Reviewing is hard work.

On the other hand, I don't enjoy writing code I am unhappy with either.
And as this particular piece of code is not a paid task for me, I do
this for fun. gpio-regmap is not mandatory for my drivers now. So, I'll
just opt-out from this change. I'll happily use the gpio-regmap where
it fits, when it fits.

So, during the last cycle I promised to look the gpio-regmap usage on
ROHM IC drivers: Currently it does not fit for the BD71815 as it lack
support for init_valid_mask and set_config. It does not work for the
BD71828 either due to lack of set_config and special handling of
HALL_GPIO. Regarding the BD70528 - with my heart bleeding I just sent a
set of patches to remove this IC's drivers completely. It seems the IC
never really took off. The BD9571 was not authored by me and I don't
have that IC - but at quick glance it seems that driver might work with
gpio-regmap. Conversion would require some testing.

> Maintainer style quirks are common, I have some myself (like
> never allowing __underscore_functions)

I like this. The Linux kernel community is well known for strict and
enforced styling guide. I've also worked in an another pretty huge
project, where every developer was pretty much allowed to use their own
style. I think it resulted happier developers and definitely made code-
readers much more careful ;) I'd claim that made people to pay more
attention when reading code - you could _never_ safely assume. It was
also somehow funny that at times one was able to recognize a file
author just by looking the code :)

Well, I would not suggest that to the Linux kernel - but I definitely
like allowing few maintainer quirks here and there. And I am definitely
hoping to see happy maintainers. Even though the __foo() for internal
functions is the right thing to do (tm) ;)

>  we just adapt to their
> quirks and be good diplomats.

Or keep whingeing and acting up - depending on the person XD

Keep up the good work you all :)

Best Regards
	--Matti