On Fri, Jan 31, 2020 at 03:29:06PM +0100, Andrew Lunn wrote: > > > 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
