Accidentally hit the reply button instead of reply all. Re sending.
> On 12-May-2015, at 11:55, trigg <mr.triggtr...@gmail.com> wrote:
>
> Hi Stewart,
>
> On Tue, May 12, 2015 at 4:01 AM, Stewart Smith
> <stew...@linux.vnet.ibm.com> wrote:
>> 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.
>
> This enum has no semantic difference with a series of #defines. So you
> are better
> off using #defines for this. Using enums with explicitly defined
> values beats the whole
> purpose of using them.
>
>> The explicit numbers means that people think
>> twice before inserting a new value in the middle and subtley breaking
>> firmware ABI.
>
> I disagree. It wont prevent (even worsen) errors like two
> enum-constants being explicitly defined to same values.
> With implicit numbering you can atleast be sure that each
> enum-constant will be unique.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
