Quoting AngeloGioacchino Del Regno (2022-09-29 05:50:38)
I've just analyzed this idea a bit more, and there's the outcome.
This driver would be fine, if some MediaTek SoCs weren't shipped with
a bootloader that supports only very small kernels... because then, if
the reset controller is not available at boot time, it's unlikely that
you can probe the eMMC or the uSD, so it won't be possible to actually
compile this driver as a module and load it afterwards.
Please don't misunderstand me: I like the idea of having the MediaTek
SoC sysclk reset controller as a ... reset controller driver but, to
make that work, one fundamental issue must be solved...
If the kernel is configured for, let's say, MT2701 and MT2712, we're
always building in reset controller support for MT7622, 7629, 8135, 8173,
8183, 8186, 8192, 8195 - and this list will grow with MT8188, and others.
Obviously, it's useless to have support for, say, MT7622, if the MT7622
system clock controllers aren't built-in, nor modules.
So, to make this idea to work, we have to find a way to:
1. Build in support only for the required SoC(s)
2. Put the reset index mapping arrays in SoC-specific files, or this
single file driver will see an exponential growth.
Split the reset driver into different files compiled for different SoCs
based on the SoC Kconfig made in step 1.
Wrapping it up - as the driver is right now - we're losing flexibility:
we need to maintain the current flexibility while keeping the improvements
that are made with this proposal.
It should work and your concerns are alleviated?