linux-kernel - Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

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:	Fri, 24 Aug 2012 01:01:13 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Lior Amsalem <alior@...vell.com>, Andrew Lunn <andrew@...n.ch>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

On 08/23/2012 11:26 PM, Stephen Warren wrote:
> As you may have guessed, I strongly prefer the hard-coded static table
> based approach, or at least separating the definition of known
> pins/groups/functions from the configuration nodes that define which
> particular mux settings to actually use.
>
> Puting this all a little more simply, the pinctrl core wants to generate
> a list of all known functions. It is a single global/unified list. It
> first calls pinmux_ops.get_functions_count() to find out how many
> functions there are in the list, then pinmux_ops.get_function_name() for
> each one to find its name, then pinmux_ops.get_function_groups() to find
> out which groups allow that function to be mux'd onto them.

Ok, now this becomes a little bit more clear to me.

Consider uart1 on dove is muxable to:
mpp2 uart1(rts), mpp3 uart1(cts), mpp21 uart1(rts), mpp22 uart1(cts),
and finally mpp_uart1(rx and tx).

So possible, valid combinations for uart1 would be:
(a) mpp_uart1;
(b) mpp_uart1, mpp2, mpp3;
(c) mpp_uart1, mpp21, mpp22;
(d) mpp_uart1, mpp2, mpp22;
(e) mpp_uart1, mpp21, mpp3;

Now what we currently do is, use DT to setup all known functions with e.g.
marvell,pins = "mpp_uart1", "mpp2", "mpp22" and marvell,function = "uart1".
This requires to count all pinctrl DT node children to count the known
functions that can ever be muxed to. It will never allow to mux uart1 to sw
flow control during run-time when there was no DT child node for it.

But you are proposing to scan the list passed from SoC specific driver for all
possible marvell,function ("uart1", "uart2", "sdio0", ...) and build up lists
of pingroups that can be used with this specific marvell,function; or even build
up lists of pingroups that allow uart1(rts), and another one for uart1(cts), ...?

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