[0/2] Fix for MediaTek reset affecting Focusrite audio interfaces

This series (choose 1 of the 2 patches) addresses an issue where the
MT7922 Bluetooth controller reset added in commit ccfc8948d7e4
("Bluetooth: btusb: mediatek: reset the controller before downloading
the fw") is causing Focusrite USB audio devices to fail to initialise
when connected during boot on kernels 6.11 and newer.

Reported by three users here:
https://github.com/geoffreybennett/linux-fcp/issues/24

Two users confirmed they have an MT7922.

I'm providing two possible solutions as I note there was a similar
change made in commit a7208610761a ("Bluetooth: btmtk: Remove
resetting mt7921 before downloading the fw"), so I'm not sure if the
reset should be reverted for the MT7925 as well as the MT7922.

Option 1: Revert the problematic reset behaviour entirely (MT7922 +
MT7925)

Option 2: Remove the reset only for the MT7922

Geoffrey D. Bennett (2):

  [PATCH 1/2] Revert "Bluetooth: btusb: mediatek: reset the controller
    before downloading the fw"

  [PATCH 2/2] Bluetooth: btmtk: Remove resetting mt7922 before
    downloading the fw

--
2.45.0

On Sun, Mar 09, 2025 at 06:02:11AM +1030, Geoffrey D. Bennett wrote:
> This series (choose 1 of the 2 patches) addresses an issue where the
> MT7922 Bluetooth controller reset added in commit ccfc8948d7e4
> ("Bluetooth: btusb: mediatek: reset the controller before downloading
> the fw") is causing Focusrite USB audio devices to fail to initialise
> when connected during boot on kernels 6.11 and newer.
> 
> Reported by three users here:
> https://github.com/geoffreybennett/linux-fcp/issues/24
> 
> Two users confirmed they have an MT7922.
> 
> I'm providing two possible solutions as I note there was a similar
> change made in commit a7208610761a ("Bluetooth: btmtk: Remove
> resetting mt7921 before downloading the fw"), so I'm not sure if the
> reset should be reverted for the MT7925 as well as the MT7922.
> 
> Option 1: Revert the problematic reset behaviour entirely (MT7922 +
> MT7925)
> 
> Option 2: Remove the reset only for the MT7922
> 
> Geoffrey D. Bennett (2):
> 
>   [PATCH 1/2] Revert "Bluetooth: btusb: mediatek: reset the controller
>     before downloading the fw"
> 
>   [PATCH 2/2] Bluetooth: btmtk: Remove resetting mt7922 before
>     downloading the fw
> 
> --
> 2.45.0
> 
>

Hi Geoffrey,

I understand there's no apparent nexus of causality here.

However if three different users suddenly reported the same problem and
the fix fixes it, we should take the report seriously and back down
on the problematic commit until we figure for sure what the heck is
going on.

My bet is this is bona fide bug in the USB subsystem, but either I'm not
looking hard enough or I'm looking into the wrong places, because
there's no way I can see in which way USB bluetooth driver from
MediaTek could cause clock detection to fail.

No point in pressing this harder, but yeah, take the reports more than
seriously, because if we don't understand in which way our own (Linux)
code could be causing this, at least we should take cautionary measures.

In that sense, putting Takashi Iwai and Greg KH to Cc: in a modest but
sincere belief that this issue is more than real, even though it looks
like anticipated April 1st. Takashi can help with his expertise in clock
detection and Greg could help pinpoint if this is indeed madness in the
USB subsystem.

Hope you and them don't mind the escalation :)

Thanks,
Geraldo Nascimento