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]

Message-ID: <cb9ed43aafcd8e1f6af05bfec8108ee8c14af265.camel@fi.rohmeurope.com>
Date:   Wed, 12 Feb 2020 06:56:37 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
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

Morning Mark,

On Tue, 2020-02-11 at 19:06 +0000, Mark Brown wrote:
> On Mon, Feb 10, 2020 at 02:13:13PM +0200, Matti Vaittinen wrote:
> 
> > Provide a linear_range helper which can do conversion from user
> > value
> > to register value 'selector'.
> > Mark, this is loosely bound to register handling... Do you think
> > the regmap could host these helpers?
> 
> There's no real tie to regmap here, something like this could quite
> happily be used by memory mapped devices where regmap has limited
> uses
> and would be a lot to pull in.  A separate library would probably
> make
> more sense.

Ugh. I know you are right. I can admit that I just saw it easier to get
this included in something that is already existing (besides, I have
found co-operating with the regmap/regulator maintainer pretty
straightforward - there has been no extra hassle required to get things
done, just the necessary fixes). I'm a bit afraid that adding a new
piece of library just for this might require a lot more social
influencing ^_^; But you are correct. Devices with this kind of
registers can easily be connected to memory mapped bus.

> Not sure how many users there would be outside of power
> related stuff, I don't recall seeing the pattern elsewhere.

I think there must be other stuff too. Bunch of NCOs (numeric
controller oscillators) from my clock/synchronization related career
comes to mind first. AFAIR they had linear frequency response. In
comparison tuning clock with DAC voltage was not linar - although
voltage change was linear :) But I would expect that there is bunch of
things (although I can not guarantee it).

> 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

This has been inspired by REGULATOR_LINEAR_RANGES in regulator
framework. I thought I did write that to somewhere so that the credits
would go to regulator code :) But maybe I did only write that when I
first introduced this code to BD70528 power-supply code.

I thought that we should add generic helpers and that the regulator
framework could switch to use them internally if it seemed like a good
idea.

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?

>  and to an extent in ALSA which takes a different approach
> with TLVs since it baked selectors directly into the ABI.

I've never played with any media subsystems. Sound, camera and video
are completely unknown to me :/

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?

Best Regards,
	Matti Vaittinen