On Wed, Apr 10, 2024 at 3:37 PM Andrew Lunn <andrew@xxxxxxx> wrote: > > > Well I was referring more to the data path level more than the phy > > configuration. I suspect different people have different levels of > > expectations on what minimal firmware is. With this hardware we at > > least don't need to use firmware commands to enable or disable queues, > > get the device stats, or update a MAC address. > > > > When it comes to multi-host NICs I am not sure there are going to be > > any solutions that don't have some level of firmware due to the fact > > that the cable is physically shared with multiple slots. > > This is something Russell King at least considered. I don't really > know enough to know why its impossible for Linux to deal with multiple > slots. It mostly has to do with the arbitration between them. It is a matter of having to pass a TON of info to the individual slice and then the problem is it would have to do things correctly and not manage to take out it's neighbor or the BMC. > > I am assuming we still want to do the PCS driver. So I will still see > > what I can do to get that setup. > > You should look at the API offered by drivers in drivers/net/pcs. It > is designed to be used with drivers which actually drive the hardware, > and use phylink. Who is responsible for configuring and looking at the > results of auto negotiation? Who is responsible for putting the PCS > into the correct mode depending on the SFP modules capabilities? > Because you seemed to of split the PCS into two, and hidden some of it > away, i don't know if it makes sense to try to shoehorn what is left > into a Linux driver. We have control of the auto negotiation as that is north of the PMA and is configured per host. We should support clause 73 autoneg. Although we haven't done much with it as most of our use cases are just fixed speed setups to the switch over either 25G-CR1, 50G-CR2, 50G-CR1, or 100G-CR2. So odds are we aren't going to be doing anything too terribly exciting. As far as the QSFP setup the FW is responsible for any communication with it. I suspect that the expectation is that we aren't going to need much in the way of config since we are just using direct attach cables. So we are the only one driving the PCS assuming we aren't talking about power-on init where the FW is setting up for the BMC to have access. We will have to see. The PCS drivers in that directory mostly make sense to me and don't look like too much of a departure from my current code. It will just be a matter of splitting up the fbnic_mac.c file and adding the PCS logic as a separate block, or at least I hope that is all that is mostly involved. Probably take me a week or two to get it coded up and push out the v2.
