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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF174F08C239@HQMAIL01.nvidia.com>
Date:	Mon, 21 Nov 2011 13:54:33 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
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

Linus Walleij wrote at Monday, November 21, 2011 2:44 PM:
> On Mon, Nov 21, 2011 at 8:00 PM, Stephen Warren <swarren@...dia.com> wrote:
...
> > I thought I'd sent this on Friday, but perhaps I only thought it up over
> > the weekend... Here's my proposal:
> >
> > 1)
> >
> > Add a new gpiolib API:
> >
> > int gpio_request_at(unsigned gpio, const char *label, unsigned at);
> 
> This has a nice look to it, I must admit.
> 
> Since the pinctrl number space is per-controller this signature
> will not work. It would have to pass in a pin controller reference
> too, preferably as struct device * or a string. Else "at" is just
> a number without meaning. "At *which* controller?"

I'm assuming that each (physical) chip will have one pinctrl driver.
Therefore, for any GPIO driver (and hence any GPIO number) on that chip,
there is a single pinctrl driver that's relevant, and hence pinctrl
driver can be determined directly and internally from the GPIO ID.

Now that I say it though, I wonder if that assumption is totally valid;
after all, we're talking about having multiple GPIO controller drivers
within a (physical) chip, so perhaps having multiple pinctrl drivers
for different subsets of the pins wouldn't be impossible, albeit pretty
unlikely and bizarre. Should we just ignore that case? We could deal
with it by internally creating an aggregate driver if it ever happened.

...
> Yes letting gpio_chip hold a reference to the pin controller
> is equivalent to the pin controller GPIO range holding a
> reference to the struct gpio_chip * as it can do today.

Yes, those are pretty much the same thing.

Assuming my assumption above is correct, then each GPIO (and GPIO chip)
maps to a single pinctrl, which makes storing the data easy and static,
but each pinctrl range might map to different GPIO chips and IDs which
makes things harder, so I still see some value pushing the data storage
into GPIO.

> Any solution like the above needs to be anchored with the
> GPIO maintainer anyway.
> 
> My past attempts to patch gpio_chip have been shot down,
> pinctrl was created to get away from having to introduce any kind of
> control or muxing in gpiolib drivers. The current ranges are
> totally encapsulated in the pinctrl subsystem and that's a pretty
> nice feature I suspect.

Yes, that's all true.

-- 
nvpublic

--
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/