From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Linus Walleij <linus.walleij@linaro.org>,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing]
Date: Tue, 20 Oct 2015 09:14:55 +0200 [thread overview]
Message-ID: <20151020071454.GE4931@pengutronix.de> (raw)
In-Reply-To: <CAAVeFuKvwYikwjdTHK5Bq+Ot3s3hySe=7e-_8cXFN7tdUV18YA@mail.gmail.com>
Hello,
[trimming list of recipients considerably because of changed topic]
On Tue, Oct 20, 2015 at 08:47:21AM +0900, Alexandre Courbot wrote:
> On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> >> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> >> > It's a bit ironic that you've chosen GPIO as an example there. The
> >> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> >> > gpio descriptor. There's no of_* method.
> >>
> >> Without following all that fwnode discussion:
> >> gpiod_get et al. should work for you here, doesn't it? It just takes a
> >> struct device * and I'm happy with it.
> >
> > What if you don't have a struct device? I had that problem recently
> > when modifying the mvebu PCIe code. The 'struct device' node doesn't
> > contain the GPIOs, it's the PCIe controller. Individual ports on the
> > controller are described in DT as sub-nodes, and the sub-nodes can
> > have a GPIO for card reset purposes. These sub-nodes don't have a
> > struct device.
> >
> > Right now, I'm having to do this to work around this issue:
> >
> > reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
> > if (reset_gpio == -EPROBE_DEFER) {
> > ret = reset_gpio;
> > goto err;
> > }
> >
> > if (gpio_is_valid(reset_gpio)) {
> > unsigned long gpio_flags;
> >
> > port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
> > port->name);
> > if (!port->reset_name) {
> > ret = -ENOMEM;
> > goto err;
> > }
> >
> > if (flags & OF_GPIO_ACTIVE_LOW) {
> > dev_info(dev, "%s: reset gpio is active low\n",
> > of_node_full_name(child));
> > gpio_flags = GPIOF_ACTIVE_LOW |
> > GPIOF_OUT_INIT_LOW;
> > } else {
> > gpio_flags = GPIOF_OUT_INIT_HIGH;
> > }
> >
> > ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
> > port->reset_name);
> > if (ret) {
> > if (ret == -EPROBE_DEFER)
> > goto err;
> > goto skip;
> > }
> >
> > port->reset_gpio = gpio_to_desc(reset_gpio);
> > }
> >
> > Not nice, is it? Not nice to have that in lots of drivers either.
> >
> > However, switching to use any of_* or fwnode_* thing also carries with
> > it another problem: you can't control the name appearing in the
> > allocation, so you end up with a bunch of GPIOs requested with a "reset"
> > name - meaning you lose any identification of which port the GPIO was
> > bound to.
>
> There are a few holes in the gpiod API. I see two solutions here:
>
> 1) extend devm_get_gpiod_from_child() to take an optional name argument
> 2) add a function to explicitly change a GPIO's name
>
> 2) seems to be the most generic solution, would that do the trick?
I would prefer 1) without "optional". A third alternative is to add at
least dev_name(dev) and maybe index to the name where applicable. Also
note that gpiod_request is called with label=NULL (in
fwnode_get_named_gpiod which is used in devm_get_gpiod_from_child), so
/sys/kernel/debug/gpio doesn't even contain "reset". I only see question
marks (using v4.3-rc5).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2015-10-20 7:14 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 8:34 [GIT PULL] On-demand device probing Tomeu Vizoso
2015-10-14 9:26 ` Mark Brown
2015-10-15 11:42 ` Tomeu Vizoso
[not found] ` <1444909328-24761-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2015-10-16 21:23 ` Olof Johansson
2015-10-17 15:19 ` Rob Herring
2015-10-19 16:52 ` Olof Johansson
2015-10-17 6:57 ` Greg Kroah-Hartman
2015-10-17 15:04 ` Rob Herring
2015-10-17 15:47 ` Greg Kroah-Hartman
2015-10-17 16:28 ` Rob Herring
2015-10-17 16:56 ` Greg Kroah-Hartman
2015-10-17 17:54 ` Rob Clark
2015-10-17 18:27 ` Greg Kroah-Hartman
2015-10-17 18:45 ` Rob Clark
2015-10-17 18:59 ` Greg Kroah-Hartman
2015-10-17 19:39 ` Rob Clark
2015-10-17 20:22 ` Greg Kroah-Hartman
2015-10-17 19:04 ` Noralf Trønnes
2015-10-17 19:48 ` Rob Clark
2015-10-18 19:41 ` Mark Brown
2015-10-18 19:29 ` Mark Brown
2015-10-18 19:37 ` Greg Kroah-Hartman
2015-10-18 19:53 ` Mark Brown
2015-10-19 9:44 ` David Woodhouse
2015-10-19 9:52 ` Russell King - ARM Linux
2015-10-19 11:02 ` Mark Brown
2015-10-19 12:35 ` Rob Herring
2015-10-19 12:47 ` David Woodhouse
2015-10-19 14:50 ` Mark Brown
2015-10-19 15:29 ` David Woodhouse
2015-10-19 15:43 ` Russell King - ARM Linux
2015-10-19 18:27 ` Uwe Kleine-König
2015-10-19 18:39 ` Russell King - ARM Linux
2015-10-19 23:47 ` Alexandre Courbot
2015-10-20 7:14 ` Uwe Kleine-König [this message]
2015-10-20 11:12 ` David Woodhouse
2015-10-19 15:58 ` Rob Herring
2015-10-19 21:40 ` Rafael J. Wysocki
2015-10-19 22:58 ` Rob Herring
[not found] ` <CAL_JsqKa3MFJUWKV2KxPE_NmrP2g4dOD3zr+0Kyx4yBkDOg2HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-20 7:56 ` Rafael J. Wysocki
2015-10-20 14:15 ` Rob Herring
[not found] ` <CAL_JsqJuu5_Osqi+X6M6UeRDZFQB+_8riYDF1gvsGayk5-4SFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-20 14:40 ` Alan Stern
2015-10-20 15:36 ` Mark Brown
2015-10-20 16:04 ` Alan Stern
2015-10-20 16:21 ` Tomeu Vizoso
2015-10-20 17:14 ` Alan Stern
2015-10-20 19:35 ` Mark Brown
2015-10-20 23:35 ` Rafael J. Wysocki
2015-10-21 6:15 ` Jean-Francois Moine
2015-10-22 0:54 ` Rafael J. Wysocki
2015-10-22 9:14 ` Tomeu Vizoso
2015-10-27 5:03 ` Rafael J. Wysocki
2015-10-20 23:34 ` Rafael J. Wysocki
2015-10-21 8:55 ` Geert Uytterhoeven
2015-10-21 23:39 ` Rafael J. Wysocki
2015-10-19 16:04 ` Mark Brown
2015-10-19 12:34 ` Tomeu Vizoso
2015-10-19 13:18 ` Russell King - ARM Linux
[not found] ` <20151019131821.GA32532-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-10-19 14:10 ` Tomeu Vizoso
2015-10-19 14:30 ` Russell King - ARM Linux
2015-10-19 15:00 ` Tomeu Vizoso
2015-10-19 15:35 ` Russell King - ARM Linux
2015-10-19 16:21 ` Geert Uytterhoeven
2015-10-19 16:45 ` Russell King - ARM Linux
2015-10-20 15:46 ` Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Russell King - ARM Linux
2015-10-21 3:58 ` Alternative approach to solve the deferred probe Frank Rowand
2015-10-21 8:18 ` Russell King - ARM Linux
2015-10-21 15:36 ` Frank Rowand
2015-10-21 16:55 ` Grygorii Strashko
2015-10-21 17:20 ` Russell King - ARM Linux
2015-10-21 18:13 ` Grygorii Strashko
2015-10-21 18:28 ` Russell King - ARM Linux
2015-10-22 15:12 ` Grygorii Strashko
2015-10-21 18:02 ` Frank Rowand
2015-10-21 18:29 ` Grygorii Strashko
2015-10-21 20:35 ` Russell King - ARM Linux
2015-10-22 0:05 ` Frank Rowand
2015-10-22 13:20 ` Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Mark Brown
[not found] ` <CAAObsKB2BUZ-smid45wOdAQw6h2yNqCydk+azAFNk69ewHJtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-21 15:59 ` [GIT PULL] On-demand device probing Frank Rowand
2015-10-21 16:27 ` Mark Brown
2015-10-21 18:18 ` Frank Rowand
2015-10-21 21:03 ` Mark Brown
2015-10-21 21:12 ` Rob Herring
2015-10-21 21:50 ` Frank Rowand
2015-10-22 9:05 ` Tomeu Vizoso
2015-10-22 14:38 ` Greg Kroah-Hartman
2015-10-22 14:44 ` Greg Kroah-Hartman
[not found] ` <20151022144405.GC21861-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-10-22 15:02 ` Russell King - ARM Linux
2015-10-22 23:33 ` Mark Brown
2015-10-22 18:53 ` Frank Rowand
2015-10-22 19:26 ` Greg Kroah-Hartman
[not found] ` <20151022192639.GC27248-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-10-23 12:28 ` Tomeu Vizoso
[not found] ` <562930AB.1070203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-23 15:45 ` Tim Bird
2015-10-23 16:34 ` Rob Herring
2015-10-24 14:17 ` Rafael J. Wysocki
2015-10-24 22:06 ` Mark Brown
2015-10-25 13:54 ` Rafael J. Wysocki
2015-10-26 1:12 ` Mark Brown
2015-10-26 10:51 ` Michael Turquette
2015-10-26 12:55 ` Tomeu Vizoso
2015-10-26 23:37 ` Rafael J. Wysocki
2015-10-25 19:45 ` Andrew F. Davis
2015-10-24 17:55 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151020071454.GE4931@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=gnurou@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).