From: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
Describe device tree binding for virtual clock controller guard.
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
---
.../bindings/clock/clock-controller-guard.yaml | 79 ++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml b/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml
new file mode 100644
index 000000000000..71c2d80de1f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/clock/clock-controller-guard.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Clock Controller Guard
+
+maintainers:
+ - Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
+
+description: |
+ Clock controller that guards upstream clocks and/or GPIO
+ signals and exposes them as a single clock output.
+
+properties:
+ compatible:
+ const: clock-controller-guard
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ description: Input clocks that will be guarded.
+ minItems: 0
+
+ clock-names: Input clock names.
+ minItems: 0
+
+ clock-output-names:
+ description: Names of the clock provided by this controller.
+ minItems: 1
+ items:
+ type: string
+
+ gpios:
+ description: |
+ GPIOs used to control or guard the clocks.
+ minItems: 0
+ maxItems: 32
+
+ gpio-names:
+ description: Names corresponding to each GPIO.
+ minItems: 0
+ maxItems: 32
+
+ items:
+ type: string
+
+required:
+ - compatible
+ - "#clock-cells"
+anyOf:
+ - required:
+ - clocks
+ - required:
+ - gpios
+dependencies:
+ gpio-names: [gpios]
+ clock-names: [clocks]
+
+additionalProperties: false
+
+examples:
+ - |
+ clkctrl: clock-controller {
+ compatible = "clock-controller-guard";
+ #clock-cells = <1>;
+
+ clocks = <&clk0 0>, <&pll 0>;
+
+ gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>,
+ <&gpio0 5 GPIO_ACTIVE_HIGH>,
+ <&gpio1 2 GPIO_ACTIVE_LOW>;
+
+ gpio-names = "gpio0", "gpio1", "gpio2";
+
+ clock-output-names = "clkout0";
+ };
--
2.34.1On Wed, Mar 18, 2026 at 05:43:40PM +0000, Vyacheslav Yurkov wrote:
> Describe device tree binding for virtual clock controller guard.
No idea what this means. Please explain how I would identify this h/w.
We generally don't do bindings for virtual devices and we don't do
single clock bindings (other than some we are stuck with).
>
> Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
> Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> ---
> .../bindings/clock/clock-controller-guard.yaml | 79 ++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml b/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml
> new file mode 100644
> index 000000000000..71c2d80de1f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/clock/clock-controller-guard.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Clock Controller Guard
> +
> +maintainers:
> + - Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> +
> +description: |
> + Clock controller that guards upstream clocks and/or GPIO
> + signals and exposes them as a single clock output.
> +
> +properties:
> + compatible:
> + const: clock-controller-guard
> +
> + "#clock-cells":
> + const: 1
> +
> + clocks:
> + description: Input clocks that will be guarded.
> + minItems: 0
> +
> + clock-names: Input clock names.
> + minItems: 0
> +
> + clock-output-names:
> + description: Names of the clock provided by this controller.
> + minItems: 1
> + items:
> + type: string
> +
> + gpios:
> + description: |
> + GPIOs used to control or guard the clocks.
> + minItems: 0
> + maxItems: 32
> +
> + gpio-names:
> + description: Names corresponding to each GPIO.
> + minItems: 0
> + maxItems: 32
> +
> + items:
> + type: string
> +
> +required:
> + - compatible
> + - "#clock-cells"
> +anyOf:
> + - required:
> + - clocks
> + - required:
> + - gpios
> +dependencies:
> + gpio-names: [gpios]
> + clock-names: [clocks]
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + clkctrl: clock-controller {
> + compatible = "clock-controller-guard";
> + #clock-cells = <1>;
> +
> + clocks = <&clk0 0>, <&pll 0>;
> +
> + gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>,
> + <&gpio0 5 GPIO_ACTIVE_HIGH>,
> + <&gpio1 2 GPIO_ACTIVE_LOW>;
> +
> + gpio-names = "gpio0", "gpio1", "gpio2";
> +
> + clock-output-names = "clkout0";
> + };
>
> --
> 2.34.1
>
On 18.03.2026 23:55, Rob Herring wrote: > On Wed, Mar 18, 2026 at 05:43:40PM +0000, Vyacheslav Yurkov wrote: >> Describe device tree binding for virtual clock controller guard. > No idea what this means. Please explain how I would identify this h/w. > > We generally don't do bindings for virtual devices and we don't do > single clock bindings (other than some we are stuck with). > I described a use case in my cover letter (PATCH 0). Perhaps our approach to tackle the issue is not correct in the first place. The term "virtual clock controller guard" is something we named it, but it's literally just a clock provider which combines several other clocks and input GPIO signals in order for the consumers to check whether they are allowed to probe already or have to wait until the input clocks are enabled. So in essence it's like a helper driver to simplify consumers probe procedure. Does it make sense? If you don't do bindings for virtual HW, how else would you approach this?
On Thu, Mar 19, 2026 at 06:50:52AM +0100, Vyacheslav Yurkov wrote: > On 18.03.2026 23:55, Rob Herring wrote: > > On Wed, Mar 18, 2026 at 05:43:40PM +0000, Vyacheslav Yurkov wrote: > > > Describe device tree binding for virtual clock controller guard. > > No idea what this means. Please explain how I would identify this h/w. > > > > We generally don't do bindings for virtual devices and we don't do > > single clock bindings (other than some we are stuck with). > > > > I described a use case in my cover letter (PATCH 0). Perhaps our approach to > tackle the issue is not correct in the first place. The term "virtual clock > controller guard" is something we named it, but it's literally just a clock > provider which combines several other clocks and input GPIO signals in order > for the consumers to check whether they are allowed to probe already or have > to wait until the input clocks are enabled. Can you explain how this is different to gpio-gate-clock? AFAICT, you're trying to support clocks that are enabled by a gpio, and that's what it is for. > > So in essence it's like a helper driver to simplify consumers probe > procedure. Does it make sense? If you don't do bindings for virtual HW, how > else would you approach this?
On 19.03.2026 17:50, Conor Dooley wrote: >> I described a use case in my cover letter (PATCH 0). Perhaps our approach to >> tackle the issue is not correct in the first place. The term "virtual clock >> controller guard" is something we named it, but it's literally just a clock >> provider which combines several other clocks and input GPIO signals in order >> for the consumers to check whether they are allowed to probe already or have >> to wait until the input clocks are enabled. > > Can you explain how this is different to gpio-gate-clock? AFAICT, you're > trying to support clocks that are enabled by a gpio, and that's what it > is for. > It partially covers the similar use case, but differs in the sense that gpio-gate-clock controls the clock via GPIO (enable/disable), the clock-controller-guard gets the GPIO status signals whether the clock _was_ enabled externally because a CPU has no direct access to the clock. So perhaps the terminology I came up with is not so self-explanatory, that's why I posted it for review and other opinions.
On Mon, Mar 23, 2026 at 02:52:21PM +0100, Vyacheslav Yurkov wrote:
> On 19.03.2026 17:50, Conor Dooley wrote:
>
> > > I described a use case in my cover letter (PATCH 0). Perhaps our approach to
> > > tackle the issue is not correct in the first place. The term "virtual clock
> > > controller guard" is something we named it, but it's literally just a clock
> > > provider which combines several other clocks and input GPIO signals in order
> > > for the consumers to check whether they are allowed to probe already or have
> > > to wait until the input clocks are enabled.
> >
> > Can you explain how this is different to gpio-gate-clock? AFAICT, you're
> > trying to support clocks that are enabled by a gpio, and that's what it
> > is for.
> >
> It partially covers the similar use case, but differs in the sense that
> gpio-gate-clock controls the clock via GPIO (enable/disable), the
> clock-controller-guard gets the GPIO status signals whether the clock _was_
> enabled externally because a CPU has no direct access to the clock. So
> perhaps the terminology I came up with is not so self-explanatory, that's
> why I posted it for review and other opinions.
The binding you've got says "GPIOs used to control or guard the clocks",
which is not what you're saying that is going on in this mail. A more
suitable description would be "GPIOs used to check the status of the
clocks".
I want to see an example dts user for this please.
TBH, I don't understand your driver implementation either and why it has
+static const struct clk_ops clkctrl_guard_ops = {
+ .enable = clkctrl_guard_enable,
+ .disable = clkctrl_guard_disable,
+ .prepare = clkctrl_guard_prepare,
+ .unprepare = clkctrl_guard_unprepare,
+ .is_prepared = clkctrl_guard_is_prepared,
any of these 4 implemented when you have no control over the clock.
I didn't think it was required to call your parent clocks enables in
your own enable either, thought that was handled by the core recursively
calling clk_enable() on clk->parent. The one thing I would expect you to
have implemented ops wise is is_enabled, which you don't have.
Also no sign of any rate acquisition functions, which I thought were
mandatory.
+ .get_parent = clkctrl_guard_get_parent,
+};
On 23.03.2026 21:14, Conor Dooley wrote:
>
> The binding you've got says "GPIOs used to control or guard the clocks",
> which is not what you're saying that is going on in this mail. A more
> suitable description would be "GPIOs used to check the status of the
> clocks".
Agree, the description I provided is not very accurate.
> I want to see an example dts user for this please.
DTS example:
clock_guard: clock_controller_guard {
compatible = "clock-controller-guard";
#clock-cells = <1>;
clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
gpio-names = "gpio-input0", "gpio-input1";
clock-output-names = "clkctrl-guard";
};
custom_device {
compatible = "...";
...
#clock-cells = <1>;
clocks = <&clock_guard 0>;
clock-names = "clock-guard";
};
The driver usage exaple:
clk = devm_clk_get(dev, "clock-guard");
if (IS_ERR(clk))
return dev_err_probe(dev, PTR_ERR(clk), "failed to get clock\n");
ret = clk_prepare_enable(clk);
if (ret) {
dev_warn(dev, "Clock is not ready, %d\n", ret);
return -EPROBE_DEFER;
}
> TBH, I don't understand your driver implementation either and why it has
>
> +static const struct clk_ops clkctrl_guard_ops = {
>
> + .enable = clkctrl_guard_enable,
> + .disable = clkctrl_guard_disable,
> + .prepare = clkctrl_guard_prepare,
> + .unprepare = clkctrl_guard_unprepare,
> + .is_prepared = clkctrl_guard_is_prepared,
>
> any of these 4 implemented when you have no control over the clock.
> I didn't think it was required to call your parent clocks enables in
> your own enable either, thought that was handled by the core recursively
> calling clk_enable() on clk->parent. The one thing I would expect you to
> have implemented ops wise is is_enabled, which you don't have.
> Also no sign of any rate acquisition functions, which I thought were
> mandatory.
>
> + .get_parent = clkctrl_guard_get_parent,
> +};
Good point on .is_enabled, I indeed missed that. As for the rate
acquisition functions I referred to this table
https://docs.kernel.org/driver-api/clk.html#id4 , and it see that
.set_rate is actually optional.
On Thu, Mar 26, 2026 at 10:54:52AM +0100, Vyacheslav Yurkov wrote:
> On 23.03.2026 21:14, Conor Dooley wrote:
>
> >
> > The binding you've got says "GPIOs used to control or guard the clocks",
> > which is not what you're saying that is going on in this mail. A more
> > suitable description would be "GPIOs used to check the status of the
> > clocks".
>
> Agree, the description I provided is not very accurate.
>
> > I want to see an example dts user for this please.
>
> DTS example:
> clock_guard: clock_controller_guard {
> compatible = "clock-controller-guard";
> #clock-cells = <1>;
> clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
Unfortunately, this doesn't contain the part that I wanted to see - who
the providers of these clocks here actually are.
To be frank, I am not sure how this block would know that these clocks
are enabled but their providers do not. I can think of a few ideas for
how this block would know, but I don't understand why the providers
themselves don't, and therefore why you need this gpio to tell you.
> clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
> gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
> gpio-names = "gpio-input0", "gpio-input1";
> clock-output-names = "clkctrl-guard";
> };
>
> custom_device {
> compatible = "...";
> ...
> #clock-cells = <1>;
> clocks = <&clock_guard 0>;
> clock-names = "clock-guard";
> };
>
> The driver usage exaple:
>
> clk = devm_clk_get(dev, "clock-guard");
> if (IS_ERR(clk))
> return dev_err_probe(dev, PTR_ERR(clk), "failed to get clock\n");
>
> ret = clk_prepare_enable(clk);
> if (ret) {
> dev_warn(dev, "Clock is not ready, %d\n", ret);
> return -EPROBE_DEFER;
> }
>
>
> > TBH, I don't understand your driver implementation either and why it has
> >
> > +static const struct clk_ops clkctrl_guard_ops = {
> >
> > + .enable = clkctrl_guard_enable,
> > + .disable = clkctrl_guard_disable,
> > + .prepare = clkctrl_guard_prepare,
> > + .unprepare = clkctrl_guard_unprepare,
> > + .is_prepared = clkctrl_guard_is_prepared,
> >
> > any of these 4 implemented when you have no control over the clock.
> > I didn't think it was required to call your parent clocks enables in
> > your own enable either, thought that was handled by the core recursively
> > calling clk_enable() on clk->parent. The one thing I would expect you to
> > have implemented ops wise is is_enabled, which you don't have.
> > Also no sign of any rate acquisition functions, which I thought were
> > mandatory.
> >
> > + .get_parent = clkctrl_guard_get_parent,
> > +};
>
> Good point on .is_enabled, I indeed missed that. As for the rate acquisition
> functions I referred to this table
> https://docs.kernel.org/driver-api/clk.html#id4 , and it see that .set_rate
> is actually optional.
.set_rate is not rate acquisition. .round_rate and .determine_rate are.
I thought they were mandatory, but for a gate clock I guess they are not
and the parent rate gets used automatically.
On 26/03/2026 10:54, Vyacheslav Yurkov wrote:
> On 23.03.2026 21:14, Conor Dooley wrote:
>
>>
>> The binding you've got says "GPIOs used to control or guard the clocks",
>> which is not what you're saying that is going on in this mail. A more
>> suitable description would be "GPIOs used to check the status of the
>> clocks".
>
> Agree, the description I provided is not very accurate.
>
>> I want to see an example dts user for this please.
>
> DTS example:
> clock_guard: clock_controller_guard {
> compatible = "clock-controller-guard";
> #clock-cells = <1>;
> clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
> clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
> gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
> gpio-names = "gpio-input0", "gpio-input1";
> clock-output-names = "clkctrl-guard";
> };
>
> custom_device {
> compatible = "...";
> ...
> #clock-cells = <1>;
> clocks = <&clock_guard 0>;
> clock-names = "clock-guard";
> };
So a pure SW construct? Device has specific clock inputs but you do not
model them and instead replace with one fake-guard-input.
I don't see how this represents the hardware at all.
Maybe some diagrams would help, assuming we still talk about hardware.
Best regards,
Krzysztof
On 26.03.2026 11:08, Krzysztof Kozlowski wrote:
>>
>> DTS example:
>> clock_guard: clock_controller_guard {
>> compatible = "clock-controller-guard";
>> #clock-cells = <1>;
>> clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
>> clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
>> gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
>> gpio-names = "gpio-input0", "gpio-input1";
>> clock-output-names = "clkctrl-guard";
>> };
>>
>> custom_device {
>> compatible = "...";
>> ...
>> #clock-cells = <1>;
>> clocks = <&clock_guard 0>;
>> clock-names = "clock-guard";
>> };
>
> So a pure SW construct? Device has specific clock inputs but you do not
> model them and instead replace with one fake-guard-input.
>
> I don't see how this represents the hardware at all.
>
> Maybe some diagrams would help, assuming we still talk about hardware.
>
> Best regards,
> Krzysztof
Techincally that's correct, it's a software construct. If this is not a
right place to submit such a helper driver, I'd appreciate a hint what
subsystem is the right one.
I was not sure how to provide a diagram in the mailing list, so I posted
in on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
It is a driver which models dependencies for other drivers. These are
soft or "indirect" dependencies, because we cannot access the FPGA
unless the FPGA_PLL_locked, and GPIO is telling us we are good to go.
Conor, I think this should answer your question as well.
Thanks,
Slava
On Thu, Mar 26, 2026 at 02:39:22PM +0100, Vyacheslav Yurkov wrote:
> On 26.03.2026 11:08, Krzysztof Kozlowski wrote:
>
> > >
> > > DTS example:
> > > clock_guard: clock_controller_guard {
> > > compatible = "clock-controller-guard";
> > > #clock-cells = <1>;
> > > clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
> > > clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
> > > gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
> > > gpio-names = "gpio-input0", "gpio-input1";
> > > clock-output-names = "clkctrl-guard";
> > > };
> > >
> > > custom_device {
> > > compatible = "...";
> > > ...
> > > #clock-cells = <1>;
> > > clocks = <&clock_guard 0>;
> > > clock-names = "clock-guard";
> > > };
> >
> > So a pure SW construct? Device has specific clock inputs but you do not
> > model them and instead replace with one fake-guard-input.
> >
> > I don't see how this represents the hardware at all.
> >
> > Maybe some diagrams would help, assuming we still talk about hardware.
> >
> > Best regards,
> > Krzysztof
>
> Techincally that's correct, it's a software construct. If this is not a
Is it a software construct?
I assume that the PLL status is going to be some lock bit in a register,
and you're got some "hardware" in your FPGA fabric that reads that bit
and sets a GPIO when it gets locked? Or maybe it's even simpler, and
your GPIO just gets set once your custom HDL comes out of reset, which
happens when the PLL locks?
If that's an approximation of what you have, that's not a software
construct.
> right place to submit such a helper driver, I'd appreciate a hint what
> subsystem is the right one.
>
> I was not sure how to provide a diagram in the mailing list, so I posted in
> on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
>
> It is a driver which models dependencies for other drivers. These are soft
> or "indirect" dependencies, because we cannot access the FPGA unless the
> FPGA_PLL_locked, and GPIO is telling us we are good to go.
>
> Conor, I think this should answer your question as well.
Not really, but it gets part of the way there. I want to know what this
provider actually is. I now know it is a PLL, not an off-chip
oscillator, but I know nothing about the interface that you have to it
(or if you have one at all). What compatible string/kernel driver does
it use?
Because SoC-FPGAs can route GPIOs from the SoC part to the FPGA fabric
and use them as if interacting with something off-chip, I'm not sure if
we are dealing with an separate FPGA or a SoC-FPGA. Which is it?
Effectively I want to understand why you cannot just read the lock bit
from the PLL directly. In my experience with *SoC*-FPGAs, things like
PLLs that must lock for the fabric to be usable have a register
interface from which the lock bit can be read, that is of course not
clocked by the PLL output clock and therefore accessible before the
PLL has locked.
I think more info is needed here to guide you on where such a "helper
driver" should be located and what the dt represetation should be.
On 26.03.2026 19:32, Conor Dooley wrote: >> I was not sure how to provide a diagram in the mailing list, so I posted in >> on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1 >> >> It is a driver which models dependencies for other drivers. These are soft >> or "indirect" dependencies, because we cannot access the FPGA unless the >> FPGA_PLL_locked, and GPIO is telling us we are good to go. >> >> Conor, I think this should answer your question as well. > > Not really, but it gets part of the way there. I want to know what this > provider actually is. I now know it is a PLL, not an off-chip > oscillator, but I know nothing about the interface that you have to it > (or if you have one at all). What compatible string/kernel driver does > it use? > > Because SoC-FPGAs can route GPIOs from the SoC part to the FPGA fabric > and use them as if interacting with something off-chip, I'm not sure if > we are dealing with an separate FPGA or a SoC-FPGA. Which is it? > Effectively I want to understand why you cannot just read the lock bit > from the PLL directly. In my experience with *SoC*-FPGAs, things like > PLLs that must lock for the fabric to be usable have a register > interface from which the lock bit can be read, that is of course not > clocked by the PLL output clock and therefore accessible before the > PLL has locked. > > I think more info is needed here to guide you on where such a "helper > driver" should be located and what the dt represetation should be. I really appreciate your feedback on this. Here's an attempt to provide a better exlanation. We have various use cases. Most of the time it's a PLL in the FPGA but it can also be some signal from a custom FPGA IP used to indicate if some preconditions are met and the IP is ready to be used (some kind of inverted reset but exposed by the IP). For a PLL we typically get the signal connected either to a GPIO IP block (altr,pio-1.0) OR to a bit in a custom IP register. In addition, some of the IPs in our design do not have a proper split between registers and IP core, which means that if an external clock and/or PLL lock is missing and we access the registers we won’t ever get an answer and thus stall the CPU. We are using a SoC-FPGA and use some GPIO IP within the FPGA (altr,pio-1.0 for example). The PLL itself doesn't have any registers but the signal indicating that it is locked is available and routed to such a GPIO. The point is that we will have several IPs/drivers that will depend on the same preconditions (clk, gpios being high or low) and we want to use this clk_guard driver as an aggregator for those pre-conditions. Define once, reuse a lot. Slava
On 26/03/2026 14:39, Vyacheslav Yurkov wrote:
> On 26.03.2026 11:08, Krzysztof Kozlowski wrote:
>
>>>
>>> DTS example:
>>> clock_guard: clock_controller_guard {
>>> compatible = "clock-controller-guard";
>>> #clock-cells = <1>;
>>> clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
>>> clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
>>> gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
>>> gpio-names = "gpio-input0", "gpio-input1";
>>> clock-output-names = "clkctrl-guard";
>>> };
>>>
>>> custom_device {
>>> compatible = "...";
>>> ...
>>> #clock-cells = <1>;
>>> clocks = <&clock_guard 0>;
>>> clock-names = "clock-guard";
>>> };
>>
>> So a pure SW construct? Device has specific clock inputs but you do not
>> model them and instead replace with one fake-guard-input.
>>
>> I don't see how this represents the hardware at all.
>>
>> Maybe some diagrams would help, assuming we still talk about hardware.
>>
>> Best regards,
>> Krzysztof
>
> Techincally that's correct, it's a software construct. If this is not a
> right place to submit such a helper driver, I'd appreciate a hint what
> subsystem is the right one.
>
> I was not sure how to provide a diagram in the mailing list, so I posted
> in on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
Diagram of hardware. We talk here about hardware.
>
> It is a driver which models dependencies for other drivers. These are
> soft or "indirect" dependencies, because we cannot access the FPGA
> unless the FPGA_PLL_locked, and GPIO is telling us we are good to go.
DT is not for drivers. It's not about subsystem, but concept. DT
describes hardware.
Certain generic bindings which solve real and common hardware problems
are accepted, but so far I miss what hardware problem are you solving here.
Best regards,
Krzysztof
On Wed, 18 Mar 2026 17:43:40 +0000, Vyacheslav Yurkov wrote: > Describe device tree binding for virtual clock controller guard. > > Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> > Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com> > --- > .../bindings/clock/clock-controller-guard.yaml | 79 ++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/clock/clock-controller-guard.yaml:4:6: [error] string value is redundantly quoted with any quotes (quoted-strings) ./Documentation/devicetree/bindings/clock/clock-controller-guard.yaml:5:10: [error] string value is redundantly quoted with any quotes (quoted-strings) ./Documentation/devicetree/bindings/clock/clock-controller-guard.yaml:28:13: [error] syntax error: mapping values are not allowed here (syntax) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/clock-controller-guard.yaml: ignoring, error parsing file ./Documentation/devicetree/bindings/clock/clock-controller-guard.yaml:28:13: mapping values are not allowed here make[2]: *** Deleting file 'Documentation/devicetree/bindings/clock/clock-controller-guard.example.dts' Documentation/devicetree/bindings/clock/clock-controller-guard.yaml:28:13: mapping values are not allowed here make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/clock/clock-controller-guard.example.dts] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1601: dt_binding_check] Error 2 make: *** [Makefile:248: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.kernel.org/project/devicetree/patch/20260318-feature-clock-guard-v1-2-6137cb4084b7@bruker.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2026 Red Hat, Inc.