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:	Sat, 10 Dec 2011 01:18:43 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Shawn Guo <shawn.guo@...escale.com>,
	Stephen Warren <swarren@...dia.com>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	"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 9, 2011 at 12:08 PM, Sascha Hauer <s.hauer@...gutronix.de> wrote:

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

This is basically what the current pinmux hog concept does.

> Drivers should not be bothered with pin muxing *at all*.

Not if they are simple. Like - set them up once and for all and
then forget about it.

It gets problematic when we get to sleep states and the system
need to reconfigure all pins on say idle or deep sleep.

We also have heard about hardware routing the *same*
IO block (an I2C port IIRC) to two different sets of pins at
*runtime*, i.e. route it to pin 1-4 do some traffic, route
it to pin 9-12, do some other traffic...

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

I fear that is just the top of an iceberg :-P

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

It's a value to have it in debugfs, where it is right now, and that
is optional. It helped me a lot when developing a driver...

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/