Hi Tony,
> -----Original Message-----
> From: Tony Chuang
> Sent: Thursday, May 07, 2020 12:26 PM
> To: Sebastian Andrzej Siewior
> Cc: kvalo@xxxxxxxxxxxxxx; Pkshih; linux-wireless@xxxxxxxxxxxxxxx; briannorris@xxxxxxxxxxxx; Kevin
> Yang
> Subject: RE: [PATCH 28/40] rtw88: 8723d: Add shutdown callback to disable BT USB suspend
>
> Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> writes
> > On 2020-05-06 02:35:21 [+0000], Tony Chuang wrote:
> > > > On 2020-04-17 15:46:41 [+0800], yhchuang@xxxxxxxxxxx wrote:
> > > > > From: Ping-Ke Shih <pkshih@xxxxxxxxxxx>
> > > > >
> > > > > Without this patch, wifi card can't initialize properly due to BT in USB
> > > > > suspend state. So, we disable BT USB suspend (wakeup) in shutdown
> > callback
> > > > > that is the moment before rebooting. To save BT USB power, we can't do
> > this
> > > > > in 'remove' callback.
> > > >
> > > > So you can't initialize the USB part because it is in suspend and the
> > > > only way to avoid it to disable it on the PCI side. That means you don't
> > > > see it enumerated on the USB bus at all?
> > >
> > > Yes, if we don't disable it on PCI side, then the USB part cannot be
> > > probed on USB bus.
> >
> > We talk here about USB's runtime-suspend / autosuspend? If so, are you
> > aware of commit
> > 7ecacafc24063 ("Bluetooth: btusb: Disable runtime suspend on Realtek
> > devices")
> >
> > or is this an attempt to get rid of this change in favour of this one
> > (so that the device can enter suspend-mode)?
> >
>
> Ping-Ke, can you please help to check on this ?
> Looks like Kai-Heng is doing the much same thing here.
>
The Kai-Heng's patch turns off suspend entirely, so I believe if the patch
is existing, this patch doesn't affect the result.
However, the patch seems like a temporal fix, so this patch is needed.
> But it's still worth to do it in wifi side I think, because it's difficult to
> make sure the synchronization of BT and Wifi patch.
>
Agree.
Thank you
PK
