linux-kernel - Re: [PATCH v2] pinctrl: add support for group and pinmux states

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] [day] [month] [year] [list]

Message-ID: <CACRpkdZnhW7tT0EtoDOx8gXP0vV0zCLWAVmemD=K4D2t2HuMdA@mail.gmail.com>
Date:	Mon, 9 Jan 2012 00:36:53 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Dong Aisheng <dong.aisheng@...aro.org>,
	Rajendra Nayak <rajendra.nayak@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...vell.com>
Subject: Re: [PATCH v2] pinctrl: add support for group and pinmux states

On Sat, Jan 7, 2012 at 12:45 AM, Stephen Warren <swarren@...dia.com> wrote:

> Linus Walleij wrote at Monday, January 02, 2012 4:36 AM:

> The main issue I see is that:
>
> * With the current pin mux API, the driver is simply defining what the
> SoC can do, and the mapping table (outside the driver) is selecting which
> of those things to do. There's zero knowledge (or need) of board-specific
> data in the pin mux driver.
>
> * With your proposal for pin configuration, the driver still of course
> defines what the SoC can do since it must implement it, but also the
> (e.g. platform) data that defines which of those things to do is now
> Handled by the driver rather than the pinctrl/pinconfig core.
>
> That seems like a needless semantic difference.

I'm  buying this and the following argument. I need to come up with
something better. Apparently this idea of states need to be paired
with a proper state configuration table like you suggest, so no
shortcuts (I was hoping to do one, then the other) I will have to
code it all in one go.

One minor thing:

> IIRC, I was talking about two different kinds of states.
>
> The PIN_GROUP_STATE_* you quoted above are individual pin group states.
>
> The "standard states" in the second chunk I wrote above was regarding
> states of an entire device (a pmx entry I think)

They were to use the same states.

Since a PMX corresponds to one or more groups these are easy
to couple, that's what it's all about. So setting the state of a pmx just
falls through to the state of it's mapped in groups. And if these
share the same syntax, it's a quick thing to do.

This will work with string-named states too I think, we'll see.

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/