linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "lee.jones@linaro.org" <lee.jones@linaro.org>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"dmurphy@ti.com" <dmurphy@ti.com>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
	"a.zummo@towertech.it" <a.zummo@towertech.it>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"pavel@ucw.cz" <pavel@ucw.cz>,
	"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH v8 08/12] regulator: bd718x7: Split driver to common and bd718x7 specific parts
Date: Wed, 8 Jan 2020 08:34:03 +0000	[thread overview]
Message-ID: <32f8fa4201ae99df64e7a39c6a69be2bef179f7b.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20200107124124.GI14821@dell>

Hello Lee,

On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote:
> On Mon, 30 Dec 2019, Matti Vaittinen wrote:
> 
> > Few ROHM PMICs allow setting the voltage states for different
> > system states
> > like RUN, IDLE, SUSPEND and LPSR. States are then changed via SoC
> > specific
> > mechanisms. bd718x7 driver implemented device-tree parsing
> > functions for
> > these state specific voltages. The parsing functions can be re-used 
> > by
> > other ROHM chip drivers like bd71828. Split the generic functions
> > from
> > bd718x7-regulator.c to rohm-regulator.c and export them for other
> > modules
> > to use.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > ---
> > 
> > +
> > +struct rohm_dvs_config {
> > +	uint64_t level_map;
> > +	unsigned int run_reg;
> > +	unsigned int run_mask;
> > +	unsigned int run_on_mask;
> > +	unsigned int idle_reg;
> > +	unsigned int idle_mask;
> > +	unsigned int idle_on_mask;
> > +	unsigned int suspend_reg;
> > +	unsigned int suspend_mask;
> > +	unsigned int suspend_on_mask;
> > +	unsigned int lpsr_reg;
> > +	unsigned int lpsr_mask;
> > +	unsigned int lpsr_on_mask;
> > +};
> 
> I think this deserves a kernel-doc header.
Oh, the struct here? Hmm. You might be correct. I can add some.

> 
> > +#if IS_ENABLED(CONFIG_REGULATOR_ROHM)
> > +int rohm_regulator_set_dvs_levels(const struct rohm_dvs_config
> > *dvs,
> > +				  struct device_node *np,
> > +				  const struct regulator_desc *desc,
> > +				  struct regmap *regmap);
> 
> Does these really need to live in the parent's header file?

I don't know what would be a better place?

> What other call-sites are there?

After this series the bd718x7-regulator.c and bd71828-regulator.c are
the in-tree drivers using these. rohm-regulator.c is implementing them.
And I hope we see yet another driver landing in later this year. 

Anyways, I will investigate if I can switch this to some common (not
rohm specific) DT bindings at some point (I've scheduled this study to
March) - If I can then they should live in regulator core headers.

But changing the existing properties should again be own set of patches
and I'd prefer doing that work independently of this series and not
delaying the BD71828 due to not-yet-evaluated bd718x7 property changes.

> 
> > +#else
> > +static inline int rohm_regulator_set_dvs_levels(const struct
> > rohm_dvs_config *dvs,
> > +						struct device_node *np,
> > +						const struct
> > regulator_desc *desc,
> > +						struct regmap *regmap)
> > +{
> > +	return 0;
> > +}
> > +#endif //IS_ENABLED(CONFIG_REGULATOR_ROHM)
> 
> a) This comment is not really required
> b) You shouldn't be using C++ comments

Thanks, I'll remove it.

Best Regards
	Matti

  reply	other threads:[~2020-01-08  8:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30  9:33 [PATCH v8 00/12] Support ROHM BD71828 PMIC Matti Vaittinen
2019-12-30  9:34 ` [PATCH v8 01/12] dt-bindings: leds: ROHM BD71282 PMIC LED driver Matti Vaittinen
2019-12-30  9:35 ` [PATCH v8 02/12] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-12-30  9:36 ` [PATCH v8 03/12] mfd: rohm PMICs - use platform_device_id to match MFD sub-devices Matti Vaittinen
2019-12-30  9:36 ` [PATCH v8 04/12] mfd: bd718x7: Add compatible for BD71850 Matti Vaittinen
2020-01-07 12:36   ` Lee Jones
2019-12-30  9:37 ` [PATCH v8 05/12] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-12-30  9:38 ` [PATCH v8 06/12] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-12-30  9:38 ` [PATCH v8 07/12] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-12-30  9:39 ` [PATCH v8 08/12] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2020-01-07 12:41   ` Lee Jones
2020-01-08  8:34     ` Vaittinen, Matti [this message]
2020-01-13 10:53       ` Lee Jones
2020-01-13 11:49         ` Vaittinen, Matti
2020-01-13 12:11           ` Lee Jones
2020-01-15  8:29             ` Lee Jones
2020-01-15  8:34               ` Vaittinen, Matti
2019-12-30  9:40 ` [PATCH v8 09/12] rtc: bd70528: add BD71828 support Matti Vaittinen
2020-01-07 12:57   ` Lee Jones
2020-01-08  8:11     ` Vaittinen, Matti
2019-12-30  9:40 ` [PATCH v8 10/12] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-12-30  9:45 ` [PATCH v8 11/12] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-12-30  9:45 ` [PATCH v8 12/12] led: bd71828: Support LED outputs on ROHM BD71828 PMIC 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=32f8fa4201ae99df64e7a39c6a69be2bef179f7b.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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).