Hi Andre,
> doc/mgmt-api.txt | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 78f0bd2..a2c65db 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -995,7 +995,8 @@ Unpair Device Command
> Return Parameters: Address (6 Octets)
> Address_Type (1 Octet)
>
> - Removes all keys associated with the remote device.
> + Removes all keys and connection parameters associated with the remote
> + device.
>
> Possible values for the Address_Type parameter:
> 0 BR/EDR
> @@ -1668,6 +1669,62 @@ Load Identity Resolving Keys Command
> Invalid Index
>
>
> +Load Connection Parameters Command
> +====================================
> +
> + Command Code: 0x0031
> + Controller Index: <controller id>
> + Command Parameters: Params_Count (2 Octets)
> + Params1 {
> + Address (6 Octets)
> + Address_Type (1 Octet)
> + Auto_Connect_Option (1 Octet)
the one thing that I wonder is if we want to include this auto connect option here. I currently lean towards leaving this out and instead provide a different command that sets the auto-connect list.
As I said before, the link-loss re-connect option is something I rather see set via a socket option. I think that just makes more sense. You are connect, and you want to be re-connect if anything forces a disconnect.
> + Min_Connection_Interval (2 Octets)
> + Max_Connection_Interval (2 Octes)
> + Connection_Latency (2 Octets)
> + Supervision_Timeout (2 Octets)
> + }
> + Params2 { }
> + ...
> + Return Parameters:
> +
> + This command is used load connection parameters from several LE devices
> + into kernel. It is only supported on controllers with LE support.
> +
> + The provided Address and Address_Type are the identity of a device. So
> + either its public address or static random address. Unresolvable random
> + addresses and resolvable random addresses are not valid and will be
> + rejected.
> +
> + Possible values for the Address_Type parameter:
> + 0 Reserved (not in use)
> + 1 LE Public
> + 2 LE Random
What I wonder is if we should include BR/EDR here as well. Since the link supervision timeout is something we could allow modification on BR/EDR while keeping connection interval and latency at zero.
In the past there have been discussions about link supervision timeout being configurable and not just using the default value and hoping the remote side would adjust it.
> +
> + Possible values for the Auto_Connect_Option parameter:
> + 0 Disabled
> + 1 Always
> + 2 Link Loss
> +
> + The 'Always' option configures the kernel to always re-establish the
> + connection, no matter the reason the connection was terminated. The
> + 'Link Loss' option configures the kernel to re-establish the connection
> + only in case the connection was terminated due to a link loss.
> +
> + The Min_Connection_Interval, Max_Connection_Interval, Connection_Latency
> + and Supervision_Timeout parameters should be configured as described in
> + Core 4.1 spec, Vol 2, 7.8.12.
> +
> + This command can be used when the controller is not powered.
> +
> + This command generates a Command Complete event on success or
> + a Command Status event on failure.
> +
> + Possible errors: Invalid Parameters
> + Invalid Index
> + Not Supported
> +
> +
> Command Complete Event
> ======================
>
> @@ -2257,3 +2314,33 @@ New Signature Resolving Key Event
>
> The provided Address and Address_Type are the identity of
> a device. So either its public address or static random address.
> +
> +
> +New Connection Parameters Event
> +===============================
> +
> + Event Code: 0x001a
> + Controller Index: <controller id>
> + Event Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Connection_Interval (2 Octets)
This should be min and max connection interval. The actually chosen one by the controller is pretty irrelevant to us. We want to know what we have to load back into the kernel after next reboot.
> + Connection_Latency (2 Octets)
> + Supervision_Timeout (2 Octets)
> +
> + This event indicates the new LE connection parameters set by GAP
> + Connection Parameter Update Procedure.
> +
> + This event is sent only if the new parameters are different from the
> + parameters the user has configured (See Load Connection Parameters
> + Command) or if there is no parameters configured for that device.
> +
> + Possible values for the Address_Type parameter:
> + 0 Reserved (not in use)
> + 1 LE Public
> + 2 LE Random
> +
> + The provided Address and Address_Type are the identity of
> + a device. So either its public address or static random address.
> +
> + The Connection_Interval, Connection_Latency and Supervision_Timeout
> + parameters are encoded as described in Core 4.1 spec, Vol 2, 7.7.65.3.
Regards
Marcel
--
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
