Hi Lukasz, Luiz, On Mon, Feb 19, 2018 at 4:37 PM, Łukasz Rymanowski <lukasz.rymanowski@xxxxxxxxxxx> wrote: > 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 > I would wait for Marcel's comments here. 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
