[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bb3042da7df488ea01e9869ebc40545@CY1PR0301MB0748.namprd03.prod.outlook.com>
Date: Fri, 19 Sep 2014 21:30:54 +0000
From: Stuart Yoder <stuart.yoder@...escale.com>
To: Kim Phillips <Kim.Phillips@...escale.com>
CC: Jose Rivera <German.Rivera@...escale.com>,
Alexander Graf <agraf@...e.de>,
"<gregkh@...uxfoundation.org>" <gregkh@...uxfoundation.org>,
"<arnd@...db.de>" <arnd@...db.de>,
"<linux-kernel@...r.kernel.org>" <linux-kernel@...r.kernel.org>,
Scott Wood <scottwood@...escale.com>,
"<linuxppc-release@...ux.freescale.net>"
<linuxppc-release@...ux.freescale.net>
Subject: RE: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
> -----Original Message-----
> From: Kim Phillips [mailto:kim.phillips@...escale.com]
> Sent: Friday, September 19, 2014 3:25 PM
> To: Yoder Stuart-B08248
> Cc: Rivera Jose-B46482; Alexander Graf; <gregkh@...uxfoundation.org>; <arnd@...db.de>; <linux-
> kernel@...r.kernel.org>; Wood Scott-B07421; <linuxppc-release@...ux.freescale.net>
> Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
>
> On Fri, 19 Sep 2014 14:06:32 -0500
> Yoder Stuart-B08248 <stuart.yoder@...escale.com> wrote:
>
> > > > >>>>> +/**
> > > > >>>>> + * @brief Management Complex firmware version information
> > > > >>>>> + */
> > > > >>>>> +#define MC_VER_MAJOR 2
> > > > >>>>> +#define MC_VER_MINOR 0
> > > > >>>>
> > > > >>>> code should be adjusted to run on all *compatible* versions of h/w,
> > > > >>>> not strictly the one set in these defines.
> > > > >>> This comment is not precise enough be actionable.
> > > > >>> What exactly you want to be changed here?
> > > > >>
> > > > >> I think the easy thing to do is to convert the exact version check into a ranged version check: have
> > > minimum and maximum versions you support. Or a list of exact versions you support. Or not check for the
> > > version at all - or only for the major version and guarantee that the major version indicates backwards
> > > compatibility.
> > > > >
> > > > > yes, this was my point: elsewhere I noticed the code denies to run
> > > > > iff those defines are not matched exactly: that code should change
> > > > > to run as Alex describes.
> > > > >
> > > > As I mentioned in the reply to Alex, I will remove the minor version check.
> > >
> > > the code should be able to run on all subsequent versions of the
> > > h/w, even in the major version case.
> >
> > You're right, in the future if there are future major versions we would want this
> > same driver to function on multiple versions of the hardware. But at this
> > point in time we don't know what future evolutions there will be and we
> > need the check to error out for now.
>
> why? We have to make the standard assumption that newer versions
> will be backward compatible, in which case the driver should be left
> to run.
If future changes are backward compatible then only the minor version changes. That is
the explicit definition of the meaning of major/minor version for this device.
If the major number changes, then it is not backward compatible and will require
driver changes. So this "error out" check is temporary until we reach that future
point, where it can be removed and we can hopefully implement dynamic handling
of the incompatibility.
Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists