netdev - Re: [PATCH] ath9k: turn on btcoex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87in41nxfx.fsf@kamboji.qca.qualcomm.com>
Date:   Thu, 23 Aug 2018 14:18:10 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     Felix Fietkau <nbd@....name>, ath9k-devel@....qualcomm.com,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ath9k: turn on btcoex_enable as default

Kai-Heng Feng <kai.heng.feng@...onical.com> writes:

> at 12:15, Kai Heng Feng <kai.heng.feng@...onical.com> wrote:
>
>>
>>
>>> On 10 Feb 2018, at 10:05 PM, Felix Fietkau <nbd@....name> wrote:
>>>
>>> On 2018-02-10 14:56, Kai Heng Feng wrote:
>>>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo <kvalo@...eaurora.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?

I don't know what Felix thinkgs, but to me using DMI sounds like a good
idea to try, assuming the matches are unique enough and there's no risk
of enabling bt coex on wrong platforms. Should the PCI bus number etc
checked as well in case the user adds more ath9k devices to the
platform?

But of course I need to see the patch to comment more.

-- 
Kalle Valo