mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>, Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Eric Dumazet <edumazet@google.com>, Rob Herring <robh@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Donald Hunter <donald.hunter@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jonathan Corbet <corbet@lwn.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Lukasz Majewski <lukma@denx.de>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Paolo Abeni <pabeni@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Divya.Koppera@microchip.com,
	Kory Maincent <kory.maincent@bootlin.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	netdev@vger.kernel.org, Sabrina Dubroca <sd@queasysnail.net>,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH net-next v8 1/1] Documentation: net: add flow control guide and document ethtool API
Date: Thu, 27 Nov 2025 16:31:50 +0100	[thread overview]
Message-ID: <c14b1dae-142e-4038-92a9-cfcad492f4e2@bootlin.com> (raw)
In-Reply-To: <7a5a9201-4c26-42f8-94f2-02763f26e8c1@lunn.ch>

Hi Andrew

I am sorry, I have a bit of sidetracking...

>> State Persistence and Toggling When toggling autoneg (e.g., autoneg on -> off
>> -> on), should the kernel or driver cache the previous advertisement?
> 
> This has been discussed in the past, and i _think_ phylink does.
> 
> But before we go too far into edge causes, my review experience is
> that MAC drivers get the basics wrong. What we really want to do here
> is:
> 
> 1) Push driver developers towards phylink

Is it something we should insist on in the review process ? Can we make
it a hard requirement that _new_ MAC drivers need to use phylink, if the
driver plans to interact with a PHY ?

phylink has long outgrown the original use-case of supporting SFPs by
abstracting away the MAc to [PHY/SFP] interactions, it's now used as a
an abstraction layer that avoids MAC drivers making the same mistakes
over and over again on a lot of cases that don't have anything to do
with SFP.

I think we can no longer really say "If your driver is simple enough,
you can stick to using phylib directly", at least not for new drivers,
as phylink now simplifies EEE, WoL, Pause, etc.

> 2) For those who don't use phylink give clear documentation of the
>    basics.
> 
> We can look at edge cases, but i would only do it in the context of
> phylink. Its one central implementation means we can add complexity
> there and not overload developers who get the basics wrong.
> 
> 	Andrew

Maxime

  reply	other threads:[~2025-11-27 15:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 14:03 Oleksij Rempel
2025-11-26  2:19 ` Jakub Kicinski
2025-11-26  8:36   ` Oleksij Rempel
2025-11-26 22:42     ` Jakub Kicinski
2025-11-27  9:20       ` Oleksij Rempel
2025-11-27 15:07         ` Andrew Lunn
2025-11-27 15:31           ` Maxime Chevallier [this message]
2025-11-27 15:48             ` Andrew Lunn
2025-11-27 16:18               ` Russell King (Oracle)
2025-11-27 16:14           ` Russell King (Oracle)
2025-11-28  1:21             ` Jakub Kicinski
2025-11-27 16:10         ` Russell King (Oracle)
2025-11-28  1:27     ` Russell King (Oracle)
2025-11-28  1:47       ` Russell King (Oracle)
2025-11-28  8:55         ` Oleksij Rempel
2025-11-28  9:35           ` Russell King (Oracle)
2025-11-28 18:32           ` Jakub Kicinski
2025-11-28 20:16             ` Andrew Lunn
2025-11-28 20:38               ` Russell King (Oracle)
2025-11-28 22:17                 ` Jakub Kicinski
2025-12-01  9:49                   ` Oleksij Rempel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c14b1dae-142e-4038-92a9-cfcad492f4e2@bootlin.com \
    --to=maxime.chevallier@bootlin.com \
    --cc=Divya.Koppera@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=ast@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hawk@kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=john.fastabend@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kory.maincent@bootlin.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lukma@denx.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --cc=sd@queasysnail.net \
    --cc=sdf@fomichev.me \
    --cc=vadim.fedorenko@linux.dev \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®