Hi Luiz, Jaganath On 19 February 2018 at 11:31, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Jaganath, > > On Mon, Feb 19, 2018 at 12:09 PM, Jaganath K <jaganath.k.os@xxxxxxxxx> wrote: >> Hi Lukasz, >> >> On Mon, Feb 19, 2018 at 3:28 PM, Łukasz Rymanowski >> <lukasz.rymanowski@xxxxxxxxxxx> wrote: >>> Hi Jaganath, >>> >>> On 19 February 2018 at 10:25, Jaganath K <jaganath.k.os@xxxxxxxxx> wrote: >>>> Hi Luiz, >>>> >>>> >>>> On Mon, Feb 19, 2018 at 2:17 PM, Luiz Augusto von Dentz >>>> <luiz.dentz@xxxxxxxxx> wrote: >>>>> Hi Jaganath, >>>>> >>>>> On Fri, Feb 16, 2018 at 5:40 AM, Jaganath K <jaganath.k.os@xxxxxxxxx> wrote: >>>>>> Hi Marcel, >>>>>> >>>>>> >>>>>> On Wed, Nov 29, 2017 at 12:22 PM, Jaganath Kanakkassery >>>>>> <jaganath.k.os@xxxxxxxxx> 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. >>> >> >> 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 > > -- > Luiz Augusto von Dentz Łukasz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
