linux-kernel - RE: [PATCH] pinctrl: spawn U300 pinctrl from the COH901 GPIO

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: <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC368@HQMAIL01.nvidia.com>
Date:	Tue, 21 Feb 2012 10:33:34 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Dong Aisheng <dong.aisheng@...aro.org>,
	Rajendra Nayak <rajendra.nayak@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...vell.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: RE: [PATCH] pinctrl: spawn U300 pinctrl from the COH901 GPIO

Linus Walleij wrote at Tuesday, February 21, 2012 6:35 AM:
> From: Linus Walleij <linus.walleij@...aro.org>
> 
> This solves the riddle on how the U300 pin controller shall be
> able to reference the struct gpio_chip even though these are
> two separate drivers: spawn the pinctrl child from the GPIO
> driver and pass in the struct gpio_chip as platform data.
> In the process we rename the U300 "pinmux-u300" to
> "pinctrl-u300" so as not to confuse.
> 
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>

That's quite a neat solution, but it's not going to work very well with
device tree, if U300 is being converted to it. The reason is that the
two (GPIO, pinctrl) platform devices would be instantiated directly from
DT by the core DT code. I guess your DT board file does have the option
to explicitly override the platform data passed to your devices to
achieve the same effect, but perhaps there's a different way of making
this work, that doesn't require platform data...

I'd thought about doing the following for Tegra, where we're cheating a
little with the gpio range base value:

When GPIO driver is probed, call a function in the pinctrl driver to
tell it what the "struct gpio_chip *" value is.

When pinctrl is probed, if that call has happened, go ahead and register
the GPIO range, else don't.

In the call from GPIO to pinctrl, if the pinctrl driver has already
probed, register the GPIO range, else just save the gpio_chip value for
later use in the pinctrl driver's probe.

This way, the communication is explicit in code in the drivers, works
whichever order the drivers probe, etc.

Does that sound like a reasonable solution?

It's plausible that with deferred probe, this could be reworked to use
that, but this way might still be better for this case?

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