[Skiboot] [RFC 1/2] occ: Add support for OPAL-OCC command/response interface

Oliver O'Halloran oohall at gmail.com
Tue Jun 6 16:31:40 AEST 2017


> diff --git a/include/opal-api.h b/include/opal-api.h
> index 80033c6..4acbd44 100644
> --- a/include/opal-api.h
> +++ b/include/opal-api.h
> @@ -55,6 +55,10 @@
>  #define OPAL_XSCOM_CTR_OFFLINED        -30
>  #define OPAL_XIVE_PROVISIONING -31
>  #define OPAL_XIVE_FREE_ACTIVE  -32
> +#define OPAL_OCC_INVALID_STATE -33
> +#define OPAL_OCC_BUSY          -34
> +#define OPAL_OCC_CMD_TIMEOUT   -35
> +#define OPAL_OCC_CMD_MISMATCH -36
>
>  /* API Tokens (in r0) */
>  #define OPAL_INVALID_CALL                     -1
> @@ -204,7 +208,8 @@
>  #define OPAL_NPU_INIT_CONTEXT                  146
>  #define OPAL_NPU_DESTROY_CONTEXT               147
>  #define OPAL_NPU_MAP_LPAR                      148
> -#define OPAL_LAST                              148
> +#define OPAL_OCC_COMMAND                       149
> +#define OPAL_LAST                              149
>
>  /* Device tree flags */
>
> @@ -1021,6 +1026,67 @@ typedef struct oppanel_line {
>         __be64 line_len;
>  } oppanel_line_t;
>
> +enum occ_cmd {
> +       OCC_CMD_AMESTER_PASS_THRU = 0,
> +       OCC_CMD_CLEAR_SENSOR_DATA,
> +       OCC_CMD_SET_POWER_CAP,
> +       OCC_CMD_SET_POWER_SHIFTING_RATIO,
> +       OCC_CMD_LAST
> +};
> +
> +enum occ_cmd_data_length {
> +       OCC_CMD_DL_AMESTER_PASS_THRU            = 0, /* Variable data length */
> +       OCC_CMD_DL_CLEAR_SENSOR_DATA            = 4,
> +       OCC_CMD_DL_SET_POWER_CAP                = 2,
> +       OCC_CMD_DL_SET_POWER_SHIFTING_RATIO     = 1,
> +};
> +
> +enum occ_rsp_data_length {
> +       OCC_RSP_DL_AMESTER_PASS_THRU            = 0, /* Variable data length */
> +       OCC_RSP_DL_CLEAR_SENSOR_DATA            = 4,
> +       OCC_RSP_DL_SET_POWER_CAP                = 2,
> +       OCC_RSP_DL_SET_POWER_SHIFTING_RATIO     = 1,
> +};
> +
> +enum occ_sensor_limit_group {
> +       OCC_SENSOR_LIMIT_GROUP_CSM              = 0x10,
> +       OCC_SENSOR_LIMIT_GROUP_PROFILER         = 0x20,
> +       OCC_SENSOR_LIMIT_GROUP_JOB_SCHED        = 0x30,
> +};
> +
> +#define MAX_OPAL_CMD_DATA_LENGTH       4090
> +#define MAX_OCC_RSP_DATA_LENGTH                8698
> +
> +enum occ_response_status {
> +       OCC_SUCCESS                     = 0x00,
> +       OCC_INVALID_COMMAND             = 0x11,
> +       OCC_INVALID_CMD_DATA_LENGTH     = 0x12,
> +       OCC_INVALID_DATA                = 0x13,
> +       OCC_INTERNAL_ERROR              = 0x15,
> +};
> +
> +struct opal_occ_cmd_rsp_msg {
> +       u8 *cdata;
> +       u8 *rdata;

I don't think this is safe to have pointers in OPAL API structures. As
far as I know there's no way to annotate a pointer as big endian so
they've always been re-encoded as a __be64 or passed as function
arguments since registers are endian independent. Re-encoding them as
an integer is probably a good idea since we should be using __pa() on
pointers passed from linux to skiboot anyway.

> +       __be16 cdata_size;
> +       __be16 rdata_size;
> +       u8 cmd;
> +       u8 request_id;
> +       u8 status;
> +};

> +
> +struct opal_occ_cmd_data {
> +       u16 size;
should this be __be16?

> +       u8 cmd;
> +       u8 data[];
> +};
> +
> +struct opal_occ_rsp_data {
> +       u16 size;
same here

> +       u8 status;
> +       u8 data[];
> +};
> +

Looks fine otherwise


More information about the Skiboot mailing list