linux-kernel - Re: [PATCH net-next V2 4/5] net: lan743x: Implement phylink pcs

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: <4559162d-5502-4fc3-9e46-65393e28e082@lunn.ch>
Date: Fri, 13 Sep 2024 15:19:39 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@...rochip.com>
Cc: Ronnie Kunin - C21729 <Ronnie.Kunin@...rochip.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	Bryan Whitehead - C21958 <Bryan.Whitehead@...rochip.com>,
	UNGLinuxDriver <UNGLinuxDriver@...rochip.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>,
	"maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>,
	"rdunlap@...radead.org" <rdunlap@...radead.org>,
	Steen Hegelund - M31857 <Steen.Hegelund@...rochip.com>,
	Daniel Machon - M70577 <Daniel.Machon@...rochip.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next V2 4/5] net: lan743x: Implement phylink pcs

> It's my mistake. We don't need 2 MDIO buses. 
> If SFP present, XPC's MDIO bus can use,
> If not sfp, LAN743x MDIO bus can use. 

I still think this is wrong. Don't focus on 'sfp present'.

Other MAC drivers don't even know there is an SFP cage connected vs a
PHY. They just tell phylink the list of link modes they support, and
phylink tells it which one to use when the media has link.

You have a set of hardware building blocks, A MAC, a PCS, an MDIO bus.
Use the given abstractions in Linux to export them to the core, and
then let Linux combine them as needed.

Back to my question about EEPROM vs fuses. I assume it is an EEPROM,
and the PCS always exists. So always instantiate an MDIO bus and
instantiate the PCS. The MDIO bus always exists, so instantiate an
MDIO bus.

The driver itself should not really need to take any notice of the
EEPROM contents. All the EEPROM is used for is to indicate what
swnodes to create. It is a replacement of DT. Look at other drivers,
they don't parse DT to see if there is an SFP and so instantiate
different blocks.

As a silicon vendor, you want to export all the capabilities of the
device, and then sit back and watch all the weird and wonderful ways
you never even imagined it could be used come to life.

One such use case: What you can express in the EEPROM is very
limited. I would not be too surprised if somebody comes along and adds
DT overlay support. Look at what is going on with MikrotekBus and the
RPI add on chip RP1. Even microchip itself is using DT overlays with
some of its switch chips.

	Andrew