[PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings.

[Conor Dooley]

On Tue, May 12, 2026 at 12:33:42AM +0300, Stefan Dösinger wrote:
> Hi Conor,
> 
> Thanks for your reply!
> 
> > Am 11.05.2026 um 19:07 schrieb Conor Dooley <conor at kernel.org>:
> > 
> > How come the "matrixclk" has no constraints on clock properties?
> 
> Because I am not sure what the correct/preferred way to express the interface between top and matrix is - see the first question raised in my cover letter.
> 
> In short, matrix potentially consumes all clocks available on the top controller. There is no obvious interface between them, like there is between matrix and LSP. So I see two ways to handle this in the bindings:
> 
> 1) List the top clk inputs, top clk PLL outputs and PLL fractionals as matrix input
> 2) Be quiet about it

Unless you want to model top + matrix as a single node with two register
regions, then list it all. Hiding the relationships is ill-advised IMO.

> 
> It'd be about 20 clocks or so that I know are consumed. The bigger issue than the number of clocks is that my knowledge of the board is from reverse engineering, not proper datasheets, so I might find out that a clock is missing or wrong.
> 
> > Although, these two devices seem too different to be in the same
> > dt-binding. Do they have anyhting in common other than the SoC they are
> > part of?
> 
> No, they don't have anything in common, other than that their concerns are poorly separated in hardware.
> 
> I take it from your question that the preferred way is to have separate bindings for them in this case - I guess separate headers as well as separate yaml files. Is this correct?

Separate headers if you like, separate bindings since the hardware and
binding are completely different between devices.

> The third clock controller - LSP - is nicely separated from the other two. I would not be surprised to see this subsystem of the board show up on a different ZTE board. If top and matrix should have different bindings, LSP certainly should as well.

The "two" I was referring to were the two with constraints, so top and
lsp, so that should answer that!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260512/8091d358/attachment.sig>