[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] bug in COMMAND_COMPLETE and COMMAND_STATUS events processing
Johan Zander wrote:
> Oliver, thanks!
> We are currently working on HCI and this is fixed for the upcoming
> release. We are also fixing several possible race situations which
> might occur when running multipoint.
> We want all hci commands that are triggered from btd to block, but
hmm, i'm not an outspoken friend of blocking calls. will the stack
itself be able to handle events (e.g. incoming data, etc.) during a
blocking user call?
have you considered the multipoint scenario with arbitrary apps using
the stack? for example, the inquiry command may take up to 62 seconds
(if i remember correctly). other devices may send during that time. will
there be a (non-)blocking "recevive" in the layers above l2cap?
actually, i want all commands (hci and l2cap) to be non blocking in
callback style. do you see any chance on integating both approaches or
will we be working on different source branches?
> since the Ericsson modules (since P9A) sends the reply on the new
> baudrate we can't have set_ericsson_baudrate() to block. We now it's
> ugly but we don't have a better solution but to bypass the command
how about this? insert the set baudrate command into the command queue
as a regular command through send_cmd(). after sending the command to
the bt-device through bt_write_lower_driver() in send_cmd() check if it
was a set-ericsson-baudrate cmd, and if so call a function in user space
that sets the baudraute of the host uart accordingly (e.g. a
user-registered callback or exported function in btd). proceed with
Oliver Kasten phone: +41/ 1/ 63-2 06 63
ETH-Zurich fax: +41/ 1/ 63-2 16 59
Haldeneggsteig 4, IFW D48.1 email: firstname.lastname@example.org
CH-8092 Zuerich, Switzerland http://www.inf.ethz.ch/~kasten/
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com