DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 984CB205F4
MIME-Version: 1.0
References: <CGME20181101075451epcms5p466176e62713906cef4d5aa41ef8cfc2e@epcms5p4>
 <20181101075451epcms5p466176e62713906cef4d5aa41ef8cfc2e@epcms5p4>
In-Reply-To: <20181101075451epcms5p466176e62713906cef4d5aa41ef8cfc2e@epcms5p4>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Thu, 1 Nov 2018 16:27:19 +0200
Message-ID: <CABBYNZ+f5nsJnqa85EBt2GDv2ZL-kE9pa5NsjuJEwjTnm=qdCA@mail.gmail.com>
Subject: Re: Kernel interace for LE Set/Read PHY API's
To:     Anupam Roy <anupam.r@samsung.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Anupam,
On Thu, Nov 1, 2018 at 10:26 AM Anupam Roy <anupam.r@samsung.com> wrote:
>
> Hi,
>  Is there is any plan or on-going work to support kernel interface for BT 5.0 PHY based HCI commands - 'LE Set PHY', 'LE Read PHY'?
> Actually, we would want to have support for the above, such that PHY parameters can be updated\indicated from user space BlueZ for any particular connection.
> As I see, currently there is no kernel interface via which application can change PHY or atleast request controller to change PHY (for a particular connection)
>
> In order to support these via kernel interface, I think following could be possible approaches.
>  - via kernel's MGMT interface (I am not sure if this would be ideal approach to set PHY preferrence from user space)
>  - via L2CAP socket options (Bluez user space would be able to read\Set Preference for a particular connection handle)
>  - via kernel internal logic (Don't expose control to user space and handle Read/Set PHY internally inside kernel. Choose 2M always, irrespective of user's preference.
>        But, i am not sure, if this would conflict with different application's requirement for a particular PHY.

I think it might be better to have a QoS option per socket since it
probably need to accessible at application level, that way the
application can configure its preference which may or may not be
attended in case there are more channels, for instance if app A
request 1Mbit/s and app B request 2Mbit/s than we probably should go
with 2Mbit/s but this is a policy that could probably go into the
kernel directly. This could also be extended to connection parameters
as well, in fact I think we would benefit more from starting with
connection parameters and then add PHY field later on.

> Also please suggest if there is any other better way to support these?
>
> Why we would require these support?:  Even though LE Set Default PHY can be used to indicate controller about preferrence/mix of certain PHY's, it will be applied (unless controller denies it based on Connection interval or other requirements)
> for all subsequent connections and hence no per connection(application) control over PHY.
>
> Please provide your suggestions/comments on how to go about with these!
> Thank You very much!
>
> BR,
> -Anupam Roy


-- 
Luiz Augusto von Dentz