netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: "Jonathan Lemon" <jonathan.lemon@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	oss-drivers@netronome.com, jiri@resnulli.us
Subject: Re: [RFC net-next 0/6] devlink: add device (driver) information API
Date: Tue, 15 Jan 2019 13:06:42 -0800	[thread overview]
Message-ID: <20190115130642.0113288e@cakuba.netronome.com> (raw)
In-Reply-To: <7B7B83D2-5F56-4E7D-A313-4F8E48B23119@gmail.com>

On Tue, 15 Jan 2019 11:30:10 -0800, Jonathan Lemon wrote:
> On 14 Jan 2019, at 16:50, Jakub Kicinski wrote:
> 
> > Hi!
> >
> > For quite some time now the ethtool -i API has been showing its age.
> > The driver version field is generally considered obsolete these
> > days, and driver authors are encouraged to report the kernel version.
> > fw_version field does not suit modern needs with 31 characters being
> > quite limiting on more complex systems.  There is also no distinction
> > between the running and flashed versions of the firmware.
> >
> > Since the driver information pertains to the entire device, rather
> > than a particular netdev, it seems wise to move it do devlink, at
> > the same time fixing the aforementioned issues.
> >
> > The new API allows exposing the device serial number and versions
> > of the components of the card - both hardware, firmware (running
> > and flashed).  Driver authors can choose descriptive identifiers
> > for the version fields.  There is a potential for defining common
> > fields here, but given the general direction of the stack I don't
> > think people would like that.
> >
> > Example:
> > $ devlink  info show
> > pci/0000:05:00.0:
> >   serial_number: 00:15:4d:12:20:7e
> >   versions:
> >     fixed:
> >       board.model carbon
> >       board.partno AMDA0099-0001
> >       board.revision 07
> >       board.vendor SMA
> >     running:
> >       fw.mgmt: 010156.010156.010156
> >       fw.cpld: 0x44
> >       fw.app: sriov-2.1.16
> >     stored:
> >       fw.mgmt: 010158.010158.010158
> >       fw.cpld: 0x44
> >       fw.app: sriov-2.1.20  
> 
> How about adding the driver name and version as well?
> When connecting to an unknown system, "ethtool -i" is useful in
> discovering what is actually running.

I'm happy to add the driver name, I'd, however, rather steer clear of
the driver version.  In most scenarios kernel version is most reliable.
It's mostly out-of-tree drivers that need the driver version.

  reply	other threads:[~2019-01-15 21:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15  0:50 [RFC net-next 0/6] devlink: add device (driver) information API Jakub Kicinski
2019-01-15  0:50 ` [RFC net-next 1/6] devlink: add device " Jakub Kicinski
2019-01-15 10:15   ` Jiri Pirko
2019-01-15 17:41     ` Jakub Kicinski
2019-01-15 20:00       ` Andrew Lunn
2019-01-15 21:42         ` Jakub Kicinski
2019-01-15  0:50 ` [RFC net-next 2/6] devlink: add version reporting API Jakub Kicinski
2019-01-15 10:12   ` Jiri Pirko
2019-01-15  0:50 ` [RFC net-next 3/6] nfp: devlink: report serial number Jakub Kicinski
2019-01-15  0:50 ` [RFC net-next 4/6] nfp: devlink: report fixed versions Jakub Kicinski
2019-01-15 10:18   ` Jiri Pirko
2019-01-15 18:09     ` Jakub Kicinski
2019-01-15  0:50 ` [RFC net-next 5/6] nfp: nsp: add support for versions command Jakub Kicinski
2019-01-15  0:50 ` [RFC net-next 6/6] nfp: devlink: report the running and flashed versions Jakub Kicinski
2019-01-15  0:50 ` [RFC iproute2-next] devlink: add info subcommand Jakub Kicinski
2019-01-15  8:20   ` Jiri Pirko
2019-01-15 14:00     ` Andrew Lunn
2019-01-15 14:07       ` Jiri Pirko
2019-01-15 17:58       ` Jakub Kicinski
2019-01-15 17:53     ` Jakub Kicinski
2019-01-15 18:05       ` Jiri Pirko
2019-01-15 18:32         ` Jakub Kicinski
2019-01-15  1:00 ` [RFC net-next 0/6] devlink: add device (driver) information API Florian Fainelli
2019-01-15  1:18 ` Andrew Lunn
2019-01-15  1:33   ` Jakub Kicinski
2019-01-15  1:57     ` Andrew Lunn
2019-01-15  3:27       ` Jakub Kicinski
2019-01-15  7:36         ` Michal Kubecek
2019-01-15  8:12       ` Jiri Pirko
2019-01-15 19:30 ` Jonathan Lemon
2019-01-15 21:06   ` Jakub Kicinski [this message]
2019-01-15 23:41     ` Jiri Pirko
2019-01-16 19:00     ` Jonathan Lemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190115130642.0113288e@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jiri@resnulli.us \
    --cc=jonathan.lemon@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).