Re: [PATCH v5 2/2] clk: Add gpio-locked fixed clock driver

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

On 25.09.2026 13:57, Jerome Brunet wrote:
> On jeu. 17 sept. 2026 at 19:05, Vyacheslav Yurkov <uvv.mail@gmail.com> wrote:
> 
>> On 16.09.2026 15:57, Jerome Brunet wrote:
>>
>>>>>> +/* We can't enable the clock, but the Common Clock Framework calls only
>>>>>> + * enable() not is_enabled()
>>>>>> + */
>>>>>> +static int gpio_locked_clk_enable(struct clk_hw *hw)
>>>>>> +{
>>>>>> +	return gpio_locked_clk_is_enabled(hw);
>>>>>> +}
>>>
>>> You need to explain your problem a bit more because this is not OK. Your
>>> clock should really just provide .is_enabled() AFAICT
>>
>> When a peripheral driver uses devm_clk_get_enabled(), this is resolved
>> to clk_prepare() and clk_enable(). Neither of them check for
>> .is_enabled(). Is that a flaw in the CCF or expected behavior?
>>
> 
> .enable() does return an error on failure. It is up to the provider to
> return one or not. In your case, it will be probably be necessary to on
> the gpio a little.

I'm not sure I understand what you meant.
> Note that if the GPIO can sleep, interacting with the gpio must happen
> in prepare (think i2c gpio devices)

In other words, I should only provide prepare/unprepare instead? Do you 
think is_enabled can also be replaced by is_prepared in this case?

Slava