Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1356156

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

From Florian Fainelli <f.fainelli@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 1/3] net: thunderx: Cleanup PHY probing code.
Date 2016-03-11 20:40 +0100
Message-ID <rbB4K-2v3-23@gated-at.bofh.it> (permalink)
References (2 earlier) <rbzcC-1f1-15@gated-at.bofh.it> <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>
Organization linux.* mail to news gateway

Show all headers | View raw


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?

> 
> The generic driver should probably have a black list for such devices.
> This is a PHY issue, not an MDIO issue, and the problem should be
> solved in the PHY layer, not in one MDIO driver.

I considered the possibility once of disabling the generic PHY driver,
such that systems where the vendor-specific PHY driver is expected to be
used could utilize that. That does not play well with the fixed PHYs
using the generic PHY driver though, anyway, I am digressing.

> 
> We should also consider what happens when somebody actually writes a
> driver for this PHY. Are you not going to use it?
> 
> Before this patchset, you did not special case this compatible
> string. So at the very least, you need to split this into a separate
> patch, so the maintainers can ACK/NACK it, independent of the other
> change it is embedded in.
> 
>        Andrew
> 


-- 
Florian

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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