Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 17 Jul 2022 03:39:39 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Sean Anderson <sean.anderson@seco.com>
Cc:     "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Madalin Bucur <madalin.bucur@nxp.com>, netdev@vger.kernel.org,
        Paolo Abeni <pabeni@redhat.com>,
        Eric Dumazet <edumazet@google.com>,
        linux-arm-kernel@lists.infradead.org,
        Russell King <linux@armlinux.org.uk>,
        linux-kernel@vger.kernel.org,
        Alexandru Marginean <alexandru.marginean@nxp.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>
Subject: Re: [PATCH net-next v3 10/47] net: phylink: Adjust link settings
 based on rate adaptation
Message-ID: <YtNoW8bJdWPzX3Cq@lunn.ch>
References: <20220715215954.1449214-1-sean.anderson@seco.com>
 <20220715215954.1449214-11-sean.anderson@seco.com>
 <YtMc2qYWKRn2PxRY@lunn.ch>
 <4172fd87-8e51-e67d-bf86-fdc6829fa9b3@seco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4172fd87-8e51-e67d-bf86-fdc6829fa9b3@seco.com>
Precedence: bulk

> > I would not do this. If the requirements for rate adaptation are not
> > fulfilled, you should turn off rate adaptation.
> > 
> > A MAC which knows rate adaptation is going on can help out, by not
> > advertising 10Half, 100Half etc. Autoneg will then fail for modes
> > where rate adaptation does not work.
> 
> OK, so maybe it is better to phylink_warn here. Something along the
> lines of "phy using pause-based rate adaptation, but duplex is %s".

You say 1/2 duplex simply does not work with rate adaptation. So i
would actually return -EINVAL at the point the MAC indicates what
modes it supports if there is a 1/2 duplex mode in the list.

> 
> > The MAC should also be declaring what sort of pause it supports, so
> > disable rate adaptation if it does not have async pause.
> 
> That's what we do in the previous patch.
> 
> The problem is that rx_pause and tx_pause are resolved based on our
> advertisement and the link partner's advertisement. However, the link
> partner may not support pause frames at all. In that case, we will get
> rx_pause and tx_pause as false. However, we still want to enable rx_pause,
> because we know that the phy will be emitting pause frames. And of course
> the user can always force disable pause frames anyway through ethtool.

Right, so we need a table somewhere in the documentation listing the
different combinations and what should happen.

If the MAC does not support rx_pause, rate adaptation is turned off.
If the negotiation results in no rx_pause, force it on anyway with
Pause based adaptation. If ethtool turns pause off, turn off rate
adaptation.

Does 802.3 say anything about this?

We might also want to add an additional state to the ethtool get for
pause, to indicate rx_pause is enabled because of rate adaptation, not
because of autoneg.

       Andrew