linux-kernel.vger.kernel.org archive mirror
 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: Tue, 26 Oct 2021 13:54:29 +0200	[thread overview]
Message-ID: <e8e0f07afbae8333c94c198a20a66a9448c32ce6.camel@ew.tq-group.com> (raw)
In-Reply-To: <YXK1E9LLDCfajzmR@lunn.ch>

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


  reply	other threads:[~2021-10-26 11:54 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 [this message]
2021-11-03 11:59                 ` Matthias Schiffer

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=e8e0f07afbae8333c94c198a20a66a9448c32ce6.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 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).