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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ