* [PATCH -v3 2/2] Bluetooth: Add chan->ops->defer()
From: Gustavo Padovan @ 2012-10-12 11:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
In-Reply-To: <1350041724-29948-1-git-send-email-gustavo@padovan.org>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
When DEFER_SETUP is set defer() will trigger an authorization
request to the userspace.
l2cap_chan_no_defer() is meant to be used when one does not want to
support DEFER_SETUP (A2MP for example).
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
include/net/bluetooth/l2cap.h | 5 +++++
net/bluetooth/a2mp.c | 1 +
net/bluetooth/l2cap_core.c | 10 +++-------
net/bluetooth/l2cap_sock.c | 10 ++++++++++
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index caab98c..6e23afd 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -541,6 +541,7 @@ struct l2cap_ops {
void (*state_change) (struct l2cap_chan *chan,
int state);
void (*ready) (struct l2cap_chan *chan);
+ void (*defer) (struct l2cap_chan *chan);
struct sk_buff *(*alloc_skb) (struct l2cap_chan *chan,
unsigned long len, int nb);
};
@@ -748,6 +749,10 @@ static inline void l2cap_chan_no_ready(struct l2cap_chan *chan)
{
}
+static inline void l2cap_chan_no_defer(struct l2cap_chan *chan)
+{
+}
+
extern bool disable_ertm;
int l2cap_init_sockets(void);
diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index 3ff4dc9..7bf9a10 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -699,6 +699,7 @@ static struct l2cap_ops a2mp_chan_ops = {
.new_connection = l2cap_chan_no_new_connection,
.teardown = l2cap_chan_no_teardown,
.ready = l2cap_chan_no_ready,
+ .defer = l2cap_chan_no_defer,
};
static struct l2cap_chan *a2mp_chan_open(struct l2cap_conn *conn, bool locked)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 9d84050..314d955 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1120,11 +1120,9 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
lock_sock(sk);
if (test_bit(BT_SK_DEFER_SETUP,
&bt_sk(sk)->flags)) {
- struct sock *parent = bt_sk(sk)->parent;
rsp.result = __constant_cpu_to_le16(L2CAP_CR_PEND);
rsp.status = __constant_cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
- if (parent)
- parent->sk_data_ready(parent, 0);
+ chan->ops->defer(chan);
} else {
__l2cap_state_change(chan, BT_CONFIG);
@@ -3460,7 +3458,7 @@ static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
__l2cap_state_change(chan, BT_CONNECT2);
result = L2CAP_CR_PEND;
status = L2CAP_CS_AUTHOR_PEND;
- parent->sk_data_ready(parent, 0);
+ chan->ops->defer(chan);
} else {
__l2cap_state_change(chan, BT_CONFIG);
result = L2CAP_CR_SUCCESS;
@@ -5523,11 +5521,9 @@ int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
if (!status) {
if (test_bit(BT_SK_DEFER_SETUP,
&bt_sk(sk)->flags)) {
- struct sock *parent = bt_sk(sk)->parent;
res = L2CAP_CR_PEND;
stat = L2CAP_CS_AUTHOR_PEND;
- if (parent)
- parent->sk_data_ready(parent, 0);
+ chan->ops->defer(chan);
} else {
__l2cap_state_change(chan, BT_CONFIG);
res = L2CAP_CR_SUCCESS;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index d5093b8..5fae2bd 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1081,6 +1081,15 @@ static void l2cap_sock_ready_cb(struct l2cap_chan *chan)
release_sock(sk);
}
+static void l2cap_sock_defer_cb(struct l2cap_chan *chan)
+{
+ struct sock *sk = chan->data;
+ struct sock *parent = bt_sk(sk)->parent;
+
+ if (parent)
+ parent->sk_data_ready(parent, 0);
+}
+
static struct l2cap_ops l2cap_chan_ops = {
.name = "L2CAP Socket Interface",
.new_connection = l2cap_sock_new_connection_cb,
@@ -1089,6 +1098,7 @@ static struct l2cap_ops l2cap_chan_ops = {
.teardown = l2cap_sock_teardown_cb,
.state_change = l2cap_sock_state_change_cb,
.ready = l2cap_sock_ready_cb,
+ .defer = l2cap_sock_defer_cb,
.alloc_skb = l2cap_sock_alloc_skb_cb,
};
--
1.7.11.4
^ permalink raw reply related
* [PATCH -v3 1/2] Bluetooth: Move bt_accept_enqueue() to l2cap_sock.c
From: Gustavo Padovan @ 2012-10-12 11:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
This is part of the move the parent socket usage to l2cap_sock.c
The change is safe when it cames to locking, bt_accept_enqueue() is still
protected by the parent socket lock inside the
l2cap_sock_new_connection_cb() code.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
net/bluetooth/l2cap_core.c | 4 ----
net/bluetooth/l2cap_sock.c | 2 ++
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 2fb37de..9d84050 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1230,8 +1230,6 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
- bt_accept_enqueue(parent, sk);
-
l2cap_chan_add(conn, chan);
l2cap_chan_ready(chan);
@@ -3448,8 +3446,6 @@ static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
chan->psm = psm;
chan->dcid = scid;
- bt_accept_enqueue(parent, sk);
-
__l2cap_chan_add(conn, chan);
dcid = chan->scid;
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index f95fc7e..d5093b8 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -949,6 +949,8 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
l2cap_sock_init(sk, parent);
+ bt_accept_enqueue(parent, sk);
+
return l2cap_pi(sk)->chan;
}
--
1.7.11.4
^ permalink raw reply related
* Re: [PATCH -v2 1/8] Bluetooth: Fix L2CAP coding style
From: Andrei Emeltchenko @ 2012-10-12 11:16 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth, Gustavo Padovan
In-Reply-To: <1349938311-25101-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
On Thu, Oct 11, 2012 at 02:51:44PM +0800, Gustavo Padovan wrote:
> -static inline int l2cap_get_conf_opt(void **ptr, int *type, int *olen, unsigned long *val)
> +static inline int l2cap_get_conf_opt(void **ptr, int *type, int *olen,
> + unsigned long *val)
For those functions you could also remove inline
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCH -v2 2/8] Bluetooth: Move bt_accept_enqueue() to l2cap_sock.c
From: Gustavo Padovan @ 2012-10-12 11:13 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, Gustavo Padovan
In-Reply-To: <1349963078.27233.166.camel@aeonflux>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2012-10-11 15:44:38 +0200]:
> Hi Gustavo,
>
> > This is move the parent socket usage to l2cap_sock.c
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> > net/bluetooth/l2cap_core.c | 4 ----
> > net/bluetooth/l2cap_sock.c | 2 ++
> > 2 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index b382631..e10a1a3 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -1233,8 +1233,6 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
> > bacpy(&bt_sk(sk)->src, conn->src);
> > bacpy(&bt_sk(sk)->dst, conn->dst);
> >
> > - bt_accept_enqueue(parent, sk);
> > -
> > l2cap_chan_add(conn, chan);
> >
> > l2cap_chan_ready(chan);
> > @@ -3451,8 +3449,6 @@ static inline int l2cap_connect_req(struct l2cap_conn *conn,
> > chan->psm = psm;
> > chan->dcid = scid;
> >
> > - bt_accept_enqueue(parent, sk);
> > -
> > __l2cap_chan_add(conn, chan);
> >
> > dcid = chan->scid;
> > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> > index f95fc7e..d5093b8 100644
> > --- a/net/bluetooth/l2cap_sock.c
> > +++ b/net/bluetooth/l2cap_sock.c
> > @@ -949,6 +949,8 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> >
> > l2cap_sock_init(sk, parent);
> >
> > + bt_accept_enqueue(parent, sk);
> > +
> > return l2cap_pi(sk)->chan;
> > }
> >
>
> and this has no side effect with adding during this window. Your commit
> message is not really explaining why this is fine. Please fix that.
No, it is safe to this here. If you look to the flow you will see that this
change is trivial actually. I'll add some more explanation to the commit
message.
Gustavo
^ permalink raw reply
* pull request: bluetooth 2012-10-12
From: Gustavo Padovan @ 2012-10-12 11:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
Hi John,
Johan found a critical issue while at Bluetooth UnPlug Fest this week.
The patch fixes a failure to pair with devices that support the LE Secure
Connections feature. This is also marked for stable.
Please pull! Thanks!
Gustavo
---
The following changes since commit a7be50b7e30f9d77cb059a7ffdb781bb0fb92eba:
iwlwifi: don't double free the interrupt in failure path (2012-09-18 20:43:23 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
for you to fetch changes up to 065a13e2cc665f6547dc7e8a9d6b6565badf940a:
Bluetooth: SMP: Fix setting unknown auth_req bits (2012-10-12 17:55:20 +0800)
----------------------------------------------------------------
Johan Hedberg (1):
Bluetooth: SMP: Fix setting unknown auth_req bits
net/bluetooth/smp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH -v2 4/8] Bluetooth: Add chan->ops->defer()
From: Gustavo Padovan @ 2012-10-12 10:48 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, Gustavo Padovan
In-Reply-To: <1349963363.27233.170.camel@aeonflux>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2012-10-11 15:49:23 +0200]:
> Hi Gustavo,
>
> > When DEFER_SETUP is set defer() will trigger an authorization
> > request to the userspace.
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> > include/net/bluetooth/l2cap.h | 5 +++++
> > net/bluetooth/a2mp.c | 1 +
> > net/bluetooth/l2cap_core.c | 10 +++-------
> > net/bluetooth/l2cap_sock.c | 13 +++++++++++++
> > 4 files changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> > index caab98c..6e23afd 100644
> > --- a/include/net/bluetooth/l2cap.h
> > +++ b/include/net/bluetooth/l2cap.h
> > @@ -541,6 +541,7 @@ struct l2cap_ops {
> > void (*state_change) (struct l2cap_chan *chan,
> > int state);
> > void (*ready) (struct l2cap_chan *chan);
> > + void (*defer) (struct l2cap_chan *chan);
> > struct sk_buff *(*alloc_skb) (struct l2cap_chan *chan,
> > unsigned long len, int nb);
> > };
> > @@ -748,6 +749,10 @@ static inline void l2cap_chan_no_ready(struct l2cap_chan *chan)
> > {
> > }
> >
> > +static inline void l2cap_chan_no_defer(struct l2cap_chan *chan)
> > +{
> > +}
> > +
> > extern bool disable_ertm;
> >
> > int l2cap_init_sockets(void);
> > diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
> > index 3ff4dc9..7bf9a10 100644
> > --- a/net/bluetooth/a2mp.c
> > +++ b/net/bluetooth/a2mp.c
> > @@ -699,6 +699,7 @@ static struct l2cap_ops a2mp_chan_ops = {
> > .new_connection = l2cap_chan_no_new_connection,
> > .teardown = l2cap_chan_no_teardown,
> > .ready = l2cap_chan_no_ready,
> > + .defer = l2cap_chan_no_defer,
> > };
> >
> > static struct l2cap_chan *a2mp_chan_open(struct l2cap_conn *conn, bool locked)
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 91d312b..a2f945d 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -1123,11 +1123,9 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
> > lock_sock(sk);
> > if (test_bit(BT_SK_DEFER_SETUP,
> > &bt_sk(sk)->flags)) {
> > - struct sock *parent = bt_sk(sk)->parent;
> > rsp.result = __constant_cpu_to_le16(L2CAP_CR_PEND);
> > rsp.status = __constant_cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
> > - if (parent)
> > - parent->sk_data_ready(parent, 0);
> > + chan->ops->defer(chan);
>
> I would prefer you explain this in detail. Sine the no_defer is then no
> longer calling sk_data_ready. Is this safe?
Yes, this is safe, the no_defer exists only to be used by those that do not
implement DEFER_SETUP support. Actually ops->defer() will never be called if
DEFER_SETUP is no enabled.
>
> >
> > } else {
> > __l2cap_state_change(chan, BT_CONFIG);
> > @@ -3459,7 +3457,7 @@ static inline int l2cap_connect_req(struct l2cap_conn *conn,
> > __l2cap_state_change(chan, BT_CONNECT2);
> > result = L2CAP_CR_PEND;
> > status = L2CAP_CS_AUTHOR_PEND;
> > - parent->sk_data_ready(parent, 0);
> > + chan->ops->defer(chan);
> > } else {
> > __l2cap_state_change(chan, BT_CONFIG);
> > result = L2CAP_CR_SUCCESS;
> > @@ -5520,11 +5518,9 @@ int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
> > if (!status) {
> > if (test_bit(BT_SK_DEFER_SETUP,
> > &bt_sk(sk)->flags)) {
> > - struct sock *parent = bt_sk(sk)->parent;
> > res = L2CAP_CR_PEND;
> > stat = L2CAP_CS_AUTHOR_PEND;
> > - if (parent)
> > - parent->sk_data_ready(parent, 0);
> > + chan->ops->defer(chan);
> > } else {
> > __l2cap_state_change(chan, BT_CONFIG);
> > res = L2CAP_CR_SUCCESS;
> > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> > index 45c81e1..efcb914 100644
> > --- a/net/bluetooth/l2cap_sock.c
> > +++ b/net/bluetooth/l2cap_sock.c
> > @@ -956,6 +956,7 @@ static struct l2cap_chan *l2cap_sock_new_connection_cb(struct l2cap_chan *chan)
> >
> > bt_accept_enqueue(parent, sk);
> >
> > +
>
> No pointless empty lines please.
Yes, this is the leftover from a merge conflict. I'll remove it.
>
> > release_sock(parent);
> >
> > return l2cap_pi(sk)->chan;
> > @@ -1088,6 +1089,17 @@ static void l2cap_sock_ready_cb(struct l2cap_chan *chan)
> > release_sock(sk);
> > }
> >
> > +static void l2cap_sock_defer_cb(struct l2cap_chan *chan)
> > +{
> > + struct sock *sk = chan->data;
> > + struct sock *parent;
> > +
> > + parent = bt_sk(sk)->parent;
>
> You can do struct sock *parent = bt_sk(sk)-parent here.
Sure.
>
> > +
> > + if (parent)
> > + parent->sk_data_ready(parent, 0);
> > +}
> > +
> > static struct l2cap_ops l2cap_chan_ops = {
> > .name = "L2CAP Socket Interface",
> > .new_connection = l2cap_sock_new_connection_cb,
> > @@ -1096,6 +1108,7 @@ static struct l2cap_ops l2cap_chan_ops = {
> > .teardown = l2cap_sock_teardown_cb,
> > .state_change = l2cap_sock_state_change_cb,
> > .ready = l2cap_sock_ready_cb,
> > + .defer = l2cap_sock_defer_cb,
> > .alloc_skb = l2cap_sock_alloc_skb_cb,
> > };
> >
>
> I am bit unease with accidentally having no_defer and then DEFER_SETUP
> is set. Are we not changing behavior here?
No, as I said above, this case will not happen.
Gustavo
^ permalink raw reply
* Re: [PATCH -v2 5/8] Bluetooth: Remove GFP_ATOMIC usage from l2cap_core.c
From: Gustavo Padovan @ 2012-10-12 10:20 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, Gustavo Padovan
In-Reply-To: <1349963436.27233.171.camel@aeonflux>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2012-10-11 15:50:36 +0200]:
> Hi Gustavo,
>
> > Since we change the Bluetooth core to run in process context we don't need
> > to use GFP_ATOMIC in many of places we were using it. The we just replace
> > by GFP_KERNEL.
>
> I assume you double-checked that we nowhere hold a lock or the caller
> holds a lock.
Yes, I did double-check this. The code is running pretty fine as well.
I pushed this to bluetooth-next btw.
Gustavo
>
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: SMP: Fix setting unknown auth_req bits
From: Gustavo Padovan @ 2012-10-12 9:56 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1349965566-29482-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2012-10-11 16:26:06 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> When sending a pairing request or response we should not just blindly
> copy the value that the remote device sent. Instead we should at least
> make sure to mask out any unknown bits. This is particularly critical
> from the upcoming LE Secure Connections feature perspective as
> incorrectly indicating support for it (by copying the remote value)
> would cause a failure to pair with devices that support it.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> Cc: stable@kernel.org
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/smp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: [RFC 3/6] Bluetooth: Factor out common L2CAP connection code
From: Gustavo Padovan @ 2012-10-12 9:50 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com> [2012-10-11 17:48:22 +0300]:
> From: Mat Martineau <mathewm@codeaurora.org>
>
> L2CAP connect requests and create channel requests share a significant
> amount of code. This change moves common code to a new function.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [RFC 2/6] Bluetooth: Process create response and connect response identically
From: Gustavo Padovan @ 2012-10-12 9:46 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com> [2012-10-11 17:48:21 +0300]:
> From: Mat Martineau <mathewm@codeaurora.org>
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
Patch has been applied to bluetooth-next, thanks.
Gustavo
^ permalink raw reply
* Re: [RFC 1/6] Bluetooth: Add new l2cap_chan struct members for high speed channels
From: Andrei Emeltchenko @ 2012-10-12 7:25 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth
In-Reply-To: <alpine.DEB.2.02.1210110858010.26189@mathewm-linux>
Hi Mat,
On Thu, Oct 11, 2012 at 08:58:40AM -0700, Mat Martineau wrote:
>
> Andrei -
>
> On Thu, 11 Oct 2012, Andrei Emeltchenko wrote:
>
> >From: Mat Martineau <mathewm@codeaurora.org>
> >
> >An L2CAP channel using high speed continues to be associated with a
> >BR/EDR l2cap_conn, while also tracking an additional hci_conn
> >(representing a physical link on a high speed controller) and hci_chan
> >(representing a logical link). There may only be one physical link
> >between two high speed controllers. Each physical link may contain
> >several logical links, with each logical link representing a channel
> >with specific quality of service.
> >
> >During a channel move, the destination channel id, current move state,
> >and role (initiator vs. responder) are tracked and used by the channel
> >move state machine. The ident value associated with a move request
> >must also be stored in order to use it in later move responses.
> >
> >The active channel is stored in local_amp_id.
> >
> >Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >---
> >include/net/bluetooth/l2cap.h | 29 +++++++++++++++++++++++++++++
> >net/bluetooth/l2cap_core.c | 5 +++++
> >2 files changed, 34 insertions(+)
>
> Did you have to do anything other than rebase these 6 patches?
I would wish to, but I am stuck with dependencies :(
At least I need chan pointers to hs_hchan and hs_hcon ...
Best regards
Andrei Emeltchenko
> I can post a PATCHv1 set tomorrow or Monday.
This sounds good. I will also send my patches later today.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* [PATCH BlueZ] input: Convert to DBus.Properties
From: Lucas De Marchi @ 2012-10-11 18:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lucas De Marchi
---
profiles/input/device.c | 44 +++++++++++++-------------------------------
1 file changed, 13 insertions(+), 31 deletions(-)
diff --git a/profiles/input/device.c b/profiles/input/device.c
index 92e1fa9..997235b 100644
--- a/profiles/input/device.c
+++ b/profiles/input/device.c
@@ -729,33 +729,18 @@ static void device_unregister(void *data)
input_device_free(idev);
}
-static DBusMessage *input_device_get_properties(DBusConnection *conn,
- DBusMessage *msg, void *data)
-{
- struct input_device *idev = data;
- DBusMessage *reply;
- DBusMessageIter iter;
- DBusMessageIter dict;
- dbus_bool_t connected;
- reply = dbus_message_new_method_return(msg);
- if (!reply)
- return NULL;
- dbus_message_iter_init_append(reply, &iter);
-
- dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
- DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
- DBUS_TYPE_STRING_AS_STRING DBUS_TYPE_VARIANT_AS_STRING
- DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &dict);
-
- /* Connected */
- connected = is_connected(idev);
- dict_append_entry(&dict, "Connected", DBUS_TYPE_BOOLEAN, &connected);
+static gboolean input_device_property_get_connected(
+ const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct input_device *idev = data;
+ dbus_bool_t connected = is_connected(idev);
- dbus_message_iter_close_container(&iter, &dict);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_BOOLEAN, &connected);
- return reply;
+ return TRUE;
}
static const GDBusMethodTable device_methods[] = {
@@ -763,15 +748,11 @@ static const GDBusMethodTable device_methods[] = {
NULL, NULL, local_connect) },
{ GDBUS_METHOD("Disconnect",
NULL, NULL, input_device_disconnect) },
- { GDBUS_METHOD("GetProperties",
- NULL, GDBUS_ARGS({ "properties", "a{sv}" }),
- input_device_get_properties) },
{ }
};
-static const GDBusSignalTable device_signals[] = {
- { GDBUS_SIGNAL("PropertyChanged",
- GDBUS_ARGS({ "name", "s" }, { "value", "v" })) },
+static const GDBusPropertyTable device_properties[] = {
+ { "Connected", "b", input_device_property_get_connected },
{ }
};
@@ -800,8 +781,9 @@ static struct input_device *input_device_new(struct btd_device *device,
if (g_dbus_register_interface(btd_get_dbus_connection(),
idev->path, INPUT_DEVICE_INTERFACE,
- device_methods, device_signals, NULL,
- idev, device_unregister) == FALSE) {
+ device_methods, NULL,
+ device_properties, idev,
+ device_unregister) == FALSE) {
error("Failed to register interface %s on path %s",
INPUT_DEVICE_INTERFACE, path);
input_device_free(idev);
--
1.7.12.2
^ permalink raw reply related
* Re: [RFC 1/6] Bluetooth: Add new l2cap_chan struct members for high speed channels
From: Marcel Holtmann @ 2012-10-11 17:39 UTC (permalink / raw)
To: Mat Martineau; +Cc: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <alpine.DEB.2.02.1210110858010.26189@mathewm-linux>
Hi Mat,
> > An L2CAP channel using high speed continues to be associated with a
> > BR/EDR l2cap_conn, while also tracking an additional hci_conn
> > (representing a physical link on a high speed controller) and hci_chan
> > (representing a logical link). There may only be one physical link
> > between two high speed controllers. Each physical link may contain
> > several logical links, with each logical link representing a channel
> > with specific quality of service.
> >
> > During a channel move, the destination channel id, current move state,
> > and role (initiator vs. responder) are tracked and used by the channel
> > move state machine. The ident value associated with a move request
> > must also be stored in order to use it in later move responses.
> >
> > The active channel is stored in local_amp_id.
> >
> > Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> > ---
> > include/net/bluetooth/l2cap.h | 29 +++++++++++++++++++++++++++++
> > net/bluetooth/l2cap_core.c | 5 +++++
> > 2 files changed, 34 insertions(+)
>
> Did you have to do anything other than rebase these 6 patches?
>
> I can post a PATCHv1 set tomorrow or Monday.
that would be great. I am trying to get a few free cycles to get this
all reviewed and merged. So we finally get HS into upstream for larger
exposure.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 1/6] Bluetooth: Add new l2cap_chan struct members for high speed channels
From: Mat Martineau @ 2012-10-11 15:58 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Andrei -
On Thu, 11 Oct 2012, Andrei Emeltchenko wrote:
> From: Mat Martineau <mathewm@codeaurora.org>
>
> An L2CAP channel using high speed continues to be associated with a
> BR/EDR l2cap_conn, while also tracking an additional hci_conn
> (representing a physical link on a high speed controller) and hci_chan
> (representing a logical link). There may only be one physical link
> between two high speed controllers. Each physical link may contain
> several logical links, with each logical link representing a channel
> with specific quality of service.
>
> During a channel move, the destination channel id, current move state,
> and role (initiator vs. responder) are tracked and used by the channel
> move state machine. The ident value associated with a move request
> must also be stored in order to use it in later move responses.
>
> The active channel is stored in local_amp_id.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> include/net/bluetooth/l2cap.h | 29 +++++++++++++++++++++++++++++
> net/bluetooth/l2cap_core.c | 5 +++++
> 2 files changed, 34 insertions(+)
Did you have to do anything other than rebase these 6 patches?
I can post a PATCHv1 set tomorrow or Monday.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFC 5/6] Bluetooth: Add L2CAP create channel request handling
From: Marcel Holtmann @ 2012-10-11 15:13 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-5-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> The L2CAP create channel request is very similar to an L2CAP connect
> request, but it has an additional parameter for the controller ID. If
> the controller id is 0, the channel is set up on the BR/EDR controller
> (just like a connect request). Using a valid high speed controller ID
> will cause the channel to be initially created on that high speed
> controller. While the L2CAP data will be initially routed over the
> AMP controller, the L2CAP fixed signaling channel only uses BR/EDR.
>
> When a create channel request is received for a high speed controller,
> a pending response is always sent first. After the high speed
> physical and logical links are complete a success response will be
> sent.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 70 ++++++++++++++++++++++++++++++++++----------
> 1 file changed, 54 insertions(+), 16 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 4/6] Bluetooth: Ignore BR/EDR packet size constraints when fragmenting for AMP
From: Marcel Holtmann @ 2012-10-11 15:12 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-4-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> When operating over BR/EDR, ERTM accounts for the maximum over-the-air
> packet size when setting the PDU size. AMP controllers do not use the
> same over-the-air packets, so the PDU size should only be based on the
> HCI MTU of the AMP controller.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 1/6] Bluetooth: Add new l2cap_chan struct members for high speed channels
From: Marcel Holtmann @ 2012-10-11 15:12 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Mat,
> An L2CAP channel using high speed continues to be associated with a
> BR/EDR l2cap_conn, while also tracking an additional hci_conn
> (representing a physical link on a high speed controller) and hci_chan
> (representing a logical link). There may only be one physical link
> between two high speed controllers. Each physical link may contain
> several logical links, with each logical link representing a channel
> with specific quality of service.
>
> During a channel move, the destination channel id, current move state,
> and role (initiator vs. responder) are tracked and used by the channel
> move state machine. The ident value associated with a move request
> must also be stored in order to use it in later move responses.
>
> The active channel is stored in local_amp_id.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> include/net/bluetooth/l2cap.h | 29 +++++++++++++++++++++++++++++
> net/bluetooth/l2cap_core.c | 5 +++++
> 2 files changed, 34 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 6/6] Bluetooth: Fix error code byte order
From: Marcel Holtmann @ 2012-10-11 15:11 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-6-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 3/6] Bluetooth: Factor out common L2CAP connection code
From: Marcel Holtmann @ 2012-10-11 15:11 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> L2CAP connect requests and create channel requests share a significant
> amount of code. This change moves common code to a new function.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 2/6] Bluetooth: Process create response and connect response identically
From: Marcel Holtmann @ 2012-10-11 15:09 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, mathewm
In-Reply-To: <1349966905-32336-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: SMP: Fix setting unknown auth_req bits
From: Johan Hedberg @ 2012-10-11 15:00 UTC (permalink / raw)
To: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <20121011143355.GA28051@aemeltch-MOBL1>
Hi Andrei,
On Thu, Oct 11, 2012, Andrei Emeltchenko wrote:
> > @@ -230,7 +232,7 @@ static void build_pairing_cmd(struct l2cap_conn *conn,
> > req->max_key_size = SMP_MAX_ENC_KEY_SIZE;
> > req->init_key_dist = 0;
> > req->resp_key_dist = dist_keys;
> > - req->auth_req = authreq;
> > + req->auth_req = (authreq & AUTH_REQ_MASK);
> > return;
> > }
> >
> > @@ -239,7 +241,7 @@ static void build_pairing_cmd(struct l2cap_conn *conn,
> > rsp->max_key_size = SMP_MAX_ENC_KEY_SIZE;
> > rsp->init_key_dist = 0;
> > rsp->resp_key_dist = req->resp_key_dist & dist_keys;
> > - rsp->auth_req = authreq;
> > + rsp->auth_req = (authreq & AUTH_REQ_MASK);
>
> Would it be better to omit braces like in the line above? For both cases.
I actually didn't notice the line above the second chunk. I always
thought it was good practice to have explicit braces around bitwise
operations to avoid evaluation-order bugs (particularly in
if-statements) so I just always do it. I'll leave this to Gustavo or
Marcel to object to if necessary (otoh Marcel already gave his ack).
Johan
^ permalink raw reply
* [RFC 6/6] Bluetooth: Fix error code byte order
From: Andrei Emeltchenko @ 2012-10-11 14:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: mathewm
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 62b1d3a..cefac95 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4057,8 +4057,8 @@ static int l2cap_create_channel_req(struct l2cap_conn *conn,
rsp.dcid = 0;
rsp.scid = cpu_to_le16(scid);
- rsp.result = L2CAP_CR_BAD_AMP;
- rsp.status = L2CAP_CS_NO_INFO;
+ rsp.result = __constant_cpu_to_le16(L2CAP_CR_BAD_AMP);
+ rsp.status = __constant_cpu_to_le16(L2CAP_CS_NO_INFO);
l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP,
sizeof(rsp), &rsp);
--
1.7.9.5
^ permalink raw reply related
* [RFC 5/6] Bluetooth: Add L2CAP create channel request handling
From: Andrei Emeltchenko @ 2012-10-11 14:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: mathewm
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Mat Martineau <mathewm@codeaurora.org>
The L2CAP create channel request is very similar to an L2CAP connect
request, but it has an additional parameter for the controller ID. If
the controller id is 0, the channel is set up on the BR/EDR controller
(just like a connect request). Using a valid high speed controller ID
will cause the channel to be initially created on that high speed
controller. While the L2CAP data will be initially routed over the
AMP controller, the L2CAP fixed signaling channel only uses BR/EDR.
When a create channel request is received for a high speed controller,
a pending response is always sent first. After the high speed
physical and logical links are complete a success response will be
sent.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 70 ++++++++++++++++++++++++++++++++++----------
1 file changed, 54 insertions(+), 16 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index e4de81c..62b1d3a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3401,8 +3401,9 @@ static inline int l2cap_command_rej(struct l2cap_conn *conn, struct l2cap_cmd_hd
return 0;
}
-static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
- u8 *data, u8 rsp_code, u8 amp_id)
+static struct l2cap_chan *__l2cap_connect(struct l2cap_conn *conn,
+ struct l2cap_cmd_hdr *cmd,
+ u8 *data, u8 rsp_code, u8 amp_id)
{
struct l2cap_conn_req *req = (struct l2cap_conn_req *) data;
struct l2cap_conn_rsp rsp;
@@ -3429,7 +3430,7 @@ static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
/* Check if the ACL is secure enough (if not SDP) */
if (psm != __constant_cpu_to_le16(L2CAP_PSM_SDP) &&
- !hci_conn_check_link_mode(conn->hcon)) {
+ !hci_conn_check_link_mode(conn->hcon)) {
conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
result = L2CAP_CR_SEC_BLOCK;
goto response;
@@ -3453,6 +3454,7 @@ static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
bacpy(&bt_sk(sk)->dst, conn->dst);
chan->psm = psm;
chan->dcid = scid;
+ chan->local_amp_id = amp_id;
bt_accept_enqueue(parent, sk);
@@ -3472,8 +3474,16 @@ static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
status = L2CAP_CS_AUTHOR_PEND;
parent->sk_data_ready(parent, 0);
} else {
- __l2cap_state_change(chan, BT_CONFIG);
- result = L2CAP_CR_SUCCESS;
+ /* Force pending result for AMP controllers.
+ * The connection will succeed after the
+ * physical link is up. */
+ if (amp_id) {
+ __l2cap_state_change(chan, BT_CONNECT2);
+ result = L2CAP_CR_PEND;
+ } else {
+ __l2cap_state_change(chan, BT_CONFIG);
+ result = L2CAP_CR_SUCCESS;
+ }
status = L2CAP_CS_NO_INFO;
}
} else {
@@ -3519,6 +3529,8 @@ sendresp:
l2cap_build_conf_req(chan, buf), buf);
chan->num_conf_req++;
}
+
+ return chan;
}
static int l2cap_connect_req(struct l2cap_conn *conn,
@@ -4015,12 +4027,12 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
return 0;
}
-static inline int l2cap_create_channel_req(struct l2cap_conn *conn,
- struct l2cap_cmd_hdr *cmd, u16 cmd_len,
- void *data)
+static int l2cap_create_channel_req(struct l2cap_conn *conn,
+ struct l2cap_cmd_hdr *cmd, u16 cmd_len,
+ void *data)
{
struct l2cap_create_chan_req *req = data;
- struct l2cap_create_chan_rsp rsp;
+ struct l2cap_chan *chan;
u16 psm, scid;
if (cmd_len != sizeof(*req))
@@ -4034,14 +4046,40 @@ static inline int l2cap_create_channel_req(struct l2cap_conn *conn,
BT_DBG("psm 0x%2.2x, scid 0x%4.4x, amp_id %d", psm, scid, req->amp_id);
- /* Placeholder: Always reject */
- rsp.dcid = 0;
- rsp.scid = cpu_to_le16(scid);
- rsp.result = __constant_cpu_to_le16(L2CAP_CR_NO_MEM);
- rsp.status = __constant_cpu_to_le16(L2CAP_CS_NO_INFO);
+ if (req->amp_id) {
+ struct hci_dev *hdev;
+
+ /* Validate AMP controller id */
+ hdev = hci_dev_get(req->amp_id);
+ if (!hdev || hdev->dev_type != HCI_AMP ||
+ !test_bit(HCI_UP, &hdev->flags)) {
+ struct l2cap_create_chan_rsp rsp;
+
+ rsp.dcid = 0;
+ rsp.scid = cpu_to_le16(scid);
+ rsp.result = L2CAP_CR_BAD_AMP;
+ rsp.status = L2CAP_CS_NO_INFO;
+
+ l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP,
+ sizeof(rsp), &rsp);
+
+ if (hdev)
+ hci_dev_put(hdev);
+
+ return 0;
+ }
+
+ hci_dev_put(hdev);
+ }
+
+ chan = __l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP,
+ req->amp_id);
- l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP,
- sizeof(rsp), &rsp);
+ /* Placeholder - uncomment when amp functions are available
+ if (chan && req->amp_id &&
+ (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
+ amp_accept_physical(conn, req->amp_id, chan);
+ */
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC 4/6] Bluetooth: Ignore BR/EDR packet size constraints when fragmenting for AMP
From: Andrei Emeltchenko @ 2012-10-11 14:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: mathewm
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Mat Martineau <mathewm@codeaurora.org>
When operating over BR/EDR, ERTM accounts for the maximum over-the-air
packet size when setting the PDU size. AMP controllers do not use the
same over-the-air packets, so the PDU size should only be based on the
HCI MTU of the AMP controller.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index d56cc57..e4de81c 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2141,7 +2141,9 @@ static int l2cap_segment_sdu(struct l2cap_chan *chan,
/* PDU size is derived from the HCI MTU */
pdu_len = chan->conn->mtu;
- pdu_len = min_t(size_t, pdu_len, L2CAP_BREDR_MAX_PAYLOAD);
+ /* Constrain PDU size for BR/EDR connections */
+ if (!chan->hs_hcon)
+ pdu_len = min_t(size_t, pdu_len, L2CAP_BREDR_MAX_PAYLOAD);
/* Adjust for largest possible L2CAP overhead. */
if (chan->fcs)
--
1.7.9.5
^ permalink raw reply related
* [RFC 3/6] Bluetooth: Factor out common L2CAP connection code
From: Andrei Emeltchenko @ 2012-10-11 14:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: mathewm
In-Reply-To: <1349966905-32336-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Mat Martineau <mathewm@codeaurora.org>
L2CAP connect requests and create channel requests share a significant
amount of code. This change moves common code to a new function.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 632f291..d56cc57 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3399,7 +3399,8 @@ static inline int l2cap_command_rej(struct l2cap_conn *conn, struct l2cap_cmd_hd
return 0;
}
-static inline int l2cap_connect_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u8 *data)
+static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd,
+ u8 *data, u8 rsp_code, u8 amp_id)
{
struct l2cap_conn_req *req = (struct l2cap_conn_req *) data;
struct l2cap_conn_rsp rsp;
@@ -3493,7 +3494,7 @@ sendresp:
rsp.dcid = cpu_to_le16(dcid);
rsp.result = cpu_to_le16(result);
rsp.status = cpu_to_le16(status);
- l2cap_send_cmd(conn, cmd->ident, L2CAP_CONN_RSP, sizeof(rsp), &rsp);
+ l2cap_send_cmd(conn, cmd->ident, rsp_code, sizeof(rsp), &rsp);
if (result == L2CAP_CR_PEND && status == L2CAP_CS_NO_INFO) {
struct l2cap_info_req info;
@@ -3516,7 +3517,12 @@ sendresp:
l2cap_build_conf_req(chan, buf), buf);
chan->num_conf_req++;
}
+}
+static int l2cap_connect_req(struct l2cap_conn *conn,
+ struct l2cap_cmd_hdr *cmd, u8 *data)
+{
+ __l2cap_connect(conn, cmd, data, L2CAP_CONN_RSP, 0);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox