netdev - Re: [PATCH net-next v1 5/5] net: tn40xx: add PHYLIB support

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: <daf9400f-c7e0-4f76-9a8d-977d9f82758a@lunn.ch>
Date: Tue, 16 Apr 2024 14:57:58 +0200
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 5/5] net: tn40xx: add PHYLIB support

> > Are there variants of this device using SFP? It might be you actually
> > want to use phylink, not phylib. That is a bit messy for a PCI device,
> > look at drivers/net/ethernet/wangxun.
> 
> phylink is necessary if PHY is hot-pluggable, right? if so, the driver
> doesn't need it. The PHYs that adapters with TN40XX use are

There is more to it than that. phylib has problems when the bandwidth
is > 1G and the MAC/PHY link becomes more problematic. Often the PHY
will change this link depending on what the media side is doing. If
you have a 1G SFP inserted, the QT2025 will change the MAC/PHY link to
1000BaseX. If it has a 10G SFP it will use XAUI. phylink knows how to
decode the SFP EEPROM to determine what sort of module it is, and how
the PHY should be configured.

To fully support this hardware you are going to need to use phylink.

> >> diff --git a/drivers/net/ethernet/tehuti/Kconfig b/drivers/net/ethernet/tehuti/Kconfig
> >> index 4198fd59e42e..71f22471f9a0 100644
> >> --- a/drivers/net/ethernet/tehuti/Kconfig
> >> +++ b/drivers/net/ethernet/tehuti/Kconfig
> >> @@ -27,6 +27,7 @@ config TEHUTI_TN40
> >>  	tristate "Tehuti Networks TN40xx 10G Ethernet adapters"
> >>  	depends on PCI
> >>  	select FW_LOADER
> >> +	select AMCC_QT2025_PHY
> > 
> > That is pretty unusual, especially when you say there are a few
> > different choices.
> 
> I should not put any 'select *_PHY' here?

Correct. Most distributions just package everything.

We are going to get into an odd corner case that since Rust is still
experimental, i doubt distributions are building Rust modules. So they
will end up with a MAC driver but no PHY driver, at least not for the
QT2025. The Marvell and Aquantia PHY should just work.

Anybody who does want to use the QT2025 will either need to
build there own kernel, or black list the in kernel MAC driver and use
the out of tree driver. But eventually, Rust will start to be
packaged, and then it should work out O.K.

	Andrew