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

Message-ID: <878qri8yol.fsf@bootlin.com>
Date: Fri, 10 Jan 2025 16:40:26 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Maxime Ripard <mripard@...hat.com>
Cc: Stephen Boyd <sboyd@...nel.org>,  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 Maxime,

>> 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 think notifiers are great for customers, but not really adequate for
> the clock drivers tree. Indeed, you can only react to a (sub)tree
> configuration using notifiers, but you can't affect it to try something
> new that would be a better fit.
>
> Like, if we have a PLL A, with two child clocks that are dividers. B is
> initially (exclusively) set to freq X, and then you want to set C to 2X.
>
> The best thing to do is to set A to 2X, and double B's divider. It's
> simple enough, but we have no way to try to negociate that at the
> moment.

Indeed. Do you have something in mind to address this situation (eg. a
new clk provider or core API)?

Thanks,
Miquèl