On 08/09/2014 08:30 AM, Kalle Valo wrote:
Arend van Spriel <[email protected]> writes:
I do kind of prefer 64 bit counters in the general case. Nuke it from
orbit, it's the only way to be sure.
It's 64-bit to user-space, but that means nothing because firmware
uses 32-bit (or even 16 bit in some cases, probably) internally.
A great deal of counters are the same, so be very careful when
trying to keep long term counters grabbed from firmware/drivers/hardware.
And, stations come and go when you re-associate, so all sorts of wifi counters
reset themselves all the time...
Does ath driver notify mac80211 about firmware restart, ie. through
ieee80211_restart_hw().
ath10k does use ieee80211_restart_hw().
If only user-space could get that info.
Yeah, that would be nice to have for ath10k firmware crash dump
functionality. And doesn't Android also need something similar?
Probably. bcmdhd seems to send a "firmware hang" event up to wpa_supp,
which probably ends up in the android wifi framework through the control
interface. Currently, this is a driver private event handled by
wpa_supplicant_lib, but it seems trivial to me to add a nl80211 event to
trigger that.
I am not sure what infrastructure your "ath10k firmware crash dump" is
going to use. I have seen similar thing from Marvell recently [1] which
relies on udev and ethtool to do the work. I guess aligning the
solutions is why this topic is listed for the wireless breakout session
at kernel summit in Chicago.
Regards,
Arend
[1] http://www.spinics.net/lists/linux-wireless/msg123943.html
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
