public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Dong Aisheng <b29396@freescale.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linus.walleij@stericsson.com
Subject: Re: [PATCH RFC v2 2/2] pinctrl: add pinctrl gpio binding support
Date: Fri, 18 May 2012 14:05:46 -0600	[thread overview]
Message-ID: <4FB6AB9A.4080006@wwwdotorg.org> (raw)
In-Reply-To: <1337346755-8761-2-git-send-email-b29396@freescale.com>

On 05/18/2012 07:12 AM, Dong Aisheng wrote:
> The gpio ranges standard dt binding format is
> <&gpio $gpio_offset $pin_offset $npin>
> 
> The core will parse and register the pinctrl gpio ranges
> from device tree.

Overall this conceptually makes sense, and looks good. Some comments though:

> +/*
> + * pinctrl_dt_add_gpio_range() - parse and register GPIO ranges from device tree
> + * @pctldev: pin controller device to add the range to
> + * @np: the device node contains the property @propname
> + * @propname: a list of phandles of gpios and corresponding data.
> + *  The format is: <&gpio0 $gpio_offset $pin_offset $count>
> + */
> +int pinctrl_dt_add_gpio_ranges(struct pinctrl_dev *pctldev,
> +				struct device_node *np,
> +				const char *propname)

If this will be fully standardized, perhaps we should just choose a
standard property name, rather than allowing different drivers to do
different things.

Perhaps "gpio-map"?

> +	nranges = size /4;

Add a space after the /

> +	ranges = devm_kzalloc(pctldev->dev, nranges * sizeof(*ranges),
> +				GFP_KERNEL);
> +	for (i = 0; i < nranges; i++) {
> +			phandle = be32_to_cpup(list++);

Looks like double indentation througout this block?

> +			np_gpio = of_find_node_by_phandle(phandle);
> +			if (!np_gpio) {
> +				dev_err(pctldev->dev,
> +					"failed to find gpio node(%s)\n",
> +					np_gpio->name);

Perhaps devm_kfree(ranges) here so that if this is called multiple times
due to deferred probe, the allocations from the failed attempts don't
accumulate. Same for other error paths.

> +				return -ENODEV;
> +			}
> +
> +			ranges[i].gc = of_node_to_gpiochip(np_gpio);

Of course, there is the outstanding question of whether this API will
exist and how it will work.

I think you can of_node_put(np_gpio) here, before the error-check for
ranges[i].gc, to avoid having to do it in all the error paths below.

Do you need to xxx_get(ranges[i].gc) to prevent it going away, and put()
it when removing the ranges?

> +			if (gpio_offset < 0 ||
> +			    gpio_offset > ranges[i].gc->ngpio ||
> +			    pin_offset < 0 || npins < 0) {

These are all unsigned, so most of those conditions can never be true.

Perhaps replace the remaining check with:

	gpio_offset + npins > ranges[i].gc->ngpio

to make sure the range isn't too long either

> +	pinctrl_add_gpio_ranges(pctldev, ranges, nranges);

I think we should also store ranges somewhere separate in pctldev ...

> +void pinctrl_dt_remove_gpio_ranges(struct pinctrl_dev *pctldev,
> +				   struct pinctrl_gpio_range *ranges,
> +				   unsigned nranges)

... so that this function doesn't need ranges/nranges passed to it; it
can just get them out of pctldec.

Or better yet, what if pinctrl_unregister automatically removed any
ranges registered by pinctrl_dt_add_gpio_ranges, so this function
doesn't even need to exist?

  reply	other threads:[~2012-05-18 20:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 13:12 [PATCH RFC v2 1/2] pinctrl: add pinctrl_add_gpio_ranges function Dong Aisheng
2012-05-18 13:12 ` [PATCH RFC v2 2/2] pinctrl: add pinctrl gpio binding support Dong Aisheng
2012-05-18 20:05   ` Stephen Warren [this message]
2012-05-21 12:39     ` Dong Aisheng
2012-05-21 17:09       ` Stephen Warren
2012-05-22  1:00         ` Dong Aisheng
2012-05-21 17:11       ` Stephen Warren
2012-05-22  1:12         ` Dong Aisheng
2012-05-22  3:35     ` Dong Aisheng
2012-05-22 17:12       ` Stephen Warren
2012-05-18 19:51 ` [PATCH RFC v2 1/2] pinctrl: add pinctrl_add_gpio_ranges function Stephen Warren
2012-05-24 14:29 ` Linus Walleij
2012-05-24 14:55   ` Linus Walleij

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=4FB6AB9A.4080006@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=b29396@freescale.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox