All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Joakim Zhang <qiangqing.zhang@nxp.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: fec: defer probe if PHY on external MDIO bus is not available
Date: Wed, 03 Nov 2021 12:59:16 +0100	[thread overview]
Message-ID: <77c9849442e7e4a747aebd79747fd88c383c6b57.camel@ew.tq-group.com> (raw)
In-Reply-To: <e8e0f07afbae8333c94c198a20a66a9448c32ce6.camel@ew.tq-group.com>

On Tue, 2021-10-26 at 13:54 +0200, Matthias Schiffer wrote:
> On Fri, 2021-10-22 at 14:56 +0200, Andrew Lunn wrote:
> > > Hmm, lots of network drivers? I tried to find an example, but all
> > > drivers that generate -EPROBE_DEFER for missing PHYs at all don't have
> > > an internal MDIO bus and thus avoid the circular dependency.
> > 
> > Try drivers/net/dsa.
> > 
> > These often have mdio busses which get registered and then
> > unregistered. There are also IRQ drivers which do the same.
> > 
> > 	Andrew
> 
> 
> All drivers I looked at were careful to register the MDIO bus in the
> last part of the probe function, so that the only errors that could 
> happen after that (and thus require to unregister the bus device again)
> would not be -EPROBE_DEFER.
> 
> The documented infinite loop is easy to reproduce: You just need two
> separate device instances with misbehaving probe() functions that
> return -EPROBE_DEFER after registering and unregistering some
> subdevice. If the missing device that causes the deferral never appears
> (for example because its driver is not available), the two devices will
> be probed ad infinitum.
> 
> I agree with the documentation that a driver should not do this, and
> thus we need another way to deal with the cyclic dependency between an
> Ethernet interface and a PHY on its internal MDIO bus.
> 
> While I think that a generic solution would be theoretically possible
> by ensuring that the probing loop makes some kind of "progress", I
> think this would set a precedent for "expensive" operations happening
> before a -EPROBE_DEFER return, which should be avoided even when no
> infinite loop results.
> 
> Matthias

Does anyone have a suggestion how to proceed with this issue?


      reply	other threads:[~2021-11-03 11:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 11:30 [PATCH] net: fec: defer probe if PHY on external MDIO bus is not available Matthias Schiffer
2021-10-18 10:20 ` Joakim Zhang
2021-10-18 10:32   ` Matthias Schiffer
2021-10-19 14:12 ` Andrew Lunn
2021-10-20 12:03   ` Matthias Schiffer
2021-10-20 18:50     ` Andrew Lunn
2021-10-21  7:08       ` (EXT) " Matthias Schiffer
2021-10-21 12:50         ` Andrew Lunn
2021-10-22  7:57           ` Matthias Schiffer
2021-10-22 12:56             ` Andrew Lunn
2021-10-26 11:54               ` Matthias Schiffer
2021-11-03 11:59                 ` Matthias Schiffer [this message]

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=77c9849442e7e4a747aebd79747fd88c383c6b57.camel@ew.tq-group.com \
    --to=matthias.schiffer@ew.tq-group.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=qiangqing.zhang@nxp.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.