Reporting firmware stats to ethtool
Arend van Spriel
arend at broadcom.com
Sat Aug 9 00:30:01 PDT 2014
On 08/09/2014 08:30 AM, Kalle Valo wrote:
> Arend van Spriel <arend at broadcom.com> 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
> 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
I am not sure what infrastructure your "ath10k firmware crash dump" is
going to use. I have seen similar thing from Marvell recently  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.
More information about the ath10k