All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support
Date: Wed, 23 May 2012 14:44:03 -0600	[thread overview]
Message-ID: <4FBD4C13.8080209@wwwdotorg.org> (raw)
In-Reply-To: <1337779362-31259-3-git-send-email-b29396@freescale.com>

On 05/23/2012 07:22 AM, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> This patch implements a standard common binding for pinctrl gpio ranges.
> Each SoC can add gpio ranges through device tree by adding a gpio-maps property
> under their pinctrl devices node with the format:
> <&gpio $gpio_offset $pin_offset $npin>.
> 
> Then the pinctrl driver can call pinctrl_dt_add_gpio_ranges(pctldev, node)
> to parse and register the gpio ranges from device tree.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

This is mostly good. Just a few comments:

> +gpio-maps: 4 integers array, each entry in the array represents a gpio
> +range with the format: <&gpio $gpio_offset $pin_offset $count>
> +- gpio: phandle pointing at gpio device node
> +- gpio_offset: integer, the local offset of $gpio
> +- pin_offset: integer, the pin offset or pin id
> +- npins: integer, the gpio ranges starting from pin_offset

This uses a single cell to represent a GPIO ID within a GPIO controller.
The standard GPIO bindings use #gpio-cells, where that's a property in
the GPIO controller's node. I wonder if we shouldn't do the same here,
and call into the GPIO driver to parse #gpio-cells and give back the
Linux GPIO ID, just like of_get_named_gpio_flags() does. This would also
make this code able to cope with the GPIO of_xlate function returning a
different GPIO chip, which Grant put in place for banked GPIO controllers.

> diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c

> +int pinctrl_dt_add_gpio_ranges(struct pinctrl_dev *pctldev,

The locking I was talking about before is between the following line:

> +		ranges[i].gc = of_node_to_gpiochip(np_gpio);

and this code:

> +		ranges[i].name = dev_name(pctldev->dev);
> +		ranges[i].base = ranges[i].gc->base + gpio_offset;
> +		ranges[i].pin_base = pin_offset;
> +		ranges[i].npins = npins;

If of_node_to_gpiochip() doesn't mark the GPIO chip as "in use", then
the module that provides that device could be unloaded between the two
blocks of code above.

Re: your locking comments in your other email: ranges[i].gc doesn't
appear to be used anywhere else in pinctrl, so I think it's OK not to
lock the GPIO chip for any more time than between the above two blocks
of code.

Finally, just a minor nit:

> +		ranges[i].gc = of_node_to_gpiochip(np_gpio);
> +		if (!ranges[i].gc) {
> +			dev_err(pctldev->dev,
> +				"can not find gpio chip of node(%s)\n",
> +				np_gpio->name);
> +			of_node_put(np_gpio);
> +			return -EPROBE_DEFER;
> +		}
> +
> +		of_node_put(np_gpio);

could be slightly simpler:

+		ranges[i].gc = of_node_to_gpiochip(np_gpio);
+		of_node_put(np_gpio); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+		if (!ranges[i].gc) {
+			dev_err(pctldev->dev,
+				"can not find gpio chip of node(%s)\n",
+				np_gpio->name);
+			return -EPROBE_DEFER;
+		}

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Dong Aisheng <b29396@freescale.com>,
	Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linus.walleij@stericsson.com,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Rob Herring <rob.herring@calxeda.com>
Subject: Re: [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support
Date: Wed, 23 May 2012 14:44:03 -0600	[thread overview]
Message-ID: <4FBD4C13.8080209@wwwdotorg.org> (raw)
In-Reply-To: <1337779362-31259-3-git-send-email-b29396@freescale.com>

On 05/23/2012 07:22 AM, Dong Aisheng wrote:
> From: Dong Aisheng <dong.aisheng@linaro.org>
> 
> This patch implements a standard common binding for pinctrl gpio ranges.
> Each SoC can add gpio ranges through device tree by adding a gpio-maps property
> under their pinctrl devices node with the format:
> <&gpio $gpio_offset $pin_offset $npin>.
> 
> Then the pinctrl driver can call pinctrl_dt_add_gpio_ranges(pctldev, node)
> to parse and register the gpio ranges from device tree.
> 
> Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>

This is mostly good. Just a few comments:

> +gpio-maps: 4 integers array, each entry in the array represents a gpio
> +range with the format: <&gpio $gpio_offset $pin_offset $count>
> +- gpio: phandle pointing at gpio device node
> +- gpio_offset: integer, the local offset of $gpio
> +- pin_offset: integer, the pin offset or pin id
> +- npins: integer, the gpio ranges starting from pin_offset

This uses a single cell to represent a GPIO ID within a GPIO controller.
The standard GPIO bindings use #gpio-cells, where that's a property in
the GPIO controller's node. I wonder if we shouldn't do the same here,
and call into the GPIO driver to parse #gpio-cells and give back the
Linux GPIO ID, just like of_get_named_gpio_flags() does. This would also
make this code able to cope with the GPIO of_xlate function returning a
different GPIO chip, which Grant put in place for banked GPIO controllers.

> diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c

> +int pinctrl_dt_add_gpio_ranges(struct pinctrl_dev *pctldev,

The locking I was talking about before is between the following line:

> +		ranges[i].gc = of_node_to_gpiochip(np_gpio);

and this code:

> +		ranges[i].name = dev_name(pctldev->dev);
> +		ranges[i].base = ranges[i].gc->base + gpio_offset;
> +		ranges[i].pin_base = pin_offset;
> +		ranges[i].npins = npins;

If of_node_to_gpiochip() doesn't mark the GPIO chip as "in use", then
the module that provides that device could be unloaded between the two
blocks of code above.

Re: your locking comments in your other email: ranges[i].gc doesn't
appear to be used anywhere else in pinctrl, so I think it's OK not to
lock the GPIO chip for any more time than between the above two blocks
of code.

Finally, just a minor nit:

> +		ranges[i].gc = of_node_to_gpiochip(np_gpio);
> +		if (!ranges[i].gc) {
> +			dev_err(pctldev->dev,
> +				"can not find gpio chip of node(%s)\n",
> +				np_gpio->name);
> +			of_node_put(np_gpio);
> +			return -EPROBE_DEFER;
> +		}
> +
> +		of_node_put(np_gpio);

could be slightly simpler:

+		ranges[i].gc = of_node_to_gpiochip(np_gpio);
+		of_node_put(np_gpio); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+		if (!ranges[i].gc) {
+			dev_err(pctldev->dev,
+				"can not find gpio chip of node(%s)\n",
+				np_gpio->name);
+			return -EPROBE_DEFER;
+		}

  parent reply	other threads:[~2012-05-23 20:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23 13:22 [PATCH RFC v3 1/3] pinctrl: remove pinctrl_remove_gpio_range Dong Aisheng
2012-05-23 13:22 ` Dong Aisheng
2012-05-23 13:22 ` [PATCH RFC v3 2/3] pinctrl: add pinctrl_add_gpio_ranges function Dong Aisheng
2012-05-23 13:22   ` Dong Aisheng
2012-05-24 15:02   ` Linus Walleij
2012-05-24 15:02     ` Linus Walleij
2012-05-23 13:22 ` [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support Dong Aisheng
2012-05-23 13:22   ` Dong Aisheng
2012-05-23 13:30   ` Dong Aisheng
2012-05-23 13:30     ` Dong Aisheng
2012-05-23 20:44   ` Stephen Warren [this message]
2012-05-23 20:44     ` Stephen Warren
2012-05-24  1:42     ` Dong Aisheng
2012-05-24  1:42       ` Dong Aisheng
2012-05-24  4:42       ` Stephen Warren
2012-05-24  4:42         ` Stephen Warren
2012-05-24  5:19         ` Dong Aisheng
2012-05-24  5:19           ` Dong Aisheng
2012-05-24 15:22           ` Stephen Warren
2012-05-24 15:22             ` Stephen Warren
2012-05-24 15:22             ` Stephen Warren
2012-05-25  3:22             ` Dong Aisheng
2012-05-25  3:22               ` Dong Aisheng
2012-05-25  3:22               ` Dong Aisheng
2012-05-25  4:59               ` Stephen Warren
2012-05-25  4:59                 ` Stephen Warren
2012-05-25  5:09                 ` Dong Aisheng
2012-05-25  5:09                   ` Dong Aisheng
2012-05-25  5:09                   ` Dong Aisheng
2012-05-23 20:29 ` [PATCH RFC v3 1/3] pinctrl: remove pinctrl_remove_gpio_range Stephen Warren
2012-05-23 20:29   ` Stephen Warren

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=4FBD4C13.8080209@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 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.