[PATCH 0/4 v4] LE New PHYs kernel interfaces

[PATCH 0/4 v4] 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 (4):
  doc/mgmt-api: Add support for Get PHY Configuration command
  doc/mgmt-api: Add support for Set Phy Configuration command
  doc/mgmt-api: Add advertising phys support to flags
  doc/mgmt-api: Update Duration Parameter description of Add Advertising

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

-- 
2.7.4

[PATCH 1/4 v4] doc/mgmt-api: Add support for Get PHY Configuration command

[Jaganath Kanakkassery]

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

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 8e7de14..c07c48c 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2871,6 +2871,7 @@ Read Extended Controller Information Command
 		13	Privacy
 		14	Controller Configuration
 		15	Static Address
+		16  	PHY configuration
 
 	The EIR_Data field contains information about class of device,
 	local name and other values. Not all of them might be present. For
@@ -2916,6 +2917,33 @@ Set Appearance Command
 				Invalid Parameters
 				Invalid Index
 
+Get PHY Configuration Command
+==========================
+
+	Command Code:		0x0043
+	Controller Index:	<controller id>
+	Command Parameters:
+	Return Parameters:	Supported_phys (2 Octet)
+				Selected_phys (2 Octet)
+
+	This command is used to retrieve the supported PHYs and currently
+	selected PHYs.
+
+	Supported_phys and Selected_phys is a bitmask with the following bits.
+		0	LE 1M TX
+		1	LE 1M RX
+		2	LE 2M TX
+		3	LE 2M RX
+		4	LE CODED TX
+		5	LE CODED RX
+
+	LE 1M TX and LE 1M RX 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/4 v4] doc/mgmt-api: Add support for Get PHY Configuration command

[Luiz Augusto von Dentz]

Hi Jaganath,

On Wed, Nov 29, 2017 at 4:52 AM, Jaganath Kanakkassery
<jaganath.k.os@gmail.com> wrote:
> ---
>  doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 8e7de14..c07c48c 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2871,6 +2871,7 @@ Read Extended Controller Information Command
>                 13      Privacy
>                 14      Controller Configuration
>                 15      Static Address
> +               16      PHY configuration
>
>         The EIR_Data field contains information about class of device,
>         local name and other values. Not all of them might be present. For
> @@ -2916,6 +2917,33 @@ Set Appearance Command
>                                 Invalid Parameters
>                                 Invalid Index
>
> +Get PHY Configuration Command
> +==========================
> +
> +       Command Code:           0x0043
> +       Controller Index:       <controller id>
> +       Command Parameters:
> +       Return Parameters:      Supported_phys (2 Octet)
> +                               Selected_phys (2 Octet)
> +
> +       This command is used to retrieve the supported PHYs and currently
> +       selected PHYs.
> +
> +       Supported_phys and Selected_phys is a bitmask with the following bits.
> +               0       LE 1M TX
> +               1       LE 1M RX
> +               2       LE 2M TX
> +               3       LE 2M RX
> +               4       LE CODED TX
> +               5       LE CODED RX
> +
> +       LE 1M TX and LE 1M RX 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

Are you still working on this, these perhaps we should integrate and
start working on setting 2M whenever available.

-- 
Luiz Augusto von Dentz

Re: [PATCH 1/4 v4] doc/mgmt-api: Add support for Get PHY Configuration command

[Jaganath K]

Hi Luiz,


> Hi Jaganath,
>
> On Wed, Nov 29, 2017 at 4:52 AM, Jaganath Kanakkassery
> <jaganath.k.os@gmail.com> wrote:
>> ---
>>  doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>> index 8e7de14..c07c48c 100644
>> --- a/doc/mgmt-api.txt
>> +++ b/doc/mgmt-api.txt
>> @@ -2871,6 +2871,7 @@ Read Extended Controller Information Command
>>                 13      Privacy
>>                 14      Controller Configuration
>>                 15      Static Address
>> +               16      PHY configuration
>>
>>         The EIR_Data field contains information about class of device,
>>         local name and other values. Not all of them might be present. For
>> @@ -2916,6 +2917,33 @@ Set Appearance Command
>>                                 Invalid Parameters
>>                                 Invalid Index
>>
>> +Get PHY Configuration Command
>> +==========================
>> +
>> +       Command Code:           0x0043
>> +       Controller Index:       <controller id>
>> +       Command Parameters:
>> +       Return Parameters:      Supported_phys (2 Octet)
>> +                               Selected_phys (2 Octet)
>> +
>> +       This command is used to retrieve the supported PHYs and currently
>> +       selected PHYs.
>> +
>> +       Supported_phys and Selected_phys is a bitmask with the following bits.
>> +               0       LE 1M TX
>> +               1       LE 1M RX
>> +               2       LE 2M TX
>> +               3       LE 2M RX
>> +               4       LE CODED TX
>> +               5       LE CODED RX
>> +
>> +       LE 1M TX and LE 1M RX 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
>
> Are you still working on this, these perhaps we should integrate and
> start working on setting 2M whenever available.

Yes, actually i had already raised RFC patches for these.
I will raise non RFC patches in a while.

Thanks,
Jaganath

[PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath Kanakkassery]

This also adds PHY Configuration Changed Event.
---
 doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index c07c48c..628ff18 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2940,9 +2940,46 @@ Get PHY Configuration Command
 	LE 1M TX and LE 1M RX 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
+
+Set PHY Configuration Command
+=============================
+
+	Command Code:		0x0044
+	Controller Index:	<controller id>
+	Command Parameters: 	Default_phys (2 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.
+
+	The list of supported PHYs can be retrieved via the
+	Get PHY Configuration command. Selecting unsupported PHYs will
+	result in an Invalid Parameters	error.
+
+	This can be called at any point to change the preferred PHYs.
+
+	Default_phy is a bitmask with the following bits.
+		0	LE 1M TX
+		1	LE 1M RX
+		2	LE 2M TX
+		3	LE 2M RX
+		4	LE CODED TX
+		5	LE CODED RX
+
+	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
@@ -3810,3 +3847,18 @@ Extended Controller Information Changed Event
 
 	The event will only be sent to management sockets other than the
 	one through which the change was triggered.
+
+PHY Configuration Changed Event
+===============================
+
+	Event Code:		0x0026
+	Controller Index:	<controller id>
+	Event Parameters:	Selected_phys (2 Octets)
+
+	This event indicates that default PHYs have been updated.
+
+	This event will only be used after Set PHY Configuration
+	command has been used at least once.
+
+	The event will only be sent to management sockets other than the
+	one through which the change was triggered.
-- 
2.7.4

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath K]

Hi Marcel,


On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
<jaganath.k.os@gmail.com> wrote:
> This also adds PHY Configuration Changed Event.
> ---
>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index c07c48c..628ff18 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>         LE 1M TX and LE 1M RX 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
> +
> +Set PHY Configuration Command
> +=============================
> +
> +       Command Code:           0x0044
> +       Controller Index:       <controller id>
> +       Command Parameters:     Default_phys (2 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.
> +
> +       The list of supported PHYs can be retrieved via the
> +       Get PHY Configuration command. Selecting unsupported PHYs will
> +       result in an Invalid Parameters error.
> +
> +       This can be called at any point to change the preferred PHYs.
> +
> +       Default_phy is a bitmask with the following bits.
> +               0       LE 1M TX
> +               1       LE 1M RX
> +               2       LE 2M TX
> +               3       LE 2M RX
> +               4       LE CODED TX
> +               5       LE CODED RX
> +
> +       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
>

I think there is a limitation with current API proposal, user cannot do extended
scanning in only 1M (to scan secondary channel in 1M) since with 1M we will
switch to legacy scanning.

I think we need two more flags eg: 1MTX-SEC & 1MRX-SEC, if set we will
use extended scanning in !M.

Plz let me know your opinion.

Thanks,
Jaganath

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Luiz Augusto von Dentz]

Hi Jaganath,

On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com> wrote:
> Hi Marcel,
>
>
> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
> <jaganath.k.os@gmail.com> wrote:
>> This also adds PHY Configuration Changed Event.
>> ---
>>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>>
>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>> index c07c48c..628ff18 100644
>> --- a/doc/mgmt-api.txt
>> +++ b/doc/mgmt-api.txt
>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>         LE 1M TX and LE 1M RX 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
>> +
>> +Set PHY Configuration Command
>> +=============================
>> +
>> +       Command Code:           0x0044
>> +       Controller Index:       <controller id>
>> +       Command Parameters:     Default_phys (2 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.
>> +
>> +       The list of supported PHYs can be retrieved via the
>> +       Get PHY Configuration command. Selecting unsupported PHYs will
>> +       result in an Invalid Parameters error.
>> +
>> +       This can be called at any point to change the preferred PHYs.
>> +
>> +       Default_phy is a bitmask with the following bits.
>> +               0       LE 1M TX
>> +               1       LE 1M RX
>> +               2       LE 2M TX
>> +               3       LE 2M RX
>> +               4       LE CODED TX
>> +               5       LE CODED RX
>> +
>> +       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
>>
>
> I think there is a limitation with current API proposal, user cannot do extended
> scanning in only 1M (to scan secondary channel in 1M) since with 1M we will
> switch to legacy scanning.

Why do we have to switch to legacy scanning for 1M? It seems it would
be possible to use extended scanning whenever it is supported
regardless of the PHY, or perhaps the spec imposes limitations to
certain PHYs? Coded perhaps?

> I think we need two more flags eg: 1MTX-SEC & 1MRX-SEC, if set we will
> use extended scanning in !M.
>
> Plz let me know your opinion.
>
> Thanks,
> Jaganath
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath K]

Hi Luiz,


On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Jaganath,
>
> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com> wrote:
>> Hi Marcel,
>>
>>
>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>> <jaganath.k.os@gmail.com> wrote:
>>> This also adds PHY Configuration Changed Event.
>>> ---
>>>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 52 insertions(+)
>>>
>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>> index c07c48c..628ff18 100644
>>> --- a/doc/mgmt-api.txt
>>> +++ b/doc/mgmt-api.txt
>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>         LE 1M TX and LE 1M RX 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
>>> +
>>> +Set PHY Configuration Command
>>> +=============================
>>> +
>>> +       Command Code:           0x0044
>>> +       Controller Index:       <controller id>
>>> +       Command Parameters:     Default_phys (2 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.
>>> +
>>> +       The list of supported PHYs can be retrieved via the
>>> +       Get PHY Configuration command. Selecting unsupported PHYs will
>>> +       result in an Invalid Parameters error.
>>> +
>>> +       This can be called at any point to change the preferred PHYs.
>>> +
>>> +       Default_phy is a bitmask with the following bits.
>>> +               0       LE 1M TX
>>> +               1       LE 1M RX
>>> +               2       LE 2M TX
>>> +               3       LE 2M RX
>>> +               4       LE CODED TX
>>> +               5       LE CODED RX
>>> +
>>> +       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
>>>
>>
>> I think there is a limitation with current API proposal, user cannot do extended
>> scanning in only 1M (to scan secondary channel in 1M) since with 1M we will
>> switch to legacy scanning.
>
> Why do we have to switch to legacy scanning for 1M? It seems it would
> be possible to use extended scanning whenever it is supported
> regardless of the PHY, or perhaps the spec imposes limitations to
> certain PHYs? Coded perhaps?
>

The idea is to enable application to use legacy scanning even if
controller supports
extended. (ie if application dont want extended features to be used)
and unlike advertising
legacy scanning can not be emulated using extended scanning.

Thanks,
Jaganath

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Łukasz Rymanowski]

Hi Jaganath,

On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@gmail.com> wrote:
> Hi Luiz,
>
>
> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Jaganath,
>>
>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com> wrote:
>>> Hi Marcel,
>>>
>>>
>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>> <jaganath.k.os@gmail.com> wrote:
>>>> This also adds PHY Configuration Changed Event.
>>>> ---
>>>>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 52 insertions(+)
>>>>
>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>> index c07c48c..628ff18 100644
>>>> --- a/doc/mgmt-api.txt
>>>> +++ b/doc/mgmt-api.txt
>>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>>         LE 1M TX and LE 1M RX 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
>>>> +
>>>> +Set PHY Configuration Command
>>>> +=============================
>>>> +
>>>> +       Command Code:           0x0044
>>>> +       Controller Index:       <controller id>
>>>> +       Command Parameters:     Default_phys (2 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.
>>>> +
>>>> +       The list of supported PHYs can be retrieved via the
>>>> +       Get PHY Configuration command. Selecting unsupported PHYs will
>>>> +       result in an Invalid Parameters error.
>>>> +
>>>> +       This can be called at any point to change the preferred PHYs.
>>>> +
>>>> +       Default_phy is a bitmask with the following bits.
>>>> +               0       LE 1M TX
>>>> +               1       LE 1M RX
>>>> +               2       LE 2M TX
>>>> +               3       LE 2M RX
>>>> +               4       LE CODED TX
>>>> +               5       LE CODED RX
>>>> +
>>>> +       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
>>>>
>>>
>>> I think there is a limitation with current API proposal, user cannot do extended
>>> scanning in only 1M (to scan secondary channel in 1M) since with 1M we will
>>> switch to legacy scanning.
>>
>> Why do we have to switch to legacy scanning for 1M? It seems it would
>> be possible to use extended scanning whenever it is supported
>> regardless of the PHY, or perhaps the spec imposes limitations to
>> certain PHYs? Coded perhaps?
>>
>
> The idea is to enable application to use legacy scanning even if
> controller supports
> extended. (ie if application dont want extended features to be used)
> and unlike advertising
> legacy scanning can not be emulated using extended scanning.

Bluetooth controller which is doing extended scanning will report legacy
advertisings as well. It will just use Extended Advertising Report
Event for this purpose and Linux Kernel should handle it.

>
> Thanks,
> Jaganath
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath K]

Hi Lukasz,

On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
<lukasz.rymanowski@codecoup.pl> wrote:
> Hi Jaganath,
>
> On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@gmail.com> wrote:
>> Hi Luiz,
>>
>>
>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>> <luiz.dentz@gmail.com> wrote:
>>> Hi Jaganath,
>>>
>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com> w=
rote:
>>>> Hi Marcel,
>>>>
>>>>
>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>> <jaganath.k.os@gmail.com> wrote:
>>>>> This also adds PHY Configuration Changed Event.
>>>>> ---
>>>>>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++=
++++++
>>>>>  1 file changed, 52 insertions(+)
>>>>>
>>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>>> index c07c48c..628ff18 100644
>>>>> --- a/doc/mgmt-api.txt
>>>>> +++ b/doc/mgmt-api.txt
>>>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>>>         LE 1M TX and LE 1M RX 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
>>>>> +
>>>>> +Set PHY Configuration Command
>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>>> +
>>>>> +       Command Code:           0x0044
>>>>> +       Controller Index:       <controller id>
>>>>> +       Command Parameters:     Default_phys (2 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.
>>>>> +
>>>>> +       The list of supported PHYs can be retrieved via the
>>>>> +       Get PHY Configuration command. Selecting unsupported PHYs wil=
l
>>>>> +       result in an Invalid Parameters error.
>>>>> +
>>>>> +       This can be called at any point to change the preferred PHYs.
>>>>> +
>>>>> +       Default_phy is a bitmask with the following bits.
>>>>> +               0       LE 1M TX
>>>>> +               1       LE 1M RX
>>>>> +               2       LE 2M TX
>>>>> +               3       LE 2M RX
>>>>> +               4       LE CODED TX
>>>>> +               5       LE CODED RX
>>>>> +
>>>>> +       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
>>>>>
>>>>
>>>> I think there is a limitation with current API proposal, user cannot d=
o extended
>>>> scanning in only 1M (to scan secondary channel in 1M) since with 1M we=
 will
>>>> switch to legacy scanning.
>>>
>>> Why do we have to switch to legacy scanning for 1M? It seems it would
>>> be possible to use extended scanning whenever it is supported
>>> regardless of the PHY, or perhaps the spec imposes limitations to
>>> certain PHYs? Coded perhaps?
>>>
>>
>> The idea is to enable application to use legacy scanning even if
>> controller supports
>> extended. (ie if application dont want extended features to be used)
>> and unlike advertising
>> legacy scanning can not be emulated using extended scanning.
>
> Bluetooth controller which is doing extended scanning will report legacy
> advertisings as well. It will just use Extended Advertising Report
> Event for this purpose and Linux Kernel should handle it.
>

Yes, but the idea here is more on perspective of power savings
where in application dont want to scan on secondary channels itself and
API should support it.

Thanks,
Jaganath

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Luiz Augusto von Dentz]

Hi Jaganath,

On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <jaganath.k.os@gmail.com> wrot=
e:
> Hi Lukasz,
>
> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
> <lukasz.rymanowski@codecoup.pl> wrote:
>> Hi Jaganath,
>>
>> On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@gmail.com> wrote=
:
>>> Hi Luiz,
>>>
>>>
>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi Jaganath,
>>>>
>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com> =
wrote:
>>>>> Hi Marcel,
>>>>>
>>>>>
>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>> <jaganath.k.os@gmail.com> wrote:
>>>>>> This also adds PHY Configuration Changed Event.
>>>>>> ---
>>>>>>  doc/mgmt-api.txt | 52 +++++++++++++++++++++++++++++++++++++++++++++=
+++++++
>>>>>>  1 file changed, 52 insertions(+)
>>>>>>
>>>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>>>> index c07c48c..628ff18 100644
>>>>>> --- a/doc/mgmt-api.txt
>>>>>> +++ b/doc/mgmt-api.txt
>>>>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>>>>         LE 1M TX and LE 1M RX 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
>>>>>> +
>>>>>> +Set PHY Configuration Command
>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>>>> +
>>>>>> +       Command Code:           0x0044
>>>>>> +       Controller Index:       <controller id>
>>>>>> +       Command Parameters:     Default_phys (2 Octet)
>>>>>> +       Return Parameters:
>>>>>> +
>>>>>> +       This command is used to set the default phy to the controlle=
r.
>>>>>> +
>>>>>> +       This will be stored and used for all the subsequent scanning
>>>>>> +       and connection initiation.
>>>>>> +
>>>>>> +       The list of supported PHYs can be retrieved via the
>>>>>> +       Get PHY Configuration command. Selecting unsupported PHYs wi=
ll
>>>>>> +       result in an Invalid Parameters error.
>>>>>> +
>>>>>> +       This can be called at any point to change the preferred PHYs=
.
>>>>>> +
>>>>>> +       Default_phy is a bitmask with the following bits.
>>>>>> +               0       LE 1M TX
>>>>>> +               1       LE 1M RX
>>>>>> +               2       LE 2M TX
>>>>>> +               3       LE 2M RX
>>>>>> +               4       LE CODED TX
>>>>>> +               5       LE CODED RX
>>>>>> +
>>>>>> +       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
>>>>>>
>>>>>
>>>>> I think there is a limitation with current API proposal, user cannot =
do extended
>>>>> scanning in only 1M (to scan secondary channel in 1M) since with 1M w=
e will
>>>>> switch to legacy scanning.
>>>>
>>>> Why do we have to switch to legacy scanning for 1M? It seems it would
>>>> be possible to use extended scanning whenever it is supported
>>>> regardless of the PHY, or perhaps the spec imposes limitations to
>>>> certain PHYs? Coded perhaps?
>>>>
>>>
>>> The idea is to enable application to use legacy scanning even if
>>> controller supports
>>> extended. (ie if application dont want extended features to be used)
>>> and unlike advertising
>>> legacy scanning can not be emulated using extended scanning.
>>
>> Bluetooth controller which is doing extended scanning will report legacy
>> advertisings as well. It will just use Extended Advertising Report
>> Event for this purpose and Linux Kernel should handle it.
>>
>
> Yes, but the idea here is more on perspective of power savings
> where in application dont want to scan on secondary channels itself and
> API should support it.

I would agree if this affects passive scanning, but in that case we
can probably program the scan type when adding a device or only really
scan on primary channel since the purpose is to connect it doesn't
really matter what is on the secondary channels, for active scanning I
don't think we would be saving that much power since that should be
short-lived so Im not sure we should bother with it.

--=20
Luiz Augusto von Dentz

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Łukasz Rymanowski]

Hi Luiz, Jaganath

On 19 February 2018 at 11:31, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Jaganath,
>
> On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <jaganath.k.os@gmail.com> wr=
ote:
>> Hi Lukasz,
>>
>> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
>> <lukasz.rymanowski@codecoup.pl> wrote:
>>> Hi Jaganath,
>>>
>>> On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@gmail.com> wrot=
e:
>>>> Hi Luiz,
>>>>
>>>>
>>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>>> <luiz.dentz@gmail.com> wrote:
>>>>> Hi Jaganath,
>>>>>
>>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com>=
 wrote:
>>>>>> Hi Marcel,
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>>> <jaganath.k.os@gmail.com> wrote:
>>>>>>> This also adds PHY Configuration Changed Event.
>>>>>>> ---
>>>>>>>  doc/mgmt-api.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++=
++++++++
>>>>>>>  1 file changed, 52 insertions(+)
>>>>>>>
>>>>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>>>>> index c07c48c..628ff18 100644
>>>>>>> --- a/doc/mgmt-api.txt
>>>>>>> +++ b/doc/mgmt-api.txt
>>>>>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>>>>>         LE 1M TX and LE 1M RX 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
>>>>>>> +
>>>>>>> +Set PHY Configuration Command
>>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>>>>> +
>>>>>>> +       Command Code:           0x0044
>>>>>>> +       Controller Index:       <controller id>
>>>>>>> +       Command Parameters:     Default_phys (2 Octet)
>>>>>>> +       Return Parameters:
>>>>>>> +
>>>>>>> +       This command is used to set the default phy to the controll=
er.
>>>>>>> +
>>>>>>> +       This will be stored and used for all the subsequent scannin=
g
>>>>>>> +       and connection initiation.
>>>>>>> +
>>>>>>> +       The list of supported PHYs can be retrieved via the
>>>>>>> +       Get PHY Configuration command. Selecting unsupported PHYs w=
ill
>>>>>>> +       result in an Invalid Parameters error.
>>>>>>> +
>>>>>>> +       This can be called at any point to change the preferred PHY=
s.
>>>>>>> +
>>>>>>> +       Default_phy is a bitmask with the following bits.
>>>>>>> +               0       LE 1M TX
>>>>>>> +               1       LE 1M RX
>>>>>>> +               2       LE 2M TX
>>>>>>> +               3       LE 2M RX
>>>>>>> +               4       LE CODED TX
>>>>>>> +               5       LE CODED RX
>>>>>>> +
>>>>>>> +       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
>>>>>>>
>>>>>>
>>>>>> I think there is a limitation with current API proposal, user cannot=
 do extended
>>>>>> scanning in only 1M (to scan secondary channel in 1M) since with 1M =
we will
>>>>>> switch to legacy scanning.
>>>>>
>>>>> Why do we have to switch to legacy scanning for 1M? It seems it would
>>>>> be possible to use extended scanning whenever it is supported
>>>>> regardless of the PHY, or perhaps the spec imposes limitations to
>>>>> certain PHYs? Coded perhaps?
>>>>>
>>>>
>>>> The idea is to enable application to use legacy scanning even if
>>>> controller supports
>>>> extended. (ie if application dont want extended features to be used)
>>>> and unlike advertising
>>>> legacy scanning can not be emulated using extended scanning.
>>>
>>> Bluetooth controller which is doing extended scanning will report legac=
y
>>> advertisings as well. It will just use Extended Advertising Report
>>> Event for this purpose and Linux Kernel should handle it.
>>>
>>
>> Yes, but the idea here is more on perspective of power savings
>> where in application dont want to scan on secondary channels itself and
>> API should support it.

Then maybe there should not be dependence between this command and scan/con=
nect.
Actually I do not understand why we have it, need to check previous
conversation.

>
> I would agree if this affects passive scanning, but in that case we
> can probably program the scan type when adding a device or only really
> scan on primary channel since the purpose is to connect it doesn't
> really matter what is on the secondary channels, for active scanning I
> don't think we would be saving that much power since that should be
> short-lived so Im not sure we should bother with it.

In extended advertising there is no such thing as connectable and
scannable at the same time
When device is connectable, then address and optionally advertising
data is in the aux ptr (secondary channel)

Please also remember that it is up to controller to connect / scan on
secondary PHY based on primary PHY provided by host.
Meaning, host controls primary channel only, which can be 1M or Coded.
Rest is up to controller and data in AUX_PTR of ADV_EXT_IND

>
> --
> Luiz Augusto von Dentz

=C5=81ukasz

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath K]

Hi Lukasz, Luiz,


On Mon, Feb 19, 2018 at 4:37 PM, =C5=81ukasz Rymanowski
<lukasz.rymanowski@codecoup.pl> wrote:
> Hi Luiz, Jaganath
>
> On 19 February 2018 at 11:31, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Jaganath,
>>
>> On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <jaganath.k.os@gmail.com> w=
rote:
>>> Hi Lukasz,
>>>
>>> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
>>> <lukasz.rymanowski@codecoup.pl> wrote:
>>>> Hi Jaganath,
>>>>
>>>> On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@gmail.com> wro=
te:
>>>>> Hi Luiz,
>>>>>
>>>>>
>>>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>> Hi Jaganath,
>>>>>>
>>>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@gmail.com=
> wrote:
>>>>>>> Hi Marcel,
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>>>> <jaganath.k.os@gmail.com> wrote:
>>>>>>>> This also adds PHY Configuration Changed Event.
>>>>>>>> ---
>>>>>>>>  doc/mgmt-api.txt | 52 +++++++++++++++++++++++++++++++++++++++++++=
+++++++++
>>>>>>>>  1 file changed, 52 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>>>>>> index c07c48c..628ff18 100644
>>>>>>>> --- a/doc/mgmt-api.txt
>>>>>>>> +++ b/doc/mgmt-api.txt
>>>>>>>> @@ -2940,9 +2940,46 @@ Get PHY Configuration Command
>>>>>>>>         LE 1M TX and LE 1M RX 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
>>>>>>>> +
>>>>>>>> +Set PHY Configuration Command
>>>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>>>> +
>>>>>>>> +       Command Code:           0x0044
>>>>>>>> +       Controller Index:       <controller id>
>>>>>>>> +       Command Parameters:     Default_phys (2 Octet)
>>>>>>>> +       Return Parameters:
>>>>>>>> +
>>>>>>>> +       This command is used to set the default phy to the control=
ler.
>>>>>>>> +
>>>>>>>> +       This will be stored and used for all the subsequent scanni=
ng
>>>>>>>> +       and connection initiation.
>>>>>>>> +
>>>>>>>> +       The list of supported PHYs can be retrieved via the
>>>>>>>> +       Get PHY Configuration command. Selecting unsupported PHYs =
will
>>>>>>>> +       result in an Invalid Parameters error.
>>>>>>>> +
>>>>>>>> +       This can be called at any point to change the preferred PH=
Ys.
>>>>>>>> +
>>>>>>>> +       Default_phy is a bitmask with the following bits.
>>>>>>>> +               0       LE 1M TX
>>>>>>>> +               1       LE 1M RX
>>>>>>>> +               2       LE 2M TX
>>>>>>>> +               3       LE 2M RX
>>>>>>>> +               4       LE CODED TX
>>>>>>>> +               5       LE CODED RX
>>>>>>>> +
>>>>>>>> +       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
>>>>>>>>
>>>>>>>
>>>>>>> I think there is a limitation with current API proposal, user canno=
t do extended
>>>>>>> scanning in only 1M (to scan secondary channel in 1M) since with 1M=
 we will
>>>>>>> switch to legacy scanning.
>>>>>>
>>>>>> Why do we have to switch to legacy scanning for 1M? It seems it woul=
d
>>>>>> be possible to use extended scanning whenever it is supported
>>>>>> regardless of the PHY, or perhaps the spec imposes limitations to
>>>>>> certain PHYs? Coded perhaps?
>>>>>>
>>>>>
>>>>> The idea is to enable application to use legacy scanning even if
>>>>> controller supports
>>>>> extended. (ie if application dont want extended features to be used)
>>>>> and unlike advertising
>>>>> legacy scanning can not be emulated using extended scanning.
>>>>
>>>> Bluetooth controller which is doing extended scanning will report lega=
cy
>>>> advertisings as well. It will just use Extended Advertising Report
>>>> Event for this purpose and Linux Kernel should handle it.
>>>>
>>>
>>> Yes, but the idea here is more on perspective of power savings
>>> where in application dont want to scan on secondary channels itself and
>>> API should support it.
>
> Then maybe there should not be dependence between this command and scan/c=
onnect.
> Actually I do not understand why we have it, need to check previous
> conversation.
>
>>
>> I would agree if this affects passive scanning, but in that case we
>> can probably program the scan type when adding a device or only really
>> scan on primary channel since the purpose is to connect it doesn't
>> really matter what is on the secondary channels, for active scanning I
>> don't think we would be saving that much power since that should be
>> short-lived so Im not sure we should bother with it.
>
> In extended advertising there is no such thing as connectable and
> scannable at the same time
> When device is connectable, then address and optionally advertising
> data is in the aux ptr (secondary channel)
>
> Please also remember that it is up to controller to connect / scan on
> secondary PHY based on primary PHY provided by host.
> Meaning, host controls primary channel only, which can be 1M or Coded.
> Rest is up to controller and data in AUX_PTR of ADV_EXT_IND
>

I would wait for Marcel's comments here.

Thanks,
Jaganath

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Szymon Janc]

Hi,

On Wednesday, 21 February 2018 07:09:49 CET Jaganath K wrote:
> >>>>>>> I think there is a limitation with current API proposal, user cannot
> >>>>>>> do extended scanning in only 1M (to scan secondary channel in 1M)
> >>>>>>> since with 1M we will switch to legacy scanning.
> >>>>>> 
> >>>>>> Why do we have to switch to legacy scanning for 1M? It seems it would
> >>>>>> be possible to use extended scanning whenever it is supported
> >>>>>> regardless of the PHY, or perhaps the spec imposes limitations to
> >>>>>> certain PHYs? Coded perhaps?
> >>>>> 
> >>>>> The idea is to enable application to use legacy scanning even if
> >>>>> controller supports
> >>>>> extended. (ie if application dont want extended features to be used)
> >>>>> and unlike advertising
> >>>>> legacy scanning can not be emulated using extended scanning.
> >>>> 
> >>>> Bluetooth controller which is doing extended scanning will report
> >>>> legacy
> >>>> advertisings as well. It will just use Extended Advertising Report
> >>>> Event for this purpose and Linux Kernel should handle it.
> >>> 
> >>> Yes, but the idea here is more on perspective of power savings
> >>> where in application dont want to scan on secondary channels itself and
> >>> API should support it.
> > 
> > Then maybe there should not be dependence between this command and
> > scan/connect. Actually I do not understand why we have it, need to check
> > previous conversation.
> > 
> >> I would agree if this affects passive scanning, but in that case we
> >> can probably program the scan type when adding a device or only really
> >> scan on primary channel since the purpose is to connect it doesn't
> >> really matter what is on the secondary channels, for active scanning I
> >> don't think we would be saving that much power since that should be
> >> short-lived so Im not sure we should bother with it.
> > 
> > In extended advertising there is no such thing as connectable and
> > scannable at the same time
> > When device is connectable, then address and optionally advertising
> > data is in the aux ptr (secondary channel)
> > 
> > Please also remember that it is up to controller to connect / scan on
> > secondary PHY based on primary PHY provided by host.
> > Meaning, host controls primary channel only, which can be 1M or Coded.
> > Rest is up to controller and data in AUX_PTR of ADV_EXT_IND
> 
> I would wait for Marcel's comments here.

FWIW Apache Mynewt (master, soon to be released 1.4) has full support for 
Extended Advertising and Scanning including all PHYs (on nRF52840) and data 
fragmentation. You can build blehci app and use it with BlueZ for testing.

-- 
pozdrawiam
Szymon Janc

Re: [PATCH 2/4 v4] doc/mgmt-api: Add support for Set Phy Configuration command

[Jaganath K]

Hi,

On Wed, Feb 21, 2018 at 1:17 PM, Szymon Janc <szymon.janc@codecoup.pl> wrote:
> Hi,
>
> On Wednesday, 21 February 2018 07:09:49 CET Jaganath K wrote:
>> >>>>>>> I think there is a limitation with current API proposal, user cannot
>> >>>>>>> do extended scanning in only 1M (to scan secondary channel in 1M)
>> >>>>>>> since with 1M we will switch to legacy scanning.
>> >>>>>>
>> >>>>>> Why do we have to switch to legacy scanning for 1M? It seems it would
>> >>>>>> be possible to use extended scanning whenever it is supported
>> >>>>>> regardless of the PHY, or perhaps the spec imposes limitations to
>> >>>>>> certain PHYs? Coded perhaps?
>> >>>>>
>> >>>>> The idea is to enable application to use legacy scanning even if
>> >>>>> controller supports
>> >>>>> extended. (ie if application dont want extended features to be used)
>> >>>>> and unlike advertising
>> >>>>> legacy scanning can not be emulated using extended scanning.
>> >>>>
>> >>>> Bluetooth controller which is doing extended scanning will report
>> >>>> legacy
>> >>>> advertisings as well. It will just use Extended Advertising Report
>> >>>> Event for this purpose and Linux Kernel should handle it.
>> >>>
>> >>> Yes, but the idea here is more on perspective of power savings
>> >>> where in application dont want to scan on secondary channels itself and
>> >>> API should support it.
>> >
>> > Then maybe there should not be dependence between this command and
>> > scan/connect. Actually I do not understand why we have it, need to check
>> > previous conversation.
>> >
>> >> I would agree if this affects passive scanning, but in that case we
>> >> can probably program the scan type when adding a device or only really
>> >> scan on primary channel since the purpose is to connect it doesn't
>> >> really matter what is on the secondary channels, for active scanning I
>> >> don't think we would be saving that much power since that should be
>> >> short-lived so Im not sure we should bother with it.
>> >
>> > In extended advertising there is no such thing as connectable and
>> > scannable at the same time
>> > When device is connectable, then address and optionally advertising
>> > data is in the aux ptr (secondary channel)
>> >
>> > Please also remember that it is up to controller to connect / scan on
>> > secondary PHY based on primary PHY provided by host.
>> > Meaning, host controls primary channel only, which can be 1M or Coded.
>> > Rest is up to controller and data in AUX_PTR of ADV_EXT_IND
>>
>> I would wait for Marcel's comments here.
>
> FWIW Apache Mynewt (master, soon to be released 1.4) has full support for
> Extended Advertising and Scanning including all PHYs (on nRF52840) and data
> fragmentation. You can build blehci app and use it with BlueZ for testing.
>

It looks like we have to use Extended scanning always if supported
(even though i could
not find this restriction in core spec), the test is there in HCI TS spec -
HCI/GEV/BV-03-C [Disallow Mixing Legacy and Extended Scanning
Commands].

Actually in my first patch sets, it was done like this (use extended
features always if supported),
So i will rebase it and resent it for review.

Thanks,
Jaganath

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

[Jaganath Kanakkassery]

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

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 628ff18..e7453ea 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2504,6 +2504,9 @@ Read Advertising Features Command
 		4	Add TX Power field to Adv_Data
 		5	Add Appearance field to Scan_Rsp
 		6	Add Local Name in Scan_Rsp
+		7	Secondary Channel with LE 1M
+		8	Secondary Channel with LE 2M
+		9	Secondary Channel with LE Coded
 
 	The Flags bit 0 indicates support for connectable advertising
 	and for switching to connectable advertising independent of the
@@ -2553,6 +2556,15 @@ Read Advertising Features Command
 	space is limited a short version or no name information. The
 	Local Name will be added at the end of the scan response data.
 
+	The Flags bit 7 indicates support for advertising in secondary
+	channel in LE 1M PHY.
+
+	The Flags bit 8 indicates support for advertising in secondary
+	channel in LE 2M PHY. Primary channel would be on 1M.
+
+	The Flags bit 9 indicates support for advertising in secondary
+	channel in LE CODED PHY.
+
 	The valid range for Instance identifiers is 1-254. The value 0
 	is reserved for internal use and the value 255 is reserved for
 	future extensions. However the Max_Instances value for indicating
@@ -2613,6 +2625,9 @@ 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	Secondary Channel with LE 1M
+		8	Secondary Channel with LE 2M
+		9	Secondary Channel with LE Coded
 
 	When the connectable flag is set, then the controller will use
 	undirected connectable advertising. The value of the connectable
@@ -2640,6 +2655,15 @@ Add Advertising Command
 	supported to provide less air traffic for devices implementing
 	broadcaster role.
 
+	Secondary channel flags can be used to advertise in secondary
+	channel with the corresponding PHYs. These flag bits are mutually
+	exclusive and setting multiple will result in Invalid Parameter
+	error. Choosing LE 1M and LE 2M will result in using extended
+	advertising with the primary channel being 1M and secondary channel
+	with the respective PHY. Choosing LE Coded will result in extended
+	advertising with both primary and secondary channel in LE Coded.
+	Choosing none of these flags will result in legacy advertising.
+
 	The Duration parameter configures the length of an Instance. The
 	value is in seconds.
 
-- 
2.7.4

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

[Marcel Holtmann]

Hi Jaganath,

> ---
> doc/mgmt-api.txt | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 628ff18..e7453ea 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2504,6 +2504,9 @@ Read Advertising Features Command
> 		4	Add TX Power field to Adv_Data
> 		5	Add Appearance field to Scan_Rsp
> 		6	Add Local Name in Scan_Rsp
> +		7	Secondary Channel with LE 1M
> +		8	Secondary Channel with LE 2M
> +		9	Secondary Channel with LE Coded
> 
> 	The Flags bit 0 indicates support for connectable advertising
> 	and for switching to connectable advertising independent of the
> @@ -2553,6 +2556,15 @@ Read Advertising Features Command
> 	space is limited a short version or no name information. The
> 	Local Name will be added at the end of the scan response data.
> 
> +	The Flags bit 7 indicates support for advertising in secondary
> +	channel in LE 1M PHY.
> +
> +	The Flags bit 8 indicates support for advertising in secondary
> +	channel in LE 2M PHY. Primary channel would be on 1M.
> +
> +	The Flags bit 9 indicates support for advertising in secondary
> +	channel in LE CODED PHY.
> +
> 	The valid range for Instance identifiers is 1-254. The value 0
> 	is reserved for internal use and the value 255 is reserved for
> 	future extensions. However the Max_Instances value for indicating
> @@ -2613,6 +2625,9 @@ 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	Secondary Channel with LE 1M
> +		8	Secondary Channel with LE 2M
> +		9	Secondary Channel with LE Coded
> 
> 	When the connectable flag is set, then the controller will use
> 	undirected connectable advertising. The value of the connectable
> @@ -2640,6 +2655,15 @@ Add Advertising Command
> 	supported to provide less air traffic for devices implementing
> 	broadcaster role.
> 
> +	Secondary channel flags can be used to advertise in secondary
> +	channel with the corresponding PHYs. These flag bits are mutually
> +	exclusive and setting multiple will result in Invalid Parameter
> +	error. Choosing LE 1M and LE 2M will result in using extended
> +	advertising with the primary channel being 1M and secondary channel

I think this needs to be phrased differencing.

Choosing either LE 1M or LE 2M will result in using extended advertising on the primary channel with LE 1M and the respectively LE 1M or LE 2M on the secondary channel. Choosing LE Coded will result in using extended advertising on the primary and secondary channels.

> +	with the respective PHY. Choosing LE Coded will result in extended
> +	advertising with both primary and secondary channel in LE Coded.
> +	Choosing none of these flags will result in legacy advertising.
> +

Regards

Marcel

[PATCH 4/4] doc/mgmt-api: Update Duration Parameter description of Add Advertising

[Jaganath Kanakkassery]

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

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index e7453ea..afc43da 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2670,6 +2670,9 @@ Add Advertising Command
 	A value of 0 indicates a default value is chosen for the
 	Duration. The default is 2 seconds.
 
+	Duration parameter will be ignored if controller supports extended
+	advertising and instance scheduling will be done by the controller.
+
 	If only one advertising Instance has been added, then the Duration
 	value will be ignored. It only applies for the case where multiple
 	Instances are configured. In that case every Instance will be
-- 
2.7.4

[PATCH 0/4 v3] 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 (4):
  doc/mgmt-api: Add support for Get PHY Configuration command
  doc/mgmt-api: Add support for Set Phy Configuration command
  doc/mgmt-api: Add advertising phys support to flags
  doc/mgmt-api: Update Duration Parameter description of Add Advertising

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

-- 
2.7.4

[PATCH 4/4] doc/mgmt-api: Update Duration Parameter description of Add Advertising

[Jaganath Kanakkassery]

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

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index e7453ea..afc43da 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2670,6 +2670,9 @@ Add Advertising Command
 	A value of 0 indicates a default value is chosen for the
 	Duration. The default is 2 seconds.
 
+	Duration parameter will be ignored if controller supports extended
+	advertising and instance scheduling will be done by the controller.
+
 	If only one advertising Instance has been added, then the Duration
 	value will be ignored. It only applies for the case where multiple
 	Instances are configured. In that case every Instance will be
-- 
2.7.4