public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: lizhi2@eswincomputing.com
Cc: Simon Horman <horms@kernel.org>,
	alexandre.torgue@foss.st.com, devicetree@vger.kernel.org,
	alex@ghiti.fr, linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	ningyu@eswincomputing.com, linux-riscv@lists.infradead.org,
	krzk+dt@kernel.org, davem@davemloft.net, andrew+netdev@lunn.ch,
	conor+dt@kernel.org, weishangjuan@eswincomputing.com,
	kuba@kernel.org, robh@kernel.org, edumazet@google.com,
	pjw@kernel.org, rmk+kernel@armlinux.org.uk, palmer@dabbelt.com,
	mcoquelin.stm32@gmail.com, pinkesh.vaghela@einfochips.com,
	linux-kernel@vger.kernel.org, pritesh.patel@einfochips.com,
	pabeni@redhat.com, aou@eecs.berkeley.edu, wens@kernel.org,
	netdev@vger.kernel.org, linmin@eswincomputing.com
Subject: Re: [net-next,v4,2/3] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
Date: Sun, 15 Mar 2026 16:27:35 +0000	[thread overview]
Message-ID: <20260315162735.1427325-1-horms@kernel.org> (raw)
In-Reply-To: <20260313075416.1607-1-lizhi2@eswincomputing.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing

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.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> index bcb8e000e720..b230bc5b902a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c

[ ... ]

> @@ -61,8 +81,26 @@ 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)
> +		return ret;

Does this code leak the enabled clocks? The function calls
eic7700_clks_config(dwc, true) to enable the clocks, then later calls
regmap_set_bits(). If regmap_set_bits() fails, the function returns
without disabling the clocks.

Looking at the caller in stmmac_main.c:stmmac_dvr_probe():

    if (priv->plat->init) {
        ret = priv->plat->init(priv->device, priv->plat->bsp_priv);
        if (ret)
            return ret;
    }

    ret = __stmmac_dvr_probe(priv->device, priv->plat, &res);
    if (ret)
        goto error_exit_init;

The exit handler is only called when __stmmac_dvr_probe() fails, not
when init() fails. This leaves the bulk clocks in the prepared-and-enabled
state on this error path.

> +
> +	regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset,
> +		     EIC7700_ETH_CSYSREQ_VAL);
>
> -	return eic7700_clks_config(dwc, true);
> +	regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_txd_offset, 0);
> +	regmap_write(dwc->eic7700_hsp_regmap, dwc->eth_rxd_offset, 0);
> +
> +	return 0;
>  }

[ ... ]

  reply	other threads:[~2026-03-15 16:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13  7:52 [PATCH net-next v4 0/3] net: stmmac: eic7700: fix EIC7700 eth1 RX sampling timing lizhi2
2026-03-13  7:53 ` [PATCH net-next v4 1/3] dt-bindings: ethernet: eswin: add clock sampling control lizhi2
2026-03-13 17:39   ` Conor Dooley
2026-03-19  9:55     ` 李志
2026-03-13  7:54 ` [PATCH net-next v4 2/3] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing lizhi2
2026-03-15 16:27   ` Simon Horman [this message]
2026-03-16  2:10     ` Re: [net-next,v4,2/3] " 李志
2026-03-13  7:54 ` [PATCH net-next v4 3/3] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller lizhi2

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=20260315162735.1427325-1-horms@kernel.org \
    --to=horms@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=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-riscv@lists.infradead.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=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 \
    --cc=wens@kernel.org \
    /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