Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code.

From: David Daney
Date: Fri Mar 11 2016 - 15:56:16 EST

On 03/11/2016 11:37 AM, Florian Fainelli wrote:
On 11/03/16 11:06, Andrew Lunn wrote:
I don't see why it should wait around forever. I have boards with
Marvell PHYs, yet if i don't build the Marvell driver, the Ethernet
driver still loads, because the generic PHY driver is used instead.
Why does this not work here?

As I said before, there is no driver for the device, so
of_phy_find_device() will always return NULL.

I'm not yet convinced this is true. I really do expect that the
generic PHY driver will bind to it. It might then go horribly wrong,
because it is not standard compliant, but that is a different issue.

I concur with Andrew here, unless the PHY is guaranteed to return
garbage when get_phy_id() is called, there is a good chance that the
Generic PHY driver will be bound to this PHY device, or this is not
happening for you for some reason?

get_phy_id() is working a designed.

For this phy, we have:

compatible = "cortina,cs4223-slice";

Therefore get_phy_id() is being called with a is_c45 value of false.

get_phy_id() is returning a value of 0, which means that it succeeds, but the returned phy_id is 0xffffffff, which causes get_phy_device() to not create a phy_device, and no driver can be bound.

I know you are all skeptical, but I really think the best thing to do is not try to attach a phy driver when this compatible value is encountered.

It is a defective device tree, and I am attempting to handle it in the specific site where it can cause problems.

We are trying to distinguish between these two cases:

- of_phy_find_device() returns NULL because driver is not yet bound

- of_phy_find_device() returns NULL because "cortina,cs4223-slice"

I don't think we need to build some sort of frame work to handle things like this in a general way.

David Daney