On Sunday 28 October 2007 00:24:10 Alan Stern wrote:
> On Sat, 27 Oct 2007, Maxim Levitsky wrote:
>
> > > Use del_timer_sync(). It guarantees that when it returns, the timer
> > > will be stopped and the timer routine will no longer be running on any
> > > CPU.
> > >
> > Even if the timer re-e
On Sat, 27 Oct 2007, Maxim Levitsky wrote:
> > Use del_timer_sync(). It guarantees that when it returns, the timer
> > will be stopped and the timer routine will no longer be running on any
> > CPU.
> >
> Even if the timer re-enables itself, are you sure?
Last time I looked at the source code
On Saturday 27 October 2007 21:17:55 Alan Stern wrote:
> On Fri, 26 Oct 2007, Maxim Levitsky wrote:
>
> > > > Looking through the dmfe code, I noticed yet another possible race.
> > > > A race between the .suspend, and a timer that serves both as a
> > > > watchdog, and link state detector.
> > >
On Fri, 26 Oct 2007, Maxim Levitsky wrote:
> > > Looking through the dmfe code, I noticed yet another possible race.
> > > A race between the .suspend, and a timer that serves both as a watchdog,
> > > and link state detector.
> > > Again I need to prevent it from running during the suspend/resum
On Thursday 25 October 2007 19:02:12 Alan Stern wrote:
> On Thu, 25 Oct 2007, Maxim Levitsky wrote:
>
> > Hi,
> >
> > Recently, trying to fix saa7134 suspend/resume problems I found that there
> > is a race between IRQ handler and .suspend , and that I cant let driver
> > access the device
> >
On Thu, 25 Oct 2007, Maxim Levitsky wrote:
> Hi,
>
> Recently, trying to fix saa7134 suspend/resume problems I found that there
> is a race between IRQ handler and .suspend , and that I cant let driver
> access the device
> while its in D3 since it can lock up some systems.
>
> Now I am lookin
