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

Maxime Chevallier
2025-06-06T08:19:36Z

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
>