[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56AA5A5C.9080402@openwrt.org>
Date: Thu, 28 Jan 2016 19:13:48 +0100
From: John Crispin <blogic@...nwrt.org>
To: Mark Brown <broonie@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Chen Zhong <chen.zhong@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
HenryC Chen (陳建豪)
<HenryC.Chen@...iatek.com>
Subject: Re: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323
regulator
On 27/01/2016 15:41, 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.
>
> The comment is also inaccurate, it claims it's imposing constraints but
> in fact it's adding additional permissions.
>
Hi Mark
would the following two bindings be ok ? I would create patches to add them.
* regulator-allow-mode; or regulator-allow-change-mode;
* regulator-modes = <REGULATOR_MODE_NORMAL REGULATOR_MODE_STANDBY>;
John
Powered by blists - more mailing lists