linux-kernel - Re: [PATCH] dt: pinctrl: Document device tree binding

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:	Tue, 13 Mar 2012 10:14:11 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...ricsson.com>,
	B29396@...escale.com, s.hauer@...gutronix.de, dongas86@...il.com,
	shawn.guo@...aro.org, thomas.abraham@...aro.org, tony@...mide.com
Subject: Re: [PATCH] dt: pinctrl: Document device tree binding

On Fri, Mar 9, 2012 at 7:14 PM, Stephen Warren <swarren@...dotorg.org> wrote:

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> @@ -0,0 +1,118 @@
> +== Introduction ==
> +
> +Hardware modules that control pin multiplexing or configuration parameters
> +such as pull-up/down, tri-state, drive-strength etc are designated as pin
> +controllers. Each pin controller must be represented as a node in device tree,
> +just like any other hardware module.

Maybe put in a reference to Documentation/pinctrl.txt for in-depth
discussion? Also some stuff may be moved over there as generic
information. A lot of the text here does not seem to be about the
device tree ...

However maybe the use case is outside the Linux kernel too
and in that case I'm happy with it.

> +For a client device to operate correctly, certain pin controllers must
> +set up certain specific pin configurations. Some client devices need a
> +single static pin configuration, e.g. set up during initialization. Others
> +need to reconfigure pins at run-time, for example to tri-state pins when the
> +device is inactive. Hence, each client device can define a set of named
> +states. The number and names of those states is defined by the client device's
> +own binding.

Just so I understand: is "pin configuration" here strictly what we
handle in pinconf.c or does it include multiplexing (pinmux.c)?

I guess it's not multiplexing, just making sure.

Maybe state explicitly that multiplexing is not part of pin config,
else someone will invariably get confused.

> +Note that pin controllers themselves may also be client devices of themselves.

Insert something about this being known as config hogging.

The rest I barely understand so I leave it for the others to discuss...

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/