lkml.org 
[lkml]   [2020]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] mwifiex: fix mwifiex_shutdown_sw() causing sw reset failure
From
Date
On Sun, 2020-11-08 at 13:31 +0200, Kalle Valo wrote:
> Tsuchiya Yuto <kitakar@gmail.com> writes:
>
> > When FLR is performed but without fw reset for some reasons (e.g. on
> > Surface devices, fw reset requires another quirk), it fails to reset
> > properly. You can trigger the issue on such devices via debugfs entry
> > for reset:
> >
> > $ echo 1 | sudo tee /sys/kernel/debug/mwifiex/mlan0/reset
> >
> > and the resulting dmesg log:
> >
> > [ 45.740508] mwifiex_pcie 0000:03:00.0: Resetting per request
> > [ 45.742937] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 3
> > [ 45.744666] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex...
> > [ 45.751530] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.751539] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771691] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771695] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 45.771697] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771698] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 45.771699] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771701] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 45.771702] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771703] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 45.771704] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771705] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 45.771707] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed
> > [ 45.771708] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 53.099343] mwifiex_pcie 0000:03:00.0: info: trying to associate to '[SSID]' bssid [BSSID]
> > [ 53.241870] mwifiex_pcie 0000:03:00.0: info: associated to bssid [BSSID] successfully
> > [ 75.377942] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> > [ 85.385491] mwifiex_pcie 0000:03:00.0: info: successfully disconnected from [BSSID]: reason code 15
> > [ 87.539408] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> > [ 87.539412] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 99.699917] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> > [ 99.699925] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [ 111.859802] mwifiex_pcie 0000:03:00.0: cmd_wait_q terminated: -110
> > [ 111.859808] mwifiex_pcie 0000:03:00.0: deleting the crypto keys
> > [...]
> >
> > When comparing mwifiex_shutdown_sw() with mwifiex_pcie_remove(), it
> > lacks mwifiex_init_shutdown_fw().
> >
> > This commit fixes mwifiex_shutdown_sw() by adding the missing
> > mwifiex_init_shutdown_fw().
> >
> > Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
> > Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com>
>
> Otherwise looks good to me, but what is FLR? I can add the description
> to the commit log if you tell me what it is.
>

Thanks! It's a PCIe Function Level Reset (FLR). In addition to this,
it may be better to add a vendor name (Microsoft) of the devices where
we observed this issue?
(The other patch I sent also lacks the vendor name [1])

Based on the two improvements, I think the commit log should look like
this (also fixed some grammatical errors):

When a PCIe function level reset (FLR) is performed but without fw reset
for some reasons (e.g., on Microsoft Surface devices, fw reset requires
other quirks), it fails to reset wifi properly. You can trigger the issue
on such devices via debugfs entry for reset:
[...]

I'd appreciate it if you could add the above changes (and/or your changes
if required). I can also resend this series if this is more preferable.

[1] [PATCH] mwifiex: pcie: skip cancel_work_sync() on reset failure path
https://lore.kernel.org/linux-wireless/20201028142346.18355-1-kitakar@gmail.com/


\
 
 \ /
  Last update: 2020-11-08 13:20    [W:0.046 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site