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  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

Powered by blists - more mailing lists