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] [day] [month] [year] [list]

Message-ID: <CACRpkdbuCMV0k=bfST65ZNojzUQVvDpbOB=-NN=wd3Hc7Mj_MQ@mail.gmail.com>
Date:	Wed, 22 Feb 2012 07:08:23 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	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>,
	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>
Subject: Re: [PATCH] pinctrl: spawn U300 pinctrl from the COH901 GPIO

On Tue, Feb 21, 2012 at 7:33 PM, Stephen Warren <swarren@...dia.com> wrote:
> 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.

Right now it looks like it won't happen.

U300 has a hard-coded bootloader I cannot change so cannot pass
DT from bootloader.

I cannot use attached device tree either, since those can only be
attached to compressed kernels, and U300 uses uncompressed
kernels.

If I try to fix either of the above, I have so much problems to
fix that probeing of the devices is going to be eclipsed by
those issues :-D

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

Sure anything that works and can be understood... the root of the
problem is the global GPIO pin space anyway, so we will have to live
with any solutions to patch around it until that happens.

Maybe some of the above described mechanisms can ge
generalized though?

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