Hi Vladimir,

On 8/19/21 1:22 PM, Vladimir Oltean wrote:

Sorry for the delay, I wanted to reconfirm what I said (hint, I was wrong).

Thanks for the clarification. It also lines up with Saravana's analysis 
for my case.

In my case, whatever I do, I cannot get the driver core enforce a device
link between the ethernet-switch and the PHY.

So I cannot actually see the same issue. What I was seeing was in fact
stupid testing on my part (it was working with the PHY driver as
built-in, it was working, then I made it a module, it broke, I forgot to
switch it back to module, then I thought it's broken while the PHY is
built-in).

Do you mean to say that you are hitting the "case (1)" that Saravana 
described? See below:

On 8/19/21 5:28 AM, Saravana Kannan wrote:

The main problem is that the parent device switch seems to be assuming
it's child/grandchild devices (mdiobus/PHYs) will have probed
successfully as soon as they are added. This assumption is not true
and can be broken for multiple reasons such as:

1. The driver for the child devices (PHYs in this case) could be
loaded as a module after the parent (switch) is probed. So when the
devices are added, the PHYs would not be probed.
2. The child devices could defer probe because one of their suppliers
isn't ready yet. Either because of fw_devlink=on or the framework
itself returning -EPROBE_DEFER.
3. The child devices could be getting probed asynchronously. So the
device_add() would kick off a thread to probe the child devices in a
separate thread.

I would think that - in general - it should not matter if the PHY driver 
is built as a module.

Kind regards,
Alvin