On Fri, Jan 31, 2020 at 03:29:06PM +0100, Andrew Lunn wrote:

quoted

quoted

But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters.  They are physical and logical devices that can adapt to
what is plugged into them.  How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity.

Apologies - I was under the impression that SFP and friends were a
physical-layer thing and that a MAC in the SoC would still be fixed such
that its DMA and interrupt configuration could be statically described
regardless of what transceiver was plugged in (even if some configurations
might not use every interrupt/stream ID/etc.) If that isn't the case I shall
go and educate myself further.

It gets interesting with QSFP cages. The Q is quad, there are 4 SERDES
lanes. You can use them for 1x 40G link, or you can split them into 4x
10G links. So you either need one MAC or 4 MACs connecting to the
cage, and this can change on the fly when a modules is ejected and
replaced with another module. There are only one set of control pins
for i2c, loss of signal, TX disable, module inserted. So where the
interrupt/stream ID/etc are mapped needs some flexibility.

There is also to some degree a conflict with hiding all this inside
firmware. This is complex stuff. It is much better to have one core
implementing in Linux plus some per hardware driver support, than
having X firmware blobs, generally closed source, each with there own
bugs which nobody can fix.

Devicetree to the rescue!

Entertaining the use of ACPI without any firmware abstraction for this
hardware really feels like a square peg / round hole situation, so I'm
assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who
is it and can you tell them to bog off?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel