[Skiboot] [PATCH 1/2] include: Add PRD message definition

[Stewart Smith]

Neelesh Gupta <neelegup at linux.vnet.ibm.com> writes:
> From: Jeremy Kerr <jk at ozlabs.org>
>
> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
> Signed-off-by: Neelesh Gupta <neelegup at linux.vnet.ibm.com>
> ---
>  include/opal.h  |   41 ++++++++++++++++++++++++++++++++++++++++-
>  include/xscom.h |    8 ++++++++
>  2 files changed, 48 insertions(+), 1 deletion(-)

Add something to doc/opal-api/opal-messages.txt ?

> +enum opal_prd_msg_type {
> +	OPAL_PRD_MSG_TYPE_INIT = 0,	/* RT --> FW */

RT?

> +struct opal_prd_msg {
> +	uint8_t		type;
> +	uint8_t		pad[3];
> +	uint32_t	token;

Do we want a version in here?

I'm thinking of future when we have either:
a) more types
b) some types have extended information.

Please clearly document how OS should behave in the event of unknown
types or newer version.

> +	union {
> +		struct {
> +			uint32_t	version;
> +			uint64_t	ipoll;
> +		} init;
> +		struct {
> +			uint64_t	proc;
> +			uint64_t	ipoll_status;
> +			uint64_t	ipoll_mask;
> +		} attn;
> +		struct {
> +			uint64_t	proc;
> +			uint64_t	ipoll_ack;
> +		} attn_ack;
> +		struct {
> +			uint64_t	chip;
> +		} occ_error;
> +		struct {
> +			uint64_t	chip;
> +		} occ_reset;
> +	};
> +};

seeing as this is an opal_msg, can we also have a BUILD_ASSERT() of it
being < sizeof(struct opal_msg) ?

Actually, recent discoveries suggest we should actually BUILD_ASSERT()
on it being <= 72 as well.