[Skiboot] [PATCH v2 4/5] external/opal-prd: Support manufacturing command HTMGT and attribute override

Patrick Williams patrick at stwcx.xyz
Wed Aug 26 04:37:15 AEST 2015

On Tue, Aug 25, 2015 at 12:45:08PM +0800, Jeremy Kerr wrote:
> Hi Patrick,
> >> Since we don't have interface version changes here, you'll need to
> >> consume part of this reserved[] array if you add functions to the
> >> runtime_interfaces struct.
> >>
> > 
> > That's not true.  We purposefully have a big enough reserve that we are
> > fine with NULL pointers between any two reasonable levels of Hostboot
> > and Skiboot.  We're not going to add 32 functions between two levels we
> > need common support between.
> I don't understand why you wouldn't want to put these new pointers into
> the previously-reserved area. Not doing so changes the size of the
> struct shared between HBRT and opal-prd, which doesn't seem like a great
> idea to me. Even if we do have fewer than 32 additions, we'd still be
> accessing areas outside of the struct when running with an older HBRT.
> Although this will *probably* behave okay for the foreseeable future,
> we're dealing with distros that have 10+ years until EoL.
> Cheers,
> Jeremy

The Hostboot version of this file says the following:


// Reserve some space for future growth.
// do NOT ever change this number, even if you add functions.
// The value of 32 was somewhat arbitrarily chosen.
// If either side modifies the interface.h file we're suppose to be able to
// tolerate the other side not supporting the function yet.  The function
// pointer can be NULL.  So if we require a new interface from OPAL,
// like "read_iic", we need to be able to tolerate that function pointer
// being NULL and do something sane (and erroring out is not consider sane).
// The purpose of this is to give us the ability to update Hostboot and
// OPAL independently.  It is pretty rare that we both have function ready
// at the same time.  The "reserve" is there so that the structures are
// allocated with sufficient space and populated with NULL function pointers.
// 32 is big enough that we should not likely add that many functions from
// either direction in between any two levels of support.

Is there a reason why this file isn't just copied verbatim from

Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150825/a930535c/attachment.sig>

More information about the Skiboot mailing list