Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4533758ybb; Tue, 24 Mar 2020 00:06:01 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuI0z/t3TXE1Szm7BsN6Eon1DdZM12ZGBzDx7g2Z1pCK3h3PMITJooQc4PR9NPgZ1Jf25e8 X-Received: by 2002:a05:6830:403d:: with SMTP id i29mr19496388ots.353.1585033561431; Tue, 24 Mar 2020 00:06:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585033561; cv=none; d=google.com; s=arc-20160816; b=rH+LtFQan5fRzw1xBxIJ7T/gjoVLDQ9f/7kEMa8li7B2GIIy/pHeF91AYupCh2CPU4 oVqcgVYxN9bNqTBQKnohVIQz8SwLB9vt7yRqjzLbOalGWk6FILAQ4AuZU2xi9Rvjy0Jc S2c0CRzuPK6xfZlBq3wQKwo1sjvBVZVeyvl6dG62CDAneXt2IIalJevEWjhcO4oG0pwq +VjT8dLP6itO3aZq3iuQXCw/UArx+1hM7yUr69c1brJwfTD9ntl/Z+9ZdJ/nXiry7lcx OlYEhbX02BEpxoM456Y+Jg9OOAFlvNw9qlnQx9H51UU16Sx4BxluXCT8hTrb8fJNLkOw aoKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from:authenticated-by; bh=vxm1WKQ+0KKsXAXdlHuZAV4KtijbhPXVc6FMSgvOo0s=; b=vErCinGdJhNFkTHhU5gJ/gPfBjShhARrka9YT8zk7XG/FSZJcv8+9GhEGtZrC7vV4z uv+QzBl/YT/chLl6mvyRA6g9WWSjsMtHETyfLtOu+V7PjP+R9cz59YHYs50583nK3fgk Y9AQ1plbEoLntT9kTC3n2WrZVNLhA0wlxecf6S8cf7zFFAZI43R0iIX1ttINMhccXTIf ERF0OOhMZuBJjK3drozV1WvHoYBuq0lksjNh9Xm4DUYX+4NmGa+e20WufF/rwyzjBsBU 0gCfVAe9wZAOx7D4/JxYa9XtbMS/xF5ixh1jBvkl35w8S+qdRPZt1JoxOi8rE7Vp4aPJ ylKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si9027820otc.153.2020.03.24.00.05.49; Tue, 24 Mar 2020 00:06:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727351AbgCXHF0 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 24 Mar 2020 03:05:26 -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