From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter
Date: Tue, 29 Aug 2017 12:02:41 +0200 [thread overview]
Message-ID: <20170829100241.GB3101@ubuntu> (raw)
In-Reply-To: <20170829063734.GC12198@kroah.com>
On 29-08-17, 08:37, Greg Kroah-Hartman wrote:
> On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> > + boot_constraints_disable
> > + Do not set any boot constraints for devices.
>
> Shouldn't that be the default? As really, that is what the situation is
> today, why force everyone to always enable the disable value? And
> enabling a value to disable something is usually a sign of bad naming...
I will explain once again how it is getting used and then will do whatever you
suggest.
- Platforms that don't need boot constraints should not enable the CONFIG in the
first place. Though we use the same kernel image on multiple hardware types
many times.
- If a platform doesn't have a platform-specific driver that adds constraints at
boot, then the boot constraint core wouldn't get into picture at all and it is
as good as being disabled.
- And the above boot-argument (boot_constraints_disable) is used ONLY in the
case where the platform driver is adding boot constraints at runtime.
So, the boot-constraints are disabled by default for everyone even if the
configuration is enabled. And that's why I named it the way it is right now.
Do you still feel that it needs to be renamed?
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Vincent Guittot <vincent.guittot@linaro.org>,
Mark Brown <broonie@kernel.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Shiraz Hashim <shashim@codeaurora.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, robdclark@gmail.com,
linux-doc@vger.kernel.org
Subject: Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter
Date: Tue, 29 Aug 2017 12:02:41 +0200 [thread overview]
Message-ID: <20170829100241.GB3101@ubuntu> (raw)
In-Reply-To: <20170829063734.GC12198@kroah.com>
On 29-08-17, 08:37, Greg Kroah-Hartman wrote:
> On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> > + boot_constraints_disable
> > + Do not set any boot constraints for devices.
>
> Shouldn't that be the default? As really, that is what the situation is
> today, why force everyone to always enable the disable value? And
> enabling a value to disable something is usually a sign of bad naming...
I will explain once again how it is getting used and then will do whatever you
suggest.
- Platforms that don't need boot constraints should not enable the CONFIG in the
first place. Though we use the same kernel image on multiple hardware types
many times.
- If a platform doesn't have a platform-specific driver that adds constraints at
boot, then the boot constraint core wouldn't get into picture at all and it is
as good as being disabled.
- And the above boot-argument (boot_constraints_disable) is used ONLY in the
case where the platform driver is adding boot constraints at runtime.
So, the boot-constraints are disabled by default for everyone even if the
configuration is enabled. And that's why I named it the way it is right now.
Do you still feel that it needs to be renamed?
--
viresh
next prev parent reply other threads:[~2017-08-29 10:02 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 9:23 [PATCH V3 0/8] drivers: Boot Constraints core Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 1/8] drivers: Add boot constraints core Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-29 6:39 ` Greg Kroah-Hartman
2017-08-29 6:39 ` Greg Kroah-Hartman
2017-08-29 9:52 ` Viresh Kumar
2017-08-29 9:52 ` Viresh Kumar
2017-08-29 12:03 ` Greg Kroah-Hartman
2017-08-29 12:03 ` Greg Kroah-Hartman
2017-09-04 9:15 ` Viresh Kumar
2017-09-04 9:15 ` Viresh Kumar
2017-09-04 9:38 ` Greg Kroah-Hartman
2017-09-04 9:38 ` Greg Kroah-Hartman
2017-09-19 22:46 ` Viresh Kumar
2017-09-19 22:46 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-29 6:37 ` Greg Kroah-Hartman
2017-08-29 6:37 ` Greg Kroah-Hartman
2017-08-29 6:48 ` Jani Nikula
2017-08-29 6:48 ` Jani Nikula
2017-08-29 10:02 ` Viresh Kumar [this message]
2017-08-29 10:02 ` Viresh Kumar
2017-08-29 11:56 ` Greg Kroah-Hartman
2017-08-29 11:56 ` Greg Kroah-Hartman
2017-08-01 9:23 ` [PATCH V3 3/8] drivers: boot_constraint: Add support for supply constraints Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 4/8] drivers: boot_constraint: Add support for clk constraints Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 5/8] drivers: boot_constraint: Add support for PM constraints Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 6/8] drivers: boot_constraint: Add debugfs support Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-29 6:36 ` Greg Kroah-Hartman
2017-08-29 6:36 ` Greg Kroah-Hartman
2017-08-29 10:04 ` Viresh Kumar
2017-08-29 10:04 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 7/8] drivers: boot_constraint: Manage deferrable constraints Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-08-01 9:23 ` [PATCH V3 8/8] drivers: boot_constraint: Add Qualcomm display controller constraints Viresh Kumar
2017-08-01 9:23 ` Viresh Kumar
2017-09-04 16:25 ` Pavel Machek
2017-09-04 16:25 ` Pavel Machek
2017-09-19 22:40 ` Viresh Kumar
2017-09-19 22:40 ` Viresh Kumar
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=20170829100241.GB3101@ubuntu \
--to=viresh.kumar@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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.