linux-kernel - Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent

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: <YAxuE8un+nznqtSx@pendragon.ideasonboard.com>
Date:   Sat, 23 Jan 2021 20:42:27 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Weiyi Lu <weiyi.lu@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        James Liao <jamesjj.liao@...iatek.com>,
        Fan Chen <fan.chen@...iatek.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-clk@...r.kernel.org,
        srv_heupstream@...iatek.com, Biao Huang <biao.huang@...iatek.com>
Subject: Re: [RFC v1] clk: core: support clocks that need to be enabled
 during re-parent

Hi Stephen,

On Tue, Jun 25, 2019 at 08:52:45PM -0700, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-06-25 18:05:22)
> > On Tue, 2019-06-25 at 15:14 -0700, Stephen Boyd wrote:
> > > Quoting Weiyi Lu (2019-06-09 20:44:53)
> > > > When using property assigned-clock-parents to assign parent clocks,
> > > > core clocks might still be disabled during re-parent.
> > > > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled
> > > > during re-parent.
> > > > 
> > > > Signed-off-by: Weiyi Lu <weiyi.lu@...iatek.com>
> > > 
> > > Can you further describe the scenario where this is a problem? Is it
> > > some sort of clk that is enabled by default out of the bootloader and is
> > > then configured to have an 'assigned-clock-parents' property to change
> > > the parent, but that clk needs to be "enabled" so that the framework
> > > turns on the parents for the parent switch?
> > 
> > When driver is built as module(.ko) and install at runtime after the
> > whole initialization stage. Clk might already be turned off before
> > configuring by assigned-clock-parents. For such clock design that need
> > to have clock enabled during re-parent, the configuration of
> > assigned-clock-parents might be failed. That's the problem we have now.
> 
> Great. Please put this sort of information in the commit text.
> 
> > Do you have any suggestion for such usage of clocks? Many thanks.
> 
> Ok, and in this case somehow CLK_OPS_PARENT_ENABLE flag doesn't work? Is
> that because the clk itself doesn't do anything unless it's enabled?  I
> seem to recall that we usually work around this by caching the state of
> the clk parents or frequencies and then when the clk prepare or enable
> op is called we actually write the hardware to change the state. There
> are some qcom clks like this and we basically just use the hardware
> itself to cache the state of the clk while it hasn't actually changed to
> be at that rate, because the clk is not enabled yet.

I'm trying to move the fix to the clock driver itself. Do you have any
pointer to such a clock that I can use as an example ?

> The main concern is that we're having to turn on clks to make things
> work, when it would be best to not turn on clks just so that register
> writes actually make a difference to what the hardware does.

I agree, it's best not to turn the clock on if we can avoid it.

-- 
Regards,

Laurent Pinchart