lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ