linux-kernel - Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdaVx=6AJ5DFjVN1ZYQ++hu9pT6WxD9n+pqmYVaCf1xawg@mail.gmail.com>
Date:	Tue, 16 Aug 2011 16:01:31 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Stephen Warren <swarren@...dia.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Colin Cross <ccross@...roid.com>,
	Erik Gilling <konkers@...roid.com>,
	Olof Johansson <olof@...om.net>,
	Russell King <linux@....linux.org.uk>,
	devicetree-discuss@...ts.ozlabs.org, linux-tegra@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Belisko Marek <marek.belisko@...il.com>,
	Jamie Iles <jamie@...ieiles.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Sergei Shtylyov <sshtylyov@...sta.com>
Subject: Re: [RFC PATCH v2 00/13] arm/tegra: Initialize GPIO & pinmux from DT

On Tue, Aug 16, 2011 at 3:09 PM, Arnd Bergmann <arnd@...db.de> wrote:

> I do think that you should keep Linus Walleij on Cc in these emails, since
> he first started pushing for a common pinmux layer, and we need to make
> sure that the binding works for all SoCs, not just for tegra.

Sorry for slipping off the pinmux stuff, I will make it my goal to recap
discussion and try to post a new patchset this week.

Concepts have grown, I see Stephen have created the new concept
of e.g. bias groups which is a real good idea

One problem is that I wanted to start out small with the pinctrl
subsystem, and now it looks like it has to do a *lot* of stuff from
day 1 to be of any use ...

One specific thing worries me: Grant asked me to make sure
to NOT create a global pin number space for the pinmuxes (and thus
pinctrl). This means that in order to proceed, mappings of pinmux
groups or pincontrol (such as bias) groups, each device using such
an entity need to reference the intended pincontroller/mux instance.

Say mmc instance 0 need pingroup foo on pincontroller bar
means that there must be a specific reference from mmc.0:s
struct device * to pinctrl bar:s struct device *. Maybe this is
peanuts in DT, sorry not enough insight.

I wonder if this has bearing on how the device tree need to be
structured to be future proof? (Hopefully not.)

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