[lkml]   [2014]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Staging: comedi: add timeouts to while loops in s626.c
>On Friday, February 28, 2014 11:26 AM, Ian Abbott <> wrote:

>>On 2014-02-28 07:35, Chase Southwood wrote:
>> Smatch located a handful of while loops testing readl calls in s626.c.
>> Since these while loops depend on readl succeeding, it's safer to make
>> sure they time out eventually.
>> Signed-off-by: Chase Southwood <>
>> ---
>> Ian and/or Hartley, I'd love your comments on this.  It seems to me that
>> we want these kinds of while loops properly timed out, but I want to make
>> sure I'm doing everything properly.  First off, s626_debi_transfer() says
>> directly that it is called from within critical sections, so I assume
>> that means that the new comedi_timeout() function is no good here, and
>> s626_send_dac() looked equally suspicious, so I opted for iterative
>> timeouts.  Is this correct?  Also, for these timeouts, I used a very
>> conservative 10000 iterations, would it be better to decrease that?
>Well 10000 iterations is an improvement on infinity!  If the hardware is
>working, you'd expect it to go round a lot fewer iterations than that,
>but if the hardware is broken all bets are off, especially if it is
>generating interrupts.

Great, thanks!  I suppose I'll leave that number there then.

>> Also, do my error strings appear acceptable?
>Mostly.  There's a type in one of the strings that says "TLS" instead of

*Sigh* I promise I can type sometimes :P I'll get this corrected.

>> And finally, are timeouts here even necessary or helpful, or are there
>> any better ways to do it?
>In the case of s626_send_dac(), it doesn't seem to be used in any
>critical sections, so it could make use of Hartley's comedi_timeout().
>Some of the timeout errors could be propagated, especially for
>s626_send_dac() which is only reachable from very few paths.

Awesome, I'll swap all of my timeouts out for comedi_timeout() in s626_send_dac().
As for propagating the timeout errors, could you please clarify that a bit further?  Both of the functions
which I add timeouts inside of in this patch return void, and so in their current state they cannot return any error
values.  Would you like them (or at least s626_send_dac()) to instead return an error upon timeout/or success on success,
or am I just totally misunderstanding your meaning of propagate here?

>There are other infinite loops involving calls to the s626_mc_test()
>function, but those could be dealt with by other patches.

Yeah, I saw those...I'll whip up a patch for them, just wanted to verify that everything looks pretty good here
before I started on that.  I'll have that right out!

>-=( Ian Abbott @ MEV Ltd.    E-mail: <>        )=-
>-=( Tel: +44 (0)161 477 1898  FAX: +44 (0)161 718 3587        )=-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2014-03-01 07:21    [W:0.233 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site