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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3BF32C761A6 for ; Mon, 27 Mar 2023 19:24:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U+nKCzE5x8CZ1kcW5tOO/pON5LCkeMRzJvaab+CP1dc=; b=tPVRhbzQBg7kQI k/FPNONaCssCPe1e/7BpwSrDhF1atAI4HReS1b6bw0t7TEv9zkWrK5MNjP+yTiCFOtReWTAoUyOuE ZA1RQWaRr7EuUB0dFYbShktHFha0JpFQKdQwWoJ+xWL4TJy+hTft66hqIPjE3/TK8bdkGbB10jG5H c8kx+bh9zK8O3w4YhfUZ9DRQAjZi7x5WmFqIMpotwJMKoMY32FiMQas3Ugda2j0CG5peKcXcE/hkX m+OP0LSLR3dqw1mpkVcKM7jZq1Z/pXQvSqPisWfpwtSLfm7ihY5bVnXQTiPf6Q7x6wzzIf2UwJCUF nzs035wuH6/9CV+CRq3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pgsSS-00CDGe-2d; Mon, 27 Mar 2023 19:24:44 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pgsSN-00CDDK-2T; Mon, 27 Mar 2023 19:24:41 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id A10135821C9; Mon, 27 Mar 2023 15:24:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 27 Mar 2023 15:24:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1679945075; x=1679952275; bh=rUuK9HXT1QKP+JaV2sHZBw1jLvvNj/LeTVl Vzz2mgnE=; b=Gbu8P4udsMzoUHOjBbc5vfZkP8tmap7dDKr2UbNlg1rixDocDy1 FxnzMOf4IOE2QfpQC16ztGYJPxILJkIxjIgvAYZvE6YKh8ByrZaG/DwGgBebbWeR u897wwvNEQblafmWFWlheo89ARPXU3Y8oogaRB7FitYdT+Ut11wADq6gdu2WovDh Xkmp8I7I9FIQMArX6acMwEXaNFUqd2HKMXcH43MHmPOzshN26/iirV1eH6W3dVXI 8/qFTx4K/XYsgt3TO6s0Awb2KVJUO/QYpQYZyPru8lsOFL1AaMAGCylG/7RBI5k9 jN2zsyhGhjzCZHGorsCFbB/6Ikisoduw5rw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1679945075; x=1679952275; bh=rUuK9HXT1QKP+JaV2sHZBw1jLvvNj/LeTVl Vzz2mgnE=; b=SHHB4k7bT/dpA/WpBJ4y6Me/WnLbpnFXIndTiaB8/gRhPh84gMh BWWBeQ2XwYOIN72SfXrmMvw1Fp7uf/LOu2PSFypexIyJHggZzMGs7l6ee1zSHLSh oDdQ+vdPBe9KNPXErhfHevDOs1nDqM2OVelCWFp97TAwMIVY0/2/h3xlmXqOtiYf EVwH2yJfjFhnXvgqDRNyzHjPstZZOaYq3QFTE2qxYXpu0A46u0Mm1LUIMjT71nea MN2+d/lsVf8chYLWOQNX2owgkOwLov/Ep9ne8iDdinid6yyrileqeAyQzZn48c9N Q0qZYiL21tuinlqT4OtghVeAeGKaikoV2ow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehvddgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthhqredttddtvdenucfhrhhomhepofgr gihimhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtf frrghtthgvrhhnpeetgfelgefggeekkefggfeludeiudffjeffgeevveekjedukedtudeu teefteefgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Mar 2023 15:24:32 -0400 (EDT) Date: Mon, 27 Mar 2023 21:24:30 +0200 From: Maxime Ripard To: Aidan MacDonald Cc: Stephen Boyd , 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 Message-ID: <20230327192430.b2cp3yyrkzy4g4vw@penduick> References: <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230327_122440_145999_20360A9D X-CRM114-Status: GOOD ( 28.70 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote: > >> 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. > > > > I'm generally not a fan of putting all these policies in the device > > tree. Do you have an example where it wouldn't be possible to do exactly > > this from the driver itself? > > I'm confused. What's implicit in the example is clk1 and clk2 might > have *other* possible choices of parent clock and the device tree is > limiting what the OS is allowed to choose. > > Why would you put such arbitrary limitations into the driver? Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic. > They would be different from machine to machine, unless the clock > tree is so simple there is only *one* meaningful way to configure > it. If we look at the device trees we have in-tree, most of the users of assigned-clocks are the same from one board to another. > Most SoCs are complicated enough that there will be tradeoffs > depending on what peripherals you are using (typically a single > machine will not use *every* peripheral device provided by the SoC). We already have APIs to lock parents or rates on a given clock from the consumer. It's far superior (feature-wise) than what the device tree will ever offer because it's code, and it depends on the usage already since an unused driver won't probe. Maxime -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy