From: Helmut Grohne <helmut.grohne@intenta.de>
To: David Miller <davem@davemloft.net>
Cc: "andrew@lunn.ch" <andrew@lunn.ch>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"kuba@kernel.org" <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"woojung.huh@microchip.com" <woojung.huh@microchip.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>
Subject: Re: [PATCH] net: phy: phy_remove_link_mode should not advertise new modes
Date: Wed, 15 Jul 2020 09:03:45 +0200 [thread overview]
Message-ID: <20200715070345.GA3452@laureti-dev> (raw)
In-Reply-To: <20200714.140710.213288407914809619.davem@davemloft.net>
On Tue, Jul 14, 2020 at 11:07:10PM +0200, David Miller wrote:
> From: Helmut Grohne <helmut.grohne@intenta.de>
> Date: Tue, 14 Jul 2020 10:25:42 +0200
>
> > When doing "ip link set dev ... up" for a ksz9477 backed link,
> > ksz9477_phy_setup is called and it calls phy_remove_link_mode to remove
> > 1000baseT HDX. During phy_remove_link_mode, phy_advertise_supported is
> > called.
> >
> > If one wants to advertise fewer modes than the supported ones, one
> > usually reduces the advertised link modes before upping the link (e.g.
> > by passing an appropriate .link file to udev). However upping
> > overrwrites the advertised link modes due to the call to
> > phy_advertise_supported reverting to the supported link modes.
> >
> > It seems unintentional to have phy_remove_link_mode enable advertising
> > bits and it does not match its description in any way. Instead of
> > calling phy_advertise_supported, we should simply clear the link mode to
> > be removed from both supported and advertising.
>
> The problem is that we can't allow the advertised setting to exceed
> what is in the supported list.
>
> That's why this helper is coded this way from day one.
Would you mind going into a little more detail here?
I think you have essentially two possible cases with respect to that
assertion.
Case A: advertised does not exceed supported before the call to
phy_remove_link_mode.
In this case, the relevant link mode is removed from both supported
and advertised after my patch and therefore the requested invariant
is still ok.
Case B: advertised exceeds supported prior to the call to
phy_remove_link_mode.
You said that we cannot allow this to happen. So it would seem to be
a bug somewhere else. Do you see phy_remove_link_mode as a tool to
fix up a violated invariant?
It also is not true that the current code ensures your assertion.
Specifically, phy_advertise_supported copies the pause bits from the old
advertised to the new one regardless of whether they're set in
supported. I believe this is expected, but it means that your invariant
needs to be:
We cannot allow advertised to exceed the supported list for
non-pause bits.
In any case, having a helper called "phy_remove_link_mode" enable bits
in the advertised bit field is fairly unexpected. Do you disagree with
this being a bug?
Helmut
next prev parent reply other threads:[~2020-07-15 7:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 8:25 [PATCH] net: phy: phy_remove_link_mode should not advertise new modes Helmut Grohne
2020-07-14 21:07 ` David Miller
2020-07-15 7:03 ` Helmut Grohne [this message]
2020-07-15 18:20 ` Jakub Kicinski
2020-07-15 19:01 ` Andrew Lunn
2020-07-15 18:51 ` Andrew Lunn
2020-07-15 19:27 ` Andrew Lunn
2020-07-16 12:57 ` [PATCH v2] net: dsa: microchip: call phy_remove_link_mode during probe Helmut Grohne
2020-07-16 14:10 ` Andrew Lunn
2020-07-17 8:18 ` Helmut Grohne
2020-07-17 13:18 ` Andrew Lunn
2020-07-20 9:04 ` [PATCH v3] " Helmut Grohne
2020-07-20 20:43 ` Andrew Lunn
2020-07-21 11:07 ` [PATCH v4] " Helmut Grohne
2020-07-21 15:20 ` Andrew Lunn
2020-07-21 22:50 ` David Miller
2020-07-20 21:04 ` [PATCH v3] " Andrew Lunn
2020-07-21 7:38 ` Helmut Grohne
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=20200715070345.GA3452@laureti-dev \
--to=helmut.grohne@intenta.de \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.com \
--cc=woojung.huh@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.