From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32BC2C77B60 for ; Fri, 24 Mar 2023 11:09:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229945AbjCXLJp (ORCPT ); Fri, 24 Mar 2023 07:09:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229908AbjCXLJn (ORCPT ); Fri, 24 Mar 2023 07:09:43 -0400 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EC7312CFA; Fri, 24 Mar 2023 04:09:42 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id r29so1356682wra.13; Fri, 24 Mar 2023 04:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679656180; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:from:to:cc:subject:date:message-id:reply-to; bh=KKGzHAjESOwY5CJ6aIkXRblEUT9vcmLWXQ+M0lRFaT8=; b=hzyILuXnSZ7lMaDYB5rhB/bnNUkufwU6fB5inzHRnGwGUpJquemA3X84Lzp++Y2YJ+ xX92fJNLk8xQHwS1+YxTda7OSm5DtCOvp4pDLhNSgUC+z/fJXup9nphjXvyJHgvtZySv Ing1oEJUNGaC5fkPShiXmhVhP4ZVm14D3SAO1J3Mw26nhpiPZuGPtANkaXRqnth94OzX eWmkntp/5aW21aNCDZJKirG9vn5GmZabE2CYZSk/g1dEY9qxrgIgg/yw5kqOFSzwoNBS JwX3UeufEHb7ANEt7KtJeAKptHBPlTmLr2bfmp8WEFpNkr4PD3Q/FNi6OhewGezr1Z61 Chlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679656180; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KKGzHAjESOwY5CJ6aIkXRblEUT9vcmLWXQ+M0lRFaT8=; b=ly5d+/fL5EKpn7Bp+71iKSRbyO7HkCOSlqRVToPpkQcwQxjoExn2qXhRa6aL2P8VYR L3cn82n8D9kWtW16wyaaCX2aA6PPBslJ8KqtQ1eqA4ewCd18tmzREnRvXWEQ+9yxxZn1 EbYNXUve1JZbDLB3j8Zs/5G+EGgC51UdGWxpiruj70bvj8LntE6DUFbkLIc3+Luxy1qz ezJKwU4NO0MEoxdtsntbn7gEFewHA9RCTbYvSewCzIIyK+mf/QOha5nQ524L5qLN85vo tUrOAiKIiPTT1xR6FGISAj7kHKy9Y89e6s7Y+S3bmjgQoUJSyYfSxhZagl4orQqlJk9B ar6Q== X-Gm-Message-State: AAQBX9f6sUP/obKVPazfcA2R9b+mg0FPaxX/sf6ZLCxXwDWmtsT29Jvx jjOxYpQFGLrRNZTHL2w6/D8= X-Google-Smtp-Source: AKy350ZmBQJTJNYHdzNhp0Qvsm2ha5bci7Pffhjn47i2N4HkGJnSU/0GajVbD8LVTLhlg10uq2ysNw== X-Received: by 2002:a5d:6290:0:b0:2da:53e3:57cf with SMTP id k16-20020a5d6290000000b002da53e357cfmr1959487wru.71.1679656180460; Fri, 24 Mar 2023 04:09:40 -0700 (PDT) Received: from localhost (188.28.8.105.threembb.co.uk. [188.28.8.105]) by smtp.gmail.com with ESMTPSA id a8-20020a056000100800b002d8566128e5sm9760336wrx.25.2023.03.24.04.09.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 04:09:39 -0700 (PDT) References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-56-f6736dec138e@cerno.tech> <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> From: Aidan MacDonald To: Stephen Boyd Cc: Maxime Ripard , Paul Cercueil , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , Jaroslav Kysela , Shawn Guo , Fabio Estevam , Ulf Hansson , Claudiu Beznea , Michael Turquette , Dinh Nguyen , Chunyan Zhang , Manivannan Sadhasivam , Andreas =?utf-8?Q?F=C3=A4rber?= , Jonathan Hunter , Abel Vesa , Charles Keepax , Alessandro Zummo , Peter De Schrijver , Orson Zhai , Alexandre Torgue , Prashant Gaikwad , Liam Girdwood , Alexandre Belloni , Samuel Holland , Matthias Brugger , Richard Fitzgerald , Vinod Koul , NXP Linux Team , Sekhar Nori , Kishon Vijay Abraham I , Linus Walleij , Takashi Iwai , David Airlie , Luca Ceresoli , Jernej Skrabec , Pengutronix Kernel Team , Baolin Wang , David Lechner , Sascha Hauer , Mark Brown , Max Filippov , Geert Uytterhoeven , linux-stm32@st-md-mailman.stormreply.com, alsa-devel@alsa-project.org, linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, linux-mips@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-actions@lists.infradead.org, linux-clk@vger.kernel.org, AngeloGioacchino Del Regno , patches@opensource.cirrus.com, linux-tegra@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Thu, 23 Mar 2023 15:35:30 +0000 In-reply-to: <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org Stephen Boyd writes: > Quoting Maxime Ripard (2022-11-09 03:00:45) >> On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote: >> > >> > Maxime Ripard writes: >> > >> > > Hi, >> > > >> > > On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote: >> > >> > Assigning the parent clock in the DT works once, at boot, but going off >> > what you wrote in the commit message, if the clock driver has a >> > .determine_rate() implementation that *can* reparent clocks then it >> > probably *will* reparent them, and the DT assignment will be lost. >> >> Yes, indeed, but assigned-clock-parents never provided any sort of >> guarantee on whether or not the clock was allowed to reparent or not. >> It's just a one-off thing, right before probe, and a clk_set_parent() >> call at probe will override that just fine. >> >> Just like assigned-clock-rates isn't permanent. >> >> > What I'm suggesting is a runtime constraint that the clock subsystem >> > would enforce, and actively prevent drivers from changing the parent. >> > Either explicitly with clk_set_parent() or due to .determine_rate(). >> > >> > That way you could write a .determine_rate() implementation that *can* >> > select a better parent, but if the DT applies a constraint to fix the >> > clock to a particular parent, the clock subsystem will force that parent >> > to be used so you can be sure the clock is never reparented by accident. >> >> Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't >> too far off from this, it's just ignored by clk_set_parent() for now. I >> guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make >> clk_set_parent handle it, and set that flag whenever >> assigned-clock-parents is set on a clock. >> >> It's out of scope for this series though, and I certainly don't want to >> deal with all the regressions it might create :) >> > > This sounds like a new dt binding that says the assigned parent should > never change. It sounds sort of like gpio hogs. A clock-hogs binding? Ideally we want the clock driver to be able to reparent clocks freely to get the best rate. But we also need some control over that to stop consumers from being reparented in undesired ways. Eg. you might want to make sure the GPU gets its own PLL so it can be reclocked easily, and putting another device on the GPU's PLL could prevent that. The only way to achieve this today is (1) never do any reparenting in the clock driver; and (2) use assigned-clock-parents in the DT to set up the entire clock tree manually. Maxime said that (2) is basically wrong -- if assigned-clock-parents provides no guarantee on what the OS does "after boot" then the OS is pretty much free to ignore it. My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example: clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>; This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy. assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.