From: Quentin Schulz <quentin.schulz@cherry.de>
To: Quentin Schulz <foss+uboot@0leil.net>,
Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
u-boot@lists.denx.de
Subject: Re: [PATCH] dm: core: downgrade some dm_warn messages to log_debug()
Date: Thu, 17 Oct 2024 17:09:43 +0200 [thread overview]
Message-ID: <b62ddc9c-ef61-4ab9-a00d-5ea4a60e40c0@cherry.de> (raw)
In-Reply-To: <20241017-clambake-trekker-048460185316@thorsis.com>
Hi Alex,
On 10/17/24 4:56 PM, Alexander Dahl wrote:
> Hello Quentin,
>
> Am Tue, Oct 15, 2024 at 04:32:14PM +0200 schrieb Quentin Schulz:
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> People complained that enabling (SPL_)DM_WARN was now totally unusable
>> due to the amount of messages printed on the console.
>>
>> Let's downgrade the log level of some messages that are clearly not on
>> the error path.
>>
>> Note that there's one pr_debug in there, because it is followed by
>> pr_cont so it made sense to reuse the same family of functions.
>>
>> Reported-by: Alexander Dahl <ada@thorsis.com>
>> Fixes: 6afdb1585112 ("dm: core: migrate debug() messages to use dm_warn")
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
>> Note that I am not entirely sure about the "not found" and "not large
>> enough" changes there.
>>
>> Another note, %#x isn't handled by tinyprintf so it just prints "x"
>> instead of the value.
>>
>> Finally, I don't know how one can enable LOG_DEBUG level without
>> enabling DEBUG which enables assert() so I just tested that by removing
>> the #define DEBUG in include/log.h :)
>> ---
>> drivers/core/of_access.c | 36 ++++++++++++-------------
>> drivers/core/of_addr.c | 26 +++++++++---------
>> drivers/core/of_extra.c | 6 ++---
>> drivers/core/ofnode.c | 68 ++++++++++++++++++++++++------------------------
>> 4 files changed, 68 insertions(+), 68 deletions(-)
>>
>> diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
>> index d05be273e7bbb68c3ad82ef4c1c036ae7f68ae61..77acd76626257b6da95a27d107052ff8800c2b67 100644
>> --- a/drivers/core/of_access.c
>> +++ b/drivers/core/of_access.c
>> @@ -490,17 +490,17 @@ int of_read_u8(const struct device_node *np, const char *propname, u8 *outp)
>> {
>> const u8 *val;
>>
>> - dm_warn("%s: %s: ", __func__, propname);
>> + log_debug("%s: %s: ", __func__, propname);
>
> Printing __func__ when using log_* functions, is redundant, isn't it?
> You can enabling printing the function name through the logging
> framework, right?
>
Only if LOGF_FUNC symbol is enabled, if I understood correctly. Not an
excuse but:
$ git grep -o "log.*__func__" | wc -l
202
So there are a "few" other places doing that. Will let Simon decide on
that one, no personal opinion.
>> if (!np)
>> return -EINVAL;
>> val = of_find_property_value_of_size(np, propname, sizeof(*outp));
>> if (IS_ERR(val)) {
>> - dm_warn("(not found)\n");
>> + log_debug("(not found)\n");
>> return PTR_ERR(val);
>
> What about using log_msg_ret() instead in these cases?
>
log_msg_ret will log with LOGL_ERR and not LOGL_DEBUG if
LOG_ERROR_RETURN symbol is enabled, otherwise it'll simply not be
printed. It's a change of behavior/expectation here.
If we go this route we should at least make this a bit more useful by
adding the propname to the error message since it would be printed with
log_debug() at the beginning of the function, and the log level wouldn't
match. Also, this means that enabling debug log level but not enabling
LOG_ERROR_RETURN would basically print the first log_debug() and nothing
else in case it fails. A choice to be made but it's a bit more complex
than the one above.
Cheers,
Quentin
next prev parent reply other threads:[~2024-10-17 15:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 14:32 [PATCH] dm: core: downgrade some dm_warn messages to log_debug() Quentin Schulz
2024-10-16 11:31 ` Quentin Schulz
2024-10-17 14:56 ` Alexander Dahl
2024-10-17 15:09 ` Quentin Schulz [this message]
2024-10-27 17:16 ` Simon Glass
2024-10-28 10:04 ` Quentin Schulz
2024-10-29 22:28 ` 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=b62ddc9c-ef61-4ab9-a00d-5ea4a60e40c0@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=foss+uboot@0leil.net \
--cc=sjg@chromium.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.