Received-SPF: pass (google.com: domain of linux-kernel+bounces-182566-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 17 May 2024 15:24:55 -0400
From: Frank Li <Frank.li@nxp.com>
To: Conor Dooley <conor@kernel.org>
Cc: Shengjiu Wang <shengjiu.wang@gmail.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Shengjiu Wang <shengjiu.wang@nxp.com>, 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: <ZkevB4ayrYh3qMHu@lizhi-Precision-Tower-5810>
References: <20240514-campus-sibling-21cdf4c78366@spud>
 <b86c83a520f0c45a60249468fa92b1de.sboyd@kernel.org>
 <CAA+D8ANTdvQJVtniyMtqjnJdT4qX+LDGjVuFO6H0RSO+GDw+ng@mail.gmail.com>
 <20240515-unbundle-bubble-8623b495a4f1@spud>
 <ZkT+4yUgcUdB/i2t@lizhi-Precision-Tower-5810>
 <20240516-reversing-demeanor-def651bc82ac@spud>
 <ZkbVa5KvvbnH/tNQ@lizhi-Precision-Tower-5810>
 <20240517-gristle-dealt-56b5299b9cb8@spud>
 <ZkePbZBufOHWQdzM@lizhi-Precision-Tower-5810>
 <20240517-afterglow-sandstone-076e593fedf8@spud>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240517-afterglow-sandstone-076e593fedf8@spud>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ZnRyq2SjaVLm4eCykljM5nXDKhOp5UgrTO09MLLDryOOH/13noS+/r1I/JHH?=
 =?us-ascii?Q?Uscn1Lac6s/cFaFKkZb9lJbQXEo3rs/H1US2OauKzP+7JGmPV3LjdkEauuyn?=
 =?us-ascii?Q?Jemt5uL4jFm1Judwa0ETsdzNi2aWY7tFLDTlIdinGDE9j5xeP4PfbnGDnyjk?=
 =?us-ascii?Q?qsg/VmCcHl2ox7TkVNm+OBh23u5WGPgl1sZTQVNJKu60mq7HJx0zXdQy/UgQ?=
 =?us-ascii?Q?vQgqlq8ghC5e6jktCNsOfmYqcRZF0WDZmTYX7o8CRqXM3e9FqTOSEZIrJJ+Z?=
 =?us-ascii?Q?LpgutGArRfdjKwJje4ahhpfnvEfrO5QE8ymBaXtHF5/uFxjnf5oxjUVE0KXl?=
 =?us-ascii?Q?+c0+oySbb68HiHCqQKx8SV+oeep+Ks7y3msqdVljQqMkcC04FpED75uSFlM8?=
 =?us-ascii?Q?Z8QGM9sWRPCBMEKGTTpedAp9tGIVA4mkB9QAAjrEXPeMgofKQ5OHuJM8aIYV?=
 =?us-ascii?Q?f1eTSMHEjCf2CaWsPdT+vnqB///uTvat9NrLE0adv4YFAjcXydXL/vXnEN46?=
 =?us-ascii?Q?cAlCne+Py+ozuh4IWHLQOrXMok6AfUcjaxL0BFV0eI+gIBhTVwpn9LeBYhvh?=
 =?us-ascii?Q?n0UBjtnVsHa2YB0pGiKb5Cd/Omeq9iup/crHpLD+qq3FWqLP0oMU79HuzzES?=
 =?us-ascii?Q?wTOf8AE9cInf9kWa2QSgrI2eH4smzmS5uf53CoUN3m0w/4lUSkHAfxBamlQ2?=
 =?us-ascii?Q?cpZ4YVdoqkaZgpc7EtNfYCkscYKALoQ5Ie3K05skC27m41KoqL3MUNGWUoQg?=
 =?us-ascii?Q?YccmqhQnGisk5z47hjLlYuLl78hxPuhjnPWXk81AIxr/TSIuwt8cndBL0OF0?=
 =?us-ascii?Q?M+i5XmLRjRQmktT+VbyrQdPOeewcDuD7U+RuXkuOcPwl65Dmql6jhL0LbxQt?=
 =?us-ascii?Q?WZNCr5AUO0D/Frmuu347Xo1kql6CseHe9MHpOxkfEolCi/Bkf3yXJnid7D3U?=
 =?us-ascii?Q?Trk5gMETm2dXAdLjFwhukqMMxRHE2i0Pa3FMvX6OjVggO/Hjc7rF9nHG7paw?=
 =?us-ascii?Q?RvuzWLONRxLvJDABWFealHkOIcVc4pefGiUWk+Sqs04UwJ6Ni22T/+DGrwHe?=
 =?us-ascii?Q?kZNpdBXnMSC5BZ/stmk/IWxBtQmGB8LL8pXf/BKA8R3TFYWeWPnZDbPtuxA4?=
 =?us-ascii?Q?lRWaIHd0UpbIAgJWikkuCNR7MYa03DDWEIrr14Adsz2072gb4GZKTc3WwdX5?=
 =?us-ascii?Q?fTseryxdR6OoSU/YX5ZQ6TNKB8otPNa959uxh+ysXtmzVd5549as+BbOuyVt?=
 =?us-ascii?Q?dFY3z4UJ4YgAF+YiTJEp6AWYBPrjtI9njDRqm/EbccTAVDchBYuruVMfBL97?=
 =?us-ascii?Q?Xp16U91WfFKbBQkv41FxchTmsiouCacbxYVPFnUw9jqj/O/9vdr21aVlRQSx?=
 =?us-ascii?Q?BsChrtZr5dRGKg8AedhSpEc+t3BgvY87Ws4B5bCY659qAUX/AKH1vVf/ixo/?=
 =?us-ascii?Q?kGcWTHsWXsvZ4pa27tsyg6KN6LadG1qvWgMibnbDyc3bOfa8oRvzIYuu7wPI?=
 =?us-ascii?Q?5RJhOhBW4EnRPghpAbmPeof/vIWF5BNAifD+LqCZMpMKof8cXb7WLfnDd/C6?=
 =?us-ascii?Q?6KH4w+nxbozmb/ZyqnhxeZ/lAeP0ThthQ63hwYN1?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d401da57-fa01-4ae0-171b-08dc76a70e69
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9642.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2024 19:25:05.4133
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: R5flTBVNtTztS4X8Cuelr+vCj6ajCjw4wkZobVLGpnnoXlKu7sdJUsO6nL1xMvnMwSkBOpmcLUKEM4fpUQOxFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7197

On Fri, May 17, 2024 at 06:13:21PM +0100, Conor Dooley wrote:
> 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@30e20000 {
> >         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@30e20000 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@30e20000 {
> > 		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.

Thanks for your time. After I did more rearch, especially read your
previous patch:
https://lore.kernel.org/linux-clk/20240424-strangle-sharpener-34755c5e6e3e@spud/

I have better view about auxdev.

Frank

> 
> > A possible benefit may be that Auxdev needn't binding doc for clock and
> > reset node devices.
>