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@oss.qualcomm.com>
---
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@oss.qualcomm.com
---
 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);
 
 	return hci_recv_frame(hdev, skb);

---
base-commit: f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8
change-id: 20260803-qca_logs_enable-9b8197aaac09

Best regards,
--  
Dishank Garg <dishank.garg@oss.qualcomm.com>

Hi Dishank,

On Tue, Aug 4, 2026 at 1:20 AM Dishank Garg
<dishank.garg@oss.qualcomm.com> 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@oss.qualcomm.com>
> ---
> 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@oss.qualcomm.com
> ---
>  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@oss.qualcomm.com>
>


-- 
Luiz Augusto von Dentz

On 8/4/2026 10:47 AM, Dishank Garg 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@oss.qualcomm.com>
> ---
> 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@oss.qualcomm.com
> ---
>   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);
>   
>   	return hci_recv_frame(hdev, skb);
>
> ---
> base-commit: f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8
> change-id: 20260803-qca_logs_enable-9b8197aaac09
>
> Best regards,
> --
> Dishank Garg <dishank.garg@oss.qualcomm.com>
Apologies for the confusion - the "v1" of this patch was sent as a test 
email to myself only, before I had added the actual To/Cc recipients. 
When I then sent it to the correct list with the full recipient list, b4 
auto-incremented it to "v2".
There were no changes to the patch content between the two - please 
disregard the v1 test mail and treat this v2 as the first real 
submission for review. I'll continue versioning normally (v2, v3, ...) 
from here if further changes are needed.

Best regards,
Dishank Garg