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

[Vyacheslav Yurkov <uvv.mail@gmail.com>]

On 21.04.2026 19:28, Conor Dooley wrote:

>> Before I send a v2 I'd like to clarify a few more things:
>> - I provided a schematics by means of the URL. I believe there's no unified
>> way to provide something like that in the documentation, is there? So the
>> only way to describe it properly would be to summarize the description from
>> the mailing list, right?
> 
> I don't believe anything we have at the moment is what you're looking
> for.
> 
>> - I'm going over the Common Clk Framework again, and perhaps I understood it
>> wrong. You mentioned that I have to implement is_enabled, but I implemented
>> is_prepared. It seems that I just have to move my is_prepared implementation
>> to is_enabled. Does that sound correct?
> 
> Effectively yes, I think.
> 
>> - In my particular use case I don't need enable/disable ops, but to keep the
>> driver generic, I'd probably want to have the bulk_enable implementation
>> inside, because I don't know which clocks are assigned in a device tree. The
> 
> Why don't you know this? I'd expect there to be 1:1 mapping of gpios to
> clocks, with an equal number of input and output clocks, since all
> you're doing is detecting if the clocks are ready to go?
> 
>> clk_core_enable function only enables 1 parent clock, not the the list of
>> parent clocks. Or I'm missing something here?
> 

Thanks for your support. Yes, I talked to the HW team and I have this 
information.

One last important bit, which I'm trying to figure out, is how to notify 
the users of the driver about the state change. I understand that Common 
Clock Framework doesn't support clocks drifting to unlocked state, and 
I'm OK with this limitation. Right now what happens on the clock 
consumer side is that it gets -EPROBE_DEFER when any providers are not 
there or not initialized. But if the state of GPIO is not the expected 
one, then -EBUSY is propagated to the probe of the dependent driver. I 
can also change EBUSY to EPROBE_DEFER, but how to trigger the deferred 
probe again is something I don't know. The only alternative I can think 
of is a call to rmmod / insmod from the userspace.

Is there any other way to achieve this?

Slava