Re: [PATCH v2 0/4] Power off HCI devices before rfkilling them

[Jonas Dreßler]

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@xxxxxxx> 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