Re: [MAINTAINER SUMMIT] Enforcing API deprecation

Bartosz Golaszewski
2025-08-27T15:07:39Z

On Wed, 27 Aug 2025 at 00:44, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>

[snip]

>
> Perfect is often the enemy of good. Making the new API easier to
> convert to, in the name of making for a smoother development model,
> may be the right thing to do, even if maybe the new API isn't then
> everything you would want it to be.
>
> I suspect Bartosz comes at this from the recent GPIO setting changes,
> and honestly, I do think that could have been done with a coccinelle
> script originally, instead of doing a parallel API at all.
>

No, not at all, that was super easy as the conversions were - for most
part - trivial and while I did catch some new incoming code with the
old callbacks, the whole conversion took 2 or 3 cycles so that wasn't
an issue.

I'm mostly referring to the conversion from global GPIO numbers to
GPIO descriptors. This change is so profound that the two APIs don't
even have much in common (including their implementations) so most of
your points above don't apply: there's a fundamental difference
between requesting a global GPIO number that's a magic value defined
somewhere and getting it through device property accessors. We do, of
course, have a compatibility layer for that but it's janky at best.

This is the conversion that's really challenging and taking years and
the progress is slow because you have to functionally test these
changes. This cannot be automated or coccinelled away because it
touches on providers, consumers and firmware nodes.

And in the process: even really experienced developers (I won't point
fingers :) ) sometimes submit patches using the legacy API which is
something I'd like to avoid, hence this proposal.

Bartosz