Re: [PATCH 1/2] [RFC] cfg80211: configuration of Bluetooth coexistence mode

[Felix Fietkau <nbd@openwrt.org>]

On 2013-02-25 6:08 AM, Adrian Chadd wrote:
> On 24 February 2013 09:28, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
>>> In the driver we could inspect each sk_buff and boost priority of any
>>> BOOTP packets so that it will end up in the AC_VO fifo and have
>>> hardware coexistence handle it further. I consider that more a
>>> pragmatic fix, which is not always the worst thing to go for.
>>
>> Well, I don't really think that's the best idea. Sniffing the protocol
>> is clumsy at best.
> 
> Sure, but it's the kind of thing that commercial devices do in order
> to work around real world issues.
Just because commercial devices do this crap to weasel out of fixing
things properly doesn't mean we have to do the same.

> So it'd be nice to have a programmatic way to detect things (eg bootp
> packets going out) and signal the driver via some side channel to do
> things like btcoex weight changing.
I disagree, that approach clumsy and fragile and it's trying to address
the issue in the wrong place.

Most devices have some kind of connection manager that has a high-level
perspective of when it's fully connected (which includes DHCP/bootp).
Why not just let that connection manager set a sane maximum network
latency value via pm_qos network_latency and derive btcoex weight
changing and multi-channel settings from that?

- Felix