Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1320358 > unrolled thread
| Started by | Henry Chen <henryc.chen@mediatek.com> |
|---|---|
| First post | 2016-01-28 08:20 +0100 |
| Last post | 2016-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.
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
| From | Henry Chen <henryc.chen@mediatek.com> |
|---|---|
| Date | 2016-01-28 08:20 +0100 |
| Subject | Re: [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]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2016-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