> 'Update firmware operation' will take long time, maybe more than > 10s. If user use 'ethtool -f' to update firmware, and ^C before done? > If ^C before mucse_write_mbx, return as soon as possible. If after mucse_write_mbx, > wait until fw true response. And what happens if the firmware writing is interrupted? Could you end up with a brick? This is actually one of the operations i would not expect to be able to ^C. You might also want consider devlink flash. https://www.kernel.org/doc/html/latest/networking/devlink/devlink-flash.html It replaces the older ethtool-flash mechanism, and doesn’t require taking any networking locks in the kernel to perform the flash update. I assume this is meaning ethtool take RTNL, and while that is held, no other network configuration can be performed on any interface. devlink has its own lock so avoids this. Andrew
