> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@xxxxxxxx> wrote: > > On 2018-02-10 14:56, Kai Heng Feng wrote: >> >>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> 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. So what information can we use to whitelist btcoex chips? Can we get btcoex support status at ath9k probing? Kai-Heng > > - Felix
