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]
Date:   Wed, 15 May 2019 16:02:14 +0200
From:   Maxime Chevallier <>
To:     Andrew Lunn <>
Cc:     Florian Fainelli <>,
        Vivien Didelot <>,
        Russell King <>,,
        "" <>,
        Antoine Tenart <>,
        Heiner Kallweit <>
Subject: Re: dsa: using multi-gbps speeds on CPU port

Hi Andrew,

On Wed, 15 May 2019 15:27:01 +0200
Andrew Lunn <> wrote:

>I think you are getting your terminology wrong. 'master' is eth0 in
>the example you gave above. CPU and DSA ports don't have netdev
>structures, and so any PHY used with them is not corrected to a

Ah yes sorry, I'm still in the process of getting familiar with the
internals of DSA :/

>> I'll be happy to help on that, but before prototyping anything, I wanted
>> to have your thougts on this, and see if you had any plans.  
>There are two different issues here.
>1) Is using a fixed-link on a CPU or DSA port the right way to do this?
>2) Making fixed-link support > 1G.
>The reason i decided to use fixed-link on CPU and DSA ports is that we
>already have all the code needed to configure a port, and an API to do
>it, the adjust_link() callback. Things have moved on since then, and
>we now have an additional API, .phylink_mac_config(). It might be
>better to directly use that. If there is a max-speed property, create
>a phylink_link_state structure, which has no reference to a netdev,
>and pass it to .phylink_mac_config().
>It is just an idea, but maybe you could investigate if that would

Ok I see what you mean, this would allow us to get rid of the phydev
built from the fixed-link, and the .adjust_link call. I'll prototype
that, thanks for the hint.

>On the master interface, the armada 8040, eth0, you still need
>something. However, if you look at phylink_parse_fixedlink(), it puts
>the speed etc into a phylink_link_state. It never instantiates a
>fixed-phy. So i think that could be expanded to support higher speeds
>without too much trouble. The interesting part is the IOCTL handler.

Yes I'm not too worried about that part, unless I missed something this
shouldn't be too problematic.

Once again, thanks for your help,


Powered by blists - more mailing lists