[PATCH] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

[PATCH] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

[Wei-Ning Huang]

Some EC chip has larger flash sector size which requires longer erase
time. During erase the CPU is usually stalled and can't even respond to
interrupts. We sleep a while to block any EC command from executing
during the flash erase period.

Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
---
 drivers/mfd/cros_ec_i2c.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1e4c70..8f23d5a8cc5b 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,14 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
+/*
+ * Some EC chip has larger flash sector size which requires longer erase time.
+ * During erase the CPU is usually stalled and can't even respond to
+ * interrupts. We sleep for a while to block any EC command from executing
+ * during the flash erase period to prevent i2c timeout.
+ */
+#define EC_FLASH_ERASE_DELAY_MS	5000
+
 /**
  * Request format for protocol v3
  * byte 0	0xda (EC_COMMAND_PROTOCOL_3)
@@ -177,6 +185,16 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
 
 	ret = ec_response->data_len;
 
+	/*
+	 * If we get EC_RES_IN_PROGRESS for EC_CMD_FLASH_ERASE this means EC
+	 * need a long time to erase flash, during flash erase CPU is stalled
+	 * and can't respond to interrupts, so we sleep for a while to stop new
+	 * EC commands from communicating with EC.
+	 */
+	if (msg->command == EC_CMD_FLASH_ERASE &&
+	    msg->result == EC_RES_IN_PROGRESS)
+		msleep(EC_FLASH_ERASE_DELAY_MS);
+
 done:
 	if (msg->command == EC_CMD_REBOOT_EC)
 		msleep(EC_REBOOT_DELAY_MS);
-- 
2.12.2

Re: [PATCH] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

[Doug Anderson]

Hi,

On Wed, May 10, 2017 at 10:30 PM, Wei-Ning Huang <wnhuang@chromium.org> wrote:
> Some EC chip has larger flash sector size which requires longer erase
> time. During erase the CPU is usually stalled and can't even respond to
> interrupts. We sleep a while to block any EC command from executing
> during the flash erase period.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>

Slightly odd here that your SoB and author don't match.  Patch is
listed as "From" your chromium address but SoB is your google one.


> ---
>  drivers/mfd/cros_ec_i2c.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
> index 9f70de1e4c70..8f23d5a8cc5b 100644
> --- a/drivers/mfd/cros_ec_i2c.c
> +++ b/drivers/mfd/cros_ec_i2c.c
> @@ -23,6 +23,14 @@
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
>
> +/*
> + * Some EC chip has larger flash sector size which requires longer erase time.
> + * During erase the CPU is usually stalled and can't even respond to
> + * interrupts. We sleep for a while to block any EC command from executing
> + * during the flash erase period to prevent i2c timeout.
> + */
> +#define EC_FLASH_ERASE_DELAY_MS        5000
> +
>  /**
>   * Request format for protocol v3
>   * byte 0      0xda (EC_COMMAND_PROTOCOL_3)
> @@ -177,6 +185,16 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
>
>         ret = ec_response->data_len;
>
> +       /*
> +        * If we get EC_RES_IN_PROGRESS for EC_CMD_FLASH_ERASE this means EC
> +        * need a long time to erase flash, during flash erase CPU is stalled
> +        * and can't respond to interrupts, so we sleep for a while to stop new
> +        * EC commands from communicating with EC.
> +        */
> +       if (msg->command == EC_CMD_FLASH_ERASE &&
> +           msg->result == EC_RES_IN_PROGRESS)
> +               msleep(EC_FLASH_ERASE_DELAY_MS);
> +
>  done:
>         if (msg->command == EC_CMD_REBOOT_EC)
>                 msleep(EC_REBOOT_DELAY_MS);


As per review that took place off-list on crosreview.com/502840, this
seems pretty sane to me.

Reviewed-by: Douglas Anderson <dianders@chromium.org>