From: "Michał Kardaś" <mkmkl@google.com>
To: "Linus Walleij" <linusw@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Douglas Anderson" <dianders@chromium.org>,
"Vic Huang" <vich@google.com>,
linux-gpio@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, "Michał Kardaś" <mkmkl@google.com>
Subject: [PATCH v1 0/2] pinctrl / 8250_dw: Allow drivers to keep init pinctrl state until first open
Date: Mon, 10 Aug 2026 13:06:33 +0000 [thread overview]
Message-ID: <20260810130635.1166626-1-mkmkl@google.com> (raw)
During device probe, pinctrl_bind_pins() binds pins to their "init" state
if specified in Device Tree. When probe finishes, pinctrl_init_done()
automatically transitions the pins from "init" to "default" state.
While this auto-transition works well for devices that are immediately
active upon driver binding, certain peripherals (such as power-sequenced
devices connected over UART, SPI, or other buses) remain unpowered until
userspace explicitly opens the device node or attaches a protocol driver.
On board designs where the connected peripheral is kept unpowered during
boot, auto-selecting "default" pin states (where signals such as TXD or
RTS may be driven high or pulled up) can cause parasitic back-powering
into the unpowered peripheral through its ESD protection diodes.
To address this without requiring new Device Tree binding names, this
series extends the existing "init" pinctrl state mechanism (introduced
in commit ef0eebc05130 ("drivers/pinctrl: Add the concept of an "init"
state")):
1. Patch 1 (pinctrl core):
Adds pinctrl_keep_init_state(dev). When called during probe,
pinctrl_init_done() opts out of the automatic "init" -> "default"
transition, allowing the driver to keep pins in the safe "init" state
upon probe completion. Updates Documentation/driver-api/pin-control.rst.
Board configurations that do not define an "init" state are completely
unaffected.
2. Patch 2 (8250_dw serial driver):
Updates 8250_dw so that when an "init" state is defined for the port,
the driver calls pinctrl_keep_init_state() and preserves the "init"
state until the port is first opened via dw8250_do_pm(), at which point
it transitions to "default" state and resumes normal operation.
Testing:
- Built and verified with CONFIG_PINCTRL=y and CONFIG_PINCTRL=n on
upstream tree.
- Verified zero checkpatch warnings (`checkpatch.pl --strict`).
- Note: Functional hardware testing was performed on a downstream kernel
tree where the physical back-powering issue was reproduced and verified
fixed. The underlying UART pinctrl lifecycle issue and core logic apply
identically to upstream.
Michał Kardaś (2):
pinctrl: core: Allow drivers to keep "init" pinctrl state after probe
tty: serial: 8250_dw: Keep init pinctrl state until first open
Documentation/driver-api/pin-control.rst | 10 ++++++----
drivers/pinctrl/core.c | 20 ++++++++++++++++++++
drivers/tty/serial/8250/8250_dw.c | 13 ++++++++++++-
include/linux/pinctrl/consumer.h | 6 ++++++
include/linux/pinctrl/devinfo.h | 2 ++
5 files changed, 46 insertions(+), 5 deletions(-)
--
2.55.0.654.g21b8a5bc05-goog
next reply other threads:[~2026-08-10 13:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 13:06 Michał Kardaś [this message]
2026-08-10 13:06 ` [PATCH v1 1/2] pinctrl: core: Allow drivers to keep "init" pinctrl state after probe Michał Kardaś
2026-08-10 18:12 ` Andy Shevchenko
2026-08-10 13:06 ` [PATCH v1 2/2] tty: serial: 8250_dw: Keep init pinctrl state until first open Michał Kardaś
2026-08-10 18:17 ` Andy Shevchenko
2026-08-11 6:36 ` Linus Walleij
2026-08-11 6:34 ` [PATCH v1 0/2] pinctrl / 8250_dw: Allow drivers to keep " Linus Walleij
2026-08-11 17:00 ` Doug Anderson
2026-08-11 18:47 ` Linus Walleij
2026-08-11 20:15 ` Doug Anderson
2026-08-12 1:26 ` Doug Anderson
2026-08-12 7:00 ` Andy Shevchenko
2026-08-12 16:28 ` Doug Anderson
2026-08-12 6:51 ` Andy Shevchenko
2026-08-12 7:46 ` Linus Walleij
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=20260810130635.1166626-1-mkmkl@google.com \
--to=mkmkl@google.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=vich@google.com \
/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
all inboxes | Powered by JetHome®