lkml.org 
[lkml]   [2014]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 16:50, schrieb Alexander Holler:
> Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:

>> This timeout seems arbitrary so I suppose we can increase it if we
>> feel it is necessary but we used already different timeout for
>> different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
>> identify which command is more likely to timeout.
>>
>> We could perhaps auto reset if a command timeout if there is really no
>> other way to recover.
>
> It is arbitrary but 2s is not enough here. And as I've written in the
> description, there is absolutely no reason to keep this timeout
> unnecessarily short. No one cares if an error message appears after 2s
> or 8s if the communication with the dongle is in both cases broken
> afterwards.
>
> One of the commands I experieced the problem with was e.g.
> HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE.

The problem is that you can never be sure what the origin of a timeouted
command was. It might have been e.g. the USB-subsystem through wich the
command and the response has to travel (in case of USB dongles) and not
the dongle itself.

Regards,

Alexander Holler


\
 
 \ /
  Last update: 2014-05-15 18:21    [W:0.087 / U:1.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site