[Skiboot] [PATCH 1/2] opal-prd: Add get_prd_flags to host interfaces

Jeremy Kerr jk at ozlabs.org
Wed Sep 14 11:36:16 AEST 2016

Hi Dan,

>>     /**
>>      * @brief Query the HBRT host for a list of fixes
>>      *
>>      * There are times when workarounds need to be put into place to handle
>>      * issues with the hosting layer (e.g. opal-prd) while fixes are not yet
>>      * released.  This is especially true because of the disconnected
>> release
>>      * 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, etc.
> 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



More information about the Skiboot mailing list