[PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
Philipp Zabel
p.zabel at pengutronix.de
Thu Jul 2 02:01:34 PDT 2026
On Di, 2026-06-30 at 11:53 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> > Am 30.06.2026 um 11:27 schrieb Philipp Zabel <p.zabel at pengutronix.de>:
> >
> > I think the MFD driver is unnecessary overhead. Can't you just keep the
> > reset controllers as auxdev and use of_platform_populate() to create
> > devices for clock-controller child nodes such as syscon-reboot?
>
> MFD for top and matrix was the suggestion of Conor:
>
> https://lore.kernel.org/linux-arm-kernel/20260618-fantasy-estimate-6c52edbc6890@spud/
>
> To quote:
>
> > 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.
Note how the example Conor gives is introduced with:
> > Because I messed up stuff in the past, reset-mpfs.c has both aux bus
> > and mfd probing in it, [...]
So while, yes, this is possible, I'd like to avoid it if not necessary.
> I can go either way. To me aux vs mfd seems like a distinction without a difference.
I think that's because the main difference doesn't apply here:
MFD comes from aggregate devices where a shared register space
accessible via a physical bus (which we have) can be partitioned out to
child devices. Reset controls are often just individual registers or
even bits scattered around the CRU register space, so we can't make use
of the MFD framework's IO/IRQ resource partitioning infrastructure at
all.
Auxiliary devices were introduced to separate functionality of a single
device into subsystem drivers (which applies here) for devices that are
not just controlled via direct register access, for example via a
firmware interface. That's not the case here, we usually can just share
a regmap.
Either way, I'd prefer the reset driver to not carry more boilerplate
than actual reset code, so if you can either put all of them into a
single auxiliary_driver or into a single platform_driver, I would be
happier.
regards
Philipp
More information about the linux-arm-kernel
mailing list