[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170626184050.k4fibk5m42f47sug@rob-hp-laptop>
Date: Mon, 26 Jun 2017 13:40:50 -0500
From: Rob Herring <robh@...nel.org>
To: Jacopo Mondi <jacopo+renesas@...ndi.org>
Cc: linus.walleij@...aro.org, andy.shevchenko@...il.com,
dongas86@...il.com, geert+renesas@...der.be,
Chris.Brandt@...esas.com, laurent.pinchart@...asonboard.com,
mark.rutland@....com, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] pinctrl: generic: Add output-enable property
On Thu, Jun 22, 2017 at 12:00:58PM +0200, Jacopo Mondi wrote:
> Add output-enable generic pin configuration property.
> This properties allows enabling/disabling pin's output capabilities
> without actually driving any value on the line.
>
> ---
> v1->v2:
> - Expand the property description as suggested by Laurent. I ended up
> mentioning the in-famous output buffer :)
>
> One (more) question to GPIO people on:
> + PCONFDUMP(PIN_CONFIG_OUTPUT_ENABLE, "output enabled", NULL, false),
>
> I copied this from INPUT_ENABLE where arguments 2 and 3 passed to PCONFDUMP are
> NULL and false even if the property has an argument, used to enable/disable
> the input mode. Is this intended? Should that be turned instead to
> - PCONFDUMP(PIN_CONFIG_INPUT_ENABLE, "input enabled", NULL, false),
> + PCONFDUMP(PIN_CONFIG_INPUT_ENABLE, "input enabled", "enabled", true),
>
> Note that the same applies to most of the properties that have an
> "enable"/"disable" argument. Just to make sure this is done on purpose.
>
> Thanks
> j
> .../devicetree/bindings/pinctrl/pinctrl-bindings.txt | 2 ++
Acked-by: Rob Herring <robh@...nel.org>
> drivers/pinctrl/pinconf-generic.c | 3 +++
> include/linux/pinctrl/pinconf-generic.h | 15 +++++++++++----
> 3 files changed, 16 insertions(+), 4 deletions(-)
Powered by blists - more mailing lists