From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/5] pinctrl: clarify some dt pinconfig options
Date: Wed, 19 Jun 2013 16:10:39 -0600 [thread overview]
Message-ID: <51C22C5F.5020402@wwwdotorg.org> (raw)
In-Reply-To: <201306141742.49923.heiko@sntech.de>
On 06/14/2013 09:42 AM, Heiko St?bner wrote:
> The bias-pull-* options use values > 0 to indicate that the pull should
> be activated and optionally also indicate the strength of the pull.
> Therefore use an default value of 1 for these options.
>
> Split the low-power-mode option into low-power-enable and -disable.
>
> Update the documentation to describe the param arguments better.
>
> Wrong default options
> Reported-by: James Hogan <james.hogan@imgtec•com>
>
That blank line should be before the Reported-by not after it.
> Signed-off-by: Heiko Stuebner <heiko@sntech•de>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> -low-power-mode - low power mode
> +low-power-enable - enable low power mode
> +low-power-disable - disable low power mode
Hmmm. That's changing the binding definition. What if somebody already
wrote their device tree according previous definition?
It seems to be that tri-states are preferable for pinctrl DT:
no entry: do nothing
= 0: disable
= 1: enable
> +Arguments for parameters:
> +
> +- bias-pull-up, -down and -pin-default take as optional argument 0 to disable
> + the pull, on hardware supporting it the pull strength in Ohm. bias-disable
> + will also disable any active pull.
Does this agree with the latest definition of the kernel-internal
meaning of 0 for pull-up/down?
> +- input-schmitt takes as argument the adjustable hysteresis in a
> + driver-specific format
> +
> +- input-debounce takes the debounce time as argument or 0 to disable debouncing
> +
> +- power-source argument is the custom value describing the source to select
> +
> +- slew-rate takes as argument the target rate in a driver-specific format
If those things have driver-specific (note: should be
DT-binding-specific, not driver-specific) values, then I'm not convinced
that having a generic parameter name for them is a good idea; it makes
things look the same when they aren't. By forcing each binding to
include the vendor prefix on those properties and hence define a custom
property name, you're making it clear that the semantics may be different.
next prev parent reply other threads:[~2013-06-19 22:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 15:41 [PATCH 0/5] pinctrl: fix some issues with new pinconfig dt parsing Heiko Stübner
2013-06-14 15:42 ` [PATCH 1/5] pinctrl: update the documentation for some pinconfig params Heiko Stübner
2013-06-16 10:26 ` Linus Walleij
2013-06-16 10:45 ` Heiko Stübner
2013-06-16 12:26 ` Linus Walleij
2013-06-14 15:42 ` [PATCH 2/5] pinctrl: clarify some dt pinconfig options Heiko Stübner
2013-06-16 10:28 ` Linus Walleij
2013-06-19 22:10 ` Stephen Warren [this message]
2013-06-24 9:51 ` Linus Walleij
2013-06-14 15:43 ` [PATCH 3/5] pinctrl: handle zero found dt pinconfig properties better Heiko Stübner
2013-06-16 10:29 ` Linus Walleij
2013-06-14 15:43 ` [PATCH 4/5] pinctrl: dynamically alloc temp array when parsing dt pinconf options Heiko Stübner
2013-06-16 10:31 ` Linus Walleij
2013-06-14 15:44 ` [PATCH 5/5] pinctrl: rockchip: correctly handle arguments of " Heiko Stübner
2013-06-16 10:35 ` Linus Walleij
2013-06-16 11:02 ` Heiko Stübner
2013-06-16 12:35 ` Linus Walleij
2013-06-16 15:41 ` [PATCH v2] " Heiko Stübner
2013-06-17 15:48 ` Linus Walleij
2013-06-14 15:53 ` [PATCH 0/5] pinctrl: fix some issues with new pinconfig dt parsing James Hogan
2013-06-17 3:03 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C22C5F.5020402@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox