On Tue, Feb 19, 2019 at 11:35:08AM +0100, Jiri Pirko wrote: > >- some features provided by ethtool would rather belong to devlink (and > > some are already superseded by devlink); however, only few drivers > > provide devlink interface at the moment and as recent discussion on > > flashing revealed, we cannot rely on devlink's presence > > Could you explain why please?
What I mean is the problem discussed under Jakub's devlink flash patchset: that he couldn't implement only the devlink callback in nfp and rely on the generic fallback to devlink because it wouldn't work if devlink is built as a module. But I think this should be addressed. If we agree that flashing (and other features provided by ethtool at the moment) rather belongs to devlink (which nobody seems to oppose), we should rather try to make it possible for drivers to provide only the devlink callback and gradually move all in-tree drivers to doing so. (And one day, remove it from ethtool_ops.) It doesn't seem to make much sense to have devlink as a module in such scenario. Michal
