linux-kernel - Re: [PATCH] staging: rtl8723bs: remove if (true) statement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210519135020.wm3qi4gv475hg54b@bryanbrattlof.com>
Date:   Wed, 19 May 2021 13:51:12 +0000
From:   Bryan Brattlof <hello@...anbrattlof.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>,
        Fabio Aiuto <fabioaiuto83@...il.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Larry Finger <Larry.Finger@...inger.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8723bs: remove if (true) statement

On Wed, May 19, 2021 at 04:31:08PM +0300, Dan Carpenter wrote:
> On Wed, May 19, 2021 at 04:25:29PM +0300, Dan Carpenter wrote:
> > On Wed, May 19, 2021 at 02:44:38PM +0200, Fabio Aiuto wrote:
> > > Hi Bryan,
> > >
> > > On Tue, May 18, 2021 at 02:45:19PM +0000, Bryan Brattlof wrote:
> > > > 'if (true) { ... }' will always evaluate to true. Remove it and
> > > > save a few tabs for somewhere else.
> > > >
> > > > Signed-off-by: Bryan Brattlof <hello@...anbrattlof.com>
> > > > ---
> > > >  drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
> > > >  1 file changed, 78 insertions(+), 81 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > index 9df4476b2e2d..98b1bec67999 100644
> > > > --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > @@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
> > > >
> > >
> > > I was wondering why are you using the first patch of a nine patch
> > > series as a 'cover letter' of an eight patch patchset.
> > >
> > > In other words, why putting the In-Reply-To field of all patches subsequent
> > > to the first one ponting to the first patch itself as a cover letter,
> > > is it a recommened practice?
> >
> > It's fine.  It doesn't matter.  It's not recommended.  I do it normally
> > if I have to send patches in certain order.  I never write cover letters
> > because my patches are all independent bug fixes and not new features.
>
> Wait, this was just a mistake I think.  It's not a cover letter.  It's
> not part of the eight patch series but it probably was intended to be as
> you suggest.
>
> The patches are basically okay.  Greg applies patches in the order that
> he recieves them so it should all apply fine.  And if it doesn't Greg
> will just ask for a resend.  No big deal.
>

Yep this is due to my inexperience with git over email :)

I wanted to send the patches in order to avoid conflicts when applying
because they deal with the same area of the file, but didn't feel they
deserved a cover letter to remove some unused definitions.

I was using 'git-series' to manage the patch set which generated an
empty cover letter that I didn't send out. I should have known that
In-Reply-To would have been set for all the remaining emails.

Going forward I'll probably just stick with 'git-send-email' and write a
proper cover letter, especially while I'm still getting used to sending
patches over email. :)

--
~Bryan

> regards,
> dan carpenter
>