linux-kernel - Re: [RESEND PATCH 0/4] Drop ROHM BD70528 support

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:   Mon, 1 Nov 2021 06:18:47 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Matti Vaittinen <mazziesaccount@...il.com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-power <linux-power@...rohmeurope.com>
Subject: Re: [RESEND PATCH 0/4] Drop ROHM BD70528 support

Hello Andy,

On 10/31/21 15:06, Andy Shevchenko wrote:
> On Thu, Oct 28, 2021 at 12:18 PM Matti Vaittinen
> <matti.vaittinen@...rohmeurope.com> wrote:
>>
>> Drop ROHM BD70528 support
> 
> I am always for the code removal, but the Q here is do you think there
> won't be similar chips that may utilize the code and avoid duplication
> in the future?

The BD70528 RTC driver will stay because we do really have couple of 
other PMICs with RTC blocks that have similarities to BD70528. Also the 
CLK driver used by BD70528 is also used by a few other ROHM ICs.

As for the regulators - The PMICs which I have seen from ROHM have 
pretty mauch all had different gpio control design. Seems like HW 
colleagues like reinventing the wheel. Well, perhaps this will 
eventually result a better wheel - for SW colleague this does bring some 
additional work though...

Same goes with the GPIOs - although - as you probably know - I do think 
many of the GPIOs could be handled by a generic GPIO helpers by allowing 
IC specific GPIO config functions. Well, the BD70528 GPIO driver is not 
written to be generic - and no, I don't see similar GPIO block in other 
ROHM PMICs. Same goes with the MFD.

After all this being written - code dublication won't be an issue if we 
_drop_ the BD70528 support. Even re-adding similar driver for another IC 
in the future won't bring dublication as BD70528 is dropped. And if we 
will see BD70528 v2.0 - then I (or someone else) can dig the old BD70528 
drivers - or write a new ones - and bring them back in-tree. But until 
that happens carrying the existing drivers is just an additional burden 
and waste. The BD70528 v2.0 may never come.

Well, don't get me wrong. The BD70528 drivers won't bother me in 
community kernel. I do like seeing my name in the spotlight XD What I do 
not like is leaving others to hold up the light - or to pay the 
electricity for it :)

So yes. I did submit this patch series as I really think maintaining the 
driver(s) for dead IC is not worth the work :/ Oh, by the way, part of 
the drivers were already dropped during the previous cycles.

Best Regards
   -- Matti Vaittinen