* [PATCHv2 06/10] android/avrcp: Add vendor unique passthrough request
From: Andrei Emeltchenko @ 2014-03-11 13:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
android/avctp.c | 22 ++++++++++++++++++++++
android/avctp.h | 7 +++++++
android/avrcp-lib.c | 5 +++++
android/avrcp-lib.h | 2 ++
4 files changed, 36 insertions(+)
diff --git a/android/avctp.c b/android/avctp.c
index d970250..33729f0 100644
--- a/android/avctp.c
+++ b/android/avctp.c
@@ -48,6 +48,7 @@
#include "src/uinput.h"
#include "avctp.h"
+#include "avrcp-lib.h"
/* AV/C Panel 1.23, page 76:
* command with the pressed value is valid for two seconds
@@ -1214,6 +1215,27 @@ static gboolean repeat_timeout(gpointer user_data)
return TRUE;
}
+int avctp_passthrough_vendor_req(struct avctp *session, uint8_t op, bool press)
+{
+ uint8_t operands[7];
+
+ DBG("op %d press %d", op, press);
+
+ if (press)
+ operands[0] = AVC_VENDOR_UNIQUE;
+ else
+ operands[0] = AVC_VENDOR_UNIQUE | 0x80;
+
+ operands[1] = 5;
+ hton24(&operands[2], IEEEID_BTSIG);
+ bt_put_be16(op, &operands[5]);
+
+ return avctp_send_req(session, AVC_CTYPE_CONTROL,
+ AVC_SUBUNIT_PANEL, AVC_OP_PASSTHROUGH,
+ operands, sizeof(operands),
+ avctp_passthrough_rsp, NULL);
+}
+
static void release_pressed(struct avctp *session)
{
avctp_passthrough_release(session, session->key.op);
diff --git a/android/avctp.h b/android/avctp.h
index 2f419a2..4f65869 100644
--- a/android/avctp.h
+++ b/android/avctp.h
@@ -108,6 +108,11 @@
#define AVC_BLUE 0x7c
#define AVC_YELLOW 0x7c
+#define AVC_VENDOR_UNIQUE 0x7e
+
+#define AVC_VENDOR_NEXT_GROUP 0x00
+#define AVC_VENDOR_PREV_GROUP 0x01
+
struct avctp;
typedef bool (*avctp_passthrough_cb) (struct avctp *session,
@@ -170,3 +175,5 @@ int avctp_send_vendordep_req(struct avctp *session, uint8_t code,
int avctp_send_browsing_req(struct avctp *session,
uint8_t *operands, size_t operand_count,
avctp_browsing_rsp_cb func, void *user_data);
+int avctp_passthrough_vendor_req(struct avctp *session, uint8_t op,
+ bool press);
diff --git a/android/avrcp-lib.c b/android/avrcp-lib.c
index 5400f80..a9bd438 100644
--- a/android/avrcp-lib.c
+++ b/android/avrcp-lib.c
@@ -471,3 +471,8 @@ int avrcp_register_notification_rsp(struct avrcp *session, uint8_t transaction,
AVC_SUBUNIT_PANEL, AVRCP_REGISTER_NOTIFICATION,
params, params_len);
}
+
+int avrcp_passthrough_vendor_req(struct avrcp *session, uint8_t op, bool press)
+{
+ return avctp_passthrough_vendor_req(session->conn, op, press);
+}
diff --git a/android/avrcp-lib.h b/android/avrcp-lib.h
index 91a7d47..2acf0fb 100644
--- a/android/avrcp-lib.h
+++ b/android/avrcp-lib.h
@@ -164,3 +164,5 @@ int avrcp_get_element_attrs_rsp(struct avrcp *session, uint8_t transaction,
int avrcp_register_notification_rsp(struct avrcp *session, uint8_t transaction,
uint8_t code, uint8_t *params,
size_t params_len);
+int avrcp_passthrough_vendor_req(struct avrcp *session, uint8_t op,
+ bool press);
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 07/10] unit/avrcp: Add /TP/BGN/BV-01-I test
From: Andrei Emeltchenko @ 2014-03-11 13:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Test verifies that the Controller can send Next Group command to the
Target.
---
unit/test-avrcp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
index 5d78a9a..d33c69d 100644
--- a/unit/test-avrcp.c
+++ b/unit/test-avrcp.c
@@ -636,6 +636,9 @@ static void test_client(gconstpointer data)
AVRCP_EVENT_STATUS_CHANGED, 0,
NULL, NULL);
+ if (g_str_equal(context->data->test_name, "/TP/BGN/BV-01-I"))
+ avrcp_passthrough_vendor_req(context->session,
+ AVC_VENDOR_NEXT_GROUP, true);
execute_context(context);
}
@@ -1030,5 +1033,12 @@ int main(int argc, char *argv[])
0xff, 0x00, 0x00, 0x01,
AVRCP_STATUS_INVALID_COMMAND));
+ /* Next Group command transfer - CT */
+ define_test("/TP/BGN/BV-01-I", test_client,
+ raw_pdu(0x00, 0x11, 0x0e, 0x00, 0x48,
+ AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_NEXT_GROUP));
+
return g_test_run();
}
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 08/10] unit/avrcp: Add /TP/BGN/BV-02-I test
From: Andrei Emeltchenko @ 2014-03-11 13:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Test verifies that the Controller can send Prev Group command to the
Target.
---
unit/test-avrcp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
index d33c69d..923fd9f 100644
--- a/unit/test-avrcp.c
+++ b/unit/test-avrcp.c
@@ -639,6 +639,11 @@ static void test_client(gconstpointer data)
if (g_str_equal(context->data->test_name, "/TP/BGN/BV-01-I"))
avrcp_passthrough_vendor_req(context->session,
AVC_VENDOR_NEXT_GROUP, true);
+
+ if (g_str_equal(context->data->test_name, "/TP/BGN/BV-02-I"))
+ avrcp_passthrough_vendor_req(context->session,
+ AVC_VENDOR_PREV_GROUP, true);
+
execute_context(context);
}
@@ -1040,5 +1045,12 @@ int main(int argc, char *argv[])
AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
0x58, 0x00, AVC_VENDOR_NEXT_GROUP));
+ /* Previous Group command transfer - CT */
+ define_test("/TP/BGN/BV-02-I", test_client,
+ raw_pdu(0x00, 0x11, 0x0e, 0x00, 0x48,
+ AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_PREV_GROUP));
+
return g_test_run();
}
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 09/10] unit/avrcp: Add /TP/BGN/BV-01-I TG test
From: Andrei Emeltchenko @ 2014-03-11 13:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Test verifies that the Target responds to Next Group command.
---
unit/test-avrcp.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
index 923fd9f..5179c7b 100644
--- a/unit/test-avrcp.c
+++ b/unit/test-avrcp.c
@@ -280,11 +280,20 @@ static bool handle_select(struct avrcp *session, bool pressed, void *user_data)
return true;
}
+static bool handle_vendor_uniq(struct avrcp *session, bool pressed,
+ void *user_data)
+{
+ DBG("");
+
+ return true;
+}
+
static const struct avrcp_passthrough_handler passthrough_handlers[] = {
{ AVC_PLAY, handle_play },
{ AVC_VOLUME_UP, handle_volume_up },
{ AVC_CHANNEL_UP, handle_channel_up },
{ AVC_SELECT, handle_select },
+ { AVC_VENDOR_UNIQUE, handle_vendor_uniq },
{ },
};
@@ -1045,6 +1054,17 @@ int main(int argc, char *argv[])
AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
0x58, 0x00, AVC_VENDOR_NEXT_GROUP));
+ /* Next Group command transfer - TG */
+ define_test("/TP/BGN/BV-01-I", test_server,
+ raw_pdu(0x00, 0x11, 0x0e, 0x00, 0x48,
+ AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_NEXT_GROUP),
+ raw_pdu(0x02, 0x11, 0x0e, AVC_CTYPE_ACCEPTED,
+ 0x48, AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_NEXT_GROUP));
+
/* Previous Group command transfer - CT */
define_test("/TP/BGN/BV-02-I", test_client,
raw_pdu(0x00, 0x11, 0x0e, 0x00, 0x48,
--
1.8.3.2
^ permalink raw reply related
* [PATCHv2 10/10] unit/avrcp: Add /TP/BGN/BV-02-I TG test
From: Andrei Emeltchenko @ 2014-03-11 13:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Test verifies that the Target responds to Prev Group command.
---
unit/test-avrcp.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
index 5179c7b..08e07ac 100644
--- a/unit/test-avrcp.c
+++ b/unit/test-avrcp.c
@@ -1072,5 +1072,16 @@ int main(int argc, char *argv[])
AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
0x58, 0x00, AVC_VENDOR_PREV_GROUP));
+ /* Previous Group command transfer - TG */
+ define_test("/TP/BGN/BV-02-I", test_server,
+ raw_pdu(0x00, 0x11, 0x0e, 0x00, 0x48,
+ AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_PREV_GROUP),
+ raw_pdu(0x02, 0x11, 0x0e, AVC_CTYPE_ACCEPTED,
+ 0x48, AVC_OP_PASSTHROUGH,
+ AVC_VENDOR_UNIQUE, 0x05, 0x00, 0x19,
+ 0x58, 0x00, AVC_VENDOR_PREV_GROUP));
+
return g_test_run();
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv2 01/10] unit/avrcp: Pass context to control handlers
From: Luiz Augusto von Dentz @ 2014-03-11 14:06 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1394543154-25355-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Tue, Mar 11, 2014 at 3:05 PM, Andrei Emeltchenko
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> ---
> unit/test-avrcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
> index 9760420..fe7009a 100644
> --- a/unit/test-avrcp.c
> +++ b/unit/test-avrcp.c
> @@ -578,7 +578,7 @@ static void test_server(gconstpointer data)
>
> avrcp_set_passthrough_handlers(context->session, passthrough_handlers,
> context);
> - avrcp_set_control_handlers(context->session, control_handlers, NULL);
> + avrcp_set_control_handlers(context->session, control_handlers, context);
>
> g_idle_add(send_pdu, context);
>
> --
> 1.8.3.2
Patches 1-5 are now applied, please rework the patch 6/10 so it
doesn't include avrcp-lib.h in avctp.c.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH 1/3] android/tester: Add support for bredr hciemu devices
From: Grzegorz Kolodziejczyk @ 2014-03-11 14:25 UTC (permalink / raw)
To: linux-bluetooth
Current test cases works on bredrle hciemu adapter types. Test cases
with device scan do LE scan first (for 5 sec - kernel specific) then
change scan to bredr devices as hciemu device is. To avoid timeout
(within 3 secs) - fail of test cases, hciemu adapter should be bredr.
---
android/android-tester.c | 79 ++++++++++++++++++++++++++++--------------------
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/android/android-tester.c b/android/android-tester.c
index b762a2d..111299f 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -4422,6 +4422,19 @@ static void test_hidhost_get_report(const void *test_data)
tester_test_failed();
}
+#define test_bredr(name, data, test_setup, test, test_teardown) \
+ do { \
+ struct test_data *user; \
+ user = g_malloc0(sizeof(struct test_data)); \
+ if (!user) \
+ break; \
+ user->hciemu_type = HCIEMU_TYPE_BREDR; \
+ user->test_data = data; \
+ tester_add_full(name, data, test_pre_setup, test_setup, \
+ test, test_teardown, test_post_teardown, \
+ 1, user, g_free); \
+ } while (0)
+
#define test_bredrle(name, data, test_setup, test, test_teardown) \
do { \
struct test_data *user; \
@@ -4578,157 +4591,157 @@ int main(int argc, char *argv[])
setup_enabled_adapter,
test_discovery_stop_done, teardown);
- test_bredrle("Bluetooth BR/EDR Discovery Device Found",
+ test_bredr("Bluetooth BR/EDR Discovery Device Found",
&bluetooth_discovery_device_found_test,
setup_enabled_adapter,
test_discovery_device_found, teardown);
- test_bredrle("Bluetooth Device Get Props - Success",
+ test_bredr("Bluetooth Device Get Props - Success",
&bt_dev_getprops_success_test,
setup_enabled_adapter,
test_dev_getprops_success, teardown);
- test_bredrle("Bluetooth Device Get BDNAME - Success",
+ test_bredr("Bluetooth Device Get BDNAME - Success",
&bt_dev_getprop_bdname_success_test,
setup_enabled_adapter,
test_dev_getprop_bdname_success, teardown);
- test_bredrle("Bluetooth Device Get UUIDS - Success",
+ test_bredr("Bluetooth Device Get UUIDS - Success",
&bt_dev_getprop_uuids_success_test,
setup_enabled_adapter,
test_dev_getprop_uuids_success, teardown);
- test_bredrle("Bluetooth Device Get COD - Success",
+ test_bredr("Bluetooth Device Get COD - Success",
&bt_dev_getprop_cod_success_test,
setup_enabled_adapter,
test_dev_getprop_cod_success, teardown);
- test_bredrle("Bluetooth Device Get TOD - Success",
+ test_bredr("Bluetooth Device Get TOD - Success",
&bt_dev_getprop_tod_success_test,
setup_enabled_adapter,
test_dev_getprop_tod_success, teardown);
- test_bredrle("Bluetooth Device Get RSSI - Success",
+ test_bredr("Bluetooth Device Get RSSI - Success",
&bt_dev_getprop_rssi_success_test,
setup_enabled_adapter,
test_dev_getprop_rssi_success, teardown);
- test_bredrle("Bluetooth Device Get TIMESTAMP - Success",
+ test_bredr("Bluetooth Device Get TIMESTAMP - Success",
&bt_dev_getprop_timpestamp_success_test,
setup_enabled_adapter,
test_dev_getprop_timestamp_success, teardown);
- test_bredrle("Bluetooth Device Get BDADDR - Fail",
+ test_bredr("Bluetooth Device Get BDADDR - Fail",
&bt_dev_getprop_bdaddr_fail_test,
setup_enabled_adapter,
test_dev_getprop_bdaddr_fail, teardown);
- test_bredrle("Bluetooth Device Get SERVICE_RECORD - Fail",
+ test_bredr("Bluetooth Device Get SERVICE_RECORD - Fail",
&bt_dev_getprop_servrec_fail_test,
setup_enabled_adapter,
test_dev_getprop_servrec_fail, teardown);
- test_bredrle("Bluetooth Device Get SCAN_MODE - Fail",
+ test_bredr("Bluetooth Device Get SCAN_MODE - Fail",
&bt_dev_getprop_scanmode_fail_test,
setup_enabled_adapter,
test_dev_getprop_scanmode_fail, teardown);
- test_bredrle("Bluetooth Device Get BONDED_DEVICES - Fail",
+ test_bredr("Bluetooth Device Get BONDED_DEVICES - Fail",
&bt_dev_getprop_bondeddev_fail_test,
setup_enabled_adapter,
test_dev_getprop_bondeddev_fail, teardown);
- test_bredrle("Bluetooth Device Get DISCOVERY_TIMEOUT - Fail",
+ test_bredr("Bluetooth Device Get DISCOVERY_TIMEOUT - Fail",
&bt_dev_getprop_disctimeout_fail_test,
setup_enabled_adapter,
test_dev_getprop_disctimeout_fail, teardown);
- test_bredrle("Bluetooth Device Get VERSION_INFO - Fail",
+ test_bredr("Bluetooth Device Get VERSION_INFO - Fail",
&bt_dev_getprop_verinfo_fail_test,
setup_enabled_adapter,
test_dev_getprop_verinfo_fail, teardown);
- test_bredrle("Bluetooth Device Get FRIENDLY_NAME - Fail",
+ test_bredr("Bluetooth Device Get FRIENDLY_NAME - Fail",
&bt_dev_getprop_fname_fail_test,
setup_enabled_adapter,
test_dev_getprop_fname_fail, teardown);
- test_bredrle("Bluetooth Device Set FRIENDLY_NAME - Success",
+ test_bredr("Bluetooth Device Set FRIENDLY_NAME - Success",
&bt_dev_setprop_fname_success_test,
setup_enabled_adapter,
test_dev_setprop_fname_success, teardown);
- test_bredrle("Bluetooth Device Set BDNAME - Fail",
+ test_bredr("Bluetooth Device Set BDNAME - Fail",
&bt_dev_setprop_bdname_fail_test,
setup_enabled_adapter,
test_dev_setprop_bdname_fail, teardown);
- test_bredrle("Bluetooth Device Set UUIDS - Fail",
+ test_bredr("Bluetooth Device Set UUIDS - Fail",
&bt_dev_setprop_uuids_fail_test,
setup_enabled_adapter,
test_dev_setprop_uuids_fail, teardown);
- test_bredrle("Bluetooth Device Set COD - Fail",
+ test_bredr("Bluetooth Device Set COD - Fail",
&bt_dev_setprop_cod_fail_test,
setup_enabled_adapter,
test_dev_setprop_cod_fail, teardown);
- test_bredrle("Bluetooth Device Set TOD - Fail",
+ test_bredr("Bluetooth Device Set TOD - Fail",
&bt_dev_setprop_tod_fail_test,
setup_enabled_adapter,
test_dev_setprop_tod_fail, teardown);
- test_bredrle("Bluetooth Device Set RSSI - Fail",
+ test_bredr("Bluetooth Device Set RSSI - Fail",
&bt_dev_setprop_rssi_fail_test,
setup_enabled_adapter,
test_dev_setprop_rssi_fail, teardown);
- test_bredrle("Bluetooth Device Set TIMESTAMP - Fail",
+ test_bredr("Bluetooth Device Set TIMESTAMP - Fail",
&bt_dev_setprop_timpestamp_fail_test,
setup_enabled_adapter,
test_dev_setprop_timestamp_fail, teardown);
- test_bredrle("Bluetooth Device Set BDADDR - Fail",
+ test_bredr("Bluetooth Device Set BDADDR - Fail",
&bt_dev_setprop_bdaddr_fail_test,
setup_enabled_adapter,
test_dev_setprop_bdaddr_fail, teardown);
- test_bredrle("Bluetooth Device Set SERVICE_RECORD - Fail",
+ test_bredr("Bluetooth Device Set SERVICE_RECORD - Fail",
&bt_dev_setprop_servrec_fail_test,
setup_enabled_adapter,
test_dev_setprop_servrec_fail, teardown);
- test_bredrle("Bluetooth Device Set SCAN_MODE - Fail",
+ test_bredr("Bluetooth Device Set SCAN_MODE - Fail",
&bt_dev_setprop_scanmode_fail_test,
setup_enabled_adapter,
test_dev_setprop_scanmode_fail, teardown);
- test_bredrle("Bluetooth Device Set BONDED_DEVICES - Fail",
+ test_bredr("Bluetooth Device Set BONDED_DEVICES - Fail",
&bt_dev_setprop_bondeddev_fail_test,
setup_enabled_adapter,
test_dev_setprop_bondeddev_fail, teardown);
- test_bredrle("Bluetooth Device Set DISCOVERY_TIMEOUT - Fail",
+ test_bredr("Bluetooth Device Set DISCOVERY_TIMEOUT - Fail",
&bt_dev_setprop_disctimeout_fail_test,
setup_enabled_adapter,
test_dev_setprop_disctimeout_fail, teardown);
- test_bredrle("Bluetooth Create Bond PIN - Success",
+ test_bredr("Bluetooth Create Bond PIN - Success",
&bt_bond_create_pin_success_test,
setup_enabled_adapter,
test_bond_create_pin_success, teardown);
- test_bredrle("Bluetooth Create Bond PIN - Bad PIN",
+ test_bredr("Bluetooth Create Bond PIN - Bad PIN",
&bt_bond_create_pin_fail_test,
setup_enabled_adapter,
test_bond_create_pin_fail, teardown);
- test_bredrle("Bluetooth Create Bond SSP - Success",
+ test_bredr("Bluetooth Create Bond SSP - Success",
&bt_bond_create_ssp_success_test,
setup_enabled_adapter,
test_bond_create_ssp_success, teardown);
- test_bredrle("Bluetooth Create Bond SSP - Negative reply",
+ test_bredr("Bluetooth Create Bond SSP - Negative reply",
&bt_bond_create_ssp_fail_test,
setup_enabled_adapter,
test_bond_create_ssp_fail, teardown);
@@ -4743,12 +4756,12 @@ int main(int argc, char *argv[])
setup_enabled_adapter,
test_bond_create_bad_addr_success, teardown);
- test_bredrle("Bluetooth Cancel Bonding - Success",
+ test_bredr("Bluetooth Cancel Bonding - Success",
&bt_bond_cancel_success_test,
setup_enabled_adapter,
test_bond_cancel_success, teardown);
- test_bredrle("Bluetooth Remove Bond - Success",
+ test_bredr("Bluetooth Remove Bond - Success",
&bt_bond_remove_success_test,
setup_enabled_adapter,
test_bond_remove_success, teardown);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/3] android: Enable LE if controller supports it
From: Grzegorz Kolodziejczyk @ 2014-03-11 14:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394547904-19100-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
---
android/bluetooth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index ba4f14b..2732390 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -2015,6 +2015,9 @@ static void read_info_complete(uint8_t status, uint16_t length,
if (missing_settings & MGMT_SETTING_PAIRABLE)
set_mode(MGMT_OP_SET_PAIRABLE, 0x01);
+ if (missing_settings & MGMT_SETTING_LE)
+ set_mode(MGMT_OP_SET_LE, 0x01);
+
return;
failed:
--
1.8.5.2
^ permalink raw reply related
* [PATCH 3/3] android/tester: Fix TOD test cases to support dual mode
From: Grzegorz Kolodziejczyk @ 2014-03-11 14:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394547904-19100-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
This modifies test cases to support dual mode type of device.
---
android/android-tester.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/android/android-tester.c b/android/android-tester.c
index 111299f..ade5b40 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -1422,7 +1422,7 @@ static bt_uuid_t enable_done_uuids_val = {
.uu = { 0x00, 0x00, 0x12, 0x00, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00,
0x00, 0x80, 0x5f, 0x9b, 0x34, 0xfb},
};
-static bt_device_type_t enable_done_tod_val = BT_DEVICE_DEVTYPE_BREDR;
+static bt_device_type_t enable_done_tod_val = BT_DEVICE_DEVTYPE_DUAL;
static bt_scan_mode_t enable_done_scanmode_val = BT_SCAN_MODE_NONE;
static uint32_t enable_done_disctimeout_val = 120;
@@ -1615,7 +1615,7 @@ static const struct generic_data bluetooth_setprop_cod_invalid_test = {
.expected_adapter_status = BT_STATUS_FAIL,
};
-static bt_device_type_t setprop_type_of_device = BT_DEVICE_DEVTYPE_BREDR;
+static bt_device_type_t setprop_type_of_device = BT_DEVICE_DEVTYPE_DUAL;
static struct priority_property setprop_tod_props[] = {
{
@@ -1730,7 +1730,7 @@ static const struct generic_data bluetooth_getprop_cod_success_test = {
.expected_adapter_status = BT_STATUS_SUCCESS,
};
-static bt_device_type_t getprop_tod = BT_DEVICE_DEVTYPE_BREDR;
+static bt_device_type_t getprop_tod = BT_DEVICE_DEVTYPE_DUAL;
static struct priority_property getprop_tod_props[] = {
{
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH bluetooth-next] bluetooth: make bluetooth 6lowpan as an option
From: Marcel Holtmann @ 2014-03-11 14:56 UTC (permalink / raw)
To: Alexander Aring
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
bluez mailin list (linux-bluetooth@vger.kernel.org), netdev
In-Reply-To: <1393924982-14001-1-git-send-email-alex.aring@gmail.com>
Hi Alexander,
> Currently you can have bluetooth 6lowpan without ipv6 enabled. This
> doesn't make any sense. With this patch you can disable/enable bluetooth
> 6lowpan support at compile time.
>
> The current bluetooth 6lowpan implementation doesn't check the return
> value of 6lowpan function. Nevertheless I added -EOPNOTSUPP as return value
> if 6lowpan bluetooth is disabled.
>
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> ---
> net/bluetooth/6lowpan.h | 21 +++++++++++++++++++++
> net/bluetooth/Kconfig | 8 +++++++-
> net/bluetooth/Makefile | 3 ++-
> 3 files changed, 30 insertions(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes
From: Marcel Holtmann @ 2014-03-11 15:14 UTC (permalink / raw)
To: John W. Linville
Cc: Sander Eikelenboom, Gustavo F. Padovan, Peter Hurley,
Linus Torvalds,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <20140310150858.GA25703@tuxdriver.com>
Hi John,
>> Since:
>> - 3.14-RC6 has been cut
>> - this regression is known and reported since the merge window
>> - the fix (revert of 3 patches) is known for over a month now
>> - but it's still not in mainline
>> - my polite ping request from last week seems to have provoked exactly 0 (zero) response.
>>
>> IT'S TIME TO CHIME SOME BELLS :-)
>>
>> Hope that WILL be heard somewhere ...
>>
>> --
>> Sander
>>
>> PS. on the informative side the 3 commits to be reverted are:
>>
>> f86772af6a0f643d3e13eb3f4f9213ae0c333ee4 Bluetooth: Remove rfcomm_carrier_raised()
>> 4a2fb3ecc7467c775b154813861f25a0ddc11aa0 Bluetooth: Always wait for a connection on RFCOMM open()
>> e228b63390536f5b737056059a9a04ea016b1abf Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()
>
> Gustavo, should I be expecting a pull request?
you have all 3 reverts already in wireless-next as part of a larger RFCOMM change from Peter that we had to do to get this bug fixed. The whole series ended up as 24 patches and was way to late in the -rc stage. In addition we did not have enough exposure from people running that patch set. I did not wanted to end up in a ping-pong situation with apply + revert over and over again until we gave this some test exposure.
I think it is pretty safe to revert these 3 patches from 3.14-rc6 since they broke more than they actually fixed. However everybody has to be aware of that the real fix only comes in 3.15 since the change unfortunately is large. As far as we can tell, only users of RFCOMM TTY are affected. All RFCOMM socket users are fine.
So I do not know what the best way of getting these reverts merged. Gustavo has a tree ready for you to pull from. Or would it be better if they get cherry picked from wireless-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] bluetooth: Fix aborting eSCO connection in case of error 0x20
From: Marcel Holtmann @ 2014-03-11 15:17 UTC (permalink / raw)
To: Andrew Earl; +Cc: linux-bluetooth
In-Reply-To: <1394447464-29164-2-git-send-email-andrewx.earl@intel.com>
Hi Andrew,
> Add additional error case to attempt alternative configuration for SCO. Error
> occurs with Intel BT controller where fallback is not attempted as the error
> 0x20 Unsupported LMP Parameter value is not included in the list of errors
> where a retry should be attempted.
> The problem also affects PTS test case TC_HF_ACS_BV_05_I.
>
> See the HCI log below for details:
> < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> handle 256 voice setting 0x0060 ptype 0x0380
>> HCI Event: Command Status (0x0f) plen 4
> Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
>> HCI Event: Max Slots Change (0x1b) plen 3
> handle 256 slots 1
>> HCI Event: Synchronous Connect Complete (0x2c) plen 17
> status 0x20 handle 0 bdaddr 00:80:98:09:0B:19 type eSCO
> Error: Unsupported LMP Parameter Value
> < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> handle 256 voice setting 0x0060 ptype 0x0380
>> HCI Event: Command Status (0x0f) plen 4
> Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
>> HCI Event: Max Slots Change (0x1b) plen 3
> handle 256 slots 5
>> HCI Event: Synchronous Connect Complete (0x2c) plen 17
> status 0x20 handle 0 bdaddr 00:80:98:09:0B:19 type eSCO
> Error: Unsupported LMP Parameter Value
> < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> handle 256 voice setting 0x0060 ptype 0x03c8
>> HCI Event: Command Status (0x0f) plen 4
> Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
>> HCI Event: Max Slots Change (0x1b) plen 3
> handle 256 slots 1
>> HCI Event: Synchronous Connect Complete (0x2c) plen 17
> status 0x00 handle 257 bdaddr 00:80:98:09:0B:19 type eSCO
> Air mode: CVSD
>
> See btmon log for further details:
>> HCI Event (0x0f) plen 4 [hci0] 44.888063
> Setup Synchronous Connection (0x01|0x0028) ncmd 1
> Status: Success (0x00)
>> HCI Event (0x1b) plen 3 [hci0] 44.893064
> Handle: 256
> Max slots: 1
>> HCI Event (0x2c) plen 17 [hci0] 44.942080
> Status: Unsupported LMP Parameter Value (0x20)
> Handle: 0
> Address: 00:1B:DC:06:04:B0 (OUI 00-1B-DC)
> Link type: eSCO (0x02)
> Transmission interval: 0x00
> Retransmission window: 0x01
> RX packet length: 0
> TX packet length: 0
> Air mode: CVSD (0x02)
>> HCI Event (0x1b) plen 3 [hci0] 44.948054
> Handle: 256
> Max slots: 5
>
> Signed-off-by: Andrew Earl <andrewx.earl@intel.com>
> ---
> net/bluetooth/hci_event.c | 1 +
> 1 file changed, 1 insertion(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Enable duplicates filter in background scan
From: Marcel Holtmann @ 2014-03-11 16:28 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1394486784-5431-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> To avoid flooding the host with useless advertising reports during
> background scan, we enable the duplicates filter from controller.
>
> However, enabling duplicates filter requires a small change in
> background scan routine in order to fix the following scenario:
> 1) Background scan is running.
> 2) A device disconnects and starts advertising.
> 3) Before host gets the disconnect event, the advertising is reported
> to host. Since there is no pending LE connection at that time,
> nothing happens.
> 4) Host gets the disconnection event and adds a pending connection.
> 5) No advertising is reported (since controller is filtering) and the
> connection is never established.
>
> So, to address this scenario, we should always restart background scan
> to unsure we don't miss any advertising report (due to duplicates
> filter).
don’t we need a timer that restarts the background scan in a regular interval?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Enable duplicates filter in background scan
From: Andre Guedes @ 2014-03-11 17:10 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <A8F8858B-001A-44CB-B295-E31E4ACC4FE8@holtmann.org>
Hi Marcel,
On 03/11/2014 01:28 PM, Marcel Holtmann wrote:
> Hi Andre,
>
>> To avoid flooding the host with useless advertising reports during
>> background scan, we enable the duplicates filter from controller.
>>
>> However, enabling duplicates filter requires a small change in
>> background scan routine in order to fix the following scenario:
>> 1) Background scan is running.
>> 2) A device disconnects and starts advertising.
>> 3) Before host gets the disconnect event, the advertising is reported
>> to host. Since there is no pending LE connection at that time,
>> nothing happens.
>> 4) Host gets the disconnection event and adds a pending connection.
>> 5) No advertising is reported (since controller is filtering) and the
>> connection is never established.
>>
>> So, to address this scenario, we should always restart background scan
>> to unsure we don't miss any advertising report (due to duplicates
>> filter).
>
> don’t we need a timer that restarts the background scan in a regular interval?
We don't need that timer since the background scan is now restarted
every time hci_update_background_scan() is called.
Regards,
Andre
^ permalink raw reply
* Re: [PATCH bluetooth-next] bluetooth: make bluetooth 6lowpan as an option
From: Alexander Aring @ 2014-03-11 18:20 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
bluez mailin list (linux-bluetooth@vger.kernel.org), netdev
In-Reply-To: <5D79FB52-77AC-4391-9CAB-6F792388EFD8@holtmann.org>
Hi Marcel,
On Tue, Mar 11, 2014 at 07:56:52AM -0700, Marcel Holtmann wrote:
> Hi Alexander,
>
> > Currently you can have bluetooth 6lowpan without ipv6 enabled. This
> > doesn't make any sense. With this patch you can disable/enable bluetooth
> > 6lowpan support at compile time.
> >
> > The current bluetooth 6lowpan implementation doesn't check the return
> > value of 6lowpan function. Nevertheless I added -EOPNOTSUPP as return value
> > if 6lowpan bluetooth is disabled.
> >
> > Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> > ---
> > net/bluetooth/6lowpan.h | 21 +++++++++++++++++++++
> > net/bluetooth/Kconfig | 8 +++++++-
> > net/bluetooth/Makefile | 3 ++-
> > 3 files changed, 30 insertions(+), 2 deletions(-)
>
> patch has been applied to bluetooth-next tree.
>
thanks and I see that next time I need to write:
"Bluetooth: ..." instead "bluetooth: ..."
Sorry, about that!
- Alex
^ permalink raw reply
* Re: [PATCH] Bluetooth: Enable duplicates filter in background scan
From: Marcel Holtmann @ 2014-03-11 20:00 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1394486784-5431-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> To avoid flooding the host with useless advertising reports during
> background scan, we enable the duplicates filter from controller.
>
> However, enabling duplicates filter requires a small change in
> background scan routine in order to fix the following scenario:
> 1) Background scan is running.
> 2) A device disconnects and starts advertising.
> 3) Before host gets the disconnect event, the advertising is reported
> to host. Since there is no pending LE connection at that time,
> nothing happens.
> 4) Host gets the disconnection event and adds a pending connection.
> 5) No advertising is reported (since controller is filtering) and the
> connection is never established.
>
> So, to address this scenario, we should always restart background scan
> to unsure we don't miss any advertising report (due to duplicates
> filter).
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_core.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/7] unit/test-hfp: Add ability to pass custom result handler to test
From: Szymon Janc @ 2014-03-11 20:10 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1394493034-2417-1-git-send-email-szymon.janc@gmail.com>
On Tuesday 11 March 2014 00:10:28 Szymon Janc wrote:
> ---
> unit/test-hfp.c | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/unit/test-hfp.c b/unit/test-hfp.c
> index 5218a2b..adc600b 100644
> --- a/unit/test-hfp.c
> +++ b/unit/test-hfp.c
> @@ -51,6 +51,7 @@ struct test_pdu {
> struct test_data {
> char *test_name;
> struct test_pdu *pdu_list;
> + hfp_result_func_t result_func;
> };
>
> #define data(args...) ((const unsigned char[]) { args })
> @@ -83,7 +84,7 @@ struct test_data {
> .fragmented = true, \
> }
>
> -#define define_test(name, function, args...) \
> +#define define_test(name, function, result_function, args...) \
> do { \
> const struct test_pdu pdus[] = { \
> args, { } \
> @@ -91,6 +92,7 @@ struct test_data {
> static struct test_data data; \
> data.test_name = g_strdup(name); \
> data.pdu_list = g_malloc(sizeof(pdus)); \
> + data.result_func = result_function; \
> memcpy(data.pdu_list, pdus, sizeof(pdus)); \
> g_test_add_data_func(name, &data, function); \
> } while (0)
> @@ -252,9 +254,11 @@ static void test_register(gconstpointer data)
> ret = hfp_gw_set_close_on_unref(context->hfp, true);
> g_assert(ret);
>
> - ret = hfp_gw_register(context->hfp, prefix_handler, (char *)pdu->data,
> - context, NULL);
> - g_assert(ret);
> + if (context->data->result_func) {
> + ret = hfp_gw_register(context->hfp, context->data->result_func,
> + (char *)pdu->data, context, NULL);
> + g_assert(ret);
> + }
>
> pdu = &context->data->pdu_list[context->pdu_offset++];
>
> @@ -302,42 +306,42 @@ int main(int argc, char *argv[])
> {
> g_test_init(&argc, &argv, NULL);
>
> - define_test("/hfp/test_init", test_init, data_end());
> - define_test("/hfp/test_cmd_handler_1", test_command_handler,
> + define_test("/hfp/test_init", test_init, NULL, data_end());
> + define_test("/hfp/test_cmd_handler_1", test_command_handler, NULL,
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F'),
> data_end());
> - define_test("/hfp/test_cmd_handler_2", test_command_handler,
> + define_test("/hfp/test_cmd_handler_2", test_command_handler, NULL,
> raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '\r'),
> raw_pdu('A', 'T', 'D', '1', '2', '3', '4'),
> data_end());
> - define_test("/hfp/test_register_1", test_register,
> + define_test("/hfp/test_register_1", test_register, prefix_handler,
> raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '\r'),
> type_pdu(HFP_GW_CMD_TYPE_COMMAND, 0),
> data_end());
> - define_test("/hfp/test_register_2", test_register,
> + define_test("/hfp/test_register_2", test_register, prefix_handler,
> raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '=', '\r'),
> type_pdu(HFP_GW_CMD_TYPE_SET, 0),
> data_end());
> - define_test("/hfp/test_register_3", test_register,
> + define_test("/hfp/test_register_3", test_register, prefix_handler,
> raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '?', '\r'),
> type_pdu(HFP_GW_CMD_TYPE_READ, 0),
> data_end());
> - define_test("/hfp/test_register_4", test_register,
> + define_test("/hfp/test_register_4", test_register, prefix_handler,
> raw_pdu('+', 'B', 'R', 'S', 'F', '\0'),
> raw_pdu('A', 'T', '+', 'B', 'R', 'S', 'F', '=', '?',
> '\r'),
> type_pdu(HFP_GW_CMD_TYPE_TEST, 0),
> data_end());
> - define_test("/hfp/test_register_5", test_register,
> + define_test("/hfp/test_register_5", test_register, prefix_handler,
> raw_pdu('D', '\0'),
> raw_pdu('A', 'T', 'D', '1', '2', '3', '4', '5', '\r'),
> type_pdu(HFP_GW_CMD_TYPE_SET, 0),
> data_end());
> - define_test("/hfp/test_fragmented_1", test_fragmented,
> + define_test("/hfp/test_fragmented_1", test_fragmented, NULL,
> frg_pdu('A'), frg_pdu('T'), frg_pdu('+'), frg_pdu('B'),
> frg_pdu('R'), frg_pdu('S'), frg_pdu('F'), frg_pdu('\r'),
> data_end());
This is now upstream.
--
Szymon K. Janc
szymon.janc@gmail.com
^ permalink raw reply
* rctest -c "Can't connect: Device or resource busy (16)"
From: Scott James Remnant @ 2014-03-11 21:44 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Is this expected behavior for RFCOMM? When using rctest -r on one
side, and rctest -c (connect/disconnect/connect...) on the other, the
client side fails to connect a significant percentage of the time:
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Connected [handle 34817, class 0xff8801, priority 0]
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
rctest[23705]: Can't connect: Device or resource busy (16)
Scott
^ permalink raw reply
* Re: [PATCH 1/3] android/tester: Add support for bredr hciemu devices
From: Szymon Janc @ 2014-03-11 22:10 UTC (permalink / raw)
To: Grzegorz Kolodziejczyk; +Cc: linux-bluetooth
In-Reply-To: <1394547904-19100-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Hi Grzegorz,
On Tuesday 11 March 2014 15:25:02 Grzegorz Kolodziejczyk wrote:
> Current test cases works on bredrle hciemu adapter types. Test cases
> with device scan do LE scan first (for 5 sec - kernel specific) then
> change scan to bredr devices as hciemu device is. To avoid timeout
> (within 3 secs) - fail of test cases, hciemu adapter should be bredr.
> ---
> android/android-tester.c | 79
> ++++++++++++++++++++++++++++-------------------- 1 file changed, 46
> insertions(+), 33 deletions(-)
>
> diff --git a/android/android-tester.c b/android/android-tester.c
> index b762a2d..111299f 100644
> --- a/android/android-tester.c
> +++ b/android/android-tester.c
> @@ -4422,6 +4422,19 @@ static void test_hidhost_get_report(const void
> *test_data) tester_test_failed();
> }
>
> +#define test_bredr(name, data, test_setup, test, test_teardown) \
> + do { \
> + struct test_data *user; \
> + user = g_malloc0(sizeof(struct test_data)); \
> + if (!user) \
> + break; \
> + user->hciemu_type = HCIEMU_TYPE_BREDR; \
> + user->test_data = data; \
> + tester_add_full(name, data, test_pre_setup, test_setup, \
> + test, test_teardown, test_post_teardown, \
> + 1, user, g_free); \
> + } while (0)
> +
> #define test_bredrle(name, data, test_setup, test, test_teardown) \
> do { \
> struct test_data *user; \
> @@ -4578,157 +4591,157 @@ int main(int argc, char *argv[])
> setup_enabled_adapter,
> test_discovery_stop_done, teardown);
>
> - test_bredrle("Bluetooth BR/EDR Discovery Device Found",
> + test_bredr("Bluetooth BR/EDR Discovery Device Found",
> &bluetooth_discovery_device_found_test,
> setup_enabled_adapter,
> test_discovery_device_found, teardown);
>
> - test_bredrle("Bluetooth Device Get Props - Success",
> + test_bredr("Bluetooth Device Get Props - Success",
> &bt_dev_getprops_success_test,
> setup_enabled_adapter,
> test_dev_getprops_success, teardown);
>
> - test_bredrle("Bluetooth Device Get BDNAME - Success",
> + test_bredr("Bluetooth Device Get BDNAME - Success",
> &bt_dev_getprop_bdname_success_test,
> setup_enabled_adapter,
> test_dev_getprop_bdname_success, teardown);
>
> - test_bredrle("Bluetooth Device Get UUIDS - Success",
> + test_bredr("Bluetooth Device Get UUIDS - Success",
> &bt_dev_getprop_uuids_success_test,
> setup_enabled_adapter,
> test_dev_getprop_uuids_success, teardown);
>
> - test_bredrle("Bluetooth Device Get COD - Success",
> + test_bredr("Bluetooth Device Get COD - Success",
> &bt_dev_getprop_cod_success_test,
> setup_enabled_adapter,
> test_dev_getprop_cod_success, teardown);
>
> - test_bredrle("Bluetooth Device Get TOD - Success",
> + test_bredr("Bluetooth Device Get TOD - Success",
> &bt_dev_getprop_tod_success_test,
> setup_enabled_adapter,
> test_dev_getprop_tod_success, teardown);
>
> - test_bredrle("Bluetooth Device Get RSSI - Success",
> + test_bredr("Bluetooth Device Get RSSI - Success",
> &bt_dev_getprop_rssi_success_test,
> setup_enabled_adapter,
> test_dev_getprop_rssi_success, teardown);
>
> - test_bredrle("Bluetooth Device Get TIMESTAMP - Success",
> + test_bredr("Bluetooth Device Get TIMESTAMP - Success",
> &bt_dev_getprop_timpestamp_success_test,
> setup_enabled_adapter,
> test_dev_getprop_timestamp_success, teardown);
>
> - test_bredrle("Bluetooth Device Get BDADDR - Fail",
> + test_bredr("Bluetooth Device Get BDADDR - Fail",
> &bt_dev_getprop_bdaddr_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_bdaddr_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get SERVICE_RECORD - Fail",
> + test_bredr("Bluetooth Device Get SERVICE_RECORD - Fail",
> &bt_dev_getprop_servrec_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_servrec_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get SCAN_MODE - Fail",
> + test_bredr("Bluetooth Device Get SCAN_MODE - Fail",
> &bt_dev_getprop_scanmode_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_scanmode_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get BONDED_DEVICES - Fail",
> + test_bredr("Bluetooth Device Get BONDED_DEVICES - Fail",
> &bt_dev_getprop_bondeddev_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_bondeddev_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get DISCOVERY_TIMEOUT - Fail",
> + test_bredr("Bluetooth Device Get DISCOVERY_TIMEOUT - Fail",
> &bt_dev_getprop_disctimeout_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_disctimeout_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get VERSION_INFO - Fail",
> + test_bredr("Bluetooth Device Get VERSION_INFO - Fail",
> &bt_dev_getprop_verinfo_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_verinfo_fail, teardown);
>
> - test_bredrle("Bluetooth Device Get FRIENDLY_NAME - Fail",
> + test_bredr("Bluetooth Device Get FRIENDLY_NAME - Fail",
> &bt_dev_getprop_fname_fail_test,
> setup_enabled_adapter,
> test_dev_getprop_fname_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set FRIENDLY_NAME - Success",
> + test_bredr("Bluetooth Device Set FRIENDLY_NAME - Success",
> &bt_dev_setprop_fname_success_test,
> setup_enabled_adapter,
> test_dev_setprop_fname_success, teardown);
>
> - test_bredrle("Bluetooth Device Set BDNAME - Fail",
> + test_bredr("Bluetooth Device Set BDNAME - Fail",
> &bt_dev_setprop_bdname_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_bdname_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set UUIDS - Fail",
> + test_bredr("Bluetooth Device Set UUIDS - Fail",
> &bt_dev_setprop_uuids_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_uuids_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set COD - Fail",
> + test_bredr("Bluetooth Device Set COD - Fail",
> &bt_dev_setprop_cod_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_cod_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set TOD - Fail",
> + test_bredr("Bluetooth Device Set TOD - Fail",
> &bt_dev_setprop_tod_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_tod_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set RSSI - Fail",
> + test_bredr("Bluetooth Device Set RSSI - Fail",
> &bt_dev_setprop_rssi_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_rssi_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set TIMESTAMP - Fail",
> + test_bredr("Bluetooth Device Set TIMESTAMP - Fail",
> &bt_dev_setprop_timpestamp_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_timestamp_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set BDADDR - Fail",
> + test_bredr("Bluetooth Device Set BDADDR - Fail",
> &bt_dev_setprop_bdaddr_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_bdaddr_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set SERVICE_RECORD - Fail",
> + test_bredr("Bluetooth Device Set SERVICE_RECORD - Fail",
> &bt_dev_setprop_servrec_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_servrec_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set SCAN_MODE - Fail",
> + test_bredr("Bluetooth Device Set SCAN_MODE - Fail",
> &bt_dev_setprop_scanmode_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_scanmode_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set BONDED_DEVICES - Fail",
> + test_bredr("Bluetooth Device Set BONDED_DEVICES - Fail",
> &bt_dev_setprop_bondeddev_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_bondeddev_fail, teardown);
>
> - test_bredrle("Bluetooth Device Set DISCOVERY_TIMEOUT - Fail",
> + test_bredr("Bluetooth Device Set DISCOVERY_TIMEOUT - Fail",
> &bt_dev_setprop_disctimeout_fail_test,
> setup_enabled_adapter,
> test_dev_setprop_disctimeout_fail, teardown);
>
> - test_bredrle("Bluetooth Create Bond PIN - Success",
> + test_bredr("Bluetooth Create Bond PIN - Success",
> &bt_bond_create_pin_success_test,
> setup_enabled_adapter,
> test_bond_create_pin_success, teardown);
>
> - test_bredrle("Bluetooth Create Bond PIN - Bad PIN",
> + test_bredr("Bluetooth Create Bond PIN - Bad PIN",
> &bt_bond_create_pin_fail_test,
> setup_enabled_adapter,
> test_bond_create_pin_fail, teardown);
>
> - test_bredrle("Bluetooth Create Bond SSP - Success",
> + test_bredr("Bluetooth Create Bond SSP - Success",
> &bt_bond_create_ssp_success_test,
> setup_enabled_adapter,
> test_bond_create_ssp_success, teardown);
>
> - test_bredrle("Bluetooth Create Bond SSP - Negative reply",
> + test_bredr("Bluetooth Create Bond SSP - Negative reply",
> &bt_bond_create_ssp_fail_test,
> setup_enabled_adapter,
> test_bond_create_ssp_fail, teardown);
> @@ -4743,12 +4756,12 @@ int main(int argc, char *argv[])
> setup_enabled_adapter,
> test_bond_create_bad_addr_success, teardown);
>
> - test_bredrle("Bluetooth Cancel Bonding - Success",
> + test_bredr("Bluetooth Cancel Bonding - Success",
> &bt_bond_cancel_success_test,
> setup_enabled_adapter,
> test_bond_cancel_success, teardown);
>
> - test_bredrle("Bluetooth Remove Bond - Success",
> + test_bredr("Bluetooth Remove Bond - Success",
> &bt_bond_remove_success_test,
> setup_enabled_adapter,
> test_bond_remove_success, teardown);
All patches applied, thanks.
--
Szymon K. Janc
szymon.janc@gmail.com
^ permalink raw reply
* Re: rctest -c "Can't connect: Device or resource busy (16)"
From: Marcel Holtmann @ 2014-03-11 23:03 UTC (permalink / raw)
To: Scott James Remnant; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CAHZ1yC=+XNxEx5ivA+ebGi_Cjui2Mcrx+q83b-eUPvt2J0XLPw@mail.gmail.com>
Hi Scott,
> Is this expected behavior for RFCOMM? When using rctest -r on one
> side, and rctest -c (connect/disconnect/connect...) on the other, the
> client side fails to connect a significant percentage of the time:
>
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Connected [handle 34817, class 0xff8801, priority 0]
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
> rctest[23705]: Can't connect: Device or resource busy (16)
it is not an expected behavior. Can you create a btmon trace for this and see what error code we get on the HCI level.
Without any kind of analysis this sound like a race condition in the disconnect handling where the connection is not fully terminated and you try to re-connect too quickly.
What kernel version is this? And as usual the first question, do you still see this behavior with a bluetooth-next kernel?
Regards
Marcel
^ permalink raw reply
* Re: rctest -c "Can't connect: Device or resource busy (16)"
From: Scott James Remnant @ 2014-03-11 23:37 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <7C822ED2-E0F6-4CC7-AF1D-D909AD7C0B1F@holtmann.org>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
3.10 with bluetooth-next applied - btmon of both sides attached
On Tue, Mar 11, 2014 at 4:03 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Scott,
>
>> Is this expected behavior for RFCOMM? When using rctest -r on one
>> side, and rctest -c (connect/disconnect/connect...) on the other, the
>> client side fails to connect a significant percentage of the time:
>>
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Connected [handle 34817, class 0xff8801, priority 0]
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>> rctest[23705]: Can't connect: Device or resource busy (16)
>
> it is not an expected behavior. Can you create a btmon trace for this and see what error code we get on the HCI level.
>
> Without any kind of analysis this sound like a race condition in the disconnect handling where the connection is not fully terminated and you try to re-connect too quickly.
>
> What kernel version is this? And as usual the first question, do you still see this behavior with a bluetooth-next kernel?
>
> Regards
>
> Marcel
>
[-- Attachment #2: connect.btsnoop --]
[-- Type: application/octet-stream, Size: 13642 bytes --]
[-- Attachment #3: listen.btsnoop --]
[-- Type: application/octet-stream, Size: 14060 bytes --]
^ permalink raw reply
* Re: rctest -c "Can't connect: Device or resource busy (16)"
From: Marcel Holtmann @ 2014-03-12 2:14 UTC (permalink / raw)
To: Scott James Remnant; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CAHZ1yCnx_fbd_O5VLZ6TWpBbyT3vsx_1JB-qOR5NBYuGMwnA_g@mail.gmail.com>
Hi Scott,
> 3.10 with bluetooth-next applied - btmon of both sides attached
I am seeing the same with bluetooth-next on a 3.13 kernel. It even has a weird pattern for me.
rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Device or resource busy (16)
rctest[52844]: Can't connect: Connection refused (111)
rctest[52844]: Can't connect: Connection reset by peer (104)
rctest[52844]: Can't connect: Connection reset by peer (104)
rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
Unfortunately I currently have no idea on why this happens. When using SO_LINGER of 60 seconds with rctest -L 60 -c <bdaddr> I am getting some really odd tracing behavior.
> ACL Data RX: Handle 11 flags 0x02 dlen 14
L2CAP: Command Reject (0x01) ident 7 len 6
Reason: Invalid CID in request (0x0002)
Destination CID: 64
Source CID: 0
This should never happen and makes me wonder if something is even screwed up one down in L2CAP. Do you happen to have time to bisect this and figure out which patch introduced this behavior.
Regards
Marcel
^ permalink raw reply
* Re: rctest -c "Can't connect: Device or resource busy (16)"
From: Peter Hurley @ 2014-03-12 3:01 UTC (permalink / raw)
To: Marcel Holtmann, Scott James Remnant; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <15A2D205-97BC-4790-A998-52AD8941DB3F@holtmann.org>
On 03/11/2014 10:14 PM, Marcel Holtmann wrote:
> Hi Scott,
>
>> 3.10 with bluetooth-next applied - btmon of both sides attached
>
> I am seeing the same with bluetooth-next on a 3.13 kernel. It even has a weird pattern for me.
>
> rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Device or resource busy (16)
> rctest[52844]: Can't connect: Connection refused (111)
> rctest[52844]: Can't connect: Connection reset by peer (104)
> rctest[52844]: Can't connect: Connection reset by peer (104)
> rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
>
> Unfortunately I currently have no idea on why this happens. When using
> SO_LINGER of 60 seconds with rctest -L 60 -c <bdaddr> I am getting some
> really odd tracing behavior.
>
>> ACL Data RX: Handle 11 flags 0x02 dlen 14
> L2CAP: Command Reject (0x01) ident 7 len 6
> Reason: Invalid CID in request (0x0002)
> Destination CID: 64
> Source CID: 0
>
> This should never happen and makes me wonder if something is
> even screwed up one down in L2CAP. Do you happen to have time
> to bisect this and figure out which patch introduced this behavior.
Marcel,
I'm looking into this on the assumption I broke something in
the refactor of __rfcomm_dlc_close.
I can reproduce this and looking at the kernel trace shows
that that UA reply of the dlc DISC is not being processed, because
the rfcomm thread is not getting scheduled, but I'm not sure where
that was supposed to happen.
IOW,
rctest -r | rctest -c xx:xx:....
| ...
| rfcomm_sock_shutdown
| __rfcomm_sock_close
| rfcomm_dlc_close dlci 20
| __rfcomm_dlc_close
| rfcomm_send_disc dlci 20
rfcomm_recv_disc state 1 dlci 20 |
rfcomm_send_ua dlci 20 |
__rfcomm_dlc_close state 9 |
rfcomm_dlc_unlink |
... | UA never shows up here because
| rfcomm_process_sessions isn't run
| so rfcomm_recv_ua never happens
Regards,
Peter Hurley
^ permalink raw reply
* Re: rctest -c "Can't connect: Device or resource busy (16)"
From: Peter Hurley @ 2014-03-12 3:27 UTC (permalink / raw)
To: Marcel Holtmann, Scott James Remnant; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <531FCE03.4080704@hurleysoftware.com>
On 03/11/2014 11:01 PM, Peter Hurley wrote:
> On 03/11/2014 10:14 PM, Marcel Holtmann wrote:
>> Hi Scott,
>>
>>> 3.10 with bluetooth-next applied - btmon of both sides attached
>>
>> I am seeing the same with bluetooth-next on a 3.13 kernel. It even has a weird pattern for me.
The pattern occurs because this the dlc is not getting
unlinked on this end until the watchdog timer goes off and
closes it. [The listener is unlinking the dlc properly. ]
>> rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Device or resource busy (16)
>> rctest[52844]: Can't connect: Connection refused (111)
>> rctest[52844]: Can't connect: Connection reset by peer (104)
>> rctest[52844]: Can't connect: Connection reset by peer (104)
>> rctest[52844]: Connected [handle 11, class 0x000000, priority 0]
>>
>> Unfortunately I currently have no idea on why this happens. When using
>> SO_LINGER of 60 seconds with rctest -L 60 -c <bdaddr> I am getting some
>> really odd tracing behavior.
>>
>>> ACL Data RX: Handle 11 flags 0x02 dlen 14
>> L2CAP: Command Reject (0x01) ident 7 len 6
>> Reason: Invalid CID in request (0x0002)
>> Destination CID: 64
>> Source CID: 0
>>
>> This should never happen and makes me wonder if something is
>> even screwed up one down in L2CAP. Do you happen to have time
>> to bisect this and figure out which patch introduced this behavior.
>
> Marcel,
>
> I'm looking into this on the assumption I broke something in
> the refactor of __rfcomm_dlc_close.
Ok, it's nothing I broke. This is repeatable on 3.12 (sender and
receiver). I'll keep looking this anyway since at least I know
what's broken.
> I can reproduce this and looking at the kernel trace shows
> that that UA reply of the dlc DISC is not being processed, because
> the rfcomm thread is not getting scheduled, but I'm not sure where
> that was supposed to happen.
>
> IOW,
>
> rctest -r | rctest -c xx:xx:....
> | ...
> | rfcomm_sock_shutdown
> | __rfcomm_sock_close
> | rfcomm_dlc_close dlci 20
> | __rfcomm_dlc_close
> | rfcomm_send_disc dlci 20
> rfcomm_recv_disc state 1 dlci 20 |
> rfcomm_send_ua dlci 20 |
> __rfcomm_dlc_close state 9 |
> rfcomm_dlc_unlink |
> ... | UA never shows up here because
> | rfcomm_process_sessions isn't run
> | so rfcomm_recv_ua never happens
Regards,
Peter Hurley
^ permalink raw reply
* [RFC BlueZ 0/2] Initial D-Bus GATT client API implementation.
From: armansito @ 2014-03-12 4:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arman Uguray
From: Arman Uguray <armansito@chromium.org>
Hi everyone,
I'm working on the GATT client API and I have an initial implementation that
exposes basic GATT service and characteristic objects via D-Bus. Before I go
any further in the implementation, I wanted to get some feedback on whether or
not I've been taking the right approach so far. Also, since this is the first
time I'm contributing to BlueZ, there might be some general style/convention
issues that I would like to get corrected sooner than later :)
This set includes two patches that add support for GATT service and
characteristic objects. Characteristic descriptors, characteristic value
read/write requests, characteristic value notifications and indications,
characteristic properties (flags) and permissions, and included services are
not yet implemented. The main implementation choices that I've made that I would
especially like comments on are the following:
1. A GATT service is represented by instances of btd_gatt_dbus_service. A
btd_device directly creates and owns services. It might actually be better to
keep track of services and the devices that created them in src/gatt-dbus.c,
as the way I implemented it might make managing included services difficult.
2. btd_gatt_dbus_service objects get created in
src/device.c:register_all_services. This may not be the right place to create
them, but every time register_all_services gets called, a btd_device removes
all GATT services that it created and reconstructs them. I took this route
to keep the initial implementation simple but there might be a smarter way to
go about it.
3. GATT service hierarchies are not cached and services are created only after
we connect to a remote device.
4. A btd_device creates a btd_gatt_dbus_service object for all GATT primary
services that it has created. Each service then individually does
characteristic discovery based on it's handle range.
5. GAttrib is used for discovery. GATT services obtain the GAttrib instance
from btd_device by using its attio callbacks. I did it this way solely based
on profiles (profiles/gatt/gas.c and profiles/gatt/heartrate.c) and for all I
know this might be an absolutely terrible way of managing the ATT connection
to the remote device, so please tell me whether or not this is the right
approach.
6. The first patch introduces a change to the way device_browse_primary gets
called in device.c:att_connect_cb; the existing code doesn't do primary
service discovery unless (as far as I understand) the connect request came
over D-Bus, so an auto-connect won't discover remote GATT services, for
example. I made a change here, not because I intended to change that code
path, but because I was curious why it was done the way it is.
Arman Uguray (2):
gatt-dbus: Add remote GATT service objects.
gatt-dbus: Add remote GATT characteristic objects.
src/device.c | 47 ++++++++++-
src/gatt-dbus.c | 255 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
src/gatt-dbus.h | 25 ++++++
3 files changed, 321 insertions(+), 6 deletions(-)
--
1.8.3.2
^ 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