From: Quentin Schulz <quentin.schulz@cherry.de>
To: Rogerio Guerra Borin <rogerio.borin@gmail.com>,
Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de, Rogerio Guerra Borin <rogerio.borin@toradex.com>
Subject: Re: [PATCH] cmd: fuse: add switch for quiet operation
Date: Mon, 24 Mar 2025 10:55:39 +0100 [thread overview]
Message-ID: <c45358f6-e84f-4fc6-b5ae-44a3ff5985f1@cherry.de> (raw)
In-Reply-To: <20250317225336.2891974-1-rogerio.borin@toradex.com>
Hi Rogerio,
On 3/17/25 11:53 PM, Rogerio Guerra Borin wrote:
> [You don't often get email from rogerio.borin@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Add switch -q for quiet operation to all fuse subcommands. This helps
> avoid bloating the console with messages that can be distracting to
> users (particularly when the command is employed by scripts and multiple
> fuse values are read/compared/programmed). For example, the "fuse cmp"
> command normally produces five lines of output:
>
> U-Boot # fuse cmp 6 0 0x70af49db
> Comparing bank 6:
>
> Word 0x00000000:
> Value 0x70af49db:0x70af49db
> passed
> U-Boot # echo $?
> 0
>
> But scripts issuing the command do not know or care about that output
> since the command exit code is the only relevant information visible to
> them. With the new switch one can avoid the unnecessary output:
>
> U-Boot # fuse cmp -q 6 0 0x70af49db
> U-Boot # echo $?
> 0
>
I think this is a reasonable expectation. I'm wondering if we shouldn't
think about using the log architecture we have to have a generic
solution rather than expecting each command driver to handle (possibly
in their own way) a quiet flag.
https://docs.u-boot.org/en/latest/develop/logging.html
The idea I have in mind is that we could dynamically set the loglevel
for a specific command driver (or at least for the command subsystem (by
e.g. defining an LOG_CATEGORY LOGC_CMD) and use log_* functions in the
command driver rather than IF_NOT_QUIET() below. This would also allow
different log levels to be used. Maybe there's something to be done with
filters, or something new needs to be added to set the log level for a
category maybe? I don't know, not too verse in our log system.
Another option to have a generic logic would be to depend on an
environment variable instead of needing to expand each command driver's
logic.
Cheers,
Quentin
next prev parent reply other threads:[~2025-03-24 9:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 22:53 [PATCH] cmd: fuse: add switch for quiet operation Rogerio Guerra Borin
2025-03-24 9:55 ` Quentin Schulz [this message]
2025-03-30 19:37 ` Rogerio Guerra Borin
-- strict thread matches above, loose matches on Subject: below --
2025-03-14 19:54 Rogerio Guerra Borin
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=c45358f6-e84f-4fc6-b5ae-44a3ff5985f1@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=rogerio.borin@gmail.com \
--cc=rogerio.borin@toradex.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox