linux-kernel - Re: [RFC] clk: Mark HW enabled clocks as enabled in core

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: <20210126131239.uyolpawk2jfat7z4@fsr-ub1664-175>
Date:   Tue, 26 Jan 2021 15:12:39 +0200
From:   Abel Vesa <abel.vesa@....com>
To:     Sascha Hauer <sha@...gutronix.de>
Cc:     Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        Lucas Stach <l.stach@...gutronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-clk@...r.kernel.org
Subject: Re: [RFC] clk: Mark HW enabled clocks as enabled in core

On 21-01-26 12:51:05, Sascha Hauer wrote:
> On Tue, Jan 26, 2021 at 01:21:36PM +0200, Abel Vesa wrote:
> > Some clocks are already enabled in HW even before the kernel
> > starts to boot. So, in order to make sure that these clocks do not
> > get disabled when clk_disable_unused call is done or when
> > reparenting clocks, we enable them in core on clock registration.
> > Such a clock will have to be registered with CLK_IGNORE_UNUSED flag
> > and also needs to have the is_enabled ops implemented.
> > 
> > Signed-off-by: Abel Vesa <abel.vesa@....com>
> > ---
> >  drivers/clk/clk.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 3d751ae5bc70..26d55851cfa5 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3416,6 +3416,7 @@ static int __clk_core_init(struct clk_core *core)
> >  	int ret;
> >  	struct clk_core *parent;
> >  	unsigned long rate;
> > +	bool is_hw_enabled = false;
> >  	int phase;
> >  
> >  	if (!core)
> > @@ -3558,12 +3559,20 @@ static int __clk_core_init(struct clk_core *core)
> >  		rate = 0;
> >  	core->rate = core->req_rate = rate;
> >  
> > +	/*
> > +	 * If the clock has the CLK_IGNORE_UNUSED flag set and it is already
> > +	 * enabled in HW, enable it in core too so it won't get accidentally
> > +	 * disabled when walking the orphan tree and reparenting clocks
> > +	 */
> > +	if (core->flags & CLK_IGNORE_UNUSED && core->ops->is_enabled)
> > +		is_hw_enabled = clk_core_is_enabled(core);
> > +
> >  	/*
> >  	 * Enable CLK_IS_CRITICAL clocks so newly added critical clocks
> >  	 * don't get accidentally disabled when walking the orphan tree and
> >  	 * reparenting clocks
> >  	 */
> > -	if (core->flags & CLK_IS_CRITICAL) {
> > +	if (core->flags & CLK_IS_CRITICAL || is_hw_enabled) {
> >  		unsigned long flags;
> >  
> >  		ret = clk_core_prepare(core);
> 
> This means that a bootloader enabled clock with CLK_IGNORE_UNUSED flag
> can effectively never be disabled because the prepare/enable count is 1
> without any user. This is the behaviour we want to have with critical
> clocks, but I don't think this is desired for clocks with the
> CLK_IGNORE_UNUSED flag.
> 

Here is the way I see it. Critical clocks means the system can't work
without, so do not ever disable/unprepare. The "ignore unused" flag
tells the core to not do anything to this clock, even if it is unused.
For now, it just leaves the clock alone, but the flag could be used for
some other stuff in the future.

Now, the behavior is entirely different.

For the "critical" clock disable/unprepare, the core does nothing
(returns without calling the disable/unprepare ops).

As for the "ignore unused", the clock can be disabled later on,
which would decrement the prepare/enable counter.
The imx earlycon serial driver could implement a late initcall,
that takes the clocks from the devicetree uart node and disables
them. The user doesn't even count in this situation.

Plus, there is no other reason someone would use the CLK_IGNORE_UNUSED,
other than leaving a clock that is already enabled stay as is (at least,
not with the current implementation). So why not mark it as enabled in 
the core, if the HW says it is enabled ?