[PATCH v2 0/4] Allwinner A100/A133 Ethernet MAC (EMAC0) Support

[PATCH v2 0/4] Allwinner A100/A133 Ethernet MAC (EMAC0) Support

[Paul Kocialkowski]

This series adds support for the Alwinner A100/A133 Ethernet MAC (EMAC0)
and uses it in the Liontron H-A133L board.

Changes since v1:
- Reverted the emac0 to emac rename;
- Added collected tags.

Paul Kocialkowski (4):
  Revert "pinctrl: sunxi: Fix a100 emac pin function name"
  arm64: dts: allwinner: a100: Add pin definitions for RGMII/RMII
  arm64: dts: allwinner: a100: Add EMAC support
  arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

 .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 35 +++++++++++++++++++
 .../sun50i-a133-liontron-h-a133l.dts          | 19 ++++++++++
 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c   | 32 ++++++++---------
 3 files changed, 70 insertions(+), 16 deletions(-)

-- 
2.49.0

[PATCH v2 1/4] Revert "pinctrl: sunxi: Fix a100 emac pin function name"

[Paul Kocialkowski]

While the A100/A133 chips only expose a single EMAC, the sun50iw10 die
that they share actually has two such controllers.

One specific package, the T509 is reported to expose both ports.

Since we want to keep the pinctrl function names unique accross
packages of the same die to share a single common base dtsi, keep the
emac0 naming in order to allow the introduction of the emac1 function
in the future.

Note that the original commit also breaks the ABI between the driver
and the device-tree. It's however unlikely that anybody would have
complained about that since the a100/a133 port is still very early
and experimental.

Fixes: d4775ba60b55 ("pinctrl: sunxi: Fix a100 emac pin function name")
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 32 ++++++++++-----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
index 95b764ee1c0d..b97de80ae2f3 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
@@ -546,33 +546,33 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD1 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD1 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 0)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD0 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD0 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 1)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SCK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXCTL */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXCTL */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 2)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SDA */
 		  SUNXI_FUNCTION(0x3, "cir0"),		/* OUT */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* CLKIN */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* CLKIN */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 3)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "uart3"),		/* TX */
 		  SUNXI_FUNCTION(0x3, "spi1"),		/* CS */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD1 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD1 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 4)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -580,14 +580,14 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x2, "uart3"),		/* RX */
 		  SUNXI_FUNCTION(0x3, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x4, "ledc"),
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD0 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD0 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 5)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "uart3"),		/* RTS */
 		  SUNXI_FUNCTION(0x3, "spi1"),		/* MOSI */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXCK */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXCK */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 6)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -595,7 +595,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x2, "uart3"),		/* CTS */
 		  SUNXI_FUNCTION(0x3, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x4, "spdif"),		/* OUT */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXCTL */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXCTL */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 7)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -611,7 +611,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x2, "dmic"),		/* DATA0 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
 		  SUNXI_FUNCTION(0x4, "i2s2"),		/* BCLK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* MDC */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* MDC */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -619,7 +619,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x2, "dmic"),		/* DATA1 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
 		  SUNXI_FUNCTION(0x4, "i2s2"),		/* LRCK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* MDIO */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* MDIO */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 10)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -642,33 +642,33 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x3, "i2c3"),		/* SCK */
 		  SUNXI_FUNCTION(0x4, "i2s3"),		/* MCLK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* EPHY */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* EPHY */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 13)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x4, "i2s3"),		/* BCLK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD3 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD3 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 14)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x4, "i2s3"),		/* LRCK */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD2 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD2 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 15)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x3, "i2s3_dout0"),	/* DOUT0 */
 		  SUNXI_FUNCTION(0x4, "i2s3_din1"),	/* DIN1 */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* RXCK */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXCK */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 16)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x3, "i2s3_dout1"),	/* DOUT1 */
 		  SUNXI_FUNCTION(0x4, "i2s3_din0"),	/* DIN0 */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD3 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD3 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 17)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -676,7 +676,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
 		  SUNXI_FUNCTION(0x2, "cir0"),		/* OUT */
 		  SUNXI_FUNCTION(0x3, "i2s3_dout2"),	/* DOUT2 */
 		  SUNXI_FUNCTION(0x4, "i2s3_din2"),	/* DIN2 */
-		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD2 */
+		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD2 */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 18)),
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
-- 
2.49.0

Re: [PATCH v2 1/4] Revert "pinctrl: sunxi: Fix a100 emac pin function name"

[Andre Przywara]

On Mon,  7 Jul 2025 18:51:52 +0200
Paul Kocialkowski <paulk@sys-base.io> wrote:

Hi Paul,

> While the A100/A133 chips only expose a single EMAC, the sun50iw10 die
> that they share actually has two such controllers.
> 
> One specific package, the T509 is reported to expose both ports.
> 
> Since we want to keep the pinctrl function names unique accross
> packages of the same die to share a single common base dtsi, keep the
> emac0 naming in order to allow the introduction of the emac1 function
> in the future.
> 
> Note that the original commit also breaks the ABI between the driver
> and the device-tree. It's however unlikely that anybody would have
> complained about that since the a100/a133 port is still very early
> and experimental.
> 
> Fixes: d4775ba60b55 ("pinctrl: sunxi: Fix a100 emac pin function name")
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>

many thanks for sending this, it looks good to me now. I just wonder if
the original patch can be still backed out, I think it would be still
time before the v6.17 PR?

Good to have an explicit revert anyway, to make this case clear.

Cheers,
Andre

> ---
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 32 ++++++++++-----------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> index 95b764ee1c0d..b97de80ae2f3 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> @@ -546,33 +546,33 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD1 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD1 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 0)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD0 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD0 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 1)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SCK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXCTL */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXCTL */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 2)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SDA */
>  		  SUNXI_FUNCTION(0x3, "cir0"),		/* OUT */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* CLKIN */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* CLKIN */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 3)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "uart3"),		/* TX */
>  		  SUNXI_FUNCTION(0x3, "spi1"),		/* CS */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD1 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD1 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 4)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -580,14 +580,14 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x2, "uart3"),		/* RX */
>  		  SUNXI_FUNCTION(0x3, "spi1"),		/* CLK */
>  		  SUNXI_FUNCTION(0x4, "ledc"),
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD0 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD0 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 5)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "uart3"),		/* RTS */
>  		  SUNXI_FUNCTION(0x3, "spi1"),		/* MOSI */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXCK */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXCK */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 6)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -595,7 +595,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x2, "uart3"),		/* CTS */
>  		  SUNXI_FUNCTION(0x3, "spi1"),		/* MISO */
>  		  SUNXI_FUNCTION(0x4, "spdif"),		/* OUT */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXCTL */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXCTL */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 7)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -611,7 +611,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x2, "dmic"),		/* DATA0 */
>  		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
>  		  SUNXI_FUNCTION(0x4, "i2s2"),		/* BCLK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* MDC */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* MDC */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -619,7 +619,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x2, "dmic"),		/* DATA1 */
>  		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
>  		  SUNXI_FUNCTION(0x4, "i2s2"),		/* LRCK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* MDIO */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* MDIO */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 10)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -642,33 +642,33 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x3, "i2c3"),		/* SCK */
>  		  SUNXI_FUNCTION(0x4, "i2s3"),		/* MCLK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* EPHY */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* EPHY */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 13)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 14),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x4, "i2s3"),		/* BCLK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD3 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD3 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 14)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 15),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x4, "i2s3"),		/* LRCK */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXD2 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXD2 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 15)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 16),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x3, "i2s3_dout0"),	/* DOUT0 */
>  		  SUNXI_FUNCTION(0x4, "i2s3_din1"),	/* DIN1 */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* RXCK */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* RXCK */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 16)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 17),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x3, "i2s3_dout1"),	/* DOUT1 */
>  		  SUNXI_FUNCTION(0x4, "i2s3_din0"),	/* DIN0 */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD3 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD3 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 17)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 18),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -676,7 +676,7 @@ static const struct sunxi_desc_pin a100_pins[] = {
>  		  SUNXI_FUNCTION(0x2, "cir0"),		/* OUT */
>  		  SUNXI_FUNCTION(0x3, "i2s3_dout2"),	/* DOUT2 */
>  		  SUNXI_FUNCTION(0x4, "i2s3_din2"),	/* DIN2 */
> -		  SUNXI_FUNCTION(0x5, "emac"),		/* TXD2 */
> +		  SUNXI_FUNCTION(0x5, "emac0"),		/* TXD2 */
>  		  SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 18)),
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),

Re: [PATCH v2 1/4] Revert "pinctrl: sunxi: Fix a100 emac pin function name"

[Linus Walleij]

On Tue, Jul 8, 2025 at 1:35 AM Andre Przywara <andre.przywara@arm.com> wrote:

> > Fixes: d4775ba60b55 ("pinctrl: sunxi: Fix a100 emac pin function name")
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
>
> many thanks for sending this, it looks good to me now. I just wonder if
> the original patch can be still backed out, I think it would be still
> time before the v6.17 PR?

Yeah I just dropped the patch :)

Yours,
Linus Walleij

[PATCH v2 2/4] arm64: dts: allwinner: a100: Add pin definitions for RGMII/RMII

[Paul Kocialkowski]

The Allwinner A100/A133 supports both RGMII and RMII for its Ethernet
MAC (EMAC) controller. Add corresponding pin definitions.

Note that the sun50iw10 die actually includes two ethernet controllers,
the second of which is rarely exposed to pins. Call the first controller
"emac0" to distinguish it from the second that may be added later.

Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index bd366389b238..7d5be0975371 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -236,6 +236,21 @@ mmc2_pins: mmc2-pins {
 				bias-pull-up;
 			};
 
+			rgmii0_pins: rgmii0-pins {
+				pins = "PH0", "PH1", "PH2", "PH3", "PH4",
+				       "PH5", "PH6", "PH7", "PH9", "PH10",
+				       "PH14", "PH15", "PH16", "PH17", "PH18";
+				function = "emac0";
+				drive-strength = <40>;
+			};
+
+			rmii0_pins: rmii0-pins {
+				pins = "PH0", "PH1", "PH2", "PH3", "PH4",
+				       "PH5", "PH6", "PH7", "PH9", "PH10";
+				function = "emac0";
+				drive-strength = <40>;
+			};
+
 			uart0_pb_pins: uart0-pb-pins {
 				pins = "PB9", "PB10";
 				function = "uart0";
-- 
2.49.0

[PATCH v2 3/4] arm64: dts: allwinner: a100: Add EMAC support

[Paul Kocialkowski]

The Allwinner A100/A133 Ethernet MAC (EMAC) is compatible with the A64
one and needs access to the syscon register for control of the
top-level integration of the unit.

Note that there are two such controllers on the sun50iw10 die, which are
the same unit with a different top-level syscon register offset.

Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
---
 .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index 7d5be0975371..bb5f9e4f3d42 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -420,6 +420,26 @@ i2c3: i2c@5002c00 {
 			#size-cells = <0>;
 		};
 
+		emac0: ethernet@5020000 {
+			compatible = "allwinner,sun50i-a100-emac",
+				     "allwinner,sun50i-a64-emac";
+			reg = <0x5020000 0x10000>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			clocks = <&ccu CLK_BUS_EMAC>;
+			clock-names = "stmmaceth";
+			resets = <&ccu RST_BUS_EMAC>;
+			reset-names = "stmmaceth";
+			syscon = <&syscon>;
+			status = "disabled";
+
+			mdio0: mdio {
+				compatible = "snps,dwmac-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+
 		ths: thermal-sensor@5070400 {
 			compatible = "allwinner,sun50i-a100-ths";
 			reg = <0x05070400 0x100>;
-- 
2.49.0

[PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Paul Kocialkowski]

The Liontron H-A133L board features an Ethernet controller with a
JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.

Note that the reset pin must be handled as a bus-wide reset GPIO in
order to let the MDIO core properly reset it before trying to read
its identification registers. There's no other device on the MDIO bus.

The datasheet of the PHY mentions that the reset signal must be held
for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
be on the safe side without wasting too much time during boot.

Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
 .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
index fe77178d3e33..90a50910f07b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
@@ -65,6 +65,25 @@ &ehci1 {
 	status = "okay";
 };
 
+&emac0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&rmii0_pins>;
+	phy-handle = <&rmii_phy>;
+	phy-mode = "rmii";
+	status = "okay";
+};
+
+&mdio0 {
+	reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
+	reset-delay-us = <2000>;
+	reset-post-delay-us = <2000>;
+
+	rmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &mmc0 {
 	vmmc-supply = <&reg_dcdc1>;
 	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
-- 
2.49.0

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Andre Przywara]

On Mon,  7 Jul 2025 18:51:55 +0200
Paul Kocialkowski <paulk@sys-base.io> wrote:

Hi Paul,

> The Liontron H-A133L board features an Ethernet controller with a
> JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> 
> Note that the reset pin must be handled as a bus-wide reset GPIO in
> order to let the MDIO core properly reset it before trying to read
> its identification registers. There's no other device on the MDIO bus.

putting the PHY reset GPIO into the MDIO node is a clever solution, I
was struggling with putting it either in the MAC or PHY node, though
conceptually it would still belong in the latter, I think. But this
might be a more generic problem: for most other devices we activate
reset and clock gates *before* trying to access them, though this might
be historically different for Ethernet PHYs.
 
> The datasheet of the PHY mentions that the reset signal must be held
> for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> be on the safe side without wasting too much time during boot.
> 
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>

Despite the above, this looks fine, and works for me:

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre

> ---
>  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> index fe77178d3e33..90a50910f07b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> @@ -65,6 +65,25 @@ &ehci1 {
>  	status = "okay";
>  };
>  
> +&emac0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rmii0_pins>;
> +	phy-handle = <&rmii_phy>;
> +	phy-mode = "rmii";
> +	status = "okay";
> +};
> +
> +&mdio0 {
> +	reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> +	reset-delay-us = <2000>;
> +	reset-post-delay-us = <2000>;
> +
> +	rmii_phy: ethernet-phy@1 {
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};
> +};
> +
>  &mmc0 {
>  	vmmc-supply = <&reg_dcdc1>;
>  	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Andre Przywara]

On Tue, 8 Jul 2025 00:34:25 +0100
Andre Przywara <andre.przywara@arm.com> wrote:

Hi Paul,

forgot to mention: can you please add an ethernet0 alias, to make
U-Boot generate a MAC address, from the SID?

Cheers,
Andre

> On Mon,  7 Jul 2025 18:51:55 +0200
> Paul Kocialkowski <paulk@sys-base.io> wrote:
> 
> Hi Paul,
> 
> > The Liontron H-A133L board features an Ethernet controller with a
> > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> > 
> > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > order to let the MDIO core properly reset it before trying to read
> > its identification registers. There's no other device on the MDIO bus.  
> 
> putting the PHY reset GPIO into the MDIO node is a clever solution, I
> was struggling with putting it either in the MAC or PHY node, though
> conceptually it would still belong in the latter, I think. But this
> might be a more generic problem: for most other devices we activate
> reset and clock gates *before* trying to access them, though this might
> be historically different for Ethernet PHYs.
>  
> > The datasheet of the PHY mentions that the reset signal must be held
> > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > be on the safe side without wasting too much time during boot.
> > 
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>  
> 
> Despite the above, this looks fine, and works for me:
> 
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Andre Przywara <andre.przywara@arm.com>
> 
> Cheers,
> Andre
> 
> > ---
> >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > index fe77178d3e33..90a50910f07b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > @@ -65,6 +65,25 @@ &ehci1 {
> >  	status = "okay";
> >  };
> >  
> > +&emac0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&rmii0_pins>;
> > +	phy-handle = <&rmii_phy>;
> > +	phy-mode = "rmii";
> > +	status = "okay";
> > +};
> > +
> > +&mdio0 {
> > +	reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > +	reset-delay-us = <2000>;
> > +	reset-post-delay-us = <2000>;
> > +
> > +	rmii_phy: ethernet-phy@1 {
> > +		compatible = "ethernet-phy-ieee802.3-c22";
> > +		reg = <1>;
> > +	};
> > +};
> > +
> >  &mmc0 {
> >  	vmmc-supply = <&reg_dcdc1>;
> >  	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */  
> 

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

Hi Andre,

Le Tue 08 Jul 25, 00:48, Andre Przywara a écrit :
> On Tue, 8 Jul 2025 00:34:25 +0100
> Andre Przywara <andre.przywara@arm.com> wrote:
> 
> Hi Paul,
> 
> forgot to mention: can you please add an ethernet0 alias, to make
> U-Boot generate a MAC address, from the SID?

Ah yes, sorry I forgot to do that. Will respin the series then.

Cheers,

Paul

> Cheers,
> Andre
> 
> > On Mon,  7 Jul 2025 18:51:55 +0200
> > Paul Kocialkowski <paulk@sys-base.io> wrote:
> > 
> > Hi Paul,
> > 
> > > The Liontron H-A133L board features an Ethernet controller with a
> > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> > > 
> > > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > > order to let the MDIO core properly reset it before trying to read
> > > its identification registers. There's no other device on the MDIO bus.  
> > 
> > putting the PHY reset GPIO into the MDIO node is a clever solution, I
> > was struggling with putting it either in the MAC or PHY node, though
> > conceptually it would still belong in the latter, I think. But this
> > might be a more generic problem: for most other devices we activate
> > reset and clock gates *before* trying to access them, though this might
> > be historically different for Ethernet PHYs.
> >  
> > > The datasheet of the PHY mentions that the reset signal must be held
> > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > > be on the safe side without wasting too much time during boot.
> > > 
> > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>  
> > 
> > Despite the above, this looks fine, and works for me:
> > 
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > 
> > Cheers,
> > Andre
> > 
> > > ---
> > >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > index fe77178d3e33..90a50910f07b 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > @@ -65,6 +65,25 @@ &ehci1 {
> > >  	status = "okay";
> > >  };
> > >  
> > > +&emac0 {
> > > +	pinctrl-names = "default";
> > > +	pinctrl-0 = <&rmii0_pins>;
> > > +	phy-handle = <&rmii_phy>;
> > > +	phy-mode = "rmii";
> > > +	status = "okay";
> > > +};
> > > +
> > > +&mdio0 {
> > > +	reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > > +	reset-delay-us = <2000>;
> > > +	reset-post-delay-us = <2000>;
> > > +
> > > +	rmii_phy: ethernet-phy@1 {
> > > +		compatible = "ethernet-phy-ieee802.3-c22";
> > > +		reg = <1>;
> > > +	};
> > > +};
> > > +
> > >  &mmc0 {
> > >  	vmmc-supply = <&reg_dcdc1>;
> > >  	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */  
> > 
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Chen-Yu Tsai]

On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Mon,  7 Jul 2025 18:51:55 +0200
> Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Paul,
>
> > The Liontron H-A133L board features an Ethernet controller with a
> > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> >
> > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > order to let the MDIO core properly reset it before trying to read
> > its identification registers. There's no other device on the MDIO bus.
>
> putting the PHY reset GPIO into the MDIO node is a clever solution, I
> was struggling with putting it either in the MAC or PHY node, though
> conceptually it would still belong in the latter, I think. But this
> might be a more generic problem: for most other devices we activate
> reset and clock gates *before* trying to access them, though this might
> be historically different for Ethernet PHYs.

The phylib core has code to deal with reset GPIOs listed under the PHY node.
It might be worth checking why that doesn't work.

OOTH, there's no code to deal with regulator supplies for PHYs.

ChenYu

> > The datasheet of the PHY mentions that the reset signal must be held
> > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > be on the safe side without wasting too much time during boot.
> >
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
>
> Despite the above, this looks fine, and works for me:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Andre Przywara <andre.przywara@arm.com>
>
> Cheers,
> Andre
>
> > ---
> >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > index fe77178d3e33..90a50910f07b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > @@ -65,6 +65,25 @@ &ehci1 {
> >       status = "okay";
> >  };
> >
> > +&emac0 {
> > +     pinctrl-names = "default";
> > +     pinctrl-0 = <&rmii0_pins>;
> > +     phy-handle = <&rmii_phy>;
> > +     phy-mode = "rmii";
> > +     status = "okay";
> > +};
> > +
> > +&mdio0 {
> > +     reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > +     reset-delay-us = <2000>;
> > +     reset-post-delay-us = <2000>;
> > +
> > +     rmii_phy: ethernet-phy@1 {
> > +             compatible = "ethernet-phy-ieee802.3-c22";
> > +             reg = <1>;
> > +     };
> > +};
> > +
> >  &mmc0 {
> >       vmmc-supply = <&reg_dcdc1>;
> >       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>
>

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 3632 bytes --]

Hi,

Le Tue 08 Jul 25, 16:18, Chen-Yu Tsai a écrit :
> On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Mon,  7 Jul 2025 18:51:55 +0200
> > Paul Kocialkowski <paulk@sys-base.io> wrote:
> >
> > Hi Paul,
> >
> > > The Liontron H-A133L board features an Ethernet controller with a
> > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> > >
> > > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > > order to let the MDIO core properly reset it before trying to read
> > > its identification registers. There's no other device on the MDIO bus.
> >
> > putting the PHY reset GPIO into the MDIO node is a clever solution, I
> > was struggling with putting it either in the MAC or PHY node, though
> > conceptually it would still belong in the latter, I think. But this
> > might be a more generic problem: for most other devices we activate
> > reset and clock gates *before* trying to access them, though this might
> > be historically different for Ethernet PHYs.
> 
> The phylib core has code to deal with reset GPIOs listed under the PHY node.
> It might be worth checking why that doesn't work.

While this code does exist, it's too early to be called when the mdio bus is
trying to probe the phy. I was also surprised the existing reset gpio support
in the phylib core didn't take effect (that's how I tried to implement it first)
only to find that the code was never called. It's only called once the phy was
probed and registered.

Cheers,

Paul

> OOTH, there's no code to deal with regulator supplies for PHYs.
> 
> ChenYu
> 
> > > The datasheet of the PHY mentions that the reset signal must be held
> > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > > be on the safe side without wasting too much time during boot.
> > >
> > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> >
> > Despite the above, this looks fine, and works for me:
> >
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Andre Przywara <andre.przywara@arm.com>
> >
> > Cheers,
> > Andre
> >
> > > ---
> > >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > index fe77178d3e33..90a50910f07b 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > @@ -65,6 +65,25 @@ &ehci1 {
> > >       status = "okay";
> > >  };
> > >
> > > +&emac0 {
> > > +     pinctrl-names = "default";
> > > +     pinctrl-0 = <&rmii0_pins>;
> > > +     phy-handle = <&rmii_phy>;
> > > +     phy-mode = "rmii";
> > > +     status = "okay";
> > > +};
> > > +
> > > +&mdio0 {
> > > +     reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > > +     reset-delay-us = <2000>;
> > > +     reset-post-delay-us = <2000>;
> > > +
> > > +     rmii_phy: ethernet-phy@1 {
> > > +             compatible = "ethernet-phy-ieee802.3-c22";
> > > +             reg = <1>;
> > > +     };
> > > +};
> > > +
> > >  &mmc0 {
> > >       vmmc-supply = <&reg_dcdc1>;
> > >       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >
> >

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Chen-Yu Tsai]

On Tue, Jul 8, 2025 at 9:22 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi,
>
> Le Tue 08 Jul 25, 16:18, Chen-Yu Tsai a écrit :
> > On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote:
> > >
> > > On Mon,  7 Jul 2025 18:51:55 +0200
> > > Paul Kocialkowski <paulk@sys-base.io> wrote:
> > >
> > > Hi Paul,
> > >
> > > > The Liontron H-A133L board features an Ethernet controller with a
> > > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> > > >
> > > > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > > > order to let the MDIO core properly reset it before trying to read
> > > > its identification registers. There's no other device on the MDIO bus.
> > >
> > > putting the PHY reset GPIO into the MDIO node is a clever solution, I
> > > was struggling with putting it either in the MAC or PHY node, though
> > > conceptually it would still belong in the latter, I think. But this
> > > might be a more generic problem: for most other devices we activate
> > > reset and clock gates *before* trying to access them, though this might
> > > be historically different for Ethernet PHYs.
> >
> > The phylib core has code to deal with reset GPIOs listed under the PHY node.
> > It might be worth checking why that doesn't work.
>
> While this code does exist, it's too early to be called when the mdio bus is
> trying to probe the phy. I was also surprised the existing reset gpio support
> in the phylib core didn't take effect (that's how I tried to implement it first)
> only to find that the code was never called. It's only called once the phy was
> probed and registered.

OK, that's definitely weird. The code looked like it just walked the DT
and registered PHY devices, upon which the GPIO lines would be found and
toggled.

ChenYu

> Cheers,
>
> Paul
>
> > OOTH, there's no code to deal with regulator supplies for PHYs.
> >
> > ChenYu
> >
> > > > The datasheet of the PHY mentions that the reset signal must be held
> > > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > > > be on the safe side without wasting too much time during boot.
> > > >
> > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> > >
> > > Despite the above, this looks fine, and works for me:
> > >
> > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > > Tested-by: Andre Przywara <andre.przywara@arm.com>
> > >
> > > Cheers,
> > > Andre
> > >
> > > > ---
> > > >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> > > >  1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > > index fe77178d3e33..90a50910f07b 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > > > @@ -65,6 +65,25 @@ &ehci1 {
> > > >       status = "okay";
> > > >  };
> > > >
> > > > +&emac0 {
> > > > +     pinctrl-names = "default";
> > > > +     pinctrl-0 = <&rmii0_pins>;
> > > > +     phy-handle = <&rmii_phy>;
> > > > +     phy-mode = "rmii";
> > > > +     status = "okay";
> > > > +};
> > > > +
> > > > +&mdio0 {
> > > > +     reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > > > +     reset-delay-us = <2000>;
> > > > +     reset-post-delay-us = <2000>;
> > > > +
> > > > +     rmii_phy: ethernet-phy@1 {
> > > > +             compatible = "ethernet-phy-ieee802.3-c22";
> > > > +             reg = <1>;
> > > > +     };
> > > > +};
> > > > +
> > > >  &mmc0 {
> > > >       vmmc-supply = <&reg_dcdc1>;
> > > >       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > >
> > >
>
> --
> Paul Kocialkowski,
>
> Independent contractor - sys-base - https://www.sys-base.io/
> Free software developer - https://www.paulk.fr/
>
> Expert in multimedia, graphics and embedded hardware support with Linux.

Re: [PATCH v2 4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

Hi Andre,

Le Tue 08 Jul 25, 00:34, Andre Przywara a écrit :
> On Mon,  7 Jul 2025 18:51:55 +0200
> Paul Kocialkowski <paulk@sys-base.io> wrote:
> 
> Hi Paul,
> 
> > The Liontron H-A133L board features an Ethernet controller with a
> > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
> > 
> > Note that the reset pin must be handled as a bus-wide reset GPIO in
> > order to let the MDIO core properly reset it before trying to read
> > its identification registers. There's no other device on the MDIO bus.
> 
> putting the PHY reset GPIO into the MDIO node is a clever solution, I
> was struggling with putting it either in the MAC or PHY node, though
> conceptually it would still belong in the latter, I think. But this
> might be a more generic problem: for most other devices we activate
> reset and clock gates *before* trying to access them, though this might
> be historically different for Ethernet PHYs.

Yes this feels a bit unusual. Unfortunately the mdio bus performs probing on
the PHYs before registering them as devices, which gives us no hope of
running driver-specific code to power the PHY up.

So the only device we can hold on to is the mdio bus. I think there was an
initial design assumption that 1 mdio bus == 1 PHY device

> > The datasheet of the PHY mentions that the reset signal must be held
> > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
> > be on the safe side without wasting too much time during boot.
> > 
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> 
> Despite the above, this looks fine, and works for me:
> 
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Andre Przywara <andre.przywara@arm.com>

Thanks for the review and test!

Paul

> Cheers,
> Andre
> 
> > ---
> >  .../sun50i-a133-liontron-h-a133l.dts          | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > index fe77178d3e33..90a50910f07b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
> > @@ -65,6 +65,25 @@ &ehci1 {
> >  	status = "okay";
> >  };
> >  
> > +&emac0 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&rmii0_pins>;
> > +	phy-handle = <&rmii_phy>;
> > +	phy-mode = "rmii";
> > +	status = "okay";
> > +};
> > +
> > +&mdio0 {
> > +	reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
> > +	reset-delay-us = <2000>;
> > +	reset-post-delay-us = <2000>;
> > +
> > +	rmii_phy: ethernet-phy@1 {
> > +		compatible = "ethernet-phy-ieee802.3-c22";
> > +		reg = <1>;
> > +	};
> > +};
> > +
> >  &mmc0 {
> >  	vmmc-supply = <&reg_dcdc1>;
> >  	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> 

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: (subset) [PATCH v2 0/4] Allwinner A100/A133 Ethernet MAC (EMAC0) Support

[Chen-Yu Tsai]

On Mon, 07 Jul 2025 18:51:51 +0200, Paul Kocialkowski wrote:
> This series adds support for the Alwinner A100/A133 Ethernet MAC (EMAC0)
> and uses it in the Liontron H-A133L board.
> 
> Changes since v1:
> - Reverted the emac0 to emac rename;
> - Added collected tags.
> 
> [...]

Applied to sunxi/dt-for-6.17 in local tree, thanks!

[2/4] arm64: dts: allwinner: a100: Add pin definitions for RGMII/RMII
      commit: 28e4499a9ad68129d41db10b7481c61738fdb3d1
[3/4] arm64: dts: allwinner: a100: Add EMAC support
      commit: 4e3be5629f1f6de30d3fbcdc357e7da948ccf698
[4/4] arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet support
      commit: 8f128f357dfe5907a6f3432ffb1f444e93f1fbf2

Best regards,
-- 
Chen-Yu Tsai <wens@csie.org>