Return-Path: MIME-Version: 1.0 In-Reply-To: <35c90d960903302313y3900c724m285f984ba5eb9ec0@mail.gmail.com> References: <35c90d960903302313y3900c724m285f984ba5eb9ec0@mail.gmail.com> Date: Tue, 31 Mar 2009 14:43:39 +0800 Message-ID: Subject: Re: eSCO or SCO link? From: =?GB2312?B?seXA2g==?= To: Nick Pelly Cc: linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=GB2312 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi All, 2009/3/31 Nick Pelly : > 2009/3/30 ???? : >> Hi All, >> I made a mistake when writing the email, I have not complete my question. >> >> 2009/3/31 ???? : >>> Hi All, >>> I have a stlc2500c which is a Bluetooth 1.2 chip. When debuging >>> function 'hci_connect', i found the hci link type of the arguments was >>> SCO_LINK, because i enabled 'lmp_esco_capable' in my kernel, it call >>> 'hci_setup_sync' to setup eSCO link. >> >> But when i check connection by 'hcitool con', the hcitool show it was >> a SCO link. So, is it a SCO link or eSCO link? Thanks. > > hcitool con will report eSCO if it is eSCO, so you have a SCO link. > > hci_setup_sync can be used for both SCO and eSCO, and the chipset > and/or the host stack will fall back to SCO if eSCO parameters can not > be negotiated. An LMP log will show why. Maybe the function 'hci_sync_conn_complete_evt' matches what you said. static inline void hci_sync_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb) { ... printk("hci_sync_conn_complete_evt, ev->link_type=%d\n", ev->link_type); ------> ev->link_type=0 conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr); printk("hci_sync_conn_complete_evt, conn=%p\n", conn);-------------------------------> conn=00000000 if (!conn) { if (ev->link_type == ESCO_LINK) goto unlock; conn = hci_conn_hash_lookup_ba(hdev, ESCO_LINK, &ev->bdaddr); if (!conn) goto unlock; conn->type = SCO_LINK;-----------------------------------------------------------------------> fall back to SCO? } ... } > > Nick > LeiBian BR