Re: [PATCH net] net: phy: phy_caps: Don't skip better duplex macth on non-exact match

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

On Thu, 5 Jun 2025 12:24:54 +0200
Paolo Abeni <pabeni@redhat.com> wrote:

> On 6/3/25 10:35 AM, Maxime Chevallier wrote:
> > When performing a non-exact phy_caps lookup, we are looking for a
> > supported mode that matches as closely as possible the passed speed/duplex.
> > 
> > Blamed patch broke that logic by returning a match too early in case
> > the caller asks for half-duplex, as a full-duplex linkmode may match
> > first, and returned as a non-exact match without even trying to mach on
> > half-duplex modes.
> > 
> > Reported-by: Jijie Shao <shaojijie@huawei.com>
> > Closes: https://lore.kernel.org/netdev/20250603102500.4ec743cf@fedora/T/#m22ed60ca635c67dc7d9cbb47e8995b2beb5c1576
> > Fixes: fc81e257d19f ("net: phy: phy_caps: Allow looking-up link caps based on speed and duplex")
> > Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> > ---
> >  drivers/net/phy/phy_caps.c | 15 +++++++++------
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/net/phy/phy_caps.c b/drivers/net/phy/phy_caps.c
> > index 703321689726..d80f6a37edf1 100644
> > --- a/drivers/net/phy/phy_caps.c
> > +++ b/drivers/net/phy/phy_caps.c
> > @@ -195,7 +195,7 @@ const struct link_capabilities *
> >  phy_caps_lookup(int speed, unsigned int duplex, const unsigned long *supported,
> >  		bool exact)
> >  {
> 	> -	const struct link_capabilities *lcap, *last = NULL;
> > +	const struct link_capabilities *lcap, *match = NULL, *last = NULL;
> >  
> >  	for_each_link_caps_desc_speed(lcap) {
> >  		if (linkmode_intersects(lcap->linkmodes, supported)) {
> > @@ -204,16 +204,19 @@ phy_caps_lookup(int speed, unsigned int duplex, const unsigned long *supported,
> >  			if (lcap->speed == speed && lcap->duplex == duplex) {
> >  				return lcap;
> >  			} else if (!exact) {
> > -				if (lcap->speed <= speed)
> > -					return lcap;
> > +				if (!match && lcap->speed <= speed)
> > +					match = lcap;
> > +
> > +				if (lcap->speed < speed)
> > +					break;
> >  			}
> >  		}
> >  	}
> >  
> > -	if (!exact)
> > -		return last;
> > +	if (!match && !exact)
> > +		match = last;  
> 
> If I read correctly, when user asks for half-duplex, this can still
> return a non exact matching full duplex cap, even when there is non
> exact matching half-duplex cap available.

That would be only if there's no half-duplex match at the requested
speed, but yes indeed.

> 
> I'm wondering if the latter would be preferable, or at least if the
> current behaviour should be explicitly called out in the function
> documentation.

Looking at the previous way of doing this, we looked at the following
array in descending order : 

[...]
	/* 1G */
	PHY_SETTING(   1000, FULL,   1000baseT_Full		),
	PHY_SETTING(   1000, HALF,   1000baseT_Half		),
	PHY_SETTING(   1000, FULL,   1000baseT1_Full		),
	PHY_SETTING(   1000, FULL,   1000baseX_Full		),
	PHY_SETTING(   1000, FULL,   1000baseKX_Full		),
	/* 100M */
	PHY_SETTING(    100, FULL,    100baseT_Full		),
	PHY_SETTING(    100, FULL,    100baseT1_Full		),
	PHY_SETTING(    100, HALF,    100baseT_Half		),
	PHY_SETTING(    100, HALF,    100baseFX_Half		),
	PHY_SETTING(    100, FULL,    100baseFX_Full		),
[...]

The matching logic was pretty much the same, walk that (and and'ing
with the passed supported modes), note the partial matches, return
either an exact or non-exact match.

None of the logic actually cared about the duplex for non-exact
matches, only the speed. I think we would have faced the same behaviour.

In reality, the case you're mentioning would be a device that supports
1000/Full, 100/Full and 100/Half, user asks for 1000/Half, and 100/Full
would be reported.

That's unlikely to exist, but I'll document it as I've been surprised
in the past with setups that shouldn't exist that actually do :)

All of this really makes me want to add some test scripts to cover all
these corner-case behaviours and test for future regressions.
Hopefully when I get a bit more bandwidth I'll be finally able to
finish the netdevsim PHY support...

Thanks,

Maxime

> /P
>