LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Louis JANG <louis@mizi.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Dave Young <hidave.darkstar@gmail.com>,
	linux-bluetooth@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	bmidgley@gmail.com, David Miller <davem@davemloft.net>,
	Netdev <netdev@vger.kernel.org>,
	littletux@zarb.org
Subject: Re: [Bluez-devel] forcing SCO connection patch
Date: Thu, 28 Feb 2008 11:49:43 +0900	[thread overview]
Message-ID: <47C62147.90007@mizi.com> (raw)
In-Reply-To: <5D9353FF-6A69-4039-9033-C0EBD1CDA756@holtmann.org>

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

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
>


[-- Attachment #2: patch_hci_event.c7 --]
[-- Type: text/plain, Size: 1529 bytes --]

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);

      reply	other threads:[~2008-02-28  2:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <47666E1F.2000902@mizi.com>
2008-02-25  7:30 ` Dave Young
2008-02-25  7:34   ` Dave Young
2008-02-25  8:26     ` Dave Young
2008-02-25  9:28   ` Louis JANG
2008-02-25  9:55     ` Dave Young
2008-02-25 11:35       ` Louis JANG
2008-02-26  3:07         ` Marcel Holtmann
2008-02-26  3:53           ` Louis JANG
2008-02-26 19:43             ` Marcel Holtmann
2008-02-27  1:58               ` Louis JANG
2008-02-27  9:57                 ` Marcel Holtmann
2008-02-27 12:21                   ` Louis JANG
2008-02-27 15:21                     ` Marcel Holtmann
2008-02-28  2:49                       ` Louis JANG [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C62147.90007@mizi.com \
    --to=louis@mizi.com \
    --cc=bmidgley@gmail.com \
    --cc=davem@davemloft.net \
    --cc=hidave.darkstar@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=littletux@zarb.org \
    --cc=marcel@holtmann.org \
    --cc=netdev@vger.kernel.org \
    --subject='Re: [Bluez-devel] forcing SCO connection patch' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).