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

From: Yixun Lan <dlan@kernel.org>
To: Andrew Rembrandt <kernel@rembrandt.dev>
Cc: E Shattow <e@freeshell.de>, Inochi Amaoto <inochiama@gmail.com>,
	linux-riscv@lists.infradead.org, spacemit@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: dts: spacemit: k3-pico-itx: Fix non-functional ethernet TX timing
Date: Sun, 19 Jul 2026 10:28:57 +0000	[thread overview]
Message-ID: <20260719102857-GKA8523@kernel.org> (raw)
In-Reply-To: <als2a8ra4PB6Y1t5@mcmanus>

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.
> 
> 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.
> 
> Given that, the patch isn't the fix as described in the changelog, and
> the property has no functional effect on this board.
> 
..
> Yixun -- since you've already applied it, could you drop it from your
> tree? A revert is fine too if it's landed somewhere non-rewindable, but
I can drop this patch

> I don't think it should go upstream as-is: the "Fixes:" tag and the "no
> ethernet traffic passes" rationale are both wrong. Sorry for the hassle,
> and thanks for queuing it in good faith.
> 
No worry

> 
> Sorry again for the noise, and thanks E for the careful testing that
> caught this.

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv