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. Thanks, Jaganath -- 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
