From: Jakub Kicinski <kuba@kernel.org>
To: lizhi2@eswincomputing.com
Cc: devicetree@vger.kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
alex@ghiti.fr, linux-riscv@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, maxime.chevallier@bootlin.com,
ningyu@eswincomputing.com, linmin@eswincomputing.com,
pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com,
weishangjuan@eswincomputing.com, horms@kernel.org
Subject: Re: [PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
Date: Tue, 28 Apr 2026 18:06:25 -0700 [thread overview]
Message-ID: <20260428180625.738223cf@kernel.org> (raw)
In-Reply-To: <20260427072508.1151-1-lizhi2@eswincomputing.com>
On Mon, 27 Apr 2026 15:25:05 +0800 lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> The second Ethernet controller (eth1) on the Eswin EIC7700 SoC may fail
> to sample RX data correctly at Gigabit speed due to EIC7700-specific
> receive clock to data skew at the MAC input in the silicon.
>
> The existing internal delay configuration does not provide sufficient
> adjustment range to compensate for this condition at 1000Mbps.
> Update the EIC7700 DWMAC glue driver to apply EIC7700-specific clock
> sampling inversion only during Gigabit operation on MAC instances
> that require it.
>
> TXD and RXD delay registers are explicitly cleared during initialization
> to override any residual configuration left by the bootloader. All HSP
> CSR register accesses are performed only after the required clocks are
> enabled.
>
> Fixes: ea77dbbdbc4e ("net: stmmac: add Eswin EIC7700 glue driver")
Why Fixes? If eth1 never worked this is not a fix but new functionality
If you want to make this a fix to prevent incompatibility - cut it down
just to the eth0 changes.
> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> ---
> .../ethernet/stmicro/stmmac/dwmac-eic7700.c | 183 ++++++++++++++----
> 1 file changed, 140 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> index bcb8e000e720..33144611da8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> @@ -28,20 +28,40 @@
>
> /*
> * TX/RX Clock Delay Bit Masks:
> - * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.1ns per bit)
> - * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.1ns per bit)
> + * - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.02ns per bit)
> + * - TX Invert : bit [15]
> + * - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.02ns per bit)
> + * - RX Invert : bit [31]
> */
> #define EIC7700_ETH_TX_ADJ_DELAY GENMASK(14, 8)
> #define EIC7700_ETH_RX_ADJ_DELAY GENMASK(30, 24)
> +#define EIC7700_ETH_TX_INV_DELAY BIT(15)
> +#define EIC7700_ETH_RX_INV_DELAY BIT(31)
>
> -#define EIC7700_MAX_DELAY_UNIT 0x7F
> +#define EIC7700_MAX_DELAY_STEPS 0x7F
> +#define EIC7700_DELAY_STEP_PS 20
> +#define EIC7700_MAX_DELAY_PS \
> + (EIC7700_MAX_DELAY_STEPS * EIC7700_DELAY_STEP_PS)
AI says:
The step unit is being silently changed from 0.1 ns (delay_ps / 100)
to 0.02 ns (delay_ps / 20). The same DT value now programs 5x the number
of delay steps into the hardware.
> static const char * const eic7700_clk_names[] = {
> "tx", "axi", "cfg",
> };
>
> +struct eic7700_dwmac_data {
> + bool rgmii_rx_clk_invert;
> +};
> +
> struct eic7700_qos_priv {
> + struct device *dev;
> struct plat_stmmacenet_data *plat_dat;
> + struct regmap *eic7700_hsp_regmap;
> + u32 eth_axi_lp_ctrl_offset;
> + u32 eth_phy_ctrl_offset;
> + u32 eth_txd_offset;
> + u32 eth_clk_offset;
> + u32 eth_rxd_offset;
> + u32 eth_clk_dly_param;
> + bool eth_rx_clk_inv;
> };
>
> static int eic7700_clks_config(void *priv, bool enabled)
> @@ -61,8 +81,28 @@ static int eic7700_clks_config(void *priv, bool enabled)
> static int eic7700_dwmac_init(struct device *dev, void *priv)
> {
> struct eic7700_qos_priv *dwc = priv;
> + int ret;
> +
> + ret = eic7700_clks_config(dwc, true);
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(dwc->eic7700_hsp_regmap,
> + dwc->eth_phy_ctrl_offset,
> + EIC7700_ETH_TX_CLK_SEL |
> + EIC7700_ETH_PHY_INTF_SELI);
> + if (ret) {
> + eic7700_clks_config(dwc, false);
> + return ret;
> + }
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset,
> + EIC7700_ETH_CSYSREQ_VAL);
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_txd_offset, 0);
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_rxd_offset, 0);
>
> - return eic7700_clks_config(dwc, true);
> + return 0;
> }
>
> static void eic7700_dwmac_exit(struct device *dev, void *priv)
> @@ -88,18 +128,35 @@ static int eic7700_dwmac_resume(struct device *dev, void *priv)
> return ret;
> }
>
> +static void eic7700_dwmac_fix_speed(void *priv, phy_interface_t interface,
> + int speed, unsigned int mode)
> +{
> + struct eic7700_qos_priv *dwc = (struct eic7700_qos_priv *)priv;
> + u32 dly_param = dwc->eth_clk_dly_param;
> +
> + switch (speed) {
> + case SPEED_1000:
> + if (dwc->eth_rx_clk_inv)
> + dly_param |= EIC7700_ETH_RX_INV_DELAY;
> + break;
> + case SPEED_100:
> + case SPEED_10:
> + break;
> + default:
> + dev_err(dwc->dev, "invalid speed %u\n", speed);
> + break;
> + }
> +
> + regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_clk_offset, dly_param);
AI says
In the default case this logs "invalid speed %u" but then falls
through and still executes the regmap_write() with the base dly_param. An
unsupported speed reports an error and reprograms the hardware anyway.
Should the default path return without writing, or should the write be
moved into the valid cases only?
> +}
> +
> static int eic7700_dwmac_probe(struct platform_device *pdev)
> {
> + const struct eic7700_dwmac_data *data;
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> struct eic7700_qos_priv *dwc_priv;
> - struct regmap *eic7700_hsp_regmap;
> - u32 eth_axi_lp_ctrl_offset;
> - u32 eth_phy_ctrl_offset;
> - u32 eth_phy_ctrl_regset;
> - u32 eth_rxd_dly_offset;
> - u32 eth_dly_param = 0;
> - u32 delay_ps;
> + u32 delay_ps, val;
> int i, ret;
>
> ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> @@ -116,70 +173,95 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> if (!dwc_priv)
> return -ENOMEM;
>
> + dwc_priv->dev = &pdev->dev;
> +
> + data = device_get_match_data(&pdev->dev);
> + if (!data)
> + return dev_err_probe(&pdev->dev,
> + -EINVAL, "no match data found\n");
> +
> + dwc_priv->eth_rx_clk_inv = data->rgmii_rx_clk_invert;
> +
> /* Read rx-internal-delay-ps and update rx_clk delay */
> if (!of_property_read_u32(pdev->dev.of_node,
> "rx-internal-delay-ps", &delay_ps)) {
> - u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
> + if (delay_ps % EIC7700_DELAY_STEP_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "rx delay must be multiple of %dps\n",
> + EIC7700_DELAY_STEP_PS);
> +
> + if (delay_ps > EIC7700_MAX_DELAY_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "rx delay out of range\n");
>
> - eth_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> - eth_dly_param |= FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property rx-internal-delay-ps\n");
> + val = delay_ps / EIC7700_DELAY_STEP_PS;
> +
> + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> + dwc_priv->eth_clk_dly_param |=
> + FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> }
>
> /* Read tx-internal-delay-ps and update tx_clk delay */
> if (!of_property_read_u32(pdev->dev.of_node,
> "tx-internal-delay-ps", &delay_ps)) {
> - u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT);
> + if (delay_ps % EIC7700_DELAY_STEP_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "tx delay must be multiple of %dps\n",
> + EIC7700_DELAY_STEP_PS);
> +
> + if (delay_ps > EIC7700_MAX_DELAY_PS)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "tx delay out of range\n");
> +
> + val = delay_ps / EIC7700_DELAY_STEP_PS;
>
> - eth_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> - eth_dly_param |= FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property tx-internal-delay-ps\n");
> + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> + dwc_priv->eth_clk_dly_param |=
> + FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> }
AI says:
First, rx-internal-delay-ps and tx-internal-delay-ps are silently
demoted from required to optional. The previous driver returned
-EINVAL with "missing required property ..." when either was absent;
the else branches have been removed, so missing properties now leave
eth_clk_dly_param at zero and fix_mac_speed() programs zero delay
without diagnostic. Is this intentional, and if so should the commit
message and the DT binding reflect it?
Second, the previous code silently clamped out-of-range values via
min() and only required non-zero step units by integer truncation.
The new code rejects non-multiples of 20 and values greater than 2540
ps with -EINVAL at probe time. DTBs that previously probed with
clamped delays will now fail probe. Should this stricter validation
also be called out in the commit message?
> - eic7700_hsp_regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> - "eswin,hsp-sp-csr");
> - if (IS_ERR(eic7700_hsp_regmap))
> + dwc_priv->eic7700_hsp_regmap =
> + syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "eswin,hsp-sp-csr");
> + if (IS_ERR(dwc_priv->eic7700_hsp_regmap))
> return dev_err_probe(&pdev->dev,
> - PTR_ERR(eic7700_hsp_regmap),
> + PTR_ERR(dwc_priv->eic7700_hsp_regmap),
> "Failed to get hsp-sp-csr regmap\n");
>
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 1, ð_phy_ctrl_offset);
> + 1, &dwc_priv->eth_phy_ctrl_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> "can't get eth_phy_ctrl_offset\n");
>
> - regmap_read(eic7700_hsp_regmap, eth_phy_ctrl_offset,
> - ð_phy_ctrl_regset);
> - eth_phy_ctrl_regset |=
> - (EIC7700_ETH_TX_CLK_SEL | EIC7700_ETH_PHY_INTF_SELI);
> - regmap_write(eic7700_hsp_regmap, eth_phy_ctrl_offset,
> - eth_phy_ctrl_regset);
> -
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 2, ð_axi_lp_ctrl_offset);
> + 2, &dwc_priv->eth_axi_lp_ctrl_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> "can't get eth_axi_lp_ctrl_offset\n");
>
> - regmap_write(eic7700_hsp_regmap, eth_axi_lp_ctrl_offset,
> - EIC7700_ETH_CSYSREQ_VAL);
> + ret = of_property_read_u32_index(pdev->dev.of_node,
> + "eswin,hsp-sp-csr",
> + 3, &dwc_priv->eth_clk_offset);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "can't get eth_clk_offset\n");
>
> ret = of_property_read_u32_index(pdev->dev.of_node,
> "eswin,hsp-sp-csr",
> - 3, ð_rxd_dly_offset);
> + 4, &dwc_priv->eth_txd_offset);
> if (ret)
> return dev_err_probe(&pdev->dev, ret,
> - "can't get eth_rxd_dly_offset\n");
> + "can't get eth_txd_offset\n");
>
> - regmap_write(eic7700_hsp_regmap, eth_rxd_dly_offset,
> - eth_dly_param);
> + ret = of_property_read_u32_index(pdev->dev.of_node,
> + "eswin,hsp-sp-csr",
> + 5, &dwc_priv->eth_rxd_offset);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "can't get eth_rxd_offset\n");
AI says:
The eswin,hsp-sp-csr phandle-args layout is expanded from 4 cells
(phandle + 3 offsets) to 6 cells (phandle + 5 offsets), with new
indices 3/4/5 now required. Any DTB produced against the original
ea77dbbdbc4e binding will fail probe here with -EINVAL.
--
pw-bot: cr
next prev parent reply other threads:[~2026-04-29 1:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 7:23 [PATCH net-next v7 0/4] net: stmmac: eic7700: fix EIC7700 eth1 RX sampling timing lizhi2
2026-04-27 7:24 ` [PATCH net-next v7 1/4] dt-bindings: ethernet: eswin: add clock sampling control lizhi2
2026-04-29 1:28 ` Andrew Lunn
2026-04-27 7:25 ` [PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing lizhi2
2026-04-29 1:06 ` Jakub Kicinski [this message]
2026-04-27 7:25 ` [PATCH net-next v7 3/4] dt-bindings: mfd: syscon: add ESWIN EIC7700 compatible lizhi2
2026-04-27 19:05 ` Conor Dooley
2026-04-27 7:26 ` [PATCH net-next v7 4/4] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller lizhi2
2026-04-29 1:41 ` Andrew Lunn
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=20260428180625.738223cf@kernel.org \
--to=kuba@kernel.org \
--cc=alex@ghiti.fr \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linmin@eswincomputing.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=lizhi2@eswincomputing.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ningyu@eswincomputing.com \
--cc=pabeni@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pinkesh.vaghela@einfochips.com \
--cc=pjw@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox