[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 */

     /* OPAL fixes */
     #define HBRT_CAPABILITIES_OPAL_HAS_XSCOM_RC  (1ul << 0)

     /* PHYP fixes */

> Or should we make the sets based on functionality, rather than
> implementation?
Not completely sure what you are suggesting here.

Dan Crowell
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 

Hi Dan,

>>     /**
>>      * @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 
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, 
> 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...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20160913/5268f7ce/attachment.html>

More information about the Skiboot mailing list