On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@xxxxxxxx> wrote:
On 2018-02-10 14:56, Kai Heng Feng wrote:
I just reviewed the code again, and I am sure that we cannot merge thisOn 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?
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
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?