> It's confusing, I guess these PHY's don't come and go
> very much so the plug/play part isn't really exercised.
Very true. We sometimes need to handle -EPROBE_DEFER, which is not too
different from hot-plugging PHYs. Also, SFP modules are hot-pluggable,
and can contain a copper PHY. However, SFP
On Wed, Jul 11, 2018 at 10:04 PM Andrew Lunn wrote:
> What probably make sense as a followup is add a
> of_phy_disconnect_and_put(). When the module is unloaded, you leak a
> fixed link, because of_phy_deregister_fixed_link() is not being
> called.
I looked at this but I get a bit confused. How
From: Linus Walleij
Date: Wed, 11 Jul 2018 19:45:11 +0200
> By a simple extension of of_phy_get_and_connect() drivers
> that have a fixed link on e.g. RGMII can support also
> fixed links, so in addition to:
>
> ethernet-port {
> phy-mode = "rgmii";
> phy-handle = <&foo>;
> };
>
> T
On Wed, Jul 11, 2018 at 07:45:11PM +0200, Linus Walleij wrote:
> By a simple extension of of_phy_get_and_connect() drivers
> that have a fixed link on e.g. RGMII can support also
> fixed links, so in addition to:
>
> ethernet-port {
> phy-mode = "rgmii";
> phy-handle = <&foo>;
> };
>
By a simple extension of of_phy_get_and_connect() drivers
that have a fixed link on e.g. RGMII can support also
fixed links, so in addition to:
ethernet-port {
phy-mode = "rgmii";
phy-handle = <&foo>;
};
This setup with a fixed-link node and no phy-handle will
now also work just f
