linux-kernel - Re: [PATCH v2 0/3] pinctrl: single: bit-per-mux DT flexibility, probe robustness, and consistent pinconf offsets

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:
 <OSQPR06MB72526DA818EACDE2931BA0168B62A@OSQPR06MB7252.apcprd06.prod.outlook.com>
Date: Tue, 10 Feb 2026 06:28:33 +0000
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Tony Lindgren <tony@...mide.com>, Linus Walleij <linusw@...nel.org>
CC: Haojian Zhuang <haojian.zhuang@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-omap@...r.kernel.org"
	<linux-omap@...r.kernel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "andrew@...econstruct.com.au"
	<andrew@...econstruct.com.au>, BMC-SW <BMC-SW@...eedtech.com>
Subject: Re: [PATCH v2 0/3] pinctrl: single: bit-per-mux DT flexibility, probe
 robustness, and consistent pinconf offsets

> * Linus Walleij <linusw@...nel.org> [260209 09:51]:
> > On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai <billy_tsai@...eedtech.com> wrote:
> >
> > > To make sure I align with your expectations:
> > > 1) Would you prefer the new driver to be fully standalone (using the
> > >    GENERIC_PIN* helpers + syscon/regmap-mmio), rather than trying to
> > >    refactor/export helpers from pinctrl-single?
> >
> > Yes. Conor improved these helpers so now it should be possible
> > to use these to do a very simple and slim driver for what you
> > want to do.
> >
> > >    Action item: Introduce a new pinctrl-single-bit.c driver and DT
> > >    binding, which can also cover the existing bit-per-mux logic currently
> > >    in pinctrl-single.c.
> >
> > Sounds about right.
> >
> > > 2) For the syscon/regmap hookup, is it acceptable to add a syscon phandle
> > >    property in DT (e.g. "syscon = <&scu>;") for the new driver to obtain
> > >    the regmap, or do you prefer a different binding/property name?
> >
> > This works for me.

> Great, sounds good to me too!

Hi Tony & Linus,

Thanks again for the earlier guidance — that was very helpful.

I wanted to double-check one remaining detail around the syscon/regmap
hookup. As discussed before, using an explicit syscon phandle on the
pinctrl node (e.g. syscon = <&scu>) is fine from my side, and I
understand that approach is acceptable.

Andrew also pointed out that, for AST2700/SoC0, the SCU is moving towards
an auxiliary-bus based model, where subfunctions such as pinctrl are
instantiated as auxiliary devices by the SCU driver itself, with the
pinctrl node appearing as a subnode of the SCU binding. In that setup,
the pinctrl driver would obtain the regmap from its parent device rather
than via an explicit DT phandle, similar to what is discussed here:
  https://lore.kernel.org/all/459f84c56a5010910ecbf8b445c092674f060691.camel@codeconstruct.com.au/

Before proceeding, I wanted to confirm whether this auxbus-based approach
for the new pinctrl-single-bit driver would also be acceptable from your
perspective, given that it avoids introducing a generalized DT-based
syscon hookup up front and aligns with the SoC0 direction.

Thanks,
Billy