quoted

devlink has become the standard way for upgrading firmware on complex
network devices, like NICs and TOR switches. That is probably a good
solution here. The problem is, what devlink instance to use. Only a
few MAC drivers are using devlink, so it is unlikely the MAC driver
the PHY is attached to has a devlink instance. Do we create a devlink
instance for the PHY?

Ccing Jakub. I don't think it is good idea to create a devlink instance
per-PHY. However, on the other hand, we have a devlink instance per
devlink linecard now. The devlink linecard however has devlink
representation, which PHY does not have.

Perhaps now is the time to dust-off my devlink components implementation
and use it for PHYs? IDF. Jakub, WDYT.

If we want to make the PHY a component of an existing devlink for a
MAC, we somehow have to find that devlink instance. A PHY is probably
a property of a port, so we can call netdev_to_devlink_port(), which
gives us a way into devlink.

However, the majority of MAC drivers don't have a devlink
instance. What do we do then? Have phylib create the devlink instance
for the MAC driver? That seems very wrong.

Which is why i was thinking the PHY should have its own devlink
instance.

Or we do firmware upgrade some other way.

	Andrew