linux-kernel - Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

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: <bc31f53a-ba85-4580-add3-a287dca06661@lunn.ch>
Date: Sun, 17 Aug 2025 21:39:36 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Rob Landley <rob@...dley.net>
Cc: Artur Rojek <contact@...ur-rojek.eu>, Jeff Dionne <jeff@...esemi.io>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

> My vague recollection is this SOC only implemented full duplex 100baseT
> because they didn't have any hardware lying around that _couldn't_ talk to
> that.

It is pretty unusual to find hardware, now a days, which only does
10Mbp. So it is a somewhat theoretical use case. And as you say,
100Mbps is plenty fast for lots of applications.

What we need to think about is the path forwards, how MDIO and PHY
support can be added later, without breaking DT backwards
compatibility.

What you would normally do if there is no access to the PHY is use
fixed-link. It emulates a PHY, one that is always up and at a fixed
speed. See fixed-link in
Documentation/devicetree/bindings/net/ethernet-controller.yaml

That allows the MAC driver to use the phylib API. The MAC does not
hard coded the carrier up, phylib tells the MAC link is up, and phylib
manages the carrier.

What this means is, if sometime in the future MDIO is added, and
phylib gets access to the PHY, there are no MAC driver changes. Old DT
blobs, using fixed-link still work, and new DT blobs with MDIO, a PHY
node, and a phy-handle have working PHY.

If you don't do this now, adding support later will be messy, if you
don't want to break backwards compatibility with old DT blobs.

	Andrew