[PATCH RFC v3 0/5] ZTE zx297520v3 clock bindings and driver

[Philipp Zabel]

Hi Stefan,

On Mi, 2026-06-03 at 23:49 +0300, Stefan Dösinger wrote:
> Hi Philipp,
> 
> Am Mittwoch, 3. Juni 2026, 11:50:14 Ostafrikanische Zeit schrieben Sie:
> > When there is no interaction required when operating the clk/reset
> > bits, I prefer the reset driver sitting in drivers/reset as an aux
> > device, especially when register access can be abstracted via a shared
> > regmap. Some of the reset drivers under drivers/clk just predate the
> > aux bus.
> 
> There are two interactions:
> 
> The register lock because all LSP and at least one TOP register contains both 
> clocks and resets.

That could be solved with regmap.

> Shared register definition: in the case of the LSP clocks breaking up the 
> composite definition would sacrifice readability.

That is a matter of perspective.

I had a harder time validating that the resets[] array is properly
initialized from the two different composite arrays because of the
unordered reset_ids, and some remaining resets[] being filled via code.

It would be much simpler if you split the reset definitions out into a
single, separate, const array, indexed by reset id. In fact,
I would suggest this even if you don't intend to move the reset code.

> Neither of them are insurmountable and I can certainly arrange a separation if 
> asked to - but my preference is to keep them together.

I'll leave this up to the clock maintainers.

regards
Philipp