netdev - Re: dsa: using multi-gbps speeds on CPU port

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: <20190515160214.1aa5c7d9@bootlin.com>
Date:   Wed, 15 May 2019 16:02:14 +0200
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: dsa: using multi-gbps speeds on CPU port

Hi Andrew,

On Wed, 15 May 2019 15:27:01 +0200
Andrew Lunn <andrew@...n.ch> 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.

>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,

Maxime