From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 888F5C28CF6 for ; Fri, 3 Aug 2018 13:42:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 384C721763 for ; Fri, 3 Aug 2018 13:42:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 384C721763 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732188AbeHCPjA (ORCPT ); Fri, 3 Aug 2018 11:39:00 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:3182 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729871AbeHCPi7 (ORCPT ); Fri, 3 Aug 2018 11:38:59 -0400 X-UUID: e06a3d0886b242cd86bd2f74edf5c82a-20180803 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1468524000; Fri, 03 Aug 2018 21:42:31 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs03n1.mediatek.inc (172.21.101.181) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Aug 2018 21:42:29 +0800 Received: from [172.21.77.33] (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Fri, 3 Aug 2018 21:42:29 +0800 Message-ID: <1533303749.3472.160.camel@mtkswgap22> Subject: Re: [PATCH v7 2/3] Bluetooth: mediatek: Add protocol support for MediaTek serial devices From: Sean Wang To: Marcel Holtmann CC: Rob Herring , Mark Rutland , Johan Hedberg , devicetree , "open list:BLUETOOTH DRIVERS" , linux-arm-kernel , , Date: Fri, 3 Aug 2018 21:42:29 +0800 In-Reply-To: References: <1707FFA1-A294-4A95-A3BF-0910CE455232@holtmann.org> <1533192799.3472.122.camel@mtkswgap22> <1533199720.3472.136.camel@mtkswgap22> <9526E5D9-50BA-4D57-80F5-083DB7D28AFE@holtmann.org> <1533205495.3472.144.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-08-03 at 14:51 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>>>>>> + > >>>>>>> +static int mtk_hci_wmt_sync(struct hci_dev *hdev, u8 op, u8 flag, u16 plen, > >>>>>>> + const void *param) > >>>>>>> +{ > >>>>>>> + struct mtk_hci_wmt_cmd wc; > >>>>>>> + struct mtk_wmt_hdr *hdr; > >>>>>>> + struct sk_buff *skb; > >>>>>>> + u32 hlen; > >>>>>>> + > >>>>>>> + hlen = sizeof(*hdr) + plen; > >>>>>>> + if (hlen > 255) > >>>>>>> + return -EINVAL; > >>>>>>> + > >>>>>>> + hdr = (struct mtk_wmt_hdr *)&wc; > >>>>>>> + hdr->dir = 1; > >>>>>>> + hdr->op = op; > >>>>>>> + hdr->dlen = cpu_to_le16(plen + 1); > >>>>>>> + hdr->flag = flag; > >>>>>>> + memcpy(wc.data, param, plen); > >>>>>>> + > >>>>>>> + atomic_inc(&hdev->cmd_cnt); > >>>>>> > >>>>>> Why are you doing this one. It will need a comment here if really needed. However I doubt that this is needed. You are only using it from hdev->setup and hdev->shutdown callbacks. > >>>>>> > >>>>> > >>>>> An increment on cmd_cnt is really needed because hci_cmd_work would check whether cmd_cnt is positive and then has a decrement on cmd_cnt before a packet is being sent out. > >>>>> > >>>>> okay will add a comment. > >>>> > >>>> but you are in ->setup callback this time. So if you need this, then all the other ->setup routines would actually fail as well. Either this is leftover from when you did things in ->probe or ->open or this is some thing we might better fix properly in the core instead of papering over it. Can you recheck if this is really needed. > >>>> > >>> > >>> I added a counter print and the counter increments as below > >>> > >>> /* atomic_inc(&hdev->cmd_cnt); */ > >>> pr_info("cmd_cnt = %d\n" , atomic_read(&hdev->cmd_cnt)); > >>> > >>> skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, > >>> HCI_INIT_TIMEOUT); > >>> > >>> and the log show up that > >>> > >>> > >>> [ 334.049156] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 334.054840] cmd_cnt = 0 > >>> [ 336.065076] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 336.070795] cmd_cnt = 0 > >>> [ 338.080997] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 338.086683] cmd_cnt = 0 > >>> [ 340.096907] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 340.102609] cmd_cnt = 0 > >>> [ 342.112824] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 342.118520] cmd_cnt = 0 > >>> [ 344.128747] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 344.134454] cmd_cnt = 0 > >>> [ 346.144667] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 346.150372] cmd_cnt = 0 > >>> > >>> > >>> The packet is dropped by hci_cmd_work at [1], so I also wondered why the > >>> other vendor driver works, it seems the counter needs to be incremented > >>> before every skb is being queued to cmd_q. > >>> > >>> 4257 static void hci_cmd_work(struct work_struct *work) > >>> 4258 { > >>> 4259 struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_work); > >>> 4260 struct sk_buff *skb; > >>> 4261 > >>> 4262 BT_DBG("%s cmd_cnt %d cmd queued %d", hdev->name, > >>> 4263 atomic_read(&hdev->cmd_cnt), skb_queue_len(&hdev->cmd_q)); > >>> 4264 > >>> 4265 /* Send queued commands */ > >>> > >>> [1] > >>> 4266 if (atomic_read(&hdev->cmd_cnt)) { /* dropped when cmd_cnt is zero */ > >>> 4267 skb = skb_dequeue(&hdev->cmd_q); > >>> 4268 if (!skb) > >>> 4269 return; > >>> 4270 > >>> 4271 kfree_skb(hdev->sent_cmd); > >>> 4272 > >>> 4273 hdev->sent_cmd = skb_clone(skb, GFP_KERNEL); > >>> 4274 if (hdev->sent_cmd) { > >>> 4275 atomic_dec(&hdev->cmd_cnt); /* cmd_cnt-- */ > >>> 4276 hci_send_frame(hdev, skb); > >> > >> actually the command also needs to better go via the raw_q anyway since it doesn’t come back with the cmd status or cmd complete. You have it waiting for a vendor event. Maybe with is something we need to consider with __hci_cmd_sync_ev anyway. > >> > >> Johan would know best since he wrote that code. Anyway, we should fix that in the core and not have you hack around it. > >> > > > > yes, my case is that received event is neither cmd status nor cmd complete. It is completely a vendor event. > > > > if it wants to be solved by the core layer, do you permit that I remove the hack and then send it in the next version? > > we need to have a __hci_raw_sync_ev that uses the hdev->raw_q and waits for the specified event to come back. I never realized that you are missing the cmd status or cmd complete. So this is similar to the original CSR vendor commands which had the same behavior. > > I have the feeling that you hdev->cmd_cnt increment is just hiding the problem here. If you really think that it is not chains any side effects we can merge the driver with a big warning and fix this up. However the clean way would be for you to create a patch that introduces __hci_raw_sync_ev as describe above. What do you think of this? If I add extra atomic_set 1 on cmd_cnt after driver really got a vendor event back instead of blinding to increment for every packet sent. the behavior is the same to receive a cmd status or complete. it should not have side effects. 96 skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, 97 HCI_INIT_TIMEOUT); 98 99 if (IS_ERR(skb)) { 100 int err = PTR_ERR(skb); 101 102 bt_dev_err(hdev, "Failed to send wmt cmd (%d)", err); 103 return err; 104 } 105 106 if (!test_bit(HCI_RESET, &hdev->flags)) <<<<<< 107 atomic_set(&hdev->cmd_cnt, 1); <<<<<< 108 109 kfree_skb(skb); > Regards > > Marcel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Wang Subject: Re: [PATCH v7 2/3] Bluetooth: mediatek: Add protocol support for MediaTek serial devices Date: Fri, 3 Aug 2018 21:42:29 +0800 Message-ID: <1533303749.3472.160.camel@mtkswgap22> References: <1707FFA1-A294-4A95-A3BF-0910CE455232@holtmann.org> <1533192799.3472.122.camel@mtkswgap22> <1533199720.3472.136.camel@mtkswgap22> <9526E5D9-50BA-4D57-80F5-083DB7D28AFE@holtmann.org> <1533205495.3472.144.camel@mtkswgap22> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Marcel Holtmann Cc: Rob Herring , Mark Rutland , Johan Hedberg , devicetree , "open list:BLUETOOTH DRIVERS" , linux-arm-kernel , linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On Fri, 2018-08-03 at 14:51 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>>>>>> + > >>>>>>> +static int mtk_hci_wmt_sync(struct hci_dev *hdev, u8 op, u8 flag, u16 plen, > >>>>>>> + const void *param) > >>>>>>> +{ > >>>>>>> + struct mtk_hci_wmt_cmd wc; > >>>>>>> + struct mtk_wmt_hdr *hdr; > >>>>>>> + struct sk_buff *skb; > >>>>>>> + u32 hlen; > >>>>>>> + > >>>>>>> + hlen = sizeof(*hdr) + plen; > >>>>>>> + if (hlen > 255) > >>>>>>> + return -EINVAL; > >>>>>>> + > >>>>>>> + hdr = (struct mtk_wmt_hdr *)&wc; > >>>>>>> + hdr->dir = 1; > >>>>>>> + hdr->op = op; > >>>>>>> + hdr->dlen = cpu_to_le16(plen + 1); > >>>>>>> + hdr->flag = flag; > >>>>>>> + memcpy(wc.data, param, plen); > >>>>>>> + > >>>>>>> + atomic_inc(&hdev->cmd_cnt); > >>>>>> > >>>>>> Why are you doing this one. It will need a comment here if really needed. However I doubt that this is needed. You are only using it from hdev->setup and hdev->shutdown callbacks. > >>>>>> > >>>>> > >>>>> An increment on cmd_cnt is really needed because hci_cmd_work would check whether cmd_cnt is positive and then has a decrement on cmd_cnt before a packet is being sent out. > >>>>> > >>>>> okay will add a comment. > >>>> > >>>> but you are in ->setup callback this time. So if you need this, then all the other ->setup routines would actually fail as well. Either this is leftover from when you did things in ->probe or ->open or this is some thing we might better fix properly in the core instead of papering over it. Can you recheck if this is really needed. > >>>> > >>> > >>> I added a counter print and the counter increments as below > >>> > >>> /* atomic_inc(&hdev->cmd_cnt); */ > >>> pr_info("cmd_cnt = %d\n" , atomic_read(&hdev->cmd_cnt)); > >>> > >>> skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, > >>> HCI_INIT_TIMEOUT); > >>> > >>> and the log show up that > >>> > >>> > >>> [ 334.049156] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 334.054840] cmd_cnt = 0 > >>> [ 336.065076] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 336.070795] cmd_cnt = 0 > >>> [ 338.080997] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 338.086683] cmd_cnt = 0 > >>> [ 340.096907] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 340.102609] cmd_cnt = 0 > >>> [ 342.112824] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 342.118520] cmd_cnt = 0 > >>> [ 344.128747] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 344.134454] cmd_cnt = 0 > >>> [ 346.144667] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 346.150372] cmd_cnt = 0 > >>> > >>> > >>> The packet is dropped by hci_cmd_work at [1], so I also wondered why the > >>> other vendor driver works, it seems the counter needs to be incremented > >>> before every skb is being queued to cmd_q. > >>> > >>> 4257 static void hci_cmd_work(struct work_struct *work) > >>> 4258 { > >>> 4259 struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_work); > >>> 4260 struct sk_buff *skb; > >>> 4261 > >>> 4262 BT_DBG("%s cmd_cnt %d cmd queued %d", hdev->name, > >>> 4263 atomic_read(&hdev->cmd_cnt), skb_queue_len(&hdev->cmd_q)); > >>> 4264 > >>> 4265 /* Send queued commands */ > >>> > >>> [1] > >>> 4266 if (atomic_read(&hdev->cmd_cnt)) { /* dropped when cmd_cnt is zero */ > >>> 4267 skb = skb_dequeue(&hdev->cmd_q); > >>> 4268 if (!skb) > >>> 4269 return; > >>> 4270 > >>> 4271 kfree_skb(hdev->sent_cmd); > >>> 4272 > >>> 4273 hdev->sent_cmd = skb_clone(skb, GFP_KERNEL); > >>> 4274 if (hdev->sent_cmd) { > >>> 4275 atomic_dec(&hdev->cmd_cnt); /* cmd_cnt-- */ > >>> 4276 hci_send_frame(hdev, skb); > >> > >> actually the command also needs to better go via the raw_q anyway since it doesn’t come back with the cmd status or cmd complete. You have it waiting for a vendor event. Maybe with is something we need to consider with __hci_cmd_sync_ev anyway. > >> > >> Johan would know best since he wrote that code. Anyway, we should fix that in the core and not have you hack around it. > >> > > > > yes, my case is that received event is neither cmd status nor cmd complete. It is completely a vendor event. > > > > if it wants to be solved by the core layer, do you permit that I remove the hack and then send it in the next version? > > we need to have a __hci_raw_sync_ev that uses the hdev->raw_q and waits for the specified event to come back. I never realized that you are missing the cmd status or cmd complete. So this is similar to the original CSR vendor commands which had the same behavior. > > I have the feeling that you hdev->cmd_cnt increment is just hiding the problem here. If you really think that it is not chains any side effects we can merge the driver with a big warning and fix this up. However the clean way would be for you to create a patch that introduces __hci_raw_sync_ev as describe above. What do you think of this? If I add extra atomic_set 1 on cmd_cnt after driver really got a vendor event back instead of blinding to increment for every packet sent. the behavior is the same to receive a cmd status or complete. it should not have side effects. 96 skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, 97 HCI_INIT_TIMEOUT); 98 99 if (IS_ERR(skb)) { 100 int err = PTR_ERR(skb); 101 102 bt_dev_err(hdev, "Failed to send wmt cmd (%d)", err); 103 return err; 104 } 105 106 if (!test_bit(HCI_RESET, &hdev->flags)) <<<<<< 107 atomic_set(&hdev->cmd_cnt, 1); <<<<<< 108 109 kfree_skb(skb); > Regards > > Marcel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: sean.wang@mediatek.com (Sean Wang) Date: Fri, 3 Aug 2018 21:42:29 +0800 Subject: [PATCH v7 2/3] Bluetooth: mediatek: Add protocol support for MediaTek serial devices In-Reply-To: References: <1707FFA1-A294-4A95-A3BF-0910CE455232@holtmann.org> <1533192799.3472.122.camel@mtkswgap22> <1533199720.3472.136.camel@mtkswgap22> <9526E5D9-50BA-4D57-80F5-083DB7D28AFE@holtmann.org> <1533205495.3472.144.camel@mtkswgap22> Message-ID: <1533303749.3472.160.camel@mtkswgap22> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 2018-08-03 at 14:51 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>>>>>> + > >>>>>>> +static int mtk_hci_wmt_sync(struct hci_dev *hdev, u8 op, u8 flag, u16 plen, > >>>>>>> + const void *param) > >>>>>>> +{ > >>>>>>> + struct mtk_hci_wmt_cmd wc; > >>>>>>> + struct mtk_wmt_hdr *hdr; > >>>>>>> + struct sk_buff *skb; > >>>>>>> + u32 hlen; > >>>>>>> + > >>>>>>> + hlen = sizeof(*hdr) + plen; > >>>>>>> + if (hlen > 255) > >>>>>>> + return -EINVAL; > >>>>>>> + > >>>>>>> + hdr = (struct mtk_wmt_hdr *)&wc; > >>>>>>> + hdr->dir = 1; > >>>>>>> + hdr->op = op; > >>>>>>> + hdr->dlen = cpu_to_le16(plen + 1); > >>>>>>> + hdr->flag = flag; > >>>>>>> + memcpy(wc.data, param, plen); > >>>>>>> + > >>>>>>> + atomic_inc(&hdev->cmd_cnt); > >>>>>> > >>>>>> Why are you doing this one. It will need a comment here if really needed. However I doubt that this is needed. You are only using it from hdev->setup and hdev->shutdown callbacks. > >>>>>> > >>>>> > >>>>> An increment on cmd_cnt is really needed because hci_cmd_work would check whether cmd_cnt is positive and then has a decrement on cmd_cnt before a packet is being sent out. > >>>>> > >>>>> okay will add a comment. > >>>> > >>>> but you are in ->setup callback this time. So if you need this, then all the other ->setup routines would actually fail as well. Either this is leftover from when you did things in ->probe or ->open or this is some thing we might better fix properly in the core instead of papering over it. Can you recheck if this is really needed. > >>>> > >>> > >>> I added a counter print and the counter increments as below > >>> > >>> /* atomic_inc(&hdev->cmd_cnt); */ > >>> pr_info("cmd_cnt = %d\n" , atomic_read(&hdev->cmd_cnt)); > >>> > >>> skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, > >>> HCI_INIT_TIMEOUT); > >>> > >>> and the log show up that > >>> > >>> > >>> [ 334.049156] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 334.054840] cmd_cnt = 0 > >>> [ 336.065076] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 336.070795] cmd_cnt = 0 > >>> [ 338.080997] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 338.086683] cmd_cnt = 0 > >>> [ 340.096907] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 340.102609] cmd_cnt = 0 > >>> [ 342.112824] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 342.118520] cmd_cnt = 0 > >>> [ 344.128747] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 344.134454] cmd_cnt = 0 > >>> [ 346.144667] Bluetooth: hci0: command 0xfc6f tx timeout > >>> [ 346.150372] cmd_cnt = 0 > >>> > >>> > >>> The packet is dropped by hci_cmd_work at [1], so I also wondered why the > >>> other vendor driver works, it seems the counter needs to be incremented > >>> before every skb is being queued to cmd_q. > >>> > >>> 4257 static void hci_cmd_work(struct work_struct *work) > >>> 4258 { > >>> 4259 struct hci_dev *hdev = container_of(work, struct hci_dev, cmd_work); > >>> 4260 struct sk_buff *skb; > >>> 4261 > >>> 4262 BT_DBG("%s cmd_cnt %d cmd queued %d", hdev->name, > >>> 4263 atomic_read(&hdev->cmd_cnt), skb_queue_len(&hdev->cmd_q)); > >>> 4264 > >>> 4265 /* Send queued commands */ > >>> > >>> [1] > >>> 4266 if (atomic_read(&hdev->cmd_cnt)) { /* dropped when cmd_cnt is zero */ > >>> 4267 skb = skb_dequeue(&hdev->cmd_q); > >>> 4268 if (!skb) > >>> 4269 return; > >>> 4270 > >>> 4271 kfree_skb(hdev->sent_cmd); > >>> 4272 > >>> 4273 hdev->sent_cmd = skb_clone(skb, GFP_KERNEL); > >>> 4274 if (hdev->sent_cmd) { > >>> 4275 atomic_dec(&hdev->cmd_cnt); /* cmd_cnt-- */ > >>> 4276 hci_send_frame(hdev, skb); > >> > >> actually the command also needs to better go via the raw_q anyway since it doesn?t come back with the cmd status or cmd complete. You have it waiting for a vendor event. Maybe with is something we need to consider with __hci_cmd_sync_ev anyway. > >> > >> Johan would know best since he wrote that code. Anyway, we should fix that in the core and not have you hack around it. > >> > > > > yes, my case is that received event is neither cmd status nor cmd complete. It is completely a vendor event. > > > > if it wants to be solved by the core layer, do you permit that I remove the hack and then send it in the next version? > > we need to have a __hci_raw_sync_ev that uses the hdev->raw_q and waits for the specified event to come back. I never realized that you are missing the cmd status or cmd complete. So this is similar to the original CSR vendor commands which had the same behavior. > > I have the feeling that you hdev->cmd_cnt increment is just hiding the problem here. If you really think that it is not chains any side effects we can merge the driver with a big warning and fix this up. However the clean way would be for you to create a patch that introduces __hci_raw_sync_ev as describe above. What do you think of this? If I add extra atomic_set 1 on cmd_cnt after driver really got a vendor event back instead of blinding to increment for every packet sent. the behavior is the same to receive a cmd status or complete. it should not have side effects. 96 skb = __hci_cmd_sync_ev(hdev, 0xfc6f, hlen, &wc, HCI_VENDOR_PKT, 97 HCI_INIT_TIMEOUT); 98 99 if (IS_ERR(skb)) { 100 int err = PTR_ERR(skb); 101 102 bt_dev_err(hdev, "Failed to send wmt cmd (%d)", err); 103 return err; 104 } 105 106 if (!test_bit(HCI_RESET, &hdev->flags)) <<<<<< 107 atomic_set(&hdev->cmd_cnt, 1); <<<<<< 108 109 kfree_skb(skb); > Regards > > Marcel >