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]
Message-ID: <CACRpkdahin4srDh7dphgvq306gjz7CGP=h4dVkUY+w0z0wpXRQ@mail.gmail.com>
Date:	Mon, 6 Feb 2012 05:20:59 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Dong Aisheng <dongas86@...il.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"Sascha Hauer (s.hauer@...gutronix.de)" <s.hauer@...gutronix.de>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	"Grant Likely (grant.likely@...retlab.ca)" 
	<grant.likely@...retlab.ca>,
	"ext Tony Lindgren (tony@...mide.com)" <tony@...mide.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: An extremely simplified pinctrl bindings proposal

On Sun, Feb 5, 2012 at 6:31 AM, Stephen Warren <swarren@...dia.com> wrote:

> Sorry, I haven't had a chance to read any of the pincrl emails from
> Friday onwards. However, I thought a bit more about this, and decided
> to propose someting much simpler:

I think this approach is quite interesting, but since it removes more
or less all semantic meaning of the pinctrl system, I don't see why
it would be a pinctrl rewrite at all or called pinctrl, rather it'd be
something new and separate, since it could (if I understand
correctly) very well be used to configure things that are totally
unrelated to pin control, could it not?

It is indeed described as "little more than a system to execute a
list of arbitrary register writes".

For example it could be readily used to set up the config registers
of parameters in an external memory controller - these are also a lot
of magic writes into various registers, nobody really knows what they
actually do, timings for access and whatnot.

Incidentally external memory controllers is another things that
is usually magically reconfigured at idle/sleep and on the way
back up.

Can we defined it then as controlled register processing at
determined points, some during boot, some at runtime, and
maybe tied to certain devices at certain points in time?

A controlled set of register read/writes and maybe also conditionals
(if that bit is 1, do this, else do that, plus a loop command to wait
for a flag or similar) are known as a "jam tables" and usually used
in BIOSes to do a compact machine initialization. I learned this term
in Bunnie Huang's "Hacking the Xbox, where he describes finding a
jam table interpreter in the Xbox ROM.

So if I understand the proposal correctly it would fit nice as
drivers/jamtable or so, and could do that kind of control of whatever
hardware you want to control with opaque register accesses,
then reflect it as raw register contents in debugfs etc.

If it turns out everyone is happy with that and we can move other
drivers over to it we can just scrap pinctrl, or have it only for those
systems that want a semantic representation.

While I would probably mourn the death of sematics I also see
that if the goal is to get huge static data sets out of the kernel,
something like this may be the best way to get there.

Thoughts?
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