[PATCH v9 05/12] clk: zte: Add Clock registration infrastructure
Brian Masney
bmasney at redhat.com
Wed Aug 5 16:15:04 PDT 2026
Hi Stefan,
On Mon, Aug 03, 2026 at 08:48:18PM +0300, Stefan Dösinger wrote:
> I have a long-standing question about tristate/module support for drivers like
> this: I don't think the driver can realistically be unloaded. I have been
> testing driver unloading by removing the UART clocks from the DT (otherwise
> the clock driver is busy) and marking all clocks critical (otherwise
> unloading/unbinding will shut down the UART (and more) and lock me out of the
> system).
>
> I have made it tristate because from early research into clock driver state of
> the art I gathered it was desired, even for drivers necessary for fundamental
> operation [0]. Did I understand this correctly? It also uncovered some linking
> errors that weren't obvious when compiling the driver into the kernel.
Leave it as a tristate since that's how most clk drivers are built. Also
think about this from the standpoint from the perspective of a generic
distro like Fedora or Debian. Support for lots of SoCs will be enabled
in the kernel configuration. Some SoCs that may be deemed to be not as
popular for that distro may have their clk drivers compiled as modules.
(We at least do that in Fedora -- can't speak to Debian.) That way they
are available if needed, however the generic kernel image doesn't have
a huge number of built in clk drivers. Some more popular SoCs where the
distro may run will have these drivers set to built in to help with boot
speed.
Brian
More information about the linux-phy
mailing list