> I'm assuming it is some sort of firmware functionality that is needed > to enable it? One thing with our design is that the firmware actually > has minimal functionality. Basically it is the liaison between the > BMC, Host, and the MAC. Otherwise it has no role to play in the > control path so when the driver is loaded it is running the show. Which i personally feel is great. In an odd way, this to me indicates this is a commodity product, or at least, leading the way towards commodity 100G products. Looking at the embedded SoC NIC market, which pretty is much about commodity, few 1G Ethernet NICs have firmware. Most 10G NICs also have no firmware. Linux is driving the hardware. Much of the current Linux infrastructure is limited to 10G, because currently everything faster than that hides away in firmware, Linux does not get to driver it. This driver could help push Linux controlling the hardware forward, to be benefit of us all. It would be great if this driver used phylink to manage the PCS and the SFP cage, that the PCS code is moved into drivers/net/pcs, etc. Assuming this PCS follows the standards, it would be great to add helpers like we have for clause 37, clause 73, to help support other future PCS drivers which will appear. 100G in SoCs is probably not going to appear too soon, but single channel 25G is probably the next step after 10G. And what is added for this device will probably also work for 25G. 40G via 4 channels is probably not too far away either. Our Linux SFP driver is also currently limited to 10G. It would be great if this driver could push that forwards to support faster SFP cages and devices, support splitting and merging, etc. None of this requires new kAPIs, they all already exist. There is nothing controversial here. Everything follows standards. So if Meta were to abandon the MAC driver, it would not matter, its not dead infrastructure code, future drivers would make use of it, as this technology becomes more and more commodity. Andrew
