linux-kernel - Re: [PATCH 4/5] clk: Add flag to prevent frequency changes when walking subtrees

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: <87msfy8yse.fsf@bootlin.com>
Date: Fri, 10 Jan 2025 16:38:09 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Maxime Ripard <mripard@...hat.com>,  Abel Vesa <abelvesa@...nel.org>,
  Peng Fan <peng.fan@....com>,  Michael Turquette
 <mturquette@...libre.com>,  Shawn Guo <shawnguo@...nel.org>,  Sascha Hauer
 <s.hauer@...gutronix.de>,  Pengutronix Kernel Team
 <kernel@...gutronix.de>,  Fabio Estevam <festevam@...il.com>,  Ying Liu
 <victor.liu@....com>,  Marek Vasut <marex@...x.de>,  Laurent Pinchart
 <laurent.pinchart@...asonboard.com>,  linux-clk@...r.kernel.org,
  imx@...ts.linux.dev,  linux-arm-kernel@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  dri-devel@...ts.freedesktop.org,  Abel
 Vesa <abel.vesa@...aro.org>,  Herve Codina <herve.codina@...tlin.com>,
  Luca Ceresoli <luca.ceresoli@...tlin.com>,  Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>,  Ian Ray <ian.ray@...com>
Subject: Re: [PATCH 4/5] clk: Add flag to prevent frequency changes when
 walking subtrees

Hi Stephen,

>> The idea is: if the flag is set, instead of accepting the new upstream
>> rate and recalculate the downstream rate based on a previously set
>> divider value, we change our divider value to match the same frequency
>> as before. But if we cannot, then we just keep the old way.
>> 
>
> The exclusive rate code could support this if it doesn't already do so.
> If you call clk_set_rate_exclusive(child, <constant rate>) followed by
> clk_set_rate(parent, <new rate>) the core code should try to keep the
> child at the constant rate, or fail the clk_set_rate() call on the
> parent. It should be possible to confirm this with some KUnit tests for
> clk_set_rate_exclusive(). Similarly, if another child, child_B, of the
> parent changes the parent rate, we should speculate the new rate of the
> child_A that's protected and fail if we can't maintain the rate. We need
> to start generating a list of clks that we operate a rate change on to
> support this though, because right now we rely on the stack to track the
> clks that we change the rate of.
>
> Initially we thought that we could do this with clk notifiers. That may
> work here, but I suspect it will be clunky to get working because clk
> notifiers operate on struct clk.

I see, thanks a lot for the feedback, I'll have a look.

Thanks,
Miquèl