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��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
