From: Marcel Holtmann <marcel@holtmann.org>
To: Mat Martineau <mathewm@codeaurora.org>
Cc: linux-bluetooth@vger.kernel.org, padovan@profusion.mobi,
pkrystad@codeaurora.org, andrei.emeltchenko@intel.com
Subject: Re: [PATCH 1/9] Bluetooth: Add BT_AMP_POLICY socket option
Date: Thu, 13 Oct 2011 16:38:07 -0700 [thread overview]
Message-ID: <1318549090.15441.49.camel@aeonflux> (raw)
In-Reply-To: <1318543247-27130-2-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> Allow control of AMP functionality on L2CAP sockets. By default,
> connections will be restricted to BR/EDR. Manipulating the
> BT_AMP_POLICY option allows for channels to be moved to or created
> on AMP controllers.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/bluetooth.h | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index e727555..14ae418 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -77,6 +77,33 @@ struct bt_power {
> #define BT_POWER_FORCE_ACTIVE_OFF 0
> #define BT_POWER_FORCE_ACTIVE_ON 1
>
> +#define BT_AMP_POLICY 10
> +
> +/* Require BR/EDR (default policy)
> + * AMP controllers cannot be used.
> + * Channel move requests from the remote device are denied.
> + * If the L2CAP channel is currently using AMP, move the channel to BR/EDR.
> + */
> +#define BT_AMP_POLICY_REQUIRE_BR_EDR 0
so lets brainstorm a little bit with the names here. Do we really wanna
use the term AMP_POLICY? Is it really AMP specific? Or do we better make
ourselves a bit more future proof?
I am currently thinking a bit more generic. Maybe this is not the best
choice, but lets entertain this for a bit. So what about calling this
BT_CHANNEL_POLICY?
And instead of REQUIRE_BR_EDR I would call it BREDR_ONLY.
> +/* Prefer AMP
> + * Allow use of AMP controllers
> + * If the L2CAP channel is currently on BR/EDR and AMP controller
> + * resources are available, initiate a channel move to AMP.
> + * Channel move requests from the remote device are allowed.
> + * If the L2CAP socket has not been connected yet, try to create
> + * and configure the channel directly on an AMP controller rather
> + * than BR/EDR.
> + */
> +#define BT_AMP_POLICY_PREFER_AMP 1
> +
> +/* Prefer BR/EDR
> + * Allow use of AMP controllers.
> + * If the L2CAP channel is currently on AMP, move it to BR/EDR.
> + * Channel move requests from the remote device are allowed.
> + */
> +#define BT_AMP_POLICY_PREFER_BR_EDR 2
We might also wanna look into the option of having a SCM message in the
socket that tells us the current type. Or at least tells us when we
successfully switched to AMP or back to BR/EDR. Since obviously we are
not blocking on the setsockopt call.
Not sure if applications actually do care, but for OBEX it might be
interesting to know if you are on an AMP controller right now or not.
Regards
Marcel
next prev parent reply other threads:[~2011-10-13 23:38 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 [this message]
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
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=1318549090.15441.49.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=andrei.emeltchenko@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=mathewm@codeaurora.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;
as well as URLs for NNTP newsgroup(s).