>> The third option I see is to completely ditch this, stating that although >> We obviously CAN set the non-volatile memory we CAN'T do it with the >> regular API, and to move into doing this via some proprietary API such >> as debugfs.
> Why go to debugfs rather than gracefully extending the ethtool stuff to > explicitly support what you need? Gracefully extend it to where? The most I can learn from this is that some adapters are in need of additional metadata for doing this sort of stuff. The state-machine itself is propriety and I don't think anyone would gain from trying to formalize anything else from it. If by 'graceful extension' of ethtool API you mean adding an additional field or two for metadata - sure, I can do that, I just don't think of it as graceful. ;-) And if this is actually the way we want to take this, I would still [don't get upset ;-)] argue in favor of overloading the 'magic' field for this purpose, as bnx2x and bnxt are already doing. Basically if the 'magic' would also contain metadata that could be verified as appropriate [I.e., by having valid ranges], it would still fit as a safety measure for guaranteeing the correctness of the write request.