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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190125202535.50d5b402@nic.cz>
Date:   Fri, 25 Jan 2019 20:25:35 +0100
From:   Marek Behun <marek.behun@....cz>
To:     Florian Fainelli <f.fainelli@...il.com>
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 Fri, 25 Jan 2019 10:48:38 -0800
Florian Fainelli <f.fainelli@...il.com> wrote:

> 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);

But in the dts there would still have to be speed=<1000>; otherwise
swphy will fail...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ