linux-kernel - Re: [PATCH] regulator: adding disable options for regulator-always-on and regulator-boots-on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <545B17B3.4060901@lge.com>
Date:	Thu, 06 Nov 2014 15:39:47 +0900
From:	Hugh Kang <hugh.kang@....com>
To:	Mark Brown <broonie@...nel.org>
CC:	Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
	jonghoon.park@....com
Subject: Re: [PATCH] regulator: adding disable options for regulator-always-on
 and regulator-boots-on


On 2014년 11월 05일 04:56, Mark Brown wrote:
> On Tue, Nov 04, 2014 at 05:20:11PM +0900, Hugh Kang wrote:
>
> Please fix your mailer to word wrap within paragraphs.
>
>> I understand that I could make Rev.B with b.dtsi due to LDOs option is
>> different. However, aim to use device tree is that making easy steps.
>> Refer to dts option, if you set to be set status disabled option, the
>> driver dose not probe when the system boot up. Even though, the system
>> has different board revision exist. So dts have to be no corrupts any
>> overlap situation.
> Right, nothing is going to be perfect but equally if we use this sort of
> override property to do things it then becomes harder to read the DT for
> the system since you can't trust that a property you see in one file
> won't be overridden by another file somewhere else.  This can happen to
> an extent already but normally not and it doesn't seem like a pattern we
> want to encourage.
>
>> I have mentions the simple example to change only one LDOs. However,
>> if someone want to edit many regulators with similar configuration, he
>> has to do lots of copy and paste works. Because he has to create new
>> dts file. So I would suggest to make it as simple as I could.
> Sure, but that's purely mechanical and very easy to review - you can do
> a code motion patch to split the bits of DT out then start changing
> things, and you can still keep the common paramters in the core file.
>
>> Also, I have somehow agree with you that affects any boolean property in the DT.
> This is a big one for me - it's going to be both time consuming and
> complex to add this sort of thing for more properties and we do get
> into complexity things if each individual property and its override
> has to be handled by hand.
Thank you for advising. I would take another way to apply it.
Also, I would like to say thanks to Krzysztof, giving me a advice.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/