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;
From:   <Mario.Limonciello@dell.com>
To:     <ckellner@redhat.com>, <linux-bluetooth@vger.kernel.org>
Subject: RE: BT advertising packets and s2idle issue
Thread-Topic: BT advertising packets and s2idle issue
Thread-Index: AQHVRhqgVGNmeV2XRUeiYVQj/t6U86bwL+ZQ
Date:   Wed, 7 Aug 2019 20:43:17 +0000
Message-ID: <ccb1c793a9094d3d9cac1c63b695d5e5@AUSX13MPC105.AMER.DELL.COM>
References: <87sgqoewqv.fsf@kellner.me>
In-Reply-To: <87sgqoewqv.fsf@kellner.me>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=Mario_Limonciello@Dell.com;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-08-07T20:43:15.5083913Z;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure
 Information Protection;
 MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual;
 aiplabel=External Public
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.143.18.86]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-07_06:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1906280000 definitions=main-1908070179
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0
 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011
 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000
 definitions=main-1908070179
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-bluetooth.vger.kernel.org>
X-Mailing-List: linux-bluetooth@vger.kernel.org

> -----Original Message-----
> From: Christian Kellner <ckellner@redhat.com>
> Sent: Monday, July 29, 2019 9:33 AM
> To: linux-bluetooth@vger.kernel.org
> Cc: Limonciello, Mario
> Subject: BT advertising packets and s2idle issue
>=20
>=20
> [EXTERNAL EMAIL]
>=20
>=20
> Hi all,
>=20
> I have been wondering what to do about the bug that advertising packet
> will wake systems from s2idle when a device was previously paired with
> the HCI_AUTO_CONN_ALWAYS flag (kernel bug #200039[1]). I was thinking of
> creating a patch for bluez that would create a "delay lock"[2] and
> de-register any such device from the kernel before entering s2idle, but
> I wanted to check first if that is the best approach.
> In comment #27 it is suggested that using a "LE Privacy v1.2" feature
> could fix the issue as well. Is there some more information about this
> available somewhere?  II can help out with development and testing as I
> have an affected system myself.
>=20
> Cheers,
> CK
>=20
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=3D200039
> [2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
>=20
> --
> Dr. Christian J. Kellner
> Desktop Hardware Enablement
> Red Hat

If I'm not mistaken, even unpaired LE devices can cause the wakeup.  Any de=
vice
with an advertisement report will cause the wakeup.  So de-registering all =
devices
from kernel before entering s2idle wouldn't solve the problem.

My opinion is there should be a dedicated kernel freeze handler that does t=
he following:
1) If LE Privacy 1.2 "in use", handle regular suspend/resume flow
2) If LE Privacy 1.1in use, power off the radio in freeze, power back on in=
 resume.

For now, since LE privacy 1.2 not yet enabled, this would at least help wit=
h this
situation as reported.

Of course this will mean BT devices can't wake the system anymore if s2i, s=
o maybe
the behavior  should be put behind a module parameter or sysfs file.

BLE devices are so prevalent though; I find it a hard time imagining anyone=
 wants it
the way it exists today.