From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: lizhi2@eswincomputing.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
rmk+kernel@armlinux.org.uk,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: ningyu@eswincomputing.com, linmin@eswincomputing.com,
pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com,
weishangjuan@eswincomputing.com
Subject: Re: [PATCH net v1 2/2] net: stmmac: eic7700: fix delay step calculation and ensure safe register initialization
Date: Thu, 7 May 2026 13:21:41 +0200 [thread overview]
Message-ID: <92e8a3dd-a46a-499f-b5f6-99f7b99f45f5@bootlin.com> (raw)
In-Reply-To: <20260507083214.192-1-lizhi2@eswincomputing.com>
Hi,
On 07/05/2026 10:32, lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> Fix several issues in the EIC7700 DWMAC glue driver related to delay
> configuration and register initialization.
>
> The hardware implements TX/RX delay with a granularity of 20 ps per
> step, but the driver previously assumed a 100 ps step. Update the
> definitions to match the actual hardware behaviour and align with
> the binding constraints.
>
> Introduce explicit definitions for the maximum programmable delay
> range based on the hardware limits.
>
> Move HSP CSR configuration into the initialization path after clocks
> are enabled. This ensures that all register accesses occur with the
> required clocks active, avoiding undefined behaviour.
>
> Clear the TXD and RXD delay control registers during initialization
> to override any residual configuration left by the bootloader. This
> ensures deterministic RGMII timing and prevents unintended delay
> being applied.
>
> The MAC RGMII delay programming is only required for 100Mbps and
> 1000Mbps modes, where precise clock-to-data alignment is necessary for
> reliable sampling.
>
> For 10Mbps operation, timing margins are sufficiently relaxed and no
> additional delay compensation is required. In this case, the driver
> falls back to a safe default configuration with delay disabled.
>
> For unsupported or unexpected link speeds, the driver avoids
> programming invalid delay values and falls back to a safe default
> state by explicitly clearing the delay configuration.
>
> Explicitly programming zero ensures that no residual delay settings
> from previous configurations or bootloader state remain active.
>
> These changes fix incorrect delay programming and initialization
> ordering for existing users.
>
> This also aligns the driver implementation with the updated device
> tree binding.
There's a lot going on in this patch, can you split this into patches
that solves each of these individual issues ?
It's a mix of fixes (the reg access moved after clk config for example)
and non-fixes (the RGMII timings, you're improving the granularity of
the delays, is this required to fix existing setups, or is it a generic
improvement ?), splitting this would make it both easier to review, and
easier to bisect should problems arise in the future.
Thanks,
Maxime
next prev parent reply other threads:[~2026-05-07 11:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 8:30 [PATCH net v1 0/2] net: stmmac: eic7700: fix delay calculation and initialization ordering lizhi2
2026-05-07 8:31 ` [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description lizhi2
2026-05-07 12:29 ` Andrew Lunn
2026-05-08 5:47 ` 李志
2026-05-15 7:31 ` 李志
2026-05-15 13:14 ` Andrew Lunn
2026-05-07 17:24 ` Conor Dooley
2026-05-08 5:43 ` 李志
2026-05-08 14:55 ` Conor Dooley
2026-05-07 8:32 ` [PATCH net v1 2/2] net: stmmac: eic7700: fix delay step calculation and ensure safe register initialization lizhi2
2026-05-07 11:21 ` Maxime Chevallier [this message]
2026-05-08 6:25 ` 李志
2026-05-08 17:14 ` sashiko-bot
2026-05-09 5:28 ` 李志
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=92e8a3dd-a46a-499f-b5f6-99f7b99f45f5@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linmin@eswincomputing.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=lizhi2@eswincomputing.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ningyu@eswincomputing.com \
--cc=pabeni@redhat.com \
--cc=pinkesh.vaghela@einfochips.com \
--cc=pritesh.patel@einfochips.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh@kernel.org \
--cc=weishangjuan@eswincomputing.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.