linux-kernel - Re: [PATCH] clk: add sys node to disable unused clk

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <163021444683.2676726.5708766744722496303@swboyd.mtv.corp.google.com>
Date:   Sat, 28 Aug 2021 22:20:46 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Zhipeng Wang <zhipeng.wang_1@....com>, mturquette@...libre.com
Cc:     linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: add sys node to disable unused clk

Quoting Zhipeng Wang (2021-08-13 02:11:18)
> The normal sequence is that the clock provider registers clk to
> the clock framework, and the clock framework manages the clock resources
> of the system. Clk consumers obtain clk through the clock framework API,
> enable and disable clk.
> 
> Not all clk registered through the clock provider will be used
> by the clock consumer, so the clock framework has a function
> late_initcall_sync(clk_disable_unused); disables the unused clk.
> 
> Now we modularize the clock provider and some consumers, which will
> cause late_initcall_sync(clk_disable_unused); cannot work properly, so
> increase the sys node.

Sorry, I honestly don't know what's going on here. The commit text is
describing the clk disable unused logic, and then we're adding a sysfs
attribute without documenting it in Documentation/ABI? And there's one
sentence about modular clks not working properly, but I don't know what
is wrong about it besides it is "wrong".

I've been considering ripping out the late initcall to disable unused
clks. It pretty much only leads to problems. If we want to save power,
then maybe we should have clk providers tell us what clks aren't ever
going to be used unless they're referenced in DT or via some clkdev
lookup and only turn the ones off that are in that list if they're on.