On Wed, 2020-06-03 at 14:47 +0200, Takashi Iwai wrote: > On Wed, 03 Jun 2020 14:39:24 +0200, > Macpaul Lin wrote: > > > > On Wed, 2020-06-03 at 10:45 +0200, Takashi Iwai wrote: > > > On Wed, 03 Jun 2020 08:54:51 +0200, > > > Takashi Iwai wrote: > > > > > > > > On Wed, 03 Jun 2020 08:28:09 +0200, > > > > Takashi Iwai wrote: > > > > > > > > > > And, the most suspicious case is the last one, > > > > > chip->num_suspended-intf. It means that the device has multiple > > > > > USB interfaces and they went to suspend, while the resume isn't > > > > > performed for the all suspended interfaces in return. > > > > > > > > If this is the cause, a patch like below might help. > > > > It gets/puts the all assigned interfaced instead of only the primary > > > > one. > > > > > > ... and considering of the problem again, rather the patch below might > > > be the right answer. Now the driver tries to remember at which state > > > it entered into the system-suspend. Upon resume, in return, when the > > > state reaches back to that point, set the card state to D0. > > > > > > The previous patch can be applied on the top, too, and it might be > > > worth to apply both. > > > > > > Let me know if any of those actually helps. > > > > > > > > > Takashi > > > > Thanks for your response so quickly. > > I've just test this patch since it looks like enough for the issue. > > Good to hear! > > > This patch worked since the flag system_suspend will be set at the same > > time when power state has been changed. I have 2 interface with the head > > set. But actually the problem happened when primary one is suspended. > > Currently the autosuspend is set only to the primary interface; IOW, > the other interfaces will never get autosuspend, and the another > suspend-all-intf patch should improve that situation. But it won't > fix your actual bug, obviously :) > > > So I didn't test the earlier patch "suspend all interface instead of > > only the primary one." > > Could you try it one on top of the last patch? At least I'd like to > see whether it causes any regression. I've tried both of these 2 patches together, and it looks okay. > > Will you resend this patch officially later? I think this solution is > > required to send to stable, too. It's better to have it for other stable > > kernel versions include android's. > > Yes, that's a general bug and worth to be merged quickly. > I'm going to submit a proper patch soon later. > > > thanks, > > Takashi > Thanks! Macpaul Lin
