linux-kernel - Re: An extremely simplified pinctrl bindings proposal

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:	Mon, 6 Feb 2012 10:57:11 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Dong Aisheng <dongas86@...il.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"Linus Walleij (linus.walleij@...aro.org)" <linus.walleij@...aro.org>,
	"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>,
	"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

* Stephen Warren <swarren@...dia.com> [120204 21:01]:
> 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:
> 
> Thoughts:
> 
> * Defining all the pins, groups, functions, ... takes a lot of space,
>   whether it's in static data in pinctrl drivers or in the device tree.
>   The lists must also be stored in RAM at runtime.
> 
> * It's been very difficult to come up with a generic description of all
>   pin controller's capabilities. This is true even irrespective of device
>   tree; think pin config where we've agonized over whether we can create
>   a standardized list of pin config properties, or need to allow each
>   pinctrl driver to define its own set of properties, etc.
> 
> * The only real use of the lists is for debugfs. Drivers shouldn't expect
>   to directly request specific pinctrl settings, since that would encode
>   knowledge of an individual SoC's pin controller. This should be
>   abstracted from drivers.
> 
> * The data in debugfs could easily be replaced by a raw register dump
>   coupled with a SoC-specific script to print out what each register
>   means.

My conclusions are pretty much the same: The data is only needed in
the driver for debugging. And the register names and values are best
translated into readable format using debugfs and userspace tools.

I pretty much did this with the pinctrl-simple.c I posted few days
ago, except no userspace debugging support yet in pinctrl framework
naturally.

This all seems to fit into the current pinctrl framework OK.

I think we just need to make string names optional data, and
structure things in debugfs to just display register physical
addresses rather than string names for userspace tools.

FYI, I'm currently working around the names by using the hex
register physical address as the pin name.

Also, the alternative pin modes bindings still needs to be
discussed, so maybe we all can talk about that at Linaro Connect
on Tuesday at some point.

Regards,

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