From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Lunn <andrew@lunn.ch>
Subject: Re: [RFC net-next 0/6] devlink: add device (driver) information API
Date: Tue, 15 Jan 2019 02:57:55 +0100
Message-ID: <20190115015755.GE8882@lunn.ch>
References: <20190115005009.16025-1-jakub.kicinski@netronome.com>
 <20190115011859.GA8882@lunn.ch>
 <20190114173306.3d8037cd@cakuba.netronome.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: davem@davemloft.net, netdev@vger.kernel.org,
        oss-drivers@netronome.com, jiri@resnulli.us
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from vps0.lunn.ch ([185.16.172.187]:43211 "EHLO vps0.lunn.ch"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1727169AbfAOB55 (ORCPT <rfc822;netdev@vger.kernel.org>);
        Mon, 14 Jan 2019 20:57:57 -0500
Content-Disposition: inline
In-Reply-To: <20190114173306.3d8037cd@cakuba.netronome.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

> I think the plan was to use this opportunity to move the information
> which belongs in devlink to devlink.  There is absolutely nothing
> netdev specific here, and ethtool uses a netdev as a handle.  We can
> have the new ethtool command just issue a devlink request behind the
> scenes if we care.

Hi Jakub

Using that argument, you should probably make the devlink core call
the ethtool .get_drvinfo op if the device does not implement the
devlink op.

    Andrew