From: David Laight <david.laight.linux@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Abraham Samuel Adekunle <abrahamadekunle50@gmail.com>,
julia.lawall@inria.fr, outreachy@lists.linux.dev,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
dan.carpenter@linaro.org, andy@kernel.org
Subject: Re: [PATCH v4] staging: rtl8723bs: Use % 4096u instead of & 0xfff
Date: Mon, 7 Apr 2025 13:21:15 +0100 [thread overview]
Message-ID: <20250407132115.11ded3d9@pumpkin> (raw)
In-Reply-To: <2025040752-unrefined-labored-8c8c@gregkh>
On Mon, 7 Apr 2025 08:53:30 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 07, 2025 at 08:36:35AM +0200, Greg KH wrote:
> > On Mon, Apr 07, 2025 at 06:30:50AM +0000, Abraham Samuel Adekunle wrote:
> > > The sequence number is constrained to a range of [0, 4095], which
> > > is a total of 4096 values. The bitmask operation using `0xfff` is
> > > used to perform this wrap-around. While this is functionally correct,
> > > it obscures the intended semantic of a 4096-based wrap.
> > >
> > > Using a modulo operation with `4096u` makes the wrap-around logic
> >
> > <snip>
> >
> > > - psta->sta_xmitpriv.txseq_tid[pattrib->priority] &= 0xFFF;
> > > + psta->sta_xmitpriv.txseq_tid[pattrib->priority] &= 4096u;
> >
> > I do not see a modulo operation here, only another & operation.
> >
> > > pattrib->seqnum = psta->sta_xmitpriv.txseq_tid[pattrib->priority];
> > >
> > > SetSeqNum(hdr, pattrib->seqnum);
> > > @@ -963,11 +963,11 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr, struct pkt_attrib *pattr
> > > if (SN_LESS(pattrib->seqnum, tx_seq)) {
> > > pattrib->ampdu_en = false;/* AGG BK */
> > > } else if (SN_EQUAL(pattrib->seqnum, tx_seq)) {
> > > - psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (tx_seq+1)&0xfff;
> > > + psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (tx_seq+1)&4096u;
> >
> > This also looks odd, nothing is being "AND" here, it's an address value
> > being set (and an odd one at that, but that's another issue...)
>
> Sorry, no, I was wrong, it is being & here, but not %. My fault,
> the lack of spaces here threw me.
It is still wrong '& 0xfff' => '% 4096u'.
But it is all rather pointless especially if you can't test it.
Plausibly more useful would be to find ALL of the uses of 0xfff/4096 (I suspect
there is an array lurking somewhere) and change them to use the same constant.
But you need to be able to test the changes - or at least discover that
they make absolutely no difference to the generated object code.
David
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2025-04-07 12:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 6:30 [PATCH v4] staging: rtl8723bs: Use % 4096u instead of & 0xfff Abraham Samuel Adekunle
2025-04-07 6:36 ` Greg KH
2025-04-07 6:53 ` Greg KH
2025-04-07 7:51 ` Samuel Abraham
2025-04-07 12:21 ` David Laight [this message]
2025-04-07 12:28 ` Andy Shevchenko
2025-04-07 18:06 ` David Laight
2025-04-07 18:13 ` Andy Shevchenko
2025-04-07 13:35 ` Samuel Abraham
2025-04-07 7:20 ` Dan Carpenter
2025-04-07 8:07 ` Samuel Abraham
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=20250407132115.11ded3d9@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=abrahamadekunle50@gmail.com \
--cc=andy@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@inria.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=outreachy@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox