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 685EBC04FFE for ; Fri, 17 May 2024 18:17:43 +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=+yGhODdyEG/Clyhhn2J2tQVyc+F4jzmN56Y89U8P094=; b=MBd+b57rXlgumRSUMafCv1P+1p 2VsSUK84LbBxXMWog3B55/cNKO3rkLlqsEZoavTBzfblQzTmfBqCF8nYh1MnFTr7/BkOfIiRzyv2Y 6ifUB7vsszG6TgKFqL6X7/jZAJRJI+hFMggUMvJbLDURcOXfsSQPbFMr5IS6XtFdPdG8c+jBlo4+f z5VcsarD0BWvEl/xcK59IDNsuaR5VZf6R4heBhZF2Y6rNA8SMwOtyf56sTgiRu75AT05UvV/Mlzvi ykA5uXI7/zqlxUQm3RQRx3UakUsiRX55UYoaJJ/XUOGvGUb4YNaVIMyebgqZGuwryaLPrLogNgmqC tkqEBwdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s8297-00000008h7i-2oWF; Fri, 17 May 2024 18:17:33 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s819J-00000008UZo-2F8c for linux-arm-kernel@bombadil.infradead.org; Fri, 17 May 2024 17:13:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=V5wP1GBcIlpyWV4jLebu/jiLDwEJEll3WqfXVjUV9rA=; b=g7FjhI410yCadLB7KFKWiTWl2S FH0Hbh+bnGY4bHhAhIfNVESeQ2K5jJ/hhgoxQJ1Ey0jA9jPp4UYjwIMizWKhzKohovBLqpPZIFcAx qtLXR4bqGcZghoPBldw0w9Tln70amHxuVAfhXrbTmV72yR1Yum4LCWBXwceF+0aMSvMbK7Nr9fNlY DoNkRucWnMLprcksQM3QCmRMLLbtGXqmqetmGID3nS3FUsNvhCBMHryJejNDhat+dlFCPIrQaniOq DHDgxOOx36kRpbGjiDq8JqEJb6frfRNkr+0jpnHjiI1sWFAcz6g885xc1aqRYKtUIuWy6QHPhH+A7 sKNPCRkw==; Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by desiato.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s819D-00000005kqQ-0q9v for linux-arm-kernel@lists.infradead.org; Fri, 17 May 2024 17:13:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B9CE3CE19DF; Fri, 17 May 2024 17:13:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36F22C2BD10; Fri, 17 May 2024 17:13:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715966007; bh=eIB82ShxELVgBdcB/A5n4OiJqzz7D53HQjPat52aDwI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p2eDkI91pFS3fnmKgUUxrplDIkMWNwGS9C/lVsb1VRSG9t8FutGodJhWxij5EFYWs aFw2m0F8zvZFEsx8B6TyjoHMTNxQOzr9HTpxniV2Hs09lGjAFA2+WKlASEU3JVKKqa 25N5906X9zGn44TPQBbp+lyquyPK3uxzP5RKp+wXfCp6mUepK502VzQgOWMkHCNccp Dn/6+hvv8OMF8kk6Z3zVbvrsl7BtBXXbcNuqNAUrXZLPXlSzgjTNKWOBpI1txPlnvz 0wwfcinM1IDUM6NDIz4KMxscp4lkUtuTLygOqPYT28lbGqlweNPRWcnhXyZf+K4ncD ozRd1UhOlRziQ== Date: Fri, 17 May 2024 18:13:21 +0100 From: Conor Dooley To: Frank Li Cc: Shengjiu Wang , Stephen Boyd , Shengjiu Wang , abelvesa@kernel.org, peng.fan@nxp.com, mturquette@baylibre.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, marex@denx.de, linux-clk@vger.kernel.org, imx@lists.linux.dev, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, p.zabel@pengutronix.de Subject: Re: [PATCH v3 3/6] dt-bindings: clock: imx8mp: Add reset-controller sub-node Message-ID: <20240517-afterglow-sandstone-076e593fedf8@spud> References: <1715679210-9588-4-git-send-email-shengjiu.wang@nxp.com> <20240514-campus-sibling-21cdf4c78366@spud> <20240515-unbundle-bubble-8623b495a4f1@spud> <20240516-reversing-demeanor-def651bc82ac@spud> <20240517-gristle-dealt-56b5299b9cb8@spud> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240517_181336_087960_5E0B09F1 X-CRM114-Status: GOOD ( 25.04 ) 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: , Content-Type: multipart/mixed; boundary="===============8410585738042847855==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8410585738042847855== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xt3yTz/9sLzzf4YV" Content-Disposition: inline --xt3yTz/9sLzzf4YV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 17, 2024 at 01:10:05PM -0400, Frank Li wrote: > On Fri, May 17, 2024 at 05:21:32PM +0100, Conor Dooley wrote: > > On Thu, May 16, 2024 at 11:56:27PM -0400, Frank Li wrote: > >=20 > > > Look like it is easy to register auxdev "reset" devices. But I have a > > > problem. How to use it by DT phandle? "reset" devices is service pro= vider. > > > Some client will use it. > > >=20 > > > Generally, reset node will used by other devices nodes. like > > >=20 > > > ABC: reset { > > > compatible=3D"simple-reset"; > > > ... > > > } > > >=20 > > > other node will use "reset =3D <&ABC 0>". If use auxdev, how to get = &ABC > > > in dts file. > >=20 > > Whether or not you use auxdev or any other method etc, does not matter > > in a DT system, the consumer will always have a phandle to the provider > > node: > >=20 > > ABC: whatever { > > compatible =3D "whatever"; > > #clock-cells =3D <...>; > > #reset-cells =3D <...>; > > } > >=20 > > something-else { > > clocks =3D <&ABC ...>; > > resets =3D <&ABC ...>; > > } >=20 >=20 > It goes back to old problem, "reset-cells" will be in "clock-controller". >=20 > clock-controller@30e20000 { > compatible =3D "fsl,imx8mp-audio-blk-ctrl", "syscon", "simple-mfd= "; > reg =3D <0x30e20000 0x10000>; > ... > =09 > #reset-cells =3D <...>; > ^^^ > }; >=20 > If create new "whatever" auxdev bus driver which included two aux devices= ,=20 > (clock and reset).=20 >=20 > it will be similar with mfd. Still need change > clock-controller@30e20000 drivers. >=20 > "Which is I suspect is gonna require a change to your clock driver, > because the range in the existing clock nodes: > audio_blk_ctrl: clock-controller@30e20000 { > compatible =3D "fsl,imx8mp-audio-blk-ctrl"; > reg =3D <0x30e20000 0x10000>; > }; > would then have to move to the mfd parent node, and your clock child > would have a reg property that overlaps the reset region. You'd need to > then define a new binding that splits the range in two - obviously > doable, but significantly more work and more disruptive than using an > auxdev." >=20 > So I don't know why auxdev will be better than mfd. I think Stephen and I have spent enough time trying to explain why using auxdev is beneficial here. I, at least, won't be wasting any more of my (metaphorical) breath. > A possible benefit may be that Auxdev needn't binding doc for clock and > reset node devices. --xt3yTz/9sLzzf4YV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZkeQMQAKCRB4tDGHoIJi 0gYFAPwKc+FHcmVmGrUDsNpNdPs1BSVvTRRziCDnTk17ziMFeAEA6IsAjmQ6/TRJ PymGCZBH+JT2QFCLdgg7f7nFHjsA2go= =fmDE -----END PGP SIGNATURE----- --xt3yTz/9sLzzf4YV-- --===============8410585738042847855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============8410585738042847855==--