Re: [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing

[E Shattow <e@freeshell.de>]

Hi Andrew, Yixun,

On 7/19/26 03:28, Yixun Lan wrote:
> Hi Andrew,
> 
> On 11:07 Sat 18 Jul     , Andrew Rembrandt wrote:
>> Hi E, Yixun,
>>
>> On Fri, Jul 10, 2026 at 07:34:34 am E Shattow wrote:
>>> On the topic of this ethernet TX timing thread I don't know what
>>> this does? Is there a test situation I may try to know if it is doing
>>> anything? Thanks very much, -E
>> Apologies for the slow reply -- I've been swamped the past month.
>>
>> Thank you for taking the time to test this; your results are what
>> prompted me to go back and re-test properly, and it turns out my
>> original premise was wrong.
>>
>> The non-functional TX I originally saw was not fixed by this delay
>> property at all. An unrelated commit that landed between v7.1-rc1 and
>> v7.1-rc7 is what actually fixed the dead TX on my board. While
>> developing this patch I'd inadvertently picked up that change, and I
>> wrongly concluded the tx-internal-delay-ps addition was what got traffic
>> flowing.

I guess this refers to commit 3ea695eb111f ("dts: riscv: spacemit: k3:
Fix I/O power settings") pulled in for 7.2 and with the fixes tag also
applied for 7.1 prior to 7.1-rc6 tag. That was confusing for me until
having the benefit of an explanation by the Fedora RISC-V special
interest group discussion member(s) highlighting that patch, as I was
experiencing three distinct problems for that network interface. My use
of debian-installer just happens to be a reproducer for all three
problems. The Fedora RISC-V SIG members did not have difficulty with
their distro development processes on two of the three problems I
experience which led me to identify there are remaining problems not
fixed in 7.1

>>
>> To confirm, I re-ran a series of iperf3 tests without the delay patch
>> and saw no transmission problem whatsoever -- a full 1Gb/s in both
>> directions with no errors. So this matches exactly what you and perhaps
>> Yixun also observed: on a current base the property makes no measurable
>> difference, because the TX path already works without it.

Andrew, there are remaining problems of de-assert delay [1] and
rmmod/modprobe cycle failure [2]. I suggest you test and validate the
proposed changes so providing another data point of [1] the minimum
delay that is successful. The rmmod/modprobe cycling workaround [2] can
also benefit from testing. In the case of Kconfig with k3 networking =m
as modules, or =y compiled-in either way it would be helpful to know
that your use of networking is not disrupted in some unexpected way with
the expected fixes.

Yixun, are patches [1] [2] expected as fixes for 7.2 ?

1:
https://lore.kernel.org/lkml/20260710063314.1030249-1-inochiama@gmail.com/
2: https://lore.kernel.org/lkml/20260712045233.800748-1-inochiama@gmail.com/

- E