Hi Luiz, >--------- Original Message --------- >Sender : Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> >Date : 2018-11-01 23:28 (GMT+9) >Title : Re: Kernel interace for LE Set/Read PHY API's > >Hi Anupam, >On Thu, Nov 1, 2018 at 10:26 AM Anupam Roy <anupam.r@xxxxxxxxxxx> 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. > Thank you providing your suggestions and sory for delay in response. By extending to connection parameters, if you are suggesting that we can introduce l2cap socket options for configuring LE connection parameters, I think it will be ofcourse a good option for user/app for configuring params, based on its specific needs. Handling LE connection parameter update alone seems OK to handle inside kernel based on some conditions. However, in this context, I am wondering if later on, if we add PHY fields to the same socket option, do we need to consider following for handing the mixed (PHY params + Conn params) options via L2CAP socket? - Whether to go for Connection parameter update procedure (based on connection parameters and other requirements) or go for LE Set PHY (based on PHY fields suggested by user) - Or handle both in some sequence Basically in order to resolve this, I think some further policy need to be defined inside kernel? Please provide some insights. Thank You! >> 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 BR, -Anupam Roy
