Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1356182
| From | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. |
| Date | 2016-03-11 22:00 +0100 |
| Message-ID | <rbCka-3or-7@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <rbzFE-1Ep-17@gated-at.bofh.it> <rbzFE-1Ep-15@gated-at.bofh.it> <rbABI-2hR-25@gated-at.bofh.it> <rbABI-2hR-23@gated-at.bofh.it> <rbB4K-2v3-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/3] net/phy: Improvements to Cavium Thunder MDIO code. David Daney <ddaney.cavm@gmail.com> - 2016-03-11 17:50 +0100
[PATCH 1/3] net: thunderx: Cleanup PHY probing code. David Daney <ddaney.cavm@gmail.com> - 2016-03-11 17:50 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. Andrew Lunn <andrew@lunn.ch> - 2016-03-11 18:40 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. Andrew Lunn <andrew@lunn.ch> - 2016-03-11 19:10 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. Andrew Lunn <andrew@lunn.ch> - 2016-03-11 20:10 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. Florian Fainelli <f.fainelli@gmail.com> - 2016-03-11 20:40 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. David Daney <ddaney.cavm@gmail.com> - 2016-03-11 22:00 +0100
Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code. Andrew Lunn <andrew@lunn.ch> - 2016-03-11 22:40 +0100
[PATCH 3/3] phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses. David Daney <ddaney.cavm@gmail.com> - 2016-03-11 17:50 +0100
[PATCH 2/3] phy: mdio-octeon: Refactor into two files/modules David Daney <ddaney.cavm@gmail.com> - 2016-03-11 17:50 +0100
csiph-web