Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756648AbYB1CuN (ORCPT ); Wed, 27 Feb 2008 21:50:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751555AbYB1Ct6 (ORCPT ); Wed, 27 Feb 2008 21:49:58 -0500 Received: from mail.mizi.com ([61.107.31.33]:47312 "EHLO mail.mizi.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbYB1Ct5 (ORCPT ); Wed, 27 Feb 2008 21:49:57 -0500 Message-ID: <47C62147.90007@mizi.com> Date: Thu, 28 Feb 2008 11:49:43 +0900 From: Louis JANG Organization: MIZI Research, Inc. User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Marcel Holtmann CC: Dave Young , linux-bluetooth@vger.kernel.org, Linux Kernel , bmidgley@gmail.com, David Miller , Netdev , littletux@zarb.org Subject: Re: [Bluez-devel] forcing SCO connection patch References: <47666E1F.2000902@mizi.com> <47C28A33.4070102@mizi.com> <47C2A7FA.2060902@mizi.com> <70692DDF-93B7-447E-ABEE-3CDBD94F15F1@holtmann.org> <47C38D40.3040809@mizi.com> <47C4C3D4.8010902@mizi.com> <2A7EF87C-1340-45D7-B457-F81799674B1E@holtmann.org> <47C555E5.2000903@mizi.com> <5D9353FF-6A69-4039-9033-C0EBD1CDA756@holtmann.org> In-Reply-To: <5D9353FF-6A69-4039-9033-C0EBD1CDA756@holtmann.org> Content-Type: multipart/mixed; boundary="------------070300070203030909050207" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4496 Lines: 105 This is a multi-part message in MIME format. --------------070300070203030909050207 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Hi Marcel, I changed what you said below and attached patch again. And did you check Guillaume's patch for this issue? his patch try to find again when ev->link_type is SCO_LINK only. I think his way is better than mine. I haven't saw other case (LM is not support esco but ESCO_LINK is connected) and I think it shouldn't happen in a normal situation. Best regards, Louis JANG Marcel Holtmann ?? ??: > Hi Louis, > >> When bluez tried to connect SCO channel with >> HCI_OP_SETUP_SYNC_CONN(ESCO_LINK), >> a real connection may be connected with SCO_LINK instead of ESCO_LINK >> when >> peer device doesn't support eSCO. however bluez try to find >> connection handle >> by event's link type(SCO_LINK in above case) and the valid connection >> handle >> for this event is waiting for ESCO_LINK. so bluez can't find >> connection handle >> and discarded the event. > > using HCI_OP_SETUP_SYNC_CONN doesn't mean eSCO. It is perfectly fine > to request SCO links via that command. The difference here is > Bluetooth 1.1 or 1.2 and later. > >> This patch is to handle different type of synchronous link is >> estabilished >> with its request. >> >> If bluez can't find connection handle, it try to find with different >> link type again. (For the above case, if bluez 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. > > Inside the kernel it is not called BlueZ :) It simply is the Bluetooth > subsystem and in case the HCI core. > > Regards > > Marcel > > - > To unsubscribe from this list: send the line "unsubscribe > linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --------------070300070203030909050207 Content-Type: text/plain; name="patch_hci_event.c7" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patch_hci_event.c7" V2hlbiBIQ0kgY29yZSB0cmllZCB0byBjb25uZWN0IFNDTyBjaGFubmVsIHdpdGggSENJX09Q X1NFVFVQX1NZTkNfQ09OTiwgSENJIGNvcmUKaXMgdXNpbmcgRVNDT19MSU5LIGxpbmsgdHlw ZSBpZiBMTSBzdXBwb3J0cyBlU0NPLiBob3dldmVyIGEgcmVhbCBjb25uZWN0aW9uIG1heSBi ZSAKY29ubmVjdGVkIHdpdGggU0NPX0xJTksgaW5zdGVhZCBvZiBFU0NPX0xJTksgd2hlbiBw ZWVyIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgZVNDTy4gIAoKSG93ZXZlciBIQ0kgY29yZSB0 cnkgdG8gZmluZCBjb25uZWN0aW9uIGhhbmRsZSBieSBldmVudCdzIGxpbmsgdHlwZSAKKFND T19MSU5LIGluIGFib3ZlIGNhc2UpICBpbiB0aGlzIGNhc2UsIHRoZSB2YWxpZCBjb25uZWN0 aW9uIGhhbmRsZSBmb3IgdGhpcyBldmVudCAKaXMgd2FpdGluZyBmb3IgRVNDT19MSU5LLiBI Q0kgY29yZSBjYW4ndCBmaW5kIGNvbm5lY3Rpb24gaGFuZGxlIGFuZCBkaXNjYXJkZWQgdGhl IGV2ZW50LiAKClRoaXMgcGF0Y2ggaXMgdG8gaGFuZGxlIGRpZmZlcmVudCB0eXBlIG9mIHN5 bmNocm9ub3VzIGxpbmsgaXMgZXN0YWJpbGlzaGVkIAp3aXRoIGl0cyByZXF1ZXN0LiAKCklm IEhDSSBjb3JlIGNhbid0IGZpbmQgY29ubmVjdGlvbiBoYW5kbGUsIGl0IHRyeSB0byBmaW5k IHdpdGggZGlmZmVyZW50IApsaW5rIHR5cGUgYWdhaW4uIChGb3IgdGhlIGFib3ZlIGNhc2Us IGlmIEhDSSBjb3JlIGNhbid0IGZpbmQgY29ubmVjdGlvbiAKaGFuZGxlIHdpdGggU0NPX0xJ TkssIGl0IHRyeSB0byBmaW5kIGNvbm5lY3Rpb24gaGFuZGxlIHdpdGggRVNDT19MSU5LIGFn YWluLikKYW5kIHVwZGF0ZSBsaW5rIHR5cGUgb2YgdGhpcyBjb25uZWN0aW9uIGhhbmRsZSB3 aXRoIGV2ZW50J3MgbGluayB0eXBlLgoKU2lnbmVkLW9mZi1ieTogTG91aXMgSkFORyA8bG91 aXNAbWl6aS5jb20+Ci0tLSBsaW51eC0yLjYuMjMvbmV0L2JsdWV0b290aC9oY2lfZXZlbnQu Yy5vcmlnCTIwMDgtMDItMjYgMTI6NDY6MzYuMDAwMDAwMDAwICswOTAwCisrKyBsaW51eC0y LjYuMjMvbmV0L2JsdWV0b290aC9oY2lfZXZlbnQuYwkyMDA4LTAyLTI3IDEwOjQ4OjI5LjAw MDAwMDAwMCArMDkwMApAQCAtMTMxMyw4ICsxMzEzLDE1IEBACiAJaGNpX2Rldl9sb2NrKGhk ZXYpOwogCiAJY29ubiA9IGhjaV9jb25uX2hhc2hfbG9va3VwX2JhKGhkZXYsIGV2LT5saW5r X3R5cGUsICZldi0+YmRhZGRyKTsKLQlpZiAoIWNvbm4pCi0JCWdvdG8gdW5sb2NrOworCWlm ICghY29ubikgeworCQlfX3U4IGxpbmtfdHlwZSA9IChldi0+bGlua190eXBlID09IEVTQ09f TElOSykgPyBTQ09fTElOSyA6IEVTQ09fTElOSzsKKworCQljb25uID0gaGNpX2Nvbm5faGFz aF9sb29rdXBfYmEoaGRldiwgbGlua190eXBlLCAmZXYtPmJkYWRkcik7CisJCWlmICghY29u bikKKwkJCWdvdG8gdW5sb2NrOworCisJCWNvbm4tPnR5cGUgPSBldi0+bGlua190eXBlOwor CX0KIAogCWlmICghZXYtPnN0YXR1cykgewogCQljb25uLT5oYW5kbGUgPSBfX2xlMTZfdG9f Y3B1KGV2LT5oYW5kbGUpOwo= --------------070300070203030909050207-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/