diff options
author | Gustavo F. Padovan <padovan@profusion.mobi> | 2010-05-04 23:16:01 -0300 |
---|---|---|
committer | Marcel Holtmann <marcel@holtmann.org> | 2010-05-10 09:28:53 +0200 |
commit | 844c0972427ee5f661158160aaca10b22b3dda60 (patch) | |
tree | b4e7694efc8dbfbc88ecfcca97a2381f0144c046 /include/net | |
parent | 4178ba462a3e8ab5094e69606f01d9e95f2d5ea6 (diff) | |
download | kernel_samsung_aries-844c0972427ee5f661158160aaca10b22b3dda60.zip kernel_samsung_aries-844c0972427ee5f661158160aaca10b22b3dda60.tar.gz kernel_samsung_aries-844c0972427ee5f661158160aaca10b22b3dda60.tar.bz2 |
Bluetooth: Fix spec error in the RemoteBusy Logic
On the receipt of an RR(P=1) under RemoteBusy set to TRUE(on the RECV
state table) we have to call sendIorRRorRNR(F=1) and just after set
RemoteBusy to False. This leads to a freeze in the sending process since
it's not allowed send data with RemoteBusy set to true and no one
call SendPending-I-Frames after set RemoteBusy to false(The last action
for that event).
Actually sendIorRRorRNR() calls SendPending-I-Frames but at that moment
RemoteBusy is still True and we cannot send any frame, after, no one
calls SendPending-I-Frames again and the sending process stops.
The solution here is to set RemoteBusy to false inside
SendPending-I-Frames just before call SendPending-I-Frames. That will
make SendPending-I-Frames able to send frames. This solution is similar
to what RR(P=0)(F=0) on the RECV table and RR(P=1) on the SREJ_SENT
table do.
Actually doesn't make any sense call SendPending-I-Frames if we can send
any frame, i. e., RemoteBusy is True.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'include/net')
0 files changed, 0 insertions, 0 deletions