Re: [PATCH] gpio: mvebu: use devm_clk_get_optional_enabled()

[Bartosz Golaszewski]

On Wed, 8 Jul 2026 21:27:09 +0200, Rosen Penev <rosenp@xxxxxxxxx> said:
> On Wed, Jul 8, 2026 at 7:27 AM Andrew Lunn <andrew@xxxxxxx> wrote:
>>
>> On Tue, Jul 07, 2026 at 04:06:51PM -0700, Rosen Penev wrote:
>> > The clock is obtained without doing any sort of cleanup on remove or
>> > anywhere else.
>>
>> Given this is a SoC gpio controller, it is very unlikely it every gets
>> unloaded. There is no remove method, so is it even possible to remove
>> it?
> Not that I know of. My devices don't.

You don't need the .remove() callback or even the module to be loadable to be
able to force-unbind a device.

>>
>> How did you test this?
> I have two mvebu devices currently (sold the third).
>>
>> > -     if (IS_ERR(mvchip->clk))
>> > -             return PTR_ERR(mvchip->clk);
>> > +     if (!mvchip->clk)
>> > +             return -ENODEV;
>>
>> You should not replace one error code with another.
> This section of the code is a result of the older API returning a
> PTR_ERR when clock is missing. New one does not. Reading the code it
> looks like it returns -ENOENT.
>>

So is the clock optional or is it not? The answer determines the correct
clk API to use.

>> This driver has been in use for over 14 years, without anybody having
>> problems with it. The SoCs themselves are EOL. They were used in NAS
>> boxes, which do tend to have a long life, but i doubt there are many
>> left still running a modern kernel.
> Still have one. It's unfortunate that ARM32 userspace is getting
> deprecated by a bunch of tools.
>>
>> Changes like this seems pointless, and just waste everybody's time.
> This was a sashiko tagged issue.

I'm not against refactoring of old drivers, otherwise we'll just let older
code bitrot. I'm fine with this, I just want my question above answered.

Bart