From: Lee Jones <lee.jones@linaro.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: linux-kernel@vger.kernel.org,
"Sameer Nanda" <snanda@chromium.org>,
"Javier Martinez Canillas" <javier@osg.samsung.com>,
"Benson Leung" <bleung@chromium.org>,
"Enric Balletbò" <enric.balletbo@collabora.co.uk>,
"Vic Yang" <victoryang@chromium.org>,
"Stephen Boyd" <sboyd@codeaurora.org>,
"Vincent Palatin" <vpalatin@chromium.org>,
"Randall Spangler" <rspangler@chromium.org>,
"Todd Broch" <tbroch@chromium.org>,
"Gwendal Grignou" <gwendal@chromium.org>,
"Olof Johansson" <olof@lixom.net>
Subject: Re: [RESEND PATCH v7 2/6] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper
Date: Mon, 11 Apr 2016 12:18:11 +0100 [thread overview]
Message-ID: <20160411111811.GH8094@x1> (raw)
In-Reply-To: <1459842789-13852-3-git-send-email-tomeu.vizoso@collabora.com>
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 <tomeu.vizoso@collabora.com>
> Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
>
> 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.
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?
> + * @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
next prev parent reply other threads:[~2016-04-11 11:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 7:53 [RESEND PATCH v7 0/6] EC-based USB Power Delivery support for Chrome machines Tomeu Vizoso
2016-04-05 7:53 ` [RESEND PATCH v7 1/6] mfd: cros_ec: Add MKBP event support Tomeu Vizoso
2016-04-07 15:29 ` Lee Jones
2016-04-11 11:45 ` Tomeu Vizoso
2016-04-11 14:04 ` Lee Jones
2016-04-05 7:53 ` [RESEND PATCH v7 2/6] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper Tomeu Vizoso
2016-04-11 11:18 ` Lee Jones [this message]
2016-04-11 13:53 ` Tomeu Vizoso
2016-04-05 7:53 ` [RESEND PATCH v7 3/6] mfd: cros_ec: Add cros_ec_get_host_event Tomeu Vizoso
2016-04-11 11:23 ` Lee Jones
2016-04-05 7:53 ` [RESEND PATCH v7 4/6] mfd: cros_ec: Add more definitions for PD commands Tomeu Vizoso
2016-04-11 11:27 ` Lee Jones
2016-04-05 7:53 ` [RESEND PATCH v7 5/6] power: cros_usbpd-charger: Add EC-based USB PD charger driver Tomeu Vizoso
2016-04-05 7:53 ` [RESEND PATCH v7 6/6] platform/chrome: Register USB PD charger device Tomeu Vizoso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160411111811.GH8094@x1 \
--to=lee.jones@linaro.org \
--cc=bleung@chromium.org \
--cc=enric.balletbo@collabora.co.uk \
--cc=gwendal@chromium.org \
--cc=javier@osg.samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rspangler@chromium.org \
--cc=sboyd@codeaurora.org \
--cc=snanda@chromium.org \
--cc=tbroch@chromium.org \
--cc=tomeu.vizoso@collabora.com \
--cc=victoryang@chromium.org \
--cc=vpalatin@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox