From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Subject: Re: [PATCH] ath9k: turn on btcoex_enable as default Date: Sat, 10 Feb 2018 15:05:05 +0100 Message-ID: <7170e2d5-a59d-8260-fa8e-f02f583b773f@nbd.name> References: <20180208052801.15670-1-kai.heng.feng@canonical.com> <56d650e6-d26f-087c-4e86-2e5d4e859414@nbd.name> <87k1vmeip8.fsf@kamboji.qca.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: Kai Heng Feng , Kalle Valo Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 2018-02-10 14:56, Kai Heng Feng wrote: > >> On 9 Feb 2018, at 3:16 PM, Kalle Valo wrote: >> Sure, but we have to make sure that we don't create regressions on >> existing systems. For example, did you test this with any system which >> don't support btcoex? (just asking, haven't tested this myself) > > No not really, but I will definitely test it. > The only module I have that uses ath9k is Dell’s DW1707. > How do I check if it support btcoex or not? I just reviewed the code again, and I am sure that we cannot merge this patch. Enabling the btcoex parameter makes the driver enable a whole bunch of code starting timers, listening to some GPIOs, etc. On non-btcoex systems, some of those GPIOs might be floating or even connected to different things, which could cause a lot of undefined behavior. This is simply too big a risk, so there absolutely needs to be a whitelist for systems that need this, otherwise it has to remain disabled by default. - Felix