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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-arm-kernel@lists.infradead.org,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	imx@lists.linux.dev, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, Johannes Zink <j.zink@pengutronix.de>
Subject: Re: [PATCH v2 2/5] arm64: dts: freescale: Add device tree for Compulab UCM-iMX8M-Plus
Date: Mon, 18 Mar 2024 01:50:30 +0200	[thread overview]
Message-ID: <20240317235030.GB18202@pendragon.ideasonboard.com> (raw)
In-Reply-To: <7deaf04a-7433-4712-9fb8-1c89fc283346@lunn.ch>

(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@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

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