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@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).
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
--
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
