All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Marco Cesati <marcocesati@gmail.com>,
	 Ross Schmidt <ross.schm.dev@gmail.com>,
	fabioaiuto83@gmail.com,  linux-staging@lists.linux.dev,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH -next 5/6] staging: rtl8723bs: mark some variables as __maybe_unused
Date: Sat, 27 Mar 2021 08:44:29 -0600	[thread overview]
Message-ID: <CAOc6etZaqnDXU4dgBmx_qd8iwpmEjDhs=7JnLuCUFxs65=TRHQ@mail.gmail.com> (raw)
In-Reply-To: <20210327081758.GJ1667@kadam>

On Sat, Mar 27, 2021 at 2:18 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> This is just papering over badness.  Leave the warnings as is so someone
> will notice it and fix it properly in the future.
>

Interesting.... I wonder what the right way to handle this would be
then. Is it a more appropriate solution defining the debug macros
_only_ if we are debugging and then also use #ifs in code to define
the variables and handle them?

So, currently, in rtw_debug.h, we have this (lines ~134-140):

#define RT_TRACE(_Comp, _Level, Fmt) do {} while (0)
#define RT_PRINT_DATA(_Comp, _Level, _TitleString, _HexData,
_HexDataLen) do {} while (0)

#define DBG_871X(x, ...) do {} while (0)
#define MSG_8192C(x, ...) do {} while (0)
#define DBG_8192C(x, ...) do {} while (0)
#define DBG_871X_LEVEL(x, ...) do {} while (0)


And then, a bit further down the road in the same file:
#ifdef DEBUG
#if defined(_dbgdump)
    #undef DBG_871X
    #define DBG_871X(...)     do {\
        _dbgdump(DRIVER_PREFIX __VA_ARGS__);\
    } while (0)

    #undef MSG_8192C
    #define MSG_8192C(...)     do {\
        _dbgdump(DRIVER_PREFIX __VA_ARGS__);\
    } while (0)

    #undef DBG_8192C
    #define DBG_8192C(...)     do {\
        _dbgdump(DRIVER_PREFIX __VA_ARGS__);\
    } while (0)
#endif /* defined(_dbgdump) */
#endif /* DEBUG */

If we remove the definition of the macros that were around line 134,
we need to make sure that those macros are not used in code if the
same conditions are not met... so, it might mean that we control if we
define the variables we are using... one of the examples from this
patch:


    unsigned char *p, *pos, *wpa_ie;
#ifdef DEBUG && defined(_dbgdump)
    unsigned char * reassoc;
#endif
    unsigned char WMM_IE[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
.
.
.
    if (frame_type == WIFI_ASSOCREQ) {
#ifdef DEBUG && defined(_dbgdump)
        reassoc = 0;
#endif
        ie_offset = _ASOCREQ_IE_OFFSET_;
    } else { /*  WIFI_REASSOCREQ */
#ifdef DEBUG && defined(_dbgdump)
        reassoc = 1;
#endif
        ie_offset = _REASOCREQ_IE_OFFSET_;
    }

    if (pkt_len < sizeof(struct ieee80211_hdr_3addr) + ie_offset) {
#ifdef DEBUG && defined(_dbgdump)
        DBG_871X("handle_assoc(reassoc =%d) - too short payload (len =%lu)"
             "\n", reassoc, (unsigned long)pkt_len);
#endif
        return _FAIL;
    }

> regards,
> dan carpenter
>

  reply	other threads:[~2021-03-27 14:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27  0:17 [PATCH -next 1/6] staging: rtl8723bs: ieee80211: remove unused variable Edmundo Carmona Antoranz
2021-03-27  0:17 ` [PATCH -next 2/6] staging: rtl8723bs: mlme: remove unused variables Edmundo Carmona Antoranz
2021-03-28 12:33   ` Greg KH
2021-03-27  0:17 ` [PATCH -next 3/6] staging: rtl8723bs: hal: remove unused variable in HalBtc8723b1Ant.c Edmundo Carmona Antoranz
2021-03-27  0:17 ` [PATCH -next 4/6] staging: rtl8723bs: sdio_ops: removing unused variable Edmundo Carmona Antoranz
2021-03-27  0:17 ` [PATCH -next 5/6] staging: rtl8723bs: mark some variables as __maybe_unused Edmundo Carmona Antoranz
2021-03-27  8:17   ` Dan Carpenter
2021-03-27 14:44     ` Edmundo Carmona Antoranz [this message]
2021-03-27 14:44       ` Edmundo Carmona Antoranz
2021-03-27 16:27       ` Dan Carpenter
2021-03-27  0:17 ` [PATCH -next 6/6] staging: rtl8723bs: sta_mgt: return _FAIL if there is an error Edmundo Carmona Antoranz
2021-03-27  0:23   ` Edmundo Carmona Antoranz
2021-03-27  0:23     ` Edmundo Carmona Antoranz
2021-03-27  8:21   ` Dan Carpenter
2021-03-27  8:13 ` [PATCH -next 1/6] staging: rtl8723bs: ieee80211: remove unused variable Dan Carpenter
2021-03-28 12:32 ` Greg KH

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='CAOc6etZaqnDXU4dgBmx_qd8iwpmEjDhs=7JnLuCUFxs65=TRHQ@mail.gmail.com' \
    --to=eantoranz@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=fabioaiuto83@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=marcocesati@gmail.com \
    --cc=ross.schm.dev@gmail.com \
    /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.