Received: by 2002:a4a:301c:0:0:0:0:0 with SMTP id q28-v6csp1113347oof; Tue, 25 Sep 2018 08:25:30 -0700 (PDT) X-Google-Smtp-Source: ACcGV62buTENVABOS/oUaO1WHCHKl10VEBJjU4Xhz+guUFCd2yJuo4KCHv4YA0Bb5/tzJj/BvCOF X-Received: by 2002:a17:902:464:: with SMTP id 91-v6mr1746882ple.125.1537889130241; Tue, 25 Sep 2018 08:25:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537889130; cv=none; d=google.com; s=arc-20160816; b=LSaYM22w6C8CPTU9HUX7/JzZUNCjSTv9BoOn+RmWYV9PES91bLWF/PpNYpQYkQkagj kKQ0o+YKKjI4qCmCPug7B9kCV5cGpJ0fs/S2txs19R/w1XAY+mf/BzOpJsK6txBSY9Ts Rrcb3OilpQgAPfJB5tqG++Ty43t3QQcPXzLhFSm9+kxwWr2zHffjHOroPMCpplq10Pwt QxTR6FW8OSxcW3DLpLylkzzt8k1TM71YS5vSk0YOVBGTe4PCqrm4PTWjsUcYiSs6leHu 7QKauDMtWO9X+42V1XosShxd0H9GKfEBUXUwaR0WDmBLvc21NCn4wLY5okNIYoXBHFzg r25A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=9jJnzzLM/Fq9pFO1IsRitvxgtntWgwRUBuCOXTiHbeU=; b=A1yUm1pruWhJN+1tlMSBItOg5HeQQBy3Ms1KUR064ltmZDacTokXRA5u07oHl1PrpZ zL1ygfYsW4K2ZM/sNdQQ+bM5JrQR0bOZ4H9dd8MKLhHpYMO+6t/T45bo/UoiBouBZIV0 QoruSNYi/xLwTaRKRQzeYhABerVzbT+FDBh/5RqR+SyXDIOPHqs9laVzHcKzu3gKyluU EnxDpjNq+u+mp8mOR3hNqHyOjKyLSY55xB/a8KzTO/i/3V1lrF+LrF2eI5IGqzO+WAYc SXetFewL8XkGEyv0SdWW48/wN5cQb6XcwwT/JzmLRUwdMQyiGsuIPs0lScEkgcn9iJQF Q9FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=wifqlxNX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6-v6si2437349pgq.240.2018.09.25.08.25.14; Tue, 25 Sep 2018 08:25:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=wifqlxNX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729945AbeIYVas (ORCPT + 99 others); Tue, 25 Sep 2018 17:30:48 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:39944 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729577AbeIYVaH (ORCPT ); Tue, 25 Sep 2018 17:30:07 -0400 Received: by mail-io1-f68.google.com with SMTP id w16-v6so2651584iom.7 for ; Tue, 25 Sep 2018 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9jJnzzLM/Fq9pFO1IsRitvxgtntWgwRUBuCOXTiHbeU=; b=wifqlxNXyN9w1LATkccktgbazeO470NrYCpaGy1xmWVj5D0Kd78EZdTfMlUVR7gIUG J75LL4pA5+aPcs7B6fhlWY6DCyxn96NzIrDFe0meuX5rRmzhEJFdY5EIEeXxDu4G/wMT vSUKjlO7nJB8EYIXfNeerQZBx5PPJ9JEAQneqKfaNVUup+9fQm7OkW/LF5ZC5D0YyU9k ph1OZ84VISbqqZF14IhKJmgSEPuriYBTK8eHmCG6VjlXgQBUdTZqnaLckhq4kXov0fTC bjSQlDZSjm/JnMziQtnrj4bWD0qwpj0QRJQ683EH0x5I1bRkmUNnLdUBnP8xY1YBxWkR NsBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9jJnzzLM/Fq9pFO1IsRitvxgtntWgwRUBuCOXTiHbeU=; b=RtReSFx6woDyIg4fXKLqynpNuLt3sv1JYCIgEYcsQderV5joy8RVJXruoYuZpNogTq qGkoBjHB8pa/BVNtP4pGj7RN2y/KuS5S/bGeBdzJ3CeiYTSvo0Y7FcK02Vj977JQyKdF IGEdq+5Mfj0zYn9z1y5558c4zgMqyuiO0ma5LYDzUySkkpKL9pCwx8S3YPQ96urNj+0p JT6EMtjQSmf83JL7ds4nvuMESIOnKzgapjtUMsbsZ1GUoAjilnv9LJCC2eR6L+lIQRyY PW9L7OEL79v1UJ+pu0i0QHi0HYGpi/u33FbHn26FPcAWCJtuF/cBURXvce0feshRjCI5 8zcw== X-Gm-Message-State: ABuFfojpWGvXkyUxTeO2Msu6lJgFOP00UKSGyroAcQZOTLP7Zo6fGX10 tF2xTfEohlvOh2Yh1d6aEgc6WFk/GSPyD30cdiEoPA== X-Received: by 2002:a5e:8c04:: with SMTP id n4-v6mr1346401ioj.258.1537888927964; Tue, 25 Sep 2018 08:22:07 -0700 (PDT) MIME-Version: 1.0 References: <1533404620-18536-1-git-send-email-mark.jonas@de.bosch.com> <1534441534-6357-1-git-send-email-mark.jonas@de.bosch.com> In-Reply-To: <1534441534-6357-1-git-send-email-mark.jonas@de.bosch.com> From: Bartosz Golaszewski Date: Tue, 25 Sep 2018 17:21:57 +0200 Message-ID: Subject: Re: [PATCH v2] eeprom: at24: Fix unexpected timeout under high load To: "Jonas Mark (ST-FIR/ENG1)" Cc: Arnd Bergmann , Greg Kroah-Hartman , Andy Shevchenko , linux-i2c , Linux Kernel Mailing List , Wang Xin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org czw., 16 sie 2018 o 19:46 Mark Jonas napisa=C5=82= (a): > > From: Wang Xin > > Within at24_loop_until_timeout the timestamp used for timeout checking > is recorded after the I2C transfer and sleep_range(). Under high CPU > load either the execution time for I2C transfer or sleep_range() could > actually be larger than the timeout value. Worst case the I2C transfer > is only tried once because the loop will exit due to the timeout > although the EEPROM is now ready. > > To fix this issue the timestamp is recorded at the beginning of each > iteration. That is, before I2C transfer and sleep. Then the timeout > is actually checked against the timestamp of the previous iteration. > This makes sure that even if the timeout is reached, there is still one > more chance to try the I2C transfer in case the EEPROM is ready. > > Example: > > If you have a system which combines high CPU load with repeated EEPROM > writes you will run into the following scenario. > > - System makes a successful regmap_bulk_write() to EEPROM. > - System wants to perform another write to EEPROM but EEPROM is still > busy with the last write. > - Because of high CPU load the usleep_range() will sleep more than > 25 ms (at24_write_timeout). > - Within the over-long sleeping the EEPROM finished the previous write > operation and is ready again. > - at24_loop_until_timeout() will detect timeout and won't try to write. > > Signed-off-by: Wang Xin > Signed-off-by: Mark Jonas Applied to at24/for-next. Thanks, Bartosz > --- > Changes in v2: > - Remove loop macro > - Accept superfluous sleep in case of timeout > - Add concrete example to commit message > --- > drivers/misc/eeprom/at24.c | 43 ++++++++++++++++++++++------------------= --- > 1 file changed, 22 insertions(+), 21 deletions(-) > > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c > index f5cc517..37a5c8b 100644 > --- a/drivers/misc/eeprom/at24.c > +++ b/drivers/misc/eeprom/at24.c > @@ -106,23 +106,6 @@ static unsigned int at24_write_timeout =3D 25; > module_param_named(write_timeout, at24_write_timeout, uint, 0); > MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (defaul= t 25)"); > > -/* > - * Both reads and writes fail if the previous write didn't complete yet.= This > - * macro loops a few times waiting at least long enough for one entire p= age > - * write to work while making sure that at least one iteration is run be= fore > - * checking the break condition. > - * > - * It takes two parameters: a variable in which the future timeout in ji= ffies > - * will be stored and a temporary variable holding the time of the last > - * iteration of processing the request. Both should be unsigned integers > - * holding at least 32 bits. > - */ > -#define at24_loop_until_timeout(tout, op_time) \ > - for (tout =3D jiffies + msecs_to_jiffies(at24_write_timeout), = \ > - op_time =3D 0; = \ > - op_time ? time_before(op_time, tout) : true; \ > - usleep_range(1000, 1500), op_time =3D jiffies) > - > struct at24_chip_data { > /* > * these fields mirror their equivalents in > @@ -308,13 +291,22 @@ static ssize_t at24_regmap_read(struct at24_data *a= t24, char *buf, > /* adjust offset for mac and serial read ops */ > offset +=3D at24->offset_adj; > > - at24_loop_until_timeout(timeout, read_time) { > + timeout =3D jiffies + msecs_to_jiffies(at24_write_timeout); > + do { > + /* > + * The timestamp shall be taken before the actual operati= on > + * to avoid a premature timeout in case of high CPU load. > + */ > + read_time =3D jiffies; > + > ret =3D regmap_bulk_read(regmap, offset, buf, count); > dev_dbg(&client->dev, "read %zu@%d --> %d (%ld)\n", > count, offset, ret, jiffies); > if (!ret) > return count; > - } > + > + usleep_range(1000, 1500); > + } while (time_before(read_time, timeout)); > > return -ETIMEDOUT; > } > @@ -358,14 +350,23 @@ static ssize_t at24_regmap_write(struct at24_data *= at24, const char *buf, > regmap =3D at24_client->regmap; > client =3D at24_client->client; > count =3D at24_adjust_write_count(at24, offset, count); > + timeout =3D jiffies + msecs_to_jiffies(at24_write_timeout); > + > + do { > + /* > + * The timestamp shall be taken before the actual operati= on > + * to avoid a premature timeout in case of high CPU load. > + */ > + write_time =3D jiffies; > > - at24_loop_until_timeout(timeout, write_time) { > ret =3D regmap_bulk_write(regmap, offset, buf, count); > dev_dbg(&client->dev, "write %zu@%d --> %d (%ld)\n", > count, offset, ret, jiffies); > if (!ret) > return count; > - } > + > + usleep_range(1000, 1500); > + } while (time_before(write_time, timeout)); > > return -ETIMEDOUT; > } > -- > 2.7.4 >