When HCI core tried to connect SCO channel with HCI_OP_SETUP_SYNC_CONN, HCI core
is using ESCO_LINK link type if LM supports eSCO. however a real connection may be 
connected with SCO_LINK instead of ESCO_LINK when peer device doesn't support eSCO.  

However HCI core try to find connection handle by event's link type 
(SCO_LINK in above case)  in this case, the valid connection handle for this event 
is waiting for ESCO_LINK. HCI core can't find connection handle and discarded the event. 

This patch is to handle different type of synchronous link is estabilished 
with its request. 

If HCI core can't find connection handle, it try to find with different 
link type again. (For the above case, if HCI core can't find connection 
handle with SCO_LINK, it try to find connection handle with ESCO_LINK again.)
and update link type of this connection handle with event's link type.

Signed-off-by: Louis JANG <louis@mizi.com>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig	2008-02-26 12:46:36.000000000 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c	2008-02-27 10:48:29.000000000 +0900
@@ -1313,8 +1313,15 @@
 	hci_dev_lock(hdev);
 
 	conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
-	if (!conn)
-		goto unlock;
+	if (!conn) {
+		__u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK : ESCO_LINK;
+
+		conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+		if (!conn)
+			goto unlock;
+
+		conn->type = ev->link_type;
+	}
 
 	if (!ev->status) {
 		conn->handle = __le16_to_cpu(ev->handle);