From: "Jonas Dreßler" <verdre@v0yd.nl>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
asahi@lists.linux.dev, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
verdre@v0yd.nl
Subject: Re: [PATCH v2 0/4] Power off HCI devices before rfkilling them
Date: Wed, 3 Jan 2024 13:15:52 +0100 [thread overview]
Message-ID: <548fb407-ef57-4108-aa26-52deafdca55c@v0yd.nl> (raw)
In-Reply-To: <CABBYNZ+sTko6reoJO43W2LHGW58f0kK_8Zgc3mep7xki355=iA@mail.gmail.com>
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@v0yd.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
next prev parent reply other threads:[~2024-01-03 12:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 18:19 [PATCH v2 0/4] Power off HCI devices before rfkilling them Jonas Dreßler
2024-01-02 18:19 ` [PATCH v2 1/4] Bluetooth: Remove HCI_POWER_OFF_TIMEOUT Jonas Dreßler
2024-01-02 18:58 ` Power off HCI devices before rfkilling them bluez.test.bot
2024-01-02 18:19 ` [PATCH v2 2/4] Bluetooth: mgmt: Remove leftover queuing of power_off work Jonas Dreßler
2024-01-02 18:19 ` [PATCH v2 3/4] Bluetooth: Add new state HCI_POWERING_DOWN Jonas Dreßler
2024-01-02 18:19 ` [PATCH v2 4/4] Bluetooth: Queue a HCI power-off command before rfkilling adapters Jonas Dreßler
2024-01-02 18:31 ` Luiz Augusto von Dentz
2024-01-02 18:49 ` Jonas Dreßler
2024-01-02 18:39 ` [PATCH v2 0/4] Power off HCI devices before rfkilling them Luiz Augusto von Dentz
2024-01-03 12:15 ` Jonas Dreßler [this message]
2024-01-07 18:10 ` Jonas Dreßler
2024-01-07 23:49 ` Luiz Augusto von Dentz
2024-01-08 19:50 ` patchwork-bot+bluetooth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=548fb407-ef57-4108-aa26-52deafdca55c@v0yd.nl \
--to=verdre@v0yd.nl \
--cc=asahi@lists.linux.dev \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).