This patch propose a new set of NL80211 commands and attributes
to communicate information about ongoing Bluetooth operations to the
wifi chip in case of a Bluetooth-WiFi coex solution.
It can then be used by the WiFi hardware to understand the requirements
of a Bluetooth radio and manage shared resources between
Bluetooth and Wifi modules better.
The proposed Bluetooth information sent are mainly regarding Bluetooth
SCO, A2DP connection, inquiry and master/slave role of Bluetooth chip.
This information can be sent by a userspace Bluetooth filter utility
application to the WiFi driver.
Signed-off-by: Suraj Sumangala <[email protected]>
---
include/linux/nl80211.h | 73 +++++++++++++++++++++++++++++++++++++++++++++++
net/wireless/nl80211.c | 6 ++++
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 0343504..301ac13 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -499,6 +499,31 @@
* this command may also be sent by the driver as an MLME event to
* inform userspace of the new replay counter.
*
+ * @NL80211_CMD_BTCOEX_INQ: This command is used to provide WiFi driver the
+ * Bluetooth inquiry status. The status will be available in flag
+ * %NL80211_ATTR_BTCOEX_INQ_STATUS. This information can be used to
+ * manage shared resources when the wireless device is a Bluetooth-Wifi
+ * coex solution.
+ *
+ * @NL80211_CMD_BTCOEX_SCO: This command is used to give the driver the
+ * Bluetooth SCO connection status. The SCO status is available in
+ * %NL80211_ATTR_BTCOEX_SCO_STATUS flag. It also provide
+ * %NL80211_ATTR_BTCOEX_TYPE_ESCO to specify if the connection is ESCO.
+ * It also has %NL80211_ATTR_BTCOEX_SCO_MAX_SLOT specifing the maximum
+ * number of slots used for a SCO packet. This feature is typically used
+ * when the wireless device is a Bluetooth-Wifi coex solution.
+ *
+ * @NL80211_CMD_BTCOEX_A2DP: This command is used to give the driver the
+ * Bluetooth A2DP profile connection status. The A2DP profile connection
+ * status is available in %NL80211_ATTR_BTCOEX_A2DP_STATUS flag.
+ * This feature is typically used when the wireless device is a
+ * Bluetooth-Wifi coex solution.
+ *
+ * @NL80211_CMD_BTCOEX_ACL_ROLE: This command is used to let the wifi driver
+ * know whether the Bluetooth chip is master or slave in an ACL link.
+ * The role is available as %NL80211_ATTR_BTCOEX_ACL_ROLE. This feature is
+ * useful when the wireless device is a Bluetooth-Wifi coex solution.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -623,6 +648,11 @@ enum nl80211_commands {
NL80211_CMD_SET_REKEY_OFFLOAD,
+ NL80211_CMD_BTCOEX_INQ,
+ NL80211_CMD_BTCOEX_SCO,
+ NL80211_CMD_BTCOEX_A2DP,
+ NL80211_CMD_BTCOEX_ACL_ROLE,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -1045,6 +1075,33 @@ enum nl80211_commands {
* @NL80211_ATTR_STA_WME: Nested attribute containing the wme configuration
* of the station, see &enum nl80211_sta_wme_attr.
*
+ * @%NL80211_ATTR_BTCOEX_INQ_STATUS: A flag indicating if Bluetooth inquiry
+ * is in progress. this flag is useful for resource management in a
+ * bluetooth wifi combo solution.
+ *
+ * @%NL80211_ATTR_BTCOEX_SCO_STATUS: A flag indicating if Bluetooth SCO audio
+ * connection is active. this flag is useful for resource management in a
+ * bluetooth wifi combo solution.
+ *
+ * @%NL80211_ATTR_BTCOEX_TYPE_ESCO: A flag indicating if the audio connection
+ * is of type ESCO. If this attribute is available, the audio connection
+ * is of type ESCO. this information is useful for resource management
+ * in a bluetooth wifi combo solution.
+ *
+ * @%NL80211_ATTR_BTCOEX_SCO_MAX_SLOT: Provides the maximum number of slots
+ * possible for a SCO packet in an active SCO connection.
+ * this information is useful for resource management in a bluetooth
+ * wifi combo solution.
+ *
+ * @%NL80211_ATTR_BTCOEX_A2DP_STATUS: A flag indicating the Bluetooth
+ * A2DP connection status. This flag is useful for resource management
+ * in a bluetooth wifi combo solution.
+ *
+ * @%NL80211_ATTR_BTCOEX_ACL_ROLE: Indicates if Bluetooth chip's role
+ * in an ACL connection. See &enum nl80211_btcoex_acl_role for possible
+ * value. This flag is useful for resource management in a bluetooth
+ * wifi combo solution.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1257,6 +1314,13 @@ enum nl80211_attrs {
NL80211_ATTR_STA_WME,
+ NL80211_ATTR_BTCOEX_INQ_STATUS,
+ NL80211_ATTR_BTCOEX_SCO_STATUS,
+ NL80211_ATTR_BTCOEX_TYPE_ESCO,
+ NL80211_ATTR_BTCOEX_SCO_MAX_SLOT,
+ NL80211_ATTR_BTCOEX_A2DP_STATUS,
+ NL80211_ATTR_BTCOEX_ACL_ROLE,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -2505,4 +2569,13 @@ enum nl80211_sta_wme_attr {
NL80211_STA_WME_MAX = __NL80211_STA_WME_AFTER_LAST - 1
};
+/**
+ * enum nl80211_btcoex_acl_role - Bluetooth ACL link role
+ * @NL80211_BTCOEX_ACL_ROLE_MASTER: Bluetooth chip is in master role.
+ * @NL80211_BTCOEX_ACL_ROLE_SLAVE: Bluetooth chip is in slave role.
+ */
+enum nl80211_btcoex_acl_role {
+ NL80211_BTCOEX_ACL_ROLE_MASTER,
+ NL80211_BTCOEX_ACL_ROLE_SLAVE
+};
#endif /* __LINUX_NL80211_H */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index bddb559..da2d24f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -189,6 +189,12 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
.len = IEEE80211_MAX_DATA_LEN },
[NL80211_ATTR_IE_ASSOC_RESP] = { .type = NLA_BINARY,
.len = IEEE80211_MAX_DATA_LEN },
+ [NL80211_ATTR_BTCOEX_INQ_STATUS] = { .type = NLA_FLAG },
+ [NL80211_ATTR_BTCOEX_SCO_STATUS] = { .type = NLA_FLAG },
+ [NL80211_ATTR_BTCOEX_TYPE_ESCO] = { .type = NLA_FLAG },
+ [NL80211_ATTR_BTCOEX_SCO_MAX_SLOT] = { .type = NLA_U32 },
+ [NL80211_ATTR_BTCOEX_A2DP_STATUS] = { .type = NLA_FLAG },
+ [NL80211_ATTR_BTCOEX_ACL_ROLE] = { .type = NLA_U32 },
};
/* policy for the key attributes */
--
1.7.0.4
Hi Suraj,
> > Why would this need a userspace utility? Are you cloning some sort of
> > windows architecture here?
>
> Ugh, please trim your quotes and use a useful mailer that will indent things.
>
> > It will be the userpace bluez dbus events that can provide information
> > regarding the status of variout Bluetooth events.
> > On receiving that information, it can send corresponding NL80211
> > command.
>
> Doesn't the kernel's bluetooth subsystem already know anyway?
>
> Not all of the information I believe. Things like A2DP streaming will be best known at the userspace. Also, there is no way to tap these information at the kernel subsystem right now. But, there is a clear defined way to get these information at the userspace. Also, profile based information might not be available at the kernel space.
this looks like the total wrong approach to me. This needs to be done
between mac80211 and Bluetooth subsystems in the kernel directly. Going
through userspace for this is a pretty bad idea.
Especially if you wanna listen on D-Bus events from bluetoothd and then
run another process to then execute nl80211 commands looks like total
overhead at no gain. Not to talk about potential latency effects that
might be counterproductive.
What you really want is a way to mark A2DP channels for streaming from
userspace as streaming/realtime/priority so the Bluetooth subsystem
knows on what to do with it and that way can also tell mac80211
correctly about coex settings.
We are already settings flushable flags for A2DP streaming channels and
there is work ongoing for SO_PRIORITY support with L2CAP sockets.
Regards
Marcel
Hi Johannes,
________________________________________
From: Johannes Berg [[email protected]]
Sent: Wednesday, August 31, 2011 12:44 PM
To: Sumangala, Suraj
Cc: [email protected]; ath6kl-devel; Balasubramanian, senthilkumar; Mehta, Vipin; Valo, Kalle; [email protected]
Subject: Re: [RFC] nl80211: Added NL80211 commands for Bluetooth-WiFi coex
On Wed, 2011-08-31 at 11:55 +0530, Suraj Sumangala wrote:
> + NL80211_CMD_BTCOEX_INQ,
> + NL80211_CMD_BTCOEX_SCO,
> + NL80211_CMD_BTCOEX_A2DP,
> + NL80211_CMD_BTCOEX_ACL_ROLE,
> Why do you need all these commands and not just one BT config command
> that gives everything? Need to see more of the implementation but that
> seems pointless.
One reason I went this way is because some of the events for which commands are generated has different associated parameters associated with it.
But, I do understand your point and there is scope to club similar commands together.
I guess I will send another set of patches along with the cfg80211 callbacks.
-Suraj
SGkgTWFyY2VsLA0KDQoNCj4gdGhpcyBsb29rcyBsaWtlIHRoZSB0b3RhbCB3cm9uZyBhcHByb2Fj
aCB0byBtZS4gVGhpcyBuZWVkcyB0byBiZSBkb25lIGJldHdlZW4gbWFjODAyMTEgYW5kIEJsdWV0
b290aCBzdWJzeXN0ZW1zIGluIHRoZSBrZXJuZWwgZGlyZWN0bHkuIEdvaW5nIHRocm91Z2ggdXNl
cnNwYWNlIGZvciB0aGlzIGlzIGEgcHJldHR5IGJhZCBpZGVhLg0KDQo+IEVzcGVjaWFsbHkgaWYg
eW91IHdhbm5hIGxpc3RlbiBvbiBELUJ1cyBldmVudHMgZnJvbSBibHVldG9vdGhkIGFuZCB0aGVu
IHJ1biBhbm90aGVyIHByb2Nlc3MgdG8gdGhlbiBleGVjdXRlIG5sODAyMTEgY29tbWFuZHMgbG9v
a3MgbGlrZSB0b3RhbCBvdmVyaGVhZCBhdCBubyBnYWluLiBOb3QgdG8gdGFsayBhYm91dCBwb3Rl
bnRpYWwgbGF0ZW5jeSA+IGVmZmVjdHMgdGhhdCBtaWdodCBiZSBjb3VudGVycHJvZHVjdGl2ZS4N
Cg0KPiBXaGF0IHlvdSByZWFsbHkgd2FudCBpcyBhIHdheSB0byBtYXJrIEEyRFAgY2hhbm5lbHMg
Zm9yIHN0cmVhbWluZyBmcm9tIHVzZXJzcGFjZSBhcyBzdHJlYW1pbmcvcmVhbHRpbWUvcHJpb3Jp
dHkgc28gdGhlIEJsdWV0b290aCBzdWJzeXN0ZW0ga25vd3Mgb24gd2hhdCB0byBkbyB3aXRoIGl0
IGFuZCB0aGF0IHdheSBjYW4gYWxzbyB0ZWxsID4gPiBtYWM4MDIxMSBjb3JyZWN0bHkgYWJvdXQg
Y29leCBzZXR0aW5ncy4NCg0KPiBXZSBhcmUgYWxyZWFkeSBzZXR0aW5ncyBmbHVzaGFibGUgZmxh
Z3MgZm9yIEEyRFAgc3RyZWFtaW5nIGNoYW5uZWxzIGFuZCB0aGVyZSBpcyB3b3JrIG9uZ29pbmcg
Zm9yIFNPX1BSSU9SSVRZIHN1cHBvcnQgd2l0aCBMMkNBUCBzb2NrZXRzLg0KDQpNb3JlIHRoYW4g
dGhlIEEyRFAgY29ubmVjdGlvbiwgaXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdG8gZmluZCBvdXQg
d2hlbiBBMkRQIHN0YXJ0L3N0b3Agc3RyZWFtaW5nIHNvIHRoYXQgd2UgY2FuIGtub3cgd2hlbiB0
byByZWFsbG9jYXRlIHJlc291cmNlIHRvIEJsdWV0b290aC4gSXMgaXQgcG9zc2libGUgdG8gdGFw
IHRoaXMgaW5mb3JtYXRpb24gb3V0IG9mIHRoZSBCbHVldG9vdGggY29yZT8NCkFsc28sIGNhbiB5
b3Ugc3VnZ2VzdCBhIHdheSB0byBnZXQgQTJEUCBzdHJlYW1pbmcgc3RhdHVzLCBpbnF1aXJ5IHN0
YXR1cywgYW5kIFNDTyBhbmQgQUNMIHJvbGUgd2l0aG91dCBhIGhhY2sgaW4gdGhlIEJsdWV0b290
aCBzdWJzeXN0ZW0/DQoNCi1TdXJhag0K
On Wed, 2011-08-31 at 06:36 +0000, Sumangala, Suraj wrote:
> Hi johannes,
> ???
> Why would this need a userspace utility? Are you cloning some sort of
> windows architecture here?
Ugh, please trim your quotes and use a useful mailer that will indent things.
> It will be the userpace bluez dbus events that can provide information
> regarding the status of variout Bluetooth events.
> On receiving that information, it can send corresponding NL80211
> command.
Doesn't the kernel's bluetooth subsystem already know anyway?
johannes
On Wed, 2011-08-31 at 11:55 +0530, Suraj Sumangala wrote:
> This patch propose a new set of NL80211 commands and attributes
> to communicate information about ongoing Bluetooth operations to the
> wifi chip in case of a Bluetooth-WiFi coex solution.
>
> It can then be used by the WiFi hardware to understand the requirements
> of a Bluetooth radio and manage shared resources between
> Bluetooth and Wifi modules better.
>
> The proposed Bluetooth information sent are mainly regarding Bluetooth
> SCO, A2DP connection, inquiry and master/slave role of Bluetooth chip.
>
> This information can be sent by a userspace Bluetooth filter utility
> application to the WiFi driver.
???
Why would this need a userspace utility? Are you cloning some sort of
windows architecture here?
johannes
On Wed, 2011-08-31 at 11:55 +0530, Suraj Sumangala wrote:
> + NL80211_CMD_BTCOEX_INQ,
> + NL80211_CMD_BTCOEX_SCO,
> + NL80211_CMD_BTCOEX_A2DP,
> + NL80211_CMD_BTCOEX_ACL_ROLE,
Why do you need all these commands and not just one BT config command
that gives everything? Need to see more of the implementation but that
seems pointless.
johannes
Hi johannes,
________________________________________
From: Johannes Berg [[email protected]]
Sent: Wednesday, August 31, 2011 12:00 PM
To: Sumangala, Suraj
Cc: [email protected]; ath6kl-devel; Balasubramanian, senthilkumar; Mehta, Vipin; Valo, Kalle; [email protected]
Subject: Re: [RFC] nl80211: Added NL80211 commands for Bluetooth-WiFi coex
On Wed, 2011-08-31 at 11:55 +0530, Suraj Sumangala wrote:
> This patch propose a new set of NL80211 commands and attributes
> to communicate information about ongoing Bluetooth operations to the
> wifi chip in case of a Bluetooth-WiFi coex solution.
>
> It can then be used by the WiFi hardware to understand the requirements
> of a Bluetooth radio and manage shared resources between
> Bluetooth and Wifi modules better.
>
> The proposed Bluetooth information sent are mainly regarding Bluetooth
> SCO, A2DP connection, inquiry and master/slave role of Bluetooth chip.
>
> This information can be sent by a userspace Bluetooth filter utility
> application to the WiFi driver.
???
Why would this need a userspace utility? Are you cloning some sort of
windows architecture here?
johannes
It will be the userpace bluez dbus events that can provide information regarding the status of variout Bluetooth events.
On receiving that information, it can send corresponding NL80211 command.
Regards
Suraj
________________________________________
From: Johannes Berg [[email protected]]
Sent: Wednesday, August 31, 2011 12:10 PM
To: Sumangala, Suraj
Cc: [email protected]; ath6kl-devel; Balasubramanian, senthilkumar; Mehta, Vipin; Valo, Kalle; [email protected]
Subject: RE: [RFC] nl80211: Added NL80211 commands for Bluetooth-WiFi coex
On Wed, 2011-08-31 at 06:36 +0000, Sumangala, Suraj wrote:
> Hi johannes,
> ???
> Why would this need a userspace utility? Are you cloning some sort of
> windows architecture here?
Ugh, please trim your quotes and use a useful mailer that will indent things.
> It will be the userpace bluez dbus events that can provide information
> regarding the status of variout Bluetooth events.
> On receiving that information, it can send corresponding NL80211
> command.
Doesn't the kernel's bluetooth subsystem already know anyway?
Not all of the information I believe. Things like A2DP streaming will be best known at the userspace. Also, there is no way to tap these information at the kernel subsystem right now. But, there is a clear defined way to get these information at the userspace. Also, profile based information might not be available at the kernel space.
-Suraj
SGkgTWFyY2VsLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmNl
bCBIb2x0bWFubiBbbWFpbHRvOm1hcmNlbEBob2x0bWFubi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5
LCBTZXB0ZW1iZXIgMDEsIDIwMTEgNDoyMiBBTQ0KPiBUbzogU3VtYW5nYWxhLCBTdXJhag0KPiBD
YzogSm9oYW5uZXMgQmVyZzsgbGludmlsbGVAdHV4ZHJpdmVyLmNvbTsgYXRoNmtsLWRldmVsOyBC
YWxhc3VicmFtYW5pYW4sDQo+IHNlbnRoaWxrdW1hcjsgTWVodGEsIFZpcGluOyBWYWxvLCBLYWxs
ZTsgbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJFOiBbUkZDXSBu
bDgwMjExOiBBZGRlZCBOTDgwMjExIGNvbW1hbmRzIGZvciBCbHVldG9vdGgtV2lGaSBjb2V4DQo+
IA0KPiBIaSBTdXJhaiwNCj4gDQo+ID4gPiB0aGlzIGxvb2tzIGxpa2UgdGhlIHRvdGFsIHdyb25n
IGFwcHJvYWNoIHRvIG1lLiBUaGlzIG5lZWRzIHRvIGJlIGRvbmUNCj4gYmV0d2VlbiBtYWM4MDIx
MSBhbmQgQmx1ZXRvb3RoIHN1YnN5c3RlbXMgaW4gdGhlIGtlcm5lbCBkaXJlY3RseS4gR29pbmcN
Cj4gdGhyb3VnaCB1c2Vyc3BhY2UgZm9yIHRoaXMgaXMgYSBwcmV0dHkgYmFkIGlkZWEuDQo+ID4N
Cj4gPiA+IEVzcGVjaWFsbHkgaWYgeW91IHdhbm5hIGxpc3RlbiBvbiBELUJ1cyBldmVudHMgZnJv
bSBibHVldG9vdGhkIGFuZCB0aGVuIHJ1bg0KPiBhbm90aGVyIHByb2Nlc3MgdG8gdGhlbiBleGVj
dXRlIG5sODAyMTEgY29tbWFuZHMgbG9va3MgbGlrZSB0b3RhbCBvdmVyaGVhZCBhdA0KPiBubyBn
YWluLiBOb3QgdG8gdGFsayBhYm91dCBwb3RlbnRpYWwgbGF0ZW5jeSA+IGVmZmVjdHMgdGhhdCBt
aWdodCBiZQ0KPiBjb3VudGVycHJvZHVjdGl2ZS4NCj4gPg0KPiA+ID4gV2hhdCB5b3UgcmVhbGx5
IHdhbnQgaXMgYSB3YXkgdG8gbWFyayBBMkRQIGNoYW5uZWxzIGZvciBzdHJlYW1pbmcgZnJvbQ0K
PiB1c2Vyc3BhY2UgYXMgc3RyZWFtaW5nL3JlYWx0aW1lL3ByaW9yaXR5IHNvIHRoZSBCbHVldG9v
dGggc3Vic3lzdGVtIGtub3dzIG9uDQo+IHdoYXQgdG8gZG8gd2l0aCBpdCBhbmQgdGhhdCB3YXkg
Y2FuIGFsc28gdGVsbCA+ID4gbWFjODAyMTEgY29ycmVjdGx5IGFib3V0IGNvZXgNCj4gc2V0dGlu
Z3MuDQo+ID4NCj4gPiA+IFdlIGFyZSBhbHJlYWR5IHNldHRpbmdzIGZsdXNoYWJsZSBmbGFncyBm
b3IgQTJEUCBzdHJlYW1pbmcgY2hhbm5lbHMgYW5kIHRoZXJlDQo+IGlzIHdvcmsgb25nb2luZyBm
b3IgU09fUFJJT1JJVFkgc3VwcG9ydCB3aXRoIEwyQ0FQIHNvY2tldHMuDQo+ID4NCj4gPiBNb3Jl
IHRoYW4gdGhlIEEyRFAgY29ubmVjdGlvbiwgaXQgd291bGQgYmUgbW9yZSB1c2VmdWwgdG8gZmlu
ZCBvdXQgd2hlbg0KPiBBMkRQIHN0YXJ0L3N0b3Agc3RyZWFtaW5nIHNvIHRoYXQgd2UgY2FuIGtu
b3cgd2hlbiB0byByZWFsbG9jYXRlIHJlc291cmNlIHRvDQo+IEJsdWV0b290aC4gSXMgaXQgcG9z
c2libGUgdG8gdGFwIHRoaXMgaW5mb3JtYXRpb24gb3V0IG9mIHRoZSBCbHVldG9vdGggY29yZT8N
Cj4gPiBBbHNvLCBjYW4geW91IHN1Z2dlc3QgYSB3YXkgdG8gZ2V0IEEyRFAgc3RyZWFtaW5nIHN0
YXR1cywgaW5xdWlyeSBzdGF0dXMsIGFuZA0KPiBTQ08gYW5kIEFDTCByb2xlIHdpdGhvdXQgYSBo
YWNrIGluIHRoZSBCbHVldG9vdGggc3Vic3lzdGVtPw0KPiANCj4gdGhlIGlucXVpcnkgc3RhdHVz
IGlzIHRyYWNrZWQgYnkgdGhlIExpbnV4IGtlcm5lbCBzaW5jZSBldmVyLiBTYW1lIGdvZXMgZm9y
IEFDTA0KPiBhbmQgU0NPIHN0YXR1cy4gVGhlIGtlcm5lbCBrZWVwcyB0cmFjayBvdmVyIGFsbW9z
dCBldmVyeXRoaW5nIG9uIHRoZSBIQ0kgbGV2ZWwNCj4gYW5kIHdpbGwgZG8gcHJvcGVyIGNsZWFu
dXAgYWZ0ZXJ3YXJkcy4gRG9pbmcgdGhpcyBpbiB1c2Vyc3BhY2Ugd2lsbCBub3Qgd29yayBvdXQu
DQo+IEFuZCBpdCBpcyBhbHNvIHJhY3kuDQo+IA0KPiBFc3BlY2lhbGx5IGluIHRoZSBmdXR1cmUg
Ymx1ZXRvb3RoZCB3aWxsIGJlIHRyYWNraW5nIGxlc3MgYW5kIGxlc3MgaW5mb3JtYXRpb24uIFRo
ZQ0KPiBuZXcgbWFuYWdlbWVudCBpbnRlcmZhY2Ugd2lsbCBoaWRlIGFsbW9zdCBldmVyeSBzaW5n
bGUgc3RhdGUgZnJvbSBibHVldG9vdGhkDQo+IHdoZXJlIHRoZSBrZXJuZWwgaXMgZG9pbmcgdGhl
IGpvYiBhbnl3YXkgYW5kIGNhbiBkbyBhIHdheSBiZXR0ZXIgam9iIGluIHRoZSBmaXJzdA0KPiBw
bGFjZS4gVGhpcyBpcyBhbHNvIGxlYWRzIHRvIHBvd2VyIGNvbnN1bXB0aW9uIGFkdmFudGFnZXMg
c2luY2UgYmx1ZXRvb3RoZCBkb2VzDQo+IG5vdCBuZWVkIHRvIGJlIHdva2VuIHVwIHRoYXQgb2Z0
ZW4gYW55d2F5LiBBbmQgaW4gYWRkaXRpb24gdGhlIGtlcm5lbCBoYXMgbm90DQo+IGRlYWwgd2l0
aCB0aGUgZXh0cmEgSENJIGZpbHRlciBoYW5kbGluZy4NCj4gDQo+IFRoZSBvbmx5IHRoaW5nIHRo
YXQgeW91IG1lbnRpb25lZCBoZXJlIGlzIEEyRFAgc3RyZWFtaW5nLiBBbmQgYnkgdGhlIG5hdHVy
ZSBvZg0KPiB0aGUgQTJEUCBwcm90b2NvbCwgeW91IGRvIGVzdGFibGlzaCBhIHNlY29uZCBMMkNB
UCBjaGFubmVsIHRoYXQgaXMganVzdCB1c2VkIGZvcg0KPiBzdHJlYW1pbmcuIFRoYXQgY2hhbm5l
bCBpcyBhbHNvIG9ubHkgcHJlc2VudCBpZiB5b3UgYXJlIHN0cmVhbWluZyByaWdodCBub3cuIElm
IG5vdA0KPiBzdHJlYW1pbmcgaXMgZ29pbmcgb24sIGl0IHdpbGwgYmUgZGlzY29ubmVjdGVkLiBT
byBpdCBpcyBwcmV0dHkgZWFzeSB0byBoYXZlDQo+IGJsdWV0b290aGQgdGFnIHN1Y2ggYSBjaGFu
bmVsIHdpdGggcHJvcGVyIFNPX1BSSU9SSVRZIChvbmNlIHdlIGhhdmUgdGhhdCBjb2RlDQo+IG1l
cmdlZCB1cHN0cmVhbSkgYW5kIHRoZW4gdGhlIEJsdWV0b290aCBzdWJzeXN0ZW0ga25vd3Mgd2hl
biBBMkRQDQo+IHN0cmVhbWluZyBvciBhbnkgaGlnaCBwcmlvcml0eS9yZWFsdGltZSBkYXRhIGlz
IHRyYW5zZmVycmVkIG92ZXIgQmx1ZXRvb3RoLg0KPiANCj4gUmVnYXJkcw0KPiANCj4gTWFyY2Vs
DQo+IA0KDQpUaGFua3MuDQpSZWdhcmRpbmcgU0NPIGFuZCBJbnF1aXJ5IHN0YXR1cywgZG8gd2Ug
aGF2ZSBhbiBleGlzdGluZyBBUEkgaW4gQmx1ZXRvb3RoIGNvcmUgdGhhdCBJIGNhbiB1c2UgdG8g
Z2V0IHRoYXQgaW5mb3JtYXRpb24/DQoNClJlZ2FyZHMNClN1cmFqDQoNCg0K
Hi Marcel,
a minor nitpick:
On 09/01/2011 02:43 PM, Marcel Holtmann wrote:
> However first we need to establish in which direction this should be
> done anyway. Should the Bluetooth subsystem notify mac80211
> unconditional or should mac80211 register notifiers of the Bluetooth
> subsystem.
Not all wireless drivers use mac80211 so this should use cfg80211 instead.
Kalle
On Thu, 2011-09-01 at 04:43 -0700, Marcel Holtmann wrote:
> We also should not forget direct integration support for changing AFH
> channel maps based on the used WiFi channels.
I would really prefer to see that first, much simpler and it gives us an
idea of how to work across BT/wifi subsystems.
johannes
On Fri, 2011-09-02 at 07:54 +0000, Sumangala, Suraj wrote:
> If we can provide "hci_dev" as the handle to the Bluetooth core, does
> it make sense to follow the below steps to send channel
> classification?
> 1. Implement an NL80211 command to provide the Bluetooth BDADDR.
> 2. Send it down to the WiFi driver via a cfg80211 API.
> 3. Let it call "hci_get_route" to get a hci_hdev handle.
> 4. Export an API to set channel classification in Bluetooth HCI core.
> 5. Let the WiFi driver form the channel classification and call the
> Bluetooth core "write channel classification" API to set the channels.
I don't see any reason to have a specific wifi device talk to a specific
BT device. The channel exclusion makes more sense if all wifi devices
and all BT devices are taken into account. As such, only simple API is
needed to let cfg80211 tell bluez about the channels, and then bluez can
multiplex it out to all its BT devices.
johannes
Hi Suraj,
> > > > this looks like the total wrong approach to me. This needs to be done
> > between mac80211 and Bluetooth subsystems in the kernel directly. Going
> > through userspace for this is a pretty bad idea.
> > >
> > > > Especially if you wanna listen on D-Bus events from bluetoothd and then run
> > another process to then execute nl80211 commands looks like total overhead at
> > no gain. Not to talk about potential latency > effects that might be
> > counterproductive.
> > >
> > > > What you really want is a way to mark A2DP channels for streaming from
> > userspace as streaming/realtime/priority so the Bluetooth subsystem knows on
> > what to do with it and that way can also tell > > mac80211 correctly about coex
> > settings.
> > >
> > > > We are already settings flushable flags for A2DP streaming channels and there
> > is work ongoing for SO_PRIORITY support with L2CAP sockets.
> > >
> > > More than the A2DP connection, it would be more useful to find out when
> > A2DP start/stop streaming so that we can know when to reallocate resource to
> > Bluetooth. Is it possible to tap this information out of the Bluetooth core?
> > > Also, can you suggest a way to get A2DP streaming status, inquiry status, and
> > SCO and ACL role without a hack in the Bluetooth subsystem?
> >
> > the inquiry status is tracked by the Linux kernel since ever. Same goes for ACL
> > and SCO status. The kernel keeps track over almost everything on the HCI level
> > and will do proper cleanup afterwards. Doing this in userspace will not work out.
> > And it is also racy.
> >
> > Especially in the future bluetoothd will be tracking less and less information. The
> > new management interface will hide almost every single state from bluetoothd
> > where the kernel is doing the job anyway and can do a way better job in the first
> > place. This is also leads to power consumption advantages since bluetoothd does
> > not need to be woken up that often anyway. And in addition the kernel has not
> > deal with the extra HCI filter handling.
> >
> > The only thing that you mentioned here is A2DP streaming. And by the nature of
> > the A2DP protocol, you do establish a second L2CAP channel that is just used for
> > streaming. That channel is also only present if you are streaming right now. If not
> > streaming is going on, it will be disconnected. So it is pretty easy to have
> > bluetoothd tag such a channel with proper SO_PRIORITY (once we have that code
> > merged upstream) and then the Bluetooth subsystem knows when A2DP
> > streaming or any high priority/realtime data is transferred over Bluetooth.
>
> Regarding SCO and Inquiry status, do we have an existing API in Bluetooth core that I can use to get that information?
there is obviously no exported symbols or anything alike. Since we only
export things that are used by drivers or other subsystem. So you would
need to create such an API.
However first we need to establish in which direction this should be
done anyway. Should the Bluetooth subsystem notify mac80211
unconditional or should mac80211 register notifiers of the Bluetooth
subsystem.
We also should not forget direct integration support for changing AFH
channel maps based on the used WiFi channels.
Regards
Marcel
SGkgTWFyY2VsLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmNl
bCBIb2x0bWFubiBbbWFpbHRvOm1hcmNlbEBob2x0bWFubi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5
LCBTZXB0ZW1iZXIgMDEsIDIwMTEgNToxMyBQTQ0KPiBUbzogU3VtYW5nYWxhLCBTdXJhag0KPiBD
YzogSm9oYW5uZXMgQmVyZzsgbGludmlsbGVAdHV4ZHJpdmVyLmNvbTsgYXRoNmtsLWRldmVsOyBC
YWxhc3VicmFtYW5pYW4sDQo+IHNlbnRoaWxrdW1hcjsgTWVodGEsIFZpcGluOyBWYWxvLCBLYWxs
ZTsgbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJFOiBbUkZDXSBu
bDgwMjExOiBBZGRlZCBOTDgwMjExIGNvbW1hbmRzIGZvciBCbHVldG9vdGgtV2lGaSBjb2V4DQo+
IA0KPiBIaSBTdXJhaiwNCj4gDQo+ID4gPiA+ID4gdGhpcyBsb29rcyBsaWtlIHRoZSB0b3RhbCB3
cm9uZyBhcHByb2FjaCB0byBtZS4gVGhpcyBuZWVkcyB0byBiZQ0KPiA+ID4gPiA+IGRvbmUNCj4g
PiA+IGJldHdlZW4gbWFjODAyMTEgYW5kIEJsdWV0b290aCBzdWJzeXN0ZW1zIGluIHRoZSBrZXJu
ZWwgZGlyZWN0bHkuDQo+ID4gPiBHb2luZyB0aHJvdWdoIHVzZXJzcGFjZSBmb3IgdGhpcyBpcyBh
IHByZXR0eSBiYWQgaWRlYS4NCj4gPiA+ID4NCj4gPiA+ID4gPiBFc3BlY2lhbGx5IGlmIHlvdSB3
YW5uYSBsaXN0ZW4gb24gRC1CdXMgZXZlbnRzIGZyb20gYmx1ZXRvb3RoZA0KPiA+ID4gPiA+IGFu
ZCB0aGVuIHJ1bg0KPiA+ID4gYW5vdGhlciBwcm9jZXNzIHRvIHRoZW4gZXhlY3V0ZSBubDgwMjEx
IGNvbW1hbmRzIGxvb2tzIGxpa2UgdG90YWwNCj4gPiA+IG92ZXJoZWFkIGF0IG5vIGdhaW4uIE5v
dCB0byB0YWxrIGFib3V0IHBvdGVudGlhbCBsYXRlbmN5ID4gZWZmZWN0cw0KPiA+ID4gdGhhdCBt
aWdodCBiZSBjb3VudGVycHJvZHVjdGl2ZS4NCj4gPiA+ID4NCj4gPiA+ID4gPiBXaGF0IHlvdSBy
ZWFsbHkgd2FudCBpcyBhIHdheSB0byBtYXJrIEEyRFAgY2hhbm5lbHMgZm9yDQo+ID4gPiA+ID4g
c3RyZWFtaW5nIGZyb20NCj4gPiA+IHVzZXJzcGFjZSBhcyBzdHJlYW1pbmcvcmVhbHRpbWUvcHJp
b3JpdHkgc28gdGhlIEJsdWV0b290aCBzdWJzeXN0ZW0NCj4gPiA+IGtub3dzIG9uIHdoYXQgdG8g
ZG8gd2l0aCBpdCBhbmQgdGhhdCB3YXkgY2FuIGFsc28gdGVsbCA+ID4gbWFjODAyMTENCj4gPiA+
IGNvcnJlY3RseSBhYm91dCBjb2V4IHNldHRpbmdzLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFdlIGFy
ZSBhbHJlYWR5IHNldHRpbmdzIGZsdXNoYWJsZSBmbGFncyBmb3IgQTJEUCBzdHJlYW1pbmcNCj4g
PiA+ID4gPiBjaGFubmVscyBhbmQgdGhlcmUNCj4gPiA+IGlzIHdvcmsgb25nb2luZyBmb3IgU09f
UFJJT1JJVFkgc3VwcG9ydCB3aXRoIEwyQ0FQIHNvY2tldHMuDQo+ID4gPiA+DQo+ID4gPiA+IE1v
cmUgdGhhbiB0aGUgQTJEUCBjb25uZWN0aW9uLCBpdCB3b3VsZCBiZSBtb3JlIHVzZWZ1bCB0byBm
aW5kIG91dA0KPiA+ID4gPiB3aGVuDQo+ID4gPiBBMkRQIHN0YXJ0L3N0b3Agc3RyZWFtaW5nIHNv
IHRoYXQgd2UgY2FuIGtub3cgd2hlbiB0byByZWFsbG9jYXRlDQo+ID4gPiByZXNvdXJjZSB0byBC
bHVldG9vdGguIElzIGl0IHBvc3NpYmxlIHRvIHRhcCB0aGlzIGluZm9ybWF0aW9uIG91dCBvZiB0
aGUNCj4gQmx1ZXRvb3RoIGNvcmU/DQo+ID4gPiA+IEFsc28sIGNhbiB5b3Ugc3VnZ2VzdCBhIHdh
eSB0byBnZXQgQTJEUCBzdHJlYW1pbmcgc3RhdHVzLCBpbnF1aXJ5DQo+ID4gPiA+IHN0YXR1cywg
YW5kDQo+ID4gPiBTQ08gYW5kIEFDTCByb2xlIHdpdGhvdXQgYSBoYWNrIGluIHRoZSBCbHVldG9v
dGggc3Vic3lzdGVtPw0KPiA+ID4NCj4gPiA+IHRoZSBpbnF1aXJ5IHN0YXR1cyBpcyB0cmFja2Vk
IGJ5IHRoZSBMaW51eCBrZXJuZWwgc2luY2UgZXZlci4gU2FtZQ0KPiA+ID4gZ29lcyBmb3IgQUNM
IGFuZCBTQ08gc3RhdHVzLiBUaGUga2VybmVsIGtlZXBzIHRyYWNrIG92ZXIgYWxtb3N0DQo+ID4g
PiBldmVyeXRoaW5nIG9uIHRoZSBIQ0kgbGV2ZWwgYW5kIHdpbGwgZG8gcHJvcGVyIGNsZWFudXAg
YWZ0ZXJ3YXJkcy4gRG9pbmcgdGhpcw0KPiBpbiB1c2Vyc3BhY2Ugd2lsbCBub3Qgd29yayBvdXQu
DQo+ID4gPiBBbmQgaXQgaXMgYWxzbyByYWN5Lg0KPiA+ID4NCj4gPiA+IEVzcGVjaWFsbHkgaW4g
dGhlIGZ1dHVyZSBibHVldG9vdGhkIHdpbGwgYmUgdHJhY2tpbmcgbGVzcyBhbmQgbGVzcw0KPiA+
ID4gaW5mb3JtYXRpb24uIFRoZSBuZXcgbWFuYWdlbWVudCBpbnRlcmZhY2Ugd2lsbCBoaWRlIGFs
bW9zdCBldmVyeQ0KPiA+ID4gc2luZ2xlIHN0YXRlIGZyb20gYmx1ZXRvb3RoZCB3aGVyZSB0aGUg
a2VybmVsIGlzIGRvaW5nIHRoZSBqb2INCj4gPiA+IGFueXdheSBhbmQgY2FuIGRvIGEgd2F5IGJl
dHRlciBqb2IgaW4gdGhlIGZpcnN0IHBsYWNlLiBUaGlzIGlzIGFsc28NCj4gPiA+IGxlYWRzIHRv
IHBvd2VyIGNvbnN1bXB0aW9uIGFkdmFudGFnZXMgc2luY2UgYmx1ZXRvb3RoZCBkb2VzIG5vdCBu
ZWVkDQo+ID4gPiB0byBiZSB3b2tlbiB1cCB0aGF0IG9mdGVuIGFueXdheS4gQW5kIGluIGFkZGl0
aW9uIHRoZSBrZXJuZWwgaGFzIG5vdCBkZWFsDQo+IHdpdGggdGhlIGV4dHJhIEhDSSBmaWx0ZXIg
aGFuZGxpbmcuDQo+ID4gPg0KPiA+ID4gVGhlIG9ubHkgdGhpbmcgdGhhdCB5b3UgbWVudGlvbmVk
IGhlcmUgaXMgQTJEUCBzdHJlYW1pbmcuIEFuZCBieSB0aGUNCj4gPiA+IG5hdHVyZSBvZiB0aGUg
QTJEUCBwcm90b2NvbCwgeW91IGRvIGVzdGFibGlzaCBhIHNlY29uZCBMMkNBUCBjaGFubmVsDQo+
ID4gPiB0aGF0IGlzIGp1c3QgdXNlZCBmb3Igc3RyZWFtaW5nLiBUaGF0IGNoYW5uZWwgaXMgYWxz
byBvbmx5IHByZXNlbnQNCj4gPiA+IGlmIHlvdSBhcmUgc3RyZWFtaW5nIHJpZ2h0IG5vdy4gSWYg
bm90IHN0cmVhbWluZyBpcyBnb2luZyBvbiwgaXQNCj4gPiA+IHdpbGwgYmUgZGlzY29ubmVjdGVk
LiBTbyBpdCBpcyBwcmV0dHkgZWFzeSB0byBoYXZlIGJsdWV0b290aGQgdGFnDQo+ID4gPiBzdWNo
IGEgY2hhbm5lbCB3aXRoIHByb3BlciBTT19QUklPUklUWSAob25jZSB3ZSBoYXZlIHRoYXQgY29k
ZQ0KPiA+ID4gbWVyZ2VkIHVwc3RyZWFtKSBhbmQgdGhlbiB0aGUgQmx1ZXRvb3RoIHN1YnN5c3Rl
bSBrbm93cyB3aGVuIEEyRFANCj4gc3RyZWFtaW5nIG9yIGFueSBoaWdoIHByaW9yaXR5L3JlYWx0
aW1lIGRhdGEgaXMgdHJhbnNmZXJyZWQgb3ZlciBCbHVldG9vdGguDQo+ID4NCj4gPiBSZWdhcmRp
bmcgU0NPIGFuZCBJbnF1aXJ5IHN0YXR1cywgZG8gd2UgaGF2ZSBhbiBleGlzdGluZyBBUEkgaW4g
Qmx1ZXRvb3RoIGNvcmUNCj4gdGhhdCBJIGNhbiB1c2UgdG8gZ2V0IHRoYXQgaW5mb3JtYXRpb24/
DQo+IA0KPiB0aGVyZSBpcyBvYnZpb3VzbHkgbm8gZXhwb3J0ZWQgc3ltYm9scyBvciBhbnl0aGlu
ZyBhbGlrZS4gU2luY2Ugd2Ugb25seSBleHBvcnQNCj4gdGhpbmdzIHRoYXQgYXJlIHVzZWQgYnkg
ZHJpdmVycyBvciBvdGhlciBzdWJzeXN0ZW0uIFNvIHlvdSB3b3VsZCBuZWVkIHRvIGNyZWF0ZQ0K
PiBzdWNoIGFuIEFQSS4NCj4gDQo+IEhvd2V2ZXIgZmlyc3Qgd2UgbmVlZCB0byBlc3RhYmxpc2gg
aW4gd2hpY2ggZGlyZWN0aW9uIHRoaXMgc2hvdWxkIGJlIGRvbmUNCj4gYW55d2F5LiBTaG91bGQg
dGhlIEJsdWV0b290aCBzdWJzeXN0ZW0gbm90aWZ5IG1hYzgwMjExIHVuY29uZGl0aW9uYWwgb3IN
Cj4gc2hvdWxkIG1hYzgwMjExIHJlZ2lzdGVyIG5vdGlmaWVycyBvZiB0aGUgQmx1ZXRvb3RoIHN1
YnN5c3RlbS4NCj4gDQo+IFdlIGFsc28gc2hvdWxkIG5vdCBmb3JnZXQgZGlyZWN0IGludGVncmF0
aW9uIHN1cHBvcnQgZm9yIGNoYW5naW5nIEFGSCBjaGFubmVsDQo+IG1hcHMgYmFzZWQgb24gdGhl
IHVzZWQgV2lGaSBjaGFubmVscy4NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IE1hcmNlbA0KPiANCg0K
SWYgd2UgY2FuIHByb3ZpZGUgImhjaV9kZXYiIGFzIHRoZSBoYW5kbGUgdG8gdGhlIEJsdWV0b290
aCBjb3JlLCBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gZm9sbG93IHRoZSBiZWxvdyBzdGVwcyB0byBz
ZW5kIGNoYW5uZWwgY2xhc3NpZmljYXRpb24/DQoxLiBJbXBsZW1lbnQgYW4gTkw4MDIxMSBjb21t
YW5kIHRvIHByb3ZpZGUgdGhlIEJsdWV0b290aCBCREFERFIuDQoyLiBTZW5kIGl0IGRvd24gdG8g
dGhlIFdpRmkgZHJpdmVyIHZpYSBhIGNmZzgwMjExIEFQSS4NCjMuIExldCBpdCBjYWxsICJoY2lf
Z2V0X3JvdXRlIiB0byBnZXQgYSBoY2lfaGRldiBoYW5kbGUuDQo0LiBFeHBvcnQgYW4gQVBJIHRv
IHNldCBjaGFubmVsIGNsYXNzaWZpY2F0aW9uIGluIEJsdWV0b290aCBIQ0kgY29yZS4NCjUuIExl
dCB0aGUgV2lGaSBkcml2ZXIgZm9ybSB0aGUgY2hhbm5lbCBjbGFzc2lmaWNhdGlvbiBhbmQgY2Fs
bCB0aGUgQmx1ZXRvb3RoIGNvcmUgIndyaXRlIGNoYW5uZWwgY2xhc3NpZmljYXRpb24iIEFQSSB0
byBzZXQgdGhlIGNoYW5uZWxzLg0KDQpSZWdhcmRzDQpTdXJhag0KDQo=
Hi Suraj,
> > this looks like the total wrong approach to me. This needs to be done between mac80211 and Bluetooth subsystems in the kernel directly. Going through userspace for this is a pretty bad idea.
>
> > Especially if you wanna listen on D-Bus events from bluetoothd and then run another process to then execute nl80211 commands looks like total overhead at no gain. Not to talk about potential latency > effects that might be counterproductive.
>
> > What you really want is a way to mark A2DP channels for streaming from userspace as streaming/realtime/priority so the Bluetooth subsystem knows on what to do with it and that way can also tell > > mac80211 correctly about coex settings.
>
> > We are already settings flushable flags for A2DP streaming channels and there is work ongoing for SO_PRIORITY support with L2CAP sockets.
>
> More than the A2DP connection, it would be more useful to find out when A2DP start/stop streaming so that we can know when to reallocate resource to Bluetooth. Is it possible to tap this information out of the Bluetooth core?
> Also, can you suggest a way to get A2DP streaming status, inquiry status, and SCO and ACL role without a hack in the Bluetooth subsystem?
the inquiry status is tracked by the Linux kernel since ever. Same goes
for ACL and SCO status. The kernel keeps track over almost everything on
the HCI level and will do proper cleanup afterwards. Doing this in
userspace will not work out. And it is also racy.
Especially in the future bluetoothd will be tracking less and less
information. The new management interface will hide almost every single
state from bluetoothd where the kernel is doing the job anyway and can
do a way better job in the first place. This is also leads to power
consumption advantages since bluetoothd does not need to be woken up
that often anyway. And in addition the kernel has not deal with the
extra HCI filter handling.
The only thing that you mentioned here is A2DP streaming. And by the
nature of the A2DP protocol, you do establish a second L2CAP channel
that is just used for streaming. That channel is also only present if
you are streaming right now. If not streaming is going on, it will be
disconnected. So it is pretty easy to have bluetoothd tag such a channel
with proper SO_PRIORITY (once we have that code merged upstream) and
then the Bluetooth subsystem knows when A2DP streaming or any high
priority/realtime data is transferred over Bluetooth.
Regards
Marcel