[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b985a54-8c47-4f62-8971-e2a4d7976c03@broadcom.com>
Date: Tue, 16 Apr 2024 16:46:55 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Andrew Lunn <andrew@...n.ch>, Kamil HorĂ¡k - 2N
<kamilh@...s.com>
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/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?
--
Florian
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)
Powered by blists - more mailing lists