[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b288b97d-4c5f-1966-92b0-e949588ba97e@fi.rohmeurope.com>
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