[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251217135519.GA767145-robh@kernel.org>
Date: Wed, 17 Dec 2025 07:55:19 -0600
From: Rob Herring <robh@...nel.org>
To: Stefan Eichenberger <eichest@...il.com>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, krzk+dt@...nel.org,
conor+dt@...nel.org, hkallweit1@...il.com, linux@...linux.org.uk,
geert+renesas@...der.be, ben.dooks@...ethink.co.uk,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, francesco.dolcini@...adex.com,
rafael.beims@...adex.com,
Stefan Eichenberger <stefan.eichenberger@...adex.com>
Subject: Re: [PATCH net-next v1 2/3] dt-bindings: net: micrel: Add
keep-preamble-before-sfd
On Wed, Dec 17, 2025 at 01:21:19PM +0100, Stefan Eichenberger wrote:
> On Wed, Dec 17, 2025 at 10:58:54AM +0100, Stefan Eichenberger wrote:
> > On Mon, Dec 15, 2025 at 08:03:30AM -0600, Rob Herring wrote:
> > > On Fri, Dec 12, 2025 at 09:46:17AM +0100, Stefan Eichenberger wrote:
> > > > From: Stefan Eichenberger <stefan.eichenberger@...adex.com>
> > > >
> > > > Add a property to activate a Micrel PHY feature that keeps the preamble
> > > > enabled before the SFD (Start Frame Delimiter) is transmitted.
> > > >
> > > > This allows to workaround broken Ethernet controllers as found on the
> > > > NXP i.MX8MP. Specifically, errata ERR050694 that states:
> > > > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > > > Byte does not precede SFD or SMD.
> > >
> > > It doesn't really work right if you have to change the DT to work-around
> > > a quirk in the kernel. You should have all the information needed
> > > already in the DT. The compatible string for the i.MX8MP ethernet
> > > controller is not sufficient?
> >
> > Is doing something like this acceptable in a phy driver?
> > if (of_machine_is_compatible("fsl,imx8mp")) {
> > ...
> > }
> >
> > That would be a different option, rather than having to add a new DT
> > property. Unfortunately, the workaround affects the PHY rather than the
> > MAC driver. This is why we considered adding a DT property.
>
> Francesco made a good point about this. The i.MX8MP has two MACs, but
> only one of them is affected. Therefore, checking the machine's
> compatible string would not be correct. As far as I know, checking the
> MAC's compatible string from within the PHY driver is also not good
> practice, is it?
It's not great, but probably what you need to do. The 2 MACs are the
same (compatible) or different? As that only works if they are
different. I suppose you need to only check the MAC the PHY is connected
to.
I think the ideal implementation would be the MAC driver calling some
phy API to apply the quirk, and then that gets passed on to the phy
driver. Surely this isn't the first case of a MAC-PHY combination
needing to go fiddle with some special setting.
Rob
Powered by blists - more mailing lists