On 11 April 2016 at 13:18, Lee Jones <[email protected]> wrote: > On Tue, 05 Apr 2016, Tomeu Vizoso wrote: > >> So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate >> code when checking for errors from the EC side. >> >> Signed-off-by: Tomeu Vizoso <[email protected]> >> Reviewed-by: Benson Leung <[email protected]> >> --- >> >> Changes in v7: None >> Changes in v6: None >> Changes in v5: >> - Check explicitly for !EC_RES_SUCCESS as suggested by Benson Leung. >> >> Changes in v4: None >> Changes in v3: None >> Changes in v2: None >> >> drivers/platform/chrome/cros_ec_proto.c | 14 ++++++++++++++ >> include/linux/mfd/cros_ec.h | 18 ++++++++++++++++++ >> 2 files changed, 32 insertions(+) >> >> diff --git a/drivers/platform/chrome/cros_ec_proto.c >> b/drivers/platform/chrome/cros_ec_proto.c >> index c792e116e621..aaccdde1c9d5 100644 >> --- a/drivers/platform/chrome/cros_ec_proto.c >> +++ b/drivers/platform/chrome/cros_ec_proto.c >> @@ -472,3 +472,17 @@ int cros_ec_get_next_event(struct cros_ec_device >> *ec_dev) >> return get_keyboard_state_event(ec_dev); >> } >> EXPORT_SYMBOL(cros_ec_get_next_event); >> + >> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev, >> + struct cros_ec_command *msg) >> +{ >> + int ret = cros_ec_cmd_xfer(ec_dev, msg); > > I don't really like function calls during declaration time.
Ok. > If you make the call here, you don't have to leave a pointless '\n' > between it and checking the return value. > >> + if (ret < 0) >> + dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret); >> + else if (msg->result != EC_RES_SUCCESS) >> + return -EECRESULT - msg->result; >> + >> + return ret; >> +} >> +EXPORT_SYMBOL(cros_ec_cmd_xfer_status); >> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h >> index ddc935ef1911..e4c4c0480c14 100644 >> --- a/include/linux/mfd/cros_ec.h >> +++ b/include/linux/mfd/cros_ec.h >> @@ -40,6 +40,9 @@ >> #define EC_MAX_REQUEST_OVERHEAD 1 >> #define EC_MAX_RESPONSE_OVERHEAD 2 >> >> +/* ec_command return value for non-success result from EC */ >> +#define EECRESULT 1000 >> + >> /* >> * Command interface between EC and AP, for LPC, I2C and SPI interfaces. >> */ >> @@ -250,6 +253,21 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev, >> struct cros_ec_command *msg); >> >> /** >> + * cros_ec_cmd_xfer_status - Send a command to the ChromeOS EC >> + * >> + * This function is identical to cros_ec_cmd_xfer, except it returns succes >> + * status only if both the command was transmitted successfully and the EC >> + * replied with success status. It's not necessary to check msg->result when >> + * using this function. > > Is it useful for callers of cros_ec_cmd_xfer() to ever not do this? > If not, why don't you make these changes in cros_ec_cmd_xfer() itself? Some callers of cros_ec_cmd_xfer() (for example, the tunnel) just want to know if the message was successfully transmitted, regardless of whether the command was successful or not. Thanks, Tomeu >> + * @ec_dev: EC device >> + * @msg: Message to write >> + * @return: Num. of bytes transferred on success, <0 on failure >> + */ >> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev, >> + struct cros_ec_command *msg); >> + >> +/** >> * cros_ec_remove - Remove a ChromeOS EC >> * >> * Call this to deregister a ChromeOS EC, then clean up any private data. > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
