On Wed, Jun 14, 2023 at 9:22 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Wed, Jun 14, 2023 at 2:22 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Wed, 14 Jun 2023 at 13:17, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > > > > On Wed, Jun 14, 2023 at 12:05 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > > > > However, we use the spin_lock to protect some members in the struct > > > > mmci_host. In this case, the mmci_cmd_irq() is using "host->cmd" to > > > > understand whether there is an active command to manage. When the > > > > command has been completed, we set host->cmd to NULL. > > > > > > Hm right... > > > > > > I'm leaning toward some catch-all like: > > > > > > if (!host->cmd) > > > state = MMCI_BUSY_DONE; > > > > > > as if there is no command going on then surely nothing is busy on the > > > host controller. > > > > Right, so at what point do you want to add this check? > > I have put it before the calls to the busy_complete() callback, in the > IRQ, where we are already in atomic context. If we are not processing > a command, we should not do any busy detection for sure. No that's wrong. The mmci_cmd_irq() is actually passed the command as parameter, so I just augment the busy_complete() prototype to pass this along down, check out the patch (I talk to much). Yours, Linus Walleij
