linux-kernel - Re: [PATCH] pinctrl: indicate GPIO direction on single GPIO request

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdapm2cx=QJkPinwteCPZFNNnxVcKqR4f0D8_ikWMTea_g@mail.gmail.com>
Date:	Mon, 21 Nov 2011 11:47:29 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Thomas Abraham <thomas.abraham@...aro.org>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>
Subject: Re: [PATCH] pinctrl: indicate GPIO direction on single GPIO request

On Thu, Nov 17, 2011 at 6:15 PM, Stephen Warren <swarren@...dia.com> wrote:

> a) gpio_request() doesn't know the direction; only gpio_direction_*()
> know that. I suggest the pinctrl API have the same set of GPIO-related
> functions that gpiolib has, so each can be passed through to a pinctrl
> function 1:1:
>
> gpio_request -> pinmux_gpio_request
> gpio_direction_input -> pinmux_gpio_direction_input
> gpio_direction_output -> pinmux_gpio_direction_output
> gpio_free -> pinmux_gpio_free
>
> (and a pinmux driver ops entry for each too)

You are right, the current solution is messy, and this is way more
elegant and to the point. I'll fix up the patch set and resubmit it.

> However, it doesn't cover the following case:
>
> b3) Some GPIO could be routed to multiple pins, just like any other pinmux
> function. In this case, knowing the GPIO ID isn't enough to program the
> pinmux, but you need to know both "this GPIO" (which we have) and "this
> pin" (which is missing).
>
> I'm not sure how to solve that. For such SoCs, perhaps we should treat
> this as a muxing setup, and require it to be in the mapping table, and
> consider all the pinmux_gpio_* functions to be "enable GPIO access to
> pins" rather than "set up pin mux for GPIOs"?

I think we'll survive that, since the gpio range concept is supposed to
make the final resolution of that at runtime.

Now ranges are dynamic, so if these pin allocation also want to
*change* at runtime it will be hairy, but that only reflects the actual
trouble in doing such re-arrangements I think...

Changing pin allocation at runtime seems dangerous but if you
only have a few limited GPIO blocks but many GPIO pins it could
happen, but I think we can deal with that the day it surfaces.

>> If we actively want to stop non-GPIO drivers from using this, shall
>> we aim for a compromise to keep the pinmux_request_gpio() call in
>> the local header in the pinctrl subsystem, i.e
>>
>> drivers/pinctrl/pinmux.h
>>
>> Then it can *only* be used by GPIO drivers migrated to the
>> pinctrl subsystem, and these probably know what they're doing.
>
> Tegra's GPIO driver has no reason to move into drivers/pinctrl; the HW is
> entirely separate from pinmux. I'm sure many other SoCs are similar. As
> such, moving the prototype like that would be unhelpful.

OK it never seemed like a good idea anyway, I'm keeping in in
<pinctrl/pinmux.h>

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/