All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.