Looking at this a bit further, I see a discrepancy between the code in
function hci_conn_complete_evt and hci_sync_conn_complete_evt.
Is this intentional or a bug ? Like I said below, using
hci_conn_complete_evt (when the AG doesn't support eSCO) results in
the connect() never returning because the socket state is not updated.
//hci_conn_complete_evt
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
hci_conn_del(conn);
}
unlock:
hci_dev_unlock(hdev);
hci_conn_check_pending(hdev);
}
//hci_sync_conn_complete_evt.
hci_proto_connect_cfm(conn, ev->status);
if (ev->status)
hci_conn_del(conn);
unlock:
hci_dev_unlock(hdev);
}
Any pointers / hints ?
Thanks
Jaikumar
On Wed, Dec 17, 2008 at 2:07 PM, jaikumar Ganesh <jaikumarg@xxxxxxxxx> wrote:
> Folks,
> I have a device which supports only SCO connections. So when the
> application calls sco_sock_connect -> sco_connect, the conn->state is
> set to BT_CONNECT and then bt_sock_state is called waiting for the
> conn->sk->sk_state to be set to BT_CONNECTED.
> When the HCI Connection Complete event comes, the conn->state is
> set to BT_CONNECTED.
>
> In 2.6.25 -> hci_proto_connect_cfm(conn, ev->status) was called
> at the end of hci_conn_complete_evt which used to set the
> conn->sk->sk_state to BT_CONNECTED in sco_conn_ready.
> In 2.6.27-> hci_proto_connect_cfm(conn, ev->status) is called
> only if the ev_status is 1.
> Hence, the conn->sk->sk_state doesn't get set to
> BT_CONNECTED and hence the connect() times out.
>
> Should we be calling sco_conn_ready in sco_connect similar to
> sco_connect_cfm if conn != null ?
> I didn't see anyone else complain so am I missing something obvious ?
>
>
> * I am new to this list so please excuse me if the above doesn't
> make sense.
>
> Thanks
> Jaikumar
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
