trigg <mr.triggtr...@gmail.com> writes:
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++ b/arch/powerpc/include/asm/opal-api.h
>> @@ -730,6 +730,36 @@ struct opal_i2c_request {
>> __be64 buffer_ra; /* Buffer real address */
>> };
>>
>> +/*
>> + * EPOW status sharing (OPAL and the host)
>> + *
>> + * The host will pass on OPAL, a buffer of length OPAL_EPOW_MAX_CLASSES
>> + * to fetch system wide EPOW status. Each element in the returned buffer
>> + * will contain bitwise EPOW status for each EPOW sub class.
>> + */
>> +
>> +/* EPOW types */
>> +enum OpalEpow {
>> + OPAL_EPOW_POWER = 0, /* Power EPOW */
>> + OPAL_EPOW_TEMP = 1, /* Temperature EPOW */
>> + OPAL_EPOW_COOLING = 2, /* Cooling EPOW */
>> + OPAL_MAX_EPOW_CLASSES = 3, /* Max EPOW categories */
>> +};
> Dont explicitly assign sequential numbers in an enum. Its taken care
> of by the compiler.
This header is shared with firmware, and the exact values of each item
does matter as it's ABI. The explicit numbers means that people think
twice before inserting a new value in the middle and subtley breaking
firmware ABI.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
