From: Stephen Boyd <sboyd@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>,
Michael Turquette <mturquette@baylibre.com>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Subject: Re: [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore_unused
Date: Mon, 03 Mar 2025 14:48:45 -0800 [thread overview]
Message-ID: <93b5004dacfe1151ca3abbb0fa31eaa6.sboyd@kernel.org> (raw)
In-Reply-To: <20250201-topic-ignore_unused_warn-v1-1-f29db78cea3a@oss.qualcomm.com>
Quoting Konrad Dybcio (2025-02-01 08:52:30)
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> If any sort of ignore_unused is in place, it means one of:
>
> * power is going to waste
> * the platform description is incomplete (missing consumer-provider
> relationships)
> * the platform description is just broken
>
> Many people will happily declare their job done when a platform
> magically happens to work as they make use of bootloader-enabled
> resources, which then leads to double or triple the amount of work
> of another person, as they attempt to reduce the unnecessary power
> drainage and/or ensure stabiility throughout a suspend-resume cycle.
>
> Issue a good ol' warning (and taint the kernel) to make such cases
> obvious and hopefully draw more attention to it. This way, it'll be
> easier to avoid effectively untested code or DT description getting
> merged into the kernel, or worse, going into production.
>
> The clock subsystem plays a crucial part in this quest, as even if
> the clock controllers themselves don't draw a lot of power when on
> (comparatively), improper description of clock requirements has been
> the #1 cause of incomplete/incorrect devicetree bindings in my
> experience.
What is a user supposed to do about this warning stack? We already print
a warning. I don't see us dumping the stack when a driver is unfinished
and doesn't implement runtime PM to save power.
next prev parent reply other threads:[~2025-03-03 22:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-01 16:52 [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore_unused Konrad Dybcio
2025-03-03 22:48 ` Stephen Boyd [this message]
2025-03-03 23:16 ` Florian Fainelli
2025-03-03 23:17 ` Dmitry Baryshkov
2025-03-04 19:34 ` Stephen Boyd
2025-05-22 19:47 ` Konrad Dybcio
2025-06-03 0:31 ` Brian Masney
2025-06-03 1:20 ` Bjorn Andersson
2025-06-03 1:23 ` Bjorn Andersson
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=93b5004dacfe1151ca3abbb0fa31eaa6.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mturquette@baylibre.com \
/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.