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

["Arend van Spriel" <arend@broadcom.com>]

On 02/25/13 06:54, Felix Fietkau wrote:
> 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).

Hi Felix,

I agree with you here. I think the responsibility is indeed to be placed 
at a higher level.

> 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?

Now you are loosing me, but that can be helped. Could you educate me 
here a bit or some pointers to reading material? If there is a proper 
means already in place to communicate the information we might as well 
use it.

> - Felix
>

Regards,
Arend