linux-kernel - [PATCH] clk: Warn (and therefore taint the kernel) on clk_ignore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20250201-topic-ignore_unused_warn-v1-1-f29db78cea3a@oss.qualcomm.com>
Date: Sat, 01 Feb 2025 17:52:30 +0100
From: Konrad Dybcio <konradybcio@...nel.org>
To: Michael Turquette <mturquette@...libre.com>, 
 Stephen Boyd <sboyd@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>, 
 linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Bjorn Andersson <bjorn.andersson@....qualcomm.com>, 
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: [PATCH] clk: Warn (and therefore taint the kernel) on
 clk_ignore_unused

From: Konrad Dybcio <konrad.dybcio@....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.

Signed-off-by: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
---
 drivers/clk/clk.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cf7720b9172ff223d86227aad144e15375ddfd86..9e2e240efc31f02e4880542370ba773037b733a0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1527,7 +1527,8 @@ static int __init clk_disable_unused(void)
 	struct clk_core *core;
 	int ret;

-	if (clk_ignore_unused) {
+	/* If you need ignore_unused, your platform description is broken / incomplete */
+	if (WARN_ON(clk_ignore_unused)) {
 		pr_warn("clk: Not disabling unused clocks\n");
 		return 0;
 	}

---
base-commit: df4b2bbff898227db0c14264ac7edd634e79f755
change-id: 20250201-topic-ignore_unused_warn-254a966f627a

Best regards,
-- 
Konrad Dybcio <konrad.dybcio@....qualcomm.com>