From: Brian Masney <bmasney@redhat.com>
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Russell King <linux@armlinux.org.uk>, Lee Jones <lee@kernel.org>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, mfd@lists.linux.dev
Subject: Re: [PATCH v9 05/12] clk: zte: Add Clock registration infrastructure
Date: Wed, 5 Aug 2026 19:15:04 -0400 [thread overview]
Message-ID: <anPD-I9GDyOZSDO7@redhat.com> (raw)
In-Reply-To: <ky2t5IqOTfWMdfZsXE91Gg@gmail.com>
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
next prev parent reply other threads:[~2026-08-05 23:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 20:33 [PATCH v9 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller Stefan Dösinger
2026-08-04 6:37 ` Krzysztof Kozlowski
2026-08-02 20:33 ` [PATCH v9 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 04/12] mfd: zx297520v3: Add a clock and reset MFD driver Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 05/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-08-03 16:03 ` Brian Masney
2026-08-03 17:48 ` Stefan Dösinger
2026-08-05 23:15 ` Brian Masney [this message]
2026-08-03 16:05 ` Brian Masney
2026-08-02 20:33 ` [PATCH v9 06/12] clk: zte: Add regmap-based clocks Stefan Dösinger
2026-08-03 16:08 ` Brian Masney
2026-08-02 20:33 ` [PATCH v9 07/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-08-03 16:14 ` Brian Masney
2026-08-02 20:33 ` [PATCH v9 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 09/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 10/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 11/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-08-02 20:33 ` [PATCH v9 12/12] ARM: dts: zte: Declare zx297520v3 CRM device nodes Stefan Dösinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anPD-I9GDyOZSDO7@redhat.com \
--to=bmasney@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mfd@lists.linux.dev \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=stefandoesinger@gmail.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox