linux-kernel - [PATCH] spi: change post transfer udelay() to usleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1475837747-7385-1-git-send-email-djkurtz@chromium.org>
Date:   Fri,  7 Oct 2016 18:55:47 +0800
From:   Daniel Kurtz <djkurtz@...omium.org>
To:     unlisted-recipients:; (no To-header on input)
Cc:     dianders@...omium.org, gwendal@...omium.org,
        Daniel Kurtz <djkurtz@...omium.org>,
        Mark Brown <broonie@...nel.org>,
        linux-spi@...r.kernel.org (open list:SPI SUBSYSTEM),
        linux-kernel@...r.kernel.org (open list)
Subject: [PATCH] spi: change post transfer udelay() to usleep_range() for long delays

The spi_transfer parameter delay_usecs allows specifying a time to wait
after transferring a spi message.  This wait can be quite long - some
devices, such as some Chrome OS ECs, require as much as 2000 usecs after
a SPI transaction, before it can respond.

(cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts:
   google,cros-ec-spi-msg-delay = <2000>
)

Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very
friendly to other processes, so change the blocking delay to a sleep
to allow other things to use this CPU (or so it can sleep).

This should be safe to do, because:
 (a) A post-transaction delay like this is always specified as a minimum
     wait time
 (b) A delay here is most likely not very time sensitive, as it occurs
     after all data has been transferred
 (c) This delay occurs in a non-critical section of the spi worker thread
     so where it is safe to sleep.

Two caveats:
 1) To avoid penalizing short delays, still use udelay for delays < 10us.
 2) usleep_range() very often picks the upper bound, an upper bounds 10%
    should be plenty.

Signed-off-by: Daniel Kurtz <djkurtz@...omium.org>
---
 drivers/spi/spi.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a0b6e14..31b4440 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -845,8 +845,14 @@ static int spi_transfer_one_message(struct spi_master *master,
 		if (msg->status != -EINPROGRESS)
 			goto out;
 
-		if (xfer->delay_usecs)
-			udelay(xfer->delay_usecs);
+		if (xfer->delay_usecs) {
+			u16 us = xfer->delay_usecs;
+
+			if (us <= 10)
+				udelay(us);
+			else
+				usleep_range(us, us + DIV_ROUND_UP(us, 10));
+		}
 
 		if (xfer->cs_change) {
 			if (list_is_last(&xfer->transfer_list,
-- 
2.8.0.rc3.226.g39d4020