Re: [PATCH v2] Bluetooth: qca: Allow capturing QCA debug logs in snoop logs

[Luiz Augusto von Dentz]

Hi Dishank,

On Tue, Aug 4, 2026 at 1:20 AM Dishank Garg
<dishank.garg@xxxxxxxxxxxxxxxx> wrote:
>
> Add a debugfs flag to forward QCA diagnostic ACL packets as regular
> ACL data, enabling their capture in Bluetooth snoop logs.
>
> Signed-off-by: Dishank Garg <dishank.garg@xxxxxxxxxxxxxxxx>
> ---
> This series adds support for capturing QCA controller debug/diagnostic
> logs in Bluetooth snoop logs. Currently, ACL packets carrying QCA
> diagnostic data are intercepted and routed to the diagnostic layer via
> hci_recv_diag(), which means they never show up in snoop captures.
> This makes it hard to correlate QCA debug logs with the surrounding
> HCI/ACL traffic when debugging issues, since the two have to be
> captured and aligned separately.
>
> The series adds a new debugfs knob, diag_as_acl, under the hci_qca
> debugfs directory. When enabled, diagnostic ACL packets are forwarded
> through the normal ACL receive path instead of being diverted to the
> diagnostic layer, so they get captured in the standard Bluetooth snoop
> log alongside all other traffic.
> ---
> Changes in v2:
> - EDITME: describe what is new in this series revision.
> - EDITME: use bulletpoints and terse descriptions.
> - Link to v1: https://patch.msgid.link/20260804-qca_logs_enable-v1-1-4e209447da0e@xxxxxxxxxxxxxxxx
> ---
>  drivers/bluetooth/hci_qca.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 1222f97800f4..6996966319e8 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -182,6 +182,7 @@ struct qca_data {
>         u64 rx_votes_on;
>         u64 tx_votes_off;
>         u64 rx_votes_off;
> +       bool diag_as_acl;
>         u64 votes_on;
>         u64 votes_off;
>  };
> @@ -698,6 +699,7 @@ static void qca_debugfs_init(struct hci_dev *hdev)
>         debugfs_create_u32("wake_retrans", mode, ibs_dir, &qca->wake_retrans);
>         debugfs_create_u32("tx_idle_delay", mode, ibs_dir,
>                            &qca->tx_idle_delay);
> +       debugfs_create_bool("diag_as_acl", 0644, hdev->debugfs, &qca->diag_as_acl);
>  }
>
>  /* Flush protocol data */
> @@ -998,12 +1000,14 @@ static int qca_ibs_wake_ack(struct hci_dev *hdev, struct sk_buff *skb)
>
>  static int qca_recv_acl_data(struct hci_dev *hdev, struct sk_buff *skb)
>  {
> +       struct hci_uart *hu = hci_get_drvdata(hdev);
> +       struct qca_data *qca = hu->priv;
>         /* We receive debug logs from chip as an ACL packets.
>          * Instead of sending the data to ACL to decode the
>          * received data, we are pushing them to the above layers
>          * as a diagnostic packet.
>          */
> -       if (get_unaligned_le16(skb->data) == QCA_DEBUG_HANDLE)
> +       if (!READ_ONCE(qca->diag_as_acl) && get_unaligned_le16(skb->data) == QCA_DEBUG_HANDLE)
>                 return hci_recv_diag(hdev, skb);

This is going backwards, we don't want to process the debug handles,
that is probably not using L2CAP, etc, so falling back to
hci_recv_frame is a bad idea like captured by sashiko:

https://sashiko.dev/#/patchset/20260804-qca_logs_enable-v2-1-587d584ef4c2%40oss.qualcomm.com

Btw, the likes of hci_send_to_monitor do have support for
HCI_DIAG_PKT, so btmon don't have any problem decoding it, so either
you don't know what you are talking about or you are using a tool that
don't undertand vendor diagnostic monitor events (HCI_MON_VENDOR_DIAG)
see https://github.com/bluez/bluez/blob/master/doc/btsnoop-protocol.rst.

>
>         return hci_recv_frame(hdev, skb);
>
> ---
> base-commit: f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8
> change-id: 20260803-qca_logs_enable-9b8197aaac09
>
> Best regards,
> --
> Dishank Garg <dishank.garg@xxxxxxxxxxxxxxxx>
>


-- 
Luiz Augusto von Dentz