All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Lamparter <chunkeey@gmail.com>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] carl9170: fix enum compare splat
Date: Mon, 10 Jun 2019 13:45:31 +0200	[thread overview]
Message-ID: <1601416.I41mb68Wgz@debian64> (raw)
In-Reply-To: <87pnnlncll.fsf@codeaurora.org>

On Monday, June 10, 2019 9:06:30 AM CEST Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> 
> > This patch fixes a noisy warning triggered by -Wenum-compare
> >
> > |main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
> > |	and ‘enum ar9170_txq’ [-Wenum-compare]
> > |  BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> > |                               ^
> > | [...]
> >
> > This is a little bit unfortunate, since the number of queues
> > (hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
> > (much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
> > less defined by the AR9170 hardware.
> 
> Is the warning enabled by default? TBH I'm not seeing how useful this
> warning is for kernel development.

It is included in the "-Wall" (which is coming from "KBUILD_CFLAGS" 
in the main Makefile).

I tried debian's gcc starting from 4.6 to the lastest 8.3. They all
complain about it in various degrees.

https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html#Warning-Options

> > --- a/drivers/net/wireless/ath/carl9170/main.c
> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > @@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> >  	int ret;
> >  
> >  	BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
> > -	BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> > +	BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
> 
> IMHO this just makes the code worse. Does it make sense to workaround
> (stupid) compiler warnings like this?
True. What's worse: This isn't really code. The BUILD_BUG_ON Macro is there
to guard but it's getting compiled away. I could also just drop it.





  reply	other threads:[~2019-06-10 11:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08 14:49 [PATCH] carl9170: fix enum compare splat Christian Lamparter
2019-06-08 14:49 ` [RFC PATCH v2] ath9k: add loader for AR92XX (and older) pci(e) Christian Lamparter
2019-06-09 13:28   ` Julian Calaby
2019-06-08 14:49 ` [PATCH v2] carl9170: fix misuse of device driver API Christian Lamparter
2019-06-10 14:12   ` Alan Stern
2019-06-27 17:47   ` Kalle Valo
2019-06-10  7:06 ` [PATCH] carl9170: fix enum compare splat Kalle Valo
2019-06-10 11:45   ` Christian Lamparter [this message]
2019-06-18 12:11     ` Kalle Valo
2019-06-20 14:41       ` Christian Lamparter
2019-06-26 14:17         ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1601416.I41mb68Wgz@debian64 \
    --to=chunkeey@gmail.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.