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
---
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
---
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
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
---
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
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
Hi,
On Wed, Feb 21, 2018 at 1:17 PM, Szymon Janc <[email protected]> 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
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
Hi Lukasz, Luiz,
On Mon, Feb 19, 2018 at 4:37 PM, =C5=81ukasz Rymanowski
<[email protected]> wrote:
> Hi Luiz, Jaganath
>
> On 19 February 2018 at 11:31, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Jaganath,
>>
>> On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <[email protected]> w=
rote:
>>> Hi Lukasz,
>>>
>>> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
>>> <[email protected]> wrote:
>>>> Hi Jaganath,
>>>>
>>>> On 19 February 2018 at 10:25, Jaganath K <[email protected]> wro=
te:
>>>>> Hi Luiz,
>>>>>
>>>>>
>>>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>>>> <[email protected]> wrote:
>>>>>> Hi Jaganath,
>>>>>>
>>>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]=
> wrote:
>>>>>>> Hi Marcel,
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>>>> <[email protected]> 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
Hi Luiz, Jaganath
On 19 February 2018 at 11:31, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Jaganath,
>
> On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <[email protected]> wr=
ote:
>> Hi Lukasz,
>>
>> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
>> <[email protected]> wrote:
>>> Hi Jaganath,
>>>
>>> On 19 February 2018 at 10:25, Jaganath K <[email protected]> wrot=
e:
>>>> Hi Luiz,
>>>>
>>>>
>>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>>> <[email protected]> wrote:
>>>>> Hi Jaganath,
>>>>>
>>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]>=
wrote:
>>>>>> Hi Marcel,
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>>> <[email protected]> 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
Hi Jaganath,
On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <[email protected]> wrot=
e:
> Hi Lukasz,
>
> On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
> <[email protected]> wrote:
>> Hi Jaganath,
>>
>> On 19 February 2018 at 10:25, Jaganath K <[email protected]> wrote=
:
>>> Hi Luiz,
>>>
>>>
>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>>> <[email protected]> wrote:
>>>> Hi Jaganath,
>>>>
>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]> =
wrote:
>>>>> Hi Marcel,
>>>>>
>>>>>
>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>>> <[email protected]> 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
Hi Lukasz,
On Mon, Feb 19, 2018 at 3:28 PM, =C5=81ukasz Rymanowski
<[email protected]> wrote:
> Hi Jaganath,
>
> On 19 February 2018 at 10:25, Jaganath K <[email protected]> wrote:
>> Hi Luiz,
>>
>>
>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> Hi Jaganath,
>>>
>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]> w=
rote:
>>>> Hi Marcel,
>>>>
>>>>
>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>>> <[email protected]> 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
Hi Jaganath,
On 19 February 2018 at 10:25, Jaganath K <[email protected]> wrote:
> Hi Luiz,
>
>
> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Jaganath,
>>
>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]> wrote:
>>> Hi Marcel,
>>>
>>>
>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>>> <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Luiz,
On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Jaganath,
>
> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]> wrote:
>> Hi Marcel,
>>
>>
>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
>> <[email protected]> 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
Hi Jaganath,
On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <[email protected]> wrote:
> Hi Marcel,
>
>
> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
> <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
Hi Marcel,
On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery
<[email protected]> 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
Hi Luiz,
> Hi Jaganath,
>
> On Wed, Nov 29, 2017 at 4:52 AM, Jaganath Kanakkassery
> <[email protected]> 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
Hi Jaganath,
On Wed, Nov 29, 2017 at 4:52 AM, Jaganath Kanakkassery
<[email protected]> 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