* [PATCH BlueZ 8/8] unit/test-avrcp: Add /TP/MPS/BI-02-C test
From: Luiz Augusto von Dentz @ 2014-10-08 12:31 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1412771509-7996-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Verify the SetBrowsedPlayer response issued by the TG when an invalid
player is requested.
---
unit/test-avrcp.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/unit/test-avrcp.c b/unit/test-avrcp.c
index 18a8785..128ab00 100644
--- a/unit/test-avrcp.c
+++ b/unit/test-avrcp.c
@@ -607,13 +607,19 @@ static int set_addressed(struct avrcp *session, uint8_t transaction,
static int set_browsed(struct avrcp *session, uint8_t transaction,
uint16_t id, void *user_data)
{
+ struct context *context = user_data;
const char *folders[1] = { "Filesystem" };
DBG("");
- avrcp_set_browsed_player_rsp(session, transaction,
- AVRCP_STATUS_SUCCESS, 0xabcd, 0, 1,
- folders);
+ if (g_str_equal(context->data->test_name, "/TP/MPS/BI-02-C"))
+ avrcp_set_browsed_player_rsp(session, transaction,
+ AVRCP_STATUS_INVALID_PLAYER_ID,
+ 0, 0, 0, NULL);
+ else
+ avrcp_set_browsed_player_rsp(session, transaction,
+ AVRCP_STATUS_SUCCESS,
+ 0xabcd, 0, 1, folders);
return -EAGAIN;
}
@@ -991,6 +997,13 @@ int main(int argc, char *argv[])
AVRCP_SET_ADDRESSED_PLAYER,
0x00, 0x00, 0x01, 0x11));
+ /* SetBrowsedPlayer - TG */
+ define_test("/TP/MPS/BI-02-C", test_server,
+ brs_pdu(0x00, 0x11, 0x0e, 0x70, 0x00, 0x02,
+ 0xab, 0xcd),
+ brs_pdu(0x02, 0x11, 0x0e, 0x70, 0x00, 0x01,
+ 0x11));
+
/*
* Media Content Navigation Commands and Notifications for Content
* Browsing.
--
1.9.3
^ permalink raw reply related
* Re: [PATCH bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 12:52 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: linux-bluetooth, linux-wpan, marcel, alex.aring
In-Reply-To: <1412770375.2705.25.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
I've misunderstood the constraints on pskb_expand_head. I don't suppose you could quickly try this patch it now uses skb_share_check to ensure skb->users == 1 and then I've put back in the skb_clone code that I took out which I think is causing the problem:
Many Thanks,
Martin.
Currently there are potentially 2 skb_copy_expand calls in IPHC
decompression. This patch replaces this with one call to
pskb_expand_head. It also checks to see if there is enough headroom
first to ensure it's only done if necessary.
As pskb_expand_head must only have one reference the calling code
now ensures this.
---
net/6lowpan/iphc.c | 51 +++++++++++++++++++++----------------------
net/bluetooth/6lowpan.c | 7 ++++++
net/ieee802154/6lowpan_rtnl.c | 5 +++++
3 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 142eef5..853b4b8 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -174,30 +174,22 @@ static int uncompress_context_based_src_addr(struct sk_buff *skb,
static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
struct net_device *dev, skb_delivery_cb deliver_skb)
{
- struct sk_buff *new;
int stat;
- new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
- GFP_ATOMIC);
- kfree_skb(skb);
-
- if (!new)
- return -ENOMEM;
-
- skb_push(new, sizeof(struct ipv6hdr));
- skb_reset_network_header(new);
- skb_copy_to_linear_data(new, hdr, sizeof(struct ipv6hdr));
+ skb_push(skb, sizeof(struct ipv6hdr));
+ skb_reset_network_header(skb);
+ skb_copy_to_linear_data(skb, hdr, sizeof(struct ipv6hdr));
- new->protocol = htons(ETH_P_IPV6);
- new->pkt_type = PACKET_HOST;
- new->dev = dev;
+ skb->protocol = htons(ETH_P_IPV6);
+ skb->pkt_type = PACKET_HOST;
+ skb->dev = dev;
raw_dump_table(__func__, "raw skb data dump before receiving",
- new->data, new->len);
+ skb->data, skb->len);
- stat = deliver_skb(new, dev);
+ stat = deliver_skb(skb, dev);
- kfree_skb(new);
+ consume_skb(skb);
return stat;
}
@@ -460,7 +452,7 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
/* UDP data uncompression */
if (iphc0 & LOWPAN_IPHC_NH_C) {
struct udphdr uh;
- struct sk_buff *new;
+ const int needed = sizeof(struct udphdr) + sizeof(hdr);
if (uncompress_udp_header(skb, &uh))
goto drop;
@@ -468,14 +460,13 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
/* replace the compressed UDP head by the uncompressed UDP
* header
*/
- new = skb_copy_expand(skb, sizeof(struct udphdr),
- skb_tailroom(skb), GFP_ATOMIC);
- kfree_skb(skb);
-
- if (!new)
- return -ENOMEM;
-
- skb = new;
+ if (skb_headroom(skb) < needed) {
+ err = pskb_expand_head(skb, needed, 0, GFP_ATOMIC);
+ if (unlikely(err)) {
+ kfree_skb(skb);
+ return err;
+ }
+ }
skb_push(skb, sizeof(struct udphdr));
skb_reset_transport_header(skb);
@@ -485,6 +476,14 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
(u8 *)&uh, sizeof(uh));
hdr.nexthdr = UIP_PROTO_UDP;
+ } else {
+ if (skb_headroom(skb) < sizeof(hdr)) {
+ err = pskb_expand_head(skb, sizeof(hdr), 0, GFP_ATOMIC);
+ if (unlikely(err)) {
+ kfree_skb(skb);
+ return err;
+ }
+ }
}
hdr.payload_len = htons(skb->len);
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index c2e0d14..6643a7c 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -343,6 +343,13 @@ static int recv_pkt(struct sk_buff *skb, struct net_device *dev,
kfree_skb(local_skb);
kfree_skb(skb);
} else {
+ /* Decompression may use pskb_expand_head so no shared skb's */
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb) {
+ dev->stats.rx_dropped++;
+ return NET_RX_DROP;
+ }
+
switch (skb->data[0] & 0xe0) {
case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
local_skb = skb_clone(skb, GFP_ATOMIC);
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index c7e07b8..702ad04 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -537,6 +537,11 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
if (ret == NET_RX_DROP)
goto drop;
} else {
+ /* Decompression may use pskb_expand_head so no shared skb's */
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb)
+ goto drop;
+
switch (skb->data[0] & 0xe0) {
case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
ret = process_data(skb, &hdr);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 0/6] android/map-client: Add HAL part
From: Szymon Janc @ 2014-10-08 12:59 UTC (permalink / raw)
To: Grzegorz Kolodziejczyk; +Cc: linux-bluetooth
In-Reply-To: <1412345077-30317-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Hi Grzegorz,
On Friday 03 of October 2014 16:04:37 Grzegorz Kolodziejczyk wrote:
> v2. changes:
> *Defines in HAL are the same as in IPC
> *Removed MAP instance structures section in ipc api doc
> *Check if MAP instance name is null terminated
> *Fixed multiline comment
>
> Grzegorz Kolodziejczyk (6):
> android/hal-ipc-api: Add MAP client HAL
> android/hal-map-client-api: Add get remote MAS instance command and
> event
> android/map-client: Add Android MAP client header
> android/hal-map-client: Add skeleton for MAP client HAL
> android/hal-map-client: Add event handler
> android/hal-map-client: Add API calls
>
> android/Android.mk | 1 +
> android/Makefile.am | 2 +
> android/hal-bluetooth.c | 3 +
> android/hal-ipc-api.txt | 42 ++++++++++++
> android/hal-map-client.c | 152 +++++++++++++++++++++++++++++++++++++++++++
> android/hal-msg.h | 26 +++++++-
> android/hal.h | 2 +
> android/hardware/bluetooth.h | 1 +
> android/hardware/bt_mce.h | 57 ++++++++++++++++
> 9 files changed, 285 insertions(+), 1 deletion(-)
> create mode 100644 android/hal-map-client.c
> create mode 100644 android/hardware/bt_mce.h
>
I've applied this set after some random cleanups and fixes. In future please test
if code build on both Linux and Android. Thanks.
--
Best regards,
Szymon Janc
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Naveen Kumar Parna @ 2014-10-08 13:01 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-bluetooth@vger.kernel.org, linux-usb, acho
In-Reply-To: <1412765090.21709.18.camel@linux-0dmf.site>
> Do you see the problem with single devices?
If I connect only one device to system then I did not see this issue.
Usually I will use 8 devices(all with the same firmware) for testing.
I tried different method to get some clue. First I disconnected all
the devices and rebooted the system and later connected only one
device and observed hci0 related debug print statements in the kernel
log. Waited for 16mins idle, but did not get –EPIPE.
Oct 8 16:41:46 banunxcas29 kernel: [ 488.018751] usb 1-1.5.1.7: new
full speed USB device number 13 using ehci_hcd
Oct 8 16:41:46 banunxcas29 kernel: [ 488.093487] usb 1-1.5.1.7: New
USB device found, idVendor=0451, idProduct=2036
Oct 8 16:41:46 banunxcas29 kernel: [ 488.093494] usb 1-1.5.1.7: New
USB device strings: Mfr=0, Product=1, SerialNumber=0
Oct 8 16:41:46 banunxcas29 kernel: [ 488.093499] usb 1-1.5.1.7:
Product: General Purpose USB Hub
Oct 8 16:41:46 banunxcas29 kernel: [ 488.094581] hub 1-1.5.1.7:1.0:
USB hub found
Oct 8 16:41:46 banunxcas29 kernel: [ 488.094811] hub 1-1.5.1.7:1.0:
2 ports detected
Oct 8 16:41:46 banunxcas29 kernel: [ 488.261141] usb 1-1.5.2: new
full speed USB device number 14 using ehci_hcd
Oct 8 16:41:46 banunxcas29 kernel: [ 488.323983] usb 1-1.5.2: device
descriptor read/64, error -32
Oct 8 16:41:47 banunxcas29 kernel: [ 488.518202] usb 1-1.5.2: New
USB device found, idVendor=0a12, idProduct=0001
Oct 8 16:41:47 banunxcas29 kernel: [ 488.518208] usb 1-1.5.2: New
USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551389] Bluetooth: Core ver 2.16
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551402] NET: Registered
protocol family 31
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551404] Bluetooth: HCI
device and connection manager initialized
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551406] Bluetooth: HCI
socket layer initialized
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551408] Bluetooth: L2CAP
socket layer initialized
Oct 8 16:41:47 banunxcas29 kernel: [ 488.551411] Bluetooth: SCO
socket layer initialized
Oct 8 16:41:47 banunxcas29 kernel: [ 488.565663] Bluetooth: Generic
Bluetooth USB driver ver 0.6
Oct 8 16:41:47 banunxcas29 kernel: [ 488.565693] intf
ffff880128640800 id ffffffffa0197f00
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580231] hci0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580236] hci0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580258] intf
ffff880128641000 id ffffffffa0197f00
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580296] usbcore: registered
new interface driver btusb
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580480] hci0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580486] hci0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.580503] hci0
Oct 8 16:41:47 banunxcas29 kernel: [ 488.581314] hci0 urb
ffff880131dbe3c0 status 0 count 6
Later connected one more device to system and noticed hci1 related
debug print statements in the kernel log. Waited for 20mins idle and
now also not received –EPIPE.
Oct 8 16:57:44 banunxcas29 kernel: [ 1443.815276] usb 1-1.5.3: new
full speed USB device number 17 using ehci_hcd
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400987] usb 1-1.5.3: New
USB device found, idVendor=0a12, idProduct=0001
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400993] usb 1-1.5.3: New
USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403218] intf
ffff880124c45800 id ffffffffa0197f00
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403360] hci1
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403364] hci1
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403500] intf
ffff880124c44c00 id ffffffffa0197f00
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403511] hci1
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403515] hci1
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403529] hci1
Oct 8 16:57:45 banunxcas29 kernel: [ 1444.404872] hci1 urb
ffff880129162840 status 0 count 6
Later connected third device(hci2) and after 2mins observed –EPIPE for
hci2(hci2 urb ffff880124f11cc0 status -32 count 0)
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.069853] usb 1-1.5.4: new
full speed USB device number 18 using ehci_hcd
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681729] usb 1-1.5.4: New
USB device found, idVendor=0a12, idProduct=0001
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681735] usb 1-1.5.4: New
USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683689] intf
ffff880119c3b400 id ffffffffa0197f00
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683886] hci2
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683889] hci2
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684083] intf
ffff880119c3a800 id ffffffffa0197f00
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684161] hci2
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684166] hci2
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684184] hci2
Oct 8 17:18:21 banunxcas29 kernel: [ 2677.685364] hci2 urb
ffff880124f11cc0 status 0 count 6
Oct 8 17:18:22 banunxcas29 kernel: [ 2678.126333] hci2 urb
ffff880124f11cc0 status 0 count 6
Oct 8 17:20:20 banunxcas29 kernel: [ 2795.645039] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 17:20:20 banunxcas29 kernel: [ 2795.646013] hci2
Later connected 4th device(hci3) and now repeatedly getting –EPIPE for
hci3 and hci2
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.073252] usb 1-1.5.5: new
full speed USB device number 19 using ehci_hcd
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.746971] usb 1-1.5.5: New
USB device found, idVendor=0a12, idProduct=0001
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.746977] usb 1-1.5.5: New
USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749042] intf
ffff880124c47400 id ffffffffa0197f00
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749403] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749407] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749526] intf
ffff880124c47000 id ffffffffa0197f00
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749679] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749684] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749700] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.750520] hci3 urb
ffff8801344e6a80 status 0 count 6
Oct 8 17:49:45 banunxcas29 kernel: [ 4556.495180] hci3 urb
ffff8801344e6a80 status -32 count 0
Oct 8 17:49:45 banunxcas29 kernel: [ 4556.496341] hci3
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.170274] hci2 urb
ffff880131c6ea80 status -32 count 0
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.170345] hci3 urb
ffff880124dfb480 status -32 count 0
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.171381] hci2
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.171759] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.920586] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.921890] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.928470] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.929511] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.933570] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.934402] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.940425] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.941531] hci3
Oct 8 18:05:18 banunxcas29 kernel: [ 5487.003279] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:05:18 banunxcas29 kernel: [ 5487.004528] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.844852] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.846068] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.860809] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.861776] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.867701] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.868651] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.874669] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.874738] hci3 urb
ffff880124f183c0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.875772] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.875949] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.877734] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.877800] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.878720] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.878922] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.098220] hci3 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.098291] hci2 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.099158] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.099339] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.101145] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.102165] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.107198] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.108141] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.121160] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.122130] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.133127] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.133196] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.134075] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.134300] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.136143] hci3 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.136176] hci2 urb
ffff880124f11e40 status -32 count 0
I ran hcidump for each hci device separately, but it does not show any
activity during EPIPE occurrence.
It clearly tells that device not producing stalls , looks like issue
might be in between btusb and ehci_hcd\hub.
What might the best way to recover and avoid spurious stalls?
Thanks,
Naveen
On Wed, Oct 8, 2014 at 4:14 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Wed, 2014-10-08 at 15:51 +0530, Naveen Kumar Parna wrote:
>> hcidump does not show anything when the stalls happen.
>
> There is nothing in all logs. Do you see the problem
> with single devices?
>
> Regards
> Oliver
>
>
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Oliver Neukum @ 2014-10-08 13:17 UTC (permalink / raw)
To: Naveen Kumar Parna; +Cc: linux-bluetooth@vger.kernel.org, linux-usb, acho
In-Reply-To: <CAG0bkvLy9YNdD-0hYNygT0cVEHAZebobxwJKdsuUcXsLmq9BfQ@mail.gmail.com>
On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote:
> Later connected third device(hci2) and after 2mins observed –EPIPE for
> hci2(hci2 urb ffff880124f11cc0 status -32 count 0)
This points to a problem in the USB HC driver.
Can you enable debugging in that driver.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] android/pts: Updated PBAP PICS and PIXITs for PTS 5.3
From: Szymon Janc @ 2014-10-08 13:20 UTC (permalink / raw)
To: Ruslan Mstoi; +Cc: linux-bluetooth
In-Reply-To: <1412604792-28728-1-git-send-email-ruslan.mstoi@linux.intel.com>
Hi Ruslan,
On Monday 06 of October 2014 17:13:12 Ruslan Mstoi wrote:
> ---
> android/pics-pbap.txt | 2 +-
> android/pixit-pbap.txt | 2 +-
> android/pts-pbap.txt | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/android/pics-pbap.txt b/android/pics-pbap.txt
> index bcb71b6..cb4126c 100644
> --- a/android/pics-pbap.txt
> +++ b/android/pics-pbap.txt
> @@ -1,6 +1,6 @@
> PBAP 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-pbap.txt b/android/pixit-pbap.txt
> index 7bc374b..f7a93c6 100644
> --- a/android/pixit-pbap.txt
> +++ b/android/pixit-pbap.txt
> @@ -1,6 +1,6 @@
> PBAP 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-pbap.txt b/android/pts-pbap.txt
> index 6341f5c..67e366d 100644
> --- a/android/pts-pbap.txt
> +++ b/android/pts-pbap.txt
> @@ -1,7 +1,7 @@
> PTS test results for PBAP
>
> -PTS version: 5.2
> -Tested: 04-August-2014
> +PTS version: 5.3
> +Tested: 06-October-2014
> Android version: 4.4.4
>
> Results:
>
Applied, thanks.
--
Best regards,
Szymon Janc
^ permalink raw reply
* Re: [PATCH] android/pts: Updated AVRCP PICS and PIXITs for PTS 5.3
From: Szymon Janc @ 2014-10-08 13:20 UTC (permalink / raw)
To: Ruslan Mstoi; +Cc: linux-bluetooth
In-Reply-To: <1412760639-6280-1-git-send-email-ruslan.mstoi@linux.intel.com>
Hi Ruslan,
On Wednesday 08 of October 2014 12:30:39 Ruslan Mstoi wrote:
> ---
> android/pics-avrcp.txt | 95 +++++++++++++++++++++++++++----------------------
> android/pixit-avrcp.txt | 2 +-
> android/pts-avrcp.txt | 4 +--
> 3 files changed, 55 insertions(+), 46 deletions(-)
>
> diff --git a/android/pics-avrcp.txt b/android/pics-avrcp.txt
> index f339689..da72fe1 100644
> --- a/android/pics-avrcp.txt
> +++ b/android/pics-avrcp.txt
> @@ -1,6 +1,6 @@
> AVRCP PICS for the PTS tool.
>
> -PTS version: 5.2
> +PTS version: 5.3
>
> * - different than PTS defaults
> # - not yet implemented/supported
> @@ -12,8 +12,8 @@ O - optional
> -------------------------------------------------------------------------------
> Parameter Name Selected Description
> -------------------------------------------------------------------------------
> -SPC_AVRCP_1_1 True Role: Controller (CT) (C.1)
> -TSPC_AVRCP_1_2 True Role: Target (TG) (C.1)
> +SPC_AVRCP_1_1 True (*) Role: Controller (CT) (C.1)
> +TSPC_AVRCP_1_2 True (*) Role: Target (TG) (C.1)
> -------------------------------------------------------------------------------
> C.1: Mandatory to support at least one of the defined roles.
> -------------------------------------------------------------------------------
> @@ -29,7 +29,7 @@ TSPC_AVRCP_2_3 False (*) CT: Initiating connection release (M)
> TSPC_AVRCP_2_4 False (*) CT: Accepting connection release (M)
> TSPC_AVRCP_2_5 False CT: Sending UNIT INFO (O)
> TSPC_AVRCP_2_6 False CT: Sending SUBUNIT INFO (O)
> -TSPC_AVRCP_2_7 False (*) CT: Sending PASS THROUGH command category 1
> +TSPC_AVRCP_2_7 False CT: Sending PASS THROUGH command category 1
> (C.1)
> TSPC_AVRCP_2_8 False CT: Sending PASS THROUGH command category 2
> (C.1)
> @@ -161,9 +161,9 @@ TSPC_AVRCP_3_16 False CT: category 1 - Operation id:
> display_information (C.1)
> TSPC_AVRCP_3_17 False CT: category 1 - Operation id: help (C.1)
> TSPC_AVRCP_3_18 False CT: category 1 - Operation id: power (C.1)
> -TSPC_AVRCP_3_19 False (*) CT: category 1 - Operation id: play (C.1)
> -TSPC_AVRCP_3_20 False (*) CT: category 1 - Operation id: stop (C.1)
> -TSPC_AVRCP_3_21 False (*) CT: category 1 - Operation id: pause (C.1)
> +TSPC_AVRCP_3_19 False CT: category 1 - Operation id: play (C.1)
> +TSPC_AVRCP_3_20 False CT: category 1 - Operation id: stop (C.1)
> +TSPC_AVRCP_3_21 False CT: category 1 - Operation id: pause (C.1)
> TSPC_AVRCP_3_22 False CT: category 1 - Operation id: record (C.1)
> TSPC_AVRCP_3_23 False CT: category 1 - Operation id: rewind (C.1)
> TSPC_AVRCP_3_24 False CT: category 1 - Operation id: fast_forward
> @@ -211,8 +211,8 @@ TSPC_AVRCP_4_16 False CT: category 2 - Operation id:
> display_information (C.2)
> TSPC_AVRCP_4_17 False CT: category 2 - Operation id: help (C.2)
> TSPC_AVRCP_4_18 False CT: category 2 - Operation id: power (C.2)
> -TSPC_AVRCP_4_19 False (*) CT: category 2 - Operation id: volume_up (C.2)
> -TSPC_AVRCP_4_20 False (*) CT: category 2 - Operation id: volume_down (C.2)
> +TSPC_AVRCP_4_19 False CT: category 2 - Operation id: volume_up (C.2)
> +TSPC_AVRCP_4_20 False CT: category 2 - Operation id: volume_down (C.2)
> TSPC_AVRCP_4_21 False CT: category 2 - Operation id: mute (C.2)
> TSPC_AVRCP_4_22 False CT: category 2 - Operation id: F1 (C.2)
> TSPC_AVRCP_4_23 False CT: category 2 - Operation id: F2 (C.2)
> @@ -330,11 +330,11 @@ Parameter Name Selected Description
> -------------------------------------------------------------------------------
> TSPC_AVRCP_7_1 True (*) TG: Initiating connection establishment (O)
> TSPC_AVRCP_7_2 True TG: Accept connection establishment (M)
> -TSPC_AVRCP_7_3 True TG: Initiating connection release (M)
> +TSPC_AVRCP_7_3 True (*) TG: Initiating connection release (M)
> TSPC_AVRCP_7_4 True TG: Accepting connection release (M)
> TSPC_AVRCP_7_5 True TG: Receiving UNIT INFO (M)
> TSPC_AVRCP_7_6 True TG: Receiving SUBUNIT INFO (M)
> -TSPC_AVRCP_7_7 True TG: Receiving PASS THROUGH command category 1
> +TSPC_AVRCP_7_7 True (*) TG: Receiving PASS THROUGH command category 1
> (C.1)
> TSPC_AVRCP_7_8 True (*) TG: Receiving PASS THROUGH command category 2
> (C.1)
> @@ -414,10 +414,9 @@ TSPC_AVRCP_7_65 True TG: Discoverable Mode (M)
> TSPC_AVRCP_7_66 False TG: PASSTHROUGH operation supporting press
> and hold (O)
> TSPC_AVRCP_7_67 False TG: Cover Art (O)
> -TSPC_AVRCP_7_68 False TG: GetCapabilities, Cover Art (C.12)
> -TSPC_AVRCP_7_69 False TG: GetImageProperties, Cover Art (C.12)
> -TSPC_AVRCP_7_70 False TG: GetImage, Cover Art (C.12)
> -TSPC_AVRCP_7_71 False TG: GetLinkedThumbnail, Cover Art (C.12)
> +TSPC_AVRCP_7_68 False TG: GetImageProperties, Cover Art (C.16)
> +TSPC_AVRCP_7_69 False TG: GetImage, Cover Art (C.16)
> +TSPC_AVRCP_7_70 False TG: GetLinkedThumbnail, Cover Art (C.16)
> -------------------------------------------------------------------------------
> C.1: Mandatory to support at least one of the categories. Supported
> operation_id's are shown in Table 8 to Table 11.
> @@ -482,7 +481,7 @@ TSPC_AVRCP_8_17 False TG: category 1 - Operation id: help (O)
> TSPC_AVRCP_8_18 False TG: category 1 - Operation id: power (O)
> TSPC_AVRCP_8_19 True TG: category 1 - Operation id: play (M)
> TSPC_AVRCP_8_20 True TG: category 1 - Operation id: stop (M)
> -TSPC_AVRCP_8_21 True TG: category 1 - Operation id: pause (O)
> +TSPC_AVRCP_8_21 True (*) TG: category 1 - Operation id: pause (O)
> TSPC_AVRCP_8_22 False TG: category 1 - Operation id: record (O)
> TSPC_AVRCP_8_23 True (*) TG: category 1 - Operation id: rewind (O)
> TSPC_AVRCP_8_24 True (*) TG: category 1 - Operation id: fast forward (O)
> @@ -495,8 +494,8 @@ TSPC_AVRCP_8_30 False TG: category 1 - Operation id: F1 (O)
> TSPC_AVRCP_8_31 False TG: category 1 - Operation id: F2 (O)
> TSPC_AVRCP_8_32 False TG: category 1 - Operation id: F3 (O)
> TSPC_AVRCP_8_33 False TG: category 1 - Operation id: F4 (O)
> -TSPC_AVRCP_8_33a False TG: category 1 - Operation id: F5 (O)
> -TSPC_AVRCP_8_34 False TG: category 1 - Operation id: vendor unique (O)
> +TSPC_AVRCP_8_34 False TG: category 1 - Operation id: F5 (O)
> +TSPC_AVRCP_8_35 False TG: category 1 - Operation id: vendor unique (O)
> -------------------------------------------------------------------------------
>
>
> @@ -526,12 +525,12 @@ TSPC_AVRCP_9_18 False TG: category 2 - Operation id: power (O)
> TSPC_AVRCP_9_19 True TG: category 2 - Operation id: volume up (C.2)
> TSPC_AVRCP_9_20 True TG: category 2 - Operation id: volume down (C.2)
> TSPC_AVRCP_9_21 False TG: category 2 - Operation id: mute (O)
> -TSPC_AVRCP_9_24 False TG: category 2 - Operation id: F1 (O)
> -TSPC_AVRCP_9_25 False TG: category 2 - Operation id: F2 (O)
> -TSPC_AVRCP_9_26 False TG: category 2 - Operation id: F3 (O)
> -TSPC_AVRCP_9_27 False TG: category 2 - Operation id: F4 (O)
> -TSPC_AVRCP_9_27a False TG: category 2 - Operation id: F5 (O)
> -TSPC_AVRCP_9_28 False TG: category 2 - Operation id: vendor unique (O)
> +TSPC_AVRCP_9_22 False TG: category 2 - Operation id: F1 (O)
> +TSPC_AVRCP_9_23 False TG: category 2 - Operation id: F2 (O)
> +TSPC_AVRCP_9_24 False TG: category 2 - Operation id: F3 (O)
> +TSPC_AVRCP_9_25 False TG: category 2 - Operation id: F4 (O)
> +TSPC_AVRCP_9_26 False TG: category 2 - Operation id: F5 (O)
> +TSPC_AVRCP_9_27 False TG: category 2 - Operation id: vendor unique (O)
> -------------------------------------------------------------------------------
> C.2: Mandatory to support if the device supports category 2 (TSPC_AVRCP_7_8).
> -------------------------------------------------------------------------------
> @@ -554,8 +553,8 @@ TSPC_AVRCP_10_10 False TG: category 3 - Operation id: 9 (O)
> TSPC_AVRCP_10_11 False TG: category 3 - Operation id: dot (O)
> TSPC_AVRCP_10_12 False TG: category 3 - Operation id: enter (O)
> TSPC_AVRCP_10_13 False TG: category 3 - Operation id: clear (O)
> -TSPC_AVRCP_10_14 False TG: category 3 - Operation id: channel up (C.3)
> -TSPC_AVRCP_10_15 False TG: category 3 - Operation id: channel down
> +TSPC_AVRCP_10_14 False (*) TG: category 3 - Operation id: channel up (C.3)
> +TSPC_AVRCP_10_15 False (*) TG: category 3 - Operation id: channel down
> (C.3)
> TSPC_AVRCP_10_16 False TG: category 3 - Operation id: previous channel
> (O)
> @@ -565,14 +564,14 @@ TSPC_AVRCP_10_19 False TG: category 3 - Operation id: display
> information (O)
> TSPC_AVRCP_10_20 False TG: category 3 - Operation id: help (O)
> TSPC_AVRCP_10_21 False TG: category 3 - Operation id: power (O)
> -TSPC_AVRCP_10_21a False TG: category 3 - Operation id: angle (O)
> -TSPC_AVRCP_10_21b False TG: category 3 - Operation id: subpicture (O)
> -TSPC_AVRCP_10_22 False TG: category 3 - Operation id: F1 (O)
> -TSPC_AVRCP_10_23 False TG: category 3 - Operation id: F2 (O)
> -TSPC_AVRCP_10_24 False TG: category 3 - Operation id: F3 (O)
> -TSPC_AVRCP_10_25 False TG: category 3 - Operation id: F4 (O)
> -TSPC_AVRCP_10_25a False TG: category 3 - Operation id: F5 (O)
> -TSPC_AVRCP_10_26 False TG: category 3 - Operation id: vendor unique (O)
> +TSPC_AVRCP_10_22 False TG: category 3 - Operation id: angle (O)
> +TSPC_AVRCP_10_23 False TG: category 3 - Operation id: subpicture (O)
> +TSPC_AVRCP_10_24 False TG: category 3 - Operation id: F1 (O)
> +TSPC_AVRCP_10_25 False TG: category 3 - Operation id: F2 (O)
> +TSPC_AVRCP_10_26 False TG: category 3 - Operation id: F3 (O)
> +TSPC_AVRCP_10_27 False TG: category 3 - Operation id: F4 (O)
> +TSPC_AVRCP_10_28 False TG: category 3 - Operation id: F5 (O)
> +TSPC_AVRCP_10_29 False TG: category 3 - Operation id: vendor unique (O)
> -------------------------------------------------------------------------------
> C.3: Mandatory to support if the device supports category 3 (TSPC_AVRCP_7_9).
> -------------------------------------------------------------------------------
> @@ -582,16 +581,16 @@ C.3: Mandatory to support if the device supports category 3 (TSPC_AVRCP_7_9).
> -------------------------------------------------------------------------------
> Parameter Name Selected Description
> -------------------------------------------------------------------------------
> -TSPC_AVRCP_11_1 False TG: category 4 - Operation id: select (C.4)
> -TSPC_AVRCP_11_2 False TG: category 4 - Operation id: up (C.4)
> -TSPC_AVRCP_11_3 False TG: category 4 - Operation id: down (C.4)
> -TSPC_AVRCP_11_4 False TG: category 4 - Operation id: left (C.4)
> -TSPC_AVRCP_11_5 False TG: category 4 - Operation id: right (C.4)
> +TSPC_AVRCP_11_1 False (*) TG: category 4 - Operation id: select (C.4)
> +TSPC_AVRCP_11_2 False (*) TG: category 4 - Operation id: up (C.4)
> +TSPC_AVRCP_11_3 False (*) TG: category 4 - Operation id: down (C.4)
> +TSPC_AVRCP_11_4 False (*) TG: category 4 - Operation id: left (C.4)
> +TSPC_AVRCP_11_5 False (*) TG: category 4 - Operation id: right (C.4)
> TSPC_AVRCP_11_6 False TG: category 4 - Operation id: right up (O)
> TSPC_AVRCP_11_7 False TG: category 4 - Operation id: right down (O)
> TSPC_AVRCP_11_8 False TG: category 4 - Operation id: left up (O)
> TSPC_AVRCP_11_9 False TG: category 4 - Operation id: left down (O)
> -TSPC_AVRCP_11_10 False TG: category 4 - Operation id: root menu (C.4)
> +TSPC_AVRCP_11_10 False (*) TG: category 4 - Operation id: root menu (C.4)
> TSPC_AVRCP_11_11 False TG: category 4 - Operation id: setup menu (O)
> TSPC_AVRCP_11_12 False TG: category 4 - Operation id: contents menu (O)
> TSPC_AVRCP_11_13 False TG: category 4 - Operation id: favorite menu (O)
> @@ -618,9 +617,19 @@ TSPC_AVRCP_11_33 False TG: category 4 - Operation id: F1 (O)
> TSPC_AVRCP_11_34 False TG: category 4 - Operation id: F2 (O)
> TSPC_AVRCP_11_35 False TG: category 4 - Operation id: F3 (O)
> TSPC_AVRCP_11_36 False TG: category 4 - Operation id: F4 (O)
> -TSPC_AVRCP_11_36a False TG: category 4 - Operation id: F5 (O)
> -TSPC_AVRCP_11_37 False TG: category 4 - Operation id: vendor unique (O)
> -TSPC_AVRCP_ALL False Enables all test cases when set to TRUE.
> +TSPC_AVRCP_11_37 False TG: category 4 - Operation id: F5 (O)
> +TSPC_AVRCP_11_38 False TG: category 4 - Operation id: vendor unique (O)
> +
> +TSPC_AVRCP_12_1 True General discoverable mode
> +TSPC_AVRCP_13_1 True General discoverable mode
> +TSPC_AVRCP_14_1 False OBEX Connect operation (C.1)
> +TSPC_AVRCP_14_2 False OBEX Get operation (C.1)
> +TSPC_AVRCP_14_3 False OBEX Disconnect operation (C.1)
> +TSPC_AVRCP_15_1 False OBEX Connect operation (C.1)
> +TSPC_AVRCP_15_2 False OBEX Get operation (C.1)
> +TSPC_AVRCP_15_3 False OBEX Disconnect operation (C.1)
> +
> +TSPC_ALL False Enables all test cases when set to TRUE.
> -------------------------------------------------------------------------------
> C.4: Mandatory to support if the device supports category 4 (TSPC_AVRCP_7_10).
> -------------------------------------------------------------------------------
> diff --git a/android/pixit-avrcp.txt b/android/pixit-avrcp.txt
> index 7ab5f18..f576bd0 100644
> --- a/android/pixit-avrcp.txt
> +++ b/android/pixit-avrcp.txt
> @@ -1,6 +1,6 @@
> AVRCP 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-avrcp.txt b/android/pts-avrcp.txt
> index c8663be..c8aeeca 100644
> --- a/android/pts-avrcp.txt
> +++ b/android/pts-avrcp.txt
> @@ -1,7 +1,7 @@
> PTS test results for AVRCP
>
> -PTS version: 5.2
> -Tested: 15-July-2014
> +PTS version: 5.3
> +Tested: 08-October-2014
> Android version: 4.4.4
>
> Results:
>
Patch applied. Thanks.
--
Best regards,
Szymon Janc
^ permalink raw reply
* Re: [PATCH bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Jukka Rissanen @ 2014-10-08 13:35 UTC (permalink / raw)
To: Martin Townsend; +Cc: linux-bluetooth, linux-wpan, marcel, alex.aring
In-Reply-To: <54353387.3070007@xsilon.com>
Hi Martin,
On ke, 2014-10-08 at 13:52 +0100, Martin Townsend wrote:
> Hi Jukka,
>
> I've misunderstood the constraints on pskb_expand_head. I don't suppose you could quickly try this patch it now uses skb_share_check to ensure skb->users == 1 and then I've put back in the skb_clone code that I took out which I think is causing the problem:
Tried this one and did not see any errors so far. I will leave my test
to run for the night. Please send a v4 and I will try to review it
tomorrow.
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 13:42 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: linux-bluetooth, linux-wpan, marcel, alex.aring
In-Reply-To: <1412775335.2705.31.camel@jrissane-mobl.ger.corp.intel.com>
hi Jukka,
Thank you for running all these tests for me, it's very much appreciated.
I'll send out v4 in a bit.
Cheers, Martin.
On 08/10/14 14:35, Jukka Rissanen wrote:
> Hi Martin,
>
> On ke, 2014-10-08 at 13:52 +0100, Martin Townsend wrote:
>> Hi Jukka,
>>
>> I've misunderstood the constraints on pskb_expand_head. I don't suppose you could quickly try this patch it now uses skb_share_check to ensure skb->users == 1 and then I've put back in the skb_clone code that I took out which I think is causing the problem:
> Tried this one and did not see any errors so far. I will leave my test
> to run for the night. Please send a v4 and I will try to review it
> tomorrow.
>
> Cheers,
> Jukka
>
>
^ permalink raw reply
* [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 13:46 UTC (permalink / raw)
To: linux-bluetooth, linux-wpan
Cc: marcel, alex.aring, jukka.rissanen, Martin Townsend
This patch aims to reduce the amount of copying in the receive path when
decompressing by checking for headroom and calling pskb_expand_head if required.
Another benefit of this is that the skb pointer passed to the decompression
routine will be the same skb after decompression. This will be a step towards
freeing the skb within the receive function and not within all the error paths
of the decompression routine.
Bluetooth and 802.15.4 have been changed to ensure that the skb isn't shared
before calling the decompression routine as this is a requirement of
pskb_expand_head.
v1 -> v2
Use const int for new headroom size.
Remove blank line.
Use skb_unshare instead of skb_copy_expand.
Use consume_skb.
v2 -> v3
Remove cases where we are trying to free a NULL skb.
v3 -> v4
Now uses skb_share_check to ensure the skb isn't shared before decompressing.
Martin Townsend (1):
6lowpan: Use pskb_expand_head in IPHC decompression.
net/6lowpan/iphc.c | 51 +++++++++++++++++++++----------------------
net/bluetooth/6lowpan.c | 7 ++++++
net/ieee802154/6lowpan_rtnl.c | 5 +++++
3 files changed, 37 insertions(+), 26 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 13:46 UTC (permalink / raw)
To: linux-bluetooth, linux-wpan
Cc: marcel, alex.aring, jukka.rissanen, Martin Townsend
In-Reply-To: <1412776015-372-1-git-send-email-martin.townsend@xsilon.com>
Currently there are potentially 2 skb_copy_expand calls in IPHC
decompression. This patch replaces this with one call to
pskb_expand_head. It also checks to see if there is enough headroom
first to ensure it's only done if necessary.
As pskb_expand_head must only have one reference the calling code
now ensures this.
Signed-off-by: Martin Townsend <martin.townsend@xsilon.com>
---
net/6lowpan/iphc.c | 51 +++++++++++++++++++++----------------------
net/bluetooth/6lowpan.c | 7 ++++++
net/ieee802154/6lowpan_rtnl.c | 5 +++++
3 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 142eef5..853b4b8 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -174,30 +174,22 @@ static int uncompress_context_based_src_addr(struct sk_buff *skb,
static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
struct net_device *dev, skb_delivery_cb deliver_skb)
{
- struct sk_buff *new;
int stat;
- new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
- GFP_ATOMIC);
- kfree_skb(skb);
-
- if (!new)
- return -ENOMEM;
-
- skb_push(new, sizeof(struct ipv6hdr));
- skb_reset_network_header(new);
- skb_copy_to_linear_data(new, hdr, sizeof(struct ipv6hdr));
+ skb_push(skb, sizeof(struct ipv6hdr));
+ skb_reset_network_header(skb);
+ skb_copy_to_linear_data(skb, hdr, sizeof(struct ipv6hdr));
- new->protocol = htons(ETH_P_IPV6);
- new->pkt_type = PACKET_HOST;
- new->dev = dev;
+ skb->protocol = htons(ETH_P_IPV6);
+ skb->pkt_type = PACKET_HOST;
+ skb->dev = dev;
raw_dump_table(__func__, "raw skb data dump before receiving",
- new->data, new->len);
+ skb->data, skb->len);
- stat = deliver_skb(new, dev);
+ stat = deliver_skb(skb, dev);
- kfree_skb(new);
+ consume_skb(skb);
return stat;
}
@@ -460,7 +452,7 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
/* UDP data uncompression */
if (iphc0 & LOWPAN_IPHC_NH_C) {
struct udphdr uh;
- struct sk_buff *new;
+ const int needed = sizeof(struct udphdr) + sizeof(hdr);
if (uncompress_udp_header(skb, &uh))
goto drop;
@@ -468,14 +460,13 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
/* replace the compressed UDP head by the uncompressed UDP
* header
*/
- new = skb_copy_expand(skb, sizeof(struct udphdr),
- skb_tailroom(skb), GFP_ATOMIC);
- kfree_skb(skb);
-
- if (!new)
- return -ENOMEM;
-
- skb = new;
+ if (skb_headroom(skb) < needed) {
+ err = pskb_expand_head(skb, needed, 0, GFP_ATOMIC);
+ if (unlikely(err)) {
+ kfree_skb(skb);
+ return err;
+ }
+ }
skb_push(skb, sizeof(struct udphdr));
skb_reset_transport_header(skb);
@@ -485,6 +476,14 @@ int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
(u8 *)&uh, sizeof(uh));
hdr.nexthdr = UIP_PROTO_UDP;
+ } else {
+ if (skb_headroom(skb) < sizeof(hdr)) {
+ err = pskb_expand_head(skb, sizeof(hdr), 0, GFP_ATOMIC);
+ if (unlikely(err)) {
+ kfree_skb(skb);
+ return err;
+ }
+ }
}
hdr.payload_len = htons(skb->len);
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index c2e0d14..6643a7c 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -343,6 +343,13 @@ static int recv_pkt(struct sk_buff *skb, struct net_device *dev,
kfree_skb(local_skb);
kfree_skb(skb);
} else {
+ /* Decompression may use pskb_expand_head so no shared skb's */
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb) {
+ dev->stats.rx_dropped++;
+ return NET_RX_DROP;
+ }
+
switch (skb->data[0] & 0xe0) {
case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
local_skb = skb_clone(skb, GFP_ATOMIC);
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index c7e07b8..702ad04 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -537,6 +537,11 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
if (ret == NET_RX_DROP)
goto drop;
} else {
+ /* Decompression may use pskb_expand_head so no shared skb's */
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (!skb)
+ goto drop;
+
switch (skb->data[0] & 0xe0) {
case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
ret = process_data(skb, &hdr);
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 5/6] obexd/messages: Add prototypes for MASInstance response
From: Gowtham Anandha Babu @ 2014-10-08 13:52 UTC (permalink / raw)
To: 'Luiz Augusto von Dentz'
Cc: linux-bluetooth, 'Dmitry Kasatkin',
'Bharat Panda', cpgs
In-Reply-To: <CABBYNZ+-AepnfRqmKxUhtTdfF_9-b0+mQfdNkLB+HBLhZe=c5Q@mail.gmail.com>
Hi,
> -----Original Message-----
> From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
> Sent: Wednesday, October 08, 2014 6:01 PM
> To: Gowtham Anandha Babu
> Cc: linux-bluetooth@vger.kernel.org; Dmitry Kasatkin; Bharat Panda;
> cpgs@samsung.com
> Subject: Re: [PATCH 5/6] obexd/messages: Add prototypes for MASInstance
> response
>
> Hi,
>
> On Wed, Oct 8, 2014 at 3:09 PM, Gowtham Anandha Babu
> <gowtham.ab@samsung.com> wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Luiz Augusto von Dentz [mailto:luiz.dentz@gmail.com]
> >> Sent: Wednesday, October 08, 2014 4:42 PM
> >> To: Gowtham Anandha Babu
> >> Cc: linux-bluetooth@vger.kernel.org; Dmitry Kasatkin; Bharat Panda;
> >> cpgs@samsung.com
> >> Subject: Re: [PATCH 5/6] obexd/messages: Add prototypes for
> >> MASInstance response
> >>
> >> Hi,
> >>
> >> On Tue, Oct 7, 2014 at 7:06 AM, Gowtham Anandha Babu
> >> <gowtham.ab@samsung.com> wrote:
> >> > ---
> >> > obexd/plugins/messages.h | 16 ++++++++++++++++
> >> > 1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/obexd/plugins/messages.h b/obexd/plugins/messages.h
> >> > index
> >> > 00a16b1..3aaeec1 100644
> >> > --- a/obexd/plugins/messages.h
> >> > +++ b/obexd/plugins/messages.h
> >> > @@ -307,3 +307,19 @@ int messages_set_delete(void *session, const
> >> > char
> >> *handle, uint8_t value,
> >> > * session: Backend session.
> >> > */
> >> > void messages_abort(void *session);
> >> > +
> >> > +
> >> > +
> >> > +/* Retrieves MAS Instance Information for the given mas-instance id.
> >> > + *
> >> > + * session: Backend session.
> >> > + * mas_id: MAS Instance id requested by the MCE.
> >> > + *
> >> > + * Callback shall be called for every mas_instance_id request
> >> > +received
> >> from MCE.
> >> > + */
> >> > +typedef void (*messages_mas_instance_info_cb)(void *session, int
> err,
> >> > + uint16_t size, const char *name, void *user_data);
> >> > +
> >> > +int messages_get_mas_instance_info(void *session, uint16_t
> >> mas_instance_id,
> >> > + messages_mas_instance_info_cb callback,
> >> > + void *user_data);
> >> > --
> >> > 1.9.1
> >>
> >> You can drop using mas here since it is pretty obvious what it is
> >> for, also Im not sure we need the size in the callback since we can use
> strlen there.
> >>
> >>
> >> --
> >> Luiz Augusto von Dentz
> >
> > I agree with you. I will update this comment for the patch[6/6] too. I will
> include this in v2. Still is there anything to be handled?
>
> Start with the server side, I will be working on the client side to add support
> for multiple instances, I have something already it just need some polishing.
>
> --
> Luiz Augusto von Dentz
I think not much implementation in server side is needed.
No features are using the instance id in server side except this patch set. But can be added as below:
1)Define no_of_mas_instance (assign no of instances if it supports or '0')
2)While MCE discovering for MAS service, advertise all mas id's(if it supports more than one)
3) While mas_connect(), need to look match for which mas_id the MCE requesting
4) Folder ordering for multiple MAS instance is needed as you suggested. Like
MAS 1/telecom/...
MAS 2/telecom/...
Once the client part is known, we can implement that accordingly.
Meanwhile is this patch set good to go?
Regards,
Gowtham Anandha Babu
^ permalink raw reply
* Re: [PATCH v2 1/4] android/tester: Add Gatt Write Descriptor Success
From: Szymon Janc @ 2014-10-08 13:58 UTC (permalink / raw)
To: Mariusz Skamra; +Cc: linux-bluetooth
In-Reply-To: <1412605729-21818-1-git-send-email-mariusz.skamra@tieto.com>
Hi Mariusz,
On Monday 06 of October 2014 16:28:46 Mariusz Skamra wrote:
> Write descriptor value test case.
> ---
> android/tester-gatt.c | 108 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/android/tester-gatt.c b/android/tester-gatt.c
> index 6827995..1f479e1 100644
> --- a/android/tester-gatt.c
> +++ b/android/tester-gatt.c
> @@ -102,6 +102,17 @@ struct write_char_data {
> char *p_value;
> };
>
> +struct write_desc_data {
> + int conn_id;
> + btgatt_srvc_id_t *service;
> + btgatt_gatt_id_t *characteristic;
> + btgatt_gatt_id_t *descriptor;
> + int write_type;
> + int len;
> + int auth_req;
> + char *p_value;
> +};
> +
> struct notif_data {
> int conn_id;
> const bt_bdaddr_t *bdaddr;
> @@ -297,6 +308,17 @@ static struct write_char_data write_char_data_2 = {
> .auth_req = 0
> };
>
> +static struct write_desc_data write_desc_data_1 = {
> + .conn_id = CONN1_ID,
> + .service = &service_1,
> + .characteristic = &characteristic_1,
> + .descriptor = &desc_1,
> + .write_type = 2,
> + .len = sizeof(value_2),
> + .auth_req = 0,
> + .p_value = value_2,
> +};
> +
> static struct notif_data notif_data_1 = {
> .conn_id = CONN1_ID,
> .service = &service_1,
> @@ -405,6 +427,14 @@ static struct set_write_params set_write_param_3 = {
> .status = 0x01
> };
>
> +static struct set_write_params set_write_param_4 = {
> + .params = &write_params_1,
> + .srvc_id = &service_1,
> + .char_id = &characteristic_1,
> + .descr_id = &desc_1,
> + .status = BT_STATUS_SUCCESS
> +};
> +
> static struct set_notify_params set_notify_param_1 = {
> .params = ¬ify_params_1,
> .value = value_1,
> @@ -649,6 +679,24 @@ static struct iovec write_characteristic_3[] = {
> end_pdu
> };
>
> +static struct iovec write_descriptor_1[] = {
> + raw_pdu(0x10, 0x01, 0x00, 0xff, 0xff, 0x00, 0x28),
> + raw_pdu(0x11, 0x06, 0x01, 0x00, 0x10, 0x00, 0x00, 0x18),
> + raw_pdu(0x10, 0x11, 0x00, 0xff, 0xff, 0x00, 0x28),
> + raw_pdu(0x01, 0x11, 0x11, 0x00, 0x0a),
> + raw_pdu(0x08, 0x01, 0x00, 0x10, 0x00, 0x03, 0x28),
> + raw_pdu(0x09, 0x07, 0x02, 0x00, 0x04, 0x00, 0x00, 0x19, 0x00),
> + raw_pdu(0x08, 0x03, 0x00, 0x10, 0x00, 0x03, 0x28),
> + raw_pdu(0x01, 0x08, 0x03, 0x00, 0x0a),
> + raw_pdu(0x04, 0x01, 0x00, 0x10, 0x00),
> + raw_pdu(0x05, 0x01, 0x04, 0x00, 0x00, 0x29),
> + raw_pdu(0x04, 0x05, 0x00, 0x10, 0x00),
> + raw_pdu(0x01, 0x04, 0x05, 0x00, 0x0a),
> + raw_pdu(0x12, 0x04, 0x00, 0x00, 0x01, 0x02, 0x03),
> + raw_pdu(0x13),
> + end_pdu
> +};
> +
> static struct iovec notification_1[] = {
> raw_pdu(0x10, 0x01, 0x00, 0xff, 0xff, 0x00, 0x28),
> raw_pdu(0x11, 0x06, 0x01, 0x00, 0x10, 0x00, 0x00, 0x18),
> @@ -1003,6 +1051,29 @@ static void gatt_server_disconnect_action(void)
> schedule_action_verification(step);
> }
>
> +static void gatt_client_write_descriptor_action(void)
> +{
> + struct test_data *data = tester_get_data();
> + struct step *current_data_step = queue_peek_head(data->steps);
> + struct write_desc_data *write_desc_data = current_data_step->set_data;
> + const btgatt_client_interface_t *client = data->if_gatt->client;
> + struct step *step = g_new0(struct step, 1);
> + int status;
> +
> + status = client->write_descriptor(write_desc_data->conn_id,
> + write_desc_data->service,
> + write_desc_data->characteristic,
> + write_desc_data->descriptor,
> + write_desc_data->write_type,
> + write_desc_data->len,
> + write_desc_data->auth_req,
> + write_desc_data->p_value);
> +
> + step->action_status = status;
> +
> + schedule_action_verification(step);
> +}
> +
> static void gatt_cid_hook_cb(const void *data, uint16_t len, void *user_data)
> {
> struct test_data *t_data = tester_get_data();
> @@ -2180,7 +2251,42 @@ static struct test_case test_cases[] = {
> ACTION_SUCCESS(bluetooth_disable_action, NULL),
> CALLBACK_STATE(CB_BT_ADAPTER_STATE_CHANGED, BT_STATE_OFF),
> ),
> -
> + TEST_CASE_BREDRLE("Gatt Client - Write Descriptor - Success",
> + ACTION_SUCCESS(init_pdus, write_descriptor_1),
> + ACTION_SUCCESS(bluetooth_enable_action, NULL),
> + CALLBACK_STATE(CB_BT_ADAPTER_STATE_CHANGED, BT_STATE_ON),
> + ACTION_SUCCESS(init_write_params_action, &set_write_param_4),
> + ACTION_SUCCESS(emu_setup_powered_remote_action, NULL),
> + ACTION_SUCCESS(emu_set_ssp_mode_action, NULL),
> + ACTION_SUCCESS(emu_set_connect_cb_action, gatt_conn_cb),
> + ACTION_SUCCESS(gatt_client_register_action, &app1_uuid),
> + CALLBACK_STATUS(CB_GATTC_REGISTER_CLIENT, BT_STATUS_SUCCESS),
> + ACTION_SUCCESS(gatt_client_start_scan_action,
> + INT_TO_PTR(APP1_ID)),
> + CLLBACK_GATTC_SCAN_RES(prop_emu_remotes_default_set, 1, TRUE),
> + ACTION_SUCCESS(gatt_client_stop_scan_action,
> + INT_TO_PTR(APP1_ID)),
> + ACTION_SUCCESS(gatt_client_connect_action, &app1_conn_req),
> + CALLBACK_GATTC_CONNECT(GATT_STATUS_SUCCESS,
> + prop_emu_remotes_default_set,
> + CONN1_ID, APP1_ID),
> + ACTION_SUCCESS(gatt_client_search_services, &search_services_1),
> + CALLBACK_GATTC_SEARCH_COMPLETE(GATT_STATUS_SUCCESS, CONN1_ID),
> + ACTION_SUCCESS(gatt_client_get_characteristic_action,
> + &get_char_data_1),
> + CALLBACK_GATTC_GET_CHARACTERISTIC_CB(GATT_STATUS_SUCCESS,
> + CONN1_ID, &service_1, &characteristic_1, 4),
> + ACTION_SUCCESS(gatt_client_get_descriptor_action,
> + &get_desc_data_1),
> + CALLBACK_GATTC_GET_DESCRIPTOR(GATT_STATUS_SUCCESS, CONN1_ID,
> + &service_1, &characteristic_1, &desc_1),
> + ACTION_SUCCESS(gatt_client_write_descriptor_action,
> + &write_desc_data_1),
> + CALLBACK_GATTC_WRITE_DESCRIPTOR(GATT_STATUS_SUCCESS,
> + CONN1_ID, &write_params_1),
> + ACTION_SUCCESS(bluetooth_disable_action, NULL),
> + CALLBACK_STATE(CB_BT_ADAPTER_STATE_CHANGED, BT_STATE_OFF),
> + ),
> TEST_CASE_BREDRLE("Gatt Server - Register",
> ACTION_SUCCESS(gatt_server_register_action, &app1_uuid),
> CALLBACK_STATUS(CB_GATTS_REGISTER_SERVER, BT_STATUS_SUCCESS),
>
All patches applied. Thanks.
--
Best regards,
Szymon Janc
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Naveen Kumar Parna @ 2014-10-08 14:10 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-bluetooth@vger.kernel.org, linux-usb, acho
In-Reply-To: <1412774247.1629.4.camel@linux-0dmf.site>
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.
Is it enabling dynamic debugging?
Could you please point me the steps to enable debugging in USB HC driver?
Thanks,
Naveen
On Wed, Oct 8, 2014 at 6:47 PM, Oliver Neukum <oneukum@suse.de> wrote:
> On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote:
>> Later connected third device(hci2) and after 2mins observed –EPIPE for
>> hci2(hci2 urb ffff880124f11cc0 status -32 count 0)
>
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.
>
> Regards
> Oliver
>
>
^ permalink raw reply
* Re: [PATCH] Monitor: Add AVRCP PASS THROUGH command support
From: Luiz Augusto von Dentz @ 2014-10-08 14:24 UTC (permalink / raw)
To: Vikrampal Yadav; +Cc: linux-bluetooth@vger.kernel.org, Dmitry Kasatkin, cpgs
In-Reply-To: <1412676351-29503-1-git-send-email-vikram.pal@samsung.com>
Hi Vikram,
On Tue, Oct 7, 2014 at 1:05 PM, Vikrampal Yadav <vikram.pal@samsung.com> wrote:
> Support for decoding AVRCP PASS THROUGH command added in Bluetooth
> monitor.
> ---
> monitor/avctp.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/monitor/avctp.c b/monitor/avctp.c
> index 9de46d1..a4e34c5 100644
> --- a/monitor/avctp.c
> +++ b/monitor/avctp.c
> @@ -182,6 +182,20 @@
> #define AVRCP_MEDIA_SEARCH 0x02
> #define AVRCP_MEDIA_NOW_PLAYING 0x03
>
> +/* operands in passthrough commands */
> +#define AVC_PANEL_VOLUME_UP 0x41
> +#define AVC_PANEL_VOLUME_DOWN 0x42
> +#define AVC_PANEL_MUTE 0x43
> +#define AVC_PANEL_PLAY 0x44
> +#define AVC_PANEL_STOP 0x45
> +#define AVC_PANEL_PAUSE 0x46
> +#define AVC_PANEL_RECORD 0x47
> +#define AVC_PANEL_REWIND 0x48
> +#define AVC_PANEL_FAST_FORWARD 0x49
> +#define AVC_PANEL_EJECT 0x4a
> +#define AVC_PANEL_FORWARD 0x4b
> +#define AVC_PANEL_BACKWARD 0x4c
> +
> struct avctp_frame {
> uint8_t hdr;
> uint8_t pt;
> @@ -631,9 +645,54 @@ static const char *scope2str(uint8_t scope)
> }
> }
>
> -static bool avrcp_passthrough_packet(struct avctp_frame *avctp_frame)
> +static char *op2str(uint8_t op)
> +{
> + switch (op & 0x7f) {
> + case AVC_PANEL_VOLUME_UP:
> + return "VOLUME UP";
> + case AVC_PANEL_VOLUME_DOWN:
> + return "VOLUME DOWN";
> + case AVC_PANEL_MUTE:
> + return "MUTE";
> + case AVC_PANEL_PLAY:
> + return "PLAY";
> + case AVC_PANEL_STOP:
> + return "STOP";
> + case AVC_PANEL_PAUSE:
> + return "PAUSE";
> + case AVC_PANEL_RECORD:
> + return "RECORD";
> + case AVC_PANEL_REWIND:
> + return "REWIND";
> + case AVC_PANEL_FAST_FORWARD:
> + return "FAST FORWARD";
> + case AVC_PANEL_EJECT:
> + return "EJECT";
> + case AVC_PANEL_FORWARD:
> + return "FORWARD";
> + case AVC_PANEL_BACKWARD:
> + return "BACKWARD";
> + default:
> + return "UNKNOWN";
> + }
> +}
> +
> +static bool avrcp_passthrough_packet(struct avctp_frame *avctp_frame,
> + uint8_t indent)
> {
> struct l2cap_frame *frame = &avctp_frame->l2cap_frame;
> + uint8_t op, len;
> +
> + if (!l2cap_frame_get_u8(frame, &op))
> + return false;
> +
> + print_field("%*cOperation: 0x%02x (%s %s)", (indent - 2), ' ', op,
> + op2str(op), op & 0x80 ? "Released" : "Pressed");
> +
> + if (!l2cap_frame_get_u8(frame, &len))
> + return false;
> +
> + print_field("%*cLength: 0x%02x", (indent - 2), ' ', len);
>
> packet_hexdump(frame->data, frame->size);
> return true;
> @@ -1555,7 +1614,7 @@ static bool avrcp_control_packet(struct avctp_frame *avctp_frame)
>
> switch (opcode) {
> case 0x7c:
> - return avrcp_passthrough_packet(avctp_frame);
> + return avrcp_passthrough_packet(avctp_frame, 10);
> case 0x00:
> if (!l2cap_frame_get_u8(frame, &company[0]) ||
> !l2cap_frame_get_u8(frame, &company[1]) ||
> --
> 1.9.1
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: btusb_intr_complete returns -EPIPE
From: Alan Stern @ 2014-10-08 14:46 UTC (permalink / raw)
To: Oliver Neukum
Cc: Naveen Kumar Parna, linux-bluetooth@vger.kernel.org, linux-usb,
acho
In-Reply-To: <1412774247.1629.4.camel@linux-0dmf.site>
On Wed, 8 Oct 2014, Oliver Neukum wrote:
> On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote:
> > Later connected third device(hci2) and after 2mins observed –EPIPE for
> > hci2(hci2 urb ffff880124f11cc0 status -32 count 0)
>
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.
It could also be a bug in the hub that the BT devices are plugged into.
I have seen a report of a hub that sends STALL when a bunch of devices
are plugged in, even though the devices themselves did not send a
STALL.
Alan Stern
^ permalink raw reply
* [PATCH] Bluetooth: HCI H5 peer reset detection
From: Loic Poulain @ 2014-10-08 14:54 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: linux-bluetooth, Loic Poulain
H5 Specification says:
If a SYNC message is received while in the Active State, it is
assumed that the peer device has reset. The local device should
therefore perform a full reset of the upper stack, and start Link
Establishment again at the Uninitialized State. Upon entering the
Active State, the first packet sent shall have its SEQ and ACK
numbers set to zero.
This patch resets the HCI H5 driver data/state to unitialized and
reports an HCI hardware error event to notify the upper stack that
HCI synchronization has been lost. H5 will be re-synchronized and
upper stack should generate an HCI Reset command.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
---
drivers/bluetooth/hci_h5.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index caacb42..5c5e9ac 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -168,6 +168,36 @@ wakeup:
hci_uart_tx_wakeup(hu);
}
+static void h5_peer_reset(struct hci_uart *hu)
+{
+ struct h5 *h5 = hu->priv;
+ struct sk_buff *skb;
+ const unsigned char hard_err[] = { 0x10, 0x01, 0x00 };
+
+ BT_ERR("Peer device has reset");
+
+ h5->state = H5_UNINITIALIZED;
+
+ del_timer(&h5->timer);
+
+ skb_queue_purge(&h5->rel);
+ skb_queue_purge(&h5->unrel);
+ skb_queue_purge(&h5->unack);
+
+ h5->tx_seq = 0;
+ h5->tx_ack = 0;
+
+ skb = bt_skb_alloc(3, GFP_ATOMIC);
+ if (!skb)
+ return;
+
+ bt_cb(skb)->pkt_type = HCI_EVENT_PKT;
+ memcpy(skb_put(skb, 3), hard_err, 3);
+
+ /* Send Hardware Error to upper stack */
+ hci_recv_frame(hu->hdev, skb);
+}
+
static int h5_open(struct hci_uart *hu)
{
struct h5 *h5;
@@ -283,8 +313,12 @@ static void h5_handle_internal_rx(struct hci_uart *hu)
conf_req[2] = h5_cfg_field(h5);
if (memcmp(data, sync_req, 2) == 0) {
+ if (h5->state == H5_ACTIVE)
+ h5_peer_reset(hu);
h5_link_control(hu, sync_rsp, 2);
} else if (memcmp(data, sync_rsp, 2) == 0) {
+ if (h5->state == H5_ACTIVE)
+ h5_peer_reset(hu);
h5->state = H5_INITIALIZED;
h5_link_control(hu, conf_req, 3);
} else if (memcmp(data, conf_req, 2) == 0) {
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Alexander Aring @ 2014-10-08 14:59 UTC (permalink / raw)
To: Martin Townsend
Cc: linux-bluetooth, linux-wpan, marcel, jukka.rissanen,
Martin Townsend
In-Reply-To: <1412776015-372-2-git-send-email-martin.townsend@xsilon.com>
Hi Martin,
On Wed, Oct 08, 2014 at 02:46:55PM +0100, Martin Townsend wrote:
> Currently there are potentially 2 skb_copy_expand calls in IPHC
> decompression. This patch replaces this with one call to
> pskb_expand_head. It also checks to see if there is enough headroom
> first to ensure it's only done if necessary.
> As pskb_expand_head must only have one reference the calling code
> now ensures this.
>
> Signed-off-by: Martin Townsend <martin.townsend@xsilon.com>
...
> --- a/net/ieee802154/6lowpan_rtnl.c
> +++ b/net/ieee802154/6lowpan_rtnl.c
> @@ -537,6 +537,11 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
> if (ret == NET_RX_DROP)
> goto drop;
> } else {
> + /* Decompression may use pskb_expand_head so no shared skb's */
> + skb = skb_share_check(skb, GFP_ATOMIC);
> + if (!skb)
> + goto drop;
> +
We do this already at [0], is it really necessary do it here again?
This ensures that 6lowpan header replacing doesn't affect the af_802154
implementation.
- Alex
[0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L466
^ permalink raw reply
* Re: [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 15:09 UTC (permalink / raw)
To: Alexander Aring, Martin Townsend
Cc: linux-bluetooth, linux-wpan, marcel, jukka.rissanen
In-Reply-To: <20141008145917.GA23456@omega>
Hi Alex,
I completely missed it, unless reassembly can result in a shared skb? can you confirm that it doesn't then I'll remove the line.
Thanks, Martin.
On 08/10/14 15:59, Alexander Aring wrote:
> Hi Martin,
>
> On Wed, Oct 08, 2014 at 02:46:55PM +0100, Martin Townsend wrote:
>> Currently there are potentially 2 skb_copy_expand calls in IPHC
>> decompression. This patch replaces this with one call to
>> pskb_expand_head. It also checks to see if there is enough headroom
>> first to ensure it's only done if necessary.
>> As pskb_expand_head must only have one reference the calling code
>> now ensures this.
>>
>> Signed-off-by: Martin Townsend <martin.townsend@xsilon.com>
> ...
>> --- a/net/ieee802154/6lowpan_rtnl.c
>> +++ b/net/ieee802154/6lowpan_rtnl.c
>> @@ -537,6 +537,11 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
>> if (ret == NET_RX_DROP)
>> goto drop;
>> } else {
>> + /* Decompression may use pskb_expand_head so no shared skb's */
>> + skb = skb_share_check(skb, GFP_ATOMIC);
>> + if (!skb)
>> + goto drop;
>> +
> We do this already at [0], is it really necessary do it here again?
>
> This ensures that 6lowpan header replacing doesn't affect the af_802154
> implementation.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L466
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH BlueZ v1 0/5] Introduce shared/gatt-server.
From: Arman Uguray @ 2014-10-08 15:14 UTC (permalink / raw)
To: Arman Uguray; +Cc: BlueZ development
In-Reply-To: <1412629304-3391-1-git-send-email-armansito@chromium.org>
On Mon, Oct 6, 2014 at 5:01 PM, Arman Uguray <armansito@chromium.org> wrote:
> *v1:
> - Make gatt-db external to gatt-server, as initially discussed.
> - Also implement Read By Group Type request.
>
> Arman Uguray (5):
> Revert "plugins/sixaxis: Add a set_leds_sysfs() function"
> shared/att: Drop the connection is a request is received while one is
> pending.
> shared/gatt-server: Introduce shared/gatt-server.
> shared/gatt-server: Support Exchange MTU request.
> shared/gatt-server: Support Read By Group Type request.
>
> Makefile.am | 1 +
> configure.ac | 4 +-
> plugins/sixaxis.c | 89 +-----------
> src/shared/att.c | 101 ++++++++------
> src/shared/gatt-server.c | 347 +++++++++++++++++++++++++++++++++++++++++++++++
> src/shared/gatt-server.h | 40 ++++++
> 6 files changed, 455 insertions(+), 127 deletions(-)
> create mode 100644 src/shared/gatt-server.c
> create mode 100644 src/shared/gatt-server.h
>
> --
> 2.1.0.rc2.206.gedb03e5
>
ping.
Also ignore the bit about 'Revert "plugins/sixaxis: Add a
set_leds_sysfs() function"'. I revert it locally since it gives me
some dependency issues when compiling for Chromium OS; it's not part
of the patch set I uploaded.
Cheers,
Arman
^ permalink raw reply
* Re: [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Alexander Aring @ 2014-10-08 15:27 UTC (permalink / raw)
To: Martin Townsend
Cc: Martin Townsend, linux-bluetooth, linux-wpan, marcel,
jukka.rissanen
In-Reply-To: <543553AD.9000501@xsilon.com>
On Wed, Oct 08, 2014 at 04:09:33PM +0100, Martin Townsend wrote:
> Hi Alex,
>
> I completely missed it, unless reassembly can result in a shared skb? can you confirm that it doesn't then I'll remove the line.
>
No, we manipulate the skb data there. We fetch the fragment header.
See [0].
This require a unshared buffer between af_802154 and 6lowpan. Also on
LOWPAN_DISPATCH_IPV6 we fetch the one byte dispatch value.
- Alex
[0] http://lxr.free-electrons.com/source/net/ieee802154/reassembly.c#L328
^ permalink raw reply
* Re: [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Martin Townsend @ 2014-10-08 15:30 UTC (permalink / raw)
To: Alexander Aring
Cc: Martin Townsend, linux-bluetooth, linux-wpan, marcel,
jukka.rissanen
In-Reply-To: <20141008152750.GB23456@omega>
Hi Alex,
I'll wait for Jukka's ack for the bluetooth side and then send v5 with the removed skb_share_check.
- Martin.
On 08/10/14 16:27, Alexander Aring wrote:
> On Wed, Oct 08, 2014 at 04:09:33PM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> I completely missed it, unless reassembly can result in a shared skb? can you confirm that it doesn't then I'll remove the line.
>>
> No, we manipulate the skb data there. We fetch the fragment header.
> See [0].
>
> This require a unshared buffer between af_802154 and 6lowpan. Also on
> LOWPAN_DISPATCH_IPV6 we fetch the one byte dispatch value.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/ieee802154/reassembly.c#L328
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add HCI_AUTO_CONN_DIRECT_REPORT_IND
From: Alfonso Acosta @ 2014-10-09 1:01 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ development
In-Reply-To: <35741970-1ED7-4A2B-8625-4F16186FA764@holtmann.org>
Hi Marcel,
> what sounds most simple to me is that we allow for a way to suspend and later resume the trigger for doing service discovery. Attaching the attribute channel is fine, but then essentially tell it to stay put.
>
> This all becomes tricky and we might need to have some redesign and cleanups to do to make this work cleanly. We also long term want to switch to the newly designed gatt-client.c that we are working on. So something to keep in mind.
>
> However one thing has to present and that is our GATT server. So even if we stall everything else and even if we drop the keys and unpair, the GATT server needs to be operational. So we need to attach the ATT protocol to the ATT socket that we are getting from the kernel on every single connection.
Thanks. Using your suggestion I am suspending the trigger for doing
service discovery until rebonding is completed. As expected, without
the connection re-establishment, rebonding is now considerably faster.
I, however, have to keep the ATT socket around until resuming the
service discovery, which is a bit dirty. But I guess I can live with
that until the new gatt-client is in.
Thanks again,
Fons
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
^ permalink raw reply
* RE: [PATCH v4 1/3] shared/att.c: Add signed command outgoing and CSRK function
From: Gu, Chao Jie @ 2014-10-09 4:02 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZ+NW=1aW6_sMppq2kU4FUou0pK5DhHQ7ykhUFkf4dCCsw@mail.gmail.com>
SGkgTHVpeiwNCg0KPiA+IEBAIC03Nyw2ICs3OCwxNiBAQCBzdHJ1Y3QgYnRfYXR0IHsNCj4gPiAg
ICAgICAgIGJ0X2F0dF9kZWJ1Z19mdW5jX3QgZGVidWdfY2FsbGJhY2s7DQo+ID4gICAgICAgICBi
dF9hdHRfZGVzdHJveV9mdW5jX3QgZGVidWdfZGVzdHJveTsNCj4gPiAgICAgICAgIHZvaWQgKmRl
YnVnX2RhdGE7DQo+ID4gKw0KPiA+ICsgICAgICAgc3RydWN0IGJ0X2NyeXB0byAqY3J5cHRvOw0K
PiA+ICsNCj4gPiArICAgICAgIGJvb2wgdmFsaWRfbG9jYWxfY3NyazsNCj4gPiArICAgICAgIHVp
bnQ4X3QgbG9jYWxfY3Nya1sxNl07DQo+ID4gKyAgICAgICB1aW50MzJfdCBsb2NhbF9zaWduX2Nu
dDsNCj4gPiArDQo+ID4gKyAgICAgICBib29sIHZhbGlkX3JlbW90ZV9jc3JrOw0KPiA+ICsgICAg
ICAgdWludDhfdCByZW1vdGVfY3Nya1sxNl07DQo+ID4gKyAgICAgICB1aW50MzJfdCByZW1vdGVf
c2lnbl9jbnQ7DQo+IA0KPiBNYXliZSBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBwb2ludGVycyB0byBh
IHN0cnVjdHMgc28geW91IGNhbiBmcmVlIHRoZSBkYXRhIG9uY2UgaXQNCj4gYmVjb21lcyBpbnZh
bGlkIGFuZCBpdCBhbHNvIHJlbW92ZXMgdGhlIG5lY2Vzc2l0eSBvZiBleHRyYSBmbGFncyBqdXN0
IHRvIHRlbGwgaWYgdGhlIGRhdGENCj4gaXMgc3RpbGwgdmFsaWQgc2luY2UgeW91IGNhbiBjaGVj
ayBpZiB0aGUgcG9pbnRlciBpcyBub3QgTlVMTCB0aGVuIGl0IG11c3QgYmUgdmFsaWQuDQoNClRo
aXMgaXMgZ29vZCBpZGVhIHRvIHJlbW92ZSB0aGUgZXh0cmEgZmxhZ3MuIEhvd2V2ZXIsIHdlIGRl
ZmluZSB0aGUgc3RydWN0IHRvIGRvIHRoaXMgd2hpY2gNCndvdWxkIHJlc3VsdCBpbiBzb21lIHBy
b2JsZW0uIE5vdyB3ZSBpbml0aWFsaXplIHRoZSBsb2NhbF9zaWduX2NudCBpbiB0aGUgYnRfYXR0
X25ldyBmdW5jdGlvbg0KYW5kIG9ubHkgYWRkIGxvY2FsX3NpZ25fY250IHZhbHVlIHdoZW4gc2ln
bmVkIHdyaXRlIGNvbW1hbmQgb3V0Z29pbmcuIE1lYW53aWxlLCB3ZSBzZXQgbG9jYWwNCkNTUksg
aW4gdGhlIGJ0X2dhdHRfY2xpZW50X3NldF9sb2NhbF9jc3JrIGZ1bmN0aW9uIHdoZW4gdGhlcmUg
aXMgdmFsaWQgQ1NSSyBwcm92aWRlZC4gVGhpcyB0d28NClBhcmFtZXRlciBzZXQgYXQgZGlmZmVy
ZW50IHRpbWUgbm93Lg0KDQpJZiB3ZSBoYXZlIHBvaW50ZXJzIHRvIGEgc3RydWN0IGluY2x1ZGlu
ZyBsb2NhbF9jc3JrIGFuZCBsb2NhbF9zaWduZF9jbnQsIHdlIGluaXRpYWxpemUgdGhlIGxvY2Fs
X3NpZ25fY250IA0KbWVhbndoaWxlIHRoZSBzdHJ1Y3Qgc2hvdWxkIG5vdCBiZSBOVUxMIGJlY2F1
c2Ugb2YgaW5jdWRpbmcgaXQuIEluIGZhY3QsIGxvY2FsX2NzcmsgaXMgbm90IHZhbGlkIGF0IHRo
aXMgdGltZS4NCklmIHdlIGluaXRpYWxpemUgdGhlIGxvY2FsX3NpZ25lZF9jbnQgd2hlbiBDU1JL
IGlzIHZhbGlkICwgaXQgd291bGQgYmUgcmlzayB0byBjaGFuZ2UgbG9jYWxfc2lnbmVkX2NudCBi
eSB1c2VyDQpjYWxsaW5nIGJ0X2dhdHRfY2xpZW50X3NldF9sb2NhbF9jc3JrLg0KPiA+ICB9Ow0K
PiA+DQo+ID4gIGVudW0gYXR0X29wX3R5cGUgew0KPiA+IEBAIC0xNzYsNiArMTg3LDggQEAgc3Ry
dWN0IGF0dF9zZW5kX29wIHsNCj4gPiAgICAgICAgIGJ0X2F0dF9yZXNwb25zZV9mdW5jX3QgY2Fs
bGJhY2s7DQo+ID4gICAgICAgICBidF9hdHRfZGVzdHJveV9mdW5jX3QgZGVzdHJveTsNCj4gPiAg
ICAgICAgIHZvaWQgKnVzZXJfZGF0YTsNCj4gPiArDQo+ID4gKyAgICAgICBzdHJ1Y3QgYnRfYXR0
ICphdHQ7DQo+ID4gIH07DQo+ID4NCj4gPiAgc3RhdGljIHZvaWQgZGVzdHJveV9hdHRfc2VuZF9v
cCh2b2lkICpkYXRhKSBAQCAtMjc3LDYgKzI5MCwxMCBAQA0KPiA+IHN0YXRpYyBib29sIGVuY29k
ZV9wZHUoc3RydWN0IGF0dF9zZW5kX29wICpvcCwgY29uc3Qgdm9pZCAqcGR1LA0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IGxlbmd0
aCwNCj4gPiB1aW50MTZfdCBtdHUpICB7DQo+ID4gICAgICAgICB1aW50MTZfdCBwZHVfbGVuID0g
MTsNCj4gPiArICAgICAgIHN0cnVjdCBidF9hdHQgKmF0dCA9IG9wLT5hdHQ7DQo+ID4gKw0KPiA+
ICsgICAgICAgaWYgKG9wLT5vcGNvZGUgJiBBVFRfT1BfU0lHTkVEX01BU0spDQo+ID4gKyAgICAg
ICAgICAgICAgIHBkdV9sZW4gKz0gQlRfQVRUX1NJR05BVFVSRV9MRU47DQo+ID4NCj4gPiAgICAg
ICAgIGlmIChsZW5ndGggJiYgcGR1KQ0KPiA+ICAgICAgICAgICAgICAgICBwZHVfbGVuICs9IGxl
bmd0aDsNCj4gPiBAQCAtMjkzLDE3ICszMTAsMzIgQEAgc3RhdGljIGJvb2wgZW5jb2RlX3BkdShz
dHJ1Y3QgYXR0X3NlbmRfb3AgKm9wLCBjb25zdA0KPiB2b2lkICpwZHUsDQo+ID4gICAgICAgICBp
ZiAocGR1X2xlbiA+IDEpDQo+ID4gICAgICAgICAgICAgICAgIG1lbWNweShvcC0+cGR1ICsgMSwg
cGR1LCBsZW5ndGgpOw0KPiA+DQo+ID4gKyAgICAgICBpZiAob3AtPm9wY29kZSAmIEFUVF9PUF9T
SUdORURfTUFTSykgew0KPiA+ICsgICAgICAgICAgICAgICBpZiAoYnRfY3J5cHRvX3NpZ25fYXR0
KGF0dC0+Y3J5cHRvLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhdHQtPmxvY2FsX2NzcmssDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG9wLT5wZHUsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDEgKyBsZW5ndGgsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGF0dC0+bG9jYWxfc2lnbl9jbnQsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICYoKHVpbnQ4X3QgKikgb3AtPnBkdSlbMSArDQo+IGxlbmd0aF0pKQ0KPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgIGF0dC0+bG9jYWxfc2lnbl9jbnQrKzsNCj4gPiArICAg
ICAgICAgICAgICAgZWxzZQ0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBmYWxz
ZTsNCj4gPiArICAgICAgIH0NCj4gPiArDQo+IA0KPiBZb3UgY2FuIHByb2JhYmx5IGJhaWwgb3V0
IGVhcmx5IGlmIHlvdSBjaGVjayAhKG9wLT5vcGNvZGUgJiBBVFRfT1BfU0lHTkVEX01BU0spLA0K
PiBhbHNvIHBlcmhhcHMgaXQgaXMgYSBnb29kIGlkZWEgdG8gc3RhcnQgZGVmaW5pbmcgc3RydWN0
cyBmb3IgdGhlIFBEVXMgdG8gc2ltcGxpZnkgdGhlDQo+IGFjY2Vzcy4NCj4gDQpJZiB3ZSBiYWls
IG91dCB0aGlzIGNoZWNraW5nIGVhcmx5ICwgbWF5YmUgd2UgaGF2ZSB0byBuZWVkIHR3byBkaWZm
ZXJlbnQgZW5jb2RlX3BkdQ0KZnVuY3Rpb24gdG8gaW1wbGVtZW50IGl0IHN1Y2ggYXMgbmFtaW5n
IG5ldyBlbmNvZGVfc2lnbmVkX3BkdSBmdW5jdGlvbiB0byBkbyB0aGlzLg0KDQpIb3dldmVyLCBJ
IHRoaW5rIGVuY29kaW5nIHNpZ25lZF93cml0ZV9jb21tYW5kIHBkdSBtb3N0IGRpZmZlcmVuY2Ug
aXMgYWRkaW5nIA0Kc2lnbmF0Z3VyZSBpbiB0aGUgZW5kIG9mIHBkdS4gQXMgb2xkIHN0YWNrLCB3
ZSBjYW4gc2VlIGV2ZXJ5IGNvbW1hbmQgaGFzIHRoZWlyIA0Kb3duIGVuY29kZV9wZHUgZnVuY3Rp
b24uIEluIGZhY3QsIG1vc3QgcHJvY2VkdXJlIGlzIGNvbW1vbi4gU28gSSB0aGluayBhbGwgaW4g
b25lIA0KZW5jb2RlX3BkdSBmdW5jdGlvbiBpcyBuZXcgZmVhdHVyZSBpbiBuZXcgQVRUIFN0YWNr
LCBzbyB0aGlzIGltcGxlbWVudGF0aW9uIGlzIA0KYXQgbG93ZXN0IHByaWNlIHRvIGNvbXBhdGli
bGUgd2l0aCBuZXcgQVRUIFN0YWNrLiBUaGF0IGlzIHdoeSBJIGRpZG7igJl0IGJhaWwgb3V0IGVh
cmx5DQp0aGlzIGNoZWNraW5nIChvcC0+b3Bjb2RlICYgQVRUX09QX1NJR05FRF9NQVNLKS4gRm9s
bG93aW5nIHRoaXMgaW1wbGVtZW50YXRpb24sDQp0aGVyZSBpcyBubyBuZWVkIHRvIGNyZWF0ZSBh
bm90aGVyIHRoZSBlbmNvZGUgZnVuY3Rpb24gdG8gaW1wbGVtZW50IHNpZ25lZF93cml0ZSwNCkp1
c3QgdXNpbmcgb25lIGVuY29kZV9wZHUgZnVuY3Rpb24gdG8gZG8gdGhpcyBpcyBPSy4NCg0KRG8g
eW91IHRoaW5rIHRoaXMgbWFrZSBzZW5zZT8NCg0KVGhhbmtzDQpDaGFvamllIEd1DQoNCg==
^ permalink raw reply
* Re: [PATCH v4 bluetooth-next] 6lowpan: Use pskb_expand_head in IPHC decompression.
From: Jukka Rissanen @ 2014-10-09 7:18 UTC (permalink / raw)
To: Martin Townsend
Cc: Alexander Aring, Martin Townsend, linux-bluetooth, linux-wpan,
marcel
In-Reply-To: <5435589A.7050605@xsilon.com>
Hi Martin,
code is ok by me.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
On ke, 2014-10-08 at 16:30 +0100, Martin Townsend wrote:
> Hi Alex,
>
> I'll wait for Jukka's ack for the bluetooth side and then send v5 with the removed skb_share_check.
>
> - Martin.
>
Cheers,
Jukka
^ 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