On 26/03/2026 14:39, Vyacheslav Yurkov wrote:

On 26.03.2026 11:08, Krzysztof Kozlowski wrote:

quoted

quoted

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