On Sun, 28 May 2017 10:26:49 +0300, Yotam Gigi wrote: > On 05/23/2017 06:38 PM, David Miller wrote: > > From: Yotam Gigi <yot...@mellanox.com> > > Date: Tue, 23 May 2017 18:14:15 +0300 > > > >> Sorry, I am not sure I understand. You think that drivers should not > >> implement > >> ethtool's flash_device callback anymore? do you have an alternative for > >> firmware > >> flash? > > As stated, export an MTD device. > > So, after we have been going over MTD, it seems like it does not fit our needs > at all. > > MTD device provides (erasable-)block access to a flash storage, where in our > case the firmware burn process is just pouring a binary BLOB into the device. > The driver is not aware of the internal storage used for storing the firmware > as > it is not defined in our driver-hardware API. > > Needless to say that block access has no meaning in our case, so any solution > that will involve MTD device to burn our firmware (if there is a solution at > all) will be a workaround and will not fit MTD purpose. > > Apart for boot time firmware flash, which we have already pushed we would > really > like to allow the user to ask for a specific firmware version. Do you have any > other solution for us apart from "ethtool -f"?
Could you elaborate on what the requirements are for "allowing users to ask for a specific firmware version"? How do the FWs differ? I'm asking because we are currently lacking ABI for selecting device "modes". Netronome has this problem. Cavium has recently posted a patch which used module parameter to flip between "OvS" and "basic NIC" firmwares. For Netronome we will definitely want a way to switch between at least three applications so far - basic, OvS and eBPF - but I also feel like we shouldn't limit that list, since anyone can write their own FW for programmable NICs. I think you were primarily concerned with writing persistent storage so far. Does "allowing the user to ask..." means write flash and reboot or also a runtime switch? I think we probably need both? > This problem is even more relevant in the Mellanox HCA driver team, which > would > like to use that code in order to burn the HCA firmware, but not intend to > trigger it on boot time, which means that must have a way for the user to > trigger it. What would the requirements for the HCA team be? Is it about loading different code or loading HW settings?
