On Sat, Apr 6, 2024 at 9:49 AM Andrew Lunn <andrew@xxxxxxx> wrote: > > > 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 As far as the MAC/PCS code goes I will have to see what I can do. I think I have to check with our sourcing team to figure out what contracts are in place for whatever IP we are currently using before I can share any additional info beyond the code here. One other complication I can think of in terms of switching things over as you have requested is that we will probably need to look at splitting up the fbnic_mac.c file as it is currently used for both the UEFI driver and the Linux driver so I will need to have a solution for the UEFI driver which wouldn't have the advantage of phylink. Thanks, - Alex
