Re: Reporting firmware stats to ethtool

[Arend van Spriel <arend@broadcom.com>]

On 08/09/2014 08:30 AM, Kalle Valo wrote:
> Arend van Spriel <arend@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
>> 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