* Re: [PATCH BlueZ] android/test-ipc: Use correct boolean values for glib functions
From: Szymon Janc @ 2014-02-12 19:21 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1392232401-26119-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Wednesday 12 of February 2014 15:13:21 Anderson Lizardo wrote:
> ---
> android/test-ipc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/android/test-ipc.c b/android/test-ipc.c
> index 3a0729e..2def97b 100644
> --- a/android/test-ipc.c
> +++ b/android/test-ipc.c
> @@ -263,8 +263,8 @@ static void execute_context(struct context *context)
> {
> g_main_loop_run(context->main_loop);
>
> - g_io_channel_shutdown(context->notif_io, true, NULL);
> - g_io_channel_shutdown(context->cmd_io, true, NULL);
> + g_io_channel_shutdown(context->notif_io, TRUE, NULL);
> + g_io_channel_shutdown(context->cmd_io, TRUE, NULL);
> g_io_channel_unref(context->cmd_io);
> g_io_channel_unref(context->notif_io);
Applied, thanks.
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH] android/README: Add note on libglib under Valgrind
From: Andrzej Kaczmarek @ 2014-02-12 19:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
---
android/README | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/android/README b/android/README
index 75b0a83..3095383 100644
--- a/android/README
+++ b/android/README
@@ -124,6 +124,12 @@ After changing property value Bluetooth need to be restarted to apply changes
(this can be done using UI, just disable and enable it again). Property is
persistent, i.e. there's no need to enable Valgrind again after reboot.
+It's recommended to have unstripped libglib.so installed which will enable
+complete backtraces in Valgrind output. Otherwise, in many cases backtrace
+will break at e.g. g_free() function without prior callers. It's possible to
+have proper library installed automatically by appropriate entry in Android.mk,
+see https://code.google.com/p/aosp-bluez.glib/ for an example.
+
=============================
Building and running on Linux
=============================
--
1.8.5.4
^ permalink raw reply related
* partial success with PS3 sixaxis
From: Andrea @ 2014-02-12 21:31 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I've been trying to pair a PS3 sixaxis controller using bluez 5.14
I've had so far only partial success.
It connects, creates js0 and event0 devices, but after a few seconds it removes them.
The lights are always flashing.
I am on a Raspberry running ArchLinux.
This is the output of bluetoothctl
...
[bluetooth]# disconnect
[CHG] Device 00:0B:EB:63:F2:62 Connected: yes
[bluetooth]# disconnect show
[bluetooth]# disconnect 00:0B:EB:63:F2:62
Attempting to disconnect from 00:0B:EB:63:F2:62
Successful disconnected
[CHG] Device 00:0B:EB:63:F2:62 Connected: no
[CHG] Device 00:0B:EB:63:F2:62 Connected: yes
then in dmesg I can see
[ 2745.435967] sony 0005:054C:0268.0008: Fixing up Sony Sixaxis report descriptor
[ 2745.452105] sony 0005:054C:0268.0008: unknown main item tag 0x0
[ 2745.471504] input: PLAYSTATION(R)3 Controller as
/devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/bluetooth/hci0/hci0:11/input7
[ 2745.472795] sony 0005:054C:0268.0008: input,hidraw0: BLUETOOTH HID v1.00 Joystick
[PLAYSTATION(R)3 Controller] on 00:0b:0d:4c:94:a6
[ 2755.472242] sony: probe of 0005:054C:0268.0008 failed with error -5
the hardware should be ok as it works using sixad & sixpair.
any idea what could be going wrong?
I am not even sure if I am doing the right thing to pair, trust, connect etc... as I cannot google
anything using bluez 5 + ps3. All the howtos are for sixad.
Andrea
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Marcel Holtmann @ 2014-02-12 22:58 UTC (permalink / raw)
To: Peter Hurley
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <52F95A10.5010507@hurleysoftware.com>
Hi Peter,
>>> This patch series addresses a number of previously unknown issues
>>> with the RFCOMM tty device implementation, in addition to
>>> addressing the locking regression recently reported [1].
>>>
>>> As Gianluca suggested and I agree, this series first reverts
>>> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
>>
>> so for 3.14 we should revert 3 patches. And then the other 21 are
> > intended for 3.15 merge window.
>
> Yep, this is probably best. At least 3.13 & 3.14 will behave the
> same wrt rfcomm.
>
>> I realize that we still have to deal with some breakage, but we
> > do not want regressions and I clearly not going to take 24 patches
> > for 3.14 at this point in time.
>
> Yeah, I wasn't expecting you to.
>
>> What I can do is take all 24 patches into bluetooth-next and let
> > them sit for 1 week and have people test them. And then we go ahead
> > with reverting 3 patches from 3.14. Does that make sense?
>
> Yep, that's fine with me. Thanks.
we might also want to add some end-to-end test cases to rfcomm-tester that covers this behavior.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix channel check when binding RFCOMM sock
From: Marcel Holtmann @ 2014-02-12 23:01 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <CAF3PWx0PkL8fQ2ypsU24xM1HveQAia19OFDLcX9D=90_Oo9Vig@mail.gmail.com>
Hi Andrzej,
>>> When binding RFCOMM socket we should only check if there is another
>>> socket bound or listening on the same channel number. In other case,
>>> it won't be possible to bind/listen on a channel in case we have
>>> connection made to remote device on the same channel number.
>>
>> since this has been used for years now, you need to be more specific on when this fails.
>
> It's quite simple: create one socket and connect on channel X, then
> create another socket and try to bind on channel X. Event though we
> don't have listening socket on channel X yet, it will fail with
> EADDRINUSE since rfcomm_sock_bind looks for *any* socket on specified
> channel and doesn't care if it's bound/listening on local channel or
> just connected to remote channel (in which case it should not fail).
>
> Is it specific enough?
can we add a test case to rfcomm-tester for this first.
>>> Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
>>> ---
>>> net/bluetooth/rfcomm/sock.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>>> index 00573fb..9912e23 100644
>>> --- a/net/bluetooth/rfcomm/sock.c
>>> +++ b/net/bluetooth/rfcomm/sock.c
>>> @@ -331,6 +331,7 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>>> {
>>> struct sockaddr_rc *sa = (struct sockaddr_rc *) addr;
>>> struct sock *sk = sock->sk;
>>> + struct sock *sk1;
>>> int err = 0;
>>>
>>> BT_DBG("sk %p %pMR", sk, &sa->rc_bdaddr);
>>> @@ -352,7 +353,9 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>>>
>>> write_lock(&rfcomm_sk_list.lock);
>>>
>>> - if (sa->rc_channel && __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr)) {
>>> + sk1 = __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr);
>>> + if (sa->rc_channel && sk1 && (sk1->sk_state == BT_BOUND ||
>>> + sk1->sk_state == BT_LISTEN)) {
>>> err = -EADDRINUSE;
>>
>> can we find a better name than sk1 here.
>
> Something like 'existing_sk'? Or just 'oldsk'? I have no clue how to
> make a meaningful name here.
I wonder if you should not just fix __rfcomm_get_sock_by_addr to check only for BT_BOUND and BT_LISTEN.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3] hog: Use HoG device name as uHID input device name
From: Petri Gynther @ 2014-02-13 0:29 UTC (permalink / raw)
To: linux-bluetooth
Any comments on this patch?
In uHID kernel driver, uhid_dev_create() does:
...
strncpy(hid->name, ev->u.create.name, 127);
hid->name[127] = 0;
strncpy(hid->phys, ev->u.create.phys, 63);
hid->phys[63] = 0;
strncpy(hid->uniq, ev->u.create.uniq, 63);
hid->uniq[63] = 0;
Also, BlueZ already does this with HID input devices.
input_device_new() copies Bluetooth device name into idev->name. And
then, hidp_add_connection() copies idev->name to req->name and passes
it to kernel. In kernel, hidp_setup_hid() populates hid->name,
hid->phys, and hid->uniq.
On Wed, Jan 29, 2014 at 7:55 PM, Petri Gynther <pgynther@google.com> wrote:
> If HoG BLE device name is known, use it when creating uHID input device.
> Pass adapter and device addresses to uHID as well.
> ---
> profiles/input/hog.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/input/hog.c b/profiles/input/hog.c
> index ded6303..030dc91 100644
> --- a/profiles/input/hog.c
> +++ b/profiles/input/hog.c
> @@ -392,7 +392,15 @@ static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
> /* create uHID device */
> memset(&ev, 0, sizeof(ev));
> ev.type = UHID_CREATE;
> - strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + if (device_name_known(hogdev->device)) {
> + device_get_name(hogdev->device, (char *) ev.u.create.name,
> + sizeof(ev.u.create.name) - 1);
> + } else {
> + strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + }
> + ba2str(btd_adapter_get_address(device_get_adapter(hogdev->device)),
> + (char *) ev.u.create.phys);
> + ba2str(device_get_address(hogdev->device), (char *) ev.u.create.uniq);
> ev.u.create.vendor = vendor;
> ev.u.create.product = product;
> ev.u.create.version = version;
> --
> 1.8.5.3
>
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Peter Hurley @ 2014-02-13 0:38 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <433F6D97-A126-4F9F-96AC-4385575E005E@holtmann.org>
Hi Marcel,
On 02/12/2014 05:58 PM, Marcel Holtmann wrote:
> we might also want to add some end-to-end test cases to rfcomm-tester that covers this behavior.
Are there some docs for the linux-bluetooth test harness?
I have some unit tests that I can port but I should probably understand
the bluetooth test framework first. A lot of my unit tests are designed
to test races with the ioctl interface, device creation and initialization,
teardown, tty open, close, etc.
Would that kind of unit test fit in the test harness design?
Regards,
Peter Hurley
^ permalink raw reply
* [PATCH] adapter: Handle MGMT_SETTING_LE change
From: Petri Gynther @ 2014-02-13 1:45 UTC (permalink / raw)
To: linux-bluetooth
On some BLE-capable adapters, BLE is not enabled by default. When BLE is
enabled after the adapter is already powered up, we need to call
trigger_passive_scanning() so that paired BLE devices (e.g. HoG devices)
are able to reconnect back to host.
bluetoothd[1087]: src/adapter.c:adapter_start() adapter /org/bluez/hci0 has been enabled
bluetoothd[1087]: src/adapter.c:load_link_keys_complete() link keys loaded for hci0
bluetoothd[1087]: src/adapter.c:load_ltks_complete() LTKs loaded for hci0
bluetoothd[1087]: src/adapter.c:get_connections_complete() Connection count: 0
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000000c1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000040
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002c1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000200
=> BLE got enabled, adapter already up, need to call trigger_passive_scanning()
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002d1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000010
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002d3
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000002
---
src/adapter.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 18601ea..01006f2 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -405,6 +405,7 @@ static void store_adapter_info(struct btd_adapter *adapter)
static void trigger_pairable_timeout(struct btd_adapter *adapter);
static void adapter_start(struct btd_adapter *adapter);
static void adapter_stop(struct btd_adapter *adapter);
+static void trigger_passive_scanning(struct btd_adapter *adapter);
static void settings_changed(struct btd_adapter *adapter, uint32_t settings)
{
@@ -434,6 +435,13 @@ static void settings_changed(struct btd_adapter *adapter, uint32_t settings)
}
}
+ if (changed_mask & MGMT_SETTING_LE) {
+ if ((adapter->current_settings & MGMT_SETTING_POWERED) &&
+ (adapter->current_settings & MGMT_SETTING_LE)) {
+ trigger_passive_scanning(adapter);
+ }
+ }
+
if (changed_mask & MGMT_SETTING_CONNECTABLE)
g_dbus_emit_property_changed(dbus_conn, adapter->path,
ADAPTER_INTERFACE, "Connectable");
--
1.9.0.rc1.175.g0b1dcb5
^ permalink raw reply related
* Re: [PATCH 1/4] android/haltest: Remove unneeded assignment
From: Andrei Emeltchenko @ 2014-02-13 8:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJq3wWht-Jk7BP=dkEnsTG2o8fXiF8JycJr_prMvQe0NA@mail.gmail.com>
Hi Luiz,
On Mon, Feb 10, 2014 at 02:16:09PM +0200, Luiz Augusto von Dentz wrote:
> Hi Andrei,
>
> On Fri, Feb 7, 2014 at 2:11 PM, Andrei Emeltchenko
> <Andrei.Emeltchenko.news@gmail.com> wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> > ---
> > android/client/if-audio.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/android/client/if-audio.c b/android/client/if-audio.c
> > index 8c640a1..5ab11a6 100644
> > --- a/android/client/if-audio.c
> > +++ b/android/client/if-audio.c
> > @@ -225,10 +225,8 @@ static void *playback_thread(void *data)
> > pthread_mutex_unlock(&outstream_mutex);
> > } while (len && w_len > 0);
> >
> > - if (in) {
> > + if (in)
> > fclose(in);
> > - in = NULL;
> > - }
> >
> > pthread_cleanup_pop(1);
> > return NULL;
> > --
> > 1.8.3.2
>
> Pushed, note that I did move the changes from audio to android since
> the audio code will be dropped as it is not unit tested.
I still think that those patches needs to applied otherwise we have
following warnings:
...
CC profiles/audio/bluetoothd-avdtp.o
profiles/audio/avdtp.c:2735:2: warning: Null pointer passed as an argument
to a 'nonnull' parameter
memcpy(req->data, buffer, size);
^ ~~~~~~
profiles/audio/avdtp.c:3290:2: warning: Null pointer passed as an argument
to a 'nonnull' parameter
memcpy(cap->data, data, length);
^ ~~~~
2 warnings generated.
...
You may choose to fix those warns other ways though.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv3] hog: Use HoG device name as uHID input device name
From: Johan Hedberg @ 2014-02-13 9:19 UTC (permalink / raw)
To: Petri Gynther; +Cc: linux-bluetooth
In-Reply-To: <20140130035506.2A034100F4B@puck.mtv.corp.google.com>
Hi Petri,
On Wed, Jan 29, 2014, Petri Gynther wrote:
> If HoG BLE device name is known, use it when creating uHID input device.
> Pass adapter and device addresses to uHID as well.
Could you perhaps elaborate a bit what exactly the "uniq" and "phys"
members are in the request (possibly with a reference to the uHID
documentation). That would make it easier to verify that the content
you're adding to them makes sense.
> + if (device_name_known(hogdev->device)) {
> + device_get_name(hogdev->device, (char *) ev.u.create.name,
> + sizeof(ev.u.create.name) - 1);
> + } else {
> + strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + }
We don't use { } for single line branches, so you can drop these here.
> + ba2str(btd_adapter_get_address(device_get_adapter(hogdev->device)),
> + (char *) ev.u.create.phys);
This is getting a bit messy with the nested function calls. I'd add
separate adapter variable here to make this a bit more readable.
Also note our coding style wrt split lines: indent the continuation
lines as much as you can (with tabs) as long as it's under 80 chars.
Also, it might be good to split this up into two patches since you've
essentially got two independent improvements here. One is making sure
the name member contains something more useful and the other is adding
some content to the uniq and phys members.
Johan
^ permalink raw reply
* Re: partial success with PS3 sixaxis
From: Szymon Janc @ 2014-02-13 9:25 UTC (permalink / raw)
To: Andrea; +Cc: linux-bluetooth
In-Reply-To: <52FBE820.6050701@gmail.com>
Hi Andrea,
On Wednesday 12 of February 2014 21:31:12 Andrea wrote:
> Hi,
>
> I've been trying to pair a PS3 sixaxis controller using bluez 5.14
> I've had so far only partial success.
>
> It connects, creates js0 and event0 devices, but after a few seconds it removes them.
>
> The lights are always flashing.
>
> I am on a Raspberry running ArchLinux.
>
> This is the output of bluetoothctl
>
> ...
> [bluetooth]# disconnect
> [CHG] Device 00:0B:EB:63:F2:62 Connected: yes
> [bluetooth]# disconnect show
> [bluetooth]# disconnect 00:0B:EB:63:F2:62
> Attempting to disconnect from 00:0B:EB:63:F2:62
> Successful disconnected
> [CHG] Device 00:0B:EB:63:F2:62 Connected: no
> [CHG] Device 00:0B:EB:63:F2:62 Connected: yes
>
> then in dmesg I can see
>
> [ 2745.435967] sony 0005:054C:0268.0008: Fixing up Sony Sixaxis report descriptor
> [ 2745.452105] sony 0005:054C:0268.0008: unknown main item tag 0x0
> [ 2745.471504] input: PLAYSTATION(R)3 Controller as
> /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/bluetooth/hci0/hci0:11/input7
> [ 2745.472795] sony 0005:054C:0268.0008: input,hidraw0: BLUETOOTH HID v1.00 Joystick
> [PLAYSTATION(R)3 Controller] on 00:0b:0d:4c:94:a6
> [ 2755.472242] sony: probe of 0005:054C:0268.0008 failed with error -5
>
> the hardware should be ok as it works using sixad & sixpair.
>
> any idea what could be going wrong?
> I am not even sure if I am doing the right thing to pair, trust, connect etc... as I cannot google
> anything using bluez 5 + ps3. All the howtos are for sixad.
This should "just work". Since 5.14 there is authorization needed when DS3 is
connecting (device is not marked as trusted when connected on USB) so please
make sure you have default agent registered.
I assume you are using bluetoothctl so do:
agent on
default-agent
Then you should get authorization request in bluetoothctl when DS3 is connecting.
--
Best regards,
Szymon Janc
^ permalink raw reply
* [PATCH] android: Fix for BT Turn off while pairing
From: Lukasz Rymanowski @ 2014-02-13 10:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Rymanowski
This patch fix an issue when Android disables BT during ongoing
paring. In this case mgmt did not accept any commands and BT gets
in some unknown state.
Since Android turns off BT anyway, it is ok to just cancel all
the mgmt requests before send power off command.
---
android/bluetooth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index ff41627..ad8cfec 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -2907,6 +2907,9 @@ static void handle_disable_cmd(const void *buf, uint16_t len)
goto reply;
}
+ /* Cancel all pending requests. Need it in case of ongoing paring */
+ mgmt_cancel_index(mgmt_if, adapter.index);
+
if (!set_mode(MGMT_OP_SET_POWERED, 0x00)) {
status = HAL_STATUS_FAILED;
goto reply;
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] adapter: Handle MGMT_SETTING_LE change
From: Johan Hedberg @ 2014-02-13 12:41 UTC (permalink / raw)
To: Petri Gynther; +Cc: linux-bluetooth
In-Reply-To: <20140213014521.59803100423@puck.mtv.corp.google.com>
Hi Petri,
On Wed, Feb 12, 2014, Petri Gynther wrote:
> On some BLE-capable adapters, BLE is not enabled by default. When BLE is
> enabled after the adapter is already powered up, we need to call
> trigger_passive_scanning() so that paired BLE devices (e.g. HoG devices)
> are able to reconnect back to host.
No dual-mode adapter should have LE enabled by default and we do have
the following piece of code that gets run for any newly discovered
adapter:
if ((adapter->supported_settings & MGMT_SETTING_LE) &&
!(adapter->current_settings & MGMT_SETTING_LE))
set_mode(adapter, MGMT_OP_SET_LE, 0x01);
So the commit message is a bit confusing to me. How exactly do you end
up reproducing this scenario? I could imagine this maybe happening if
bluetoothd crashes and gets restarted when the adapter state is already
powered on. Either way you should explain this in the commit message.
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -405,6 +405,7 @@ static void store_adapter_info(struct btd_adapter *adapter)
> static void trigger_pairable_timeout(struct btd_adapter *adapter);
> static void adapter_start(struct btd_adapter *adapter);
> static void adapter_stop(struct btd_adapter *adapter);
> +static void trigger_passive_scanning(struct btd_adapter *adapter);
Since we try to avoid forward declarations like this whenever possible, did you
investigate what would be needed to not need it here. I.e. is it really
a lot of dependent functions that would need to be moved further up
together with trigger_passive_scanning() or is there even a circular
dependency somewhere that makes the forward declaration inevitable?
> + if (changed_mask & MGMT_SETTING_LE) {
> + if ((adapter->current_settings & MGMT_SETTING_POWERED) &&
> + (adapter->current_settings & MGMT_SETTING_LE)) {
> + trigger_passive_scanning(adapter);
> + }
> + }
The { } isn't needed for the internal if-statement.
Johan
^ permalink raw reply
* [PATCH] tools/rfcomm-tester: Add bind after connected test case
From: Andrzej Kaczmarek @ 2014-02-13 14:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
This testcase will check if it's possible to bind socket on the same
channel number as used by some other socket connected to remote device.
---
tools/rfcomm-tester.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
index 44df7e7..c6aa8c7 100644
--- a/tools/rfcomm-tester.c
+++ b/tools/rfcomm-tester.c
@@ -56,6 +56,7 @@ struct test_data {
struct rfcomm_client_data {
uint8_t server_channel;
uint8_t client_channel;
+ uint8_t bind_channel;
int expected_connect_err;
};
@@ -300,6 +301,12 @@ const struct rfcomm_client_data connect_nval = {
.expected_connect_err = -ECONNREFUSED
};
+const struct rfcomm_client_data connect_bind_success = {
+ .server_channel = 0x0c,
+ .client_channel = 0x0c,
+ .bind_channel = 0x0c
+};
+
const struct rfcomm_server_data listen_success = {
.server_channel = 0x0c,
.client_channel = 0x0c,
@@ -371,6 +378,7 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
{
struct test_data *data = tester_get_data();
const struct rfcomm_client_data *client_data = data->test_data;
+ const uint8_t *master_addr;
socklen_t len = sizeof(int);
int sk, err, sk_err;
@@ -389,10 +397,24 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
return false;
}
- if (err < 0)
+ if (!client_data->bind_channel) {
+ if (err < 0)
+ tester_test_failed();
+ else
+ tester_test_passed();
+ return false;
+ }
+
+ master_addr = hciemu_get_master_bdaddr(data->hciemu);
+ sk = create_rfcomm_sock((bdaddr_t *) master_addr,
+ client_data->bind_channel);
+ if (sk < 0) {
tester_test_failed();
- else
+ } else {
+ close(sk);
tester_test_passed();
+ }
+
return false;
}
@@ -546,6 +568,9 @@ int main(int argc, char *argv[])
setup_powered_server, test_server);
test_rfcomm("Basic RFCOMM Socket Server - Conn Refused", &listen_nval,
setup_powered_server, test_server);
+ test_rfcomm("Basic RFCOMM Socket Server - Bind Connected",
+ &connect_bind_success, setup_powered_client,
+ test_connect);
return tester_run();
}
--
1.8.5.4
^ permalink raw reply related
* [PATCH v2] Bluetooth: Fix channel check when binding RFCOMM sock
From: Andrzej Kaczmarek @ 2014-02-13 14:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
When binding RFCOMM socket with non-zero channel we're checking if
there is already any other socket which has the same channel number
assigned and then fail. This check does not consider situation where
we have another socket connected to remote device on given channel
number in which case we still should be able to bind local socket.
This patch changes __rfcomm_get_sock_by_addr() to return only sockets
in either BT_BOUND or BT_LISTEN states, also name is updated to better
describe what this function does now.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
---
net/bluetooth/rfcomm/sock.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 00573fb..1a59ddd 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -105,13 +105,18 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
}
/* ---- Socket functions ---- */
-static struct sock *__rfcomm_get_sock_by_addr(u8 channel, bdaddr_t *src)
+static struct sock *__rfcomm_get_listen_sock_by_addr(u8 channel, bdaddr_t *src)
{
struct sock *sk = NULL;
sk_for_each(sk, &rfcomm_sk_list.head) {
- if (rfcomm_pi(sk)->channel == channel &&
- !bacmp(&rfcomm_pi(sk)->src, src))
+ if (rfcomm_pi(sk)->channel != channel)
+ continue;
+
+ if (bacmp(&rfcomm_pi(sk)->src, src))
+ continue;
+
+ if (sk->sk_state == BT_BOUND || sk->sk_state == BT_LISTEN)
break;
}
@@ -352,7 +357,8 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
write_lock(&rfcomm_sk_list.lock);
- if (sa->rc_channel && __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr)) {
+ if (sa->rc_channel && __rfcomm_get_listen_sock_by_addr(sa->rc_channel,
+ &sa->rc_bdaddr)) {
err = -EADDRINUSE;
} else {
/* Save source address */
@@ -439,7 +445,7 @@ static int rfcomm_sock_listen(struct socket *sock, int backlog)
write_lock(&rfcomm_sk_list.lock);
for (channel = 1; channel < 31; channel++)
- if (!__rfcomm_get_sock_by_addr(channel, src)) {
+ if (!__rfcomm_get_listen_sock_by_addr(channel, src)) {
rfcomm_pi(sk)->channel = channel;
err = 0;
break;
--
1.8.5.4
^ permalink raw reply related
* [PATCH BlueZ 01/12] android/hal-ipc-api: Add Remote Features notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 14 ++++++++++++--
android/hal-msg.h | 6 ++++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index c1609c9..70f947d 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1300,8 +1300,18 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid type values : 0x00 = Interim
0x01 = Changed
- Opcode 0x81 - Get Play Status notification
- Opcode 0x82 - List Player Application Attributes notification
+ Opcode 0x81 - Remote Features notification
+
+ Notification parameters: Remote address (6 octets)
+ Features (1 octet)
+
+ Valid features values : 0x00 = None
+ 0x01 = Metadata
+ 0x02 = Absolute Volume
+ 0x03 = Browse
+
+ Opcode 0x82 - Get Play Status notification
+ Opcode 0x83 - List Player Application Attributes notification
...
diff --git a/android/hal-msg.h b/android/hal-msg.h
index ca1f6b5..f6cdf58 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -881,3 +881,9 @@ struct hal_cmd_avrcp_register_notification {
uint8_t len;
uint8_t data[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_REMOTE_FEATURES 0x81
+struct hal_ev_avrcp_remote_features {
+ uint8_t bdaddr[6];
+ uint8_t features;
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 02/12] android/hal-ipc-api: Add Get Play Status notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 3 +++
android/hal-msg.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 70f947d..ce50b6c 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1311,6 +1311,9 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
0x03 = Browse
Opcode 0x82 - Get Play Status notification
+
+ Notification parameters: <none>
+
Opcode 0x83 - List Player Application Attributes notification
...
diff --git a/android/hal-msg.h b/android/hal-msg.h
index f6cdf58..7dfbf2a 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -887,3 +887,5 @@ struct hal_ev_avrcp_remote_features {
uint8_t bdaddr[6];
uint8_t features;
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_GET_PLAY_STATUS 0x82
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 03/12] android/hal-ipc-api: Add List Player Attributes notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 5 +++--
android/hal-msg.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index ce50b6c..aa35050 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1314,8 +1314,9 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Notification parameters: <none>
- Opcode 0x83 - List Player Application Attributes notification
- ...
+ Opcode 0x83 - List Player Attributes notification
+
+ Notification parameters: <none>
Bluetooth GATT HAL (ID 9)
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 7dfbf2a..9536b85 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -889,3 +889,4 @@ struct hal_ev_avrcp_remote_features {
} __attribute__((packed));
#define HAL_EV_AVRCP_GET_PLAY_STATUS 0x82
+#define HAL_EV_AVRCP_LIST_PLAYER_ATTRS 0x83
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 04/12] android/hal-ipc-api: Add List Player Values notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 6 ++++++
android/hal-msg.h | 5 +++++
2 files changed, 11 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index aa35050..56df5b0 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1318,6 +1318,12 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Notification parameters: <none>
+ Opcode 0x84 - List Player Values notification
+
+ Notification parameters: Attribute (1 octet)
+
+ Valid attribute values: Same as in List Player Attributes
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 9536b85..55cea27 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -890,3 +890,8 @@ struct hal_ev_avrcp_remote_features {
#define HAL_EV_AVRCP_GET_PLAY_STATUS 0x82
#define HAL_EV_AVRCP_LIST_PLAYER_ATTRS 0x83
+
+#define HAL_EV_AVRCP_LIST_PLAYER_VALUES 0x84
+struct hal_ev_avrcp_list_player_values {
+ uint8_t attr;
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 05/12] android/hal-ipc-api: Add Get Player Values notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 7 +++++++
android/hal-msg.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 56df5b0..fd687fb 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1324,6 +1324,13 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in List Player Attributes
+ Opcode 0x85 - Get Player Values notification
+
+ Notification parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ ...
+
+ Valid attribute values: Same as in List Player Attributes
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 55cea27..d5d91dd 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -895,3 +895,9 @@ struct hal_ev_avrcp_remote_features {
struct hal_ev_avrcp_list_player_values {
uint8_t attr;
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_GET_PLAYER_VALUES 0x85
+struct hal_ev_avrcp_get_player_values {
+ uint8_t number;
+ uint8_t attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 06/12] android/hal-ipc-api: Add Get Player Attributes Text notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 8 ++++++++
android/hal-msg.h | 6 ++++++
2 files changed, 14 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index fd687fb..0810078 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1332,6 +1332,14 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in List Player Attributes
+ Opcode 0x86 - Get Player Attributes Text notification
+
+ Notification parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ ...
+
+ Valid attribute values: Same as in List Player Attributes
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index d5d91dd..67fccb9 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -901,3 +901,9 @@ struct hal_ev_avrcp_get_player_values {
uint8_t number;
uint8_t attrs[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_GET_PLAYER_ATTRS_TEXT 0x86
+struct hal_ev_avrcp_get_player_attrs_text {
+ uint8_t number;
+ uint8_t attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 07/12] android/hal-ipc-api: Add Get Player Values Text notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 9 +++++++++
android/hal-msg.h | 7 +++++++
2 files changed, 16 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 0810078..362cdf4 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1340,6 +1340,15 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in List Player Attributes
+ Opcode 0x87 - Get Player Values Text notification
+
+ Notification parameters: Attribute (1 octet)
+ Number of values (1 octet)
+ Value # (1 octet)
+ ...
+
+ Valid attribute values: Same as in List Player Attributes
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 67fccb9..188e7c2 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -907,3 +907,10 @@ struct hal_ev_avrcp_get_player_attrs_text {
uint8_t number;
uint8_t attrs[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_GET_PLAYER_VALUES_TEXT 0x87
+struct hal_ev_avrcp_get_player_values_text {
+ uint8_t attr;
+ uint8_t number;
+ uint8_t values[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 08/12] android/hal-ipc-api: Add Set Player Values notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 9 +++++++++
android/hal-msg.h | 6 ++++++
2 files changed, 15 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 362cdf4..3f7d017 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1349,6 +1349,15 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in List Player Attributes
+ Opcode 0x88 - Set Player Values notification
+
+ Notification parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ Value # (1 octet)
+ ...
+
+ Valid attribute values: Same as in List Player Attributes
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 188e7c2..fd4b522 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -914,3 +914,9 @@ struct hal_ev_avrcp_get_player_values_text {
uint8_t number;
uint8_t values[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_SET_PLAYER_VALUES 0x88
+struct hal_ev_avrcp_set_player_values {
+ uint8_t number;
+ struct hal_avrcp_player_attr_value attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 09/12] android/hal-ipc-api: Add Get Element Attributes notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 8 ++++++++
android/hal-msg.h | 6 ++++++
2 files changed, 14 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 3f7d017..f2427e1 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1358,6 +1358,14 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in List Player Attributes
+ Opcode 0x89 - Get Element Attributes notification
+
+ Notification parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ ...
+
+ Valid attribute values: Same as in Get Element Attribute
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index fd4b522..9bc2d2a 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -920,3 +920,9 @@ struct hal_ev_avrcp_set_player_values {
uint8_t number;
struct hal_avrcp_player_attr_value attrs[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_GET_ELEMENT_ATTRS 0x89
+struct hal_ev_avrcp_get_element_attrs {
+ uint8_t number;
+ uint8_t attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 10/12] android/hal-ipc-api: Add Register Notification notification
From: Luiz Augusto von Dentz @ 2014-02-13 15:18 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392304728-5061-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 7 +++++++
android/hal-msg.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index f2427e1..535e880 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1366,6 +1366,13 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attribute values: Same as in Get Element Attribute
+ Opcode 0x8a - Register Notification notification
+
+ Notification parameters: Event (1 octet)
+ Parameter (4 octets)
+
+ Valid event values: Same as in Register Notification
+
Bluetooth GATT HAL (ID 9)
=========================
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 9bc2d2a..a7df71a 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -926,3 +926,9 @@ struct hal_ev_avrcp_get_element_attrs {
uint8_t number;
uint8_t attrs[0];
} __attribute__((packed));
+
+#define HAL_EV_AVRCP_REGISTER_NOTIFICATION 0x8a
+struct hal_ev_avrcp_register_notification {
+ uint8_t event;
+ uint32_t param;
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
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