| Message ID | 20181009094159.17307-1-clg@kaod.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xive: reserve OPAL call numbers to get/set the NVT state | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | master/apply_patch Successfully applied |
| snowpatch_ozlabs/make_check | success | Test make_check on branch master |
Cédric Le Goater <clg@kaod.org> writes: > XIVE already reserves a couple of OPAL call numbers to get/set the END > state but we will need some more for the NVT state. > > Signed-off-by: Cédric Le Goater <clg@kaod.org> > --- > > or should we recycle OPAL_OLD_I2C_REQUEST, OPAL_ELOG_SEND, > OPAL_GET_COMPLETION_TOKEN_STATUS ? > > what about OPAL_RESERVED1 and OPAL_RESERVED2 ? So, in order to answer that kind of question accuratly and completely, I took a loooong detour into the depths of history and came out with that giant 110 patch long series improving the docs recently. Notably, https://open-power.github.io/skiboot/doc/opal-api/index.html is where there's relevant chatter on what all those random ones were/are. My inclination is to say that we shouldn't go and re-use the never implemented ones or removed ones just to avoid any possible confusion (plus, we're probably not going to run out of call tokens any time soon). I think bbcbbd3e071ffe654596ce19ddf8d99b4176bbc3 superseded this patch though, and we don't have any set NVT state call reserved.
On 04/06/2019 06:02, Stewart Smith wrote: > Cédric Le Goater <clg@kaod.org> writes: >> XIVE already reserves a couple of OPAL call numbers to get/set the END >> state but we will need some more for the NVT state. >> >> Signed-off-by: Cédric Le Goater <clg@kaod.org> >> --- >> >> or should we recycle OPAL_OLD_I2C_REQUEST, OPAL_ELOG_SEND, >> OPAL_GET_COMPLETION_TOKEN_STATUS ? >> >> what about OPAL_RESERVED1 and OPAL_RESERVED2 ? > > So, in order to answer that kind of question accuratly and completely, I > took a loooong detour into the depths of history and came out with that > giant 110 patch long series improving the docs recently. > > Notably, https://open-power.github.io/skiboot/doc/opal-api/index.html is > where there's relevant chatter on what all those random ones were/are. nice ! > My inclination is to say that we shouldn't go and re-use the never > implemented ones or removed ones just to avoid any possible confusion > (plus, we're probably not going to run out of call tokens any time > soon). ok. > I think bbcbbd3e071ffe654596ce19ddf8d99b4176bbc3 superseded this patch > though, yes. > and we don't have any set NVT state call reserved. no. There is no use for it for the moment in P9/P10. Thanks, C.
diff --git a/include/opal-api.h b/include/opal-api.h index 5f397c8e6731..212c3bc229ae 100644 --- a/include/opal-api.h +++ b/include/opal-api.h @@ -199,8 +199,8 @@ #define OPAL_XIVE_FREE_IRQ 140 #define OPAL_XIVE_SYNC 141 #define OPAL_XIVE_DUMP 142 -#define OPAL_XIVE_RESERVED3 143 -#define OPAL_XIVE_RESERVED4 144 +#define OPAL_XIVE_RESERVED3 143 /* Get END state */ +#define OPAL_XIVE_RESERVED4 144 /* Set END state */ #define OPAL_SIGNAL_SYSTEM_RESET 145 #define OPAL_NPU_INIT_CONTEXT 146 #define OPAL_NPU_DESTROY_CONTEXT 147 @@ -226,7 +226,9 @@ #define OPAL_NX_COPROC_INIT 167 #define OPAL_NPU_SET_RELAXED_ORDER 168 #define OPAL_NPU_GET_RELAXED_ORDER 169 -#define OPAL_LAST 169 +#define OPAL_XIVE_RESERVED5 170 /* Get NVT state */ +#define OPAL_XIVE_RESERVED6 171 /* Set NVT state */ +#define OPAL_LAST 171 #define QUIESCE_HOLD 1 /* Spin all calls at entry */ #define QUIESCE_REJECT 2 /* Fail all calls with OPAL_BUSY */
XIVE already reserves a couple of OPAL call numbers to get/set the END state but we will need some more for the NVT state. Signed-off-by: Cédric Le Goater <clg@kaod.org> --- or should we recycle OPAL_OLD_I2C_REQUEST, OPAL_ELOG_SEND, OPAL_GET_COMPLETION_TOKEN_STATUS ? what about OPAL_RESERVED1 and OPAL_RESERVED2 ? include/opal-api.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)