devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: John Crispin <blogic@openwrt.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, devicetree-discuss@lists.ozlabs.org,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 04/14] OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support
Date: Fri, 04 May 2012 14:57:26 -0600	[thread overview]
Message-ID: <4FA442B6.1020501@wwwdotorg.org> (raw)
In-Reply-To: <1336133919-26525-4-git-send-email-blogic@openwrt.org>

On 05/04/2012 06:18 AM, John Crispin wrote:
> Implement support for pinctrl on lantiq/xway socs. The IO core found on these
> socs has the registers for pinctrl, pinconf and gpio mixed up in the same
> register range. As the gpio_chip handling is only a few lines, the driver also
> implements the gpio functionality. This obseletes the old gpio driver that was
> located in the arch/ folder.

Overall looks pretty reasonable. Some comments below.

There doesn't appear to be binding documentation. Something is needed to
describe how to instantiate the pinctrl driver, and the format of the
"pin configuration nodes". See
Documentation/devicetree/bindings/pinctrl/ for some examples.

> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig

>  config LANTIQ
...
> +	select PINCTRL

> diff --git a/arch/mips/lantiq/Kconfig b/arch/mips/lantiq/Kconfig

>  config SOC_TYPE_XWAY
>  	bool
> +	select PINCTRL_XWAY

I'd be tempted to just select PINCTRL and PINCTRL_XWAY in the same place
under SOC_TYPE_XWAY.

> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile

>  obj-$(CONFIG_PINCTRL_TEGRA30)	+= pinctrl-tegra30.o
>  obj-$(CONFIG_PINCTRL_U300)	+= pinctrl-u300.o
>  obj-$(CONFIG_PINCTRL_COH901)	+= pinctrl-coh901.o
> +obj-$(CONFIG_PINCTRL_LANTIQ)	+= pinctrl-lantiq.o
> +obj-$(CONFIG_PINCTRL_XWAY)	+= pinctrl-xway.o

It'd be nice to keep this sorted. I know COH901 isn't right now; I guess
I should send a patch for that.

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

> +static const char *ltq_get_group_name(struct pinctrl_dev *pctrldev,
> +					 unsigned selector)
> +{
> +	struct ltq_pinmux_info *info = pinctrl_dev_get_drvdata(pctrldev);
> +	if (selector >= info->num_grps)
> +		return NULL;

Most/all other drivers removed this range checking, instead relying on
the pinctrl core to not be buggy, and to respect the limits set out in
the pinctrl device descriptor.

> +static int ltq_pinctrl_dt_subnode_to_map(struct pinctrl_dev *pctldev,

> +				"%s mixes pins and groups settings\n",

s/mixes/muxes/.

> +int ltq_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,

> +	*map = kzalloc(*num_maps * sizeof(struct pinctrl_map), GFP_KERNEL);

Check for failure.

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

> +static int xway_pinconf_get(struct pinctrl_dev *pctldev,
...
> +	default:
> +		pr_err("%s: Invalid config param %04x\n",
> +					pinctrl_dev_get_name(pctldev), param);

Use dev_err instead of pr_err everywhere?

> +int irq_to_gpio(unsigned int gpio)
> +{
> +	return -EINVAL;
> +}
> +EXPORT_SYMBOL(irq_to_gpio);

Hasn't this function been removed? Perhaps it's only ARM that removed it.

> +static inline int xway_gpio_pin_count(void)
> +{
> +	if (of_machine_is_compatible("lantiq,ar9") ||
> +			of_machine_is_compatible("lantiq,gr9") ||
> +			of_machine_is_compatible("lantiq,vr9"))
> +		return 56;
> +	return 32;
> +}

What are those compatible values? Are they SoC variants or boards?

If they're SoC variants, then putting each of those compatible values
into the of_device_id table, and storing the per-SoC information in the
.data field is one way to go. Or, simply put this information into a
device-tree property.

If they're board names, this seems wrong; the code should be switching
on the SoC variant rather than the individual board. If a board happens
to hook up fewer of the pins that other boards that's fine, just don't
use them, but they still exist on the SoC and hence are reasonable to
represent in the driver.

> +static int __devinit pinmux_xway_probe(struct platform_device *pdev)

> +	for (i = 0; i < xway_chip.ngpio; i++) {
> +		/* strlen("ioXY") + 1 = 5 */
> +		char *name = devm_kzalloc(&pdev->dev, 5, GFP_KERNEL);
> +
> +		if (!name) {
> +			dev_err(&pdev->dev, "Failed to allocate pad name\n");
> +			return -ENOMEM;
> +		}
> +		snprintf(name, 5, "io%d", i);

Maybe time for a devm_kasprintf()?

> +	/* finish with registering the gpio range in pinctrl */
> +	xway_gpio_range.npins = xway_chip.ngpio;

Presumably, of_gpiochip_add() above dynamically allocates the base GPIO
number? If so, that value needs to be transferred into
xway_gpio_range.base too.

> +core_initcall_sync(pinmux_xway_init);

Does this need to be a core_initcall_sync; would a simple module_init()
do instead?

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

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1336133919-26525-1-git-send-email-blogic@openwrt.org>
     [not found] ` <1336133919-26525-1-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
2012-05-04 12:18   ` [PATCH 02/14] OF: MIPS: lantiq: implement OF support John Crispin
     [not found]     ` <1336133919-26525-2-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
2012-05-12  0:47       ` Grant Likely
2012-05-04 12:18   ` [PATCH 03/14] OF: MIPS: lantiq: implement irq_domain support John Crispin
     [not found]     ` <1336133919-26525-3-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
2012-05-08 17:53       ` Grant Likely
2012-05-08 18:05         ` John Crispin
2012-05-04 12:18   ` [PATCH 04/14] OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support John Crispin
2012-05-04 20:57     ` Stephen Warren [this message]
     [not found]       ` <4FA442B6.1020501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-05-04 21:29         ` John Crispin
     [not found]     ` <1336133919-26525-4-git-send-email-blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
2012-05-08 13:21       ` Linus Walleij
     [not found]         ` <CACRpkdYJDd84GbKM7r4Xy+d4iOtdD+rJ3kdq-zwVbf_Attj2Gw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-05-08 14:12           ` John Crispin
2012-05-08 15:28           ` Stephen Warren
     [not found]             ` <4FA93B97.4070406-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-05-08 15:39               ` John Crispin
     [not found]                 ` <4FA93E37.70305-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
2012-05-08 15:51                   ` Stephen Warren
     [not found]                     ` <4FA940F3.4090008-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-05-08 15:59                       ` John Crispin

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=4FA442B6.1020501@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=blogic@openwrt.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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;
as well as URLs for NNTP newsgroup(s).