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. 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. But it'd also be nice to do it based on QoS too. >> However, I would prefer a solution is which user-space, ie. dhcp >> client can control the priority and/or BT coexistence. > > It's not just BT coex btw, with multi-channel support it might also be > interesting to not switch channels while DHCP is going on, for example. Right. Adrian -- 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
