[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a5jzmylu.fsf@kernel.org>
Date: Wed, 05 Jun 2024 14:13:17 +0300
From: Kalle Valo <kvalo@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: "Nemanov, Michael" <michael.nemanov@...com>, Johannes Berg
<johannes.berg@...el.com>, Breno Leitao <leitao@...ian.org>, Justin
Stitt <justinstitt@...gle.com>, Kees Cook <keescook@...omium.org>,
linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org, Sabeeh
Khan <sabeeh-khan@...com>
Subject: Re: [PATCH 08/17] Add main.c
Krzysztof Kozlowski <krzk@...nel.org> writes:
>>>>> +u32 cc33xx_debug_level = DEBUG_NO_DATAPATH;
>>>>>
>>>> Why this is global? Why u32? Why global variable is defined at the end
>>>> of the file?!?!
>>>
>>> cc33xx_debug_level together with cc33xx_debug/info/error() macros is how
>>> all traces were done in drivers/net/wireless/ti/wlcore/ (originally was
>>> wl1271_debug/info etc.)
>>> It enables / disables traces without rebuilding or even reloading which
>>> is very helpful for remote support. These macros map to dynamic_pr_debug
>>> / pr_debug. I saw similar wrappers in other wireless drivers (ath12k).
>>> This is also why there are plenty of cc33xx_debug() all over the code,
>>> most are silent by default.
>>
>> Any more thoughts on debug traces? I'll remove all trivial function
>> entry / exit traces as Krzysztof requested. Is it OK to keep other
>> cc33xx_debug() calls which will be off by default?
>
> Sorry, I don't see the point. Dynamic debug gives you debug control. You
> just added orthogonal code to existing debug infrastructure, so as far
> as I am concerned, this should be dropped in favor of standard debugging
> calls.
I think most wireless drivers have this kind of debug level parameter,
for example debug_level in iwlwifi or debug_mask in ath12k. Our problem
with the dynamic debug framework is that it's either too fine grained
(ie. per line) or too coarse (per file), but in wireless we usually want
to have some kind of per functionality level debugging as well. For
example, to show only management frame transmissions, certain firmware
interface commands and so on.
A long time ago there was a discussion about extending dynamic debug
framework but not sure if that ever happened.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Powered by blists - more mailing lists