> instrumented and exercised. So if this seems like a wart I'll remove
> it.
Not it seems like a nasty and subtle problem, but the code you have now
won't fix it merely limit it.
If your suspend code and your mrdy code both did
mutex_lock(&some_mutex);
if (!suspended) {
mrdy
}
mutex_unlock(&some_mutex);
and
mutex_lock(&some_mutex);
suspended = 1;
suspend_chip
mutex_unlock(&some_mutex)
I think that would make the race between testing and suspend go away.
> >Ok that wants fixing in the SPI code, otherwise we have to fix every
> >SPI device for the same thing which is bonkers.
> >
> >Ok that requires more thought on how to do it properly.
> >
> [Gorby, Russ] OK, let me know what you think.
>
> >> >> + clear_bit(IFX_SPI_STATE_IO_RETRY, &(ifx_dev->flags));
> >> >> + del_timer(&ifx_dev->spi_retry_timer);
> >> >
> >> >And if the timer handler is running in parallel on another CPU
> >> >isn't this going to cause confusion ?
> >>
> >> [Gorby, Russ] That shouldn't be possible - unless you see
> >> something I do not. There can be only one SPI msg being processed
> >> at a time, and one tasklet running. The tasklet is the only thing
> >> that calls spi_async. Spi_complete runs only if spi_async
> >> succeeded or returned something other than EBUSY and the retry
> >> timer runs only if spi_async returned EBUSY.
> >
> >Ok so in fact at the point you hit the del_timer the timer cannot in
> >fact be running anyway but must have completed already ?
>
> [Gorby, Russ] correct
Makes sense - might be worth adding a
WARN_ON(timer_pending(&ifx_dev->spi_retry_timer));
before the del_timer, as it would both add a good debug check and
document very clearly the design assumption.
> [Gorby, Russ] I agree with you and would I like to resolve that
> situation asap, but I can't do any of that until the critical
> functional changes are accepted to meego which has pretty much
> stopped at this point as far as I can tell. I have multiple
> functionality and bugfix patches I would like to submit but until I
> know what exactly has been merged to meego I don't know how to craft
> the patches as they're all mostly against the same driver and are
> inherently serial for the most part.
One for Arjan, but I believe Meego is likewise not including pw_spi3
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
