linux-kernel - Re: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs

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]

Date:	Fri, 9 Dec 2011 12:08:07 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Shawn Guo <shawn.guo@...escale.com>
Cc:	Stephen Warren <swarren@...dia.com>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs

On Fri, Dec 09, 2011 at 01:14:14PM +0800, Shawn Guo wrote:
> On Thu, Dec 08, 2011 at 09:47:24PM -0700, Stephen Warren wrote:
> > 
> > pin X: function = UART A TX
> > pin Y: function = UART A RX
> > 
> 
> We really do not expect per pin function mapping but per block function
> mapping.  That said, the UART driver is going to tell pinctrl subsystem
> "I'm UARTA, please set all my pins up for me".

I still think it should be "I'm board Y, please set all my pins up for me"

Drivers should not be bothered with pin muxing *at all*. When we add
pinmux_request to drivers all SoCs using this driver are doomed to
implement pinmux support regardless if they have any pinmux support in
hardware or not.
Where this leads we can currently see in current next branch with the
smc91x driver where one single board has a regulator for.  Suddenly all
other boards using this driver stopped working because they have no
regulator provided for the driver.
There is this CONFIG_REGULATOR_DUMMY option which will cause *all*
regulator_request to succeed on all regulators in this binary which
disqualifies this option for multiboard/SoC Kernels.

A pin setup is board specific and not driver specific. There are only
some corner cases where a driver has to do something with the pin setup
like for example on i.MX6 where the drive strength setting has to be
changed with different card speeds.

There is also no value in being able to say which pins are allocated
by which driver. All we really want is being able to abstract the
pinmux in some common way and being able to detect conflicts.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/