Re: [v3 1/1] staging: rtl8723bs: Prevent duplicate NULL tests on a value

Andy Shevchenko <[email protected]> Fri, 4 Apr 2025 13:53:16 +0300
Newsgroups dev.linux.lists.outreachy,dev.linux.lists.linux-staging,org.kernel.vger.linux-kernel
Message-ID <CAHp75VfDOaK0EXNc79cM1mNWapm7fhshU550q1mAKQdtRbUNwg@mail.gmail.com>
On Fri, Apr 4, 2025 at 12:06 PM Dan Carpenter <[email protected]> wrote:
> On Fri, Apr 04, 2025 at 10:53:22AM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 4, 2025 at 3:03 AM Abraham Samuel Adekunle
> > <[email protected]> wrote:

...

> > > +                       psta->sta_xmitpriv.txseq_tid[pattrib->priority] &= 0xFFF;
> >
> > > +                                       psta->BA_starting_seqctrl[pattrib->priority & 0x0f] =
> > > +                                               (tx_seq + 1) & 0xfff;
> >
> > > +                                       psta->BA_starting_seqctrl[pattrib->priority & 0x0f] =
> > > +                                               (pattrib->seqnum + 1) % 4096;
> >
> > Logically it's obvious that you need to align all cases to have
> > consistent approach.
> > Besides that the commit message should mention this change. Something like this
> > "While at it, convert '& 0xfff' cases to use modulo operator and
> > decimal number to make the upper limit visible and clear what the
> > semantic of it is."
>
> No, I'm sorry but that's really against the rules in drivers/staging.
> Don't mix unrelated changes into a patch.  It needs to be done as a
> separate patch if we're going to do that.
>
> To be honest, I don't even want people fixing line length issues or
> adding spaces.  I would have accepted small white space changes but I
> prefered the v2 version of this patch.  Once you start changing
> "& 0xfff" to "% 4096" that's not white space and it must be done
> in a separate patch. I use a script to review white space patches
> because I'm always nervous someone will slip something malicious
> into 100+ lines of reformated code.  It's really fast to review
> patches with my script but once people start mixing things in then
> it's a headache for me.

Separate patch is even better, indeed.

> Also if the change accidentally introduces a bug, I want it to be a
> one liner change and not something hidden inside a giant reformat.

The noisy {] have no point to be left. Now I'm curious, what do you
propose here?

-- 
With Best Regards,
Andy Shevchenko