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 02386ECE58A for ; Mon, 9 Sep 2024 21:20:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Date:To:Cc:From:Subject: References:In-Reply-To:Content-Transfer-Encoding:MIME-Version:Content-Type: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Bpi6DC9py6EX2mtYy1zo3TRuhBtFHGDIAYUhXMy+E4c=; b=oc733kyOXcE9sd3fudVmbnVb4A iLdCE0avoQojcwzvSX6XPrKtD9BxYxCRdRZ+1b/qt6+vYPsoba0jTSBVMx4E6jXiZS2ljZUbK2wub /EZmLOPDabkIn4FxjoE5Xt3qoKET8AzqV2+/9fCozmXq1iXnJ61w0I6r8pbSTs9uewqzrVJPMY5tI AVogi2uv79bwyzefysQIgkhZG5Nze/woOzHgVKSoUzXaiX/o/w51hM+Z2EybrjQwgDd0v8OWaq2p+ WAXyLBN/rNFH10jYdVx+mlHdXzBroaGYBmyD/TJ115oCGX27yEwxp16jThoKGFg2gmJTYeNAE2ybn z74hXuSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1snlnb-00000003Lh3-07AM; Mon, 09 Sep 2024 21:19:51 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1snlmZ-00000003LWi-2cfd for linux-arm-kernel@lists.infradead.org; Mon, 09 Sep 2024 21:18:48 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EAEDBA43E14; Mon, 9 Sep 2024 21:18:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7BE8C4CEC5; Mon, 9 Sep 2024 21:18:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725916725; bh=m+5SkT5EybNjaxvCRkvBg5O1miTtGMUqFVea2R19J2w=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=J/6I3CbDnNTKmJ3L2IF152M/ltoPcO5pFmy+gkca+OT1rP4WbrlaYXtr58+Vpxw87 LkrpSj8boSoQSpmNL4d4en/VfCIwyWsyw50l7ejeJV7+aAbdCKlA18NULD1Baf7kXd S0lxQHfWWmtae2GQAMPVFzv0YAzZnctIsOUZ0rxlY4GYs5e1/uLhp8xZIqAealnVFs +pLWI0oWIP6iw1X14AyJJMEw5svZsWbKqJNh4a5Tget9R2dCRPlzCCRkVjWkh6OSoN x22OuX5oJfC3eM6+/L+GY9AJ1Isiu3gIqMebsuGdobnrLvdcNx/5VxgesPEt7kApwM +cN69JplcUIig== Message-ID: <8fa43530daa941b059b2de1e15dd7773.sboyd@kernel.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20240830130218.3377060-1-claudiu.beznea.uj@bp.renesas.com> <20240830130218.3377060-8-claudiu.beznea.uj@bp.renesas.com> <83fac884d749bda0cf0b346e4e869bc8.sboyd@kernel.org> <951b5c09c3ca2de3f0a28a078084f7dd.sboyd@kernel.org> Subject: Re: [PATCH v3 07/12] arm64: dts: renesas: r9a08g045: Add VBATTB node From: Stephen Boyd Cc: alexandre.belloni@bootlin.com, claudiu beznea , conor+dt@kernel.org, krzk+dt@kernel.org, magnus.damm@gmail.com, mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Claudiu Beznea To: Geert Uytterhoeven Date: Mon, 09 Sep 2024 14:18:43 -0700 User-Agent: alot/0.10 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240909_141847_810521_B881A09C X-CRM114-Status: GOOD ( 24.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Geert Uytterhoeven (2024-09-09 05:11:03) > Hi Stephen, >=20 > On Sat, Sep 7, 2024 at 1:01=E2=80=AFAM Stephen Boyd wr= ote: > > Quoting Geert Uytterhoeven (2024-09-06 00:28:38) > > > > > > My main objections are that (1) this approach is different than the o= ne used > > > for all other external clock inputs on Renesas SoCs, and (2) this req= uires > > > duplicating part of the clocks property in all board DTS files. > > > > Can 'clock-ranges' be used here? Leave the cell as null in the SoC dtsi > > file and then fill it in with clocks property at the parent node. I > > think you'd have to use clock-names for this though. >=20 > "clock-ranges" does not seem to be well-documented... Yeah, I wasn't aware of it for years! >=20 > IUIC, your suggestion is to: > 1. Add "clock-ranges" to the /soc subnode, > 2. Completely leave out the "rtx" clock from the clocks property > of the vbattb@1005c000 node, > 3. Add the following to the board DTS: >=20 > &soc { > clocks =3D <&vbattb_xtal>; > clock-names =3D "rtx"; > }; >=20 > Then, when resolving "rtx" for the vbattb@1005c000 node, > of_parse_clkspec() would iterate up and find the proper vbattb_xtal. > Is that correct? And probably that should be done for other external > clock inputs as well? Sounds about right. >=20 > Still, it looks a bit complicated and un-intuitive. And what about > e.g. carrier boards with a SoM, where some clocks are provided by > the SoM, and some by the carrier? In that case you still have to > override the clock and clock-names properties in the carrier .dts, > thus duplicating all clocks provided by the SoM. This is the same case as the board wanting to override the soc node? When it's a SoM is there a node for the SoM? Is the clock on the SoM? Does this case exist? Hopefully this isn't a straw man. >=20 > So I prefer the original approach, like is done for all other external > SoC clock inputs on Renesas SoCs. >=20 Sure. I'm just suggesting to follow the preferred approach by DT maintainers. I don't feel strongly either way and I'm not the SoC maintainer so feel free to do what you want.