linux-kernel - Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

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: <508664CA.7000601@ti.com>
Date:	Tue, 23 Oct 2012 11:35:06 +0200
From:	Benoit Cousson <b-cousson@...com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Sourav Poddar <sourav.poddar@...com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	<tony@...mide.com>, <linux-omap@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	<devicetree-discuss@...ts.ozlabs.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-input@...r.kernel.org>, Felipe Balbi <balbi@...com>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi Linus,

On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>> I do not see anything in the driver that would directly use pinctrl. Is
>> there a better place to select default pin configuration; maybe when
>> instantiating platform device?
> 
> The option is to use pinctrl hogs. Then the pins will be taken,
> muxed and configured by the pin controller itself.
> 
> Another option (not implemented) is to use bus notifiers.
> 
> (I wrote about this in some other thread but can't find it now.)
> 
> Each approach above come with its own set of problems.
> 
> If the driver need to handle multiple states like default/idle/sleep
> it is IMO better to put the handling into the driver, so if that
> is what is going to happen also to this driver it could be a good
> idea to actually implement that code upfront and include in
> this submission so as to show that this driver is really going
> to exercise its pins.
> 
> But it's also a question of conformity: if other drivers in the
> system is using different states and this is the only one
> using a single "default" state, then it doesn't make sense
> to have just one driver get its pins using hogs, it's just
> inconsistent.
> 
> So Sourav, please tell us a bit about your plans for this
> and other drivers!

Yeah, this idea is to handle pinctrl from all the drivers, and
potentially change the mode during suspend when it is relevant.

Regards,
Benoit

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