[<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
Powered by blists - more mailing lists