linux-kernel - Re: [Bluez-devel] forcing SCO connection patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Feb 2008 15:30:18 +0800
From:	"Dave Young" <hidave.darkstar@...il.com>
To:	linux-bluetooth@...r.kernel.org
Cc:	louis@...i.com, "Marcel Holtmann" <marcel@...tmann.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [Bluez-devel] forcing SCO connection patch

Quote mail from louis@...i.com :

2007/12/17 Louis JANG <louis@...i.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@...il.com:

On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <bmidgley@...il.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@...r.kernel.org

(Thanks for andrew and davem)

Regards
dave

Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/