Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1320358 > unrolled thread

Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator

Started byHenry Chen <henryc.chen@mediatek.com>
First post2016-01-28 08:20 +0100
Last post2016-01-28 12:40 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323  regulator Henry Chen <henryc.chen@mediatek.com> - 2016-01-28 08:20 +0100
    Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323  regulator Mark Brown <broonie@kernel.org> - 2016-01-28 12:40 +0100

#1320358 — Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator

FromHenry Chen <henryc.chen@mediatek.com>
Date2016-01-28 08:20 +0100
SubjectRe: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
Message-ID<qVP22-8nH-9@gated-at.bofh.it>
Hi Mark,

On Wed, 2016-01-27 at 14:41 +0000, Mark Brown wrote:
> On Wed, Jan 27, 2016 at 01:00:59PM +0100, John Crispin wrote:
> 
> > +		/* Constrain board-specific capabilities according to what
> > +		 * this driver and the chip itself can actually do.
> > +		 */
> > +		c = rdev->constraints;
> > +		c->valid_modes_mask |= REGULATOR_MODE_NORMAL |
> > +				       REGULATOR_MODE_STANDBY;
> > +		c->valid_ops_mask |= REGULATOR_CHANGE_MODE;
> 
> No, drivers should *never* enable things that weren't explictly enabled
> by the machine constraints.  This misses the whole point of having
> constraints.  They are there so that the system integrator can enable
> the functionality that is safe on a given board.  

Okay..the constrains should be define on device tree.
But which optional properties was suitable to fill on device tree if consumers want to call
regulator_set_mode directly ?
I have check the of_regulator.c and not found the suitable property name which can set valid_modes_mask & valid_ops_mask.

Thanks,
Henry 
> 
> The comment is also inaccurate, it claims it's imposing constraints but
> in fact it's adding additional permissions.
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

[toc] | [next] | [standalone]


#1320587

FromMark Brown <broonie@kernel.org>
Date2016-01-28 12:40 +0100
Message-ID<qVT5E-2Js-11@gated-at.bofh.it>
In reply to#1320358

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 28, 2016 at 03:16:41PM +0800, Henry Chen wrote:
> On Wed, 2016-01-27 at 14:41 +0000, Mark Brown wrote:

> > No, drivers should *never* enable things that weren't explictly enabled
> > by the machine constraints.  This misses the whole point of having
> > constraints.  They are there so that the system integrator can enable
> > the functionality that is safe on a given board.  

> Okay..the constrains should be define on device tree.
> But which optional properties was suitable to fill on device tree if consumers want to call
> regulator_set_mode directly ?
> I have check the of_regulator.c and not found the suitable property name which can set valid_modes_mask & valid_ops_mask.

If you need to change the mode at runtime you will need to develop a
binding for that, there isn't one at present.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web