Comments

tms380tr driver tries to use udelay (meaning busy loop) for several half
second delays during hardware initialization. Crazy overly long busy
wait delays mean no delay at all so driver initialization fails without
waiting. Fix it by using msleep() for long delays and leave it to
udelay() for short delays.
Signed-off-by: Meelis Roos <mroos@linux.ee>
---
drivers/net/tokenring/tms380tr.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 3 Oct 2010 22:34:30 +0300 (EEST)
> tms380tr driver tries to use udelay (meaning busy loop) for several half > second delays during hardware initialization. Crazy overly long busy > wait delays mean no delay at all so driver initialization fails without > waiting. Fix it by using msleep() for long delays and leave it to > udelay() for short delays.> > Signed-off-by: Meelis Roos <mroos@linux.ee>
You can't use msleep() here because this code can be invoked
from interrupts and thus cannot sleep.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

> > tms380tr driver tries to use udelay (meaning busy loop) for several half > > second delays during hardware initialization. Crazy overly long busy > > wait delays mean no delay at all so driver initialization fails without > > waiting. Fix it by using msleep() for long delays and leave it to > > udelay() for short delays.> > > > Signed-off-by: Meelis Roos <mroos@linux.ee>> > You can't use msleep() here because this code can be invoked> from interrupts and thus cannot sleep.
I checked these two functions that contain long delays that I changed -
tms380tr_bringup_diags() and tms380tr_init_adapter() - to be called only
from tms380tr_chipset_init() that is only called from tms380tr_open() so
no call paths from interrupts AFAICS. Short delyas from interrupt
context are not changed in any way, they still use udelay().

From: Meelis Roos <mroos@linux.ee>
Date: Mon, 4 Oct 2010 11:39:02 +0300 (EEST)
>> > tms380tr driver tries to use udelay (meaning busy loop) for several half >> > second delays during hardware initialization. Crazy overly long busy >> > wait delays mean no delay at all so driver initialization fails without >> > waiting. Fix it by using msleep() for long delays and leave it to >> > udelay() for short delays.>> > >> > Signed-off-by: Meelis Roos <mroos@linux.ee>>> >> You can't use msleep() here because this code can be invoked>> from interrupts and thus cannot sleep.> > I checked these two functions that contain long delays that I changed - > tms380tr_bringup_diags() and tms380tr_init_adapter() - to be called only > from tms380tr_chipset_init() that is only called from tms380tr_open() so > no call paths from interrupts AFAICS. Short delyas from interrupt > context are not changed in any way, they still use udelay().
tms380tr_init_adapter() gets called from tms380tr_chk_irq() which is
invoked from the interrupt handler.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

> tms380tr_init_adapter() gets called from tms380tr_chk_irq() which is> invoked from the interrupt handler.
Oops, yes, sorry for repeatedly not noticing it even when I was
explicitly searching for it :(
What is the general course from here? Defer the long reset to a work
queue, or some other kind of background task?

From: Meelis Roos <mroos@linux.ee>
Date: Tue, 5 Oct 2010 00:15:17 +0300 (EEST)
>> tms380tr_init_adapter() gets called from tms380tr_chk_irq() which is>> invoked from the interrupt handler.> > Oops, yes, sorry for repeatedly not noticing it even when I was > explicitly searching for it :(> > What is the general course from here? Defer the long reset to a work > queue, or some other kind of background task?
Yes, very likely a workqueue is the best course of action.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html