mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Rembrandt <kernel@rembrandt.dev>
To: E Shattow <e@freeshell.de>
Cc: Yixun Lan <dlan@kernel.org>, 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: Sat, 18 Jul 2026 11:07:16 +0200	[thread overview]
Message-ID: <als2a8ra4PB6Y1t5@mcmanus> (raw)
In-Reply-To: <738ce6b8-798b-4689-a0f5-791fe85addbc@freeshell.de>

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 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.


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

  reply	other threads:[~2026-07-18  9:08 UTC|newest]

Thread overview: 11+ 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 [this message]
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=als2a8ra4PB6Y1t5@mcmanus \
    --to=kernel@rembrandt.dev \
    --cc=dlan@kernel.org \
    --cc=e@freeshell.de \
    --cc=inochiama@gmail.com \
    --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