Hi Koba,
> With Intel AC9560, follow this scenario and can't turn on bt since.
> 1. turn off BT
> 2. then suspend&resume multiple times
> 3. turn on BT
>
> Get this error message after turn on bt.
> [ 877.194032] Bluetooth: hci0: urb 0000000061b9a002 failed to resubmit (113)
> [ 886.941327] Bluetooth: hci0: Failed to read MSFT supported features (-110)
>
> Remove msft from compilation would be helpful.
> Turn off msft would be also helpful.
>
> As per Intel's comment, For AC9560, in JSL the hw_variant is 0x13.
> In GLK, the hw_variant is 0x11. can't use hw_variant to filter for
> AC9560.
> Only AC9560 encounter this issue, so add a reject table to
> disable msft for AC9560.
>
> Signed-off-by: Koba Ko <koba.ko@xxxxxxxxxxxxx>
> ---
> drivers/bluetooth/btusb.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index a9855a2dd561..3c131fd40869 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -479,6 +479,11 @@ static const struct usb_device_id blacklist_table[] = {
> { } /* Terminating entry */
> };
>
> +static const struct usb_device_id msft_rej_table[] = {
> + { USB_DEVICE(0x8087, 0x0aaa) },
> + { } /* Terminating entry */
> +};
> +
> /* The Bluetooth USB module build into some devices needs to be reset on resume,
> * this is a problem with the platform (likely shutting off all power) not with
> * the module itself. So we use a DMI list to match known broken platforms.
> @@ -2851,6 +2856,7 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
> char ddcname[64];
> int err;
> struct intel_debug_features features;
> + struct usb_device_id *match;
>
> BT_DBG("%s", hdev->name);
>
> @@ -2928,7 +2934,9 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
> case 0x12: /* ThP */
> case 0x13: /* HrP */
> case 0x14: /* CcP */
> - hci_set_msft_opcode(hdev, 0xFC1E);
> + match = usb_match_id(data->intf, msft_rej_table);
> + if (!match)
> + hci_set_msft_opcode(hdev, 0xFC1E);
> break;
> }
actually _no_, we are not doing this either.
We just got rid of the per USB VID:PID mess around Intel hardware and I don’t want to add it back. The Intel guys need to figure this out, otherwise, we remove 0x14 /* CcP */ from the list of MSFT extension support.
Regards
Marcel
