Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> writes: > On 31-05-17 14:16, Kalle Valo wrote: >> Adrian Chadd <adrian@xxxxxxxxxxx> 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@xxxxxxxxxxx> >> >> [...] >> >>> --- 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. -- Kalle Valo
