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  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, 9 Dec 2020 23:59:50 +0100
From:   Andrew Lunn <>
To:     Vladimir Oltean <>
Cc:     Tobias Waldekranz <>,,,,,,,,
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

> so basically my point was that I think you are adding a lot of infra
> in core DSA that only mv88e6xxx will use.

That is true already, since mv88e6xxx is currently the only driver
which supports D in DSA. And it has been Marvell devices which
initially inspired the DSA framework, and has pushed it forward. But I
someday expect another vendors switches will get added which also have
a D in DSA concept, and hopefully we can reuse the code. And is
Marvells implementation of LAGs truly unique? With only two drivers
with WIP code, it is too early to say that.

The important thing for me, is that we don't make the API for other
drivers more complex because if D in DSA, or the maybe odd way Marvell
implements LAGs.

One of the long learnt lessons in kernel development. Put complexity
in the core and make drivers simple. Because hopefully you have the
best developers working on the core and they can deal with the
complexity, and typically you have average developers working on
drivers, and they are sometimes stretched getting drivers correct.

Given your work on ocelot driver, does this core code make the ocelot
implementation more difficult? Or just the same?


Powered by blists - more mailing lists