On Tue, Nov 05, 2019 at 09:19:20AM -0800, Ben Greear wrote:
> Thanks for adding the counter. Since it us u32, I doubt you need the spin
> lock
> below?
Ok, I can remove the spin-lock.
Just for clarification though, if I recall correctly then an increment operator
is not guaranteed to work atomically. But you think it's unlikely
to race with a concurrent ++ and therefore it's fine for just a debug counter?
(and if it were racing, it'd just be a missed +1)
Or is there another mechanism that avoids concurrency in the
ath10k RX path?
>
> --Ben
>
> > + if (!(ar->filter_flags & FIF_FCSFAIL) &&
> > + status->flag & RX_FLAG_FAILED_FCS_CRC) {
> > + spin_lock_bh(&ar->data_lock);
> > + ar->stats.rx_crc_err_drop++;
> > + spin_unlock_bh(&ar->data_lock);
> > +
> > + dev_kfree_skb_any(skb);
> > + return;
> > + }
> > +
> > ath10k_dbg(ar, ATH10K_DBG_DATA,
> > "rx skb %pK len %u peer %pM %s %s sn %u %s%s%s%s%s%s
> > %srate_idx %u vht_nss %u freq %u band %u flag 0x%x fcs-err %i mic-err %i
> > amsdu-more %i\n",
> > skb,
> >
>
>
> --
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
