[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f77b9385-5934-4afd-b255-adb5c9c5cef0@axis.com>
Date: Wed, 22 May 2024 09:57:47 +0200
From: Kamil Horák, 2N <kamilh@...s.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: 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 v3 1/3] net: phy: bcm54811: New link mode for BroadR-Reach
On 5/6/24 21:14, Andrew Lunn wrote:
> On Mon, May 06, 2024 at 04:40:13PM +0200, Kamil Horák - 2N wrote:
>> Introduce new link modes necessary for the BroadR-Reach mode on
>> bcm5481x PHY by Broadcom and new PHY tunable to choose between
>> normal (IEEE) ethernet and BroadR-Reach modes of the PHY.
> I would of split this into two patches. The reason being, we need the
> new link mode. But do we need the tunable? Why don't i just use the
> link mode to select it?
>
> ethtool -s eth42 advertise 1BR10
Tried to find a way to do the link mode selection this way but the
advertised modes are only applicable when there is auto-negotiation,
which is only partially the case of BCM54811: it only has
auto-negotiation in IEEE mode.
Thus, to avoid choosing between BroadR-Reach and IEEE mode using the PHY
Tunable, we would need something else and I am already running out of
ideas...
Is there any other possibility?
In addition, we would have to check for incompatible link modes selected
to advertise (cannot choose one BRR and one IEEE mode to advertise), or
perhaps the BRR modes would take precedence, if there is any BRR mode
selected to advertise, IEEE modes would be ignored.
>
> Once you have split this up, you can explain the link mode patch in a
> bit more detail. That because the name does not fit 802.3, the normal
> macros cannot be used, so everything needs to be hand crafted.
>
> Andrew
>
> ---
> pw-bot: cr
Kamil
Powered by blists - more mailing lists