Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 08/22/2017 08:39 AM, Chen-Yu Tsai wrote:
> On Mon, Aug 21, 2017 at 10:23 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>>> All muxes are mostly always represented the same way afaik, or do you
>>> want to simply introduce a new compatible / property?
>>
>> +         mdio-mux {
>> +               compatible = "allwinner,sun8i-h3-mdio-switch";
>> +               mdio-parent-bus = <&mdio_parent>;
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               internal_mdio: mdio@1 {
>>                         reg = <1>;
>> -                       clocks = <&ccu CLK_BUS_EPHY>;
>> -                       resets = <&ccu RST_BUS_EPHY>;
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>> +                       int_mii_phy: ethernet-phy@1 {
>> +                               compatible = "ethernet-phy-ieee802.3-c22";
>> +                               reg = <1>;
>> +                               clocks = <&ccu CLK_BUS_EPHY>;
>> +                               resets = <&ccu RST_BUS_EPHY>;
>> +                               phy-is-integrated;
>> +                       };
>> +               };
>> +               mdio: mdio@0 {
>> +                       reg = <0>;
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>>                 };
>>
>> Hi Maxim
>>
>> Anybody who knows the MDIO-mux code/binding, knows that it is a run
>> time mux. You swap the mux per MDIO transaction. You can access all
>> the PHY and switches on the mux'ed MDIO bus.
>>
>> However here, it is effectively a boot-time MUX. You cannot change it
>> on the fly. What happens when somebody has a phandle to a PHY on the
>> internal and a phandle to a phy on the external? Does the driver at
>> least return -EINVAL, or -EBUSY? Is there a representation which
>> eliminates this possibility?
> 
> There is only one controller. Either you use the internal PHY, which
> is then directly coupled (no magnetics needed) to the RJ45 port, or
> you use an external PHY over MII/RMII/RGMII. You could supposedly
> have both on a board, and let the user choose one. But why bother
> with the extra complexity and cost? Either you use the internal PHY
> at 100M, or an external RGMII PHY for gigabit speeds.

I agree, there is no point in over-engineering any of this. I don't
think there is actually any MDIO mux per-se in that the MDIO clock and
data lines are muxed, however there has to be some kind of built-in port
multiplexer that lets you chose between connecting to the internal PHY
and any external PHY/MAC, but that is not what a "mdio-mux" node represents.

> 
> So I think what you are saying is either impossible or engineering-wise
> a very stupid design, like using an external MAC with a discrete PHY
> connected to the internal MAC's MDIO bus, while using the internal MAC
> with the internal PHY.
> 
> Now can we please decide on something? We're a week and a half from
> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
> nodes (internal-mdio & external-mdio).

I really don't see a need for a mdio-mux in the first place, just have
one MDIO controller (current state) sub-node which describes the
built-in STMMAC MDIO controller and declare the internal PHY as a child
node (along with 'phy-is-integrated'). If a different configuration is
used, then just put the external PHY as a child node there.

If fixed-link is required, the mdio node becomes unused anyway.

Works for everyone?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html