> 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?
Andrew
