[PATCH] ath10k: add configurable debugging.

Adrian Chadd adrian at freebsd.org
Thu Jun 1 06:33:38 PDT 2017

On 1 June 2017 at 06:24, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Arend van Spriel <arend.vanspriel at broadcom.com> writes:
>> On 31-05-17 14:16, Kalle Valo wrote:
>>> Adrian Chadd <adrian at freebsd.org> writes:
>>>> This adds a few configurable debugging options:
>>>> * driver debugging and tracing is now configurable per device
>>>> * driver debugging and tracing is now configurable at runtime
>>>> * the debugging / tracing is not run at all (besides a mask check)
>>>>   unless the specific debugging bitmap field is configured.
>>>> Signed-off-by: Adrian Chadd <adrian at FreeBSD.org>
>>> [...]
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>>> @@ -2444,6 +2444,8 @@ struct ath10k *ath10k_core_create(size_t
>>>> priv_size, struct device *dev,
>>>>     ar->hw_rev = hw_rev;
>>>>     ar->hif.ops = hif_ops;
>>>>     ar->hif.bus = bus;
>>>> +   ar->debug_mask = ath10k_debug_mask;
>>>> +   ar->trace_debug_mask = ath10k_debug_mask;
>>> Until now tracing has been always enabled, irrespective what debug_mask
>>> has contained. Now you are changing that and by default log messages are
>>> not delivered through tracing until user enables them. So I think to
>>> keep the old behaviour trace_debug_mask should be ATH10K_DBG_ANY
>>> (0xffffffff) by default and the user can modify the mask per device via
>>> the debugfs file.
>>> But is it really needed to be able to filter trace messages? debug_mask
>>> I understand, but not sure about trace_debug_mask.
>> FWIW, in brcmfmac I decided not to filter trace messages. The overhead
>> is relatively small and if needed you can pass filter expressions with
>> trace-cmd record.
> I also think that this is how it should work. For example, if you have
> tracing enabled in wpasupplicant/hostapd with the command below you can
> get a lot of information in one file with relatively little overhead:
> trace-cmd record -e mac80211 -e cfg80211 -e ath10k
> But if user is forced to use debugfs to enable ath10k tracing that is
> quite a step backwards.

I agree that is how it should work, but i can't see how you do it on
ath10k without the debug overhead always being there.

If there's a way to know /a/ trace watch is going on from the kernel
then it could be flipped on for that, but i didn't see any obvious
"trace enable" / "trace disable" hooks.


More information about the ath10k mailing list