public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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, &eth_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,
> -		    &eth_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, &eth_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, &eth_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

  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