All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Olof Johansson <olof@lixom.net>,
	Doug Anderson <dianders@chromium.org>,
	Bill Richardson <wfrichar@chromium.org>,
	Simon Glass <sjg@google.com>,
	Gwendal Grignou <gwendal@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v2 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC
Date: Tue, 20 Jan 2015 07:48:03 +0000	[thread overview]
Message-ID: <20150120074803.GR21886@x1> (raw)
In-Reply-To: <1420205572-2640-2-git-send-email-javier.martinez@collabora.co.uk>

On Fri, 02 Jan 2015, Javier Martinez Canillas wrote:

> The struct cros_ec_command will be used as an ioctl() argument for the
> API to control the ChromeOS EC from user-space. So the data structure
> has to be 64-bit safe to make it compatible between 32 and 64 avoiding
> the need for a compat ioctl interface. Since pointers are self-aligned
> to different byte boundaries, use fixed size arrays instead of pointers
> for transferring ingoing and outgoing data with the Embedded Controller.
> 
> Also, re-arrange struct members by decreasing alignment requirements to
> reduce the needing padding size.
> 
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> 
> Hello,
> 
> I choose EC_PROTO2_MAX_PARAM_SIZE as the maximum length for the input and
> output buffers since I see that is what is assumed in the cros_ec driver
> that is the maximum lengths. But the downstream kernel has also suppport
> for the EC host command protocol v3 even though there is currently no bus
> specific code to handle v3 packets. So I wonder if this is a good max len
> or if a different size should be used instead.
> 
> Best regards,
> Javier
> 
> Changes since v1: None, new patch
> 
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 51 +++++++--------------------------
>  drivers/input/keyboard/cros_ec_keyb.c   | 13 +++++----
>  drivers/mfd/cros_ec.c                   | 15 +++++-----
>  include/linux/mfd/cros_ec.h             |  8 +++---
>  4 files changed, 29 insertions(+), 58 deletions(-)

Looks okay to me, but I'd be happy with some more reviews from the
Chrome guys.  I would especially like some knowledgeable type to
answer your EC_PROTO2_MAX_PARAM_SIZE question.  If no one does, I
guess it can always be changed later.

Acked-by: Lee Jones <lee.jones@linaro.org>

> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 875c22a..fa8dedd 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -182,72 +182,41 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
>  	const u16 bus_num = bus->remote_bus;
>  	int request_len;
>  	int response_len;
> -	u8 *request = NULL;
> -	u8 *response = NULL;
>  	int result;
> -	struct cros_ec_command msg;
> +	struct cros_ec_command msg = { };
>  
>  	request_len = ec_i2c_count_message(i2c_msgs, num);
>  	if (request_len < 0) {
>  		dev_warn(dev, "Error constructing message %d\n", request_len);
> -		result = request_len;
> -		goto exit;
> +		return request_len;
>  	}
> +
>  	response_len = ec_i2c_count_response(i2c_msgs, num);
>  	if (response_len < 0) {
>  		/* Unexpected; no errors should come when NULL response */
>  		dev_warn(dev, "Error preparing response %d\n", response_len);
> -		result = response_len;
> -		goto exit;
> -	}
> -
> -	if (request_len <= ARRAY_SIZE(bus->request_buf)) {
> -		request = bus->request_buf;
> -	} else {
> -		request = kzalloc(request_len, GFP_KERNEL);
> -		if (request == NULL) {
> -			result = -ENOMEM;
> -			goto exit;
> -		}
> -	}
> -	if (response_len <= ARRAY_SIZE(bus->response_buf)) {
> -		response = bus->response_buf;
> -	} else {
> -		response = kzalloc(response_len, GFP_KERNEL);
> -		if (response == NULL) {
> -			result = -ENOMEM;
> -			goto exit;
> -		}
> +		return response_len;
>  	}
>  
> -	result = ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
> +	result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num, bus_num);
>  	if (result)
> -		goto exit;
> +		return result;
>  
>  	msg.version = 0;
>  	msg.command = EC_CMD_I2C_PASSTHRU;
> -	msg.outdata = request;
>  	msg.outsize = request_len;
> -	msg.indata = response;
>  	msg.insize = response_len;
>  
>  	result = cros_ec_cmd_xfer(bus->ec, &msg);
>  	if (result < 0)
> -		goto exit;
> +		return result;
>  
> -	result = ec_i2c_parse_response(response, i2c_msgs, &num);
> +	result = ec_i2c_parse_response(msg.indata, i2c_msgs, &num);
>  	if (result < 0)
> -		goto exit;
> +		return result;
>  
>  	/* Indicate success by saying how many messages were sent */
> -	result = num;
> -exit:
> -	if (request != bus->request_buf)
> -		kfree(request);
> -	if (response != bus->response_buf)
> -		kfree(response);
> -
> -	return result;
> +	return num;
>  }
>  
>  static u32 ec_i2c_functionality(struct i2c_adapter *adap)
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index ffa989f..769f8f7 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -148,16 +148,19 @@ static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
>  
>  static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
>  {
> +	int ret;
>  	struct cros_ec_command msg = {
> -		.version = 0,
>  		.command = EC_CMD_MKBP_STATE,
> -		.outdata = NULL,
> -		.outsize = 0,
> -		.indata = kb_state,
>  		.insize = ckdev->cols,
>  	};
>  
> -	return cros_ec_cmd_xfer(ckdev->ec, &msg);
> +	ret = cros_ec_cmd_xfer(ckdev->ec, &msg);
> +	if (ret < 0)
> +		return ret;
> +
> +	memcpy(kb_state, msg.indata, ckdev->cols);
> +
> +	return 0;
>  }
>  
>  static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index fc0c81e..c872e1b 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -74,15 +74,11 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>  	ret = ec_dev->cmd_xfer(ec_dev, msg);
>  	if (msg->result == EC_RES_IN_PROGRESS) {
>  		int i;
> -		struct cros_ec_command status_msg;
> -		struct ec_response_get_comms_status status;
> +		struct cros_ec_command status_msg = { };
> +		struct ec_response_get_comms_status *status;
>  
> -		status_msg.version = 0;
>  		status_msg.command = EC_CMD_GET_COMMS_STATUS;
> -		status_msg.outdata = NULL;
> -		status_msg.outsize = 0;
> -		status_msg.indata = (uint8_t *)&status;
> -		status_msg.insize = sizeof(status);
> +		status_msg.insize = sizeof(*status);
>  
>  		/*
>  		 * Query the EC's status until it's no longer busy or
> @@ -98,7 +94,10 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>  			msg->result = status_msg.result;
>  			if (status_msg.result != EC_RES_SUCCESS)
>  				break;
> -			if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
> +
> +			status = (struct ec_response_get_comms_status *)
> +				 status_msg.indata;
> +			if (!(status->flags & EC_COMMS_STATUS_PROCESSING))
>  				break;
>  		}
>  	}
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 0e166b9..71675b1 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -38,20 +38,20 @@ enum {
>  /*
>   * @version: Command version number (often 0)
>   * @command: Command to send (EC_CMD_...)
> - * @outdata: Outgoing data to EC
>   * @outsize: Outgoing length in bytes
> - * @indata: Where to put the incoming data from EC
>   * @insize: Max number of bytes to accept from EC
>   * @result: EC's response to the command (separate from communication failure)
> + * @outdata: Outgoing data to EC
> + * @indata: Where to put the incoming data from EC
>   */
>  struct cros_ec_command {
>  	uint32_t version;
>  	uint32_t command;
> -	uint8_t *outdata;
>  	uint32_t outsize;
> -	uint8_t *indata;
>  	uint32_t insize;
>  	uint32_t result;
> +	uint8_t outdata[EC_PROTO2_MAX_PARAM_SIZE];
> +	uint8_t indata[EC_PROTO2_MAX_PARAM_SIZE];
>  };
>  
>  /**

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-01-20  7:48 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02 13:32 [PATCH RESEND v2 0/7] platform/chrome: Add user-space dev inferface support Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 1/7] mfd: cros_ec: Use fixed size arrays to transfer data with the EC Javier Martinez Canillas
2015-01-20  7:48   ` Lee Jones [this message]
2015-01-20 15:40     ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 2/7] mfd: cros_ec: Add char dev and virtual dev pointers Javier Martinez Canillas
2015-01-20  7:50   ` Lee Jones
2015-01-20 15:41     ` Javier Martinez Canillas
2015-01-20 16:36       ` Lee Jones
2015-01-20 16:45         ` Javier Martinez Canillas
2015-01-20 16:51           ` Lee Jones
2015-01-02 13:32 ` [PATCH RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices Javier Martinez Canillas
2015-01-20  8:11   ` Lee Jones
2015-01-20 15:58     ` Javier Martinez Canillas
2015-01-20 16:34       ` Lee Jones
2015-01-20 16:52         ` Javier Martinez Canillas
2015-01-21 17:05           ` Javier Martinez Canillas
2015-01-22  8:42           ` Lee Jones
2015-01-22  9:08             ` Javier Martinez Canillas
2015-01-22  9:46               ` Lee Jones
2015-01-22 10:36                 ` Javier Martinez Canillas
2015-01-22 10:56                   ` Lee Jones
2015-01-22 11:17                     ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 4/7] platform/chrome: Add Chrome OS EC userspace device interface Javier Martinez Canillas
2015-01-13 23:40   ` Gwendal Grignou
2015-01-02 13:32 ` [PATCH RESEND v2 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device Javier Martinez Canillas
2015-01-20  8:20   ` Lee Jones
2015-01-20 16:03     ` Javier Martinez Canillas
2015-01-20 16:29       ` Lee Jones
2015-01-20 16:36         ` Javier Martinez Canillas
2015-01-20 16:55           ` Lee Jones
2015-01-20 17:11             ` Javier Martinez Canillas
2015-01-21 16:56               ` Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 6/7] platform/chrome: Create sysfs attributes for the ChromeOS EC Javier Martinez Canillas
2015-01-02 13:32 ` [PATCH RESEND v2 7/7] platform/chrome: Expose Chrome OS Lightbar to users Javier Martinez Canillas
2015-01-12 10:18 ` [PATCH RESEND v2 0/7] platform/chrome: Add user-space dev inferface support Javier Martinez Canillas

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=20150120074803.GR21886@x1 \
    --to=lee.jones@linaro.org \
    --cc=corbet@lwn.net \
    --cc=dianders@chromium.org \
    --cc=gwendal@google.com \
    --cc=javier.martinez@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sjg@google.com \
    --cc=wfrichar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.