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:   Wed, 15 May 2019 09:09:26 -0700
From:   Florian Fainelli <>
To:     Maxime Chevallier <>,
        Andrew Lunn <>
Cc:     Vivien Didelot <>,
        Russell King <>,,
        "" <>,
        Antoine Tenart <>,
        Heiner Kallweit <>,
        Vladimir Oltean <>
Subject: Re: dsa: using multi-gbps speeds on CPU port

On 5/15/19 7:02 AM, Maxime Chevallier wrote:
> 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
>> netdev.
> 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
>> work.
> 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.

Vladimir mentioned a few weeks ago that he is considering adding support
for PHYLIB and PHYLINK to run without a net_device instance, you two
should probably coordinate with each other and make sure both of your
requirements (which are likely the same) get addressed.

Powered by blists - more mailing lists