Thread (13 messages) 13 messages, 3 authors, 2014-06-01

Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s

From: Alexander Holler <hidden>
Date: 2014-05-15 15:19:46
Also in: lkml

Am 15.05.2014 16:50, schrieb Alexander Holler:
Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help