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

[Jerome Brunet]

On ven. 25 sept. 2026 at 15:15, Vyacheslav Yurkov <uvv.mail@xxxxxxxxx> wrote:

> On 25.09.2026 13:57, Jerome Brunet wrote:
>> On jeu. 17 sept. 2026 at 19:05, Vyacheslav Yurkov <uvv.mail@xxxxxxxxx> 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.

it will probably be necessary to poll on the gpio a little. (sorry)

>
> 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?

It depends on the GPIO API used. have a look at clk-gpio.c

>
> Slava

-- 
Jerome