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

[Jeremy Kerr]

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
implementation?

Cheers,


Jeremy