Re: [PATCH v2] Revert "Bluetooth: btusb: mediatek: reset the controller before downloading the fw"

["Geoffrey D. Bennett" <g@b4.vu>]

Hi all,

Sorry, I see that an identical patch has already been applied to
bluetooth-next
https://lore.kernel.org/linux-bluetooth/20250315022730.11071-1-hao.qin@mediatek.com/

While I'm glad the issue is being addressed, my original patch
https://lore.kernel.org/linux-bluetooth/Z8ybV04CVUfVAykH@m.b4.vu/
contained useful context and tags that didn't make it into the final
commit.

For getting this fix into current kernel releases 6.12/6.13/6.14, I
think the patch needs the "Cc: stable@vger.kernel.org" tag that was in
my original submission but missing from Hao's. Since this is causing
significant issues for users on kernels 6.11+ (audio interfaces
failing to work), it's important this gets backported.

Hao, is this something you can do? I think the instructions at
https://www.kernel.org/doc/html/v6.14/process/stable-kernel-rules.html#option-3
need to be followed, but I've not done this before.

Thanks,
Geoffrey.

On Fri, Mar 28, 2025 at 07:22:06AM +1030, Geoffrey D. Bennett wrote:
> This reverts commit ccfc8948d7e4d93cab341a99774b24586717d89a.
> 
> The MediaTek Bluetooth controller reset that was added increases the
> Bluetooth device setup time from ~200ms to ~20s and interferes with
> other devices on the bus.
> 
> Three users (with Focusrite Scarlett 2nd Gen 6i6 and 3rd Gen Solo and
> 4i4 audio interfaces) reported that since 6.11 (which added this
> commit) their audio interface fails to initialise if connected during
> boot. Two of the users confirmed they have an MT7922.
> 
> Errors like this are observed in dmesg for the audio interface:
> 
>   usb 3-4: parse_audio_format_rates_v2v3(): unable to find clock source (clock -110)
>   usb 3-4: uac_clock_source_is_valid(): cannot get clock validity for id 41
>   usb 3-4: clock source 41 is not valid, cannot use
> 
> The problem only occurs when both devices and kernel modules are
> present and loaded during system boot, so it can be worked around by
> connecting the audio interface after booting.
> 
> Fixes: ccfc8948d7e4 ("Bluetooth: btusb: mediatek: reset the controller before downloading the fw")
> Closes: https://github.com/geoffreybennett/linux-fcp/issues/24
> Bisected-by: Benedikt Ziemons <ben@rs485.network>
> Tested-by: Benedikt Ziemons <ben@rs485.network>
> Cc: stable@vger.kernel.org
> Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
> ---
> Changelog:
> 
> v1 -> v2:
> 
> - Updated commit message with additional information.
> - No change to this patch's diff.
> - Dropped alternate patch that only reverted for 0x7922.
> - Chris, Sean, Hao agreed to reverting the change:
>   https://lore.kernel.org/linux-bluetooth/2025031352-octopus-quadrant-f7ca@gregkh/T/#m0b31a9a8e87b9499e1ec3370c08f03e43bfb54bf
> 
>  drivers/bluetooth/btmtk.c | 10 ----------
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 68846c5bd4f7..4390fd571dbd 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -1330,13 +1330,6 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>  		break;
>  	case 0x7922:
>  	case 0x7925:
> -		/* Reset the device to ensure it's in the initial state before
> -		 * downloading the firmware to ensure.
> -		 */
> -
> -		if (!test_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags))
> -			btmtk_usb_subsys_reset(hdev, dev_id);
> -		fallthrough;
>  	case 0x7961:
>  		btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
>  				      fw_version, fw_flavor);
> @@ -1345,12 +1338,9 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>  						btmtk_usb_hci_wmt_sync);
>  		if (err < 0) {
>  			bt_dev_err(hdev, "Failed to set up firmware (%d)", err);
> -			clear_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags);
>  			return err;
>  		}
> 
> -		set_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags);
> -
>  		/* It's Device EndPoint Reset Option Register */
>  		err = btmtk_usb_uhw_reg_write(hdev, MTK_EP_RST_OPT,
>  					      MTK_EP_RST_IN_OUT_OPT);
> --
> 2.45.0
> 
> 
>