All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: Michael Walle <mwalle@kernel.org>
Cc: Caleb Connolly <caleb.connolly@linaro.org>,
	clamor95@gmail.com, sjg@chromium.org, sumit.garg@linaro.org,
	trini@konsulko.com, u-boot@lists.denx.de
Subject: Re: [PATCH v2] boot: add support for button commands
Date: Thu, 18 Jan 2024 15:33:33 +0100	[thread overview]
Message-ID: <bf263fe8e2cb0bb841efed72372ba954@manjaro.org> (raw)
In-Reply-To: <15c65f2d0d66826cd1cf1c5a18ca7f26@kernel.org>

On 2024-01-18 08:59, Michael Walle wrote:
>> Using CONFIG_EXTRA_ENV_SETTINGS should be good enough to provide
>> the fallback defaults.  However, the users can still mess the things 
>> up,
>> but again, they can do that already in many places.
> 
> I disagree. In my case that is a last resort recovery. And it should
> work in any case. Even if the user has messed up anything (except
> from erasing the bootloader in the SPI flash ;)).

Maybe the solution could be another compile-time option to "lock down" 
the built-in defaults provided through CONFIG_EXTRA_ENV_SETTINGS?  If 
that new option is selected, changes to the environment would make no 
changes to the built-in defaults, i.e. those parts of the environment 
would actually be ignored.

>>> In summary, the registered (compiled-in) command should always take
>>> precedence. If one wants to supply a default command which can be
>>> changed later, that can go via the (compiled-in) default environment.
>> 
>> Sorry, this is a bit confusing to me.  Didn't you write above that
>> the users should be able to change the associated commands through
>> the environment variables?
> 
> I had two kinds of button commands in mind: immutable ones and mutable
> ones. The first can be achieved with compiled-in commands, the second
> with a default environment and environment variables.
> 
> Also, whether a command is a mutable one or not is the decision of
> the developer (or the one who's compiling/configuring u-boot),
> not the user.

I believe that the additional compile-time option, which I proposed 
above, could be extended to specify which of the built-in default 
button-command associations are immutable, and which are allowed to be 
modified through the environment variables.

  reply	other threads:[~2024-01-18 14:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-09 11:51 [PATCH v2] boot: add support for button commands Caleb Connolly
2024-01-10 18:08 ` Dragan Simic
2024-01-10 20:09   ` Caleb Connolly
2024-01-11  9:38     ` Michael Walle
2024-01-18  6:57       ` Dragan Simic
2024-01-18  7:59         ` Michael Walle
2024-01-18 14:33           ` Dragan Simic [this message]
2024-01-18 15:11             ` Michael Walle
2024-01-18 15:14               ` Dragan Simic
2024-02-13 22:32 ` Tom Rini

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=bf263fe8e2cb0bb841efed72372ba954@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=caleb.connolly@linaro.org \
    --cc=clamor95@gmail.com \
    --cc=mwalle@kernel.org \
    --cc=sjg@chromium.org \
    --cc=sumit.garg@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.