[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200318130441.42ac70b5@kicinski-fedora-PC1C0HJN>
Date: Wed, 18 Mar 2020 13:04:41 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
Cc: David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...lanox.com>,
Michael Chan <michael.chan@...adcom.com>,
Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 01/11] devlink: add macro for "drv.spec"
On Wed, 18 Mar 2020 09:51:29 +0530 Vasundhara Volam wrote:
> On Tue, Mar 17, 2020 at 11:10 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Tue, 17 Mar 2020 20:44:38 +0530 Vasundhara Volam wrote:
> > > Add definition and documentation for the new generic info "drv.spec".
> > > "drv.spec" specifies the version of the software interfaces between
> > > driver and firmware.
> > >
> > > Cc: Jiri Pirko <jiri@...lanox.com>
> > > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
> > > Signed-off-by: Michael Chan <michael.chan@...adcom.com>
> > > ---
> > > Documentation/networking/devlink/devlink-info.rst | 6 ++++++
> > > include/net/devlink.h | 3 +++
> > > 2 files changed, 9 insertions(+)
> > >
> > > diff --git a/Documentation/networking/devlink/devlink-info.rst b/Documentation/networking/devlink/devlink-info.rst
> > > index 70981dd..0765a48 100644
> > > --- a/Documentation/networking/devlink/devlink-info.rst
> > > +++ b/Documentation/networking/devlink/devlink-info.rst
> > > @@ -59,6 +59,12 @@ board.manufacture
> > >
> > > An identifier of the company or the facility which produced the part.
> > >
> > > +drv.spec
> > > +--------
> > > +
> > > +Firmware interface specification version of the software interfaces between
> >
> > Why did you call this "drv" if the first sentence of the description
> > says it's a property of the firmware?
>
> Since it is a version of interface between driver and firmware. Both
> driver and firmware
> can support different versions. I intend to display the version
> implemented in the driver.
We're just getting rid of driver versions, with significant effort,
so starting to extend devlink info with driver stuff seems risky.
How is driver information part of device info in the first place?
As you said good driver and firmware will be modular and backward
compatible, so what's the meaning of the API version?
This field is meaningless.
> I can probably add for both driver and firmware. Add it is as drv.spec
> and fw.spec.
Powered by blists - more mailing lists