* [PATCH v2 4/5] android/ipc-tester: Add case for MAP client service opcode boundries
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
This patch adds test sending out of range opcode for service.
---
android/ipc-tester.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/android/ipc-tester.c b/android/ipc-tester.c
index 161777d..7dd25e8 100644
--- a/android/ipc-tester.c
+++ b/android/ipc-tester.c
@@ -940,6 +940,10 @@ int main(int argc, char *argv[])
HAL_SERVICE_ID_BLUETOOTH,
HAL_SERVICE_ID_HANDSFREE_CLIENT);
+ test_opcode_valid("MAP_CLIENT", HAL_SERVICE_ID_MAP_CLIENT, 0x01, 0,
+ HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+
/* check for valid data size */
test_datasize_valid("CORE Register+", HAL_SERVICE_ID_CORE,
HAL_OP_REGISTER_MODULE,
--
1.9.3
^ permalink raw reply related
* [PATCH v2 5/5] android/ipc-tester: Add cases for MAP client msg size
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Add cases testing message size verification for MAP client opcodes.
---
android/ipc-tester.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/android/ipc-tester.c b/android/ipc-tester.c
index 7dd25e8..357dda9 100644
--- a/android/ipc-tester.c
+++ b/android/ipc-tester.c
@@ -1486,5 +1486,19 @@ int main(int argc, char *argv[])
HAL_SERVICE_ID_BLUETOOTH,
HAL_SERVICE_ID_HANDSFREE_CLIENT);
+ /* check for valid data size for MAP CLIENT */
+ test_datasize_valid("MAP CLIENT Get instances+",
+ HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_OP_MAP_CLIENT_GET_INSTANCES,
+ sizeof(struct hal_cmd_map_client_get_instances),
+ 1, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+ test_datasize_valid("MAP CLIENT Get instances-",
+ HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_OP_MAP_CLIENT_GET_INSTANCES,
+ sizeof(struct hal_cmd_map_client_get_instances),
+ -1, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+
return tester_run();
}
--
1.9.3
^ permalink raw reply related
* [PATCH v4 0/2] core: Add plugin-support for Manufacturer Specific Data EIR
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
v4:
* Support for multiple MSD fields in the same EIR data block.
* Moved parsing to a separate function: eir_parse_msd()
v3:
* Corrections suggested by Johan on the handling of eir.h
* Parser sanity check on the size of the MSD payload.
* Minor typo correction on commit message.
Alfonso Acosta (2):
core: Add Manufacturer Specific Data EIR field
core: Add subscription API for Manufacturer Specific Data
src/adapter.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
src/adapter.h | 10 ++++++++++
src/eir.c | 22 ++++++++++++++++++++++
src/eir.h | 8 ++++++++
4 files changed, 84 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH v4 1/2] core: Add Manufacturer Specific Data EIR field
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413290765-20398-1-git-send-email-fons@spotify.com>
Add data structure and parsing support.
---
src/eir.c | 22 ++++++++++++++++++++++
src/eir.h | 8 ++++++++
2 files changed, 30 insertions(+)
diff --git a/src/eir.c b/src/eir.c
index d22ad91..2ea8731 100644
--- a/src/eir.c
+++ b/src/eir.c
@@ -53,6 +53,8 @@ void eir_data_free(struct eir_data *eir)
eir->hash = NULL;
g_free(eir->randomizer);
eir->randomizer = NULL;
+ g_slist_free_full(eir->msd_list, g_free);
+ eir->msd_list = NULL;
}
static void eir_parse_uuid16(struct eir_data *eir, const void *data,
@@ -137,6 +139,22 @@ static char *name2utf8(const uint8_t *name, uint8_t len)
return g_strdup(utf8_name);
}
+static void eir_parse_msd(struct eir_data *eir, const uint8_t *data,
+ uint8_t len)
+{
+ struct eir_msd *msd;
+
+ if (len < 2 || len > 2 + sizeof(msd->data))
+ return;
+
+ msd = g_malloc(sizeof(*msd));
+ msd->company = get_le16(data);
+ msd->data_len = len - 2;
+ memcpy(&msd->data, data + 2, msd->data_len);
+
+ eir->msd_list = g_slist_append(eir->msd_list, msd);
+}
+
void eir_parse(struct eir_data *eir, const uint8_t *eir_data, uint8_t eir_len)
{
uint16_t len = 0;
@@ -240,6 +258,10 @@ void eir_parse(struct eir_data *eir, const uint8_t *eir_data, uint8_t eir_len)
eir->did_product = data[4] | (data[5] << 8);
eir->did_version = data[6] | (data[7] << 8);
break;
+
+ case EIR_MANUFACTURER_DATA:
+ eir_parse_msd(eir, data, data_len);
+ break;
}
eir_data += field_len + 1;
diff --git a/src/eir.h b/src/eir.h
index e486fa2..1d5d3b3 100644
--- a/src/eir.h
+++ b/src/eir.h
@@ -37,6 +37,7 @@
#define EIR_SSP_RANDOMIZER 0x0F /* SSP Randomizer */
#define EIR_DEVICE_ID 0x10 /* device ID */
#define EIR_GAP_APPEARANCE 0x19 /* GAP appearance */
+#define EIR_MANUFACTURER_DATA 0xFF /* Manufacturer Specific Data */
/* Flags Descriptions */
#define EIR_LIM_DISC 0x01 /* LE Limited Discoverable Mode */
@@ -47,6 +48,12 @@
#define EIR_SIM_HOST 0x10 /* Simultaneous LE and BR/EDR to Same
Device Capable (Host) */
+struct eir_msd {
+ uint16_t company;
+ uint8_t data[HCI_MAX_EIR_LENGTH];
+ uint8_t data_len;
+};
+
struct eir_data {
GSList *services;
unsigned int flags;
@@ -62,6 +69,7 @@ struct eir_data {
uint16_t did_product;
uint16_t did_version;
uint16_t did_source;
+ GSList *msd_list;
};
void eir_data_free(struct eir_data *eir);
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/2] core: Add subscription API for Manufacturer Specific Data
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413290765-20398-1-git-send-email-fons@spotify.com>
This patch allows plugins to be notified whenever an adapter receives
Manufacturer Specific Data in the advertising reports from a device.
This can happen when new device is discovered or when we autoconnect
to it.
---
src/adapter.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
src/adapter.h | 10 ++++++++++
2 files changed, 54 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 92ee1a0..f23db62 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -206,6 +206,7 @@ struct btd_adapter {
gboolean initialized;
GSList *pin_callbacks;
+ GSList *msd_callbacks;
GSList *drivers;
GSList *profiles;
@@ -4549,6 +4550,9 @@ static void adapter_remove(struct btd_adapter *adapter)
g_slist_free(adapter->pin_callbacks);
adapter->pin_callbacks = NULL;
+
+ g_slist_free(adapter->msd_callbacks);
+ adapter->msd_callbacks = NULL;
}
const char *adapter_get_path(struct btd_adapter *adapter)
@@ -4647,6 +4651,28 @@ static void confirm_name(struct btd_adapter *adapter, const bdaddr_t *bdaddr,
confirm_name_timeout, adapter);
}
+void adapter_msd_notify(struct btd_adapter *adapter, struct btd_device *dev,
+ GSList *msd_list)
+{
+ GSList *cb_l, *cb_next;
+ GSList *msd_l, *msd_next;
+
+ for (cb_l = adapter->msd_callbacks; cb_l != NULL; cb_l = cb_next) {
+ btd_msd_cb_t cb = cb_l->data;
+
+ cb_next = g_slist_next(cb_l);
+
+ for (msd_l = msd_list; msd_l != NULL; msd_l = msd_next) {
+ const struct eir_msd *msd = msd_l->data;
+
+ msd_next = g_slist_next(msd_l);
+
+ cb(adapter, dev, msd->company, msd->data,
+ msd->data_len);
+ }
+ }
+}
+
static void update_found_devices(struct btd_adapter *adapter,
const bdaddr_t *bdaddr,
uint8_t bdaddr_type, int8_t rssi,
@@ -4738,6 +4764,9 @@ static void update_found_devices(struct btd_adapter *adapter,
device_add_eir_uuids(dev, eir_data.services);
+ if (eir_data.msd_list)
+ adapter_msd_notify(adapter, dev, eir_data.msd_list);
+
eir_data_free(&eir_data);
/*
@@ -5173,6 +5202,18 @@ void btd_adapter_unregister_pin_cb(struct btd_adapter *adapter,
adapter->pin_callbacks = g_slist_remove(adapter->pin_callbacks, cb);
}
+void btd_adapter_unregister_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb)
+{
+ adapter->msd_callbacks = g_slist_remove(adapter->msd_callbacks, cb);
+}
+
+void btd_adapter_register_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb)
+{
+ adapter->msd_callbacks = g_slist_prepend(adapter->msd_callbacks, cb);
+}
+
int btd_adapter_set_fast_connectable(struct btd_adapter *adapter,
gboolean enable)
{
@@ -6663,6 +6704,9 @@ static void connected_callback(uint16_t index, uint16_t length,
btd_device_device_set_name(device, eir_data.name);
}
+ if (eir_data.msd_list)
+ adapter_msd_notify(adapter, device, eir_data.msd_list);
+
eir_data_free(&eir_data);
}
diff --git a/src/adapter.h b/src/adapter.h
index 6801fee..8f4098a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -138,6 +138,16 @@ struct btd_adapter_pin_cb_iter *btd_adapter_pin_cb_iter_new(
void btd_adapter_pin_cb_iter_free(struct btd_adapter_pin_cb_iter *iter);
bool btd_adapter_pin_cb_iter_end(struct btd_adapter_pin_cb_iter *iter);
+typedef void (*btd_msd_cb_t) (struct btd_adapter *adapter,
+ struct btd_device *dev,
+ uint16_t company,
+ const uint8_t *data,
+ uint8_t data_len);
+void btd_adapter_register_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb);
+void btd_adapter_unregister_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb);
+
/* If TRUE, enables fast connectabe, i.e. reduces page scan interval and changes
* type. If FALSE, disables fast connectable, i.e. sets page scan interval and
* type to default values. Valid for both connectable and discoverable modes. */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] core: Add Manufacturer Specific Data EIR field
From: Alfonso Acosta @ 2014-10-14 12:48 UTC (permalink / raw)
To: Alfonso Acosta, BlueZ development
In-Reply-To: <CAHF=Y4r9ua3W0=kfbL6=3K+xxGda61gn2e8fb9P-1vzUQjTeOw@mail.gmail.com>
>>> + case EIR_MANUFACTURER_DATA:
>>> + if (data_len < 2 || data_len > 2 + sizeof(eir->msd->data))
>>> + break;
>>> + eir->msd = g_malloc(sizeof(*eir->msd));
>>> + eir->msd->company = get_le16(data);
>>> + eir->msd->data_len = data_len - 2;
>>> + memcpy(&eir->msd->data, data + 2, eir->msd->data_len);
>>> + break;
>>
>> Wouldn't this lead to a memory leaks if a device (violating the spec. but
>> still) had two or more manufacturer data entries in it's AD/EIR data?
>> Taking example from how remote name entries are handled you should
>> probably g_free(eir->msd) before allocating a new one.
>
> Very good point. So, should I support multiple MSD fields or just the
> first (last) one for now?
>
> In all honesty, just like Johan, I didn't even know it was legal to
> provide multiple ones.
The v4 bundle I just sent supports multiple MSD fields in the same EIR
data block.
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
^ permalink raw reply
* GATT Notification not sending
From: Nathan Jozwiak @ 2014-10-14 15:54 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
I'm trying to send a notification to a client when a characteristic
value is updated by the server.
Here is the characteristics creation in the GATT server:
/* Notification characteristic */
bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = GATT_CHR_PROP_READ | GATT_CHR_PROP_NOTIFY;
put_le16(h + 1, &atval[1]);
put_le16(UUID_NOTIFY, &atval[3]);
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
ATT_NOT_PERMITTED, atval, 5);
/* Notification value */
bt_uuid16_create(&uuid, UUID_NOTIFY);
ekey_valid_handle = h;
atval[0] = 0x00;
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
ATT_NOT_PERMITTED, atval, 1);
/* Notification Client Characteristic Config (CCC) */
bt_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
atval[0] = 0x00;
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE, ATT_NONE,
atval, 1);
I am connecting to the GATT server using the gatttool on another Linux
system.
[CON][00:02:72:C9:5E:0F][LE]> char-desc 0x18
handle: 0x0018, uuid: 2803
handle: 0x0019, uuid: f005
handle: 0x001a, uuid: 2902
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x1a
Characteristic value/descriptor: 00 01
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
Characteristic value/descriptor: 00
Should the CCC init to 0x01? That doesn't make sense to me. Wouldn't
that indicate the client was already setup for notifications?
I have an application that communicates with bluetoothd over TCP
sockets. So when I send bluetoothd a command it will forward it, my
application will process it, and respond to bluetoothd which will then
update the Notification characteristic value depending on the
success/failure of processing. I then need to notify the client of the
change so it can reread the value to see if the command was successful.
[CON][00:02:72:C9:5E:0F][LE]> char-write-cmd 0x000b 0x1234567890
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
Characteristic value/descriptor: ff
The update of the characteristic value worked fine. But I am using btmon
to monitor traffic between the two devices and I see no messages going
out from the server to the client.
Thanks,
Nate
^ permalink raw reply
* Re: GATT Notification not sending
From: Nathan Jozwiak @ 2014-10-14 16:58 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <543D474D.1040700@mlsw.biz>
Update: I downloaded the LightBlue app from the Apple Store. The app
allows you to connect to a GATT server and select available services to
interact with. My notification characteristic showed up properly with an
initial value of 0x00 and a CCC value of 0. But when attempted to
register with the notification I saw this error from my bluetoothd output:
bluetoothd[8754]: Refusing storage path for private addressed device
/org/bluez/hci0/dev_59_F2_63_47_1D_90
bluetoothd[8754]: Unable to get ccc storage path for device
bluetoothd[8754]: attrib/gattrib.c:g_attrib_ref() 0xa073bd8: ref=3
bluetoothd[8754]: attrib/gattrib.c:g_attrib_unref() 0xa073bd8: ref=2
Unfortunately, I do not know the command LightBlue was sending to set
the CCC, but I figured this might be a clue for someone.
Am I not properly setting up the notification characteristic? I followed
the same logic as the power level characteristic setup in
profiles/proximity/reporter.c register_tx_power().
Thanks
Nate
On 10/14/14 11:54 AM, Nathan Jozwiak wrote:
> Hi all,
>
> I'm trying to send a notification to a client when a characteristic
> value is updated by the server.
>
> Here is the characteristics creation in the GATT server:
>
> /* Notification characteristic */
> bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
> atval[0] = GATT_CHR_PROP_READ | GATT_CHR_PROP_NOTIFY;
> put_le16(h + 1, &atval[1]);
> put_le16(UUID_NOTIFY, &atval[3]);
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
> ATT_NOT_PERMITTED, atval, 5);
>
> /* Notification value */
> bt_uuid16_create(&uuid, UUID_NOTIFY);
> ekey_valid_handle = h;
> atval[0] = 0x00;
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
> ATT_NOT_PERMITTED, atval, 1);
>
> /* Notification Client Characteristic Config (CCC) */
> bt_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
> atval[0] = 0x00;
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE, ATT_NONE,
> atval, 1);
>
> I am connecting to the GATT server using the gatttool on another Linux
> system.
>
> [CON][00:02:72:C9:5E:0F][LE]> char-desc 0x18
> handle: 0x0018, uuid: 2803
> handle: 0x0019, uuid: f005
> handle: 0x001a, uuid: 2902
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x1a
> Characteristic value/descriptor: 00 01
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
> Characteristic value/descriptor: 00
>
> Should the CCC init to 0x01? That doesn't make sense to me. Wouldn't
> that indicate the client was already setup for notifications?
>
> I have an application that communicates with bluetoothd over TCP
> sockets. So when I send bluetoothd a command it will forward it, my
> application will process it, and respond to bluetoothd which will then
> update the Notification characteristic value depending on the
> success/failure of processing. I then need to notify the client of the
> change so it can reread the value to see if the command was successful.
>
> [CON][00:02:72:C9:5E:0F][LE]> char-write-cmd 0x000b 0x1234567890
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
> Characteristic value/descriptor: ff
>
> The update of the characteristic value worked fine. But I am using btmon
> to monitor traffic between the two devices and I see no messages going
> out from the server to the client.
>
>
> Thanks,
> Nate
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nathan Jozwiak
MapleLeaf Software, Inc.
858-598-4814
^ permalink raw reply
* Re: Not getting an AVDTP: incoming connect
From: John Tobias @ 2014-10-14 22:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZLK3w+feOuikzWrG4VhsAR7Ky+S7WZpnBOsHJGR_kE+gA@mail.gmail.com>
Hi Luiz,
I was able to reproduce again and here are the logs.
HCI LOGS:
HCI Event: Connect Request (0x04) plen 10
bdaddr 00:1B:DC:07:32:D3 class 0x080418 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:1B:DC:07:32:D3 role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:1B:DC:07:32:D3 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 1
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:1B:DC:07:32:D3 mode 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 1
Features: 0xff 0xff 0x8f 0x7e 0xd8 0x1f 0x5b 0x87
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 1 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Max Slots Change (0x1b) plen 3
handle 1 slots 5
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 1 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:1B:DC:07:32:D3 mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:1B:DC:07:32:D3 name 'PTS-A2DP-WIN-4MP7G5VHB2U'
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr D0:E7:82:ED:B0:1A
Additionally, I've encounter a scenario where I was able to respond to
the prompt (Confirm passkey 773535 (yes/no):), after entering yes and
enter, the hcidump did not logs any event.
Regards,
john
On Tue, Oct 14, 2014 at 2:51 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi John,
>
> On Tue, Oct 14, 2014 at 3:09 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hi Marcell / Bluez Team:
>>
>> I was running the PTS 5.2 and there were an occurrences that the bluez
>> did not show a similar message below:
>>
>> [agent] Authorize service 0000110d-0000-1000-8000-00805f9b34fb (yes/no):
>>
>>
>> 1. I logs below are the traces of the bluetoothd not prompting the
>> Authorize service message:
>>
>> t 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
>> connected eir_len 31
>> Oct 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:dev_disconnected() Device 00:1B:DC:07:32:D3
>> disconnected, reason 2
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:adapter_remove_connection()
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> plugins/policy.c:disconnect_cb() reason 2
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:1B:DC:07:32:D3
>> type 0 status 0xe
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/device.c:device_bonding_complete() bonding (nil) status 0x0e
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/device.c:device_bonding_failed() status 14
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:resume_discovery()
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_disconnected
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: setting adv
>> params failed: Operation not permitted
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: failed to enable
>> advertising
>>
>>
>> 2. These messages are the traces of the bluetoothd showing the
>> Authorize service message:
>>
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
>> connected eir_len 31
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
>> 00:1B:DC:07:32:D3
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/source.c:source_set_state() State changed
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_DISCONNECTED ->
>> SOURCE_STATE_CONNECTING
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_ref() 0x77a601d0: ref=2
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_authorize_service() authorize service request was
>> sent for /org/bluez/hci0/dev_00_1B_DC_07_32_D3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_ref() 0x77a601d0: ref=3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_unref() 0x77a601d0: ref=2
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_unref() 0x77a601d0: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected signaling
>> channel to 00:1B:DC:07:32:D3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP imtu=672, omtu=672
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received DISCOVER_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
>> GET_CAPABILITIES_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:endpoint_getcap_ind() Sink 0x77a69bd8:
>> Get_Capability_Ind
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
>> SET_CONFIGURATION_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:endpoint_setconf_ind() Sink 0x77a69bd8:
>> Set_Configuration_Ind
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_ref() 0x77a5d040: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/media.c:media_endpoint_async_call() Calling
>> SetConfiguration: name = :1.6 path = /MediaEndpoint/A2DPSink
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=2
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
>> IDLE -> CONFIGURED
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_unref() 0x77a5d040: ref=0
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_free() 0x77a5d040
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_unref() 0x77a6afa8: ref=1
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:open_ind() Sink 0x77a69bd8: Open_Ind
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
>> 00:1B:DC:07:32:D3
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected transport
>> channel to 00:1B:DC:07:32:D3
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
>> CONFIGURED -> OPEN
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/service.c:change_state() 0x77a70eb8: device 00:1B:DC:07:32:D3
>> profile a2dp-source state changed: disconnected -> connected (0)
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> plugins/policy.c:service_cb() Added a2dp-source reconnect 1
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/source.c:source_set_state() State changed
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_CONNECTING ->
>> SOURCE_STATE_CONNECTED
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/transport.c:transport_update_playing()
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3/fd19 State=TRANSPORT_STATE_IDLE
>>
>>
>> It seems the avdtp_server_socket did not received the signals and
>> that's the reason why the avdtp_confirm_cb function did not execute. I
>> would like to know what are the possible scenario why the bluetoothd
>> did not receive the event?.
>> Because, if I re-run the PTS with the same test case, the bluez could
>> received the event.
>
> It would probably help if you have the HCI logs as well, perhaps there
> is something wrong with authentication or we are rejecting the L2CAP
> connection for some reason. Also note that the server socket is only
> initialized if once a endpoint is registered so perhaps in case 1 you
> did not have any endpoint available.
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* BT-4.1 features (e.g. concurrent GAP operations) support
From: Min Jun,Xi @ 2014-10-15 7:25 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Where can I find the latest BT-4.1 features support for
Bluetooth-subsystem and BlueZ?
In the 4.1 features, I know connection-oriented channels has been supported;
I have one question about this new feature (Bluetooth Specification
Version 4.1[Vol 3] page 293 of 668, ): "2.2.2.5 Concurrent Operation
in Multiple GAP Roles"; this feature is very useful to support
mesh-like topology,
>From the description in chapter 2.2.2.5, the controller should support
operations in multiple GAP roles concurrently, and the host should
read the supported Link Layer States and State combinations from the
Controller before any procedures or modes are used.
Can anyone tell me if the bluetooth subsystem has supported the Link
Layer states and the States combinations? I am also looking for the
Controller support operations in multiple GAP roles concurrently, can
anyone know if CSR/Nordic/Broadcom has got the USB dongles which
supports concurrent operation and can used under Linux?
Thank you!
--
Best regards,
Xi Minjun
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Oliver Neukum @ 2014-10-15 10:11 UTC (permalink / raw)
To: Alan Stern
Cc: Naveen Kumar Parna, linux-bluetooth@vger.kernel.org, linux-usb,
acho
In-Reply-To: <Pine.LNX.4.44L0.1410091030580.1372-100000@iolanthe.rowland.org>
On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>
> > Hi Oliver & Alan,
> >
> >
> >
> > Thanks for your inputs.
> >
> >
> >
> > I enabled the dynamic debugging for USB HC driver. Please correct me
> > if I am wrong.
>
> Debugging the kernel (or doing anything else to the kernel, for that
> matter) won't solve the problem if it is caused by a buggy hub.
Indeed. Could you just try a different hub?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] Adds Sony Move Navigation controller.
From: Alex Gal @ 2014-10-15 11:24 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <2485489.uEt5Y7pmtU@uw000953>
Hi Szymon,
On Fri, Oct 10, 2014 at 6:07 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> Thanks for patch, some small comments from my side.
No problem, I will resend the patches later this week.
By the way, you were right about the Move Navigation clones since they
try to connect with a different mac address. I will try to see what
can be done about them.
Thank you,
Alex
^ permalink raw reply
* [PATCH] Bluetooth: Incorrect locking when sending data in softirq
From: Jukka Rissanen @ 2014-10-15 12:43 UTC (permalink / raw)
To: linux-bluetooth
Use spin_lock_irqsave() when sending data to hci channel. Otherwise
the lockdep gives inconsistent lock state warning when sending data
to 6lowpan channel.
[ INFO: inconsistent lock state ]
3.17.0-rc1-bt6lowpan #1 Not tainted
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/u3:0/321 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&list->lock)->rlock#6){+.?...}, at: [<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
{IN-SOFTIRQ-W} state was registered at:
[<c10915a3>] __lock_acquire+0x6d3/0x1d20
[<c109325d>] lock_acquire+0x9d/0x140
[<c1889c25>] _raw_spin_lock+0x45/0x80
[<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
[<f8480c60>] l2cap_do_send+0x60/0x100 [bluetooth]
[<f8484830>] l2cap_chan_send+0x7f0/0x10e0 [bluetooth]
[<f873191e>] send_pkt+0x4e/0xa0 [bluetooth_6lowpan]
[<f8731d20>] bt_xmit+0x3b0/0x770 [bluetooth_6lowpan]
[<c17742f4>] dev_hard_start_xmit+0x344/0x670
[<c17749ad>] __dev_queue_xmit+0x38d/0x680
[<c1774caf>] dev_queue_xmit+0xf/0x20
[<c177b8b0>] neigh_connected_output+0x130/0x1a0
[<c1812a63>] ip6_finish_output2+0x173/0x8c0
[<c18182db>] ip6_finish_output+0x7b/0x1b0
[<c18184a7>] ip6_output+0x97/0x2a0
[<c183a46b>] mld_sendpack+0x5eb/0x650
[<c183acc1>] mld_ifc_timer_expire+0x191/0x2f0
[<c10ac385>] call_timer_fn+0x85/0x1c0
[<c10acb72>] run_timer_softirq+0x192/0x280
[<c104fd84>] __do_softirq+0xd4/0x300
[<c10049fc>] do_softirq_own_stack+0x2c/0x40
[<c1050136>] irq_exit+0x86/0xb0
[<c188bd98>] smp_apic_timer_interrupt+0x38/0x50
[<c188b6ce>] apic_timer_interrupt+0x32/0x38
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
---
Hi,
this patch fixes the locking issue when sending larger amount of
data via 6lowpan link. After this patch the lockdep no longer warns
about softirq issues.
Cheers,
Jukka
net/bluetooth/hci_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8aea4be..3e295ff 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4642,6 +4642,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
struct hci_conn *conn = chan->conn;
struct hci_dev *hdev = conn->hdev;
struct sk_buff *list;
+ unsigned long irq_flags;
skb->len = skb_headlen(skb);
skb->data_len = 0;
@@ -4673,7 +4674,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
skb_shinfo(skb)->frag_list = NULL;
/* Queue all fragments atomically */
- spin_lock(&queue->lock);
+ spin_lock_irqsave(&queue->lock, irq_flags);
__skb_queue_tail(queue, skb);
@@ -4690,7 +4691,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
__skb_queue_tail(queue, skb);
} while (list);
- spin_unlock(&queue->lock);
+ spin_unlock_irqrestore(&queue->lock, irq_flags);
}
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] android/pts: Update MAP PTS tests
From: Sebastian Chlad @ 2014-10-15 13:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sebastian Chlad
Checked and tested against PTS 5.3
---
android/pics-map.txt | 2 +-
android/pixit-map.txt | 2 +-
android/pts-map.txt | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/android/pics-map.txt b/android/pics-map.txt
index 461c6ce..3f783a9 100644
--- a/android/pics-map.txt
+++ b/android/pics-map.txt
@@ -1,6 +1,6 @@
MAP PICS for the PTS tool.
-PTS version: 5.2
+PTS version: 5.3
* - different than PTS defaults
# - not yet implemented/supported
diff --git a/android/pixit-map.txt b/android/pixit-map.txt
index 45a374a..c8c130c 100644
--- a/android/pixit-map.txt
+++ b/android/pixit-map.txt
@@ -1,6 +1,6 @@
MAP PIXIT for the PTS tool.
-PTS version: 5.2
+PTS version: 5.3
* - different than PTS defaults
& - should be set to IUT Bluetooth address
diff --git a/android/pts-map.txt b/android/pts-map.txt
index 5f5a4f3..57cb317 100644
--- a/android/pts-map.txt
+++ b/android/pts-map.txt
@@ -1,7 +1,7 @@
PTS test results for MAP
-PTS version: 5.2
-Tested: 16-July-2014
+PTS version: 5.3
+Tested: 15-October-2014
Android version: 4.4.4
Results:
--
1.8.5.3
^ permalink raw reply related
* Re: btusb_intr_complete returns -EPIPE
From: Naveen Kumar Parna @ 2014-10-15 13:09 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-bluetooth@vger.kernel.org, linux-usb, acho
In-Reply-To: <1413367888.7328.1.camel@linux-0dmf.site>
EHCI controller on PCI card and hub("rate-matching" hub) also internal.
Is it possible to change the internal hub?
Thanks,
Naveen
On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>
>> > Hi Oliver & Alan,
>> >
>> >
>> >
>> > Thanks for your inputs.
>> >
>> >
>> >
>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>> > if I am wrong.
>>
>> Debugging the kernel (or doing anything else to the kernel, for that
>> matter) won't solve the problem if it is caused by a buggy hub.
>
> Indeed. Could you just try a different hub?
>
> Regards
> Oliver
>
>
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Incorrect locking when sending data in softirq
From: Peter Hurley @ 2014-10-15 13:18 UTC (permalink / raw)
To: Jukka Rissanen, linux-bluetooth
In-Reply-To: <1413376985-25812-1-git-send-email-jukka.rissanen@linux.intel.com>
Hi Jukka,
On 10/15/2014 08:43 AM, Jukka Rissanen wrote:
> Use spin_lock_irqsave() when sending data to hci channel. Otherwise
> the lockdep gives inconsistent lock state warning when sending data
> to 6lowpan channel.
>
> [ INFO: inconsistent lock state ]
> 3.17.0-rc1-bt6lowpan #1 Not tainted
> ---------------------------------
> inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> kworker/u3:0/321 [HC0[0]:SC0[0]:HE1:SE1] takes:
> (&(&list->lock)->rlock#6){+.?...}, at: [<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
> {IN-SOFTIRQ-W} state was registered at:
> [<c10915a3>] __lock_acquire+0x6d3/0x1d20
> [<c109325d>] lock_acquire+0x9d/0x140
> [<c1889c25>] _raw_spin_lock+0x45/0x80
> [<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
> [<f8480c60>] l2cap_do_send+0x60/0x100 [bluetooth]
> [<f8484830>] l2cap_chan_send+0x7f0/0x10e0 [bluetooth]
> [<f873191e>] send_pkt+0x4e/0xa0 [bluetooth_6lowpan]
> [<f8731d20>] bt_xmit+0x3b0/0x770 [bluetooth_6lowpan]
> [<c17742f4>] dev_hard_start_xmit+0x344/0x670
> [<c17749ad>] __dev_queue_xmit+0x38d/0x680
> [<c1774caf>] dev_queue_xmit+0xf/0x20
> [<c177b8b0>] neigh_connected_output+0x130/0x1a0
> [<c1812a63>] ip6_finish_output2+0x173/0x8c0
> [<c18182db>] ip6_finish_output+0x7b/0x1b0
> [<c18184a7>] ip6_output+0x97/0x2a0
> [<c183a46b>] mld_sendpack+0x5eb/0x650
> [<c183acc1>] mld_ifc_timer_expire+0x191/0x2f0
> [<c10ac385>] call_timer_fn+0x85/0x1c0
> [<c10acb72>] run_timer_softirq+0x192/0x280
> [<c104fd84>] __do_softirq+0xd4/0x300
> [<c10049fc>] do_softirq_own_stack+0x2c/0x40
> [<c1050136>] irq_exit+0x86/0xb0
> [<c188bd98>] smp_apic_timer_interrupt+0x38/0x50
> [<c188b6ce>] apic_timer_interrupt+0x32/0x38
>
> Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
> ---
> Hi,
>
> this patch fixes the locking issue when sending larger amount of
> data via 6lowpan link. After this patch the lockdep no longer warns
> about softirq issues.
>
> Cheers,
> Jukka
>
>
> net/bluetooth/hci_core.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 8aea4be..3e295ff 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -4642,6 +4642,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> struct hci_conn *conn = chan->conn;
> struct hci_dev *hdev = conn->hdev;
> struct sk_buff *list;
> + unsigned long irq_flags;
>
> skb->len = skb_headlen(skb);
> skb->data_len = 0;
> @@ -4673,7 +4674,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> skb_shinfo(skb)->frag_list = NULL;
>
> /* Queue all fragments atomically */
> - spin_lock(&queue->lock);
> + spin_lock_irqsave(&queue->lock, irq_flags);
spin_lock_bh(&queue->lock) will suffice.
Also, please consider submitting a patch to netdev to document the lock
requirement with the struct sk_buff_head definition.
Regards,
Peter Hurley
>
> __skb_queue_tail(queue, skb);
>
> @@ -4690,7 +4691,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> __skb_queue_tail(queue, skb);
> } while (list);
>
> - spin_unlock(&queue->lock);
> + spin_unlock_irqrestore(&queue->lock, irq_flags);
> }
> }
>
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Incorrect locking when sending data in softirq
From: Jukka Rissanen @ 2014-10-15 13:32 UTC (permalink / raw)
To: Peter Hurley; +Cc: linux-bluetooth
In-Reply-To: <543E7414.8090209@hurleysoftware.com>
Hi Peter,
On ke, 2014-10-15 at 09:18 -0400, Peter Hurley wrote:
> Hi Jukka,
>
> On 10/15/2014 08:43 AM, Jukka Rissanen wrote:
> > Use spin_lock_irqsave() when sending data to hci channel. Otherwise
> > the lockdep gives inconsistent lock state warning when sending data
> > to 6lowpan channel.
> >
> > [ INFO: inconsistent lock state ]
> > 3.17.0-rc1-bt6lowpan #1 Not tainted
> > ---------------------------------
> > inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> > kworker/u3:0/321 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > (&(&list->lock)->rlock#6){+.?...}, at: [<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
> > {IN-SOFTIRQ-W} state was registered at:
> > [<c10915a3>] __lock_acquire+0x6d3/0x1d20
> > [<c109325d>] lock_acquire+0x9d/0x140
> > [<c1889c25>] _raw_spin_lock+0x45/0x80
> > [<f845fdac>] hci_send_acl+0xac/0x290 [bluetooth]
> > [<f8480c60>] l2cap_do_send+0x60/0x100 [bluetooth]
> > [<f8484830>] l2cap_chan_send+0x7f0/0x10e0 [bluetooth]
> > [<f873191e>] send_pkt+0x4e/0xa0 [bluetooth_6lowpan]
> > [<f8731d20>] bt_xmit+0x3b0/0x770 [bluetooth_6lowpan]
> > [<c17742f4>] dev_hard_start_xmit+0x344/0x670
> > [<c17749ad>] __dev_queue_xmit+0x38d/0x680
> > [<c1774caf>] dev_queue_xmit+0xf/0x20
> > [<c177b8b0>] neigh_connected_output+0x130/0x1a0
> > [<c1812a63>] ip6_finish_output2+0x173/0x8c0
> > [<c18182db>] ip6_finish_output+0x7b/0x1b0
> > [<c18184a7>] ip6_output+0x97/0x2a0
> > [<c183a46b>] mld_sendpack+0x5eb/0x650
> > [<c183acc1>] mld_ifc_timer_expire+0x191/0x2f0
> > [<c10ac385>] call_timer_fn+0x85/0x1c0
> > [<c10acb72>] run_timer_softirq+0x192/0x280
> > [<c104fd84>] __do_softirq+0xd4/0x300
> > [<c10049fc>] do_softirq_own_stack+0x2c/0x40
> > [<c1050136>] irq_exit+0x86/0xb0
> > [<c188bd98>] smp_apic_timer_interrupt+0x38/0x50
> > [<c188b6ce>] apic_timer_interrupt+0x32/0x38
> >
> > Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
> > ---
> > Hi,
> >
> > this patch fixes the locking issue when sending larger amount of
> > data via 6lowpan link. After this patch the lockdep no longer warns
> > about softirq issues.
> >
> > Cheers,
> > Jukka
> >
> >
> > net/bluetooth/hci_core.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 8aea4be..3e295ff 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -4642,6 +4642,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> > struct hci_conn *conn = chan->conn;
> > struct hci_dev *hdev = conn->hdev;
> > struct sk_buff *list;
> > + unsigned long irq_flags;
> >
> > skb->len = skb_headlen(skb);
> > skb->data_len = 0;
> > @@ -4673,7 +4674,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> > skb_shinfo(skb)->frag_list = NULL;
> >
> > /* Queue all fragments atomically */
> > - spin_lock(&queue->lock);
> > + spin_lock_irqsave(&queue->lock, irq_flags);
>
> spin_lock_bh(&queue->lock) will suffice.
I thought so too but when using spin_lock_bh() I saw this warning
WARNING: CPU: 0 PID: 269 at .../linux/kernel/softirq.c:146
__local_bh_enable_ip+0x98/0xf0()
Modules linked in: bluetooth_6lowpan 6lowpan rfcomm ecb btusb bnep
bluetooth nfc rfkill ohci_pci snd_intel8x0 snd_ac97_codec ac97_bus
parport_pc parport
CPU: 0 PID: 269 Comm: systemd-journal Not tainted 3.17.0-rc1-bt6lowpan
#1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox
12/01/2006
00000000 00000000 f600bb4c c18821c1 00000000 f600bb80 c104c472 c1ac7860
00000000 0000010d c1ac7c68 00000092 c104fc58 00000092 c104fc58 00000201
f82d6e39 00000000 f600bb90 c104c532 00000009 00000000 f600bba0 c104fc58
Call Trace:
[<c18821c1>] dump_stack+0x4b/0x75
[<c104c472>] warn_slowpath_common+0x82/0xa0
[<c104fc58>] ? __local_bh_enable_ip+0x98/0xf0
[<c104fc58>] ? __local_bh_enable_ip+0x98/0xf0
[<f82d6e39>] ? hci_send_acl+0x199/0x290 [bluetooth]
[<c104c532>] warn_slowpath_null+0x22/0x30
[<c104fc58>] __local_bh_enable_ip+0x98/0xf0
[<c1889fff>] _raw_spin_unlock_bh+0x2f/0x40
[<f82d6e39>] hci_send_acl+0x199/0x290 [bluetooth]
[<c108c956>] ? trace_hardirqs_off_caller+0x66/0x160
[<f82f7bf0>] l2cap_do_send+0x60/0x100 [bluetooth]
[<c108ca5b>] ? trace_hardirqs_off+0xb/0x10
[<c188a051>] ? _raw_spin_unlock_irqrestore+0x41/0x70
[<c1763125>] ? skb_dequeue+0x45/0x60
[<f82fb7c0>] l2cap_chan_send+0x7f0/0x10e0 [bluetooth]
[<c108ca5b>] ? trace_hardirqs_off+0xb/0x10
[<c188a6d1>] ? _raw_write_unlock_irqrestore+0x41/0x70
[<c187f10c>] ? kmemleak_alloc+0x3c/0xb0
[<f84f591e>] send_pkt+0x4e/0xa0 [bluetooth_6lowpan]
[<f84f5d20>] bt_xmit+0x3b0/0x770 [bluetooth_6lowpan]
[<c176f2a0>] ? netif_napi_del+0x50/0x50
[<c17742f4>] dev_hard_start_xmit+0x344/0x670
[<c1889c4b>] ? _raw_spin_lock+0x6b/0x80
[<c17749ad>] __dev_queue_xmit+0x38d/0x680
[<c177465b>] ? __dev_queue_xmit+0x3b/0x680
[<c108f1d4>] ? trace_hardirqs_on_caller+0xf4/0x240
[<f84f5820>] ? lookup_peer+0xb0/0xb0 [bluetooth_6lowpan]
[<c1774caf>] dev_queue_xmit+0xf/0x20
[<c177b8b0>] neigh_connected_output+0x130/0x1a0
[<c1812a63>] ? ip6_finish_output2+0x173/0x8c0
[<c1812a63>] ip6_finish_output2+0x173/0x8c0
[<c181293c>] ? ip6_finish_output2+0x4c/0x8c0
[<c18182db>] ip6_finish_output+0x7b/0x1b0
[<c18184a7>] ip6_output+0x97/0x2a0
[<c1825cb0>] ? ip6_blackhole_route+0x250/0x250
[<c183a46b>] mld_sendpack+0x5eb/0x650
[<c183acc1>] ? mld_ifc_timer_expire+0x191/0x2f0
[<c183acc1>] mld_ifc_timer_expire+0x191/0x2f0
[<c10ac385>] call_timer_fn+0x85/0x1c0
[<c10ac300>] ? process_timeout+0x10/0x10
[<c108f1d4>] ? trace_hardirqs_on_caller+0xf4/0x240
[<c183ab30>] ? mld_send_initial_cr.part.31+0xa0/0xa0
[<c10acb72>] run_timer_softirq+0x192/0x280
[<c104fcb0>] ? __local_bh_enable_ip+0xf0/0xf0
[<c13d09ff>] ? __this_cpu_preempt_check+0xf/0x20
[<c183ab30>] ? mld_send_initial_cr.part.31+0xa0/0xa0
[<c104fd84>] __do_softirq+0xd4/0x300
[<c104fcb0>] ? __local_bh_enable_ip+0xf0/0xf0
[<c10049fc>] do_softirq_own_stack+0x2c/0x40
<IRQ> [<c1050136>] irq_exit+0x86/0xb0
[<c188bd98>] smp_apic_timer_interrupt+0x38/0x50
[<c188b6ce>] apic_timer_interrupt+0x32/0x38
[<c106e240>] ? __sched_fork.isra.74+0x140/0x140
[<c10c8dbb>] ? is_module_text_address+0x2b/0x50
[<c1065772>] __kernel_text_address+0x32/0x80
[<c1005c2f>] print_context_stack+0x3f/0xe0
[<c1004b65>] dump_trace+0xc5/0x1f0
[<c100fcf0>] save_stack_trace+0x30/0x50
[<c116aa8a>] create_object+0x10a/0x280
[<c187f10c>] kmemleak_alloc+0x3c/0xb0
[<c10718bb>] ? preempt_count_add+0x4b/0xa0
[<c115e693>] kmem_cache_alloc+0x1a3/0x290
[<c116fe47>] ? get_empty_filp+0x57/0x1d0
[<c116fe47>] get_empty_filp+0x57/0x1d0
[<c10761ef>] ? sched_clock_cpu+0x10f/0x160
[<c117bcd8>] path_openat+0x28/0x5c0
[<c13d09e2>] ? debug_smp_processor_id+0x12/0x20
[<c117d331>] do_filp_open+0x31/0x90
[<c118a2f8>] ? __alloc_fd+0x88/0x100
[<c1889fac>] ? _raw_spin_unlock+0x2c/0x50
[<c118a2f8>] ? __alloc_fd+0x88/0x100
[<c116d887>] do_sys_open+0x117/0x210
[<c188aeef>] ? restore_all+0xf/0xf
[<c13d09ff>] ? __this_cpu_preempt_check+0xf/0x20
[<c1080000>] ? dequeue_rt_stack+0x1a0/0x2e0
[<c116d9a2>] SyS_open+0x22/0x30
[<c188aeb6>] syscall_call+0x7/0x7
[<c1880000>] ? hpet_reserve_platform_timers+0x6e/0x111
---[ end trace 81f9756f84a67848 ]---
>
> Also, please consider submitting a patch to netdev to document the lock
> requirement with the struct sk_buff_head definition.
>
> Regards,
> Peter Hurley
>
> >
> > __skb_queue_tail(queue, skb);
> >
> > @@ -4690,7 +4691,7 @@ static void hci_queue_acl(struct hci_chan *chan, struct sk_buff_head *queue,
> > __skb_queue_tail(queue, skb);
> > } while (list);
> >
> > - spin_unlock(&queue->lock);
> > + spin_unlock_irqrestore(&queue->lock, irq_flags);
> > }
> > }
> >
> >
>
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH] Bluetooth: Incorrect locking when sending data in softirq
From: Alexander Aring @ 2014-10-15 13:36 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: linux-bluetooth
In-Reply-To: <1413376985-25812-1-git-send-email-jukka.rissanen@linux.intel.com>
Hi Jukka,
I am not sure but I think this issue occurs because the bt_xmit callback
is called in an atomic context.
The function hci_queue_acl seems to be some function which is used in
some others context which isn't an atomic context, means maybe in
some workqueue context or something else, where "might_sleep()" is
allowed. Simple this function isn't irqsafe.
With this patch you would make it allowed that this function can called
inside of an "atomic context", so you make it irqsafe.
By changing these locking mechanism to spin_lock_irqsave/spin_unlock_irqrestore
you need to be sure that all others which locks the queue->lock should
also call spin_lock_irqsave/spin_unlock_irqrestore and not
spin_lock/spin_unlock anymore.
This would be a huge design change in bluetooth, maybe the bluetooth
maintainers will ack this, I don't know. Maybe there exist also some
other calling path where "might_sleep()" is allowed and you have the
issue again.
Another "possible" solution would be a similar function but this is irqsafe.
Maybe "hci_queue_acl_irqsafe". I don't know how possible that is, simple
that not every context call the spin_foo_irqave functions. If the lock
is used somewhere else... this would be hard to solve to change
spin__foo/spin_foo_irqsave.
A second "possible" easy solution would maybe that bt_xmit setups a
workqueue, at the end of the xmit call you should schedule the workqueue
then. But this is a terrible solution, because you lost all context
information from bt_xmit calls (atomic context, lockings, etc...), also
that "might_sleep()" is allowed while transmit isn't nice.
We have the same issue in 802.15.4 because some driver calls spi_sync(),
then we start a workqueue for it and run the work callback afterwards
which calls spi_sync at least.
spi_sync is just a framework above spi_async with some fancy scheduler
function like wait_for_completion. We can't run spi_sync in the xmit
function because this call wait_for_completion ("might_sleep()") and
this isn't allowed in atomic context.
I don't can't say what you need to do here. I only want to let you know
my suggestions to this patch.
- Alex
^ permalink raw reply
* [PBAP 1/2] obexd/client/pbap: Add support for spd,fav in PBAP
From: Gowtham Anandha Babu @ 2014-10-15 13:39 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, d.kasatkin, bharat.panda, cpgs, Gowtham Anandha Babu
Add support for the speed-dial and favorite entries in PBAP.
---
doc/obex-api.txt | 2 ++
obexd/client/pbap.c | 10 +++++++---
obexd/plugins/phonebook.h | 4 ++++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/doc/obex-api.txt b/doc/obex-api.txt
index f80ef39..4439a41 100644
--- a/doc/obex-api.txt
+++ b/doc/obex-api.txt
@@ -341,6 +341,8 @@ Methods void Select(string location, string phonebook)
"och": outgoing call history
"mch": missing call history
"cch": combination of ich och mch
+ "spd": speed dials entry ( only for "internal" )
+ "fav": favorites entry ( only for "internal" )
Possible errors: org.bluez.obex.Error.InvalidArguments
org.bluez.obex.Error.Failed
diff --git a/obexd/client/pbap.c b/obexd/client/pbap.c
index 2089860..614616c 100644
--- a/obexd/client/pbap.c
+++ b/obexd/client/pbap.c
@@ -183,11 +183,13 @@ static const GMarkupParser listing_parser = {
static char *build_phonebook_path(const char *location, const char *item)
{
char *path = NULL, *tmp, *tmp1;
+ int int_telecom = 0;
if (!g_ascii_strcasecmp(location, "int") ||
- !g_ascii_strcasecmp(location, "internal"))
+ !g_ascii_strcasecmp(location, "internal")) {
path = g_strdup("/telecom");
- else if (!g_ascii_strncasecmp(location, "sim", 3)) {
+ int_telecom = 1;
+ } else if (!g_ascii_strncasecmp(location, "sim", 3)) {
if (strlen(location) == 3)
tmp = g_strdup("sim1");
else
@@ -202,7 +204,9 @@ static char *build_phonebook_path(const char *location, const char *item)
!g_ascii_strcasecmp(item, "ich") ||
!g_ascii_strcasecmp(item, "och") ||
!g_ascii_strcasecmp(item, "mch") ||
- !g_ascii_strcasecmp(item, "cch")) {
+ !g_ascii_strcasecmp(item, "cch") ||
+ (int_telecom && !g_ascii_strcasecmp(item, "spd")) ||
+ (int_telecom && !g_ascii_strcasecmp(item, "fav"))) {
tmp = path;
tmp1 = g_ascii_strdown(item, -1);
path = g_build_filename(tmp, tmp1, NULL);
diff --git a/obexd/plugins/phonebook.h b/obexd/plugins/phonebook.h
index fff33c1..70a9cb7 100644
--- a/obexd/plugins/phonebook.h
+++ b/obexd/plugins/phonebook.h
@@ -37,6 +37,8 @@
#define PB_CALLS_INCOMING_FOLDER "/telecom/ich"
#define PB_CALLS_MISSED_FOLDER "/telecom/mch"
#define PB_CALLS_OUTGOING_FOLDER "/telecom/och"
+#define PB_CALLS_SPEEDDIAL_FOLDER "/telecom/spd"
+#define PB_CALLS_FAVORITE_FOLDER "/telecom/fav"
#define PB_LUID_FOLDER "/telecom/pb/luid"
#define PB_CONTACTS "/telecom/pb.vcf"
@@ -44,6 +46,8 @@
#define PB_CALLS_INCOMING "/telecom/ich.vcf"
#define PB_CALLS_MISSED "/telecom/mch.vcf"
#define PB_CALLS_OUTGOING "/telecom/och.vcf"
+#define PB_CALLS_SPEEDDIAL "/telecom/spd.vcf"
+#define PB_CALLS_FAVORITE "/telecom/fav.vcf"
#define PB_DEVINFO "/telecom/devinfo.txt"
#define PB_INFO_LOG "/telecom/pb/info.log"
#define PB_CC_LOG "/telecom/pb/luid/cc.log"
--
1.9.1
^ permalink raw reply related
* [PBAP 2/2] obexd/client/pbap: Adds few attributes to property mask
From: Gowtham Anandha Babu @ 2014-10-15 13:39 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, d.kasatkin, bharat.panda, cpgs, Gowtham Anandha Babu
In-Reply-To: <1413380382-3302-1-git-send-email-gowtham.ab@samsung.com>
Adds the below attributes for property mask:
1) Speed-dial
2) Uniform Caller Identifier
3) Unique Identifier
---
obexd/client/pbap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/obexd/client/pbap.c b/obexd/client/pbap.c
index 614616c..fe0602e 100644
--- a/obexd/client/pbap.c
+++ b/obexd/client/pbap.c
@@ -103,6 +103,9 @@ static const char *filter_list[] = {
"CLASS",
"SORT-STRING",
"X-IRMC-CALL-DATETIME",
+ "X-BT-SPEEDDIALKEY",
+ "X-BT-UCI",
+ "X-BT-UID",
NULL
};
--
1.9.1
^ permalink raw reply related
* [PATCH] monitor: Fix indentation for AVRCP PASS THROUGH commands
From: Vikrampal Yadav @ 2014-10-15 13:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, d.kasatkin, vikram.pal, cpgs
Intendation for AVRCP PASS THROUGH commands' decoding fixed.
btmon snippets:
Channel: 66 len 14 [PSM 23 mode 0] {chan 3}
AVCTP Control: Command: type 0x00 label 0 PID 0x110e
AV/C: Status: address 0x48 opcode 0x7c
Subunit: Panel
Opcode: Passthrough
Operation: 0x44 (PLAY Pressed)
Lenght: 0x00
---
monitor/avctp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor/avctp.c b/monitor/avctp.c
index a4e34c5..4abd18f 100644
--- a/monitor/avctp.c
+++ b/monitor/avctp.c
@@ -686,13 +686,13 @@ static bool avrcp_passthrough_packet(struct avctp_frame *avctp_frame,
if (!l2cap_frame_get_u8(frame, &op))
return false;
- print_field("%*cOperation: 0x%02x (%s %s)", (indent - 2), ' ', op,
+ print_field("%*cOperation: 0x%02x (%s %s)", (indent - 8), ' ', op,
op2str(op), op & 0x80 ? "Released" : "Pressed");
if (!l2cap_frame_get_u8(frame, &len))
return false;
- print_field("%*cLength: 0x%02x", (indent - 2), ' ', len);
+ print_field("%*cLength: 0x%02x", (indent - 8), ' ', len);
packet_hexdump(frame->data, frame->size);
return true;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6] Bluetooth: Defer connection-parameter removal when unpairing
From: Johan Hedberg @ 2014-10-15 13:44 UTC (permalink / raw)
To: Alfonso Acosta; +Cc: linux-bluetooth
In-Reply-To: <1413063887-25870-1-git-send-email-fons@spotify.com>
Hi Alfonso,
On Sat, Oct 11, 2014, Alfonso Acosta wrote:
> Systematically removing the LE connection parameters and autoconnect
> action is inconvenient for rebonding without disconnecting from
> userland (i.e. unpairing followed by repairing without
> disconnecting). The parameters will be lost after unparing and
> userland needs to take care of book-keeping them and re-adding them.
>
> This patch allows userland to forget about parameter management when
> rebonding without disconnecting. It defers clearing the connection
> parameters when unparing without disconnecting, giving a chance of
> keeping the parameters if a repairing happens before the connection is
> closed.
>
> Signed-off-by: Alfonso Acosta <fons@spotify.com>
This patch has now been applied to the bluetooth-next tree. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] monitor: Fix indentation for AVRCP PASS THROUGH commands
From: Luiz Augusto von Dentz @ 2014-10-15 13:45 UTC (permalink / raw)
To: Vikrampal Yadav; +Cc: linux-bluetooth@vger.kernel.org, Dmitry Kasatkin, cpgs
In-Reply-To: <1413380509-596-1-git-send-email-vikram.pal@samsung.com>
Hi Vikram,
On Wed, Oct 15, 2014 at 4:41 PM, Vikrampal Yadav <vikram.pal@samsung.com> wrote:
> Intendation for AVRCP PASS THROUGH commands' decoding fixed.
>
> btmon snippets:
>
> Channel: 66 len 14 [PSM 23 mode 0] {chan 3}
> AVCTP Control: Command: type 0x00 label 0 PID 0x110e
> AV/C: Status: address 0x48 opcode 0x7c
> Subunit: Panel
> Opcode: Passthrough
> Operation: 0x44 (PLAY Pressed)
> Lenght: 0x00
> ---
> monitor/avctp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/monitor/avctp.c b/monitor/avctp.c
> index a4e34c5..4abd18f 100644
> --- a/monitor/avctp.c
> +++ b/monitor/avctp.c
> @@ -686,13 +686,13 @@ static bool avrcp_passthrough_packet(struct avctp_frame *avctp_frame,
> if (!l2cap_frame_get_u8(frame, &op))
> return false;
>
> - print_field("%*cOperation: 0x%02x (%s %s)", (indent - 2), ' ', op,
> + print_field("%*cOperation: 0x%02x (%s %s)", (indent - 8), ' ', op,
> op2str(op), op & 0x80 ? "Released" : "Pressed");
>
> if (!l2cap_frame_get_u8(frame, &len))
> return false;
>
> - print_field("%*cLength: 0x%02x", (indent - 2), ' ', len);
> + print_field("%*cLength: 0x%02x", (indent - 8), ' ', len);
>
> packet_hexdump(frame->data, frame->size);
> return true;
> --
> 1.9.1
>
Applied, please make sure the patch format is 50/72 according to the
HACKING document.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Naveen Kumar Parna @ 2014-10-15 13:46 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-bluetooth@vger.kernel.org, linux-usb, acho
In-Reply-To: <CAG0bkvJ8QrvdhCQjwOm79KMZWbE7S=keOfdTy7hyUCV-RmLegQ@mail.gmail.com>
Hi Oliver,
I tried this test in two different set of hardware configurations.
i) I tried in multiple test systems which has
EHCI-USB host controller on PCI card and internal USB 2.0
hub("rate-matching" hub). All the test systems with this configuration
gives spurious stall packets.
[lowerlayers@banunxcas29 ~]$ lspci | grep -i usb
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
lsusb:
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ii) I found different test systems which has
OHCI-USB host controller on PCI card and internal USB 1.1 hub. All the
test systems with this configuration are not producing stall packets.
[lowerlayers@camunxcas11 ~]$ lspci | grep -i usb
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
lsusb:
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0451:2077 Texas Instruments, Inc. TUSB2077 Hub
My device is a full-speed device. So , stall packets are due to buggy
USB 2.0 hub?
Is there a chance of getting stall packets “If the device runs at low
speed or full speed and is connected through a USB-2.0 hub”? If so it
looks like hub driver issue right?
If the hub is the problem… what will be the better solution? Is it
possible to change internal hub?
Thanks,
Naveen
On Wed, Oct 15, 2014 at 6:39 PM, Naveen Kumar Parna
<pnaveenkos@gmail.com> wrote:
> EHCI controller on PCI card and hub("rate-matching" hub) also internal.
>
> Is it possible to change the internal hub?
>
>
>
> Thanks,
> Naveen
>
> On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum <oneukum@suse.de> wrote:
>> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>>
>>> > Hi Oliver & Alan,
>>> >
>>> >
>>> >
>>> > Thanks for your inputs.
>>> >
>>> >
>>> >
>>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>>> > if I am wrong.
>>>
>>> Debugging the kernel (or doing anything else to the kernel, for that
>>> matter) won't solve the problem if it is caused by a buggy hub.
>>
>> Indeed. Could you just try a different hub?
>>
>> Regards
>> Oliver
>>
>>
>>
^ permalink raw reply
* Re: [PATCH v3 1/2] Bluetooth: Fix RFCOMM NSC response
From: Johan Hedberg @ 2014-10-15 13:56 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1413193434-16779-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Mon, Oct 13, 2014, Szymon Janc wrote:
> rfcomm_send_nsc expects CR to be either 0 or 1 since it is later
> passed to __mcc_type macro and shitfed. Unfortunatelly CR extracted
> from received frame type was not sanitized and shifted value was passed
> resulting in bogus response.
>
> Note: shifted value was also passed to other functions but was used
> only in if satements so this bug appears only for NSC case.
>
> The CR bit in the value octet shall be set to the same value
> as the CR bit in the type field octet of the not supported command
> frame but the CR bit for NCS response should be set to 0 since it is
> always a response.
>
> This was affecting TC_RFC_BV_25_C PTS qualification test.
>
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> ---
>
> V3: fixed invalid CR
> V2: moved sanitization to macro ifself
> added second patch that also fix __test_pf
>
> net/bluetooth/rfcomm/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Both of these patches have been applied to bluetooth-next. Thanks.
Johan
^ 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