how bluez supports ESCO link?

how bluez supports ESCO link?

[Shi Buyun-FVBP83]

hi, all
In the current linux 2.6.25 kernel code, can Bluez setup ESCO link?
I found in net/bluetooth/sco.c, sco_connect defined as:

static int sco_connect(struct sock *sk)
{
 if (lmp_esco_capable(hdev) && !disable_esco)
  type = ESCO_LINK;
 else
  type = SCO_LINK;
 
 hcon = hci_connect(hdev, type, dst, HCI_AT_NO_BONDING);
 }
this code shows bluez supports ESCO link.
 
But in function struct hci_conn * hci_connect(struct hci_dev *hdev, int
type, bdaddr_t *dst)
{
 if (type == SCO_LINK) {
  struct hci_conn *sco;
 
  if (!(sco = hci_conn_hash_lookup_ba(hdev, SCO_LINK, dst))) {
   if (!(sco = hci_conn_add(hdev, SCO_LINK, dst))) {
    hci_conn_put(acl);
    return NULL;
   }
  }
  acl->link = sco;
  sco->link = acl;
 
  hci_conn_hold(sco);
 
  if (acl->state == BT_CONNECTED && 
    (sco->state == BT_OPEN || sco->state == BT_CLOSED))
   hci_add_sco(sco, acl->handle);
 
  return sco;
 } else {
  return acl;
 }
} 
the else switch shows it does nothing when type NOT equal to SCO_LINK.
Should this code need to modify or this is intended to designed?
 
Brs
Shi Buyun

Re: how bluez supports ESCO link?

[Marcel Holtmann]

Hi,

> In the current linux 2.6.25 kernel code, can Bluez setup ESCO link?
> I found in net/bluetooth/sco.c, sco_connect defined as:
> 
> static int sco_connect(struct sock *sk)
> {
>  if (lmp_esco_capable(hdev) && !disable_esco)
>   type = ESCO_LINK;
>  else
>   type = SCO_LINK;
>  
>  hcon = hci_connect(hdev, type, dst, HCI_AT_NO_BONDING);
>  }
> this code shows bluez supports ESCO link.
>  
> But in function struct hci_conn * hci_connect(struct hci_dev *hdev, int
> type, bdaddr_t *dst)
> {
>  if (type == SCO_LINK) {
>   struct hci_conn *sco;
>  
>   if (!(sco = hci_conn_hash_lookup_ba(hdev, SCO_LINK, dst))) {
>    if (!(sco = hci_conn_add(hdev, SCO_LINK, dst))) {
>     hci_conn_put(acl);
>     return NULL;
>    }
>   }
>   acl->link = sco;
>   sco->link = acl;
>  
>   hci_conn_hold(sco);
>  
>   if (acl->state == BT_CONNECTED && 
>     (sco->state == BT_OPEN || sco->state == BT_CLOSED))
>    hci_add_sco(sco, acl->handle);
>  
>   return sco;
>  } else {
>   return acl;
>  }
> } 
> the else switch shows it does nothing when type NOT equal to SCO_LINK.
> Should this code need to modify or this is intended to designed?

the hci_connect from a 2.6.27 kernel looks different. So you might wanna
test with a later kernel.

Regards

Marcel

RE: how bluez supports ESCO link?

[shy]

Hi, Marcel
Thanks for your response. In the latest stable kernel code, this code =
has
been modified and can answer for my question.
Brs
Shi Buyun=20

-----Original Message-----
From: Marcel Holtmann [mailto:marcel@holtmann.org]=20
Sent: 2008=C4=EA12=D4=C212=C8=D5 09:47
To: Shi Buyun-FVBP83
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: how bluez supports ESCO link?

Hi,

> In the current linux 2.6.25 kernel code, can Bluez setup ESCO link?
> I found in net/bluetooth/sco.c, sco_connect defined as:
>=20
> static int sco_connect(struct sock *sk) {  if (lmp_esco_capable(hdev)=20
> && !disable_esco)
>   type =3D ESCO_LINK;
>  else
>   type =3D SCO_LINK;
> =20
>  hcon =3D hci_connect(hdev, type, dst, HCI_AT_NO_BONDING);  } this =
code=20
> shows bluez supports ESCO link.
> =20
> But in function struct hci_conn * hci_connect(struct hci_dev *hdev,=20
> int type, bdaddr_t *dst) {  if (type =3D=3D SCO_LINK) {
>   struct hci_conn *sco;
> =20
>   if (!(sco =3D hci_conn_hash_lookup_ba(hdev, SCO_LINK, dst))) {
>    if (!(sco =3D hci_conn_add(hdev, SCO_LINK, dst))) {
>     hci_conn_put(acl);
>     return NULL;
>    }
>   }
>   acl->link =3D sco;
>   sco->link =3D acl;
> =20
>   hci_conn_hold(sco);
> =20
>   if (acl->state =3D=3D BT_CONNECTED &&=20
>     (sco->state =3D=3D BT_OPEN || sco->state =3D=3D BT_CLOSED))
>    hci_add_sco(sco, acl->handle);
> =20
>   return sco;
>  } else {
>   return acl;
>  }
> }
> the else switch shows it does nothing when type NOT equal to SCO_LINK.
> Should this code need to modify or this is intended to designed?

the hci_connect from a 2.6.27 kernel looks different. So you might wanna
test with a later kernel.

Regards

Marcel