All of lore.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


WARNING: multiple messages have this Message-ID (diff)
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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-04-29  1:06 UTC|newest]

Thread overview: 32+ 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:23 ` lizhi2
2026-04-27  7:24 ` [PATCH net-next v7 1/4] dt-bindings: ethernet: eswin: add clock sampling control lizhi2
2026-04-27  7:24   ` lizhi2
2026-04-29  1:28   ` Andrew Lunn
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-27  7:25   ` lizhi2
2026-04-29  1:06   ` Jakub Kicinski [this message]
2026-04-29  1:06     ` Jakub Kicinski
2026-04-30  6:43     ` 李志
2026-04-30  6:43       ` 李志
2026-04-30 23:35       ` Jakub Kicinski
2026-04-30 23:35         ` Jakub Kicinski
2026-05-06  2:10         ` 李志
2026-05-06  2:10           ` 李志
2026-05-12  5:39           ` 李志
2026-05-12  5:39             ` 李志
2026-05-12 23:13             ` Jakub Kicinski
2026-05-12 23:13               ` Jakub Kicinski
2026-05-14  2:25               ` 李志
2026-05-14  2:25                 ` 李志
2026-04-27  7:25 ` [PATCH net-next v7 3/4] dt-bindings: mfd: syscon: add ESWIN EIC7700 compatible lizhi2
2026-04-27  7:25   ` lizhi2
2026-04-27 19:05   ` Conor Dooley
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-27  7:26   ` lizhi2
2026-04-29  1:41   ` Andrew Lunn
2026-04-29  1:41     ` Andrew Lunn
2026-04-30  7:05     ` 李志
2026-04-30  7:05       ` 李志

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