| Message ID | 1441062049-16535-1-git-send-email-vipin@linux.vnet.ibm.com |
|---|---|
| State | Accepted |
| Headers | show |
On Tue, 2015-09-01 at 04:30 +0530, Vipin K Parashar wrote: > This patch assigns numbers to OPAL_MSG macros of enum opal_msg_type > to prevent accidental insertion of any new value in between and thus > break OPAL API. This is also helpful while backporting mainline kernel > changes to distros which run downlevel kernel and thus don't have all > OPAL messages defined, avoiding unnecessary bugs due to enum values > order mismatch. Does the enum buy us much? Should we just use #defines? Also please send a matching kernel patch. cheers
Hi Vipin, > This patch assigns numbers to OPAL_MSG macros of enum opal_msg_type > to prevent accidental insertion of any new value in between and thus > break OPAL API. This is also helpful while backporting mainline kernel > changes to distros which run downlevel kernel and thus don't have all > OPAL messages defined, avoiding unnecessary bugs due to enum values > order mismatch. Looks good to me - this has caught us up previously. Acked-by: Jeremy Kerr <jk@ozlabs.org> mpe: The enum gives us a little more explicit type info when passing the opal_msg_types around. Cheers, Jeremy
On 09/01/2015 05:20 AM, Michael Ellerman wrote: > On Tue, 2015-09-01 at 04:30 +0530, Vipin K Parashar wrote: >> This patch assigns numbers to OPAL_MSG macros of enum opal_msg_type >> to prevent accidental insertion of any new value in between and thus >> break OPAL API. This is also helpful while backporting mainline kernel >> changes to distros which run downlevel kernel and thus don't have all >> OPAL messages defined, avoiding unnecessary bugs due to enum values >> order mismatch. > Does the enum buy us much? Should we just use #defines? > > Also please send a matching kernel patch. Matching kernel patch is posted at below: https://patchwork.ozlabs.org/patch/512628/ > > cheers > >
diff --git a/include/opal-api.h b/include/opal-api.h index f70520b..7a11fe8 100644 --- a/include/opal-api.h +++ b/include/opal-api.h @@ -410,16 +410,16 @@ enum OpalLPCAddressType { }; enum opal_msg_type { - OPAL_MSG_ASYNC_COMP = 0, /* params[0] = token, params[1] = rc, + OPAL_MSG_ASYNC_COMP = 0, /* params[0] = token, params[1] = rc, * additional params function-specific */ - OPAL_MSG_MEM_ERR, - OPAL_MSG_EPOW, - OPAL_MSG_SHUTDOWN, /* params[0] = 1 reboot, 0 shutdown */ - OPAL_MSG_HMI_EVT, - OPAL_MSG_DPO, - OPAL_MSG_PRD, - OPAL_MSG_OCC, + OPAL_MSG_MEM_ERR = 1, + OPAL_MSG_EPOW = 2, + OPAL_MSG_SHUTDOWN = 3, /* params[0] = 1 reboot, 0 shutdown */ + OPAL_MSG_HMI_EVT = 4, + OPAL_MSG_DPO = 5, + OPAL_MSG_PRD = 6, + OPAL_MSG_OCC = 7, OPAL_MSG_TYPE_MAX, };
This patch assigns numbers to OPAL_MSG macros of enum opal_msg_type to prevent accidental insertion of any new value in between and thus break OPAL API. This is also helpful while backporting mainline kernel changes to distros which run downlevel kernel and thus don't have all OPAL messages defined, avoiding unnecessary bugs due to enum values order mismatch. Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> --- include/opal-api.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)