This copies how other fill APIs are done, in that the responsibility for
filling up the message is deferred to the driver. I think it makes the
API easier to extend: if there ever is richer information available, the
drivers that want to support it just opt in and provide those attributes.

Hi Petr

Actually, if you look at the PHY layer, none of the drivers have
anything to do with netlink messages. Nor does the phylib or phylink
core. It all happens a layer above. I would keep the API to the driver
simple, just ask it for two u32, and do all the netlink conversion in
the core.

    Andrew