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@aspeedtech.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@aspeedtech.com>

Hi Billy,

thanks for your patch!

On Fri, Jan 23, 2026 at 4:41 AM Billy Tsai <billy_tsai@aspeedtech.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@aspeedtech.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