Hi,

Thanks for your feedback!

Am Mittwoch, 12. August 2026, 16:15:03 Ostafrikanische Zeit schrieb Lee Jones:
> > +config MFD_ZTE_ZX297520V3_CRM
> > +	tristate "ZTE zx297520v3 Clock and Reset Manager"
> > +	depends on ARCH_ZTE || COMPILE_TEST
> > +	select MFD_CORE
> > +	select REGMAP_MMIO
> 
> Is this used?

Thinking about it: Not in the way the build system cares, so I'll remove it.

The MFD child drivers call device_node_to_regmap(dev->parent->of_node), so a 
MMIO regmap gets constructed for the MFD parent. But since the calls are in 
the child drivers, REGMAP_MMIO shouldn't be needed to build and run this 
particular driver, and the child drivers enable REGMAP_MMIO on their own.


> > + * Copyright (C) 2026 Stefan Dösinger
> 
> Personal copyright, are you sure?
> 
> Is that okay with ZTE?

I'm not affiliated with them. This work is my personal hobby project to have 
some fun and learn things.

I'm not copying code from their kernel dumps either, the quality of the 
drivers there is pretty atrocious.

If ZTE wants to have copyright of the upstream drivers I won't stop them from 
doing the work themselves :-)

> > +enum zx297520v3_parent_type {
> > +      ZX297520V3_INVALID = 0,
> > +      ZX297520V3_TOPCRM,
> > +      ZX297520V3_MATRIXCRM,
> > +      ZX297520V3_LSPCRM,
> 
> None of these are readable.  I suggest you improve the nomenclature.

I saw that most existing drivers use "undecorated" device names, i.e. 
"TOPCRM", "MATRIXCRM", "LSPCRM" in this driver's case. I am concerned that 
"TOPCRM" is generic enough that a (future) global header might define a macro 
or enum value with that name, so I opted to semi-namespace them with the SoC 
name.

Following the example of max*.c, what do you think of TYPE_TOPCRM, 
TYPE_MATRIXCRM etc?

The rest of your comments are clear to me, I'll implement them in the next 
submission.

Cheers,
Stefan