wkz
Expose mdio-tools as a library
Hi,
Thank you for the awesome tools! The CLI has been working really well. However, I haven't found a way to easily use the tool from C since it seems like the code is very geared towards the CLI right now. Do you know of an easy way to expose mdio-tools as a library? Our usecase is that we need to update firmware for a PHY and the CLI reads/writes were being fairly slow. Thank you!
Yes, your observation is correct: The code is designed with the CLI as the only consumer in mind. I am hesitant to carve out a library from it, because I do not want support for other devices to end up in various corporate silos.
I would be happy to accept support for your device into mdio-tools, which could then support a custom upgrade operation. That way it would then be available to everyone who might need it.
In order to get decent performance, you would have to translate the firmware binary into an mdio-netlink program, so that you don't have to send/receive a netlink message for every byte.
NOTE: that the current implementation has not been tested with very large programs (if your firmware is large, then your mdio-netlink program will contain many instructions), so I am sure there are many bugs there. Also note that if you split the upgrade into multiple programs, then there is no guarantee that the kernel or another instance of mdio won't access the device in between their executions.
There are a few drivers in the kernel loading firmware via MDIO. It should be possible to follow their example and have a more robust solution in my opinion.
There are a few drivers in the kernel loading firmware via MDIO. It should be possible to follow their example and have a more robust solution in my opinion.
:100:, whenever possible the drivers should solve this via request_firmware().
Alas, this is not always possible. E.g., when you can not get the vendor to include the blob into linux-firmware.
Been there, done that, got the T-shirt: : https://lore.kernel.org/netdev/[email protected]/
Alas, this is not always possible. E.g., when you can not get the vendor to include the blob into linux-firmware.
This is a social limitation I indeed did not consider. In any case I think that, at least technically, maintaining an out-of-tree-patch is better than (ab)using userspace mdio-tools for that.
Sure. Many times it is also the only technically feasible way to do it. In the example I posted above, the PHY did not have a dedicated FLASH and was completely unusable until FW was loaded, so the driver had to do it synchronously from its probe().
For devices with their own FLASHes, which support some kind of online updates, I am not principally opposed to adding such a feature to mdio-tools. Would it be better if an open driver existed that supported it? Sure. Is it better to have an open implementation available than not? I think so.