[Skiboot] [PATCH 1/2] opal-prd: Add get_prd_flags to host interfaces
Daniel M Crowell
dcrowell at us.ibm.com
Wed Sep 14 13:40:24 AEST 2016
My intention was that the flags for OPAL and PHYP would be distinct. That
would handle the specific case we're dealing with right now. I don't want
to force a change into PHYP to set a bit to indicate they don't have a bug
we found in OPAL/opal-prd. Adding features into the mix does make the
idea of a comon set of flags more enticing though. I'll have to search
around for the notes I sent out months ago related to a 'get_capabilities'
function to see if there are more ideas we forgot.
I still like the idea of multiple sets, so here's attempt #3.
/* Common features */
#define HBRT_CAPABILITIES_SET0_COMMON 0
#define HBRT_CAPABILITIES_COMMON_AWESOME_FEATURE (1ul << 0)
#define HBRT_CAPABILITIES_COMMON_NEW_INTERFACE_PARMS (2ul << 0)
/* OPAL fixes */
#define HBRT_CAPABILITIES_SET1_OPAL 1
#define HBRT_CAPABILITIES_OPAL_HAS_XSCOM_RC (1ul << 0)
/* PHYP fixes */
#define HBRT_CAPABILITIES_SET2_PHYP 2
#define HBRT_CAPABILITIES_PHYP_FIXED_BROKEN_THING (1ul << 0)
> Or should we make the sets based on functionality, rather than
Not completely sure what you are suggesting here.
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com
From: Jeremy Kerr <jk at ozlabs.org>
To: Daniel M Crowell/Rochester/IBM at IBMUS
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>,
skiboot at lists.ozlabs.org, Corey Swenson/Rochester/IBM at IBMUS, Patrick
Barrett/Rochester/IBM at IBMUS
Date: 09/13/2016 08:36 PM
Subject: Re: [PATCH 1/2] opal-prd: Add get_prd_flags to host
>> * @brief Query the HBRT host for a list of fixes
>> * There are times when workarounds need to be put into place to
>> * issues with the hosting layer (e.g. opal-prd) while fixes are
>> * released. This is especially true because of the disconnected
>> * streams for the firmware and the hosting environment.
>> * @param i_set Indicates which set of fixes we're checking
>> * see HBRT_FIX_LIST_SET...
>> * @return a bitmask containing the relevant flags for the current
>> * implementation, see HBRT_FIX_FLAGS_...
>> uint64_t (*get_fix_list)( uint64_t i_set );
>> /* OPAL fixes */
>> #define HBRT_FIX_LIST_SET0_OPAL 0
>> #define HBRT_FIX_FLAGS_OPAL_HAS_XSCOM_RC (1ul << 0)
>> /* PHYP fixes */
>> #define HBRT_FIX_LIST_SET1_PHYP 1
>> If we run over 64 flags, we'd just make a HBRT_FIX_LIST_SET2_OPAL2 2,
> Yep, that makes sense. We'd just need to define the case where the 'set'
> is unknown to opal-prd or pHyp. I'd propose just returning zero, as long
> as we can ensure that zero-bit defaults will be acceptable in future.
On further thoughts, this could makes the interface a little difficult
to implement, mostly on the HBRT side.
If you're running under phyp, would you ever request the flags for
SET0_OPAL? If so, it would indicate that the XSCOM_RC flags is *not* set
(since it's returning 0 for an unknown set)? Or would the phyp
implementation need to know about the OPAL flags?
Or should we make the sets based on functionality, rather than
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Skiboot