Re: [PATCH 2/2] dt-bindings: Add clock guard DT description

From: Krzysztof Kozlowski

Date: Thu Mar 26 2026 - 10:02:45 EST


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