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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAD++jL=OXJdJZpjbo0_C03vcgPe5btum-J0uifvSJkMaUWG-=w@mail.gmail.com>
Date: Tue, 3 Feb 2026 01:13:31 +0100
From: Linus Walleij <linusw@...nel.org>
To: Billy Tsai <billy_tsai@...eedtech.com>
Cc: Tony Lindgren <tony@...mide.com>, Haojian Zhuang <haojian.zhuang@...aro.org>, 
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	andrew@...econstruct.com.au, BMC-SW@...eedtech.com
Subject: Re: [PATCH v2 0/3] pinctrl: single: bit-per-mux DT flexibility, probe
 robustness, and consistent pinconf offsets

Hi Billy,

thanks for your patch!

On Fri, Jan 23, 2026 at 4:41 AM Billy Tsai <billy_tsai@...eedtech.com> wrote:

> This series is motivated by the pinmux and pin configuration register layout
> of the ASPEED AST2700 SoC, which exposes several limitations in the current
> pinctrl-single behavior on bit-per-mux platforms.
>
> On AST2700, pinmux registers are laid out contiguously per pin, with each pin
> occupying a fixed-width bitfield and pins packed sequentially within shared
> registers. While the existing pinctrl-single,bits binding can represent this
> layout, doing so requires manually constructing offset/mask/value tuples that
> do not map naturally to the hardware model and are error-prone to maintain.
> In practice, describing pinmux configuration in terms of <pin_index func_sel>
> better reflects the underlying design, improves DTS readability, and reduces
> the chance of mask or shift mistakes, while still preserving
> pinctrl-single,bits as the preferred and fully supported binding when present.
>
> AST2700 pin configuration registers follow the same per-pin packing scheme as
> pinmux, with both multi-bit and single-bit fields arranged sequentially per
> pin. However, the current pinctrl-single pinconf offset calculation assumes a
> linear per-register layout, which does not align with this bit-per-pin scheme
> when bit-per-mux or function-mask configurations are in use. Aligning pinconf
> offset computation with the pinmux logic ensures consistent and predictable
> behavior and avoids incorrect pinconf operations on such platforms.
>
> In addition, on many AST2700 systems the SCU register range containing the
> pinctrl registers is commonly reserved by a top-level syscon node or by
> firmware. In this configuration, devm_request_mem_region() can return -EBUSY
> even though the registers are valid and intended to be shared. Since
> pinctrl-single is a direct MMIO-based driver and does not integrate with
> syscon/regmap, failing probe in this case prevents any pinmux configuration
> from being applied. Treating this condition as a warning allows the driver to
> initialize while still reporting the shared-resource situation.
>
> Signed-off-by: Billy Tsai <billy_tsai@...eedtech.com>

I would need the pinctrl-single maintainers to review this before merging.

I personally would not try to extend pinctrl-single for this, I would
write a custom driver using as much of the existing helpers as I can
and use the pinmux = <...>; DT property.

Yours,
Linus Walleij