From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F64129A9 for ; Wed, 5 Apr 2023 14:51:13 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 297162B066F9; Wed, 5 Apr 2023 10:51:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 05 Apr 2023 10:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc: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=1680706262; x=1680713462; bh=12 Dan7+hixlpFENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=hkUfRXi9ZUU/v0L/+I gVrH+uthhloeGbMuMyLFaLPGdmHx+ZfnEv71Adty8UoYbiAE/xjl8u5KqVjg9iph dDL+1SNtFZ1DIoSql0P9/+KZLkrmQQF9uAj4XJ3/r3yzAoVDyU+3UZyu1+aTEPER OWkJxOHbEINNDSPozQUVQlhGFT/1jQ99cutqUong+yuWAY6hka25mlIqIA3GjQ0M xDl9zwU8ch2EEnAt9r2dDdVWFEMDWJMeeAG6cjRIoFxOKPLQyawDWpS1LKq7S1Sc MGSHJpnZvjWdEWmQvJiSBEknGcWQYWFHfj+4DYMwd9wCkAvA7EmYRRWbg1P2K/Fd qCiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1680706262; x=1680713462; bh=12Dan7+hixlpF ENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=lOTStozRcIhNQiVpqSWvy6hRgVXT/ Z8/ftiEBKyaVp1oyePcUHHGpoOaAaw1wd36ZBldHKB440gbnuuWDgL4aZxY4t+D2 JoJRCNbY0NF2d9BzWQZ6I8nmk8bEGEJ52MOxbUnQvnpqprCtvLgw9V0VvdXk8yjW C/YVrE2H0tJEXEaoqCnm6pQNlv7lYnQwjCa/Zg4z9cPIiCtx72SsV2zfomP957up I+sHEZnv3M0+ChpZ9XsHO6Dx8kCKXakzvR1oF5fyxjofwoD6OTcV2p4PzM7eDPWe UjJ4Qg64vq3vbaPOW4sz1a3L5/0xOG6j9Rn4k8PPs7pnugtw7Htymzhvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejuddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtsfertddtudenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeefjeeiueeiheevtddvgfeluedufeeigeeijefhveelfeevueefieehuefg ffetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Apr 2023 10:50:59 -0400 (EDT) Date: Wed, 5 Apr 2023 16:50:56 +0200 From: Maxime Ripard To: Paul Cercueil Cc: Aidan MacDonald , Stephen Boyd , 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: References: <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7uz65y3usvns4hs" Content-Disposition: inline In-Reply-To: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> --i7uz65y3usvns4hs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote: > Le lundi 27 mars 2023 =E0 21:24 +0200, Maxime Ripard a =E9crit=A0: > > 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: > > > > >=20 > > > > > =A0=A0=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > > =A0=A0=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > >=20 > > > > 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? > > >=20 > > > 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. > > >=20 > > > Why would you put such arbitrary limitations into the driver? > >=20 > > 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. >=20 > Probably because if we have to choose between setting policy in the > kernel or in the firmware, it is arguably better to set it in the > firmware. I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently? > Especially when talking about clocks, as the firmware is already the > one programming the boot clocks. I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver. Maxime --i7uz65y3usvns4hs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZC2KyAAKCRDj7w1vZxhR xbx0AQDo/091Al9F55xVR4k44hMshHS0Db7q/bHfCkOFHJG+RwEAxo0zFijQl/Op i9WCXbYvyuKQciwCDCJE5/F+69faAgw= =nWIA -----END PGP SIGNATURE----- --i7uz65y3usvns4hs-- 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 74654C77B6E for ; Wed, 5 Apr 2023 14:51:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 25EA510E0AE; Wed, 5 Apr 2023 14:51:18 +0000 (UTC) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id D5CFC10E0AE for ; Wed, 5 Apr 2023 14:51:15 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 297162B066F9; Wed, 5 Apr 2023 10:51:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 05 Apr 2023 10:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc: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=1680706262; x=1680713462; bh=12 Dan7+hixlpFENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=hkUfRXi9ZUU/v0L/+I gVrH+uthhloeGbMuMyLFaLPGdmHx+ZfnEv71Adty8UoYbiAE/xjl8u5KqVjg9iph dDL+1SNtFZ1DIoSql0P9/+KZLkrmQQF9uAj4XJ3/r3yzAoVDyU+3UZyu1+aTEPER OWkJxOHbEINNDSPozQUVQlhGFT/1jQ99cutqUong+yuWAY6hka25mlIqIA3GjQ0M xDl9zwU8ch2EEnAt9r2dDdVWFEMDWJMeeAG6cjRIoFxOKPLQyawDWpS1LKq7S1Sc MGSHJpnZvjWdEWmQvJiSBEknGcWQYWFHfj+4DYMwd9wCkAvA7EmYRRWbg1P2K/Fd qCiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1680706262; x=1680713462; bh=12Dan7+hixlpF ENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=lOTStozRcIhNQiVpqSWvy6hRgVXT/ Z8/ftiEBKyaVp1oyePcUHHGpoOaAaw1wd36ZBldHKB440gbnuuWDgL4aZxY4t+D2 JoJRCNbY0NF2d9BzWQZ6I8nmk8bEGEJ52MOxbUnQvnpqprCtvLgw9V0VvdXk8yjW C/YVrE2H0tJEXEaoqCnm6pQNlv7lYnQwjCa/Zg4z9cPIiCtx72SsV2zfomP957up I+sHEZnv3M0+ChpZ9XsHO6Dx8kCKXakzvR1oF5fyxjofwoD6OTcV2p4PzM7eDPWe UjJ4Qg64vq3vbaPOW4sz1a3L5/0xOG6j9Rn4k8PPs7pnugtw7Htymzhvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejuddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtsfertddtudenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeefjeeiueeiheevtddvgfeluedufeeigeeijefhveelfeevueefieehuefg ffetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Apr 2023 10:50:59 -0400 (EDT) Date: Wed, 5 Apr 2023 16:50:56 +0200 From: Maxime Ripard To: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Message-ID: References: <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7uz65y3usvns4hs" Content-Disposition: inline In-Reply-To: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Prashant Gaikwad , Alexandre Belloni , Liam Girdwood , Michael Turquette , Sekhar Nori , Alexandre Torgue , dri-devel@lists.freedesktop.org, Jaroslav Kysela , Max Filippov , Thierry Reding , linux-phy@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Abel Vesa , Kishon Vijay Abraham I , Geert Uytterhoeven , Samuel Holland , Chunyan Zhang , Takashi Iwai , linux-tegra@vger.kernel.org, Jernej Skrabec , Jonathan Hunter , Chen-Yu Tsai , NXP Linux Team , Orson Zhai , linux-mips@vger.kernel.org, Luca Ceresoli , linux-rtc@vger.kernel.org, linux-clk@vger.kernel.org, Charles Keepax , Aidan MacDonald , alsa-devel@alsa-project.org, Manivannan Sadhasivam , linux-kernel@vger.kernel.org, Sascha Hauer , linux-actions@lists.infradead.org, Richard Fitzgerald , Mark Brown , linux-mediatek@lists.infradead.org, Baolin Wang , Matthias Brugger , Pengutronix Kernel Team , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Alessandro Zummo , linux-sunxi@lists.linux.dev, Stephen Boyd , patches@opensource.cirrus.com, Peter De Schrijver , Nicolas Ferre , Andreas =?utf-8?Q?F=C3=A4rber?= , linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Vinod Koul , Maxime Coquelin , David Lechner , Shawn Guo , Claudiu Beznea Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --i7uz65y3usvns4hs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote: > Le lundi 27 mars 2023 =E0 21:24 +0200, Maxime Ripard a =E9crit=A0: > > 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: > > > > >=20 > > > > > =A0=A0=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > > =A0=A0=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > >=20 > > > > 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? > > >=20 > > > 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. > > >=20 > > > Why would you put such arbitrary limitations into the driver? > >=20 > > 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. >=20 > Probably because if we have to choose between setting policy in the > kernel or in the firmware, it is arguably better to set it in the > firmware. I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently? > Especially when talking about clocks, as the firmware is already the > one programming the boot clocks. I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver. Maxime --i7uz65y3usvns4hs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZC2KyAAKCRDj7w1vZxhR xbx0AQDo/091Al9F55xVR4k44hMshHS0Db7q/bHfCkOFHJG+RwEAxo0zFijQl/Op i9WCXbYvyuKQciwCDCJE5/F+69faAgw= =nWIA -----END PGP SIGNATURE----- --i7uz65y3usvns4hs-- 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 C888FC7619A for ; Wed, 5 Apr 2023 14:51:22 +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-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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YDdmobpYhzPBert3gE4vXk7BaAPz3W5Wz9R7ypj1e9c=; b=gB3KxKSIfYhS7lHs+XNMkaRe3W uFhleY7O2bCNmDzJLEFokRw5YxWEEiuBlCIW1dPpxvTb5cqXC5yurnDgalSiOD00L4UKXkKarOmDz w+tEjVoxcJGpi6fkiLX/6fnwvrOR++ZQkWPY3clgqqTLlTIbs2Dwbjz7ycB3oaYDj2JOe3MzOkyTl 1ADgrOCQklAGM0TcAXG2qxAB0QruOn2vp4fbGiIwlYrubY0D2qYOWaAJQeNHziQ9DjAFQYvc1uXWS x94EMNKVsrIXn5kMgpSNiLM/sXUgP/Q/qbAXfcS3W/m13sSfn8bfIkAOFJDzUpZZ8GoL62/9RUX5s oTn0TQrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pk4Tq-004jAo-1Q; Wed, 05 Apr 2023 14:51:22 +0000 Received: from wnew3-smtp.messagingengine.com ([64.147.123.17]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pk4Tm-004j9E-0B; Wed, 05 Apr 2023 14:51:19 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 297162B066F9; Wed, 5 Apr 2023 10:51:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 05 Apr 2023 10:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc: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=1680706262; x=1680713462; bh=12 Dan7+hixlpFENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=hkUfRXi9ZUU/v0L/+I gVrH+uthhloeGbMuMyLFaLPGdmHx+ZfnEv71Adty8UoYbiAE/xjl8u5KqVjg9iph dDL+1SNtFZ1DIoSql0P9/+KZLkrmQQF9uAj4XJ3/r3yzAoVDyU+3UZyu1+aTEPER OWkJxOHbEINNDSPozQUVQlhGFT/1jQ99cutqUong+yuWAY6hka25mlIqIA3GjQ0M xDl9zwU8ch2EEnAt9r2dDdVWFEMDWJMeeAG6cjRIoFxOKPLQyawDWpS1LKq7S1Sc MGSHJpnZvjWdEWmQvJiSBEknGcWQYWFHfj+4DYMwd9wCkAvA7EmYRRWbg1P2K/Fd qCiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1680706262; x=1680713462; bh=12Dan7+hixlpF ENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=lOTStozRcIhNQiVpqSWvy6hRgVXT/ Z8/ftiEBKyaVp1oyePcUHHGpoOaAaw1wd36ZBldHKB440gbnuuWDgL4aZxY4t+D2 JoJRCNbY0NF2d9BzWQZ6I8nmk8bEGEJ52MOxbUnQvnpqprCtvLgw9V0VvdXk8yjW C/YVrE2H0tJEXEaoqCnm6pQNlv7lYnQwjCa/Zg4z9cPIiCtx72SsV2zfomP957up I+sHEZnv3M0+ChpZ9XsHO6Dx8kCKXakzvR1oF5fyxjofwoD6OTcV2p4PzM7eDPWe UjJ4Qg64vq3vbaPOW4sz1a3L5/0xOG6j9Rn4k8PPs7pnugtw7Htymzhvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejuddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtsfertddtudenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeefjeeiueeiheevtddvgfeluedufeeigeeijefhveelfeevueefieehuefg ffetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Apr 2023 10:50:59 -0400 (EDT) Date: Wed, 5 Apr 2023 16:50:56 +0200 From: Maxime Ripard To: Paul Cercueil Cc: Aidan MacDonald , Stephen Boyd , 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: References: <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> MIME-Version: 1.0 In-Reply-To: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230405_075118_152238_3B05DEF2 X-CRM114-Status: GOOD ( 42.30 ) 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: multipart/mixed; boundary="===============1458772141371757351==" Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org --===============1458772141371757351== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7uz65y3usvns4hs" Content-Disposition: inline --i7uz65y3usvns4hs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote: > Le lundi 27 mars 2023 =E0 21:24 +0200, Maxime Ripard a =E9crit=A0: > > 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: > > > > >=20 > > > > > =A0=A0=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > > =A0=A0=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > >=20 > > > > 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? > > >=20 > > > 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. > > >=20 > > > Why would you put such arbitrary limitations into the driver? > >=20 > > 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. >=20 > Probably because if we have to choose between setting policy in the > kernel or in the firmware, it is arguably better to set it in the > firmware. I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently? > Especially when talking about clocks, as the firmware is already the > one programming the boot clocks. I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver. Maxime --i7uz65y3usvns4hs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZC2KyAAKCRDj7w1vZxhR xbx0AQDo/091Al9F55xVR4k44hMshHS0Db7q/bHfCkOFHJG+RwEAxo0zFijQl/Op i9WCXbYvyuKQciwCDCJE5/F+69faAgw= =nWIA -----END PGP SIGNATURE----- --i7uz65y3usvns4hs-- --===============1458772141371757351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy --===============1458772141371757351==-- 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 EB619C7618D for ; Thu, 6 Apr 2023 14:27:17 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 90C3FE8A; Thu, 6 Apr 2023 16:26:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 90C3FE8A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1680791235; bh=12Dan7+hixlpFENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; h=Date:From:To:Subject:References:In-Reply-To:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=OvsDY62gx2fP0ezXP8KVNj5xT2r9pQ4PEHQ6j/Jj1+Vh34+CmWfJEYqB0wYT+K6Tz H4xU2+zfW6llRz73NOS0opYXRG57GhXtfydmN5DnjAt279hQfuZbgy7VOzoM+NmkRZ MP0yMNWRbrAU+oFec+A1KzqS0r/M40e+k9eZGe5c= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 85A5FF80246; Thu, 6 Apr 2023 16:26:02 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E83F5F8024C; Wed, 5 Apr 2023 16:51:23 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 744C5F8015B for ; Wed, 5 Apr 2023 16:51:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 744C5F8015B Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=cerno.tech header.i=@cerno.tech header.a=rsa-sha256 header.s=fm3 header.b=hkUfRXi9; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=lOTStozR Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 297162B066F9; Wed, 5 Apr 2023 10:51:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 05 Apr 2023 10:51:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc: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=1680706262; x=1680713462; bh=12 Dan7+hixlpFENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=hkUfRXi9ZUU/v0L/+I gVrH+uthhloeGbMuMyLFaLPGdmHx+ZfnEv71Adty8UoYbiAE/xjl8u5KqVjg9iph dDL+1SNtFZ1DIoSql0P9/+KZLkrmQQF9uAj4XJ3/r3yzAoVDyU+3UZyu1+aTEPER OWkJxOHbEINNDSPozQUVQlhGFT/1jQ99cutqUong+yuWAY6hka25mlIqIA3GjQ0M xDl9zwU8ch2EEnAt9r2dDdVWFEMDWJMeeAG6cjRIoFxOKPLQyawDWpS1LKq7S1Sc MGSHJpnZvjWdEWmQvJiSBEknGcWQYWFHfj+4DYMwd9wCkAvA7EmYRRWbg1P2K/Fd qCiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1680706262; x=1680713462; bh=12Dan7+hixlpF ENmGLL4GqaHPQrKwrlwcpNYaShrlRU=; b=lOTStozRcIhNQiVpqSWvy6hRgVXT/ Z8/ftiEBKyaVp1oyePcUHHGpoOaAaw1wd36ZBldHKB440gbnuuWDgL4aZxY4t+D2 JoJRCNbY0NF2d9BzWQZ6I8nmk8bEGEJ52MOxbUnQvnpqprCtvLgw9V0VvdXk8yjW C/YVrE2H0tJEXEaoqCnm6pQNlv7lYnQwjCa/Zg4z9cPIiCtx72SsV2zfomP957up I+sHEZnv3M0+ChpZ9XsHO6Dx8kCKXakzvR1oF5fyxjofwoD6OTcV2p4PzM7eDPWe UjJ4Qg64vq3vbaPOW4sz1a3L5/0xOG6j9Rn4k8PPs7pnugtw7Htymzhvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejuddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtsfertddtudenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeefjeeiueeiheevtddvgfeluedufeeigeeijefhveelfeevueefieehuefg ffetteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Apr 2023 10:50:59 -0400 (EDT) Date: Wed, 5 Apr 2023 16:50:56 +0200 From: Maxime Ripard To: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Message-ID: References: <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7uz65y3usvns4hs" Content-Disposition: inline In-Reply-To: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> X-MailFrom: maxime@cerno.tech X-Mailman-Rule-Hits: max-recipients X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header Message-ID-Hash: OUOFUAGAZX4GXEHDDS3JUVQMTIR5TWWG X-Message-ID-Hash: OUOFUAGAZX4GXEHDDS3JUVQMTIR5TWWG X-Mailman-Approved-At: Thu, 06 Apr 2023 14:25:59 +0000 CC: Aidan MacDonald , Stephen Boyd , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , 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 X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --i7uz65y3usvns4hs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote: > Le lundi 27 mars 2023 =E0 21:24 +0200, Maxime Ripard a =E9crit=A0: > > 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: > > > > >=20 > > > > > =A0=A0=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > > =A0=A0=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > >=20 > > > > 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? > > >=20 > > > 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. > > >=20 > > > Why would you put such arbitrary limitations into the driver? > >=20 > > 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. >=20 > Probably because if we have to choose between setting policy in the > kernel or in the firmware, it is arguably better to set it in the > firmware. I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently? > Especially when talking about clocks, as the firmware is already the > one programming the boot clocks. I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver. Maxime --i7uz65y3usvns4hs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZC2KyAAKCRDj7w1vZxhR xbx0AQDo/091Al9F55xVR4k44hMshHS0Db7q/bHfCkOFHJG+RwEAxo0zFijQl/Op i9WCXbYvyuKQciwCDCJE5/F+69faAgw= =nWIA -----END PGP SIGNATURE----- --i7uz65y3usvns4hs--