On Sun, May 26, 2019 at 03:58:19PM -0400, Brian Masney wrote:

I attached a patch that shows how I was able to determine what had
already claimed the host.

I realized this morning that I had a flaw with my test patch that
diagnosed what was deadlocked. The mmc_ctx structure was allocated on
the stack. I attached a second version of that patch that uses
kmalloc() for that structure. It didn't change what I reported
yesterday: brcmf_sdiod_ramrw is deadlocked by
brcmf_sdio_download_firmware.


On Mon, May 27, 2019 at 10:48:24AM +0300, Adrian Hunter wrote:

This is because SDHCI is using the IRQ thread to process the SDIO card
interrupt (sdio_run_irqs()).  When the card driver tries to use the card, it
causes interrupts which deadlocks since c07a48c26519 ("mmc: sdhci: Remove
finish_tasklet") has moved the tasklet processing to the IRQ thread.

I would expect to be able to use the IRQ thread to complete requests, and it
is desirable to do so because it is lower latency.

Probably, SDHCI should use sdio_signal_irq() which queues a work item, and
is what other drivers are doing.

I will investigate some more and send a patch.

Thank you!

Brian