[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190115234148.GB5265@nanopsycho>
Date: Wed, 16 Jan 2019 00:41:48 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: Jonathan Lemon <jonathan.lemon@...il.com>, davem@...emloft.net,
netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [RFC net-next 0/6] devlink: add device (driver) information API
Tue, Jan 15, 2019 at 10:06:42PM CET, jakub.kicinski@...ronome.com wrote:
>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
Agreed. I intended to do that for initial devlink implementation.
>the driver version. In most scenarios kernel version is most reliable.
>It's mostly out-of-tree drivers that need the driver version.
Yep. The "driver version" really makes no sense.
Powered by blists - more mailing lists