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)
next prev parent reply other threads:[~2026-07-19 10:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 18:23 Andrew Rembrandt
2026-06-09 5:37 ` Inochi Amaoto
2026-06-09 18:24 ` Andrew Rembrandt
2026-06-09 23:14 ` Inochi Amaoto
2026-06-10 9:05 ` Andrew Rembrandt
2026-06-11 7:29 ` E Shattow
2026-07-10 2:25 ` Yixun Lan
2026-07-10 14:34 ` E Shattow
2026-07-18 9:07 ` Andrew Rembrandt
2026-07-19 10:28 ` Yixun Lan [this message]
2026-07-19 16:06 ` E Shattow
2026-07-07 7:15 ` Yixun Lan
2026-07-14 9:08 ` Yixun Lan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260719102857-GKA8523@kernel.org \
--to=dlan@kernel.org \
--cc=e@freeshell.de \
--cc=inochiama@gmail.com \
--cc=kernel@rembrandt.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=spacemit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome