Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings

[Conor Dooley]

On Sat, Jun 20, 2026 at 08:28:03PM +0300, Stefan Dösinger wrote:
> Hi Conor,
> Am Donnerstag, 18. Juni 2026, 22:54:53 Ostafrikanische Zeit schrieb Conor 
> Dooley:
> 
> I think I get the gist of your suggestions. I have a few follow-up questions 
> to make sure I understand things right:
> 
> > I think aux bus makes perfect sense when you have a clock/reset
> > controller, but once you start expanding past that and you have reboot
> > or hwmon or hwspinlock then mfd starts to make sense.
> 
> At what point does it make sense to move the bindings from bindings/clock to 
> bindings/mfd? The controllers are still very clock-heavy. allwinner,*-
> prcm.yaml look like clock, reset, misc controllers in mfd/ whereas 
> ingenic,cgu.yaml, sprd,sc9863a-clk.yaml and da8xx-cfgchip.txt are clock + misc 
> drivers in clock/.

Yeah, to bindings/mfd or bindings/soc/<vendor>. Which I think is mostly
a judgement call. Two of your devices have at least three functions,
which I think is enough to make the claim that it's not just a clock
controller.

> Likewise for the node names: syscon@ or clock-controller@?

If you have syscon in the compatible, then I think it should be syscon
in the node name as it's more general and makes it clear the device
isn't just a clock controller.

> > You'd then have topclock that is a syscon + simple-mfd, matrixclk that is
> > a syscon and lsp that's using the aux bus. The topclock and matrixclock
> > would have dedicated and trivial drivers somewhere that have the mfd_cells
> > and call mfd_add_devices().
> 
> Do I even need simple-mfd? It seems I can add the syscon-reboot node via 
> mfd_cells too by setting .of_compatible. It seems once it has a driver (even a 
> very short one) simple-mfd is misplaced.

If you don't need child nodes in dt, you don't need simple-mfd.
Whether setting of_compatible is a correct thing to do, I do not know,
sorry.

> What about syscon? Topclk needs it for syscon-reboot and the watchdog 
> controls. For the other two I only want a regmap. Afaiu device_node_to_regmap 
> works without a "syscon" compatible. There's also regmap_init_mmio, but afaics 
> I only want this when my driver is the only one using the regmap.

If it is a miscellaneous system register region, then it should be a
syscon. These devices that perform multiple functions like hwspinlock,
clocks and resets fit that bill. Whether or not you "need" it for linux to
work, if it is a correct description of your hardware you need to use
that compatible.

> 
> > Probably the compatibles you've chosen start to make less sense at this
> > point though, but probably "topclk" and "matrixclk" are not what the
> > documentation for this device calls these register regions?
> 
> Yeah I'll rename them top topcrm / matrixcrm / lspcrm. I just stuck to the old 
> names for this email.
> 
> > I think the priority is having something that reflects the hardware
> > accurately, I wouldn't compromise on that just to have the same design
> > for all three drivers.
> 
> As far as I can see the primary difference between mfd_add_devices and simple-
> mfd + child nodes is that the latter makes the MFD composition visible in the 
> device tree and the former keeps it a driver implementation detail. My sense 
> is that the latter is preferred unless a subcomponent of the MFD might be 
> reused in other components - e.g. an ADC is used in PMIC-abc and PMIC-xyz and 
> thus the driver can be reused as well.

Correct. The other reason for doing it the devicetree way is if there
are conflicting property requirements. E.g. two of the same class of
device, like a pair of pin control functions or devices that use
different #address-cells to one another.

Attachment: signature.asc
Description: PGP signature