On 2013-02-25 6:08 AM, Adrian Chadd wrote: > On 24 February 2013 09:28, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
