[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Md7QKYqRaytw2xG8hqTmEDmZGxFfDyGZqoE96h-CvmJcw@mail.gmail.com>
Date: Wed, 4 Oct 2023 10:12:20 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Andy Shevchenko <andy@...nel.org>, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 00/36] pinctrl: don't use GPIOLIB global numberspace in helpers
On Tue, Oct 3, 2023 at 11:51 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Tue, Oct 3, 2023 at 4:51 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > We have a set of pinctrl helpers for GPIOLIB drivers that take a number
> > from the global GPIO numberspace as argument. We are trying to get rid
> > of this global numbering. Let's rework these helpers to use the
> > recommended gpio_chip + controller-relative offset instead.
> >
> > This work is split into phases: first let's introduce the new variants
> > of the helpers. Next: let's convert all users one-by-one for easier
> > review. Finally let's remove the old helpers and rename the new variants
> > to take the place of the old ones.
>
> Almost too good attention to process here, I hope you used some
> tooling and didn't do all this by hand...
>
> I reviewed it by applying the lot with b4 on a branch off
> my devel branch, and
>
> git diff devel..HEAD
>
> which shows what the goal of the patches is and since the
> kernel clearly looks better after than before the patches:
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>
> Or I can just merge this branch into my devel (for v6.7)
> branch, and offer you the same as immutable.
> Which is my plan.
>
I'll need to send a v2 because there was an issue with one of the stub
declarations and I think we should let it rest on the list for a week
but eventually I think you should just pick up the entire series and
if anything new for the GPIO tree conflicts then we can deal with
immutable tags.
What is your view on Andy's and Kent's issues with the _new() name
suffix? My argument is that it's just temporary and will be gone once
you apply the entire series. Bikeshedding about a temp name is just
unnecessary churn and _new() is as good as anything else.
Bart
> Shall I just do it?
>
> Yours,
> Linus Walleij
Powered by blists - more mailing lists