[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <548fb407-ef57-4108-aa26-52deafdca55c@v0yd.nl>
Date: Wed, 3 Jan 2024 13:15:52 +0100
From: Jonas Dreßler <verdre@...d.nl>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: Marcel Holtmann <marcel@...tmann.org>,
Johan Hedberg <johan.hedberg@...il.com>, asahi@...ts.linux.dev,
linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, verdre@...d.nl
Subject: Re: [PATCH v2 0/4] Power off HCI devices before rfkilling them
Hi Luiz,
On 1/2/24 19:39, Luiz Augusto von Dentz wrote:
> Hi Jonas,
>
> On Tue, Jan 2, 2024 at 1:19 PM Jonas Dreßler <verdre@...d.nl> wrote:
>>
>> In theory the firmware is supposed to power off the bluetooth card
>> when we use rfkill to block it. This doesn't work on a lot of laptops
>> though, leading to weird issues after turning off bluetooth, like the
>> connection timing out on the peripherals which were connected, and
>> bluetooth not connecting properly when the adapter is turned on again
>> quickly after rfkilling.
>>
>> This series hooks into the rfkill driver from the bluetooth subsystem
>> to send a HCI_POWER_OFF command to the adapter before actually submitting
>> the rfkill to the firmware and killing the HCI connection.
>>
>> ---
>>
>> v1 -> v2: Fixed commit message title to make CI happy
>>
>> Jonas Dreßler (4):
>> Bluetooth: Remove HCI_POWER_OFF_TIMEOUT
>> Bluetooth: mgmt: Remove leftover queuing of power_off work
>> Bluetooth: Add new state HCI_POWERING_DOWN
>> Bluetooth: Queue a HCI power-off command before rfkilling adapters
>
> Apart from the assumption of RFKILL actually killing the RF
> immediately or not, I'm fine with these changes, that said it would be
> great if we can have some proper way to test the behavior of rfkill,
> perhaps via mgmt-tester, since it should behave like the
> MGMT_OP_SET_POWERED.
Testing this sounds like a good idea, I guess we'd have to teach
mgmt-tester to write to rfkill. The bigger problem seems to be that
there's no MGMT event for power changes and also no MGMT_OP_GET_POWERED,
so that's a bit concerning, could userspace even be notified about
changes to adapter power?
Another thing I'm thinking about now is that queuing the HCI command
using hci_cmd_sync_queue() might not be enough: The command is still
executed async in a thread, and we won't actually block until it has
been sent, so this might be introducing a race (rfkill could kill the
adapter before we actually send the HCI command). The proper way might
be to use a completion and wait until the
set_powered_off_sync_complete() callback is invoked?
>
>> include/net/bluetooth/hci.h | 2 +-
>> net/bluetooth/hci_core.c | 33 ++++++++++++++++++++++++++++++---
>> net/bluetooth/hci_sync.c | 16 +++++++++++-----
>> net/bluetooth/mgmt.c | 30 ++++++++++++++----------------
>> 4 files changed, 56 insertions(+), 25 deletions(-)
>>
>> --
>> 2.43.0
>>
>
>
Cheers,
Jonas
Powered by blists - more mailing lists