Hello.
On p?tek 1. prosince 2023 9:19:04 CET Kris Karas (Bug Reporting) wrote:
> Bagas Sanjaya wrote:
> > Kris Karas (Bug Reporting) wrote:
> >> I have a regression going from mainline kernel 6.1.62 to 6.1.63, and also
> >> from kernel 6.6.1 to 6.6.2; I can bisect if patch authors can't locate the
> >> relevant commit. In the most recent kernels mentioned, bluetooth won't
> >> function.
> >
> > Then please do bisection; without it, nobody will look into this properly.
>
> As only a few people are reporting this, it must be pretty
> hardware-specific (or perhaps Kconfig/firmware specific). I'll do a
> bisect. A bit too late here in Boston (03:00), and kiddo's birthday
> "later today", so will probably get to this on the weekend.
>
> > You may also want to check current mainline (v6.7-rc3) to see if this
> > regression have already been fixed.
>
> Just tried 6.7.0-rc3, and it is also affected.
Does passing `btusb.enable_autosuspend=N` via a kernel cmdline help? [1]
[1] https://lore.kernel.org/lkml/[email protected]/
> I hadn't git-pulled my linux-stable since May, so that gave me a good
> chance to test the very latest. :-) And conveniently I'm now set for
> the bisect.
>
> Kris
>
>
--
Oleksandr Natalenko (post-factum)
[ Replying to both Oleksandr and Basavaraj ]
Oleksandr Natalenko wrote:
> Does passing `btusb.enable_autosuspend=N` via a kernel cmdline help? [1]
Yes, this works around the problem. Should be a good short-term
solution for those folks who need to wait for distro kernels to catch
up. Thanks.
Basavaraj Natikar wrote:
>> Can we enable RPM on specific controllers for AMD xHC 1.1
>> instead to cover all AMD xHC 1.1?
>>
>> Please find below the proposed changes and let me know if it is OK?
>
> sorry its
> pdev->device == 0x43f7
Thanks, Basavaraj! Yes, this fixes the problem on my hardware (by
making application of PM more selective). Running successfully at the
moment using your (pdev->device amended) patch.
Kris