[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120417034210.GD17173@shlinux2.ap.freescale.net>
Date: Tue, 17 Apr 2012 11:42:11 +0800
From: Dong Aisheng <aisheng.dong@...escale.com>
To: Stephen Warren <swarren@...dotorg.org>
CC: Dong Aisheng-B29396 <B29396@...escale.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>
Subject: Re: [PATCH 1/1] pinctrl: handle dummy state in core
On Tue, Apr 17, 2012 at 12:03:34AM +0800, Stephen Warren wrote:
> On 04/16/2012 08:24 AM, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@...aro.org>
> >
> > Remove dummy state user interface and handle it totally in core.
> > This can make it more easy to use by platforms which has neither pinctrl
> > driver support nor dt support.
> >
> > Signed-off-by: Dong Aisheng <dong.aisheng@...aro.org>
>
> I think this is the wrong direction.
>
> I specifically want people to think about which drivers require what
> pinctrl states to be defined, and what their content should be, and
> hence explicitly define dummy states when it's appropriate. This patch
> prevents that.
>
It's correct if all platforms have switched to pinctrl subsystem.
I think the main issue is for one platform neither supports dt nor using pinctrl
subsystem, do you think it still makes too much sense to force that platform
to define a _PINCTRL_ dummy state in their machine code?
But the driver is commonly shared between these different platforms(using pinctrl
or not).
That's why i proposed to handle dummy state in core in this patch rather than require
user to do it.
You must can assume there're so many platforms still have not switched to use pinctrl
subsystem. If we require user to do it, we need change many code.
Regards
Dong Aisheng
--
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/
Powered by blists - more mailing lists