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-next>] [day] [month] [year] [list]
Message-ID: <20260123-upstream_pinctrl_single-v2-0-40f8063cc5a2@aspeedtech.com>
Date: Fri, 23 Jan 2026 11:41:22 +0800
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Tony Lindgren <tony@...mide.com>, Haojian Zhuang
	<haojian.zhuang@...aro.org>, Linus Walleij <linusw@...nel.org>
CC: <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>, Billy Tsai
	<billy_tsai@...eedtech.com>
Subject: [PATCH v2 0/3] pinctrl: single: bit-per-mux DT flexibility, probe
 robustness, and consistent pinconf offsets

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>
---
Changes in v2:
- Updated the cover letter to better explain the AST2700-specific motivation
  for this series and why the current pinctrl-single behavior is insufficient
  on such platforms.
- Clarified the rationale for allowing probe to continue when the MMIO region
  is already reserved.
- No functional changes compared to v1.
- Link to v1: https://lore.kernel.org/r/20251222-upstream_pinctrl_single-v1-0-e4aaa4eeb936@aspeedtech.com

---
Billy Tsai (3):
      pinctrl: single: add per-pin binding support for bit-per-mux
      pinctrl: single: Allow probe to continue if mem region busy
      pinctrl: single: unify pinconf offset mapping with pinmux

 drivers/pinctrl/pinctrl-single.c | 150 ++++++++++++++++++++++++++++-----------
 1 file changed, 110 insertions(+), 40 deletions(-)
---
base-commit: dd9b004b7ff3289fb7bae35130c0a5c0537266af
change-id: 20251222-upstream_pinctrl_single-99e8df1fe2b9

Best regards,
-- 
Billy Tsai <billy_tsai@...eedtech.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ