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

[Conor Dooley]

On Thu, Jun 18, 2026 at 09:59:00PM +0300, Stefan Dösinger wrote:
> Am Donnerstag, 18. Juni 2026, 00:23:56 Ostafrikanische Zeit schrieben Sie:
> 
> > Do you actually need an aux bus here though? Since you have to add
> > simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
> > set the reset controller up with an mfd_cell + devm_mfd_add_devices()
> > instead?
> 
> I'll have to read up on devm_mfd_add_devices; The aux bus was the suggestion 
> of Philipp Zabel. At first sight it sounds to me like they do fairly similar 
> things. I don't see any precedence for [devm_]mfd_add_devices in drivers/clk/.

I think you don't see it because the driver calling mfd_add_devices()
probably isn't in drivers/clk and probably also uses an mfd_cell for the
clock.
There's some in drivers/soc and some in drivers/mfd (I'll be honest and
admit to not knowing what actually drives the placement of the mfd
driver).

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.

> 
> Whatever way I go I'd like to use the same for all 3 clock/reset controllers. 
> So far I only made topclk a simple-mfd. I recently stumbled upon spinlock 
> registers in matrixclk, so I guess I can justify a simple-mfd there too. For 

Just to note, simple-mfd is used when you have child nodes. You don't
need simple-mfd if a device fills multiple roles but doesn't have
children.
Your hwspinlock may not require a child node at all, you can just put
#hwlock-cells into the main node and use mfd_add_devices().

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(). The fact that topclock would be a simple-mfd
has basically no impact - I think the difference is that topclock will
call of_platform_populate() where matrixclk will not.

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?

> lspclk all I can see is clocks and resets and I ran out of unknown registers 
> in there.

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.

I guess the problem you have is that the reset driver is shared? You can
always have more than one way to probe a driver. Because I messed up
stuff in the past, reset-mpfs.c has both aux bus and mfd probing in it,
which could serve as an example for how to have both in one file.

Attachment: signature.asc
Description: PGP signature