RE: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs

[Stuart Yoder]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@xxxxxxx]
> Sent: Friday, September 19, 2014 3:33 PM
> To: Phillips Kim-R1AAHA; Yoder Stuart-B08248
> Cc: Rivera Jose-B46482; <gregkh@xxxxxxxxxxxxxxxxxxx>; <arnd@xxxxxxxx>; <linux-kernel@xxxxxxxxxxxxxxx>; Wood
> Scott-B07421; <linuxppc-release@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
> 
> 
> 
> On 19.09.14 22:24, Kim Phillips wrote:
> > On Fri, 19 Sep 2014 14:06:32 -0500
> > Yoder Stuart-B08248 <stuart.yoder@xxxxxxxxxxxxx> 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.
> 
> How much is the interface set in stone?

It is set in stone, in that a particular version has an specific set of
commands.

> Can we indicate to the MC that
> we want version x of the protocol? Then the MC can tell us whether it's
> compatible or not.

No, it's not that clever.  For the DPRC object there is a set of commands
with a binary interface. The major/minor version number tell us what version
of the hw object we are dealing with...what commands are there, what version
of the binary interface is there.

Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/