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?
next prev parent 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