netdev - Re: [PATCH] net: phy: bcm54811: add support for BroadR-Reach mode

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] [day] [month] [year] [list]

Message-ID: <feaa5d8f-f110-4ad2-be0e-94ddad9da719@lunn.ch>
Date: Thu, 25 Apr 2024 17:02:52 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Kamil Horák, 2N <kamilh@...s.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
	bcm-kernel-feedback-list@...adcom.com, hkallweit1@...il.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: bcm54811: add support for BroadR-Reach mode

> 1BR100 is really same as 100BASE-T1, in fact, the Broadcom's BroadR-Reach
> 1BR100 became 100BASE-T1 standard (IEEE 802.3bw). However, there is also
> 1BR10 to be implemented, which is neither 10BASE-T1S nor 10BASE-T1L.
> Thus, there would be 100BASE-T1 and the remaining BRR modes (1BR10, 2BR10,
> 2BR100, 4BR100), let alone the fact that it is questionable whether anyone
> would need the modes with more than one wire pair.
> So yes, for 100 MBit alone sure it would be better to make it 100BASE-T1 and
> it should be interoperable with another device using same link mode on
> non-Broadcom PHY.
> Note that the BRR modes are always full duplex
> 
> Shall we change the 1BR100 to 100BASE-T1 and leave the rest?
> 
> Option 1: 1BR10, 2BR10, 1BR100, 2BR100, 4BR100 (= leave as-is)
> 
> Option 2: 100BaseT1_Full, 1BR10, 2BR10, 2BR100, 4BR100
> 
> Option 3: 100BaseT1_Full, 1BR10 (= leave out the modes that are practically
> unusable)
> 
> In our application, 2-wire 10 and 100 MBit is used, the rest could be for
> someone else or just to map all PHY capabilities.

I would suggest you implement what you actually need. So option 3.

	Andrew