[PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
Jakub Kicinski
kuba at kernel.org
Tue Apr 28 18:06:25 PDT 2026
On Mon, 27 Apr 2026 15:25:05 +0800 lizhi2 at eswincomputing.com wrote:
> From: Zhi Li <lizhi2 at 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 at 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
More information about the linux-riscv
mailing list