linux-kernel - Re: [PATCH v1] Bluetooth: hci_qca: Drop unused event during BT on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c3ed299e-709e-4fae-9ef6-c5ad2f6a1c55@quicinc.com>
Date: Wed, 21 Aug 2024 14:58:01 +0800
From: Cheng Jiang <quic_chejiang@...cinc.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: Marcel Holtmann <marcel@...tmann.org>,
        Luiz Augusto von Dentz
	<luiz.dentz@...il.com>,
        <linux-bluetooth@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] Bluetooth: hci_qca: Drop unused event during BT on

Hi Paul, 

Thank you for the comment. 

On 8/21/2024 12:49 PM, Paul Menzel wrote:
> Dear Cheng,
> 
> 
> Thank you for your patch.
> 
> Am 21.08.24 um 06:16 schrieb Cheng Jiang:
> 
>> Is there any comment for the changes? Thanks!
>>
>> On 7/26/2024 5:58 PM, Cheng Jiang wrote:
>>> For the WCN6750/WCN6855/WCN7850, the vendor command for a baudrate
>>> change is not sent as synchronous HCI command, controller sends the
>>> corresponding vendor event with the new baudrate. It needs to be
>>> dropped, otherwise it may be misinterpreted as response to a later
>>> command.
> 
> Is that documented in some datasheet?
It's defined in 80-WL520-14_REV_F_Bluetooth_HCI_Vendor_Specific_Commands_Application_Note.pdf. 
> 
> How can this behavior be tested, and your change be verified? How did you test it?
>From the dmegs log, we can find the "Bluetooth: hci0: unexpected event for opcode 0xfc48" in dmesg. The change
is verified on QCOM's platform. Check the log is disappeared in dmesg when boot up the system.  
> 
>>> Signed-off-by: Cheng Jiang <quic_chejiang@...cinc.com>
>>> ---
>>>   drivers/bluetooth/hci_qca.c | 16 +++++++++++++++-
>>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>>> index ca6466676902..f497d601e035 100644
>>> --- a/drivers/bluetooth/hci_qca.c
>>> +++ b/drivers/bluetooth/hci_qca.c
>>> @@ -1206,7 +1206,15 @@ static int qca_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
>>>            * vendor command).
>>>            */
>>>   -        if (hdr->evt == HCI_EV_VENDOR)
>>> +        /* For the WCN6750/WCN6855/WCN7850, like the WCN3990, the
> 
> Does “like the” mean “and” in this situation? WCN3990 is not mentioned in the commit message.
WCN3990 is already handled in the exist code. WCN3990 uses HCI_EV_VENDOR (0xff) as event code while
WCN6750/WCN6855/WCN7850 use HCI_EV_CMD_COMPLETE(0x0e). The logic of handling this event is almost the
same.
> 
>>> +         * vendor command for a baudrate change command isn't sent as
>>> +         * synchronous HCI command, the controller sends the corresponding
>>> +         * command complete event with the new baudrate. The event is
>>> +         * received and properly decoded after changing the baudrate of
>>> +         * the host port. It needs to be dropped.
>>> +         */
>>> +
> 
> It’d remove the blank line.
Will remove in next patch. 
> 
>>> +        if (hdr->evt == HCI_EV_VENDOR || hdr->evt == HCI_EV_CMD_COMPLETE)
>>>               complete(&qca->drop_ev_comp);
> 
> Excuse my ignorance. Is `HCI_EV_CMD_COMPLETE` only sent in case of a baudrate change?
HCI_EV_CMD_COMPLETE is also sent for other HCI command. This section is called only if QCA_DROP_VENDOR_EVENT is
set. QCA_DROP_VENDOR_EVENT is set before sending the baudrate change HCI command, and cleared after received 
the event or timeout happens. So only the event for baudrate change HCI command is dropped here. 
> 
>>>           kfree_skb(skb);
>>> @@ -1497,6 +1505,9 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>>             switch (soc_type) {
>>>           case QCA_WCN3990:
>>> +        case QCA_WCN6750:
>>> +        case QCA_WCN6855:
>>> +        case QCA_WCN7850:
> 
> So setting the speed wasn’t working before?
It works before, but the event of baudrate change HCI command is not handled properly. Here is used to set
the QCA_DROP_VENDOR_EVENT flags and reinit completion. They will be used when handling event from controller.
> 
>>>               reinit_completion(&qca->drop_ev_comp);
>>>               set_bit(QCA_DROP_VENDOR_EVENT, &qca->flags);
>>>               break;
>>> @@ -1531,6 +1542,9 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>>             switch (soc_type) {
>>>           case QCA_WCN3990:
>>> +        case QCA_WCN6750:
>>> +        case QCA_WCN6855:
>>> +        case QCA_WCN7850:
>>>               /* Wait for the controller to send the vendor event
>>>                * for the baudrate change command.
>>>                */
> 
> 
> Kind regards,
> 
> Paul