From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A2663DF01C for ; Mon, 10 Aug 2026 13:06:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786367200; cv=none; b=P7wHS1bE7EhjVeAzE96ohN3JdWMFiDvWognCdz3A3uwU2BmDQYma/ZCt4gCMtQU6zHiF5zGyCC3N2FopRjabYX+jZ38rlPf1yo3mMzUpGEahJ4BtfDgcwwapxGr5YAZ52boO7mUVMxI4Eb1q/rYPs8A+EkIpyc40bTtAfFmVPuw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786367200; c=relaxed/simple; bh=tQTTUSW7eUWfh15MDV5ZX7e6q64R5S4/Oqee01xSP2s=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=BcV/SBc0cAewfh/JLwx9tNsSU6JP1Bs3ju0HAtDfUyJnoRt1wJTk9Sgx4TAgtbCD9zCgeIKSegm1MWDILn6VUZAA7bp2ixYdzHp9q647+BudAVL1Dr0bHHTvDHD1dd6awbBxLl1PGPKce69k6zQqODANKeM+VKO0eWyVZZJ5ThU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--mkmkl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NmXPU0La; arc=none smtp.client-ip=209.85.208.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--mkmkl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NmXPU0La" Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-39cbf7e087eso7929971fa.0 for ; Mon, 10 Aug 2026 06:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786367197; x=1786971997; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:from:to:cc:subject:date:message-id :reply-to:content-type; bh=95XcyuahfruBLeOEab+HwcmrCQNnVz9pT3RpyBKiDUY=; b=NmXPU0Lad6lCZaJrpbVNx4xxpalTRW9the7mhqbHsFDRHuHK6nBEQv6dMwA6n6eL1L ZeHJ3eQn38VcC2byGebImq0oUGI2gaRhkR8fasIKCrKQMiVkI2C9gVz4pXI/yJL+Rn3D CL8JnnlsmwBOtpwMKdpU0qT4RimephFMhr6vGVfQqCdusiHeC8pd3Z3oekbICbLLo8Xm yXOU2JytQo8wHPr83dauMMSPbZgynw+i3r9oNaQZs3fGYdBUxOK03ld/wFYpBMJNOHy9 A1XRevjWUN3x30ZQm75CDBc1eycZReSM3iZD9CgXouzXjXLv/sikCorAngdJluUP0BUI AIsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786367197; x=1786971997; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=95XcyuahfruBLeOEab+HwcmrCQNnVz9pT3RpyBKiDUY=; b=Pxsp1OaXW03SGNPRt4/hJab6u3Yh0qYBbmEemWyuBfxHclmxGoEPHvs5QWa/UxCtcA dXSMKhXHUaB4XGaLocvy0dgBv3c7y/PRK0zPGBUe6v0lJRyRLd29V3M3/OygwwDe9sff 73Rrf6YrWpIwfF+2gqeUu3GRPzbV2fsp9Tl5EUwBakMzRL731aMuZFLBDciwAqMWjC1W wVuIq/vMJaW9xxkZjqZ7I9kCKLEH+Jbt+CiEWO6o6QaXvGLcOn4oRu1UkmCAjMg/GTGX bauAj6vrDTx5reXsiUGq9GZLjuz1/4+nb7Yi07OPC5b8+S5DqZCSGld5K1fbfbegXEBA JZQQ== X-Forwarded-Encrypted: i=1; AHgh+Rrn9nkIEVixdew4U81uflSW7FA8fN53/oBoeztCqPina5l+2BOvWBlffBV0ggaTxwwsO3huUAhXJIlgNHM=@vger.kernel.org X-Gm-Message-State: AOJu0YyA1KbZNqYjJs4uFj8r1SDh3o8My/uQNlPH38fUEIEoVHQ5+Cdu Sawba6lPuZ0tB0eCIb180rHYSX1lu/JwYqdS+3ZqHFNUj/s/jsX4vreP8jDrMTb4MFCK+mOqGPR gwg== X-Received: from ljjo19.prod.google.com ([2002:a2e:9b53:0:b0:39b:50cf:4a26]) (user=mkmkl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:651c:54e:b0:39a:fa7c:b152 with SMTP id 38308e7fff4ca-39fe5648f40mr20830661fa.4.1786367196243; Mon, 10 Aug 2026 06:06:36 -0700 (PDT) Date: Mon, 10 Aug 2026 13:06:33 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.654.g21b8a5bc05-goog Message-ID: <20260810130635.1166626-1-mkmkl@google.com> Subject: [PATCH v1 0/2] pinctrl / 8250_dw: Allow drivers to keep init pinctrl state until first open From: "=?UTF-8?q?Micha=C5=82=20Karda=C5=9B?=" To: Linus Walleij , "=?UTF-8?q?Ilpo=20J=C3=A4rvinen?=" , Greg Kroah-Hartman , Jiri Slaby Cc: Andy Shevchenko , Douglas Anderson , Vic Huang , linux-gpio@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, "=?UTF-8?q?Micha=C5=82=20Karda=C5=9B?=" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3Dy and CONFIG_PINCTRL=3Dn 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=C5=82 Karda=C5=9B (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(-) --=20 2.55.0.654.g21b8a5bc05-goog