linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ddfdeba-cc85-47af-9762-b30143c4e606@axis.com>
Date: Thu, 25 Apr 2024 14:57:38 +0200
From: Kamil Horák, 2N <kamilh@...s.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>,
 Andrew Lunn <andrew@...n.ch>
Cc: 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


On 4/17/24 01:46, Florian Fainelli wrote:
> On 4/16/24 07:10, Andrew Lunn wrote:
>>> @@ -258,6 +257,9 @@ static const struct phy_setting settings[] = {
>>>       PHY_SETTING(    100, HALF,    100baseT_Half        ),
>>>       PHY_SETTING(    100, HALF,    100baseFX_Half        ),
>>>       PHY_SETTING(    100, FULL,    100baseFX_Full        ),
>>> +    PHY_SETTING(    100, FULL,    4BR100            ),
>>> +    PHY_SETTING(    100, FULL,    2BR100            ),
>>> +    PHY_SETTING(    100, FULL,    1BR100            ),
>>
>> Please could you explain the name convention. IEEE puts the speed
>> first, then some letters to indicate the media type, and then a number
>> for the number of pairs. Why is this not followed here? 100BaseBR4?
>> 100BaseBR2? 100BaseBR1? Are these names part of the BroadR-Reach
>> standard?
>
> The datasheet refers to those mode as 1BR-100 so it seems to make 
> sense to define them the same way here.
>
>>
>> Also, is there any compatibility? Are 100BaseT1 and 1BR100 compatible?
>
> As far as I could glean, they are supposed to be:
>
> https://www.electronicdesign.com/markets/automotive/article/21806576/whats-the-difference-between-broadr-reach-and-100base-t1 
>
>
> Given that part, it makes me wonder if it would not be less confusing 
> to map the existing T1 link modes onto what the BCM54811 PHY supports, 
> Kamil, what do you think?
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.