Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

On 5/29/26 14:59, Andrew Lunn wrote:
>> I think that
>>
>>    ethtool -s <iface> duplex half autoneg on
>>
>> should be enough, the link should still establish at 100M, I've tested
>> that on a 1G/FULL 100MHalf+Full interface and this is the result we
>> get :)
> 
> Nice.
> 
> But i still think the test should check the autoneg result and do
> something sensible if the link does not come up. This probably applies
> to all cases where we trigger auto neg.

Yes indeed, we need some sets of helpers to deal with link management, 
especially for this kind of ethtool tests, with ways to recover a known
working configuration.

> 
>> That said I've tested the following on mcbin, and it seems that acually
>> nothing in the code currently deals with Half duplex / Pause interaction,
>> and we don't get any EOPNOTSUPP.
>>
>> So the broader question is, should we reflect the current behaviour or
>> an ideal one ?
> 
> What 802.3 says. 

Ok, this is what I've been using to define the documented cases so far:)

> If we come across cases where phylib/phylink is
> broken, let me know, and i will fix it. But we will leave driver bugs
> to individual driver developers.
> 
> But we also need to consider that for some APIs, we have decided that
> a configuration can be set now, which does not actually apply in our
> current conditions, but it will be stored away for when conditions
> change and it is applicable. The half duplex case could fit that. When
> the link is currently half duplex, you can configure pause, but you
> don't expect it to actually change the current behaviour. It only
> kicks in when the link renegotiates to full duplex sometime in the
> future. We have to also consider this the other way around. The link
> is full duplex and pause is configured by the user. Something happens
> with the LP and the link renegotiates to half duplex. The local end
> should not throw away the configuration, it simply cannot apply it
> given the current situation.
> 

True, so the end result is that we must not error out when changing the
pause params while the link is in half duplex, but store the user intent.

Maybe an exception is if we only advertise HD modes ? i.e. HW can't do
FD, or user forced HD modes ? even then, ethtool will show that we
aren't advertising any Pause modes, so maybe that's enough.

OK maybe in the end the best course of action is to leave this 
discussion here and I followup with :

  - Well defined test cases in a machine-readable (or human readable but
    with much more details) format, including start conditions, a
    decision tree based on the "supported" fields

   - A list of identified corner cases that may be ill-defined (such as
    this HD topic) that we can openly discuss and potentially followup
    with code fixes

  - Human readable doc for developpers and AI to ingest

Maxime