On Wed, Feb 25, 2009 at 01:35:34PM +0100, Roel Kluin wrote:
> spin can reach -1 after the loop, so 0 is still success.
>
You are probably technically right, but it does not matter in
practice. The chip should answer way faster than this timeout, and we
would loose only 0.1% of the overall timeout value. If the chip answer
was that close to the timeout, because of variation, we would fail
half the time and would need a bigger timeout anyway.
A better way would be to not test spin, but to test the status
register itself. That way, it's less ambiguous.
Anyway, such low level code is tricky, and I personally would
not want any change without thourough testing with the hardware. We
know the curent code work, and I don't have time to test, so I would
vote to not change the code.
Regards,
Jean
> Signed-off-by: Roel Kluin <roel.kluin@xxxxxxxxx>
> ---
> diff --git a/drivers/net/wireless/wavelan_cs.c b/drivers/net/wireless/wavelan_cs.c
> index de717f8..1565a0a 100644
> --- a/drivers/net/wireless/wavelan_cs.c
> +++ b/drivers/net/wireless/wavelan_cs.c
> @@ -838,9 +838,8 @@ wv_82593_cmd(struct net_device * dev,
> }
> while(((status & SR3_EXEC_STATE_MASK) != SR3_EXEC_IDLE) && (spin-- > 0));
>
> - /* If the interrupt hasn't be posted */
> - if(spin <= 0)
> - {
> + /* If the interrupt hasn't been posted */
> + if (spin < 0) {
> #ifdef DEBUG_INTERRUPT_ERROR
> printk(KERN_INFO "wv_82593_cmd: %s timeout (previous command), status 0x%02x\n",
> str, status);
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
