[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6db0fd10-556d-47ec-b15a-d03e805b2621@gmail.com>
Date: Tue, 13 Feb 2024 15:19:34 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Pawel Dembicki <paweldembicki@...il.com>, netdev@...r.kernel.org
Cc: linus.walleij@...aro.org, Andrew Lunn <andrew@...n.ch>,
Vladimir Oltean <olteanv@...il.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
UNGLinuxDriver@...rochip.com, Russell King <linux@...linux.org.uk>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v4 02/15] net: dsa: vsc73xx: convert to PHYLINK
On 2/13/24 14:03, Pawel Dembicki wrote:
> This patch replaces the adjust_link api with the phylink apis that provide
> equivalent functionality.
>
> The remaining functionality from the adjust_link is now covered in the
> phylink_mac_link_* and phylink_mac_config.
>
> Removes:
> .adjust_link
> Adds:
> .phylink_mac_config
> .phylink_mac_link_up
> .phylink_mac_link_down
The implementation of phylink_mac_link_down() strictly mimics what had
been done by adjust_link() in the phydev->link == 0 case, but it really
makes me wonder whether some bits do not logically belong to
phylink_mac_link_up(), like "Accept packets again" for instance.
Are we certain there was not an assumption before that we would get
adjust_link() called first with phydev->link = 0, and then phydev->link
=1 and that this specific sequence would program things just the way we
want?
--
Florian
Powered by blists - more mailing lists