On 18/08/16 01:12, Christopher Freeman wrote: > On 08-17 01:31 PM, Robert Foss wrote: >> >> >> On 2016-08-17 06:47 AM, Adrian Hunter wrote: >>> On 17/08/16 00:25, robert.foss@xxxxxxxxxxxxx wrote: >>>> From: Christopher Freeman <cfreeman@xxxxxxxxxx> >>>> >>>> wait_event_interruptible_timeout() will return early if the blocked >>>> process receives a signal, causing the driver to abort the tuning >>>> procedure and possibly leaving the controller in a bad state. Since the >>>> tuning command is expected to complete quickly (<50ms) and we've set a >>>> timeout, use wait_event_timeout() instead. >>>> >>>> Signed-off-by: Christopher Freeman <cfreeman@xxxxxxxxxx> >>>> Tested-by: Robert Foss <robert.foss@xxxxxxxxxxxxx> >>>> Signed-off-by: Robert Foss <robert.foss@xxxxxxxxxxxxx> >>>> Reviewed-by: Benson Leung <bleung@xxxxxxxxxxxx> >>> >>> The mmc block queues are kernel threads which I would expect ignore signals, >>> so I am curious how you hit this? >> >> The issue was discovered on (tegra2?) hardware that is sensitive to >> being interrupted during tuning and having the controller left in a >> sensitive state. >> >> @Christopher Freeman: Maybe you can provide us with some additional details? >> > > It was found with Tegra 210. The signalling was an issue because tuning was > kicked off from an ioctl to the wifi device on the controller. > > FWIW, this issue was particular to the wifi driver (bcmdhd) and the android > tree. It in part depends on the way the wifi driver is able to reset the > sdio device via a routine that's not present in mainline: sdio_reset_comm. > I believe the wifi driver would power on the wifi chip and trigger tuning in > the aforementioned ioctl. Process that sent the ioctl was some network or wifi > manager service on Android. > > Let me know if you would like any more details. Thanks for the explanation. > >>> >>> In any case: >>> >>> Acked-by: Adrian Hunter <adrian.hunter@xxxxxxxxx> >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html