LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Dave Young" <hidave.darkstar@gmail.com>
To: linux-bluetooth@vger.kernel.org
Cc: louis@mizi.com, "Marcel Holtmann" <marcel@holtmann.org>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [Bluez-devel] forcing SCO connection patch
Date: Mon, 25 Feb 2008 15:30:18 +0800	[thread overview]
Message-ID: <a8e1da0802242330l765b8b1ava62b857baf8a5568@mail.gmail.com> (raw)
In-Reply-To: <47666E1F.2000902@mizi.com>

Quote mail from louis@mizi.com :

2007/12/17 Louis JANG <louis@mizi.com>:
> Hello everybody,
>
>  I attached two patches. the first one(bluez-kernel-forcesco.patch) is to
>  force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the
>  second one is to handle SCO connection complete event but its request
>  was ESCO.
>
>  1.
>  I'm developing bluetooth functions in my linux phone project, and I'm
>  using bluez for my job. I've tested lots of headsets, and found that I
>  coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old
>  headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case.
>  however, there is no api to force using SCO instead of ESCO in bluez. so
>  I added SCO_FORCESCO to handle this old headsets
>
>  2.
>  When I tried to connect SCO channel with
>  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds
>  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  handle this situation, and patch_hci_event.c is for this.
>
>
>  BRs
>  Louis JANG
>
>

Reply from bmidgley@gmail.com:

On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <bmidgley@gmail.com> wrote:
> Louis
>
>
>  >  When I tried to connect SCO channel with
>  >  HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets responds
>  >  with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't
>  >  handle this situation, and patch_hci_event.c is for this.
>
>  Marcel looked at this patch and came back with the comments below. Can
>  you revisit it? I think some other people are seeing the same issues.
>  The patch won't go upstream until Marcel likes it.
>
>  the patch you sent me is fully broken. First of all the coding style
>  is wrong. Does nobody have learned this by now? I always look for that
>  first before even reading the patch. Second the case where an
>  ESCO_LINK returns NULL is broken and will fall over and crash.
>
>  --
>  Brad
>


I ever asked marcel about the coding style. please see following thread:
http://lkml.org/lkml/2008/1/22/91

I think the style problem marcel said is
1. using kernel codeing style
2. marcel's style
container_of or get_user_data calls at the top of the variable declaration
using the empty lines to seperate code blocks

Please rework your patch and resend if you fixed them.

BTW, please use the new bluetooth mailing list for kerne issue.
linux-bluetooth@vger.kernel.org

(Thanks for andrew and davem)

Regards
dave

Regards
dave

       reply	other threads:[~2008-02-25  7:30 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 [this message]
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

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=a8e1da0802242330l765b8b1ava62b857baf8a5568@mail.gmail.com \
    --to=hidave.darkstar@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=louis@mizi.com \
    --cc=marcel@holtmann.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).