<tt><font size=2>> Are you okay with an unknown set returning 0?</font></tt><br><font size=2 face="sans-serif">Yes, I think that is the only way it
can work. We assume the bugs are un-fixed and the features are not
present unless the bits are explicitly set.</font><br><br><font size=2 face="sans-serif">Do we need to plumb in the reverse (set_capabilities)
as well? e.g. If HBRT is still using a version of a function that
the host (still haven't found a good generic name for opal-prd/phyp-adjunct)
has deprecated, how would you guys know (assuming the ABI isn't smart enough
to hide it)? Perhaps we save this for a different day (or even the
P9 interface update) regardless though...</font><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@au1.ibm.com>, Corey Swenson/Rochester/IBM@IBMUS, Patrick Barrett/Rochester/IBM@IBMUS,
skiboot list <skiboot@lists.ozlabs.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/13/2016 10:56 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>> My intention was that the flags for OPAL and PHYP would be distinct.<br>> That would handle the specific case we're dealing with right
now. I<br>> don't want to force a change into PHYP to set a bit to indicate they<br>> don't have a bug we found in OPAL/opal-prd. Adding features
into the<br>> mix does make the idea of a comon set of flags more enticing though.<br>> I'll have to search around for the notes I sent out months ago
related<br>> to a 'get_capabilities' function to see if there are more ideas we
forgot.<br>> <br>> I still like the idea of multiple sets, so here's attempt #3.<br>> <br>> /* Common features */<br>> #define HBRT_CAPABILITIES_SET0_COMMON 0<br>> #define HBRT_CAPABILITIES_COMMON_AWESOME_FEATURE
(1ul << 0)<br>> #define HBRT_CAPABILITIES_COMMON_NEW_INTERFACE_PARMS
(2ul << 0)<br>> <br>> /* 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>OK, that almost exactly lines up with the new revision that I'm working<br>on :)<br><br>>> Or should we make the sets based on functionality, rather than<br>>> implementation?<br>> Not completely sure what you are suggesting here.<br><br>This was more grouping the sets along the lines of the functionality<br>that they affect, rather than the implementer of the interface (ie,<br>OPAL vs PHYP).<br><br>However - since HBRT knows whether it's running on OPAL vs. PHYP, it<br>does makes sense to have fixes grouped into OPAL / PHYP categories. As<br>long as we do use the COMMON set(s) when appropriate, and coordinate on<br>changes to that, we should be fine.<br><br>Are you okay with an unknown set returning 0?<br><br>Cheers,<br><br><br>Jeremy<br><br></font></tt><br><br><BR>