[PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[Andre Przywara]

The Allwinner A523 uses the same GPIO voltage "withstand" programming
(setting the input level voltage thresholds) as the previous SoCs, but
for some odd reason inverts the encoding of 1.8V vs. 3.3V.

Add a new bias voltage type to note this difference, and select it for
the A523. At the same time also use the newer "CTL" version, which in
addition allows to turn off the withstand programming for I/O voltages
other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for
Ethernet PHYs). The A523 has that enable register, but didn't use it
so far.

This fixes eMMC and reportedly Ethernet operation on some A523 boards.

Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 2 +-
 drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c   | 2 +-
 drivers/pinctrl/sunxi/pinctrl-sunxi.c         | 6 ++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.h         | 2 ++
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
index dfdcfa740ecc9..cffc1e53eef14 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
@@ -26,7 +26,7 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
 static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
 	.irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
 	.irq_bank_map = a523_r_irq_bank_map,
-	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
+	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 	.pin_base = PL_BASE,
 };
 
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
index 801f62abc93df..001bd42afa3ef 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
@@ -26,7 +26,7 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
 static struct sunxi_pinctrl_desc a523_pinctrl_data = {
 	.irq_banks = ARRAY_SIZE(a523_irq_bank_map),
 	.irq_bank_map = a523_irq_bank_map,
-	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
+	.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 };
 
 static int a523_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index cabcb8b6f38e5..634d9f1f23947 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -718,6 +718,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 {
 	unsigned short bank;
 	unsigned long flags;
+	bool inverted = false;
 	u32 val, reg;
 	int uV;
 
@@ -757,6 +758,9 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 		writel(reg | val, pctl->membase +
 		       sunxi_grp_config_reg(pctl, pin));
 		return 0;
+	case BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV:
+		inverted = true;
+		fallthrough;
 	case BIAS_VOLTAGE_PIO_POW_MODE_CTL:
 		val = uV > 1800000 && uV <= 2500000 ? BIT(bank) : 0;
 
@@ -771,6 +775,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
 		fallthrough;
 	case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
 		val = uV <= 1800000 ? 1 : 0;
+		if (inverted)
+			val = !val;
 
 		raw_spin_lock_irqsave(&pctl->lock, flags);
 		reg = readl(pctl->membase + pctl->pow_mod_sel_offset);
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index d0936a32123ba..2c8648c3301b6 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -128,8 +128,10 @@ enum sunxi_desc_bias_voltage {
 	 * Bias voltage is set through PIO_POW_MOD_SEL_REG
 	 * and PIO_POW_MOD_CTL_REG register, as seen on
 	 * A100 and D1 SoC, for example.
+	 * Some SoCs invert the encoding for 1.8V vs. 3.3V.
 	 */
 	BIAS_VOLTAGE_PIO_POW_MODE_CTL,
+	BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
 };
 
 struct sunxi_desc_function {
-- 
2.46.4

Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[Per Larsson]

On Wed, 22 Jul 2026 00:39:56 +0200
Andre Przywara <andre.przywara@arm.com> wrote:

> The Allwinner A523 uses the same GPIO voltage "withstand" programming
> (setting the input level voltage thresholds) as the previous SoCs, but
> for some odd reason inverts the encoding of 1.8V vs. 3.3V.
> 
> Add a new bias voltage type to note this difference, and select it for
> the A523. At the same time also use the newer "CTL" version, which in
> addition allows to turn off the withstand programming for I/O voltages
> other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used
> for Ethernet PHYs). The A523 has that enable register, but didn't use
> it so far.
> 
> This fixes eMMC and reportedly Ethernet operation on some A523 boards.
> 
> Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner
> A523") Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---

I'd say this looks like the correct fix. With this (and removing
the incorrect voltage bump "fix") the eMMC on my X96QPro+ works.
Not seeing any regressions, so

Tested-by: Per Larsson <per@palvencia.se>

Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[Juan Manuel López Carrillo]

Hi Andre,

Tested-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>

I hit this exact bug on the Orange Pi 4A (T527) from the Ethernet side, so this
confirms the "reportedly Ethernet" with a concrete hardware data point.

Without the fix, GMAC1 (RGMII, YT8531 PHY) is RX-dead: the link comes up at
1Gbps but rx_packets stays 0, so DHCP never completes and the board is
unreachable. The PJ bank rail is 1.8V, but POW_MOD_SEL was left in 3.3V mode, so
the RGMII input thresholds were wrong and the MAC never saw RXC/RXD.

With your patch applied, RX comes back: the board gets a DHCP lease, and a 500 MB
transfer lands with ~365k rx_packets and rx_crc_errors = 0. So the CTL_INV
variant fixes it the right way, at the driver level.

For transparency on what I actually tested: I applied it on top of current
mainline (torvalds 248951ddc14d, v7.2-rc4 + a few). It didn't apply cleanly there
— it looks based on a newer pinctrl-sunxi tree — so I rebased one hunk (the
BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV case in sunxi_pinctrl_set_io_bias_cfg()) onto
that tree; the change itself is unchanged.

FWIW I'd independently reverse-engineered the same inverted encoding (bit=1 ->
3.3V mode on the A523, vs earlier SoCs; the BSP calls it "power_mode_reverse"),
so this matches what I saw on hardware, and I'm glad it's handled generically now
instead of my board-specific DT hack.

One note from poking at this, in case it's useful for edge cases: on this board a
few banks behave specially — PF is the SD UHS 1.8/3.3V switch (best left alone),
and PB/PH take their voltage from VCCIO rather than a per-bank bit. Happy to test
those paths on hardware if useful.

Thanks,
Juan Manuel

Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[Chen-Yu Tsai]

On Wed, Jul 22, 2026 at 6:43 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> The Allwinner A523 uses the same GPIO voltage "withstand" programming
> (setting the input level voltage thresholds) as the previous SoCs, but
> for some odd reason inverts the encoding of 1.8V vs. 3.3V.
>
> Add a new bias voltage type to note this difference, and select it for
> the A523. At the same time also use the newer "CTL" version, which in
> addition allows to turn off the withstand programming for I/O voltages
> other than exact 1.8V or 3.3V (for instance for 2.5V sometimes used for
> Ethernet PHYs). The A523 has that enable register, but didn't use it
> so far.
>
> This fixes eMMC and reportedly Ethernet operation on some A523 boards.
>
> Fixes: 648be4cd9517 ("pinctrl: sunxi: Add support for the Allwinner A523")
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>


Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Tested-by: Chen-Yu Tsai <wens@kernel.org> # Fixes eMMC on Orange Pi 4A

> ---
>  drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c   | 2 +-
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c         | 6 ++++++
>  drivers/pinctrl/sunxi/pinctrl-sunxi.h         | 2 ++
>  4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> index dfdcfa740ecc9..cffc1e53eef14 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> @@ -26,7 +26,7 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
>  static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
>         .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
>         .irq_bank_map = a523_r_irq_bank_map,
> -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>         .pin_base = PL_BASE,
>  };
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> index 801f62abc93df..001bd42afa3ef 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> @@ -26,7 +26,7 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
>  static struct sunxi_pinctrl_desc a523_pinctrl_data = {
>         .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
>         .irq_bank_map = a523_irq_bank_map,
> -       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>  };
>
>  static int a523_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index cabcb8b6f38e5..634d9f1f23947 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -718,6 +718,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>  {
>         unsigned short bank;
>         unsigned long flags;
> +       bool inverted = false;
>         u32 val, reg;
>         int uV;
>
> @@ -757,6 +758,9 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>                 writel(reg | val, pctl->membase +
>                        sunxi_grp_config_reg(pctl, pin));
>                 return 0;
> +       case BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV:
> +               inverted = true;
> +               fallthrough;
>         case BIAS_VOLTAGE_PIO_POW_MODE_CTL:
>                 val = uV > 1800000 && uV <= 2500000 ? BIT(bank) : 0;
>
> @@ -771,6 +775,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct sunxi_pinctrl *pctl,
>                 fallthrough;
>         case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
>                 val = uV <= 1800000 ? 1 : 0;
> +               if (inverted)
> +                       val = !val;
>
>                 raw_spin_lock_irqsave(&pctl->lock, flags);
>                 reg = readl(pctl->membase + pctl->pow_mod_sel_offset);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index d0936a32123ba..2c8648c3301b6 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -128,8 +128,10 @@ enum sunxi_desc_bias_voltage {
>          * Bias voltage is set through PIO_POW_MOD_SEL_REG
>          * and PIO_POW_MOD_CTL_REG register, as seen on
>          * A100 and D1 SoC, for example.
> +        * Some SoCs invert the encoding for 1.8V vs. 3.3V.
>          */
>         BIAS_VOLTAGE_PIO_POW_MODE_CTL,
> +       BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV,
>  };
>
>  struct sunxi_desc_function {
> --
> 2.46.4
>

Re: [PATCH] pinctrl: sunxi: A523: fix voltage withstand encoding

[Andre Przywara]

On Wed, 22 Jul 2026 19:23:56 +0200
Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com> wrote:

Hi Juan,

> Hi Andre,
> 
> Tested-by: Juan Manuel Lopez Carrillo <juanmanuellopezcarrillo@gmail.com>
> 
> I hit this exact bug on the Orange Pi 4A (T527) from the Ethernet side, so this
> confirms the "reportedly Ethernet" with a concrete hardware data point.

Thanks, this odd patch of yours (poking POW_MOD_SEL in
pinctrl-sun55i-a523.c) actually made me connect the dots: I looked at
that patch last week, more randomly and out of curiosity, but dismissed
it initially. Then Sashiko commented on my "overvolting" patch pointing
out it changes the "withstand" programming, which reminded me of that
"reversed bits" situation, and I could confirm this with the manual and
an experiment.

> Without the fix, GMAC1 (RGMII, YT8531 PHY) is RX-dead: the link comes up at
> 1Gbps but rx_packets stays 0, so DHCP never completes and the board is
> unreachable. The PJ bank rail is 1.8V, but POW_MOD_SEL was left in 3.3V mode, so
> the RGMII input thresholds were wrong and the MAC never saw RXC/RXD.
> 
> With your patch applied, RX comes back: the board gets a DHCP lease, and a 500 MB
> transfer lands with ~365k rx_packets and rx_crc_errors = 0. So the CTL_INV
> variant fixes it the right way, at the driver level.

Great to hear that, and thanks for testing! There is more to enabling
Ethernet on the box, though, right? The EMAC25M pin needs to be
configured correctly - not even sure that works cleanly with mainline?
And what are the delay values that work for you?
The BSP install on my box is dead, so I cannot poke around there easily.
 
> For transparency on what I actually tested: I applied it on top of current
> mainline (torvalds 248951ddc14d, v7.2-rc4 + a few). It didn't apply cleanly there

Ah yeah, sorry, just saw that I made it in top of my WIP A733 pinctrl
series. I should apply rather cleanly to v7.2-rc1, no?

> — it looks based on a newer pinctrl-sunxi tree — so I rebased one hunk (the
> BIAS_VOLTAGE_PIO_POW_MODE_CTL_INV case in sunxi_pinctrl_set_io_bias_cfg()) onto
> that tree; the change itself is unchanged.
> 
> FWIW I'd independently reverse-engineered the same inverted encoding (bit=1 ->
> 3.3V mode on the A523, vs earlier SoCs; the BSP calls it "power_mode_reverse"),
> so this matches what I saw on hardware, and I'm glad it's handled generically now
> instead of my board-specific DT hack.
> 
> One note from poking at this, in case it's useful for edge cases: on this board a
> few banks behave specially — PF is the SD UHS 1.8/3.3V switch (best left alone),
> and PB/PH take their voltage from VCCIO rather than a per-bank bit. Happy to test

But that is true for all Allwinner SoCs, basically: some ports are
powered by the same VCCIO power pin (typically at 3.3V), and there is
no per-bank supply pin. Look at the data sheet (not user manual), that
mentions that. Also we have a comment to that effect in the DT.

Cheers,
Andre

> those paths on hardware if useful.
> 
> Thanks,
> Juan Manuel
>