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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

On Tue, Apr 28, 2026 at 12:13:41PM +0200, Vyacheslav Yurkov wrote:
> 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?

I don't know, that's a question for the clock subsystem folks.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]