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]

Date: Thu, 25 Apr 2024 10:24:28 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: andrew@...n.ch
Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 5/5] net: tn40xx: add PHYLIB support

Hi,

On Tue, 16 Apr 2024 14:57:58 +0200
Andrew Lunn <andrew@...n.ch> wrote:

>> > 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.

I updated the code to use phylink and posted v2. At least seems that
it works with 10G SFP+ as before.

I suppose that more changes are necessary for full support. For
example, with 1G SFP inserted, the MAC driver has to configure the
hardware for 1G. I'll investigate once I get 1G SFP.

Note that the original driver supports only 10G SFP+.


>> >> 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.

Sure, I dropped the above in v2.