netdev - Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Jan 2019 10:48:38 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Marek Behun <marek.behun@....cz>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to
 1000BaseX only on 6390X

On 1/24/19 11:39 AM, Marek Behun wrote:
> On Thu, 24 Jan 2019 11:27:54 -0800
> Florian Fainelli <f.fainelli@...il.com> wrote:
> 
>> On 1/24/19 11:24 AM, Marek Behun wrote:
>>> On Thu, 24 Jan 2019 19:11:59 +0100
>>> Andrew Lunn <andrew@...n.ch> wrote:
>>>   
>>>> On Thu, Jan 24, 2019 at 07:04:51PM +0100, Marek Behun wrote:  
>>>>> What properties does the cpu port node need to contain to force
>>>>> it? phy-mode = "2500base-x"; is not enough.    
>>>>
>>>> Hi Marek
>>>>
>>>> For DSA ports we have:
>>>>
>>>>                                                 phy-mode =
>>>> "rgmii-txid"; fixed-link {
>>>>                                                         speed =
>>>> <1000>; full-duplex;
>>>>                                                 };
>>>>
>>>> See dsa_port_fixed_link_register_of()
>>>>
>>>>     Andrew  
>>>
>>> Hi Andrew,
>>> the configuration
>>>   phy-mode = "2500base-x";
>>>   fixed-link {
>>>     speed = <2500>;
>>>     full-duplex;
>>>   };
>>> does not work, because swphy does not support speed=2500 (only 10,
>>> 100 and 1000).
>>>   managed = "in-band-status";
>>> does not work either.
>>>
>>> If I use speed = <1000>, then the swphy is created correctly, cmode
>>> is set correctly to 2500base-x, but speed register on the port is
>>> set to 1000, and the connection does not work.
>>>
>>> The easiest way would probably be to implement swphy to support
>>> speed 2500. But I don't know what values should the simulated PHY
>>> registers contain...
>>>
>>> The function dsa_port_fixed_link_register_of creates this phy
>>> device, adjusts the link and then calls
>>> put_device(&phydev->mdio.dev); Does this mean that the phy device
>>> is immediately destroyed?  
>>
>> Yes, we should actually migrate that code over to PHYLINK, because in
>> PHYLINK the fixed links don't require creating a phy_device instance.
>> This is something that has a potential of breaking a lot of people,
>> so I have not really started doing it just yet :)
> 
> Can't then this patch be applied so that Turris Mox will work again? At
> least till the cpu/dsa port connection is converted to phylink.

How about the following hack until we can support netdev less PHYLINK
instances while having the Device Tree being corrected to have the
correct phy-mode = "2500base-x" property since we will need it for
PHYLINK on CPU/DSA ports later on:

diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..9ea052c30b68 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -359,6 +359,14 @@ static int dsa_port_fixed_link_register_of(struct
dsa_port *dp)
        if (mode < 0)
                mode = PHY_INTERFACE_MODE_NA;
        phydev->interface = mode;
+       switch (mode) {
+       case PHY_INTERFACE_MODE_2500BASEX:
+               phydev->speed = SPEED_2500;
+               break;
+       case PHY_INTERFACE_MODE_10GKR:
+               phydev->speed = SPEED_10000;
+               break;
+       }

        genphy_config_init(phydev);
        genphy_read_status(phydev);
-- 
Florian