linux-kernel - Re: [RFC] pinctrl: Alternative to gpio to pinctrl pin mapping via DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 14 May 2013 14:17:33 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	hanumant <hanumant@...eaurora.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dotorg.org>
Subject: Re: [RFC] pinctrl: Alternative to gpio to pinctrl pin mapping via DT

On Fri, May 10, 2013 at 1:51 AM, hanumant <hanumant@...eaurora.org> wrote:

> 1) total pins exported to pinctrl subsystem = num pins of type A +
>                                                 num pins of type B
>
> 2) Each pin type is a child node of the pinctrl node in device tree.
>
> 3) The starting pin number of each pin type on the pinctroller depends on
> the order in which it occurs in the device tree when the pinctrl driver is
> parsing the device tree.
>
> 4) In this case, if a pintype supports gpio functionality, I could have
> informed the pinctrl system of the pin range, based on the run time
> determined start pin of that pin type. (This would have involved the use of
> the now deprecated pinctrl_add_gpio_range())
>
> 5) The current way of notifying the pinctrl system of gpio functionality is
> by using the gpio-ranges attribute in the gpio chip device tree node. But in
> my case, this would require me to know run time what pin range is going to
> correspond to my pin type.
> In the above example, i could assume since the pin type A occurs first
> in order, the gpio-ranges = 0 to 99 for the corresponding. But that would
> mean ensuring that your pin type occurs at a certain order in Device tree.
(...)
> The pinctrl_add_gpio_range() would have really helped here in specifying the
> gpio range at device tree parsing time.
>
> Is there a more elegant option rather then hard coding the order of pin
> types.?

I think I just cannot follow what you are trying to do or what kind of problem
you are facing, there is something wrong with the concepts or I'm just
stupid :-(

pinctrl_add_gpio_range() is one way to add pins at runtime which
unfortunately has the problem that i refers to the global GPIO number
space, which is something we want to avoid.

Instead we recommend that gpiochip_add_pin_range() from
<linux/gpio.h> is used, which us using numbering relative to the
pin controller and GPIO controller as well, which is nice, since
it removed the reliance on the global GPIO number space.

One way to use the latter function while having pin numbers
be dynamic would be to make sure you are doing a combined
driver, i.e. do not try to artificially split the pinctrl and GPIO drivers
in two files, instanstiate one driver container for all of this
hardware and let that driver control both GPIO and pinctrl. This
way all numbering is transparent between the pinctrl and GPIO
parts of the driver and the driver can use pinctrl_add_gpio_range()
or (better) the device-tree based standard bindings to do this.

See the drivers/pinctrl/pinctrl-abx500.c driver for such a combined
driver (albeit it is not using device tree).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/