Messages in this thread | | | Subject | Re: [PATCH] ath9k: turn on btcoex_enable as default | From | Kai-Heng Feng <> | Date | Thu, 23 Aug 2018 09:33:56 +0800 |
| |
at 12:15, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
> > >> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@nbd.name> wrote: >> >> On 2018-02-10 14:56, Kai Heng Feng wrote: >>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@codeaurora.org> 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?
Sorry for bringing this up again.
Is DMI based match an acceptable approach for ath9k?
Kai-Heng
> > Kai-Heng > >> - Felix
| |