From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail81.out.titan.email (mail81.out.titan.email [3.216.99.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD888332ED3 for ; Tue, 23 Dec 2025 13:21:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=3.216.99.59 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766496111; cv=none; b=mw9cL9X6czDnoeBFf/iryyJVarQeimiuUQx3vT/2EQwH8TO9bIfz0NagE0K0iZ8PJWwQvS+O8dHZdeRSrjXMv0FrD+F1J8crf48m2nKZQ834PIWcpfi1ozJOKbSo2m1jYY+shOtSXGyHKFSWZVa/Er/DyTkVDLA039H/yg/4sIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766496111; c=relaxed/simple; bh=pecVmsoK5qEfj6C5kVS/vQWHu3GxbJmDpCtt4wlz6sw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bHg9BQetm2ll8Dgs+aO7dU7p86NUAXQJMhI3uUuUZu4pKtFBrSgn5c4z2bmFsOPS9vM7iJ7XRtkD0rSB32n455AZjMRGGl7OtAmkh2CJEj2wGQQHiDj3FazQlEj2vohG7fVKN87BYiYQoquxj9WOxux9JvIwhlgHMtL/X3BQwPw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ziyao.cc; spf=pass smtp.mailfrom=ziyao.cc; dkim=pass (1024-bit key) header.d=ziyao.cc header.i=@ziyao.cc header.b=QZrBurUv; arc=none smtp.client-ip=3.216.99.59 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ziyao.cc Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziyao.cc Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ziyao.cc header.i=@ziyao.cc header.b="QZrBurUv" Received: from localhost (localhost [127.0.0.1]) by smtp-out.flockmail.com (Postfix) with ESMTP id 4dbFZB5nPbz7t8t; Tue, 23 Dec 2025 13:03:46 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=I76jbNhd2RnmoQzo2cA05wxM926Wl/tgrqz3TL3NnOw=; c=relaxed/relaxed; d=ziyao.cc; h=from:to:subject:mime-version:date:cc:message-id:in-reply-to:references:from:to:cc:subject:date:message-id:in-reply-to:references:reply-to; q=dns/txt; s=titan1; t=1766495026; v=1; b=QZrBurUv3CXhzp3FFy9bI/Z7CVNdjHHS7lMRj4rol2r25ZAfM59ObLsQtz3lhLeahovWgQ12 uZC9VD6ALu2KtOhgTkuyKF5u1ftWhweOnCSrfb3LRXpmK8JCTWoz7d4haLsjUQZgeAqKQiclXxx 3Uw1XngdPpvWZqdjusB3LSTQ= Received: from pie (unknown [117.171.66.90]) by smtp-out.flockmail.com (Postfix) with ESMTPA id 4dbFZ26L07z7t88; Tue, 23 Dec 2025 13:03:38 +0000 (UTC) Date: Tue, 23 Dec 2025 13:03:27 +0000 Feedback-ID: :me@ziyao.cc:ziyao.cc:flockmailId From: Yao Zi To: Troy Mitchell , Inochi Amaoto , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Yixun Lan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Linus Walleij Cc: devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org Subject: Re: [PATCH 2/2] pinctrl: spacemit: support I/O power domain configuration Message-ID: References: <20251223-kx-pinctrl-aib-io-pwr-domain-v1-0-5f1090a487c7@linux.spacemit.com> <20251223-kx-pinctrl-aib-io-pwr-domain-v1-2-5f1090a487c7@linux.spacemit.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-F-Verdict: SPFVALID X-Titan-Src-Out: 1766495026646385511.30087.5691599438730667089@prod-use1-smtp-out1002. X-CMAE-Score: 0 X-CMAE-Analysis: v=2.4 cv=a8/K9VSF c=1 sm=1 tr=0 ts=694a9332 a=rBp+3XZz9uO5KTvnfbZ58A==:117 a=rBp+3XZz9uO5KTvnfbZ58A==:17 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=CEWIc4RMnpUA:10 a=lv0vYI88AAAA:8 a=q2HxCz5xri-O7L11LKAA:9 a=CjuIK1q_8ugA:10 a=E7e_GlrEz2WywKPBwZdi:22 a=9qqun4PRrEabIEPCFt1_:22 a=3z85VNIBY5UIEeAh_hcH:22 a=NWVoK91CQySWRX1oVYDe:22 On Tue, Dec 23, 2025 at 05:50:08PM +0800, Troy Mitchell wrote: > On Tue, Dec 23, 2025 at 05:42:26PM +0800, Inochi Amaoto wrote: > > On Tue, Dec 23, 2025 at 05:11:12PM +0800, Troy Mitchell wrote: > > > IO domain power control registers are used to configure the operating > > > voltage of dual-voltage GPIO banks. By default, these registers are > > > configured for 3.3V operation. As a result, even when a GPIO bank is > > > externally supplied with 1.8V, the internal logic continues to > > > operate in the 3.3V domain, which may lead to functional failures. > > > > > > This patch adds support for programming the IO domain power control > > > registers, allowing dual-voltage GPIO banks to be explicitly configured > > > for 1.8V operation when required. > > > > > > Care must be taken when configuring these registers. If a GPIO bank is > > > externally supplied with 3.3V while the corresponding IO power domain > > > is configured for 1.8V, external current injection (back-powering) > > > may occur, potentially causing damage to the GPIO pin. > > > > > > Due to these hardware constraints and safety considerations, the IO > > > domain power control registers are implemented as secure registers. > > > Access to these registers requires unlocking via the AIB Secure Access > > > Register (ASAR) in the APBC block before a single read or write > > > operation can be performed. > > > > > > Signed-off-by: Troy Mitchell > > > --- > > > arch/riscv/boot/dts/spacemit/k1.dtsi | 4 +- > > > drivers/pinctrl/spacemit/pinctrl-k1.c | 131 +++++++++++++++++++++++++++++++++- > > > 2 files changed, 131 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi > > > index 7818ca4979b6a7755722919a5958512aa11950ab..23ecb19624f227f3c39de35bf3078379f7a2490e 100644 > > > --- a/arch/riscv/boot/dts/spacemit/k1.dtsi > > > +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi > > > @@ -565,10 +565,12 @@ i2c8: i2c@d401d800 { > > > > > > pinctrl: pinctrl@d401e000 { > > > compatible = "spacemit,k1-pinctrl"; > > > - reg = <0x0 0xd401e000 0x0 0x400>; > > > + reg = <0x0 0xd401e000 0x0 0x400>, > > > + <0x0 0xd401e800 0x0 0x34>; > > > clocks = <&syscon_apbc CLK_AIB>, > > > <&syscon_apbc CLK_AIB_BUS>; > > > clock-names = "func", "bus"; > > > + spacemit,apbc = <&syscon_apbc 0x50>; > > > }; > > > > If you insist on a new reg field, you should change the binding as well. > Yes, I forgot to modify the binding. This will also break ABI compatibility with older devicetrees, I strongly suggest against a new item in reg property. Furthermore, it's unreasonable to describe d401_e000 - d401_e400 and d401_e800 - d401_e834 as separate memory regions. TRM claims the region starting from 0xd401_e000 with length 0xc00 is "Pad Configuration". So I think this separation neither simplifies anything nor matches the hardware. > > This change breaks binding, can we use something like <0x0 0xd401e000 0x0 0x1000>? If the TRM is correct, we probably can and should. > I'll double check this. Thanks! > > - Troy > > > > Regards, > > Inochi Regards, Yao Zi