[PATCH v1 2/2] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing

李志 lizhi2 at eswincomputing.com
Sun Jan 11 22:55:45 PST 2026




> -----原始邮件-----
> 发件人: "Andrew Lunn" <andrew at lunn.ch>
> 发送时间:2026-01-10 02:31:09 (星期六)
> 收件人: lizhi2 at eswincomputing.com
> 抄送: devicetree at vger.kernel.org, andrew+netdev at lunn.ch, davem at davemloft.net, edumazet at google.com, kuba at kernel.org, robh at kernel.org, krzk+dt at kernel.org, conor+dt at kernel.org, netdev at vger.kernel.org, pabeni at redhat.com, mcoquelin.stm32 at gmail.com, alexandre.torgue at foss.st.com, rmk+kernel at armlinux.org.uk, linux-stm32 at st-md-mailman.stormreply.com, linux-arm-kernel at lists.infradead.org, linux-kernel at vger.kernel.org, ningyu at eswincomputing.com, linmin at eswincomputing.com, pinkesh.vaghela at einfochips.com, weishangjuan at eswincomputing.com
> 主题: Re: [PATCH v1 2/2] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
> 
> > +	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");
> 
> In order to be backwards compatible, you cannot error out here,
> because old DT blobs won't have this property.
> 

Thanks for the review.

We would like to clarify our understanding before changing the behavior.

'eswin,hsp-sp-csr' has been documented as a required property since the
initial EIC7700 DWMAC binding, and the existing driver already relies on
it for RX/TX clock delay programming. From our understanding, this
property is fundamental to correct MAC clock configuration on EIC7700,
rather than an optional enhancement.

Given this, could you please clarify whether we should still treat
eswin,hsp-sp-csr as optional at runtime purely for DT ABI robustness,
even though it is required by the binding and hardware design?

Once confirmed, we will update the driver and binding accordingly.

Thanks,
Li Zhi


More information about the linux-arm-kernel mailing list