linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"Mutanen, Mikko" <Mikko.Mutanen@fi.rohmeurope.com>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"Laine, Markus" <Markus.Laine@fi.rohmeurope.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"sre@kernel.org" <sre@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [RFC PATCH 2/3] power: (regmap:) Add linear_range helper
Date: Fri, 14 Feb 2020 11:47:49 +0000	[thread overview]
Message-ID: <20200214114749.GB4827@sirena.org.uk> (raw)
In-Reply-To: <cb9ed43aafcd8e1f6af05bfec8108ee8c14af265.camel@fi.rohmeurope.com>

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-02-14 11:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 12:11 [RFC PATCH 0/3] Support ROHM BD99954 charger IC Matti Vaittinen
2020-02-10 12:11 ` [RFC PATCH 1/3] dt_bindings: ROHM BD99954 Charger Matti Vaittinen
2020-02-10 13:00   ` Vaittinen, Matti
2020-02-10 12:13 ` [RFC PATCH 2/3] power: (regmap:) Add linear_range helper Matti Vaittinen
2020-02-11 19:06   ` Mark Brown
2020-02-12  6:56     ` Vaittinen, Matti
2020-02-14 11:47       ` Mark Brown [this message]
2020-02-14 12:32         ` Vaittinen, Matti
2020-02-18  7:23           ` Vaittinen, Matti
2020-02-18 13:49             ` Mark Brown
2020-02-19  8:14               ` Vaittinen, Matti
2020-02-10 12:13 ` [RFC PATCH 3/3] power: supply: Support ROHM bd99954 charger Matti Vaittinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200214114749.GB4827@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Markus.Laine@fi.rohmeurope.com \
    --cc=Matti.Vaittinen@fi.rohmeurope.com \
    --cc=Mikko.Mutanen@fi.rohmeurope.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).