linux-kernel - Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one: Configure UART0 pinmux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPEfUBl6fMe6QYdY@makrotopia.org>
Date: Thu, 16 Oct 2025 17:37:36 +0100
From: Daniel Golle <daniel@...rotopia.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: Sjoerd Simons <sjoerd@...labora.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Ryder Lee <ryder.lee@...iatek.com>,
	Jianjun Wang <jianjun.wang@...iatek.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Manivannan Sadhasivam <mani@...nel.org>,
	Chunfeng Yun <chunfeng.yun@...iatek.com>,
	Vinod Koul <vkoul@...nel.org>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Lee Jones <lee@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Lorenzo Bianconi <lorenzo@...nel.org>, Felix Fietkau <nbd@....name>,
	kernel@...labora.com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, linux-pci@...r.kernel.org,
	linux-phy@...ts.infradead.org, netdev@...r.kernel.org,
	Bryan Hinton <bryan@...anhinton.com>
Subject: Re: [PATCH 02/15] arm64: dts: mediatek: mt7981b-openwrt-one:
 Configure UART0 pinmux

On Thu, Oct 16, 2025 at 04:29:14PM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/10/25 14:38, Daniel Golle ha scritto:
> > On Thu, Oct 16, 2025 at 12:08:38PM +0200, Sjoerd Simons wrote:
> > > Add explicit pinctrl configuration for UART0 on the OpenWrt One board,
> > > 
> > > Signed-off-by: Sjoerd Simons <sjoerd@...labora.com>
> > > ---
> > >   arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts | 11 +++++++++++
> > >   1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > index 968b91f55bb27..f836059d7f475 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
> > > @@ -22,6 +22,17 @@ memory@...00000 {
> > >   	};
> > >   };
> > > +&pio {
> > > +	uart0_pins: uart0-pins {
> > > +		mux {
> > > +			function = "uart";
> > > +			groups = "uart0";
> > > +		};
> > > +	};
> > > +};
> > > +
> > >   &uart0 {
> > > +	pinctrl-names = "default";
> > > +	pinctrl-0 = <&uart0_pins>;
> > >   	status = "okay";
> > >   };
> > 
> > As there is only a single possible pinctrl configuration for uart0,
> > both the pinmux definition as well as the pinctrl properties should go
> > into mt7981b.dtsi rather than in the board's dts.
> 
> If there's really one single possible pin configuration for the UART0 pins,
> as in, those pins *do not* have a GPIO mode, then yes I agree.
> 
> If those pins can be as well configured as GPIOs, this goes to board DTS.

I respectfully disagree and will explain below.

All pinmux pins on the MediaTek platform also allow being configured as
GPIOs. However, if you configure those as GPIOs the consequence is that
you cannot use UART0 any more at all. So using UART0 at all always
implies using exactly those pins, there is no alternative to that.

Hence every board with every possible uses of pins 32 and 33 (there is
only RX and TX for UART0, RTS/CTS flow-control is not possible) can be
represented without needing to configure the pinctrl for uart0 on the
board level. There isn't going to be any variation on the board-level
when it comes to uart0. Either it is enabled (status = "okay";), and
that will always imply using the 'uart0' group in mode 'uart', or, in
case any of the two pins of uart0 is used for something else that means
uart0 cannot be enabled. Simple as that.

Hence there is no need to duplicate that pinctrl settings on each and
every board, as controlling the 'status' property on the board-level
already gives 100% freedom.

(Sidenote: As even the BootROM already uses those two pins as UART for
debug output, it is very unlikely that anyone would actually use them
for anything else in production. Apart from being used as GPIOs you can
also use pins 32 and 33 as an I2C target for external debug access to the
registers of either the sgmii0_phy, sgmii1_phy or u3_phy. However, that
doesn't matter in terms of the debate above, as the crucial point there
is that using uart0 always implies using group 'uart0' in 'uart' mode.)