[PATCH v2 2/5] arm64: dts: freescale: Add device tree for Compulab UCM-iMX8M-Plus

[Laurent Pinchart]

(CC'ing Johannes)

On Sun, Mar 17, 2024 at 10:55:16PM +0100, Andrew Lunn wrote:
> On Sun, Mar 17, 2024 at 08:57:22PM +0200, Laurent Pinchart wrote:
> > On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote:
> > > > +&eqos {
> > > > +	pinctrl-names = "default";
> > > > +	pinctrl-0 = <&pinctrl_eqos>;
> > > > +	phy-mode = "rgmii-id";
> > > > +	phy-handle = <&ethphy0>;
> > > > +
> > > > +	mdio {
> > > > +		compatible = "snps,dwmac-mdio";
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <0>;
> > > > +
> > > > +		/* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */
> > > > +		ethphy0: ethernet-phy at 0 {
> > > > +			compatible = "ethernet-phy-ieee802.3-c22";
> > > > +			reg = <0>;
> > > > +			eee-broken-1000t;
> > > > +		};
> > > 
> > > Hi Laurent
> > > 
> > > Do you happen to know what is broken with respect to EEE? It seems
> > > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe
> > > we should be keying off the MAC compatible and disabling this in the
> > > ethernet driver rather than have every .dts file needing it?
> > 
> > I wonder if this could be cargo-cult. To be honest, I've copied it from
> > the BSP and haven't investigated it. I've tried dropping that and
> > haven't noticed any difference, but I'm not sure how I should test it
> > properly.
> 
> Maybe a better approach is to find the errata. It could be some older
> version of the eqos was broken, and it got fixed along the way? If
> that is so, moving it into the driver would be better, assuming there
> is some sort of hardware version register in the eqos.

I don't know if there are public errata about this issue. It is beyong
my areas of expertise. I've found a relatively recent e-mail on the
netdev mailing list that seems related ([1]), but there was no reply.

[1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/

-- 
Regards,

Laurent Pinchart