Received-SPF: pass (google.com: domain of linux-wireless+bounces-9010-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240527173454.459264-1-marcin.slusarz@gmail.com>
 <9bfc8f01e99b43e485b2afc6ae4fd661@realtek.com> <CA+GA0_sQ_Bnp8CUq1Pmxf7zut1Kocaxbw4iXT4hYC5_ceXb7WQ@mail.gmail.com>
 <3cc9cc75468d487c988dbacd8dfc5f57@realtek.com> <CA+GA0_tUy0EuXm0CGYa8SsS78oRNHUanBNwRf_BLXERa1=MYdg@mail.gmail.com>
 <b9c85972ab634364bf8a705a4f4513fd@realtek.com> <CA+GA0_v1rpoFrRVxpKpYqOrjdxEecn_m3+RKwxYc9H761dpMvw@mail.gmail.com>
 <6267f0999f34475ab21d0c42707f1bd9@realtek.com>
In-Reply-To: <6267f0999f34475ab21d0c42707f1bd9@realtek.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Fri, 14 Jun 2024 13:42:08 +0200
Message-ID: <CA+GA0_tpf4zrdvUEVEpiF7KPO_XRcwRXPbJbgnt40LiM+i2YPA@mail.gmail.com>
Subject: Re: wifi: rtw88: 8821CU hangs after some number of power-off/on cycles
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, =?UTF-8?Q?Marcin_=C5=9Alusarz?= <mslusarz@renau.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

wt., 4 cze 2024 o 02:50 Ping-Ke Shih <pkshih@realtek.com> napisa=C5=82(a):
>
> Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > > >
> > > > I'm asking because if we are going in this direction, there's somet=
hing
> > > > more to fix... With your v2, very frequently, I hit WARN_ON(!local-=
>started) in
> > > > ieee80211_rx_napi (in wireless-next, the code was moved to ieee8021=
1_rx_list).
> > > >
> > > > With my patch, I checked and hit that WARN_ON, too, but very occasi=
onally.
> > > >
> > > > I think the difference is in what happens in rtw_ips_enter - I disa=
bled only
> > > > the power_off, but you also disabled everything else, including the=
 cancelation
> > > > of work_structs.
> > > >
> > > > The warning itself sounds harmless, but I think users should never =
see such
> > > > warnings, so this needs to be fixed somehow. Probably some addition=
al
> > > > work_struct(s) need to be canceled?
> > > >
> > >
> > > I forgot to say my patch is compiled test only, and I didn't consider=
 flow
> > > too much, just to close the behavior of your patches. You can improve=
 my patch
> > > to be more reliable to avoid WARN_ON().
> >
> > Two variants of the patch that fix this issue will follow. They are
> > built on top of yours
> > v2 and my "wifi: rtw88: schedule rx work after everything is set up"
> > from the other thread.
> > Please choose the one you like more :).
>
> The patch "wifi: rtw88: usb: drop rx skbs when device is not running" is
> to drop all skb it receives. USB is still working, so I don't prefer this=
.
>
> "wifi: rtw88/usb: stop rx work before potential power off" seems to stop
> RX. But how rtw_usb_cancel_rx_bufs() can stop RX? Remove RX urb to stop i=
t?

Yes, URBs are removed, so the buffers will not be filled in, and
completion callbacks will not be called.

> Not sure if this is regular method for USB devices?

I'm not sure, either. Ideally, it should be disabled in hardware, but
AFAIK there's no public documentation for this chip, so no way for me
to figure out how to do it, and we are dealing with a case of power
management failure here.

> By the way, please take and refine my v2 patch into your patchset. That w=
ill
> be easier to me to merge patches finally.
>
> Ping-Ke
>