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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 F1535C10DCE for ; Tue, 24 Mar 2020 07:05:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D12AF20735 for ; Tue, 24 Mar 2020 07:05:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727358AbgCXHF1 convert rfc822-to-8bit (ORCPT ); Tue, 24 Mar 2020 03:05:27 -0400 Received: from rtits2.realtek.com ([211.75.126.72]:54603 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725951AbgCXHF0 (ORCPT ); Tue, 24 Mar 2020 03:05:26 -0400 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.62 with qID 02O754Df005064, This message is accepted by code: ctloc85258 Received: from mail.realtek.com (RTEXMB06.realtek.com.tw[172.21.6.99]) by rtits2.realtek.com.tw (8.15.2/2.57/5.78) with ESMTPS id 02O754Df005064 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 15:05:04 +0800 Received: from RTEXMB02.realtek.com.tw (172.21.6.95) by RTEXMB06.realtek.com.tw (172.21.6.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 24 Mar 2020 15:05:04 +0800 Received: from RTEXMB04.realtek.com.tw (172.21.6.97) by RTEXMB02.realtek.com.tw (172.21.6.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 24 Mar 2020 15:05:04 +0800 Received: from RTEXMB04.realtek.com.tw ([fe80::d9c5:a079:495e:b999]) by RTEXMB04.realtek.com.tw ([fe80::d9c5:a079:495e:b999%6]) with mapi id 15.01.1779.005; Tue, 24 Mar 2020 15:05:04 +0800 From: Tony Chuang To: Kalle Valo CC: "linux-wireless@vger.kernel.org" , "briannorris@chromium.org" , Arend Van Spriel , Johannes Berg , "tamizhr@codeaurora.org" Subject: RE: [PATCH v2 2/2] rtw88: add a debugfs entry to enable/disable coex mechanism Thread-Topic: [PATCH v2 2/2] rtw88: add a debugfs entry to enable/disable coex mechanism Thread-Index: AQHV9eid5DTKsHzIFkaU/75iZgvikahFRc8AgAEbR4CAEQe7sA== Date: Tue, 24 Mar 2020 07:05:04 +0000 Message-ID: <79e3276a8bfe4cc1bb2788668cfd16d2@realtek.com> References: <20200309075852.11454-1-yhchuang@realtek.com> <20200309075852.11454-3-yhchuang@realtek.com> <877dzpu2lt.fsf@tynnyri.adurom.net> <33d4904b71a04ed8b0226ce07b037e05@realtek.com> <87a74ko66i.fsf@kamboji.qca.qualcomm.com> In-Reply-To: <87a74ko66i.fsf@kamboji.qca.qualcomm.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.68.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org > Tony Chuang writes: > > > Kalle Valo : > > > >> writes: > >> > >> > From: Yan-Hsuan Chuang > >> > > >> > Sometimes we need to stop the coex mechanism to debug, so that we > >> > can manually control the device through various outer commands. > >> > Hence, add a new debugfs coex_enable to allow us to enable/disable > >> > the coex mechanism when driver is running. > >> > > >> > To disable coex > >> > echo 0 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > > >> > To enable coex > >> > echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > > >> > To check coex dm is enabled or not > >> > cat /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable > >> > >> I forgot, did we add a command to nl80211 for managing btcoex? At least > >> we have talking about that for years. Please check that first before > >> adding a debugfs interface for this. > >> > > > > Yes, I found there was a thread [1] talking about adding a callback to > > enable/disable btcoex, but it seems not get applied eventually. > > Too bad, I really think we should have at least enable/disable > functionality in nl80211. But if it's not there, I guess it's ok to have > yet another driver custom debugfs file :/ > > > And there's another thread [2] talking about add a btcoex subsystem. > > But seems like nobody can implement it cleanly in the host. > > > > I think adding btcoex subsystem could have a lot of pain since each > > vendor is using different mechanism controlling the btcoex, and it > > usually comes with RF related design which is difficult to write a common > > function to deal with all kinds of them. > > Yeah, btcoex subsystem is a big challenge. > So I think we can take this patch set. It is really useful to debug on coex's issues. Yen-Hsuan