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

[Daniel M Crowell]

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
> 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 
interfaces



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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20160913/5268f7ce/attachment.html>