Re: [PATCH] Staging: comedi: add timeouts to while loops in s626.c

[Chase Southwood]

>On Friday, February 28, 2014 11:26 AM, Ian Abbott <abbotti@xxxxxxxxx> 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 <chase.southwood@xxxxxxxxx>
>> ---
>> 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 
>"TSL".
>

*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!

Thanks,
Chase
>
>-- 
>-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@xxxxxxxxx>        )=-
>-=( 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/