Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [BlueZ PATCH v3 1/5] mgmt: Add docs for Set Wake Capable
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20200127180433.BlueZ.v3.1.I999b93b65e613324dbbd16a1cf493be72fa06ad1@changeid>
Date:   Wed, 29 Jan 2020 05:33:38 +0100
Cc:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>, alainm@chromium.org,
        linux-bluetooth@vger.kernel.org,
        chromeos-bluetooth-upstreaming@chromium.org
Content-Transfer-Encoding: 8BIT
Message-Id: <137EB79B-88E6-43E0-894F-A0C8D5F9B710@holtmann.org>
References: <20200128020505.239349-1-abhishekpandit@chromium.org>
 <20200127180433.BlueZ.v3.1.I999b93b65e613324dbbd16a1cf493be72fa06ad1@changeid>
To:     Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Abhishek,

> Add docs for new management operation to mark a device as wake capable.
> 
> ---
> 
> Changes in v3: None
> Changes in v2:
> * Separated docs/mgmt-api.txt into its own patch
> 
> doc/mgmt-api.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 1e59acc54..8a73a9bb9 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -3047,6 +3047,25 @@ Load Blocked Keys Command
> 	Possible errors:	Invalid Parameters
> 				Invalid Index
> 
> +Set Wake Capable Command
> +===========================
> +
> +	Command Code:		0x0047
> +	Controller Index:	<controller id>
> +	Command Parameters:	Address (6 Octets)
> +				Address_Type (1 Octet)
> +				Wake Capable (1 Octet)
> +	Return Parameters:	Address (6 Octets)
> +				Address_Type (1 Octet)
> +				Wake Capable (1 Octet)
> +
> +	This command sets whether a bluetooth device is capable of waking the
> +	system from suspend. This property is used to set the event filter and
> +	LE whitelist when the system enters suspend.
> +
> +	Possible errors:	Failed
> +				Invalid Parameters
> +				Invalid Index
> 

my current thinking goes into this API addition:

--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2003,6 +2003,7 @@ Add Device Command
                0       Background scan for device
                1       Allow incoming connection
                2       Auto-connect remote device
+               3       Allow incoming connection to wake up the system
 
        With the Action 0, when the device is found, a new Device Found
        event will be sent indicating this device is available. This
@@ -2018,6 +2019,9 @@ Add Device Command
        and if successful a Device Connected event will be sent. This
        action is only valid for LE Public and LE Random address types.
 
+       With the Action 3, the device is allowed to connect the same way
+       as with Action 1, but allows to wake up the system from suspend.
+
        When a device is blocked using Block Device command, then it is
        valid to add the device here, but all actions will be ignored
        until the device is unblocked.

Since we are really talking about incoming connections, then the Add Device command is the one that handles this. Giving a device the option to wake us up that is not set up for incoming connections makes no sense. We can discuss if certain LE advertising packets should wake us up, but that is a total different API in my book.

Regards

Marcel