[lkml]   [2020]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time
On Tue, Dec 29, 2020 at 01:27:42PM +0800, Xu Yilun wrote:
> 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.

Does this still apply with current code? There have been some fixes in
this area which I think should ensure that we don't turn the speed down
to 0 if the controller doesn't supply a limit IIRC.

> 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.

It will cause absurdly slow transfers if the controller does actually
implement speed setting though, if we're going to pick a default value
I'd go for at least 100kHz.

> } else {
> + speed_hz = xfer->speed_hz ? : 1000;

Please don't abuse the ternery operator, write normal conditional
statements to make things more legible.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2020-12-29 14:15    [W:0.056 / U:12.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site