Linux bluetooth development
 help / color / mirror / Atom feed
From: Mat Martineau <mathewm@codeaurora.org>
To: Gustavo Padovan <padovan@profusion.mobi>
Cc: linux-bluetooth@vger.kernel.org, pkrystad@codeaurora.org,
	andrei.emeltchenko@intel.com
Subject: Re: [PATCH 9/9] Bluetooth: Add signal handlers for channel moves
Date: Fri, 14 Oct 2011 16:19:53 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1110141618420.9993@mathewm-linux> (raw)
In-Reply-To: <20111014184650.GD30989@joana>


On Fri, 14 Oct 2011, Gustavo Padovan wrote:

> Hi Mat,
>
> * Mat Martineau <mathewm@codeaurora.org> [2011-10-13 15:00:47 -0700]:
>
>> AMP channels can be moved between BR/EDR and AMP controllers using a
>> sequence of signals. Every attempted channel move involves a series of
>> four signals:
>>
>>    Move Initiator                 Move Responder
>>         |                                 |
>>         |       Move Channel Request      |
>>         |  ---------------------------->  |
>>         |                                 |
>>         |       Move Channel Response     |
>>         |  <----------------------------  |
>>         |                                 |
>>         |       Move Channel Confirm      |
>>         |  ---------------------------->  |
>>         |                                 |
>>         |  Move Channel Confirm Response  |
>> 	|  <----------------------------  |
>>
>> All four signals are sent even if the move fails.
>>
>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
>> ---
>>  net/bluetooth/l2cap_core.c |  123 ++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 123 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> index e38258b..ba64bab 100644
>> --- a/net/bluetooth/l2cap_core.c
>> +++ b/net/bluetooth/l2cap_core.c
>> @@ -2957,6 +2957,112 @@ static inline int l2cap_create_channel_rsp(struct l2cap_conn *conn,
>>  	return l2cap_connect_rsp(conn, cmd, data);
>>  }
>>
>> +static void l2cap_send_move_chan_rsp(struct l2cap_conn *conn, u8 ident,
>> +				u16 icid, u16 result)
>> +{
>> +	struct l2cap_move_chan_rsp rsp;
>> +
>> +	BT_DBG("icid %d, result %d", (int) icid, (int) result);
>> +
>> +	rsp.icid = cpu_to_le16(icid);
>> +	rsp.result = cpu_to_le16(result);
>> +
>> +	l2cap_send_cmd(conn, ident, L2CAP_MOVE_CHAN_RSP, sizeof(rsp), &rsp);
>> +}
>> +
>> +static void l2cap_send_move_chan_cfm(struct l2cap_conn *conn,
>> +				struct l2cap_chan *chan, u16 icid, u16 result)
>> +{
>> +	struct l2cap_move_chan_cfm cfm;
>> +	u8 ident;
>> +
>> +	BT_DBG("icid %d, result %d", (int) icid, (int) result);
>> +
>> +	ident = l2cap_get_ident(conn);
>> +	if (chan)
>> +		chan->ident = ident;
>> +
>> +	cfm.icid = cpu_to_le16(icid);
>> +	cfm.result = cpu_to_le16(result);
>> +
>> +	l2cap_send_cmd(conn, ident, L2CAP_MOVE_CHAN_CFM, sizeof(cfm), &cfm);
>> +}
>> +
>> +static void l2cap_send_move_chan_cfm_rsp(struct l2cap_conn *conn, u8 ident,
>> +					u16 icid)
>> +{
>> +	struct l2cap_move_chan_cfm_rsp rsp;
>> +
>> +	BT_DBG("icid %d", (int) icid);
>> +
>> +	rsp.icid = cpu_to_le16(icid);
>> +	l2cap_send_cmd(conn, ident, L2CAP_MOVE_CHAN_CFM_RSP, sizeof(rsp), &rsp);
>> +}
>> +
>> +static inline int l2cap_move_channel_req(struct l2cap_conn *conn,
>> +					struct l2cap_cmd_hdr *cmd, u8 *data)
>> +{
>> +	struct l2cap_move_chan_req *req = (struct l2cap_move_chan_req *) data;
>> +	u16 icid = 0;
>> +	u16 result = L2CAP_MOVE_CHAN_REFUSED_NOT_ALLOWED;
>> +
>> +	icid = le16_to_cpu(req->icid);
>> +
>> +	BT_DBG("icid %d, dest_amp_id %d", (int) icid, (int) req->dest_amp_id);
>> +
>> +	/* Placeholder: Always refuse */
>> +	l2cap_send_move_chan_rsp(conn, cmd->ident, icid, result);
>> +
>> +	return 0;
>> +}
>
> It's a good idea protect the move channel request with enable_hs.

Yes, I'll require enable_hs to have the move channel do anything. 
When enable_hs is false, it seems like it should return a 
L2CAP_MOVE_CHAN_REFUSED_NOT_ALLOWED response like it does now.


--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


  reply	other threads:[~2011-10-14 23:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-13 22:00 [PATCH 0/9] AMP interface and signal framework Mat Martineau
2011-10-13 22:00 ` [PATCH 1/9] Bluetooth: Add BT_AMP_POLICY socket option Mat Martineau
2011-10-13 23:38   ` Marcel Holtmann
2011-10-14 22:38     ` Mat Martineau
2011-10-15 18:43       ` Marcel Holtmann
2011-10-17 10:25       ` Luiz Augusto von Dentz
2011-10-17 15:56         ` Marcel Holtmann
2011-10-13 22:00 ` [PATCH 2/9] Bluetooth: Add AMP policy information to l2cap_chan Mat Martineau
2011-10-14 11:20   ` Andrei Emeltchenko
2011-10-14 22:39     ` Mat Martineau
2011-10-13 22:00 ` [PATCH 3/9] Bluetooth: Get/set AMP policy socket option Mat Martineau
2011-10-13 22:35   ` Marcel Holtmann
2011-10-13 23:05     ` Mat Martineau
2011-10-13 23:27       ` Marcel Holtmann
2011-10-13 22:00 ` [PATCH 4/9] Bluetooth: Add AMP-related data and structures for channel signals Mat Martineau
2011-10-14 12:19   ` Andrei Emeltchenko
2011-10-14 22:58     ` Mat Martineau
2011-10-17  7:23       ` Andrei Emeltchenko
2011-10-13 22:00 ` [PATCH 5/9] Bluetooth: Add signal handlers for channel creation Mat Martineau
2011-10-13 22:00 ` [PATCH 6/9] Bluetooth: Add definitions for L2CAP fixed channels Mat Martineau
2011-10-13 22:00 ` [PATCH 7/9] Bluetooth: Use symbolic values for the fixed channel map Mat Martineau
2011-10-14 12:36   ` Andrei Emeltchenko
2011-10-14 23:04     ` Mat Martineau
2011-10-14 23:51       ` Gustavo Padovan
2011-10-13 22:00 ` [PATCH 8/9] Bluetooth: Add AMP header file Mat Martineau
2011-10-14 12:38   ` Andrei Emeltchenko
2011-10-14 23:07     ` Mat Martineau
2011-10-13 22:00 ` [PATCH 9/9] Bluetooth: Add signal handlers for channel moves Mat Martineau
2011-10-14 18:46   ` Gustavo Padovan
2011-10-14 23:19     ` Mat Martineau [this message]
2011-10-17  7:31       ` Andrei Emeltchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1110141618420.9993@mathewm-linux \
    --to=mathewm@codeaurora.org \
    --cc=andrei.emeltchenko@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=padovan@profusion.mobi \
    --cc=pkrystad@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox