On Tue, Feb 19, 2019 at 11:35:08AM +0100, Jiri Pirko wrote:

quoted

- 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