netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: netdev <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	John Crispin <john@phrozen.org>,
	Bryan.Whitehead@microchip.com
Subject: Re: [RFC PATCH 12/16] dsa: Make mdio bus optional
Date: Fri, 27 May 2016 17:18:51 +0200	[thread overview]
Message-ID: <20160527151851.GD20214@lunn.ch> (raw)
In-Reply-To: <87inxz5z4e.fsf@ketchup.mtl.sfl>

On Fri, May 27, 2016 at 10:55:45AM -0400, Vivien Didelot wrote:
> Hi Andrew,
> 
> Andrew Lunn <andrew@lunn.ch> writes:
> 
> > -	mdiobus_unregister(ds->slave_mii_bus);
> > +	if (ds->slave_mii_bus && ds->drv->phy_read)
> > +		mdiobus_unregister(ds->slave_mii_bus);
> 
> So if a driver registered the slave MII bus itself, it may have
> unregistered it itself as well, so checking ds->slave_mii_bus is OK
> (assuming the driver correctly zero'ed it).
> 
> But is it necessary to check ds->drv->phy_read?

It makes the code symmetrical to the register code, which makes the
same check. My experience is that keeping the code symmetrical results
in less surprises late on.

One such surprise could be a driver that does not zero
ds->slave_mii_bus. In fact, mv88e6xxx does not zero it. So we would
get a double unregister happening. We also don't want the core
unregistering it, since we have other cleanup work to do, we have an
of_node_put() to call.

	Andrew

  reply	other threads:[~2016-05-27 15:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27  1:20 [RFC PATCH 00/16] New DSA bind, switches as devices Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 01/16] dsa: slave: chip data is optional, don't dereference NULL Andrew Lunn
2016-05-27 18:45   ` Vivien Didelot
2016-05-27 21:24     ` Florian Fainelli
2016-05-27  1:20 ` [RFC PATCH 02/16] net: dsa: mv88e6xxx: fix circular lock in PPU work Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 03/16] dsa: slave: Remove MDIO address from switch MDIO bus name Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 04/16] dsa: tag_{e}dsa.c: Remove dependency on platform data Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 05/16] dsa: Add a ports structure and use it in the switch structure Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 06/16] dsa: Move port device node into port structure Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 07/16] dsa: Remove dynamic allocate of routing table Andrew Lunn
2016-05-27 18:54   ` Vivien Didelot
2016-05-27  1:20 ` [RFC PATCH 08/16] dsa: Copy the routing table into the switch structure Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 09/16] dsa: dsa: Split up creating/destroying of DSA and CPU ports Andrew Lunn
2016-05-27 14:33   ` Vivien Didelot
2016-05-27 15:07     ` Andrew Lunn
2016-05-27 16:36       ` Vivien Didelot
2016-05-27 19:25   ` Vivien Didelot
2016-05-27 20:01     ` Andrew Lunn
2016-05-27 20:29     ` Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 10/16] net: dsa: mv88e6xxx: Only support EDSA tagging Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 11/16] net: dsa: Refactor selection of tag ops into a function Andrew Lunn
2016-05-27 19:35   ` Vivien Didelot
2016-05-27 20:11     ` Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 12/16] dsa: Make mdio bus optional Andrew Lunn
2016-05-27 14:55   ` Vivien Didelot
2016-05-27 15:18     ` Andrew Lunn [this message]
2016-05-27 16:38       ` Vivien Didelot
2016-05-27  1:20 ` [RFC PATCH 13/16] net: dsa: mv88e6xxx: Refactor MDIO so driver registers mdio bus Andrew Lunn
2016-05-27 19:45   ` Vivien Didelot
2016-05-27  1:20 ` [RFC PATCH 14/16] net: dsa: Add new binding implementation Andrew Lunn
2016-05-27 20:39   ` Vivien Didelot
2016-05-27 20:57     ` Andrew Lunn
2016-05-27 21:29       ` Florian Fainelli
2016-05-28  8:23         ` Richard Cochran
2016-05-27  1:20 ` [RFC PATCH 15/16] arm: dt: vf610-zii-devel-b: Make use of new DSA binding Andrew Lunn
2016-05-27  1:20 ` [RFC PATCH 16/16] dsa: Document new binding Andrew Lunn
2016-05-27 18:30 ` [RFC PATCH 00/16] New DSA bind, switches as devices Vivien Didelot

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=20160527151851.GD20214@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Bryan.Whitehead@microchip.com \
    --cc=f.fainelli@gmail.com \
    --cc=john@phrozen.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).