Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210511180259.159598-1-johannes@sipsolutions.net> <20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid>
In-Reply-To: <20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid>
From:   Brian Norris <briannorris@chromium.org>
Date:   Wed, 12 May 2021 11:35:23 -0700
Message-ID: <CA+ASDXPwAWEEvWBdiLpMrm-PTcSH7QQHwx_T5nxN+faQt=Wi_g@mail.gmail.com>
Subject: Re: [PATCH 14/18] ath10k: drop MPDU which has discard flag set by
 firmware for SDIO
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>,
        Wen Gong <wgong@codeaurora.org>,
        stable <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, May 11, 2021 at 11:03 AM Johannes Berg
<johannes@sipsolutions.net> wrote:
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -2312,6 +2312,11 @@ static bool ath10k_htt_rx_proc_rx_ind_hl(struct ath10k_htt *htt,
>         fw_desc = &rx->fw_desc;
>         rx_desc_len = fw_desc->len;
>
> +       if (fw_desc->u.bits.discard) {
> +               ath10k_dbg(ar, ATH10K_DBG_HTT, "htt discard mpdu\n");
> +               goto err;
> +       }
> +
>         /* I have not yet seen any case where num_mpdu_ranges > 1.
>          * qcacld does not seem handle that case either, so we introduce the
>          * same limitiation here as well.
> diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
> index f2b6bf8f0d60..705b6295e466 100644
> --- a/drivers/net/wireless/ath/ath10k/rx_desc.h
> +++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
> @@ -1282,7 +1282,19 @@ struct fw_rx_desc_base {
>  #define FW_RX_DESC_UDP              (1 << 6)
>
>  struct fw_rx_desc_hl {
> -       u8 info0;
> +       union {
> +               struct {
> +               u8 discard:1,
> +                  forward:1,
> +                  any_err:1,
> +                  dup_err:1,
> +                  reserved:1,
> +                  inspect:1,
> +                  extension:2;
> +               } bits;
> +               u8 info0;
> +       } u;

Am I misled here, or are you introducing endianness issues here? From C99:

"The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined."

Now, we're pretty well attuned to two implementations (big and little
endian), and this should work for the most common one (little endian),
but it's not wise to assume everyone is little endian.

Brian