linux-kernel - Re: [PATCH v3 3/6] dt-bindings: clock: imx8mp: Add reset-controller sub-node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 17 May 2024 18:13:21 +0100
From: Conor Dooley <conor@...nel.org>
To: Frank Li <Frank.li@....com>
Cc: Shengjiu Wang <shengjiu.wang@...il.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Shengjiu Wang <shengjiu.wang@....com>, abelvesa@...nel.org,
	peng.fan@....com, mturquette@...libre.com, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org, shawnguo@...nel.org,
	s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
	marex@...x.de, linux-clk@...r.kernel.org, imx@...ts.linux.dev,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, p.zabel@...gutronix.de
Subject: Re: [PATCH v3 3/6] dt-bindings: clock: imx8mp: Add reset-controller
 sub-node

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:
> > 
> > > 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 provider.
> > > Some client will use it.
> > > 
> > > Generally, reset node will used by other devices nodes. like
> > > 
> > > ABC: reset {
> > > 	compatible="simple-reset";
> > > 	...
> > > }
> > > 
> > > other node will use "reset = <&ABC 0>".  If use auxdev, how to get &ABC
> > > in dts file.
> > 
> > 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:
> > 
> > ABC: whatever {
> > 	compatible = "whatever";
> > 	#clock-cells = <...>;
> > 	#reset-cells = <...>;
> > }
> > 
> > something-else {
> > 	clocks = <&ABC ...>;
> > 	resets = <&ABC ...>;
> > }
> 
> 
> It goes back to old problem, "reset-cells" will be in "clock-controller".
> 
> clock-controller@...20000 {
>         compatible = "fsl,imx8mp-audio-blk-ctrl", "syscon", "simple-mfd";
>         reg = <0x30e20000 0x10000>;
> 	...
> 	
> 	#reset-cells = <...>;
> 	^^^
>     };
> 
> If create new "whatever" auxdev bus driver which included two aux devices, 
> (clock and reset). 
> 
> it will be similar with mfd. Still need change
> clock-controller@...20000 drivers.
> 
> "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@...20000 {
> 		compatible = "fsl,imx8mp-audio-blk-ctrl";
> 		reg = <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."
> 
> 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.


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)