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.