Received-SPF: pass (google.com: domain of linux-kernel+bounces-158753-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 25 Apr 2024 17:02:52 +0200
From: Andrew Lunn <andrew@lunn.ch>
To: Kamil =?iso-8859-1?B?SG9y4Wss?= 2N <kamilh@axis.com>
Cc: Florian Fainelli <florian.fainelli@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com, hkallweit1@gmail.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: phy: bcm54811: add support for BroadR-Reach mode
Message-ID: <feaa5d8f-f110-4ad2-be0e-94ddad9da719@lunn.ch>
References: <20240416123811.1880177-1-kamilh@axis.com>
 <3aaf1b82-247e-447d-a39c-c209105c2d7c@lunn.ch>
 <1b985a54-8c47-4f62-8971-e2a4d7976c03@broadcom.com>
 <4ddfdeba-cc85-47af-9762-b30143c4e606@axis.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4ddfdeba-cc85-47af-9762-b30143c4e606@axis.com>

> 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