[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rq9ki2$uqk$1@ciao.gmane.io>
Date: Thu, 3 Dec 2020 03:03:30 -0000 (UTC)
From: Grant Edwards <grant.b.edwards@...il.com>
To: netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY
On 2020-12-02, Andrew Lunn <andrew@...n.ch> wrote:
>>> So it will access the MDIO bus of the PHY that is attached to the
>>> MAC.
>>
>> If that's the case, wouldn't the ioctl() calls "just work" even when
>> only the fixed-phy mdio bus and fake PHY are declared in the device
>> tree?
>
> The fixed-link PHY is connected to the MAC. So the IOCTL calls will be
> made to the fixed-link fake MDIO bus.
Ah! When you said "the PHY that is attached to the MAC" above, I
thought you meant electrically attached to the MAC via the mdio bus.
Then how does Forian Fainelli's solution below work? Won't the first
phy found be the fixed one, and then the ioctl() calls will use the
fixed-link bus?
Florian Fainelli wrote:
>>> You should be able to continue having the macb MDIO bus controller be
>>> registered with no PHY/MDIO devices represented in Device Tree such that
>>> user-space can continue to use it for ioctl() *and* you can point the
>>> macb node to a fixed PHY for the purpose of having fixed link parameters.
>>>
>>> There are various drivers that support exactly this mode of operation
>>> where they use a fixed PHY for the Ethernet MAC link parameters, yet
>>> their MDIO bus controller is used to interface with other devices such
>>> as Ethernet switches over MDIO. Example of drivers supporting that are
>>> stmmac, fec, mtk_star_emac and ag71xx. The way it ends up looking like
>>> in Device Tree is the following:
>>>
>>> ð0 {
>>> fixed-link {
>>> speed = <1000>;
>>> full-duplex;
>>> };
>>>
>>> mdio {
>>> phy0: phy@0 {
>>> reg = <0>;
>>> };
>>> };
>>> };
Powered by blists - more mailing lists