linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@intel.com>
To: broonie@kernel.org, linux-spi@vger.kernel.org
Cc: trix@redhat.com, lgoncalv@redhat.com, yilun.xu@intel.com,
	hao.wu@intel.com, matthew.gerlach@linux.intel.com,
	russell.h.weight@intel.com, linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time
Date: Tue, 29 Dec 2020 13:27:42 +0800	[thread overview]
Message-ID: <1609219662-27057-3-git-send-email-yilun.xu@intel.com> (raw)
In-Reply-To: <1609219662-27057-1-git-send-email-yilun.xu@intel.com>

The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
when the following patch is merged,

commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max speed")

the xfer->speed_hz may always be clamped to 0 if the controller doesn't
provide its max_speed_hz. There may be no hardware indication of the
max_speed_hz so the controller driver leaves it, but exception happens
when it tries to do irq mode transfer.

This patch makes the assumption of 1khz xfer speed if the xfer->speed_hz
is not assigned. This avoids the divide by 0 issue and ensures a
reasonable tolerant waiting time.

Signed-off-by: Xu Yilun <yilun.xu@intel.com>
---
 drivers/spi/spi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 51d7c00..2f3c2c9 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1109,6 +1109,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
 	struct spi_statistics *statm = &ctlr->statistics;
 	struct spi_statistics *stats = &msg->spi->statistics;
 	unsigned long long ms;
+	u32 speed_hz;
 
 	if (spi_controller_is_slave(ctlr)) {
 		if (wait_for_completion_interruptible(&ctlr->xfer_completion)) {
@@ -1116,8 +1117,9 @@ static int spi_transfer_wait(struct spi_controller *ctlr,
 			return -EINTR;
 		}
 	} else {
+		speed_hz = xfer->speed_hz ? : 1000;
 		ms = 8LL * 1000LL * xfer->len;
-		do_div(ms, xfer->speed_hz);
+		do_div(ms, speed_hz);
 		ms += ms + 200; /* some tolerance */
 
 		if (ms > UINT_MAX)
-- 
2.7.4


  parent reply	other threads:[~2020-12-29  5:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29  5:27 [PATCH 0/2] fix the issue when xfer by spi-altera Xu Yilun
2020-12-29  5:27 ` [PATCH 1/2] spi: altera: fix return value for altera_spi_txrx() Xu Yilun
2020-12-29  5:27 ` Xu Yilun [this message]
2020-12-29 13:13   ` [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time Mark Brown
2020-12-30  2:24     ` Xu Yilun
2020-12-30 13:46       ` Mark Brown
2020-12-31  3:23         ` Xu Yilun
2020-12-31 13:36           ` Mark Brown
2020-12-29 14:33 ` (subset) [PATCH 0/2] fix the issue when xfer by spi-altera Mark Brown

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=1609219662-27057-3-git-send-email-yilun.xu@intel.com \
    --to=yilun.xu@intel.com \
    --cc=broonie@kernel.org \
    --cc=hao.wu@intel.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=russell.h.weight@intel.com \
    --cc=trix@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).