Hi Logic,
I am helping Tedd to test this patch now, but I have a question about this patch.
For your comment It looks like you want to send HCI RESET command to controller first when BT enabled, then I found below patch also do same thing as your patch. May I know any difference for your patch? Thanks.
commit dffd30ee9619ccd7153f1861ba0436bbc4400f36
Author: Tedd Ho-Jeong An <tedd.an@xxxxxxxxx>
Date: Fri Apr 19 09:57:43 2013 -0700
Bluetooth: Add support for Intel Bluetooth device [8087:07dc]
This patch adds support for Intel Bluetooth device by adding
btusb_setup_intel() routine that update the device with ROM patch.
...
..
+static int btusb_setup_intel(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ const struct firmware *fw;
+ const u8 *fw_ptr;
+ int disable_patch;
+ struct intel_version *ver;
+
+ const u8 mfg_enable[] = { 0x01, 0x00 };
+ const u8 mfg_disable[] = { 0x00, 0x00 };
+ const u8 mfg_reset_deactivate[] = { 0x00, 0x01 };
+ const u8 mfg_reset_activate[] = { 0x00, 0x02 };
+
+ BT_DBG("%s", hdev->name);
+
+ /* The controller has a bug with the first HCI command sent to it
+ * returning number of completed commands as zero. This would stall the
+ * command processing in the Bluetooth core.
+ *
+ * As a workaround, send HCI Reset command first which will reset the
+ * number of completed commands and allow normal command processing
+ * from now on.
+ */
+ skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ BT_ERR("%s sending initial HCI reset command failed (%ld)",
+ hdev->name, PTR_ERR(skb));
+ return -PTR_ERR(skb);
+ }
+ kfree_skb(skb);
Regards,
Ethan
-----Original Message-----
From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-owner@xxxxxxxxxxxxxxx] On Behalf Of An, Tedd
Sent: Friday, June 05, 2015 3:56 AM
To: Poulain, Loic
Cc: Marcel Holtmann; linux-bluetooth@xxxxxxxxxxxxxxx
Subject: Re: [PATCHv2] Bluetooth: btusb: Fix Intel controller hang after shutdown
Hi Loic
On 6/4/15, 4:59 AM, "Poulain, Loic" <loic.poulain@xxxxxxxxx> wrote:
>Hi tedd,
>
>On 21/05/2015 21:56, Marcel Holtmann wrote:
>> Hi Tedd,
>>
>>> The vendor command (0xfc3f) in btusb_shutdown_intel causes an
>>> internal reset with old firmware. After that, upcoming HCI command
>>> will hang due to a controller bug with the first HCI command sent to it.
>>> The workaround is to send HCI Reset command first which will reset
>>> the number of completed commands.
>>>
>>> Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxx>
>>> ---
>>> v2: Send HCI reset from shutdown instead of using
>>> HCI_QUIRK_RESET_ON_CLOSE drivers/bluetooth/btusb.c | 13
>>> +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>> index d21f3b4..589f30c 100644
>>> --- a/drivers/bluetooth/btusb.c
>>> +++ b/drivers/bluetooth/btusb.c
>>> @@ -2705,6 +2705,19 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
>>> }
>>> kfree_skb(skb);
>>>
>>> + /* The 0xfc3f command causes an internal reset with old firmware.
>>> + * In order to avoid the Bug with the first HCI command, we have
>>> + * to send a HCI reset which will reset the number of completed
>>> + * command.
>>> + */
>>> + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
>>> + if (IS_ERR(skb)) {
>>> + BT_ERR("%s: Shutdown HCI reset command failed (%ld)",
>>> + hdev->name, PTR_ERR(skb));
>>> + return PTR_ERR(skb);
>>> + }
>>> + kfree_skb(skb);
>>> +
>> please test this change and see if it still has the desired effect. ACK or NACK the patch based on your testing.
>>
>> Regards
>>
>> Marcel
>>
>
>Any chance you test this patch?
I missed your patch and just got it. I will run this test and let you know the result.
>
>Regards,
>Loic
>
>--
>Intel Open Source Technology Center
>http://oss.intel.com/
>
{.n + +% lzwm b 맲 r zX h b ^n r z h & G h ( 階 ݢj" m z ޖ f h ~ m
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
