[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<174537183074.2107432.17359160335159032493.git-patchwork-notify@kernel.org>
Date: Wed, 23 Apr 2025 01:30:30 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
Cc: andrew@...n.ch, hkallweit1@...il.com, alexander.duyck@...il.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH net] net: phylink: mac_link_(up|down)() clarifications
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@...nel.org>:
On Wed, 16 Apr 2025 22:53:19 +0100 you wrote:
> As a result of an email from the fbnic author, I reviewed the phylink
> documentation, and I have decided to clarify the wording in the
> mac_link_(up|down)() kernel documentation as this was written from the
> point of view of mvneta/mvpp2 and is misleading.
>
> The documentation talks about forcing the link - indeed, this is what
> is done in the mvneta and mvpp2 drivers but not at the physical layer
> but the MACs idea, which has the effect of only allowing or stopping
> packet flow at the MAC. This "link" needs to be controlled when using
> a PHY or fixed link to start or stop packet flow at the MAC. However,
> as the MAC and PCS are tightly integrated, if the MACs idea of the
> link is forced down, it has the side effect that there is no way to
> determine that the media link has come up - in this mode, the MAC must
> be allowed to follow its built-in PCS so we can read the link state.
>
> [...]
Here is the summary with links:
- [net] net: phylink: mac_link_(up|down)() clarifications
https://git.kernel.org/netdev/net/c/ce6815585d46
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists