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

[Vyacheslav Yurkov]

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.

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