[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a144311-2085-60b5-ea36-554c6efbf7e9@gmail.com>
Date: Fri, 14 Aug 2020 19:25:58 +0200
From: Christian Lamparter <chunkeey@...il.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: davem@...emloft.net, kuba@...nel.org, linux-kernel@...r.kernel.org,
Christian Lamparter <chunkeey@...glemail.com>,
Kalle Valo <kvalo@...eaurora.org>,
Johannes Berg <johannes@...solutions.net>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as
__maybe_unused
On 2020-08-14 18:40, Lee Jones wrote:
> On Fri, 14 Aug 2020, Christian Lamparter wrote:
>
>> On 2020-08-14 13:39, Lee Jones wrote:
>>> 'ar9170_qmap' is used in some source files which include carl9170.h,
>>> but not all of them. Mark it as __maybe_unused to show that this is
>>> not only okay, it's expected.
>>>
>>> Fixes the following W=1 kernel build warning(s)
>>
>> Is this W=1 really a "must" requirement? I find it strange having
>
> Clean W=1 warnings is the dream, yes.
But is it a requirement?
>
> I would have thought most Maintainers would be on-board with this.
From what I know: It's no changes For changes' sake. Because otherwise
this would be pretty broken for maintainers. They could just write and
revert the same code over and over to prob up their LOC and commit
counter. Wouldn't you agree there?
>
> The ones I've worked with thus far have certainly been thankful. Many
> had this on their own TODO lists.
Question is, do you really want to be just the cleanup crew there? Since
semantic patches came along and a lot of this has been automated.
I'm of course after something else. Like: "Isn't there a better way than
manually slapping __maybe_unused there to suppress the warning and call
it a day?" If you already went down these avenues and can confirm that
there's no alternative than this, then "fine". But if there is a better
method of doing this, then "let's go with that!".
>
>> __maybe_unused in header files as this "suggests" that the
>> definition is redundant.
>
> Not true.
>
> If it were redundant then we would remove the line entirely.
So, why adding __maybe_unused then? I find it not very helpful to
tell the compiler to "shut up" when you want it's opinion...
This was the vibe I got from gcc's attribute unused help text.
Cheers,
Christian
>
>>> from drivers/net/wireless/ath/carl9170/carl9170.h:57,
>>> In file included from drivers/net/wireless/ath/carl9170/carl9170.h:57,
>>> drivers/net/wireless/ath/carl9170/carl9170.h:71:17: warning: ‘ar9170_qmap’ defined but not used [-Wunused-const-variable=]
>>>
>>> Cc: Christian Lamparter <chunkeey@...glemail.com>
>>> Cc: Kalle Valo <kvalo@...eaurora.org>
>>> Cc: "David S. Miller" <davem@...emloft.net>
>>> Cc: Jakub Kicinski <kuba@...nel.org>
>>> Cc: Johannes Berg <johannes@...solutions.net>
>>> Cc: linux-wireless@...r.kernel.org
>>> Cc: netdev@...r.kernel.org
>>> Signed-off-by: Lee Jones <lee.jones@...aro.org>
>>> ---
>>> drivers/net/wireless/ath/carl9170/carl9170.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
>>> index 237d0cda1bcb0..9d86253081bce 100644
>>> --- a/drivers/net/wireless/ath/carl9170/carl9170.h
>>> +++ b/drivers/net/wireless/ath/carl9170/carl9170.h
>>> @@ -68,7 +68,7 @@
>>> #define PAYLOAD_MAX (CARL9170_MAX_CMD_LEN / 4 - 1)
>>> -static const u8 ar9170_qmap[__AR9170_NUM_TXQ] = { 3, 2, 1, 0 };
>>> +static const u8 __maybe_unused ar9170_qmap[__AR9170_NUM_TXQ] = { 3, 2, 1, 0 };
>>> #define CARL9170_MAX_RX_BUFFER_SIZE 8192
>>>
>>
>
Powered by blists - more mailing lists