Re: [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing
Yixun Lan <[email protected]> Fri, 10 Jul 2026 02:25:51 +0000
| Newsgroups | dev.linux.lists.spacemit,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi E Shattow, On 00:29 Thu 11 Jun , E Shattow wrote: > Hi Andrew, > > On 6/10/26 02:05, Andrew Rembrandt wrote: > > On Wed, Jun 10, 2026 at 07:14:56 am Inochi Amaoto wrote: > >> Do not do this, just leave the rx-internal-delay-ps untouched. > > > > Sounds good, I'll leave v1 as-is. Many thanks for the review. > > > > Regards, > > > > Andrew > > > > _______________________________________________ > > linux-riscv mailing list > > [email protected] > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > I do not notice any difference with or without this property present, > tested Linux -next with U-Boot modification to devicetree: > > load usb 0:1 $fdt_addr_r /dtb/spacemit/k3-pico-itx.dtb > fdt addr $fdt_addr_r > fdt resize > fdt header get filesize totalsize > fdt set /soc/ethernet@cac80000 tx-internal-delay-ps <400> > load usb 0:1 $kernel_addr_r /EFI/BOOT/BOOTRISCV64.EFI > # throwaway use of ping is workaround for broken vendor U-Boot > ping 127.0.0.1; bootefi $kernel_addr_r $fdt_addr_r > > Aside, there is still some problem with the driver which does cause it > to fail. This can be reproduced by unloading the module and then loading > the module; built from -next with 'olddefconfig' of debian Kconfig for > kernel 7.1, no patches. > > # modprobe -r dwmac_spacemit > # modprobe dwmac_spacemit > [ 61.469745] spacemit-dwmac cac80000.ethernet end0: cannot attach to > PHY (error: -ENODEV) > > [ 91.544646] spacemit-dwmac cac80000.ethernet end0: cannot attach to > PHY (error: -ENODEV) > The problem is unrelated to this patch itself, but I can actually confirm here > If not reloading the module then I don't see any difference, traffic > passes (ping 1.1.1.1) with or without your suggested > tx-internal-delay-ps property. Is there a specific test to run to > observe expected difference? > Although I haven't narrowed down to the root cause, but it's kind of something wrong with the reset procedure, remove it from phy node will fix this issue.. +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts @@ -232,9 +232,6 @@ mdio { phy0: phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>; - reset-gpios = <&gpio 0 15 GPIO_ACTIVE_LOW>; - reset-assert-us = <10000>; - reset-deassert-us = <10000>; -- Yixun Lan (dlan)