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

On Mon, Aug 3, 2026 at 11:51 PM Chen-Yu Tsai <[email protected]> wrote:
>
> On Mon, Aug 3, 2026 at 11:37 PM Juan Manuel López Carrillo
> <[email protected]> wrote:
> >
> > Hi Andre, Chen-Yu,
> >
> > > So can you please double check this?
> >
> > Checked on my Orange Pi 4A (T527, GMAC1, Motorcomm YT8531 PHY). You are right:
> > PJ10 is not needed on this board.
> >
> > PJ10 function 5 is RGMII1-EPHY-25M, "25 MHz Output for GMAC PHY" in the A523
> > manual v1.4. The RGMII1 bus itself is the other 15 pins (PJ0-PJ9, PJ11-PJ15),
> > which mainline already has. My claim came from a stale comment in my tree, from
> > when I was chasing the dead RX. It is gone now and my rgmii1 group matches
> > sunxi/for-next. The Tested-by I sent on 22 July was already measured on plain
> > mainline without PJ10, so what revived RX here was your withstand fix alone.
> >
> > > Those settings differ from what's in mainline. What are the results with
> > > those delays?
> >
> > Measured on the same board, DTB-only changes, TCP for 10 s per direction:
> >
> >   A  mine (rgmii-rxid, MAC tx 100 / rx 0, PHY rx 1900 ps)
> >         TX 0.938-0.940   RX 0.929-0.930 Gbit/s
> >   B  mainline delays (rgmii-id, MAC tx 0 / rx 300, none on the PHY)
> >         TX 0.941   RX 0.929 Gbit/s
> >   C  the Ethernet path exactly as mainline has it
> >      (B, minus motorcomm,auto-sleep-disabled, minus PJ10)
> >         TX 0.941   RX 0.929 Gbit/s
> >
> > All three saturate the link, with rx_errs, rx_drop, tx_errs and tx_drop at 0
> > over roughly 1.6 million packets each. So mine are just other values that
> > work, and I am dropping them in favour of mainline's.
> >
> > > ethernet on the A523 has other problems. The performance is really bad
> > > (even RX), and there are errors or packet drops.
> >
> > I do not see that on this board, not even with C, which is mainline's Ethernet
> > DT unmodified. I also checked the YT8531 auto-sleep: the first packet after 5,
> > 10, 20, 30 and 45 s of silence came back in 0.21-0.24 ms, no losses.
> >
> > The kernel is my own 6.18-based tree, although stmmac and motorcomm.c are
> > stock, and this is one board with one PHY. Chen-Yu, which board and which MAC
> > are you seeing it on, and how do you measure it? If it is another board or
> > GMAC0, I can try to reproduce it here.
>
> On my Orange Pi 4A, running iperf3 between it and another Orange Pi 5 Plus
> (which has Intel PCIe NICs) as the server:

Correction, the Orange Pi 5 Plus has Realtek 2.5G NICs, not Intel.

>
>   - 4A as client: ~180 Mbps
>   - 4A as client but with reverse transfer (-R): ~520 Mbps
>
> Now if I do the same test between the Orange Pi 5 Plus and my virtual machine
> on an AMD AI 370 Pro based NAS, I can saturate the link up close to 2.5 Gbps.
>
> If I use a H618-based Orange Pi Zero 3 as the client and the Orange Pi 5 Plus
> as the server:
>
>   - Zero 3: ~920 Mbps
>   - Zero 3 with reverse: ~280 Mbps
>
> And I think my Cubie A5E and Avaota A1 fared even worse.
>
>
> Something is definitely off. I don't know what though.
>
>
> ChenYu