[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170131100721.22c2388d@bbrezillon>
Date: Tue, 31 Jan 2017 10:07:21 +0100
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Alexandre Courbot <gnurou@...il.com>,
linux-gpio@...r.kernel.org, linux-input@...r.kernel.org,
Bryan Wu <cooloney@...il.com>,
Richard Purdie <rpurdie@...ys.net>,
Jacek Anaszewski <j.anaszewski@...sung.com>,
linux-leds@...r.kernel.org, Tomi Valkeinen <tomi.valkeinen@...com>,
linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()
On Tue, 31 Jan 2017 00:44:47 -0800
Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> On Tue, Jan 31, 2017 at 09:04:32AM +0100, Boris Brezillon wrote:
> > On Mon, 30 Jan 2017 17:06:07 -0800
> > Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> >
> > > On Mon, Jan 30, 2017 at 04:41:48PM +0100, Boris Brezillon wrote:
> > > > Rename devm_get_gpiod_from_child() into
> > > > devm_fwnode_get_gpiod_from_child() to reflect the fact that this
> > > > function is operating on a fwnode object.
> > >
> > > I believe this is completely pointless rename. Are you planning on
> > > adding devm_of_get_gpiod_from_child()? Or
> > > devm_acpt_get_gpiod_from_child()? (I sure hope not).
> >
> > Of course not.
> >
> > >
> > > Also, on what object? Does it take fwnode as first argument? Or maybe we
> > > should call it devm_dev_const_charp_fwnode_get_gpiod_from_child() so we
> > > know types of all arguments?
> >
> > Linus suggested to rename this function [1]. I personally don't care
> > much about the name, though I agree with Linus that names should be
> > consistent and descriptive. Moreover, he's the maintainer, and I tend
> > to follow maintainers suggestion when I contribute to a specific
> > subsystem.
>
> OK, I did not know that that was Linus' request, my objection still
> stands.
>
> >
> > IIUC, you're concerned about the length of this function name. If I had
> > to drop something it would be the _from_child() suffix, because the
> > function is not even checking that the child parameter is actually a
> > direct child (or a descendant) of device->fwnode.
>
> OK, that sounds better. Actually, we already have
> fwnode_get_named_gpiod(), unfortunately it does not do suffixes
> permutations. There are also no users, except
> devm_get_gpiod_from_child(). So I would:
>
> - rename fwnode_get_named_gpiod() -> static __fwnode_get_named_gpiod()
> - made new fwnode_get_named_gpiod() that did suffix permutation and
> called __fwnode_get_named_gpiod() (or pulled its implementation
> inline)
Sorry but I don't follow you. Why do you need
__fwnode_get_named_gpiod(), and what is the suffix permutation you're
mentioning here?
> - renamed devm_get_gpiod_from_child() ->
> devm_fwnode_get_named_gpiod(dev, fwnode, con_id)
> and called fwnode_get_named_gpiod().
Okay. I'm fine with this name, let's see what Linus says.
>
> This would indeed match the pattern with other fwnode/property handling
> APIs.
>
> Thanks.
>
Powered by blists - more mailing lists