Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Subject: Re: [Bluez PATCH v1] doc/mgmt-api - Add a new error code for HCI
 status 0x3e
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20210429111523.Bluez.v1.1.Ic00ed950add081b346d6c8ced590bb7b2eb6e9f7@changeid>
Date:   Fri, 7 May 2021 10:18:58 +0200
Cc:     Bluetooth Kernel Mailing List <linux-bluetooth@vger.kernel.org>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        chromeos-bluetooth-upstreaming@chromium.org,
        Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <44A0B714-12C5-4A43-9829-CAE3D8BF374B@holtmann.org>
References: <20210429111523.Bluez.v1.1.Ic00ed950add081b346d6c8ced590bb7b2eb6e9f7@changeid>
To:     Yu Liu <yudiliu@google.com>
Precedence: bulk

Hi Yu,

> We want to retry the pairing when HCI status 0x3e (Connection failed to
> established/Synchronization timeout) is returned from the controller.
> This is to add a new MGMT error code so that we can catch this 0x3e
> failure and issue a retry in the user space.
> 
> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> ---
> 
> Changes in v1:
> - Initial change
> 
> doc/mgmt-api.txt | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..f7cbf7ab2 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -200,6 +200,7 @@ and Command Complete events:
> 0x12	RFKilled
> 0x13	Already Paired
> 0x14	Permission Denied
> +0x15	Connection Not Established
> 
> As a general rule all commands generate the events as specified below,
> however invalid lengths or unknown commands will always generate a
> @@ -1112,6 +1113,7 @@ Pair Device Command
> 				Not Powered
> 				Invalid Index
> 				Already Paired
> +				Connection Not Established

I really dislike the naming. And even more so, I request the motive here.

So looking at our code, we have 3 cases where we use the previous status:

	MGMT_STATUS_CONNECT_FAILED, /* Page Timeout */
	MGMT_STATUS_CONNECT_FAILED, /* Connection Establishment Failed */
	MGMT_STATUS_CONNECT_FAILED, /* MAC Connection Failed */

And they do map to the 3 available transports, either via BR/EDR or LE or AMP. That means if you call Pair Device you already know well today when it fails to establish the link and can retry it.

My question, what are you trying to fix here.

Regards

Marcel