From: Sascha Hauer <s.hauer@pengutronix.de>
To: barebox@lists.infradead.org, Ahmad Fatoum <a.fatoum@barebox.org>
Subject: Re: [PATCH] pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL
Date: Mon, 15 Jun 2026 10:29:37 +0200 [thread overview]
Message-ID: <178151217700.3636233.1064124468993563081.b4-ty@pengutronix.de> (raw)
In-Reply-To: <20260606182148.337137-1-a.fatoum@barebox.org>
On Sat, 06 Jun 2026 20:20:24 +0200, Ahmad Fatoum wrote:
> To make porting drivers from newer Linux versions a bit easier,
> port Linux commit 203a83112e097a501fbe12722b6342787497efe0:
>
> | pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL
> |
> | This generic pin config property is confusingly named so let's
> | rename it to make things clearer.
> |
> | There are already drivers in the tree that use PIN_CONFIG_OUTPUT
> | to *read* the value of an output driven pin, which is a big
> | semantic confusion for the head: are we then reading the
> | setting of the output or the actual value/level that is put
> | out on the pin?
> |
> | We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver
> | buffers for output, so this can by logical conclusion only
> | drive the voltage level if it should be any different.
> |
> | But if we read the pin, are we then reading the *setting* of
> | the output value or the *actual* value we can see on the
> | line?
> |
> | If the pin has not first been set into output mode with
> | PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode
> | or tristate, what will reading this property actually
> | return?
> |
> | Reading the current users reading this property it is clear
> | that what we read is the logical level of the pin as 0 or 1
> | depending on if it is low or high.
> |
> | Rename it to PIN_CONFIG_LEVEL so it is crystal clear that
> | we set or read the voltage level of the pin and nothing else.
> |
> | Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> | Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> [...]
Applied, thanks!
[1/1] pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVEL
https://git.pengutronix.de/cgit/barebox/commit/?id=afd843c1a83b (link may not be stable)
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
prev parent reply other threads:[~2026-06-15 8:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 18:20 Ahmad Fatoum
2026-06-15 8:29 ` Sascha Hauer [this message]
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=178151217700.3636233.1064124468993563081.b4-ty@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@barebox.org \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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