From: Hugh Kang <hugh.kang@lge.com>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, jonghoon.park@lge.com
Subject: Re: [PATCH] regulator: adding disable options for regulator-always-on and regulator-boots-on
Date: Thu, 06 Nov 2014 15:39:47 +0900 [thread overview]
Message-ID: <545B17B3.4060901@lge.com> (raw)
In-Reply-To: <20141104195640.GW3815@sirena.org.uk>
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.
prev parent reply other threads:[~2014-11-06 6:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 1:26 [PATCH] regulator: adding disable options for regulator-always-on and regulator-boots-on Hugh Kang
2014-11-03 10:00 ` Markus Pargmann
2014-11-03 12:03 ` Mark Brown
2014-11-04 8:20 ` Hugh Kang
2014-11-04 14:11 ` Krzysztof Kozłowski
2014-11-04 19:56 ` Mark Brown
2014-11-06 6:39 ` Hugh Kang [this message]
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=545B17B3.4060901@lge.com \
--to=hugh.kang@lge.com \
--cc=broonie@kernel.org \
--cc=jonghoon.park@lge.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.