Re: [MAINTAINER SUMMIT] Enforcing API deprecation

Rob Herring
2025-08-27T16:42:15Z

On Wed, Aug 27, 2025 at 10:34 AM Bartosz Golaszewski
<bartosz.golaszewski@linaro.org> wrote:
>
> 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.

I have a similar situation with DT APIs. It's a bit more nuanced than
the GPIO case. There's old APIs which are "don't add new users" or
"think twice before you add a new user". We may never get rid of the
APIs because a) no one wants to fix PPC and Sparc and b) there's
sometimes a need for these lower level functions. It's similar to
using devm_ APIs vs. the non devm_ variants.

Rob