Hi Andrew, Thanks for your review!
On Wed, Apr 28, 2010 at 11:17 AM, Andrew Morton <a...@linux-foundation.org> wrote: > On Wed, 28 Apr 2010 14:06:08 +0900 Yusuke Goda <yusuke.goda...@renesas.com> > wrote: > >> + time = wait_event_interruptible_timeout(host->intr_wait, >> + host->wait_int == 1 || >> + host->sd_error == 1, host->timeout); >> + if (host->wait_int != 1 && (time == 0 || host->sd_error != 0)) >> + return sh_mmcif_error_manage(host); > > wait_event_interruptible_timeout() will return early with -ERESTARTSYS > if the calling process gets signalled (eg, ^C was hit). > > The driver uses wait_event_interruptible_timeout() rather a lot and the > two sites I looked at seem to handle the signal_pending() case > correctly. > > But incorrectly handling signals with interruptible waits is a > frequently-occurring error in drivers. Did you deliberately cater for > this case, and have you runtime tested it? My plan is to use this driver on SH-Mobile ARM (sh7372), and I'd be happy to fix up the driver to become a bit less non-standard wrt blocking compared to the other MMC host drivers. Is it possible that Goda-san fixes up whatever minor bits that need rework and that you pick up at that point? I'd like to rework the MMCIF blocking code and perhaps also add dmaengine support as feature patches on top of Goda-sans work if that's ok with you. Better PM is also on the TODO. Not sure if any of these features will make it in time for the 2.6.35 merge window though. It would be very useful to have the MMCIF driver as-is in 2.6.35 mainline to begin with if possible. Or do you think the driver needs to be reworked more before that can happen? Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
