netdev - Re: No traffic with Marvell switch and latest linux-next

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]

Date:   Sun, 24 Feb 2019 18:04:55 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next

> The added difficulty here and the reason why Andrew went with the
> approach that is used by the code currently is because neither do the
> CPU or DSA ports are backed by a net_device. It is somewhere on my TODO
> to permit the use of PHYLINK without the need of a net_device to cover
> those specific DSA cases unless we just brute force the whole thing and
> allocate a net_device structure but not register that net_device? Yes in
> fact, why don't we do that?

Hi Florian

At the moment, we are using a phydev which is not connected to a
MAC. That is rather odd, but the phylib maintainers mostly know about
this, and keep an eye out for changes which might break any
assumptions. And the phylib API is quite small.

How many assumptions are going to break with a netdev which is not
registered? The API is much bigger, more people hack on it, and it is
going to be much harder to review changes to make sure assumptions are
not changed.

If we are going to do something odd, we should keep the scope as small
as possible.

   Andrew