Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 12 Sep 2020 18:34:37 -0700 (PDT)
Message-Id: <20200912.183437.1205152743307947529.davem@davemloft.net>
To:     geert@linux-m68k.org
Cc:     hkallweit1@gmail.com, f.fainelli@gmail.com, andrew@lunn.ch,
        kuba@kernel.org, gaku.inami.xh@renesas.com,
        yoshihiro.shimoda.uh@renesas.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "net: linkwatch: add check for netdevice being
 present to linkwatch_do_dev"
From:   David Miller <davem@davemloft.net>
In-Reply-To: <CAMuHMdW0agywTHr4bDO9f_xbQibCxDykdkcAmuRJQO90=E6-Zw@mail.gmail.com>
References: <CAMuHMdUd4VtpOGr26KAmF22N32obNqQzq3tbcPxLJ7mxUtSyrg@mail.gmail.com>
        <20200911.174400.306709791543819081.davem@davemloft.net>
        <CAMuHMdW0agywTHr4bDO9f_xbQibCxDykdkcAmuRJQO90=E6-Zw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sat, 12 Sep 2020 14:33:59 +0200

> "dev" is not the bridge device, but the physical Ethernet interface, which
> may already be suspended during s2ram.

Hmmm, ok.

Looking more deeply NETDEV_CHANGE causes br_port_carrier_check() to run which
exits early if netif_running() is false, which is going to be true if
netif_device_present() is false:

	*notified = false;
	if (!netif_running(br->dev))
		return;

The only other work the bridge notifier does is:

	if (event != NETDEV_UNREGISTER)
		br_vlan_port_event(p, event);

and:

	/* Events that may cause spanning tree to refresh */
	if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP ||
			  event == NETDEV_CHANGE || event == NETDEV_DOWN))
		br_ifinfo_notify(RTM_NEWLINK, NULL, p);

So some vlan stuff, and emitting a netlink message to any available
listeners.

Should we really do all of this for a device which is not even
present?

This whole situation seems completely illogical.  The device is
useless, it logically has no link or other state that can be managed
or used, while it is not present.

So all of these bridge operations should only happen when the device
transitions back to present again.