On Thu, Apr 19, 2012 at 4:02 AM, Vitaly Wool <vitalywool@xxxxxxxxx> wrote: > I think it looks like a hack. Can you provide a better description of > where this deadlock actually happens? > > If libertas_sdio claims host as a part of its suspend operation from a > context different from the suspend context, isn't it libertas_sdio > that has to be fixed? libertas_sdio performs work in a workqueue during the suspend routine. It doesn't take long, but it is essential. Technically it would be possible to do the same work from the suspend thread without changing context. However, implementation-wise this is quite difficult. We cannot simply blast commands off to the card directly, we have to obey various rules and keep things in sync. This is done with an abstraction layer in the driver which is also shared with equivalent devices that connect over USB, SPI, etc. Sometimes we send commands from atomic context, or asynchronously, so thats why we do things in a workqueue. Breaking this abstraction for the suspend corner-case would be a pain, and I don't agree with the strange requirement that SDIO drivers can't communicate from other contexts in the suspend routine. My thoughts are here: http://article.gmane.org/gmane.linux.kernel.mmc/13899 Ulf, you have understood the problem correctly and your patch solves the issue. Thanks for the fast response. Daniel -- 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
