Hi Mingyen, On Wed, Dec 20, 2023 at 3:22 AM Mingyen Hsieh <mingyen.hsieh@xxxxxxxxxxxx> wrote: > > From: Ming Yen Hsieh <mingyen.hsieh@xxxxxxxxxxxx> > > An ongoing command may be interrupted if suspended, leading to a > command timeout. Add a lock to the suspend function in order to > protect the ongoing command from being interrupted. > > Signed-off-by: Leon Yen <leon.yen@xxxxxxxxxxxx> > Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@xxxxxxxxxxxx> > --- > drivers/net/wireless/mediatek/mt76/mt7921/pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c > index 57903c6e4f11..e1c53f18abdc 100644 > --- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c > +++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c > @@ -409,7 +409,9 @@ static int mt7921_pci_suspend(struct device *device) > if (err < 0) > goto restore_suspend; > > + mt792x_mutex_acquire(dev); > err = mt76_connac_mcu_set_hif_suspend(mdev, true); > + mt792x_mutex_release(dev); I had assumed that all commands would finish up before the suspend handler is called, given that processes are frozen before the suspension can progress. Could you provide more details on the specific conflict between these two commands and how it results in the command timeout? Moreover, while I understand you've identified some potential issues, I suggest we work towards a comprehensive solution to address timeouts caused by potential command conflicts, not just for the specific command. For instance, we should take into account other MCU commands during suspension and extend this consideration to similar scenarios in SDIO suspension. > if (err) > goto restore_suspend; > > -- > 2.18.0 > >
