* Re: [PATCH] Bluetooth: Move bit-field var to data->flags
From: Marcel Holtmann @ 2010-07-16 20:54 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1279311633-12131-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> did_iso_resume keeps only a bit-field value, so moving that to a proper
> flags place.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> drivers/bluetooth/btusb.c | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Move bit-field var to data->flags
From: Gustavo F. Padovan @ 2010-07-16 20:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
did_iso_resume keeps only a bit-field value, so moving that to a proper
flags place.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
drivers/bluetooth/btusb.c | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 6fcb971..d22ce3c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -149,6 +149,7 @@ static struct usb_device_id blacklist_table[] = {
#define BTUSB_BULK_RUNNING 1
#define BTUSB_ISOC_RUNNING 2
#define BTUSB_SUSPENDING 3
+#define BTUSB_DID_ISO_RESUME 4
struct btusb_data {
struct hci_dev *hdev;
@@ -182,7 +183,6 @@ struct btusb_data {
unsigned int sco_num;
int isoc_altsetting;
int suspend_count;
- int did_iso_resume:1;
};
static int inc_tx(struct btusb_data *data)
@@ -810,7 +810,7 @@ static void btusb_work(struct work_struct *work)
int err;
if (hdev->conn_hash.sco_num > 0) {
- if (!data->did_iso_resume) {
+ if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
err = usb_autopm_get_interface(data->isoc);
if (err < 0) {
clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
@@ -818,7 +818,7 @@ static void btusb_work(struct work_struct *work)
return;
}
- data->did_iso_resume = 1;
+ set_bit(BTUSB_DID_ISO_RESUME, &data->flags);
}
if (data->isoc_altsetting != 2) {
clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
@@ -839,10 +839,8 @@ static void btusb_work(struct work_struct *work)
usb_kill_anchored_urbs(&data->isoc_anchor);
__set_isoc_interface(hdev, 0);
- if (data->did_iso_resume) {
- data->did_iso_resume = 0;
+ if (test_and_clear_bit(BTUSB_DID_ISO_RESUME, &data->flags))
usb_autopm_put_interface(data->isoc);
- }
}
}
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Add Google's copyright to L2CAP
From: Marcel Holtmann @ 2010-07-16 19:22 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1279307919-27801-1-git-send-email-padovan@profusion.mobi>
Hi Gustavo,
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/l2cap.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Add Google's copyright to L2CAP
From: Gustavo F. Padovan @ 2010-07-16 19:18 UTC (permalink / raw)
To: linux-bluetooth
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/l2cap.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index d030302..4b86c78 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -2,6 +2,7 @@
BlueZ - Bluetooth protocol stack for Linux
Copyright (C) 2000-2001 Qualcomm Incorporated
Copyright (C) 2009-2010 Gustavo F. Padovan <gustavo@padovan.org>
+ Copyright (C) 2010 Google Inc.
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index cdd608d..d175cc2 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2,6 +2,7 @@
BlueZ - Bluetooth protocol stack for Linux
Copyright (C) 2000-2001 Qualcomm Incorporated
Copyright (C) 2009-2010 Gustavo F. Padovan <gustavo@padovan.org>
+ Copyright (C) 2010 Google Inc.
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
--
1.7.1.1
^ permalink raw reply related
* Secure Simple Pairing Mode - Setting NoInputNoOutput mode
From: Tim Bennett @ 2010-07-16 19:14 UTC (permalink / raw)
To: linux-bluetooth
Is there a method (programmatic or hciconfig - type) to change the Mode of a
BT v2.1 dongle to require NoInputNoOutput/JustWorks pairing?
I want to make my box (running linux 2.6.30.2 kernel on an arm processor
with Bluez 4.67 and a Broadcom v2.1 dongle) pair with another device in the
"JustWorks" (NoInputNoOutput) mode.
1. The SSP mode seems to default to "Numeric Comparison" mode. I am trying
to find out how to switch to "Just Works" (NoInputNoOutput mode)
Can someone point me to a command or code that would switch my adapter into
the NoInputNoOutput mode?
Is it something I can configure through hciconfig or through a dbus command?
2. The man page for hciconfig has the command hciconfig hciX sspmode
[mode]. Is [mode] only valid for 0 or 1?
In looking in hciconfig.c, at the
hci_read_simple_pairing_mode/hci_write_simple_pairing_mode functions, there
is no clear indication as to what the accepted values are for [mode}
Tim Bennett
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-07-16 18:46 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Johan Hedberg, Marcel Holtmann, linux-bluetooth
In-Reply-To: <20100716180817.GA10326@vigoh>
[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]
El vie, 16-07-2010 a las 15:08 -0300, Gustavo F. Padovan escribió:
> Hi Pacho,
>
> * Pacho Ramos <pacho@condmat1.ciencias.uniovi.es> [2010-07-16 19:21:45 +0200]:
>
> > El vie, 16-07-2010 a las 14:01 -0300, Johan Hedberg escribió:
> > >
> > > On Fri, Jul 16, 2010, Pacho Ramos wrote:
> > > > Can this be finally committed please? Thanks a lot :-)
> > >
> > > It's strange the the patch has gone unnoticed ever since March. Anyway,
> > > could you please provide a git format-patch version of it since that's
> > > the convention for all patch submisions. That way I don't need to play
> > > manual tricks to get the git author name and email correct for the
> > > commit.
> > >
> > > Johan
> > >
> >
> > Sadly I have always failed to create patches in a git format-patch
> > version :'(
> >
> > This is what I have tried:
> > $ git clone git://git.kernel.org/pub/scm/bluetooth/bluez.git
> > Initialized empty Git repository in /home/pacho/bluez/.git/
> > remote: Counting objects: 35451, done.
> > remote: Compressing objects: 100% (8577/8577), done.
> > remote: Total 35451 (delta 27190), reused 34976 (delta 26858)
> > Receiving objects: 100% (35451/35451), 6.16 MiB | 1.39 MiB/s, done.
> > Resolving deltas: 100% (27190/27190), done.
> > $ cd bluez/
> > $ git checkout -b fix_alsa_path
> > Switched to a new branch 'fix_alsa_path'
> > $ patch -p0
> > </usr/portage/net-wireless/bluez/files/bluez-alsa_location.patch
> > patching file Makefile.am
> > Hunk #1 succeeded at 248 (offset 7 lines).
> > $ git format-patch master --stdout
> > $ (nothing is shown)
>
> If your patch is on HEAD then just do:
>
> git format-patch -1
>
> and then use 'git send-email' to send it to the mailing list.
>
Seems I forgot to commit ;-), I attach the patch
Thanks :-)
[-- Attachment #1.2: 0001-Install-alsa-stuff-in-correct-place.patch --]
[-- Type: text/x-patch, Size: 731 bytes --]
From 4421d83d1d5cd0875ec12457f621a31fdc8862a1 Mon Sep 17 00:00:00 2001
From: Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
Date: Fri, 16 Jul 2010 20:38:58 +0200
Subject: [PATCH] Install alsa stuff in correct place
---
Makefile.am | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f4bf87d..65d4312 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -248,7 +248,7 @@ audio_libasound_module_ctl_bluetooth_la_LIBADD = lib/libbluetooth.la @ALSA_LIBS@
audio_libasound_module_ctl_bluetooth_la_CFLAGS = @ALSA_CFLAGS@
if CONFIGFILES
-alsaconfdir = $(sysconfdir)/alsa
+alsaconfdir = $(datadir)/alsa
alsaconf_DATA = audio/bluetooth.conf
endif
--
1.7.1
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Gustavo F. Padovan @ 2010-07-16 18:08 UTC (permalink / raw)
To: Pacho Ramos; +Cc: Johan Hedberg, Marcel Holtmann, linux-bluetooth
In-Reply-To: <1279300905.29479.2.camel@localhost.localdomain>
Hi Pacho,
* Pacho Ramos <pacho@condmat1.ciencias.uniovi.es> [2010-07-16 19:21:45 +020=
0]:
> El vie, 16-07-2010 a las 14:01 -0300, Johan Hedberg escribi=F3:
> >=20
> > On Fri, Jul 16, 2010, Pacho Ramos wrote:
> > > Can this be finally committed please? Thanks a lot :-)
> >=20
> > It's strange the the patch has gone unnoticed ever since March. Anyway,
> > could you please provide a git format-patch version of it since that's
> > the convention for all patch submisions. That way I don't need to play
> > manual tricks to get the git author name and email correct for the
> > commit.
> >=20
> > Johan
> >=20
>=20
> Sadly I have always failed to create patches in a git format-patch
> version :'(
>=20
> This is what I have tried:
> $ git clone git://git.kernel.org/pub/scm/bluetooth/bluez.git
> Initialized empty Git repository in /home/pacho/bluez/.git/
> remote: Counting objects: 35451, done.
> remote: Compressing objects: 100% (8577/8577), done.
> remote: Total 35451 (delta 27190), reused 34976 (delta 26858)
> Receiving objects: 100% (35451/35451), 6.16 MiB | 1.39 MiB/s, done.
> Resolving deltas: 100% (27190/27190), done.
> $ cd bluez/
> $ git checkout -b fix_alsa_path
> Switched to a new branch 'fix_alsa_path'
> $ patch -p0
> </usr/portage/net-wireless/bluez/files/bluez-alsa_location.patch=20
> patching file Makefile.am
> Hunk #1 succeeded at 248 (offset 7 lines).
> $ git format-patch master --stdout
> $ (nothing is shown)
If your patch is on HEAD then just do:
git format-patch -1
and then use 'git send-email' to send it to the mailing list.
--=20
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-07-16 17:21 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20100716170135.GA22166@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
El vie, 16-07-2010 a las 14:01 -0300, Johan Hedberg escribió:
>
> On Fri, Jul 16, 2010, Pacho Ramos wrote:
> > Can this be finally committed please? Thanks a lot :-)
>
> It's strange the the patch has gone unnoticed ever since March. Anyway,
> could you please provide a git format-patch version of it since that's
> the convention for all patch submisions. That way I don't need to play
> manual tricks to get the git author name and email correct for the
> commit.
>
> Johan
>
Sadly I have always failed to create patches in a git format-patch
version :'(
This is what I have tried:
$ git clone git://git.kernel.org/pub/scm/bluetooth/bluez.git
Initialized empty Git repository in /home/pacho/bluez/.git/
remote: Counting objects: 35451, done.
remote: Compressing objects: 100% (8577/8577), done.
remote: Total 35451 (delta 27190), reused 34976 (delta 26858)
Receiving objects: 100% (35451/35451), 6.16 MiB | 1.39 MiB/s, done.
Resolving deltas: 100% (27190/27190), done.
$ cd bluez/
$ git checkout -b fix_alsa_path
Switched to a new branch 'fix_alsa_path'
$ patch -p0
</usr/portage/net-wireless/bluez/files/bluez-alsa_location.patch
patching file Makefile.am
Hunk #1 succeeded at 248 (offset 7 lines).
$ git format-patch master --stdout
$ (nothing is shown)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Johan Hedberg @ 2010-07-16 17:01 UTC (permalink / raw)
To: Pacho Ramos; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <1279276807.23291.0.camel@localhost.localdomain>
On Fri, Jul 16, 2010, Pacho Ramos wrote:
> Can this be finally committed please? Thanks a lot :-)
It's strange the the patch has gone unnoticed ever since March. Anyway,
could you please provide a git format-patch version of it since that's
the convention for all patch submisions. That way I don't need to play
manual tricks to get the git author name and email correct for the
commit.
Johan
^ permalink raw reply
* Re: [PATCH] Use default adapter for LE commands
From: Johan Hedberg @ 2010-07-16 16:54 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1279274585-17730-1-git-send-email-ville.tervo@nokia.com>
Hi Ville,
On Fri, Jul 16, 2010, Ville Tervo wrote:
> Choose default adapter if device was not specified on command line.
> ---
> tools/hcitool.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
Thanks for the patch. It's now upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Add LE connection creation dumping
From: Hedberg Johan (Nokia-D/Helsinki) @ 2010-07-16 16:53 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1279272667-16949-1-git-send-email-ville.tervo@nokia.com>
Hi Ville,
On Fri, Jul 16, 2010, Ville Tervo wrote:
> ---
> parser/hci.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 135 insertions(+), 3 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Marcel Holtmann @ 2010-07-16 16:32 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <4C3F7FEE.1040101@codeaurora.org>
Hi Ron,
> >> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> >> connection requests while the ACL is transitioning from sniff mode
> >> to active mode. Add synchronization so that SCO and eSCO connection
> >> requests will wait until the ACL has fully transitioned to active mode.
> >
> > I find your patch actually highly complicated. So I tried to capture
> > your intend the in the attached patch (only compiled test) and it would
> > be good if you can try that.
> >
> > So in general it makes no difference which mode we are in. If a mode
> > change is pending, then we have to delay the SCO setup. And once we are
> > done we the mode change we just setup the SCO link. So in theory that
> > should be enough. Not sure if that is true. I could have overlooked
> > something since I don't really have tested the patch at all ;)
>
> Would have been back with you sooner on this but I'm having some
> hardware issues preventing me from testing your code. I'm fairly
> confident it works as you've consolidated the pending check into
> hci_conn which I like.
>
> However, the complicated pieces to which I think you are referring are
> the error handling pieces which we should want want to keep. These make
> sure that we clean up appropriately if:
>
> 1. The HW rejects the exit sniff or the SCO/eSCO request for some reason
> i.e. in the case the HW returns a command status with a failure
> 2. In the latter case, the user space process is also notified that its
> SCO/eSCO request has failed.
>
> Give the cleanup code some thought. I think you'll see we want this
> there to make the system more reliable.
>
> As soon as I've confirmed your patch I'll get back to you.
I think the general discussion here is what we expect a normal behaving
system to do and what would be a good idea.
So we already have the case where just always unsniff the ACL link
before establishing any SCO link. If that assumption still holds then I
think it is more than fair to wait for the mode change event as well.
My point is just that when we receive the mode change event, we don't
care if the unsniff (or unpark/unhold) for that matter was successful.
We proceed with the SCO setup.
The change is like this "if a mode change is in progress, then wait
until it finished before trying to setup SCO". I think that is a proper
way of doing this anyway. It really doesn't change anything else. If the
link is active anyway, then nothing has been changed here in the first
place.
And yes, in case of a HCI disconnect event we should clear out the
pending SCO setup request. However that is done anyway, since this flag
is stored inside the ACL connection handle. Right now I really don't see
an issue with this patch.
For the potential security concern, yes that can happen, but lets be
fair, we can't prevent this from the host anyway. Same as someone could
just block the 2.4 GHz spectrum and will disrupt calls.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] bluetooth: retry reset for devices that fail
From: Marcel Holtmann @ 2010-07-16 16:10 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-bluetooth
In-Reply-To: <201007151423.23245.oneukum@suse.de>
Hi Oliver,
> Some devices fail to reset properly at the first attempt to reset
> them under unknown circumstances. Failures can be identified by
> an invalid btaddr. Retry in those cases.
I am not sure about this. Can you provide some examples when this is
suppose to be happening. The empty BD_ADDR might not be a good indicator
for this.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: Marcel Holtmann @ 2010-07-16 16:08 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Luis R. Rodriguez, Dan Tian, linux-bluetooth@vger.kernel.org,
Haijun Liu, Luis Rodriguez
In-Reply-To: <20100715194256.GA4307@vigoh>
Hi Dan,
> > > Could you split all your patches in little chunks? +1882 is very hard to
> > > review. And please be more verbose on the commit message, it can help us
> > > figure out what's happening.
> >
> > This used to be 1 large patch, it was recently split up to 3, I havent't
> > had a chance yet to review further but my understanding is this this was
> > split up as much as possible in the last try. If you can provide suggestions
> > how to split it up more that might be useful, but agreed, if possible more
> > splitup would help.
>
> But it is still too big. I looked to patch 3/3, it does a lot different
> things in the same patch that make the patch impossible to be tracked.
> We need atomic patches for at least each change in the ERTM code, each
> new state added in the L2CAP state machine, each new HS feature, etc,
> i.e., we need proper patches with proper commit messages explaining
> what's happening. The same should apply to 1/3 and 2/3, I didn't looked
> to them.
please split these in smaller chunks. You can provide the full blown
patch on kernel.org as Luis did, but we need small chunks to get this
merged. It touches too many areas and I won't be able to do the full
review otherwise.
Patch 1/3 can be split properly. It doesn't have to be this big in the
first place.
include/net/bluetooth/hci.h | 342 +++++++++++++++++++-
include/net/bluetooth/hci_core.h | 264 ++++++++++++++-
net/bluetooth/cmtp/core.c | 1 +
net/bluetooth/hci_conn.c | 201 +++++++++++-
net/bluetooth/hci_core.c | 349 ++++++++++++++++++--
net/bluetooth/hci_event.c | 698 +++++++++++++++++++++++++++++++++++++-
6 files changed, 1822 insertions(+), 33 deletions(-)
Why are you touching CMTP. If that is needed, then send a patch up-front
that prepares this change. This just clutters it.
I see also thinks like this:
-#define HCI_OP_WRITE_SCAN_ENABLE 0x0c1a
+#define HCI_OP_WRITE_SCAN_ENABLE 0x0c1a
If you wanna do cleanups of already existing code, then please send
these cleanup patches first. Otherwise they just clutter the rest and I
will refuse to review them.
Same here:
-void hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags);
-void hci_send_sco(struct hci_conn *conn, struct sk_buff *skb);
+int hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags);
+int hci_send_sco(struct hci_conn *conn, struct sk_buff *skb);
Separate patch with proper commit message explaining why this is needed
etc. And then ensuring that it doesn't affect current code.
And for this you better have a good explanation:
LIST_HEAD(hci_dev_list);
+EXPORT_SYMBOL(hci_dev_list);
+
DEFINE_RWLOCK(hci_dev_list_lock);
+EXPORT_SYMBOL(hci_dev_list_lock);
/* HCI callback list */
LIST_HEAD(hci_cb_list);
+EXPORT_SYMBOL(hci_cb_list);
+
DEFINE_RWLOCK(hci_cb_list_lock);
+EXPORT_SYMBOL(hci_cb_list_lock);
For every single symbol that you wanna export I expect at least a proper
paragraph in the commit message explaining why that is needed.
And then please one patch that just adds the new HCI definitions. And
form there on single steps with changing init behavior for BR/EDR and
AMP, adding the new flow control, adding physical link establishment.
All in single patches with proper commit messages please.
And this is only for patch 1/3.
After that I can have a look at the AMP Manager and the L2CAP changes.
> > Dan, can you also please drop the "by Atheros Linux BT3 team." on the subject
> > of the patches. This is already implied by the From and the Signed-off-by.
>
> Dan, your patches don't apply cleanly upstream, please rebase them
> against Marcel's bluetooth-next tree and do the proper split of the
> patches.
I can update bluetooth-testing, but right it would be way better to base
them against the bluetooth-next tree. That will be the one, I ask John
to pull into his wireless-next tree in a bit.
Regards
Marcel
^ permalink raw reply
* Re: bluez installs alsa related stuff under /etc/alsa instead of /usr/share/alsa
From: Pacho Ramos @ 2010-07-16 10:40 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1270898905.5646.29.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
El sáb, 10-04-2010 a las 13:28 +0200, Pacho Ramos escribió:
> El vie, 05-03-2010 a las 10:24 +0100, Pacho Ramos escribió:
> > El vie, 05-03-2010 a las 10:11 +0100, Pacho Ramos escribió:
> > > El jue, 04-03-2010 a las 17:42 -0800, Marcel Holtmann escribió:
> > > > Hi Pacho,
> > > >
> > > > > bluez installs stuff into /etc/alsa and it seems wrong since default
> > > > > location for alsa stuff seems to be /usr/share/alsa instead. You can
> > > > > also see that this is been workarounded in ubuntu, gentoo (and probably
> > > > > debian also).
> > > > >
> > > > > Any reason why using /etc/alsa instead?
> > > >
> > > > I thought that is the default location. If that is wrong, then please
> > > > quote the ALSA documentation and send a patch to fix it.
> > > >
> > > > Regards
> > > >
> > > > Marcel
> > >
> > > alsa-lib configure.in seems to indicate that /usr/share/alsa is the
> > > default one:
> > > dnl ALSA configuration directory
> > > AC_ARG_WITH(configdir,
> > > AS_HELP_STRING([--with-configdir=dir],
> > > [path where ALSA config files are stored]),
> > > confdir="$withval", confdir="")
> > > if test -z "$confdir"; then
> > > eval dir="$datadir"
> > > case "$dir" in
> > > /*) ;;
> > > *) dir="$prefix/share"
> > > esac
> > > confdir="$dir/alsa"
> > > fi
> > >
> >
> > I forgot the patch, sorry
> >
Can this be finally committed please? Thanks a lot :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Use default adapter for LE commands
From: Ville Tervo @ 2010-07-16 10:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
Choose default adapter if device was not specified
on command line.
---
tools/hcitool.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/tools/hcitool.c b/tools/hcitool.c
index dfb749d..1a53a38 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2435,6 +2435,9 @@ static void cmd_lescan(int dev_id, int argc, char **argv)
}
}
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
dd = hci_open_dev(dev_id);
if (dd < 0) {
perror("Could not open device");
@@ -2504,6 +2507,9 @@ static void cmd_lecc(int dev_id, int argc, char **argv)
return;
}
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
dd = hci_open_dev(dev_id);
if (dd < 0) {
perror("Could not open device");
@@ -2569,6 +2575,9 @@ static void cmd_ledc(int dev_id, int argc, char **argv)
return;
}
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
dd = hci_open_dev(dev_id);
if (dd < 0) {
perror("Could not open device");
--
1.7.0.1
^ permalink raw reply related
* [PATCH] Add LE connection creation dumping
From: Ville Tervo @ 2010-07-16 9:31 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
---
parser/hci.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 135 insertions(+), 3 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index a3f001b..6ced0ee 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -50,7 +50,7 @@ static inline uint16_t get_manufacturer(void)
return (manufacturer == DEFAULT_COMPID ? parser.defcompid : manufacturer);
}
-#define EVENT_NUM 61
+#define EVENT_NUM 76
static char *event_str[EVENT_NUM + 1] = {
"Unknown",
"Inquiry Complete",
@@ -114,6 +114,31 @@ static char *event_str[EVENT_NUM + 1] = {
"User Passkey Notification",
"Keypress Notification",
"Remote Host Supported Features Notification",
+ "LE Meta Event",
+ "Physical Link Complete",
+ "Channel Selected",
+ "Disconnection Physical Link Complete",
+ "Physical Link Loss Early Warning",
+ "Physical Link Recovery",
+ "Logical Link Complete",
+ "Disconnection Logical Link Complete",
+ "Flow Spec Modify Complete",
+ "Number Of Completed Data Blocks",
+ "AMP Start Test",
+ "AMP Test End",
+ "AMP Receiver Report",
+ "Short Range Mode Change Complete",
+ "AMP Status Change",
+};
+
+#define LE_EV_NUM 5
+static char *ev_le_meta_str[LE_EV_NUM + 1] = {
+ "Unknown",
+ "LE Connection Complete",
+ "LE Advertising Report",
+ "LE Connection Update Complete",
+ "LE Read Remote Used Features Complete",
+ "LE Long Term Key Request",
};
#define CMD_LINKCTL_NUM 52
@@ -195,7 +220,7 @@ static char *cmd_linkpol_str[CMD_LINKPOL_NUM + 1] = {
"Sniff Subrating",
};
-#define CMD_HOSTCTL_NUM 95
+#define CMD_HOSTCTL_NUM 109
static char *cmd_hostctl_str[CMD_HOSTCTL_NUM + 1] = {
"Unknown",
"Set Event Mask",
@@ -292,8 +317,21 @@ static char *cmd_hostctl_str[CMD_HOSTCTL_NUM + 1] = {
"Unknown",
"Unknown",
"Unknown",
- "Enhanced Flush"
+ "Enhanced Flush",
"Unknown",
+ "Read Logical Link Accept Timeout",
+ "Write Logical Link Accept Timeout",
+ "Set Event Mask Page 2",
+ "Read Location Data",
+ "Write Location Data",
+ "Read Flow Control Mode",
+ "Write Flow Control Mode",
+ "Read Enhanced Transmit Power Level",
+ "Read Best Effort Flush Timeout",
+ "Write Best Effort Flush Timeout",
+ "Short Range Mode",
+ "Read LE Host Supported",
+ "Write LE Host Supported",
};
#define CMD_INFO_NUM 9
@@ -331,6 +369,42 @@ static char *cmd_testing_str[CMD_TESTING_NUM + 1] = {
"Unknown",
};
+#define CMD_LE_NUM 30
+static char *cmd_le_str[CMD_LE_NUM + 1] = {
+ "Unknown",
+ "LE Set Event Mask",
+ "LE Read Buffer Size",
+ "LE Read Local Supported Features",
+ "Unknown",
+ "LE Set Random Address",
+ "LE Set Advertising Parameters",
+ "LE Read Advertising Channel Tx Power",
+ "LE Set Advertising Data",
+ "LE Set Scan Response Data",
+ "LE Set Advertise Enable",
+ "LE Set Scan Parameters",
+ "LE Set Scan Enable",
+ "LE Create Connection",
+ "LE Create Connection Cancel",
+ "LE Read White List Size",
+ "LE Clear White List",
+ "LE Add Device To White List",
+ "LE Remove Device From White List",
+ "LE Connection Update",
+ "LE Set Host Channel Classification"
+ "LE Read Channel Map",
+ "LE Read Remote Used Features",
+ "LE Encrypt",
+ "LE Rand",
+ "LE Start Encryption",
+ "LE Long Term Key Request Reply",
+ "LE Long Term Key Request Negative Reply",
+ "LE Read Supported States",
+ "LE Receiver Test",
+ "LE Transmitter Test",
+ "LE Test End",
+};
+
#define ERROR_CODE_NUM 56
static char *error_code_str[ERROR_CODE_NUM + 1] = {
"Success",
@@ -453,6 +527,13 @@ static char *opcode2str(uint16_t opcode)
cmd = "Unknown";
break;
+ case OGF_LE_CTL:
+ if (ocf <= CMD_LE_NUM)
+ cmd = cmd_le_str[ocf];
+ else
+ cmd = "Unknown";
+ break;
+
case OGF_VENDOR_CMD:
cmd = "Vendor";
break;
@@ -1333,6 +1414,16 @@ static inline void num_comp_pkts_dump(int level, struct frame *frm)
}
}
+static inline void le_create_connection_dump(int level, struct frame *frm)
+{
+ char addr[18];
+ le_create_connection_cp *cp = frm->ptr;
+
+ p_indent(level, frm);
+ p_ba2str(&cp->peer_bdaddr, addr);
+ printf("bdaddr %s type %d \n", addr, cp->peer_bdaddr_type);
+}
+
static inline void command_dump(int level, struct frame *frm)
{
hci_command_hdr *hdr = frm->ptr;
@@ -1608,6 +1699,14 @@ static inline void command_dump(int level, struct frame *frm)
return;
}
break;
+
+ case OGF_LE_CTL:
+ switch (ocf) {
+ case OCF_LE_CREATE_CONN:
+ le_create_connection_dump(level + 1, frm);
+ return;
+ }
+ break;
}
raw_dump(level, frm);
@@ -2995,6 +3094,36 @@ static inline void remote_host_features_notify_dump(int level, struct frame *frm
printf("\n");
}
+static inline void evt_le_conn_complete_dump(int level, struct frame *frm)
+{
+ evt_le_connection_complete *evt = frm->ptr;
+
+ p_indent(level, frm);
+ printf("status 0x%2.2x handle %d\n", evt->status, btohs(evt->handle));
+}
+
+static inline void le_meta_ev_dump(int level, struct frame *frm)
+{
+ evt_le_meta_event *mevt = frm->ptr;
+ uint8_t subevent;
+
+ subevent = mevt->subevent;
+
+ frm->ptr += EVT_LE_META_EVENT_SIZE;
+ frm->len -= EVT_LE_META_EVENT_SIZE;
+
+ p_indent(level, frm);
+ printf("%s\n", ev_le_meta_str[subevent]);
+
+ switch (mevt->subevent) {
+ case EVT_LE_CONN_COMPLETE:
+ evt_le_conn_complete_dump(level + 1, frm);
+ break;
+ default:
+ raw_dump(level, frm);
+ }
+}
+
static inline void event_dump(int level, struct frame *frm)
{
hci_event_hdr *hdr = frm->ptr;
@@ -3198,6 +3327,9 @@ static inline void event_dump(int level, struct frame *frm)
case EVT_REMOTE_HOST_FEATURES_NOTIFY:
remote_host_features_notify_dump(level + 1, frm);
break;
+ case EVT_LE_META_EVENT:
+ le_meta_ev_dump(level + 1, frm);
+ break;
default:
raw_dump(level, frm);
break;
--
1.7.0.1
^ permalink raw reply related
* Changing Security Level
From: r_krish @ 2010-07-16 4:53 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Can we change the securty level of an incoming connection in BlueZ?
This is required because some devices doesn't connect back if the local
device is at a higher security level. If it is not possible, the other
option is to reduce the local device's security. I think this require
changes in the code. Please clarify.
Regards,
Krishnan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Support for Atheros AR300x serial Bluetooth Chip
From: suraj @ 2010-07-16 4:16 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <20100715195214.GA5734@vigoh>
Hi Gustavo,
On Fri, 2010-07-16 at 01:22 +0530, Gustavo F. Padovan wrote:
> Hi Suraj,
>
> * Suraj Sumangala <suraj@atheros.com> [2010-07-15 16:24:10 +0530]:
>
> > Implements Atheros AR300x Serial HCI protocol.
> > This protocol extends H4 serial protocol to implement enhanced power management
> > features supported by Atheros AR300x serial Bluetooth chipsets.
> >
> > Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> > ---
>
> Patch looks fine, nevertheless I'm unable to test it since I don't have
> such hardware.
>
I have tested the driver along with the hardware using good number of
profiles successfully.
So, I am pretty confident on it. But, how do we go about it in these
kind of scenarios?
Regards
Suraj
^ permalink raw reply
* RE: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: Haijun Liu @ 2010-07-16 2:14 UTC (permalink / raw)
To: Gustavo F. Padovan, Luis Rodriguez
Cc: Dan Tian, linux-bluetooth@vger.kernel.org, Luis Rodriguez
In-Reply-To: <20100715194256.GA4307@vigoh>
Hi Gustavo,
[PATCH 1/3] is adding AMP device hci layer support, even it modify some code, but it doesn't affect BR/EDR original logic, so we can consider it as totally new.
[PATCH 2/3] is adding AMP manager/A2MP protocol support, it is totally new.
So in my thought these two patches can be considered as atomic patches.
[PATCH 3/3] modify a lot of ERTM/Streaming mode code, but it's hard to split up, since they depends each other, so any comments for how to split is welcome.
Best Regards
Haijun
86-21-61820900 Ext. 6331 Work
Haijun.Liu@Atheros.com
Skype: liu.haijun
-----Original Message-----
From: Gustavo F. Padovan [mailto:gfpadovan@gmail.com] On Behalf Of Gustavo F. Padovan
Sent: Friday, July 16, 2010 3:43 AM
To: Luis Rodriguez
Cc: Dan Tian; linux-bluetooth@vger.kernel.org; Haijun Liu; Luis Rodriguez
Subject: Re: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
Hi Luis,
* Luis R. Rodriguez <lrodriguez@atheros.com> [2010-07-15 11:43:08 -0700]:
> On Thu, Jul 15, 2010 at 08:09:21AM -0700, Gustavo F. Padovan wrote:
> > Hi Dan,
> >
> > * Dan Tian <Dan.Tian@Atheros.com> [2010-07-15 15:37:32 +0800]:
> >
> > > From 40cbfbf5c1bc9109364970956d9b6f74f5846c70 Mon Sep 17 00:00:00 2001
> > > From: Haijun.Liu <Haijun.Liu@Atheros.com>
> > > Date: Wed, 14 Jul 2010 22:50:56 +0800
> > > Subject: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
> > >
> > >
> > > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
> > > ---
> > > include/net/bluetooth/hci.h | 342 +++++++++++++++++++-
> > > include/net/bluetooth/hci_core.h | 264 ++++++++++++++-
> > > net/bluetooth/cmtp/core.c | 1 +
> > > net/bluetooth/hci_conn.c | 201 +++++++++++-
> > > net/bluetooth/hci_core.c | 349 ++++++++++++++++++--
> > > net/bluetooth/hci_event.c | 698 +++++++++++++++++++++++++++++++++++++-
> > > 6 files changed, 1822 insertions(+), 33 deletions(-)
> >
> >
> > Could you split all your patches in little chunks? +1882 is very hard to
> > review. And please be more verbose on the commit message, it can help us
> > figure out what's happening.
>
> This used to be 1 large patch, it was recently split up to 3, I havent't
> had a chance yet to review further but my understanding is this this was
> split up as much as possible in the last try. If you can provide suggestions
> how to split it up more that might be useful, but agreed, if possible more
> splitup would help.
But it is still too big. I looked to patch 3/3, it does a lot different
things in the same patch that make the patch impossible to be tracked.
We need atomic patches for at least each change in the ERTM code, each
new state added in the L2CAP state machine, each new HS feature, etc,
i.e., we need proper patches with proper commit messages explaining
what's happening. The same should apply to 1/3 and 2/3, I didn't looked
to them.
>
> Dan, can you also please drop the "by Atheros Linux BT3 team." on the subject
> of the patches. This is already implied by the From and the Signed-off-by.
Dan, your patches don't apply cleanly upstream, please rebase them
against Marcel's bluetooth-next tree and do the proper split of the
patches.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* RE: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: Dan Tian @ 2010-07-16 2:02 UTC (permalink / raw)
To: Gustavo F. Padovan, Luis Rodriguez
Cc: linux-bluetooth@vger.kernel.org, Haijun Liu, Luis Rodriguez
In-Reply-To: <20100715194256.GA4307@vigoh>
T0suIFdlIHdpbGwgZG8gaXQuDQoNCkRhbg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IEd1c3Rhdm8gRi4gUGFkb3ZhbiBbbWFpbHRvOmdmcGFkb3ZhbkBnbWFpbC5jb21d
IE9uIEJlaGFsZiBPZiBHdXN0YXZvIEYuIFBhZG92YW4NClNlbnQ6IDIwMTDE6jfUwjE2yNUgMzo0
Mw0KVG86IEx1aXMgUm9kcmlndWV6DQpDYzogRGFuIFRpYW47IGxpbnV4LWJsdWV0b290aEB2Z2Vy
Lmtlcm5lbC5vcmc7IEhhaWp1biBMaXU7IEx1aXMgUm9kcmlndWV6DQpTdWJqZWN0OiBSZTogW1BB
VENIIDEvM10gQWRkIEJUMyBBTVAgZGV2aWNlIHN1cHBvcnQsIGJ5IEF0aGVyb3MgTGludXggQlQz
IHRlYW0uDQoNCkhpIEx1aXMsDQoNCiogTHVpcyBSLiBSb2RyaWd1ZXogPGxyb2RyaWd1ZXpAYXRo
ZXJvcy5jb20+IFsyMDEwLTA3LTE1IDExOjQzOjA4IC0wNzAwXToNCg0KPiBPbiBUaHUsIEp1bCAx
NSwgMjAxMCBhdCAwODowOToyMUFNIC0wNzAwLCBHdXN0YXZvIEYuIFBhZG92YW4gd3JvdGU6DQo+
ID4gSGkgRGFuLA0KPiA+IA0KPiA+ICogRGFuIFRpYW4gPERhbi5UaWFuQEF0aGVyb3MuY29tPiBb
MjAxMC0wNy0xNSAxNTozNzozMiArMDgwMF06DQo+ID4gDQo+ID4gPiBGcm9tIDQwY2JmYmY1YzFi
YzkxMDkzNjQ5NzA5NTZkOWI2Zjc0ZjU4NDZjNzAgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAxDQo+
ID4gPiBGcm9tOiBIYWlqdW4uTGl1IDxIYWlqdW4uTGl1QEF0aGVyb3MuY29tPg0KPiA+ID4gRGF0
ZTogV2VkLCAxNCBKdWwgMjAxMCAyMjo1MDo1NiArMDgwMA0KPiA+ID4gU3ViamVjdDogW1BBVENI
IDEvM10gQWRkIEJUMyBBTVAgZGV2aWNlIHN1cHBvcnQsIGJ5IEF0aGVyb3MgTGludXggQlQzIHRl
YW0uDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gU2lnbmVkLW9mZi1ieTogSGFpanVuLkxpdSA8SGFp
anVuLkxpdUBBdGhlcm9zLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gIGluY2x1ZGUvbmV0L2JsdWV0
b290aC9oY2kuaCAgICAgIHwgIDM0MiArKysrKysrKysrKysrKysrKysrLQ0KPiA+ID4gIGluY2x1
ZGUvbmV0L2JsdWV0b290aC9oY2lfY29yZS5oIHwgIDI2NCArKysrKysrKysrKysrKy0NCj4gPiA+
ICBuZXQvYmx1ZXRvb3RoL2NtdHAvY29yZS5jICAgICAgICB8ICAgIDEgKw0KPiA+ID4gIG5ldC9i
bHVldG9vdGgvaGNpX2Nvbm4uYyAgICAgICAgIHwgIDIwMSArKysrKysrKysrKy0NCj4gPiA+ICBu
ZXQvYmx1ZXRvb3RoL2hjaV9jb3JlLmMgICAgICAgICB8ICAzNDkgKysrKysrKysrKysrKysrKysr
LS0NCj4gPiA+ICBuZXQvYmx1ZXRvb3RoL2hjaV9ldmVudC5jICAgICAgICB8ICA2OTggKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0NCj4gPiA+ICA2IGZpbGVzIGNoYW5nZWQs
IDE4MjIgaW5zZXJ0aW9ucygrKSwgMzMgZGVsZXRpb25zKC0pDQo+ID4gDQo+ID4gDQo+ID4gQ291
bGQgeW91IHNwbGl0IGFsbCB5b3VyIHBhdGNoZXMgaW4gbGl0dGxlIGNodW5rcz8gKzE4ODIgaXMg
dmVyeSBoYXJkIHRvDQo+ID4gcmV2aWV3LiBBbmQgcGxlYXNlIGJlIG1vcmUgdmVyYm9zZSBvbiB0
aGUgY29tbWl0IG1lc3NhZ2UsIGl0IGNhbiBoZWxwIHVzDQo+ID4gZmlndXJlIG91dCB3aGF0J3Mg
aGFwcGVuaW5nLg0KPiANCj4gVGhpcyB1c2VkIHRvIGJlIDEgbGFyZ2UgcGF0Y2gsIGl0IHdhcyBy
ZWNlbnRseSBzcGxpdCB1cCB0byAzLCBJIGhhdmVudCd0DQo+IGhhZCBhIGNoYW5jZSB5ZXQgdG8g
cmV2aWV3IGZ1cnRoZXIgYnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhpcyB0aGlzIHdhcw0KPiBz
cGxpdCB1cCBhcyBtdWNoIGFzIHBvc3NpYmxlIGluIHRoZSBsYXN0IHRyeS4gSWYgeW91IGNhbiBw
cm92aWRlIHN1Z2dlc3Rpb25zDQo+IGhvdyB0byBzcGxpdCBpdCB1cCBtb3JlIHRoYXQgbWlnaHQg
YmUgdXNlZnVsLCBidXQgYWdyZWVkLCBpZiBwb3NzaWJsZSBtb3JlDQo+IHNwbGl0dXAgd291bGQg
aGVscC4NCg0KQnV0IGl0IGlzIHN0aWxsIHRvbyBiaWcuIEkgbG9va2VkIHRvIHBhdGNoIDMvMywg
aXQgZG9lcyBhIGxvdCBkaWZmZXJlbnQNCnRoaW5ncyBpbiB0aGUgc2FtZSBwYXRjaCB0aGF0IG1h
a2UgdGhlIHBhdGNoIGltcG9zc2libGUgdG8gYmUgdHJhY2tlZC4NCldlIG5lZWQgYXRvbWljIHBh
dGNoZXMgZm9yIGF0IGxlYXN0IGVhY2ggY2hhbmdlIGluIHRoZSBFUlRNIGNvZGUsIGVhY2gNCm5l
dyBzdGF0ZSBhZGRlZCBpbiB0aGUgTDJDQVAgc3RhdGUgbWFjaGluZSwgZWFjaCBuZXcgSFMgZmVh
dHVyZSwgZXRjLA0KaS5lLiwgd2UgbmVlZCBwcm9wZXIgcGF0Y2hlcyB3aXRoIHByb3BlciBjb21t
aXQgbWVzc2FnZXMgZXhwbGFpbmluZw0Kd2hhdCdzIGhhcHBlbmluZy4gVGhlIHNhbWUgc2hvdWxk
IGFwcGx5IHRvIDEvMyBhbmQgMi8zLCBJIGRpZG4ndCBsb29rZWQNCnRvIHRoZW0uDQoNCj4gDQo+
IERhbiwgY2FuIHlvdSBhbHNvIHBsZWFzZSBkcm9wIHRoZSAiYnkgQXRoZXJvcyBMaW51eCBCVDMg
dGVhbS4iIG9uIHRoZSBzdWJqZWN0DQo+IG9mIHRoZSBwYXRjaGVzLiBUaGlzIGlzIGFscmVhZHkg
aW1wbGllZCBieSB0aGUgRnJvbSBhbmQgdGhlIFNpZ25lZC1vZmYtYnkuDQoNCkRhbiwgeW91ciBw
YXRjaGVzIGRvbid0IGFwcGx5IGNsZWFubHkgdXBzdHJlYW0sIHBsZWFzZSByZWJhc2UgdGhlbQ0K
YWdhaW5zdCBNYXJjZWwncyBibHVldG9vdGgtbmV4dCB0cmVlIGFuZCBkbyB0aGUgcHJvcGVyIHNw
bGl0IG9mIHRoZQ0KcGF0Y2hlcy4NCg0KLS0gDQpHdXN0YXZvIEYuIFBhZG92YW4NCmh0dHA6Ly9w
YWRvdmFuLm9yZw0K
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Ron Shaffer @ 2010-07-15 21:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1278972477.6282.10.camel@localhost.localdomain>
Marcel:
On 7/12/2010 5:07 PM, Marcel Holtmann wrote:
> Hi Ron,
>
>> Certain headsets such as the Motorola H350 will reject SCO and eSCO
>> connection requests while the ACL is transitioning from sniff mode
>> to active mode. Add synchronization so that SCO and eSCO connection
>> requests will wait until the ACL has fully transitioned to active mode.
>
> I find your patch actually highly complicated. So I tried to capture
> your intend the in the attached patch (only compiled test) and it would
> be good if you can try that.
>
> So in general it makes no difference which mode we are in. If a mode
> change is pending, then we have to delay the SCO setup. And once we are
> done we the mode change we just setup the SCO link. So in theory that
> should be enough. Not sure if that is true. I could have overlooked
> something since I don't really have tested the patch at all ;)
>
> Regards
>
> Marcel
>
Would have been back with you sooner on this but I'm having some
hardware issues preventing me from testing your code. I'm fairly
confident it works as you've consolidated the pending check into
hci_conn which I like.
However, the complicated pieces to which I think you are referring are
the error handling pieces which we should want want to keep. These make
sure that we clean up appropriately if:
1. The HW rejects the exit sniff or the SCO/eSCO request for some reason
i.e. in the case the HW returns a command status with a failure
2. In the latter case, the user space process is also notified that its
SCO/eSCO request has failed.
Give the cleanup code some thought. I think you'll see we want this
there to make the system more reliable.
As soon as I've confirmed your patch I'll get back to you.
In the meantime, I'll talk with Oleg and Matt regarding their responses.
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 3/5] Bluetooth: create a l2cap dir
From: Gustavo F. Padovan @ 2010-07-15 20:03 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1279041228.6282.20.camel@localhost.localdomain>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2010-07-13 14:13:48 -0300]:
> Hi Gustavo,
>
> > The dir is being created looking forward to the l2cap.c split.
> >
> > Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> > ---
> > net/bluetooth/Makefile | 2 +-
> > net/bluetooth/l2cap.c | 4859 ------------------------------------------
> > net/bluetooth/l2cap/Makefile | 5 +
> > net/bluetooth/l2cap/l2cap.c | 4859 ++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 4865 insertions(+), 4860 deletions(-)
> > delete mode 100644 net/bluetooth/l2cap.c
> > create mode 100644 net/bluetooth/l2cap/Makefile
> > create mode 100644 net/bluetooth/l2cap/l2cap.c
>
> hold off with this changes. We are not doing a separate directory
> anyway. I need more time to think about it.
Ok, so I can go with that inside the bluetooth directory. But we need
to sort this out soon. I think we can't go ahead with the L2CAP AMP
changes without split l2cap.c first, otherwise it will be very hard to
split l2cap.c in the future.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Bluetooth: Support for Atheros AR300x serial Bluetooth Chip
From: Gustavo F. Padovan @ 2010-07-15 19:52 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279191250-5923-1-git-send-email-suraj@atheros.com>
Hi Suraj,
* Suraj Sumangala <suraj@atheros.com> [2010-07-15 16:24:10 +0530]:
> Implements Atheros AR300x Serial HCI protocol.
> This protocol extends H4 serial protocol to implement enhanced power management
> features supported by Atheros AR300x serial Bluetooth chipsets.
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> drivers/bluetooth/Kconfig | 12 ++
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/hci_ath.c | 241 +++++++++++++++++++++++++++++++++++++++++
> drivers/bluetooth/hci_ldisc.c | 6 +
> drivers/bluetooth/hci_uart.h | 8 ++-
> 5 files changed, 267 insertions(+), 1 deletions(-)
> create mode 100755 drivers/bluetooth/hci_ath.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 058fbcc..c35047f 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -58,6 +58,18 @@ config BT_HCIUART_BCSP
>
> Say Y here to compile support for HCI BCSP protocol.
>
> +config BT_HCIUART_ATH3K
> + bool "Atheros AR300x serial Bluetooth support"
> + depends on BT_HCIUART
> + help
> + HCIATH3K (HCI Atheros AR300x Protocol) is a serial protocol
> + for communication between host and Atheros AR300x Bluetooth devices.
> + This protocol enables AR300x Chips to be enabled with
> + power management support.
> + Enable this if you have Atheros AR300x serial Bluetooth device.
> +
> + Say Y here to compile support for HCI UART ATH3K protocol.
> +
> config BT_HCIUART_LL
> bool "HCILL protocol support"
> depends on BT_HCIUART
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 7e5aed5..71bdf13 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -26,4 +26,5 @@ hci_uart-y := hci_ldisc.o
> hci_uart-$(CONFIG_BT_HCIUART_H4) += hci_h4.o
> hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
> hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
> +hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
> hci_uart-objs := $(hci_uart-y)
> diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> new file mode 100755
> index 0000000..e8da11b
> --- /dev/null
> +++ b/drivers/bluetooth/hci_ath.c
> @@ -0,0 +1,241 @@
> +/*
> + * Atheros Communication Bluetooth HCIATH UART protocol
> + *
> + * HCIATH3K (HCI Atheros AR300x Protocol) is a Atheros Communication's
> + * power management protocol extension to H4 to support AR300x Bluetooth Chip.
> + *
> + * Copyright (c) 2009-2010 Atheros Communications Inc.
> + *
> + * Acknowledgements:
> + * This file is based on hci_h4.c, which was written
> + * by Maxim Krasnyansky and Marcel Holtmann.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/tty.h>
> +#include <linux/errno.h>
> +#include <linux/ioctl.h>
> +#include <linux/skbuff.h>
> +
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include "hci_uart.h"
> +
> +struct ath_struct {
> + struct hci_uart *hu;
> + unsigned int cur_sleep;
> +
> + spinlock_t hciath_lock;
> + struct sk_buff *rx_skb;
> + struct sk_buff_head txq;
> + wait_queue_head_t wqevt;
> + struct work_struct ctxtsw;
> +};
> +
> +static int ath_wakeup_ar3k(struct tty_struct *tty)
> +{
> + struct termios settings;
> + int status = tty->driver->ops->tiocmget(tty, NULL);
> +
> + if (status & TIOCM_CTS)
> + return status;
> +
> + /* Disable Automatic RTSCTS */
> + n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
> + settings.c_cflag &= ~CRTSCTS;
> + n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
> +
> + /* Clear RTS first */
> + status = tty->driver->ops->tiocmget(tty, NULL);
> + tty->driver->ops->tiocmset(tty, NULL, 0x00, TIOCM_RTS);
> + mdelay(20);
> +
> + /* Set RTS, wake up board */
> + status = tty->driver->ops->tiocmget(tty, NULL);
> + tty->driver->ops->tiocmset(tty, NULL, TIOCM_RTS, 0x00);
> + mdelay(20);
> +
> + status = tty->driver->ops->tiocmget(tty, NULL);
> +
> + n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
> + settings.c_cflag |= CRTSCTS;
> + n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
> +
> + return status;
> +}
> +
> +static void ath_hci_uart_work(struct work_struct *work)
> +{
> + int status;
> + struct ath_struct *ath;
> + struct hci_uart *hu;
> + struct tty_struct *tty;
> +
> + ath = container_of(work, struct ath_struct, ctxtsw);
> +
> + hu = ath->hu;
> + tty = hu->tty;
> +
> + /* verify and wake up controller */
> + if (ath->cur_sleep) {
> + status = ath_wakeup_ar3k(tty);
> + if (!(status & TIOCM_CTS))
> + return;
> + }
> +
> + /* Ready to send Data */
> + clear_bit(HCI_UART_SENDING, &hu->tx_state);
> + hci_uart_tx_wakeup(hu);
> +}
> +
> +/* Initialize protocol */
> +static int ath_open(struct hci_uart *hu)
> +{
> + struct ath_struct *ath;
> +
> + BT_DBG("hu %p", hu);
> +
> + ath = kzalloc(sizeof(*ath), GFP_ATOMIC);
> + if (!ath)
> + return -ENOMEM;
> +
> + skb_queue_head_init(&ath->txq);
> + spin_lock_init(&ath->hciath_lock);
> +
> + hu->priv = ath;
> + ath->hu = hu;
> +
> + init_waitqueue_head(&ath->wqevt);
> + INIT_WORK(&ath->ctxtsw, ath_hci_uart_work);
> +
> + return 0;
> +}
> +
> +/* Flush protocol data */
> +static int ath_flush(struct hci_uart *hu)
> +{
> + struct ath_struct *ath = hu->priv;
> +
> + BT_DBG("hu %p", hu);
> +
> + skb_queue_purge(&ath->txq);
> +
> + return 0;
> +}
> +
> +/* Close protocol */
> +static int ath_close(struct hci_uart *hu)
> +{
> + struct ath_struct *ath = hu->priv;
> +
> + BT_DBG("hu %p", hu);
> +
> + skb_queue_purge(&ath->txq);
> + kfree_skb(ath->rx_skb);
> +
> + cancel_work_sync(&ath->ctxtsw);
> +
> + hu->priv = NULL;
> + kfree(ath);
> +
> + return 0;
> +}
> +
> +#define HCI_OP_ATH_SLEEP 0xFC04
> +
> +/* Enqueue frame for transmittion */
> +static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> +{
> + struct ath_struct *ath = hu->priv;
> +
> + if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
> + kfree(skb);
> + return 0;
> + }
> +
> + /*
> + * Update power management enable flag with parameters of
> + * HCI sleep enable vendor specific HCI command.
> + */
> + if (bt_cb(skb)->pkt_type == HCI_COMMAND_PKT) {
> + struct hci_command_hdr *hdr = (void *)skb->data;
> +
> + if (__le16_to_cpu(hdr->opcode) == HCI_OP_ATH_SLEEP)
> + ath->cur_sleep = skb->data[HCI_COMMAND_HDR_SIZE];
> + }
> +
> + BT_DBG("hu %p skb %p", hu, skb);
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> +
> + skb_queue_tail(&ath->txq, skb);
> + set_bit(HCI_UART_SENDING, &hu->tx_state);
> +
> + schedule_work(&ath->ctxtsw);
> +
> + return 0;
> +}
> +
> +static struct sk_buff *ath_dequeue(struct hci_uart *hu)
> +{
> + struct ath_struct *ath = hu->priv;
> +
> + return skb_dequeue(&ath->txq);
> +}
> +
> +/* Recv data */
> +static int ath_recv(struct hci_uart *hu, void *data, int count)
> +{
> + if (hci_recv_stream_fragment(hu->hdev, data, count) < 0)
> + BT_ERR("Frame Reassembly Failed");
> +
> + return count;
> +}
> +
> +static struct hci_uart_proto athp = {
> + .id = HCI_UART_ATH,
> + .open = ath_open,
> + .close = ath_close,
> + .recv = ath_recv,
> + .enqueue = ath_enqueue,
> + .dequeue = ath_dequeue,
> + .flush = ath_flush,
> +};
> +
> +int ath_init(void)
> +{
> + int err = hci_uart_register_proto(&athp);
> +
> + if (!err)
> + BT_INFO("HCIATH protocol initialized");
> + else
> + BT_ERR("HCIATH protocol registration failed");
> +
> + return err;
> +}
> +
> +int ath_deinit(void)
> +{
> + return hci_uart_unregister_proto(&athp);
> +}
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index a57dbfc..998833d 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -552,6 +552,9 @@ static int __init hci_uart_init(void)
> #ifdef CONFIG_BT_HCIUART_LL
> ll_init();
> #endif
> +#ifdef CONFIG_BT_HCIUART_ATH3K
> + ath_init();
> +#endif
>
> return 0;
> }
> @@ -569,6 +572,9 @@ static void __exit hci_uart_exit(void)
> #ifdef CONFIG_BT_HCIUART_LL
> ll_deinit();
> #endif
> +#ifdef CONFIG_BT_HCIUART_ATH3K
> + ath_deinit();
> +#endif
>
> /* Release tty registration of line discipline */
> if ((err = tty_unregister_ldisc(N_HCI)))
> diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
> index 9694d9d..107604e 100644
> --- a/drivers/bluetooth/hci_uart.h
> +++ b/drivers/bluetooth/hci_uart.h
> @@ -35,13 +35,14 @@
> #define HCIUARTGETFLAGS _IOR('U', 204, int)
>
> /* UART protocols */
> -#define HCI_UART_MAX_PROTO 5
> +#define HCI_UART_MAX_PROTO 6
>
> #define HCI_UART_H4 0
> #define HCI_UART_BCSP 1
> #define HCI_UART_3WIRE 2
> #define HCI_UART_H4DS 3
> #define HCI_UART_LL 4
> +#define HCI_UART_ATH 5
>
> #define HCI_UART_RAW_DEVICE 0
>
> @@ -96,3 +97,8 @@ int bcsp_deinit(void);
> int ll_init(void);
> int ll_deinit(void);
> #endif
> +
> +#ifdef CONFIG_BT_HCIUART_ATH3K
> +int ath_init(void);
> +int ath_deinit(void);
> +#endif
> --
> 1.7.0.4
Patch looks fine, nevertheless I'm unable to test it since I don't have
such hardware.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: Gustavo F. Padovan @ 2010-07-15 19:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dan Tian, linux-bluetooth@vger.kernel.org, Haijun Liu,
Luis Rodriguez
In-Reply-To: <20100715184308.GF1166@tux>
Hi Luis,
* Luis R. Rodriguez <lrodriguez@atheros.com> [2010-07-15 11:43:08 -0700]:
> On Thu, Jul 15, 2010 at 08:09:21AM -0700, Gustavo F. Padovan wrote:
> > Hi Dan,
> >
> > * Dan Tian <Dan.Tian@Atheros.com> [2010-07-15 15:37:32 +0800]:
> >
> > > From 40cbfbf5c1bc9109364970956d9b6f74f5846c70 Mon Sep 17 00:00:00 2001
> > > From: Haijun.Liu <Haijun.Liu@Atheros.com>
> > > Date: Wed, 14 Jul 2010 22:50:56 +0800
> > > Subject: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
> > >
> > >
> > > Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
> > > ---
> > > include/net/bluetooth/hci.h | 342 +++++++++++++++++++-
> > > include/net/bluetooth/hci_core.h | 264 ++++++++++++++-
> > > net/bluetooth/cmtp/core.c | 1 +
> > > net/bluetooth/hci_conn.c | 201 +++++++++++-
> > > net/bluetooth/hci_core.c | 349 ++++++++++++++++++--
> > > net/bluetooth/hci_event.c | 698 +++++++++++++++++++++++++++++++++++++-
> > > 6 files changed, 1822 insertions(+), 33 deletions(-)
> >
> >
> > Could you split all your patches in little chunks? +1882 is very hard to
> > review. And please be more verbose on the commit message, it can help us
> > figure out what's happening.
>
> This used to be 1 large patch, it was recently split up to 3, I havent't
> had a chance yet to review further but my understanding is this this was
> split up as much as possible in the last try. If you can provide suggestions
> how to split it up more that might be useful, but agreed, if possible more
> splitup would help.
But it is still too big. I looked to patch 3/3, it does a lot different
things in the same patch that make the patch impossible to be tracked.
We need atomic patches for at least each change in the ERTM code, each
new state added in the L2CAP state machine, each new HS feature, etc,
i.e., we need proper patches with proper commit messages explaining
what's happening. The same should apply to 1/3 and 2/3, I didn't looked
to them.
>
> Dan, can you also please drop the "by Atheros Linux BT3 team." on the subject
> of the patches. This is already implied by the From and the Signed-off-by.
Dan, your patches don't apply cleanly upstream, please rebase them
against Marcel's bluetooth-next tree and do the proper split of the
patches.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox