[PATCH 0/3] LE New PHYs kernel interfaces

[PATCH 0/3] LE New PHYs kernel interfaces

[Jaganath Kanakkassery]

These patches enables user to get the supported phys by the
controller and set preferred phy to be used in subsequent
scanning and connection initiation.

Also added flags to support user selection for phy to be
advertised.

Jaganath Kanakkassery (3):
  doc/mgmt-api: Add support for Get supported phys command
  doc/mgmt-api: Add support for Set default Phy command
  doc/mgmt-api: Add advertising phys support to flags

 doc/mgmt-api.txt | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

-- 
2.7.4

[PATCH] Bluetooth: Define l2cap sock option for LE PHYs

[Jaganath Kanakkassery]

This defines two socket options, BT_LE_PHY and BT_LE_SUPPORTED_PHYS.

BT_LE_SUPPORTED_PHYS cab ne used to get supported phys of the peer devices.

BT_LE_PHY can be used to get the current phy of the connection and also
to switch phy for the connection.

Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
---
 include/net/bluetooth/bluetooth.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index e89cff0..f9271d1 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -122,6 +122,16 @@ struct bt_voice {
 #define BT_SNDMTU		12
 #define BT_RCVMTU		13
 
+/* This can be used for both set/get the current phy */
+#define BT_LE_PHY	14
+
+#define BT_LE_PHY_1M 		0
+#define BT_LE_PHY_2M		1
+#define BT_LE_PHY_CODED		2
+
+/* This can be used only for get peer supported phys */
+#define BT_LE_SUPPORTED_PHYS 15
+
 __printf(1, 2)
 void bt_info(const char *fmt, ...);
 __printf(1, 2)
-- 
2.7.4

[PATCH 1/3] doc/mgmt-api: Add support for Get supported phys command

[Jaganath Kanakkassery]

---
 doc/mgmt-api.txt | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 8e7de14..80edb14 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2916,6 +2916,29 @@ Set Appearance Command
 				Invalid Parameters
 				Invalid Index
 
+Get Supported PHYs Command
+==========================
+
+	Command Code:		0x0043
+	Controller Index:	<controller id>
+	Command Parameters:
+	Return Parameters:	Supported_phys (1 Octet)
+
+	This command is used to retrieve the supported phys by the
+	controller.
+
+	Supported_phys is a bitmask with the following bits.
+		0	LE 1M
+		1	LE 2M
+		2	LE CODED (LR)
+
+	LE 1M would be supported by default.
+
+	This command is only available for LE capable controllers.
+	It will return Not Supported otherwise.
+
+	Possible errors:	Not Supported
+				Invalid Index
 
 Command Complete Event
 ======================
-- 
2.7.4

Re: [PATCH 1/3] doc/mgmt-api: Add support for Get supported phys command

[Marcel Holtmann]

Hi Jaganath,

> ---
> doc/mgmt-api.txt | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 8e7de14..80edb14 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2916,6 +2916,29 @@ Set Appearance Command
> 				Invalid Parameters
> 				Invalid Index
> 
> +Get Supported PHYs Command
> +==========================
> +
> +	Command Code:		0x0043
> +	Controller Index:	<controller id>
> +	Command Parameters:
> +	Return Parameters:	Supported_phys (1 Octet)
> +
> +	This command is used to retrieve the supported phys by the
> +	controller.
> +
> +	Supported_phys is a bitmask with the following bits.
> +		0	LE 1M
> +		1	LE 2M
> +		2	LE CODED (LR)
> +
> +	LE 1M would be supported by default.
> +
> +	This command is only available for LE capable controllers.
> +	It will return Not Supported otherwise.
> +
> +	Possible errors:	Not Supported
> +				Invalid Index

please combine getting supported PHYs and configured/selected PHYs into a single patch.

This patch should also include the changes to the Supported_Settings / Current_Settings of Read Controller Information (and its extended version).

So we need to have an extra bit there.

	16   PHY configuration

For supported settings this will be available if either LE 2M or LE Coded is supported. And it will not be set if only LE 1M is supported (that is covered with the LE bit.

It is also important to note that even with LE 2M and LE Coded supported by the hardware, we should limit it to use only LE 1M and not actually allow any other PHYs (this might actually need some extra patch to make this the default).

And if either LE 2M or LE Coded is selected, then PHY configuration bit should be set.

For the supported and default PHYs, I think we need to split between TX and RX PHYs like the spec does.

Regards

Marcel

[PATCH 2/3] doc/mgmt-api: Add support for Set default Phy command

[Jaganath Kanakkassery]

---
 doc/mgmt-api.txt | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 80edb14..25739cc 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2940,6 +2940,42 @@ Get Supported PHYs Command
 	Possible errors:	Not Supported
 				Invalid Index
 
+Set Default PHY Command
+==========================
+
+	Command Code:		0x0044
+	Controller Index:	<controller id>
+	Command Parameters: 	Default_phy (1 Octet)
+	Return Parameters:
+
+	This command is used to set the default phy to the controller.
+
+	This will be stored and used for all the subsequent scanning
+	and connection initiation.
+
+	Prior to this, Get Supported PHYs Command shall be called
+	to retrieve the supported phys by the controller. If default_phy
+	has phy not supported by the controller (not there in supported_phys)
+	then Invalid Parameters will be returned.
+
+	This can be called at any point to change the preferred phys.
+
+	Default_phy is a bitmask with the following bits.
+
+		0	LE 1M
+		1	LE 2M
+		2	LE CODED (LR)
+
+	This command generates a Command Complete event on success
+	or a Command Status event on failure.
+
+	This command is only available for LE capable controllers.
+	It will return Not Supported otherwise.
+
+	Possible errors:	Not Supported
+				Invalid Parameters
+				Invalid Index
+
 Command Complete Event
 ======================
 
-- 
2.7.4

[PATCH 3/3] doc/mgmt-api: Add advertising phys support to flags

[Jaganath Kanakkassery]

Technically it is possible to advertise on LE Coded in Primary
and LE 1M/2M in secondary, but that is not added in the interface
since advertising in Coded means that scanners are expected to be
in long range and then advertising in other phys in secondary
does not make sense.
---
 doc/mgmt-api.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 25739cc..fe1c0a5 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2613,6 +2613,8 @@ Add Advertising Command
 		4	Add TX Power field to Adv_Data
 		5	Add Appearance field to Scan_Rsp
 		6	Add Local Name in Scan_Rsp
+		7 	Advertise in Coded PHY
+		8	Advertise in 2M PHY
 
 	When the connectable flag is set, then the controller will use
 	undirected connectable advertising. The value of the connectable
@@ -2640,6 +2642,16 @@ Add Advertising Command
 	supported to provide less air traffic for devices implementing
 	broadcaster role.
 
+	Advertising PHY flags should be used only if the controller
+	supports the corresponding phy which can be retrieved using
+	Get Supported Phys command otherwise Invalid Parameter would
+	be returned. If none of the flags are set and if controller
+	supports extended advertising then 1M would be used for both
+	Primary and Secondary channel. If 2M is set then 1M
+	would be selected for primary and 2M for secondary channel.
+	If Coded is set then it would be used for both primary
+	and secondary channels.
+
 	The Duration parameter configures the length of an Instance. The
 	value is in seconds.
 
-- 
2.7.4

Re: [PATCH 3/3] doc/mgmt-api: Add advertising phys support to flags

[Marcel Holtmann]

Hi Jaganath,

> Technically it is possible to advertise on LE Coded in Primary
> and LE 1M/2M in secondary, but that is not added in the interface
> since advertising in Coded means that scanners are expected to be
> in long range and then advertising in other phys in secondary
> does not make sense.
> ---
> doc/mgmt-api.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 25739cc..fe1c0a5 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2613,6 +2613,8 @@ Add Advertising Command
> 		4	Add TX Power field to Adv_Data
> 		5	Add Appearance field to Scan_Rsp
> 		6	Add Local Name in Scan_Rsp
> +		7 	Advertise in Coded PHY
> +		8	Advertise in 2M PHY
> 
> 	When the connectable flag is set, then the controller will use
> 	undirected connectable advertising. The value of the connectable
> @@ -2640,6 +2642,16 @@ Add Advertising Command
> 	supported to provide less air traffic for devices implementing
> 	broadcaster role.
> 
> +	Advertising PHY flags should be used only if the controller
> +	supports the corresponding phy which can be retrieved using
> +	Get Supported Phys command otherwise Invalid Parameter would
> +	be returned. If none of the flags are set and if controller

this has nothing to do with supported PHYs command. We have supported flags here and for advertising we need to treat this independent.

> +	supports extended advertising then 1M would be used for both
> +	Primary and Secondary channel. If 2M is set then 1M
> +	would be selected for primary and 2M for secondary channel.
> +	If Coded is set then it would be used for both primary
> +	and secondary channels.
> +

I think it might be more important that we use it like this:

	7  Secondary Channel with LE 1M
	8  Secondary Channel with LE 2M
	9  Secondary Channel with LE Coded

Specifying either of the three bits will result in extended advertising to be used. If not of them are set, then legacy advertising is used.

Combining them will result into multiple advertising sets to be created. If you specify all 3, then we actually required 3 advertising sets to be programmed.

Regards

Marcel

RE: [PATCH 3/3] doc/mgmt-api: Add advertising phys support to flags

[Kanakkassery, JaganathX]

Hi Marcel,

>Hi Jaganath,

>> Technically it is possible to advertise on LE Coded in Primary and LE=20
>> 1M/2M in secondary, but that is not added in the interface since=20
>> advertising in Coded means that scanners are expected to be in long=20
>> range and then advertising in other phys in secondary does not make=20
> >sense.
> >---
>> doc/mgmt-api.txt | 12 ++++++++++++
> >1 file changed, 12 insertions(+)
>>=20
> >diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt index=20
>> 25739cc..fe1c0a5 100644
>> --- a/doc/mgmt-api.txt
>> +++ b/doc/mgmt-api.txt
>> @@ -2613,6 +2613,8 @@ Add Advertising Command
> >		4	Add TX Power field to Adv_Data
>> 		5	Add Appearance field to Scan_Rsp
>> 		6	Add Local Name in Scan_Rsp
>> +		7 	Advertise in Coded PHY
>> +		8	Advertise in 2M PHY
>>=20
>> 	When the connectable flag is set, then the controller will use
>> 	undirected connectable advertising. The value of the connectable @@=20
>> -2640,6 +2642,16 @@ Add Advertising Command
> >	supported to provide less air traffic for devices implementing
> >	broadcaster role.
> >
> >+	Advertising PHY flags should be used only if the controller
>> +	supports the corresponding phy which can be retrieved using
>> +	Get Supported Phys command otherwise Invalid Parameter would
>> +	be returned. If none of the flags are set and if controller
>
>this has nothing to do with supported PHYs command. We have supported flag=
s here and for advertising we need to treat this >independent.

Ok...i missed that, so Read Advertising Features Command also needs to be u=
pdated with new flags

> +	supports extended advertising then 1M would be used for both
> +	Primary and Secondary channel. If 2M is set then 1M
> +	would be selected for primary and 2M for secondary channel.
> +	If Coded is set then it would be used for both primary
> +	and secondary channels.
> +
>
>I think it might be more important that we use it like this:

>	7  Secondary Channel with LE 1M
>	8  Secondary Channel with LE 2M
>	9  Secondary Channel with LE Coded
>
>Specifying either of the three bits will result in extended advertising to=
 be used. If not of them are set, then legacy advertising is used.

If I understood you correctly, you are suggesting to use legacy and extende=
d
advertising together (If in one Add adv none of them are set and in another
if atleast one of them is set). But I think it is not allowed by the spec.

As per spec, legacy and extended advertising commands cannot be used in
one power on session.=20

I was thinking of using extended advertising always if controller supports
so that it will by-pass the current multi adv by host and enables controlle=
r
to rotate the instances?=20
I think it has some power saving advantage since
host does not need to be awake to rotate the adv instances.

>Combining them will result into multiple advertising sets to be created. I=
f you specify all 3, then we actually required 3 advertising sets >to be pr=
ogrammed.

Thanks,
Jaganath