linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Alain Michaud <alainmichaud@google.com>
Cc: Alain Michaud <alainm@chromium.org>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: [BlueZ PATCH v3] doc:adding definitions for load default params mgmt op
Date: Thu, 21 May 2020 15:05:38 -0700	[thread overview]
Message-ID: <CABBYNZ+8ed4qXarr647Q2SKkvqdT3N5AccP4L5a35e--9ybzgg@mail.gmail.com> (raw)
In-Reply-To: <CALWDO_UQhU5QxZ1eRNWZtAtkcghWEBM5eVeujxhROSr7PG_P=w@mail.gmail.com>

Hi Alain,

On Thu, May 21, 2020 at 1:12 PM Alain Michaud <alainmichaud@google.com> wrote:
>
> Hi Luiz,
>
>
> On Thu, May 21, 2020 at 12:26 PM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>>
>> Hi Alain,
>>
>> On Thu, May 21, 2020 at 8:05 AM Alain Michaud <alainm@chromium.org> wrote:
>> >
>> > This change adds the definition for the load default parameter command.
>> > In particular, this command is used to load default parameters for
>> > various operations in the kernel. This mechanism is also expandable to
>> > future values that may be necessary.
>> >
>> > This will allow bluetoothd to load parameters from a conf file that may
>> > be customized for the specific requirements of each platforms.
>> >
>> > ---
>> > rebase against current master
>> >
>> >  doc/mgmt-api.txt | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
>> >  1 file changed, 62 insertions(+)
>> >
>> > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>> > index 6ee01fed8..c6575e654 100644
>> > --- a/doc/mgmt-api.txt
>> > +++ b/doc/mgmt-api.txt
>> > @@ -3223,6 +3223,68 @@ Set Experimental Feature Command
>> >                                 Invalid Index
>> >
>> >
>> > +Load Default Controller Parameter Command
>> > +=============================
>> > +
>> > +       Command Code:           0x004b
>> > +       Controller Index:       <controller id>
>> > +       Command Parameters:     Parameter_Count (2 Octets)
>> > +                               Parameter1 {
>> > +                                       Parameter_Type (2 Octet)
>> > +                                       Value_Length (1 Octet)
>> > +                                       Value (0-255 Octets)
>> > +                               }
>> > +                               Parameter2 { }
>> > +                               ...
>> > +       Return Parameters:
>> > +
>> > +       This command is used to feed the kernel a list of default controller
>> > +       parameters.
>> > +
>> > +       Currently defined Parameter_Type values are:
>> > +
>> > +               0x0000  BR/EDR Page Scan Type
>> > +               0x0001  BR/EDR Page Scan Interval
>> > +               0x0002  BR/EDR Page Scan Window
>> > +               0x0003  BR/EDR Inquiry Scan Type
>> > +               0x0004  BR/EDR Inquiry Scan Interval
>> > +               0x0005  BR/EDR Inquiry Scan Window
>> > +               0x0006  BR/EDR Link Supervision Timeout
>> > +               0x0007  BR/EDR Page Timeout
>> > +               0x0008  BR/EDR Min Sniff Interval
>> > +               0x0009  BR/EDR Max Sniff Interval
>> > +               0x000a  LE Advertisement Min Interval
>> > +               0x000b  LE Advertisement Max Interval
>> > +               0x000c  LE Multi Advertisement Rotation Interval
>> > +               0x000d  LE Scanning Interval for auto connect
>> > +               0x000e  LE Scanning Window for auto connect
>> > +               0x000f  LE Scanning Interval for HID only
>> > +               0x0010  LE Scanning Window for HID only
>>
>> I remember commenting that we don't have profile information on the
>> kernel so Im not sure how you are planning to detect the when the
>> device is HID or not?
>
> I expect we'll need to add an Add Device flag to carry that information down into the kernel.  The hid profile already sends an op, so it's relatively trivial to carry that information in so we can apply specific scanning requirements for that case (which are less aggressive and therefore have less of an impact to Wifi and BT performance).

Well if we will need to feed that information of the profile type we
might as well just feed the intervals directly, that way any profile
that needs some different parameters than the default can all use the
same command and we don't have to grow this list when a new profile
want to use different parameters.

>>
>>
>> > +               0x0012  LE Scanning Interval for wake scenarios
>> > +               0x0013  LE Scanning Window for wake scenarios
>> > +               0x0014  LE Scanning Interval for discovery
>> > +               0x0015  LE Scanning Window for discovery
>> > +               0x0016  LE Scanning Interval for adv monitoring
>> > +               0x0017  LE Scanning Window for adv monitoring
>> > +               0x0018  LE Scanning Interval for connect
>> > +               0x0019  LE Scanning Window for connect
>> > +               0x001a  LE Min Connection Interval
>> > +               0x001b  LE Max Connection Interval
>> > +               0x001c  LE Connection Connection Latency
>> > +               0x001d  LE Connection Supervision Timeout
>> > +
>> > +       This command can be used when the controller is not powered and
>> > +       all settings will be programmed once powered.  Note that these only
>> > +       control the default parameters.  Higher level Apis may influence the
>> > +       effective value used.
>> > +
>> > +       This command generates a Command Complete event on success or
>> > +       a Command Status event on failure.
>> > +
>> > +       Possible errors:        Invalid Parameters
>> > +                               Invalid Index
>> > +
>> > +
>> >  Command Complete Event
>> >  ======================
>> >
>> > --
>> > 2.26.2.761.g0e0b3e54be-goog
>> >
>>
>>
>> --
>> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

  parent reply	other threads:[~2020-05-21 22:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 14:57 [BlueZ PATCH v3] doc:adding definitions for load default params mgmt op Alain Michaud
2020-05-21 16:26 ` Luiz Augusto von Dentz
     [not found]   ` <CALWDO_UQhU5QxZ1eRNWZtAtkcghWEBM5eVeujxhROSr7PG_P=w@mail.gmail.com>
2020-05-21 22:05     ` Luiz Augusto von Dentz [this message]
2020-05-21 22:27       ` Alain Michaud
2020-05-21 23:18         ` Luiz Augusto von Dentz
     [not found]           ` <CALWDO_XX-xKJ4Se6HwfyroD9uQHj32xf5ZAFkEEA_QjV5MsVNg@mail.gmail.com>
2020-05-22  0:14             ` Luiz Augusto von Dentz
     [not found]               ` <CALWDO_Uhid28nvX5NEngfTa2s76zKpQMK+8sS9Wm2cOf4weHuw@mail.gmail.com>
2020-05-22 18:04                 ` Luiz Augusto von Dentz
     [not found]                   ` <CALWDO_XiuiB6viANARXZ9hhSKkfW+stwwr44pMJbTBOUzxUDew@mail.gmail.com>
2020-05-26 13:47                     ` Alain Michaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABBYNZ+8ed4qXarr647Q2SKkvqdT3N5AccP4L5a35e--9ybzgg@mail.gmail.com \
    --to=luiz.dentz@gmail.com \
    --cc=alainm@chromium.org \
    --cc=alainmichaud@google.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).