linux-kernel - Re: [RFC PATCH 2/3] power: (regmap:) Add linear

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:   Fri, 14 Feb 2020 11:47:49 +0000
From:   Mark Brown <broonie@...nel.org>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "Mutanen, Mikko" <Mikko.Mutanen@...rohmeurope.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "Laine, Markus" <Markus.Laine@...rohmeurope.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "sre@...nel.org" <sre@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH 2/3] power: (regmap:) Add linear_range helper

On Wed, Feb 12, 2020 at 06:56:37AM +0000, Vaittinen, Matti wrote:
> On Tue, 2020-02-11 at 19:06 +0000, Mark Brown wrote:

> > Note also that we already have quite extensive helpers for this sort
> > of
> > stuff in the regulator API which I sense may have been involved in
> > this
> > implementation

> You sense well xD

If you're factoring stuff out of an existing implementation it'd be good
to explicitly do that - this both shows where things came from and also
means that you can show that the existing user works with the new code
which is good.

> But another option - which I thought only now - would be to see if
> current regulator implementation could be re-named to more generic and
> placed under some more generic component (I thought of regmap but as
> you pointed out this is equally usefull for devices connected to memory
> mapped buses - so maybe under lib - if static inline functions in a
> header are not a good option). I just have a feeling that the linear-
> ranges is currently kind of embedded in the code which is internal to
> regulator framework so it is probably not easily extracted from
> regulator code?

It is a bit but I think that's solvable with some refactoring in place
(eg, pushing things into a smaller struct embedded in the main regulator
one and then moving them out).  I might look at it myself if nobody else
gets to it first...

> So if we do not start pulling the range code out of regulator framework
> (for now at least) - and if we do not place this under regmap - then I
> can drop you out of the recipient list for this charger driver in order
> to not pollute your inbox ;) How do you feel Mark, do you want to be
> following this series?

Well, if there's a refactoring out of the regulator code going on I'll
need to look at that anyway.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)