On Tue, Oct 03, 2023 at 08:07:05PM +0200, Bartosz Golaszewski wrote: > On Tue, Oct 3, 2023 at 5:24 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > On Tue, Oct 03, 2023 at 06:17:27PM +0300, Andy Shevchenko wrote: > > > On Tue, Oct 3, 2023 at 6:02 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > On Tue, Oct 03, 2023 at 04:50:42PM +0200, Bartosz Golaszewski wrote: > > > > > > ... > > > > > > > I agree with the change in principle, just not comfortable with the naming. > > > > > > +1 here. I proposed some names, have you seen my comment(s)? > > > > > > > I have now - any of those work for me. > > Whichever is consistent with what we are using for gpiochip functions in > > gpiolib would make most sense to me. > > > > Does it really matter? It's not here to stay, it's temporary and > exists only until the whole series is applied - which given that it's > limited to gpio and pinctrl, shouldn't take more than one release > cycle. > > There are plenty of examples of this naming convention for temporary > symbols - there's even an ongoing effort to replace all .remove() > callbacks with .remove_new() which will then be changed back to > .remove() treewide. > This was the only patch that I was included into, so I didn't realise there was a treewide rename at the end. Even so, using _new suffix for that purpose is poor (well pinctrl_gpio_free_new() did draw a laugh, but other than that...). Perhaps use something specific to the patch series so it is clear what its purpose is? Cheers, Kent.