Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <20231003145114.21637-1-brgl@bgdev.pl> <CACRpkdY03QUkHcmyfTTfvVFbmNujW3qg5GcNJ-=8zj_zvGqDeg@mail.gmail.com>
 <CAMRc=Md7QKYqRaytw2xG8hqTmEDmZGxFfDyGZqoE96h-CvmJcw@mail.gmail.com>
 <CACRpkdZkQ8tJz=94rKGB4DcEC0z8HJHieZn5FD+-efRU-897Pw@mail.gmail.com> <CAHp75VfWi91WaJuoW0NWrHH9=KRjOcrwwCeiXhnBd6Wg+o2Qow@mail.gmail.com>
In-Reply-To: <CAHp75VfWi91WaJuoW0NWrHH9=KRjOcrwwCeiXhnBd6Wg+o2Qow@mail.gmail.com>
From:   Bartosz Golaszewski <brgl@bgdev.pl>
Date:   Wed, 4 Oct 2023 11:40:39 +0200
Message-ID: <CAMRc=Mf2820qT=h9GYFyKfG9jQjbFGTgsV4Uv=D-C853hOp79g@mail.gmail.com>
Subject: Re: [PATCH 00/36] pinctrl: don't use GPIOLIB global numberspace in helpers
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Andy Shevchenko <andy@kernel.org>, linux-gpio@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 4, 2023 at 11:36=E2=80=AFAM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Oct 4, 2023 at 11:42=E2=80=AFAM Linus Walleij <linus.walleij@lina=
ro.org> wrote:
> > On Wed, Oct 4, 2023 at 10:12=E2=80=AFAM Bartosz Golaszewski <brgl@bgdev=
.pl> wrote:
> > > What is your view on Andy's and Kent's issues with the _new() name
> > > suffix?
> >
> > We have done similar operations in the past, and it is similar to what
> > Uwe is doing for the moment with the .remove() callbacks.
> >
> > Usually the strategy is employed when the work needs to be spread
> > out over a few merge windows so it is a bit of a marker that "this is
> > in transition".
> >
> > There is the  horror story of this staying around forever and becoming
> > idiomatic: struct napi_struct (include/linux/netdevice.h) where
> > "napi" means "new API" - yeah that could have been handled better...
> >
> > If there is more moaning about it I will simply squash all the patches
> > into one and call it a day - the end result will be the same and no
> > sign of any *_new suffix anywhere. It was still worth it for reviewing
> > the driver changes on a per-driver basis so then it becomes one of
> > those Schopenhauer ladders that you can toss away after climbing
> > it.
>
> You can go with a compromise and name it better from the start, so at
> least the patches that are taking care of renaming back won't be
> needed.

What are you talking about?! The names are *FINE*. I DON'T want to
change them. I want to keep them. The temporary renaming is there to
make the review process easier but the end effect is that the names
stay the same with only the signature changed.

Bart

> Another way to have three or so patches with combined efforts, but still.=
..
>