Re: [PATCH 1/2] riscv: dts: spacemit: Add enough deassert time for the PHY on PICO ITX

From: E Shattow

Date: Sat Jul 11 2026 - 03:20:30 EST


Hello Inochi,

On 7/9/26 23:33, Inochi Amaoto wrote:
> RTL8211F require at least 50ms deassert to guarantee the register
> access, 10ms is only enough for the PHY reset.
>
> Fixes: 74657a376960 ("riscv: dts: spacemit: Add ethernet device for K3")
> Signed-off-by: Inochi Amaoto <inochiama@xxxxxxxxx>
> ---
> arch/riscv/boot/dts/spacemit/k3-pico-itx.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> index 1eb5abbc61f9..b2a7d2d0d3a8 100644
> --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> @@ -200,7 +200,7 @@ phy0: phy@1 {
> reg = <1>;
> reset-gpios = <&gpio 0 15 GPIO_ACTIVE_LOW>;
> reset-assert-us = <10000>;
> - reset-deassert-us = <10000>;
> + reset-deassert-us = <50000>;
> };
> };
> };

applying this as vendor pre-installed u-boot runtime command modifying
Fdt as...

load usb 0:1 $fdt_addr_r
/debian-installer/device-tree-custom/spacemit/k3-pico-itx.dtb
load usb 0:1 $kernel_addr_r /debian-installer/riscv64/linux-custom
load usb 0:1 $ramdisk_addr_r /debian-installer/riscv64/initrd-custom.gz
fdt addr $fdt_addr_r
fdt resize
fdt rm /soc/ethernet@cac80000/mdio/phy@1 reset-deassert-us
fdt set /soc/ethernet@cac80000/mdio/phy@1 reset-deassert-us <50000>
env set bootargs 'initrd='$ramdisk_addr_r',0x'$filesize'
console=ttyS0,115200'
ping 127.0.0.1; bootefi $kernel_addr_r $fdt_addr_r

...before booting 7.2-rc2 and debian-installer initrd is successful to
allow debian-installer hardware probe to continue with the network
device, on Sipeed K3 Pico ITX. I don't know if that is a full fix for
the problem I observed with rmmod/modprobe cycle of network module but
at least it is resolving this trouble observed from debian-installer
usage with K3 Pico ITX.

Non-functional values are 10000 25000 30000 35000 39000 39750 39700
39600 39585 39581.
Functioning values are 39582 39583 39580 39575 39550 39500 40000 50000.

For this particular hardware I have thus observed an exact minimum
required delay value of 39582.

Tested-by: E Shattow <e@xxxxxxxxxxxx>