All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] gpio: of: Allow overriding the device node
@ 2016-07-05 12:11 Thierry Reding
  2016-07-05 13:10 ` Alexandre Courbot
  2016-07-05 15:25 ` Linus Walleij
  0 siblings, 2 replies; 5+ messages in thread
From: Thierry Reding @ 2016-07-05 12:11 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot; +Cc: linux-gpio, linux-tegra, linux-kernel

From: Thierry Reding <treding@nvidia.com>

When registering a GPIO chip, drivers can override the device tree node
associated with the chip by setting the chip's ->of_node field. If set,
this field is supposed to take precedence over the ->parent->of_node
field, but the code doesn't actually do that.

Commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data") exposes this because it now no longer matches on the
GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
is set using the procedure described above.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpio/gpiolib.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 47a3cc0e437b..eae7664b2723 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1047,13 +1047,14 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
 	if (chip->parent) {
 		gdev->dev.parent = chip->parent;
 		gdev->dev.of_node = chip->parent->of_node;
-	} else {
+	}
+
 #ifdef CONFIG_OF_GPIO
 	/* If the gpiochip has an assigned OF node this takes precedence */
-		if (chip->of_node)
-			gdev->dev.of_node = chip->of_node;
+	if (chip->of_node)
+		gdev->dev.of_node = chip->of_node;
 #endif
-	}
+
 	gdev->id = ida_simple_get(&gpio_ida, 0, 0, GFP_KERNEL);
 	if (gdev->id < 0) {
 		status = gdev->id;
-- 
2.8.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: of: Allow overriding the device node
  2016-07-05 12:11 [PATCH] gpio: of: Allow overriding the device node Thierry Reding
@ 2016-07-05 13:10 ` Alexandre Courbot
  2016-07-05 15:25 ` Linus Walleij
  1 sibling, 0 replies; 5+ messages in thread
From: Alexandre Courbot @ 2016-07-05 13:10 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Linus Walleij, linux-gpio, linux-tegra, Linux Kernel Mailing List

On Tue, Jul 5, 2016 at 9:11 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> When registering a GPIO chip, drivers can override the device tree node
> associated with the chip by setting the chip's ->of_node field. If set,
> this field is supposed to take precedence over the ->parent->of_node
> field, but the code doesn't actually do that.
>
> Commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
> struct gg_data") exposes this because it now no longer matches on the
> GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
> is set using the procedure described above.

Acked-by: Alexandre Courbot <acourbot@nvidia.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: of: Allow overriding the device node
  2016-07-05 12:11 [PATCH] gpio: of: Allow overriding the device node Thierry Reding
  2016-07-05 13:10 ` Alexandre Courbot
@ 2016-07-05 15:25 ` Linus Walleij
  2016-07-06  1:05   ` Masahiro Yamada
  1 sibling, 1 reply; 5+ messages in thread
From: Linus Walleij @ 2016-07-05 15:25 UTC (permalink / raw)
  To: Thierry Reding, Masahiro Yamada
  Cc: Alexandre Courbot, linux-gpio, linux-tegra, linux-kernel

On Tue, Jul 5, 2016 at 2:11 PM, Thierry Reding <thierry.reding@gmail.com> wrote:

> From: Thierry Reding <treding@nvidia.com>
>
> When registering a GPIO chip, drivers can override the device tree node
> associated with the chip by setting the chip's ->of_node field. If set,
> this field is supposed to take precedence over the ->parent->of_node
> field, but the code doesn't actually do that.
>
> Commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
> struct gg_data") exposes this because it now no longer matches on the
> GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
> is set using the procedure described above.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>

Thanks for catching this, patch applied with Alexandre's ACK.

Masahiro: does this look all right to you?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: of: Allow overriding the device node
  2016-07-05 15:25 ` Linus Walleij
@ 2016-07-06  1:05   ` Masahiro Yamada
  2016-07-06  9:07     ` Linus Walleij
  0 siblings, 1 reply; 5+ messages in thread
From: Masahiro Yamada @ 2016-07-06  1:05 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Thierry Reding, Alexandre Courbot, linux-gpio, linux-tegra, linux-kernel

Hi.

2016-07-06 0:25 GMT+09:00 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Jul 5, 2016 at 2:11 PM, Thierry Reding <thierry.reding@gmail.com> wrote:
>
>> From: Thierry Reding <treding@nvidia.com>
>>
>> When registering a GPIO chip, drivers can override the device tree node
>> associated with the chip by setting the chip's ->of_node field. If set,
>> this field is supposed to take precedence over the ->parent->of_node
>> field, but the code doesn't actually do that.
>>
>> Commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and
>> struct gg_data") exposes this because it now no longer matches on the
>> GPIO chip's ->of_node field, but the GPIO device's ->of_node field that
>> is set using the procedure described above.
>>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> Thanks for catching this, patch applied with Alexandre's ACK.
>
> Masahiro: does this look all right to you?

Yes.
Now, the code matches to the comment.  Nice!

Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>


Question:

When we reference the node of gpiochip,
we should use
  chip->gpiodev->dev->of_node

instead of
  chip->of_node

because we can make chip->of_node optional
as long as chip->parent is set in the probe method.

Correct?






-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] gpio: of: Allow overriding the device node
  2016-07-06  1:05   ` Masahiro Yamada
@ 2016-07-06  9:07     ` Linus Walleij
  0 siblings, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2016-07-06  9:07 UTC (permalink / raw)
  To: Masahiro Yamada, Grant Likely
  Cc: Thierry Reding, Alexandre Courbot, linux-gpio, linux-tegra, linux-kernel

On Wed, Jul 6, 2016 at 3:05 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:

> Question:
>
> When we reference the node of gpiochip,
> we should use
>   chip->gpiodev->dev->of_node
>
> instead of
>   chip->of_node
>
> because we can make chip->of_node optional
> as long as chip->parent is set in the probe method.
>
> Correct?

Yes, if you see any bug with respect to this, just fix them.

Overall my appraisal of the situation is that it's a mess.
chip->of_node should not exist, we need to investigate all
cases where this is actually used by drivers and kill them all
off, they should all be using the parent to pass the device
containing the right of node so we can get rid of this:

#ifdef CONFIG_OF_GPIO
        /* If the gpiochip has an assigned OF node this takes precedence */
        if (chip->of_node)
                gdev->dev.of_node = chip->of_node;
#endif

I don't know why this extra OF node is there in the first
place and in which circumstances it may be used, maybe
Grant knows.

I understand so much as that it would be a situation where
you have a GPIO device node but it does not have a corresponding
device of any type, but I fail to see what circumstance would
make that happen.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-07-06  9:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-05 12:11 [PATCH] gpio: of: Allow overriding the device node Thierry Reding
2016-07-05 13:10 ` Alexandre Courbot
2016-07-05 15:25 ` Linus Walleij
2016-07-06  1:05   ` Masahiro Yamada
2016-07-06  9:07     ` Linus Walleij

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.