All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
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 08:37:34 +0200	[thread overview]
Message-ID: <20170829063734.GC12198@kroah.com> (raw)
In-Reply-To: <4bec0c3e58f76e06e5305c5ddbab859e2a87935e.1501578037.git.viresh.kumar@linaro.org>

On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> Users must be given an option to discard any constraints set by
> bootloaders. For example, consider that a constraint is set for the LCD
> controller's supply and the LCD driver isn't loaded by the kernel. If
> the user doesn't need to use the LCD device, then he shouldn't be forced
> to honour the constraint.
> 
> We can also think about finer control of such constraints with help of
> some sysfs files, but a kernel parameter is fine to begin with.
> 
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  3 +++
>  drivers/base/boot_constraints/core.c            | 17 +++++++++++++++++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index d9c171ce4190..0706d1b6004d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -426,6 +426,9 @@
>  			embedded devices based on command line input.
>  			See Documentation/block/cmdline-partition.txt
>  
> +	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...

> +
>  	boot_delay=	Milliseconds to delay each printk during boot.
>  			Values larger than 10 seconds (10000) are changed to
>  			no delay (0).
> diff --git a/drivers/base/boot_constraints/core.c b/drivers/base/boot_constraints/core.c
> index 366a05d6d9ba..e0c33b2b216f 100644
> --- a/drivers/base/boot_constraints/core.c
> +++ b/drivers/base/boot_constraints/core.c
> @@ -24,6 +24,17 @@
>  static LIST_HEAD(constraint_devices);
>  static DEFINE_MUTEX(constraint_devices_mutex);
>  
> +static bool boot_constraints_disabled;

Again, this should only be an "enable" type of option, that kicks in if
you are using this type of bootloader/kernel interaction.  Don't force
someone to disable it.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Viresh Kumar <viresh.kumar@linaro.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 08:37:34 +0200	[thread overview]
Message-ID: <20170829063734.GC12198@kroah.com> (raw)
In-Reply-To: <4bec0c3e58f76e06e5305c5ddbab859e2a87935e.1501578037.git.viresh.kumar@linaro.org>

On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> Users must be given an option to discard any constraints set by
> bootloaders. For example, consider that a constraint is set for the LCD
> controller's supply and the LCD driver isn't loaded by the kernel. If
> the user doesn't need to use the LCD device, then he shouldn't be forced
> to honour the constraint.
> 
> We can also think about finer control of such constraints with help of
> some sysfs files, but a kernel parameter is fine to begin with.
> 
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  3 +++
>  drivers/base/boot_constraints/core.c            | 17 +++++++++++++++++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index d9c171ce4190..0706d1b6004d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -426,6 +426,9 @@
>  			embedded devices based on command line input.
>  			See Documentation/block/cmdline-partition.txt
>  
> +	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...

> +
>  	boot_delay=	Milliseconds to delay each printk during boot.
>  			Values larger than 10 seconds (10000) are changed to
>  			no delay (0).
> diff --git a/drivers/base/boot_constraints/core.c b/drivers/base/boot_constraints/core.c
> index 366a05d6d9ba..e0c33b2b216f 100644
> --- a/drivers/base/boot_constraints/core.c
> +++ b/drivers/base/boot_constraints/core.c
> @@ -24,6 +24,17 @@
>  static LIST_HEAD(constraint_devices);
>  static DEFINE_MUTEX(constraint_devices_mutex);
>  
> +static bool boot_constraints_disabled;

Again, this should only be an "enable" type of option, that kicks in if
you are using this type of bootloader/kernel interaction.  Don't force
someone to disable it.

thanks,

greg k-h

  reply	other threads:[~2017-08-29  6:37 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 [this message]
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
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=20170829063734.GC12198@kroah.com \
    --to=gregkh@linuxfoundation.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.