[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<OSQPR06MB725257E71F0B7F7F1013263D8B98A@OSQPR06MB7252.apcprd06.prod.outlook.com>
Date: Wed, 4 Feb 2026 06:54:13 +0000
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Tony Lindgren <tony@...mide.com>
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>, Linus Walleij <linusw@...nel.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
Hi Tony,
This series proposes a set of changes to pinctrl-single motivated by
bit-per-mux SoC designs such as ASPEED AST2700 (per-pin DT encoding,
aligned pinconf offsets, and allowing probe to continue when the MMIO
region is already reserved).
Linus reviewed the series and noted that he would prefer a custom
pinctrl driver using existing helpers and the pinmux = <...> DT
property, rather than extending pinctrl-single, and suggested that the
pinctrl-single maintainers review the approach before any merge
decision.
I would appreciate your guidance on whether extending
pinctrl-single in this direction is acceptable, or if the preference is
to pursue a dedicated driver instead.
Thanks for your time and review.
Best regards,
Billy
Powered by blists - more mailing lists