<font size=2 face="sans-serif">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.</font><br><br><font size=2 face="sans-serif">I still like the idea of multiple sets,
so here's attempt #3.</font><br><br><tt><font size=2> /* Common features */<br> #define HBRT_CAPABILITIES_SET0_COMMON 0</font></tt><br><tt><font size=2> #define HBRT_CAPABILITIES_COMMON_AWESOME_FEATURE
(1ul << 0)<br> #define HBRT_CAPABILITIES_COMMON_NEW_INTERFACE_PARMS (2ul
<< 0)<br></font></tt><br><tt><font size=2> /* OPAL fixes */<br> #define HBRT_CAPABILITIES_SET1_OPAL 1<br> #define HBRT_CAPABILITIES_OPAL_HAS_XSCOM_RC (1ul <<
0)<br><br> /* PHYP fixes */<br> #define HBRT_CAPABILITIES_SET2_PHYP 2<br> #define HBRT_CAPABILITIES_PHYP_FIXED_BROKEN_THING (1ul
<< 0)<br><br></font></tt><br><br><tt><font size=2>> Or should we make the sets based on functionality,
rather than<br>> implementation?<br>Not completely sure what you are suggesting here.</font></tt><br><font size=2 face="sans-serif"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Jeremy Kerr <jk@ozlabs.org></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Daniel M Crowell/Rochester/IBM@IBMUS</font><br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">Benjamin Herrenschmidt
<benh@kernel.crashing.org>, skiboot@lists.ozlabs.org, Corey Swenson/Rochester/IBM@IBMUS,
Patrick Barrett/Rochester/IBM@IBMUS</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/13/2016 08:36 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [PATCH 1/2]
opal-prd: Add get_prd_flags to host interfaces</font><br><hr noshade><br><br><br><tt><font size=2>Hi Dan,<br><br>>> /**<br>>> * @brief Query the HBRT host for a list of
fixes<br>>> *<br>>> * There are times when workarounds need to
be put into place to handle<br>>> * issues with the hosting layer (e.g. opal-prd)
while fixes are not yet<br>>> * released. This is especially true
because of the disconnected<br>>> release<br>>> * streams for the firmware and the hosting
environment.<br>>> *<br>>> * @param i_set Indicates which set of
fixes we're checking<br>>> *
see HBRT_FIX_LIST_SET...<br>>> *<br>>> * @return a bitmask containing the relevant
flags for the current<br>>> * implementation,
see HBRT_FIX_FLAGS_...<br>>> */<br>>> uint64_t (*get_fix_list)( uint64_t i_set );<br>>><br>>> /* OPAL fixes */<br>>> #define HBRT_FIX_LIST_SET0_OPAL 0<br>>> #define HBRT_FIX_FLAGS_OPAL_HAS_XSCOM_RC (1ul
<< 0)<br>>><br>>> /* PHYP fixes */<br>>> #define HBRT_FIX_LIST_SET1_PHYP 1<br>>><br>>> If we run over 64 flags, we'd just make a HBRT_FIX_LIST_SET2_OPAL2
2, etc.<br>> <br>> Yep, that makes sense. We'd just need to define the case where the
'set'<br>> is unknown to opal-prd or pHyp. I'd propose just returning zero, as
long<br>> as we can ensure that zero-bit defaults will be acceptable in future.<br><br>On further thoughts, this could makes the interface a little difficult<br>to implement, mostly on the HBRT side.<br><br>If you're running under phyp, would you ever request the flags for<br>SET0_OPAL? If so, it would indicate that the XSCOM_RC flags is *not* set<br>(since it's returning 0 for an unknown set)? Or would the phyp<br>implementation need to know about the OPAL flags?<br><br>Or should we make the sets based on functionality, rather than<br>implementation?<br><br>Cheers,<br><br><br>Jeremy<br><br></font></tt><br><br><BR>