On Mon, Jun 23, 2025 at 02:48:53PM -0400, Sean Anderson wrote:

On 6/23/25 14:27, Andrew Lunn wrote:

quoted

On Mon, Jun 23, 2025 at 11:16:08AM -0400, Sean Anderson wrote:

quoted

On 6/21/25 03:33, Andrew Lunn wrote:

quoted

On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote:

quoted

Returning EPROBE_DEFER after probing a bus may result in an infinite
probe loop if the EPROBE_DEFER error is never resolved.

That sounds like a core problem. I also thought there was a time
limit, how long the system will repeat probes for drivers which defer.

This seems like the wrong fix to me.

I agree. My first attempt to fix this did so by ignoring deferred probes
from child devices, which would prevent "recursive" loops like this one
[1]. But I was informed that failing with EPROBE_DEFER after creating a
bus was not allowed at all, hence this patch.

O.K. So why not change the order so that you know you have all the
needed dependencies before registering the MDIO bus?

Quoting your previous email:

quoted

Returning EPROBE_DEFER after probing a bus may result in an infinite
probe loop if the EPROBE_DEFER error is never resolved. For example,
if the PCS is located on another MDIO bus and that MDIO bus is
missing its driver then we will always return EPROBE_DEFER.

Why not get a reference on the PCS device before registering the MDIO
bus?

Because the PCS may be on the MDIO bus. This is probably the most-common
case.

So you are saying the PCS is physically there, but the driver is
missing because of configuration errors? Then it sounds like a kconfig
issue?

Or are you saying the driver has been built but then removed from
/lib/modules/

	Andrew