linux-kernel - [PATCH RFC 0/4] clk: re-set required rates during clk_set

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

Message-Id: <20231002-ccf-set-multiple-v1-0-2df5e9eb3738@skidata.com>
Date:   Mon, 02 Oct 2023 11:23:31 +0200
From:   Benjamin Bara <bbara93@...il.com>
To:     Maxime Ripard <mripard@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>
Cc:     Frank Oltmanns <frank@...manns.dev>,
        Adam Ford <aford173@...il.com>, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Benjamin Bara <benjamin.bara@...data.com>
Subject: [PATCH RFC 0/4] clk: re-set required rates during clk_set_rate()

Hi!

This is a spin-off of my initial series[1] with the core-related parts
picked out. Without the core part, the rest of the series only partly
makes sense, therefore I wanted to clarify the state of this first.
That's also the reason why it is marked as RFC for now.

Background:
The CCF is currently very rigid in terms of dealing with multiple rate
changes in a single clk_set_rate() call. However, with the
CLK_SET_RATE_PARENT property, it is very likely that a shared clock has
a couple of children which are changed "by accident" when the common
parent is changed. These children might be clock inputs of hardware
modules, which might have set a required rate previously. These required
rates are most likely still expected after the parent has been changed
by another clock (e.g. a sibling). Currently, it is not very trivial to
get these required rates inside of a clock driver's
{determine,round}_rate() op. Therefore, I think the core should also
participate in the process of ensuring that consumer-set requirements
are still fulfilled after a rate has changed.

Idea:
The idea is to have three rates set per clock, which need to be
considered during the whole process:

1. req_rate: This is the rate required by a consumer. It is set during a
   clk_set_rate() call.
2. new_rate: This is the "new planned rate" for the clock, which it will
   set, once the "finding new rates" process is finished.
3. req_rate_tmp: This rate is set if the clock is "required to change"
   during the process. It basically means that the clock is an ancestor
   of a rate-change trigger.

With these available, the core is able to validate the changed subtree
in a more simple way. It also allows us to re-enter calc_new_rates(),
which is one of the key components of clk_set_rate().

Thanks & regards
Benjamin

[1] https://lore.kernel.org/lkml/20230918-imx8mp-dtsi-v1-0-1d008b3237c0@skidata.com/

---
Benjamin Bara (4):
      clk: only set req_rate if it is set by consumer
      clk: reset new_rates for next run
      clk: introduce req_rate_tmp
      clk: consider rates when calculating subtree

 drivers/clk/clk.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 107 insertions(+), 18 deletions(-)
---
base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6
change-id: 20230927-ccf-set-multiple-3c291416fc98

Best regards,
-- 
Benjamin Bara <benjamin.bara@...data.com>