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

[David Daney]

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