> Subject: Re: [PATCH v2 5/5] rtw88: add BT co-existence support
> 
> On Thu, Jul 25, 2019 at 10:53:31AM +0800, yhchu...@realtek.com wrote:
> > +static struct sk_buff *rtw_coex_info_request(struct rtw_dev *rtwdev,
> > +                                        struct rtw_coex_info_req *req)
> > +{
> > +   struct rtw_coex *coex = &rtwdev->coex;
> > +   struct sk_buff *skb_resp = NULL;
> > +
> > +   mutex_lock(&coex->mutex);
> > +
> > +   rtw_fw_query_bt_mp_info(rtwdev, req);
> > +
> > +   if (!wait_event_timeout(coex->wait, !skb_queue_empty(&coex->queue),
> > +                           COEX_REQUEST_TIMEOUT)) {
> > +           rtw_err(rtwdev, "coex request time out\n");
> > +           goto out;
> > +   }
> > +
> > +   skb_resp = skb_dequeue(&coex->queue);
> > +   if (!skb_resp) {
> > +           rtw_err(rtwdev, "failed to get coex info response\n");
> > +           goto out;
> > +   }
> > +
> > +out:
> > +   mutex_unlock(&coex->mutex);
> > +   return skb_resp;
> > +}
> > +
> > +static bool rtw_coex_get_bt_scan_type(struct rtw_dev *rtwdev, u8
> *scan_type)
> > +{
> > +   struct rtw_coex_info_req req = {0};
> > +   struct sk_buff *skb;
> > +   u8 *payload;
> > +   bool ret = false;
> > +
> > +   req.op_code = BT_MP_INFO_OP_SCAN_TYPE;
> > +   skb = rtw_coex_info_request(rtwdev, &req);
> > +   if (!skb)
> > +           goto out;
> > +
> > +   payload = get_payload_from_coex_resp(skb);
> > +   *scan_type = GET_COEX_RESP_BT_SCAN_TYPE(payload);
> > +   ret = true;
> > +
> > +out:
> > +   return ret;
> > +}
> > +
> > +static bool rtw_coex_set_lna_constrain_level(struct rtw_dev *rtwdev,
> > +                                        u8 lna_constrain_level)
> > +{
> > +   struct rtw_coex_info_req req = {0};
> > +   struct sk_buff *skb;
> > +   bool ret = false;
> > +
> > +   req.op_code = BT_MP_INFO_OP_LNA_CONSTRAINT;
> > +   req.para1 = lna_constrain_level;
> > +   skb = rtw_coex_info_request(rtwdev, &req);
> > +   if (!skb)
> > +           goto out;
> 
> Those coex response skb buffers are allocated in rtw_pci_rx_isr(),
> but I do not see where they are freed (seems we do not process
> them in c2h_work which does dev_kfree_skb()).

You're right, that SKB leaked. Should free them after responded.
I will send v2 to fix it :)

Thanks.

> 
> Stanislaw

Yan-Hsuan

Reply via email to