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. Regards, Arend