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

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

[Billy Tsai]

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>

[PATCH v2 1/3] pinctrl: single: add per-pin binding support for bit-per-mux

[Billy Tsai]

Add support for binding where bit-per-mux users specify pins as
<pin_index func_sel> pairs. Prefer explicit bits binding when present,
but fall back to the new per-pin binding for improved flexibility.
This approach is intended to adapt to hardware with a regular register
layout, where pin functions are arranged with a fixed stride. For example,
the function of pin 0 is controlled by bits [3:0] at offset 0, the
function of pin 1 by bits [7:4] at the same offset, and so on.

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
 drivers/pinctrl/pinctrl-single.c | 132 +++++++++++++++++++++++++++++----------
 1 file changed, 100 insertions(+), 32 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 998f23d6c317..757c22cc09f3 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1041,29 +1041,81 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
 			break;
 		}
 
-		offset = pinctrl_spec.args[0];
-		vals[found].reg = pcs->base + offset;
+		/*
+		 * For legacy (non bit-per-mux) users the first cell is the
+		 * register offset and the second (and optional third) cell is
+		 * the value to be written.
+		 *
+		 * For bit-per-mux users we want a simpler binding where the
+		 * first cell is the pin index and the second cell is the
+		 * function selector. Translate that into register offset,
+		 * value and mask here so the rest of the driver can stay
+		 * Register based.
+		 */
+		if (!pcs->bits_per_mux) {
+			offset = pinctrl_spec.args[0];
+			vals[found].reg = pcs->base + offset;
 
-		switch (pinctrl_spec.args_count) {
-		case 2:
-			vals[found].val = pinctrl_spec.args[1];
-			break;
-		case 3:
-			vals[found].val = (pinctrl_spec.args[1] | pinctrl_spec.args[2]);
-			break;
-		}
+			switch (pinctrl_spec.args_count) {
+			case 2:
+				vals[found].val = pinctrl_spec.args[1];
+				break;
+			case 3:
+				vals[found].val = (pinctrl_spec.args[1] |
+						   pinctrl_spec.args[2]);
+				break;
+			}
 
-		dev_dbg(pcs->dev, "%pOFn index: 0x%x value: 0x%x\n",
-			pinctrl_spec.np, offset, vals[found].val);
+			dev_dbg(pcs->dev, "%pOFn offset: 0x%x value: 0x%x\n",
+				 pinctrl_spec.np, offset, vals[found].val);
 
-		pin = pcs_get_pin_by_offset(pcs, offset);
-		if (pin < 0) {
-			dev_err(pcs->dev,
-				"could not add functions for %pOFn %ux\n",
-				np, offset);
-			break;
+			pin = pcs_get_pin_by_offset(pcs, offset);
+			if (pin < 0) {
+				dev_err(pcs->dev,
+					"could not add functions for %pOFn %ux\n",
+					np, offset);
+				break;
+			}
+			pins[found++] = pin;
+		} else {
+			unsigned int pin_index, func_sel;
+			unsigned int shift, mask, val;
+
+			/* Expect <pin_index func_sel> for bit-per-mux users. */
+			if (pinctrl_spec.args_count < 2) {
+				dev_err(pcs->dev,
+					"invalid args_count for bit-per-mux spec: %i\n",
+					pinctrl_spec.args_count);
+				break;
+			}
+
+			pin_index = pinctrl_spec.args[0];
+			func_sel = pinctrl_spec.args[1];
+
+			if (pin_index >= pcs->desc.npins) {
+				dev_err(pcs->dev,
+					"pin index out of range for %pOFn: %u (npins %u)\n",
+					np, pin_index, pcs->desc.npins);
+				break;
+			}
+
+			offset = pcs_pin_reg_offset_get(pcs, pin_index);
+			shift = pcs_pin_shift_reg_get(pcs, pin_index);
+
+			mask = pcs->fmask << shift;
+			val = (func_sel << shift) & mask;
+
+			vals[found].reg = pcs->base + offset;
+			vals[found].val = val;
+			vals[found].mask = mask;
+
+			dev_dbg(pcs->dev,
+				 "%pOFn pin: %u offset: 0x%x func: 0x%x val: 0x%x mask: 0x%x\n",
+				 pinctrl_spec.np, pin_index, offset,
+				 func_sel, val, mask);
+
+			pins[found++] = pin_index;
 		}
-		pins[found++] = pin;
 	}
 
 	pgnames[0] = np->name;
@@ -1280,21 +1332,37 @@ static int pcs_dt_node_to_map(struct pinctrl_dev *pctldev,
 	}
 
 	if (pcs->bits_per_mux) {
-		ret = pcs_parse_bits_in_pinctrl_entry(pcs, np_config, map,
-				num_maps, pgnames);
-		if (ret < 0) {
-			dev_err(pcs->dev, "no pins entries for %pOFn\n",
-				np_config);
-			goto free_pgnames;
+		/*
+		 * For bit-per-mux users there are two possible bindings:
+		 * - pinctrl-single,bits: offset/value/mask triples
+		 * - pinctrl-single,pins: <pin_index func_sel> pairs
+		 *
+		 * Prefer the explicit bits binding when present so existing
+		 * users keep their current behaviour, otherwise fall back
+		 * to the per-pin binding.
+		 */
+		if (of_find_property(np_config, "pinctrl-single,bits", NULL)) {
+			ret = pcs_parse_bits_in_pinctrl_entry(pcs, np_config,
+							      map, num_maps,
+							      pgnames);
+		} else if (of_find_property(np_config,
+					    "pinctrl-single,pins", NULL)) {
+			ret = pcs_parse_one_pinctrl_entry(pcs, np_config, map,
+							  num_maps, pgnames);
+		} else {
+			ret = -EINVAL;
 		}
 	} else {
-		ret = pcs_parse_one_pinctrl_entry(pcs, np_config, map,
-				num_maps, pgnames);
-		if (ret < 0) {
-			dev_err(pcs->dev, "no pins entries for %pOFn\n",
-				np_config);
-			goto free_pgnames;
-		}
+		if (of_find_property(np_config, "pinctrl-single,pins", NULL))
+			ret = pcs_parse_one_pinctrl_entry(pcs, np_config, map,
+							  num_maps, pgnames);
+		else
+			ret = -EINVAL;
+	}
+
+	if (ret < 0) {
+		dev_err(pcs->dev, "no pins entries for %pOFn\n", np_config);
+		goto free_pgnames;
 	}
 
 	return 0;

-- 
2.34.1

[PATCH v2 2/3] pinctrl: single: Allow probe to continue if mem region busy

[Billy Tsai]

Skip exclusive memory region reservation failure during probe and
continue initialization with a warning. This enables support for
systems where the memory region may already be reserved, improving
probe robustness.

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
 drivers/pinctrl/pinctrl-single.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 757c22cc09f3..e65ae737b4c5 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1910,13 +1910,13 @@ static int pcs_probe(struct platform_device *pdev)
 
 	pcs->res = devm_request_mem_region(pcs->dev, res->start,
 			resource_size(res), DRIVER_NAME);
-	if (!pcs->res) {
-		dev_err(pcs->dev, "could not get mem_region\n");
-		return -EBUSY;
-	}
+	if (!pcs->res)
+		dev_warn(pcs->dev, "mem_region busy, continuing without reservation\n");
+	else
+		res = pcs->res;
 
-	pcs->size = resource_size(pcs->res);
-	pcs->base = devm_ioremap(pcs->dev, pcs->res->start, pcs->size);
+	pcs->size = resource_size(res);
+	pcs->base = devm_ioremap(pcs->dev, res->start, pcs->size);
 	if (!pcs->base) {
 		dev_err(pcs->dev, "could not ioremap\n");
 		return -ENODEV;

-- 
2.34.1

[PATCH v2 3/3] pinctrl: single: unify pinconf offset mapping with pinmux

[Billy Tsai]

Use the same register offset calculation for pinconf as pinmux to
properly handle bit-per-mux configurations. Ensures consistent and
correct offset mapping for pin configuration operations.

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
 drivers/pinctrl/pinctrl-single.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index e65ae737b4c5..aaf830315c5d 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -505,7 +505,8 @@ static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
 			continue;
 		}
 
-		offset = pin * (pcs->width / BITS_PER_BYTE);
+		/* Use the same offset mapping as pinmux (handles bit-per-mux) */
+		offset = pcs_pin_reg_offset_get(pcs, pin);
 		data = pcs->read(pcs->base + offset) & func->conf[i].mask;
 		switch (func->conf[i].param) {
 		/* 4 parameters */
@@ -573,7 +574,8 @@ static int pcs_pinconf_set(struct pinctrl_dev *pctldev,
 			if (param != func->conf[i].param)
 				continue;
 
-			offset = pin * (pcs->width / BITS_PER_BYTE);
+			/* Use the same offset mapping as pinmux (handles bit-per-mux) */
+			offset = pcs_pin_reg_offset_get(pcs, pin);
 			data = pcs->read(pcs->base + offset);
 			arg = pinconf_to_config_argument(configs[j]);
 			switch (param) {

-- 
2.34.1

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

[Linus Walleij]

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

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

[Billy Tsai]

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

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

[Tony Lindgren]

Hi,

* Billy Tsai <billy_tsai@aspeedtech.com> [260204 06:54]:
> 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.

I agree with what Linus that separate more targeted drivers are better
to avoid the drivers getting complex. With the GENERIC_PIN* helpers doing
targeted drivers should be trivial.

My preference would be to move the bit-per-mux handling out of the
pinctrl-single driver into a separate pinctrl-single-bit type driver.
Seems that can still handle the cases where no hardware specific driver
is needed.

This would simplify pinctrl-single driver quite a bit, and would make
the new driver quite simple too AFAIK.

Regards,

Tony

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

[Billy Tsai]

* Billy Tsai <billy_tsai@aspeedtech.com> [260204 06:54]:
> > 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.

> I agree with what Linus that separate more targeted drivers are better
> to avoid the drivers getting complex. With the GENERIC_PIN* helpers doing
> targeted drivers should be trivial.

> My preference would be to move the bit-per-mux handling out of the
> pinctrl-single driver into a separate pinctrl-single-bit type driver.
> Seems that can still handle the cases where no hardware specific driver
> is needed.

> This would simplify pinctrl-single driver quite a bit, and would make
> the new driver quite simple too AFAIK.

Hi Tony,

Thanks for the clarification.

I understand the preference is to keep pinctrl-single minimal and move
the bit-per-mux handling into a separate, more targeted driver built on
top of the GENERIC_PINMUX/GENERIC_PINCONF helpers, rather than extending
pinctrl-single itself.

Based on that, I’ll look into refactoring this into a
pinctrl-single-bit style driver that covers bit-per-mux / bit-per-pin
layouts generically (including AST2700), while keeping pinctrl-single
focused on the simpler register models.

One additional point I’d like to raise is the handling of pre-reserved
MMIO regions.

On AST2700 systems, the SCU register range containing the pinctrl
registers is commonly reserved by a top-level syscon node or by firmware.
In this setup, devm_request_mem_region() can return -EBUSY even though the
registers are valid and intended to be shared, which currently causes the
driver to fail probing and leaves pinmux unconfigured.

When moving to a separate targeted driver, would the preferred approach
be to treat this condition as a warning and continue probing, or is there
an alternative pattern you’d recommend for handling shared SCU-style
register blocks in pinctrl drivers?

Thanks,
Billy

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

[Linus Walleij]

On Fri, Feb 6, 2026 at 8:24 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:

> I understand the preference is to keep pinctrl-single minimal and move
> the bit-per-mux handling into a separate, more targeted driver built on
> top of the GENERIC_PINMUX/GENERIC_PINCONF helpers, rather than extending
> pinctrl-single itself.
>
> Based on that, I’ll look into refactoring this into a
> pinctrl-single-bit style driver that covers bit-per-mux / bit-per-pin
> layouts generically (including AST2700), while keeping pinctrl-single
> focused on the simpler register models.
>
> One additional point I’d like to raise is the handling of pre-reserved
> MMIO regions.
>
> On AST2700 systems, the SCU register range containing the pinctrl
> registers is commonly reserved by a top-level syscon node or by firmware.
> In this setup, devm_request_mem_region() can return -EBUSY even though the
> registers are valid and intended to be shared, which currently causes the
> driver to fail probing and leaves pinmux unconfigured.
>
> When moving to a separate targeted driver, would the preferred approach
> be to treat this condition as a warning and continue probing, or is there
> an alternative pattern you’d recommend for handling shared SCU-style
> register blocks in pinctrl drivers?

Can't you just base this entire driver on syscon which uses regmap-mmio
to abstract and solve this problem?

The syscon is entirely designed as a singleton owning all registers
and handing them out to subdrivers.

Yours,
Linus Walleij

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

[Billy Tsai]

On Fri, Feb 6, 2026 at 8:24 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:

> > I understand the preference is to keep pinctrl-single minimal and move
> > the bit-per-mux handling into a separate, more targeted driver built on
> > top of the GENERIC_PINMUX/GENERIC_PINCONF helpers, rather than extending
> > pinctrl-single itself.
> >
> > Based on that, I’ll look into refactoring this into a
> > pinctrl-single-bit style driver that covers bit-per-mux / bit-per-pin
> > layouts generically (including AST2700), while keeping pinctrl-single
> > focused on the simpler register models.
> >
> > One additional point I’d like to raise is the handling of pre-reserved
> > MMIO regions.
> >
> > On AST2700 systems, the SCU register range containing the pinctrl
> > registers is commonly reserved by a top-level syscon node or by firmware.
> > In this setup, devm_request_mem_region() can return -EBUSY even though the
> > registers are valid and intended to be shared, which currently causes the
> > driver to fail probing and leaves pinmux unconfigured.
> >
> > When moving to a separate targeted driver, would the preferred approach
> > be to treat this condition as a warning and continue probing, or is there
> > an alternative pattern you’d recommend for handling shared SCU-style
> > register blocks in pinctrl drivers?

> Can't you just base this entire driver on syscon which uses regmap-mmio
> to abstract and solve this problem?

> The syscon is entirely designed as a singleton owning all registers
> and handing them out to subdrivers.

Agreed that syscon/regmap would be ideal. The main issue with
pinctrl-single is that it is fundamentally MMIO-based: it always
requests and ioremaps the register range and performs raw MMIO accesses,
with no regmap integration. Adapting it to act as a syscon consumer would
require a larger architectural rework of the driver.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-single.c?h=v6.19-rc6#n230

Thanks,
Billy

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

[Linus Walleij]

On Fri, Feb 6, 2026 at 12:34 PM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> On Fri, Feb 6, 2026 at 8:24 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
>
> > > I understand the preference is to keep pinctrl-single minimal and move
> > > the bit-per-mux handling into a separate, more targeted driver built on
> > > top of the GENERIC_PINMUX/GENERIC_PINCONF helpers, rather than extending
> > > pinctrl-single itself.
> > >
> > > Based on that, I’ll look into refactoring this into a
> > > pinctrl-single-bit style driver that covers bit-per-mux / bit-per-pin
> > > layouts generically (including AST2700), while keeping pinctrl-single
> > > focused on the simpler register models.
> > >
> > > One additional point I’d like to raise is the handling of pre-reserved
> > > MMIO regions.
> > >
> > > On AST2700 systems, the SCU register range containing the pinctrl
> > > registers is commonly reserved by a top-level syscon node or by firmware.
> > > In this setup, devm_request_mem_region() can return -EBUSY even though the
> > > registers are valid and intended to be shared, which currently causes the
> > > driver to fail probing and leaves pinmux unconfigured.
> > >
> > > When moving to a separate targeted driver, would the preferred approach
> > > be to treat this condition as a warning and continue probing, or is there
> > > an alternative pattern you’d recommend for handling shared SCU-style
> > > register blocks in pinctrl drivers?
>
> > Can't you just base this entire driver on syscon which uses regmap-mmio
> > to abstract and solve this problem?
>
> > The syscon is entirely designed as a singleton owning all registers
> > and handing them out to subdrivers.
>
> Agreed that syscon/regmap would be ideal. The main issue with
> pinctrl-single is that it is fundamentally MMIO-based: it always
> requests and ioremaps the register range and performs raw MMIO accesses,
> with no regmap integration. Adapting it to act as a syscon consumer would
> require a larger architectural rework of the driver.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-single.c?h=v6.19-rc6#n230

These comments were under the assumtion that you do what Tony & I
suggested and create a completely new driver for these use cases.

Sorry if it was unclear.

Yours,
Linus Walleij

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

[Billy Tsai]

> > On Fri, Feb 6, 2026 at 8:24 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> >
> > > > I understand the preference is to keep pinctrl-single minimal and move
> > > > the bit-per-mux handling into a separate, more targeted driver built on
> > > > top of the GENERIC_PINMUX/GENERIC_PINCONF helpers, rather than extending
> > > > pinctrl-single itself.
> > > >
> > > > Based on that, I’ll look into refactoring this into a
> > > > pinctrl-single-bit style driver that covers bit-per-mux / bit-per-pin
> > > > layouts generically (including AST2700), while keeping pinctrl-single
> > > > focused on the simpler register models.
> > > >
> > > > One additional point I’d like to raise is the handling of pre-reserved
> > > > MMIO regions.
> > > >
> > > > On AST2700 systems, the SCU register range containing the pinctrl
> > > > registers is commonly reserved by a top-level syscon node or by firmware.
> > > > In this setup, devm_request_mem_region() can return -EBUSY even though the
> > > > registers are valid and intended to be shared, which currently causes the
> > > > driver to fail probing and leaves pinmux unconfigured.
> > > >
> > > > When moving to a separate targeted driver, would the preferred approach
> > > > be to treat this condition as a warning and continue probing, or is there
> > > > an alternative pattern you’d recommend for handling shared SCU-style
> > > > register blocks in pinctrl drivers?
> >
> > > Can't you just base this entire driver on syscon which uses regmap-mmio
> > > to abstract and solve this problem?
> >
> > > The syscon is entirely designed as a singleton owning all registers
> > > and handing them out to subdrivers.
> >
> > Agreed that syscon/regmap would be ideal. The main issue with
> > pinctrl-single is that it is fundamentally MMIO-based: it always
> > requests and ioremaps the register range and performs raw MMIO accesses,
> > with no regmap integration. Adapting it to act as a syscon consumer would
> > require a larger architectural rework of the driver.
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/pinctrl-single.c?h=v6.19-rc6#n230

> These comments were under the assumtion that you do what Tony & I
> suggested and create a completely new driver for these use cases.

> Sorry if it was unclear.

Hi Linus and Tony,

Understood on writing a new targeted driver.

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? My assumption is that
   pinctrl-single remains unchanged and continues to support existing
   users and bindings, while the new driver offers a simpler and more
   maintainable option for SoCs with bit-per-mux / bit-per-pin hardware
   layouts.
   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.

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?

Thanks,
Billy

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

[Linus Walleij]

On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai <billy_tsai@aspeedtech.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.

Yours,
Linus Walleij

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

[Tony Lindgren]

* Linus Walleij <linusw@kernel.org> [260209 09:51]:
> On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai <billy_tsai@aspeedtech.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!

Thanks,

Tony

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

[Billy Tsai]

> * Linus Walleij <linusw@kernel.org> [260209 09:51]:
> > On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai <billy_tsai@aspeedtech.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

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

[Andrew Jeffery]

Hi Billy,

On Tue, 2026-02-10 at 06:28 +0000, Billy Tsai wrote:
> > * Linus Walleij <linusw@kernel.org> [260209 09:51]:
> > > On Mon, Feb 9, 2026 at 3:25 AM Billy Tsai <billy_tsai@aspeedtech.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.

While how we describe the hardware in the devicetree is important, the
impact on the driver is ultimately some glue code. I think the thing to
prioritise right now is the design, implementation and testing of the
bit-per-mux functionality, less so how we get the driver bound to the
device and retrieve the syscon.

The proposal I made in the message you linked is a bit speculative at
the moment. It needs buy-in from the DT maintainers as it proposes some
rework of what's already in-place. That needs thought, but perhaps it
can come a bit later. For now you could write a proof-of-concept
implementation of the glue code for testing purposes (which we may
replace once we resolve the binding discussion).

Andrew

PS: However, regarding the syscon property itself, it's probably worth
paying attention to the "“syscon” is not a generic property" note in
https://docs.kernel.org/devicetree/bindings/writing-bindings.html#typical-cases-and-caveats