> 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.
> 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.
Andrew
