> >>>> Patches 6-8 add the "ethtool -f" and the boot-time firmware upgrade > >>>> on > >> the > >>>> mlxsw spectrum driver. > >>> When we tried using `ethtool -E' for qed we got burned for trying to > >>> use > >> the magic > >>> value [1]. When we suggested extending it to allow some private data > >> indications, > >>> Ben claimed that this entire ethtool infrastructure is a thing of > >>> the past, and we should try using MTD instead - a claim no one > bothered to counter. > >>> > >>> Creating proprietary file-formats, filling them with metadata and > >>> complementary driver state-machines could easily overcome the > >>> original obstacle we faced. But it raises the question of whether > >>> these APIs are valid or obsolete. > >> The metadata in our format is needed to allow us to hold several > >> firmware images for several spectrum silicon variants in one file, > >> hence the metadata is used by the driver and does not get transferred to > the device. > > Understood; Otherwise it would have been 'data' and not 'metadata'. > > > >> Our code can only be used to transfer firmware to the device, and > >> cannot be used to configure the device. > > Not sure what this refers to? The differences between '-f' and '-E'? > > Also, assuming you haven't started selling your adapters as persistent > > memory for storage, what's the difference? > > > > 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?
That's exactly the question Ben asked in - http://marc.info/?l=linux-netdev&m=146514461214421&w=2 Suggesting to use MTD for flash access. I'm not saying that approach was necessarily the best; But no one shared any disagreement with it back then.
