[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUnI5JnKHLW05/Ux@lunn.ch>
Date: Tue, 21 Sep 2021 13:58:28 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Wolfram Sang <wsa@...nel.org>, linux-i2c@...r.kernel.org,
Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
Alvin Šipraga <alsi@...g-olufsen.dk>,
Lino Sanfilippo <LinoSanfilippo@....de>
Subject: Re: [PATCH net 1/2] net: dsa: don't allocate the slave_mii_bus using
devres
> I _could_ imagine using devres because the condition used on remove is
> different than the condition used on probe. So strictly speaking, DSA
> cannot determine whether the ds->slave_mii_bus it sees on remove is the
> ds->slave_mii_bus that _it_ has allocated on probe. Using devres would
> have solved that problem. But nonetheless, the existing code already
> proceeds to unregister the MDIO bus, even though it might be
> unregistering an MDIO bus it has never registered. So I can only guess
> that no driver that implements ds->ops->phy_read also allocates and
> registers ds->slave_mii_bus itself.
That should not happen. It should be either/or.
But there is no enforcement of that.
Reviewed-by: Andrew Lunn <andrew@...n.ch>
Andrew
Powered by blists - more mailing lists