Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220829195805.1.Ic8eabc8ed89a07c3d52726dd017539069faac6c4@changeid>
In-Reply-To: <20220829195805.1.Ic8eabc8ed89a07c3d52726dd017539069faac6c4@changeid>
From:   Abhishek Pandit-Subedi <abhishekpandit@google.com>
Date:   Thu, 1 Sep 2022 17:54:00 -0700
Message-ID: <CAN61AdcHDEB=nG7sti8uiqv534P1N21VCx+XuqnkVUOjeoADkg@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: Call shutdown for HCI_USER_CHANNEL
To:     linux-bluetooth@vger.kernel.org
Cc:     Abhishek Pandit-Subedi <abhishekpandit@chromium.org>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        Marcel Holtmann <marcel@holtmann.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Please avoid merging.

After additional testing, I've found a problem with btusb->shutdown
not working for Intel controllers.

btusb_shutdown_intel uses __hci_sync_cmd(...) to send the command and
the command complete will not get captured because it is using hci
user channel. We'll need a more invasive change to remove the
userchannel flag during close so that the stack can properly clean up.


On Mon, Aug 29, 2022 at 7:58 PM Abhishek Pandit-Subedi
<abhishekpandit@google.com> wrote:
>
> From: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
>
> Some drivers depend on shutdown being called for proper operation.
> There's no reason to restrict this from being called when using
> HCI_USER_CHANNEL.
>
> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> ---
> This is easy to reproduce on QCA6174-A, which uses the hci_qca driver.
> Simply open the socket, bind as userchannel and close again. It will
> succeed the first time and fail the second time (because shutdown wasn't
> called). A similar bug also occurs with btmtksdio (using MT7921).
>
> Question for maintainers: What is a driver supposed to be doing during
> shutdown? We should add some documentation to `struct hci_dev` to
> clarify.
>
>
>  net/bluetooth/hci_sync.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index e08c0503027d..be78fd708f16 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -4680,7 +4680,6 @@ int hci_dev_close_sync(struct hci_dev *hdev)
>         }
>
>         if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) &&
> -           !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) &&
>             test_bit(HCI_UP, &hdev->flags)) {
>                 /* Execute vendor specific shutdown routine */
>                 if (hdev->shutdown)
> --
> 2.37.2.672.g94769d06f0-goog
>