Return-path: Received: from mms1.broadcom.com ([216.31.210.17]:2544 "EHLO mms1.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932469Ab3BYKLq (ORCPT ); Mon, 25 Feb 2013 05:11:46 -0500 Message-ID: <512B38D3.7000401@broadcom.com> (sfid-20130225_111149_558005_73D88A75) Date: Mon, 25 Feb 2013 11:11:31 +0100 From: "Arend van Spriel" MIME-Version: 1.0 To: "Felix Fietkau" cc: "Adrian Chadd" , "Johannes Berg" , "linux-wireless@vger.kernel.org" , "Piotr Haber" Subject: Re: [PATCH 1/2] [RFC] cfg80211: configuration of Bluetooth coexistence mode References: <1361564916.3420.11.camel@jlt4.sipsolutions.net> <1361726886.8129.9.camel@jlt4.sipsolutions.net> <512AFC80.9030808@openwrt.org> In-Reply-To: <512AFC80.9030808@openwrt.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 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