Hi Balakrishna,
> This change sets SSR triggered flags when QCA SSR command is sent to
> SoC. After the SSR command sent, driver discards the incoming data from
> the upper layers. This way will ensure to read full dumps from the
> BT SoC without any flow control issues due to excess of data receiving
> from the HOST in audio usecases.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@xxxxxxxxxxxxxx>
> ---
> drivers/bluetooth/hci_qca.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 53deea2..5cbed6a 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -69,6 +69,8 @@
> #define QCA_LAST_SEQUENCE_NUM 0xFFFF
> #define QCA_CRASHBYTE_PACKET_LEN 1096
> #define QCA_MEMDUMP_BYTE 0xFB
> +#define QCA_SSR_OPCODE 0xFC0C
> +#define QCA_SSR_PKT_LEN 5
>
> enum qca_flags {
> QCA_IBS_DISABLED,
> @@ -871,6 +873,14 @@ static int qca_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> /* Prepend skb with frame type */
> memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
>
> + if (hci_skb_pkt_type(skb) == HCI_COMMAND_PKT &&
> + skb->len == QCA_SSR_PKT_LEN &&
> + hci_skb_opcode(skb) == QCA_SSR_OPCODE) {
> + bt_dev_info(hu->hdev, "Triggering ssr");
> + set_bit(QCA_SSR_TRIGGERED, &qca->flags);
> + set_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
> + }
> +
can we please stop hacking around by parsing opcodes in an enqueue function. Sounds like someone is injecting raw HCI vendor commands and then having a driver react to it.
Regards
Marcel
