From: Greg KH <gregkh@linuxfoundation.org>
To: Erick Karanja <karanja99erick@gmail.com>
Cc: Julia Lawall <julia.lawall@inria.fr>,
outreachy@lists.linux.dev, philipp.g.hortmann@gmail.com,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] staging: rtl8723bs: Modify struct rx_pkt_attrib attribute bdecrypted
Date: Fri, 4 Apr 2025 09:00:57 +0100 [thread overview]
Message-ID: <2025040440-provolone-uncertain-77a0@gregkh> (raw)
In-Reply-To: <cebaec5995fd21c429160b30795e03c2caa29cef.camel@gmail.com>
On Fri, Apr 04, 2025 at 09:58:23AM +0300, Erick Karanja wrote:
> On Wed, 2025-04-02 at 21:41 +0100, Greg KH wrote:
> > On Wed, Apr 02, 2025 at 10:34:22PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Wed, 2 Apr 2025, Greg KH wrote:
> > >
> > > > On Wed, Apr 02, 2025 at 08:16:42PM +0300, Erick Karanja wrote:
> > > > > Standardize boolean representation by ensuring consistency,
> > > > > replace instances of 1/0 with true/false where boolean logic is
> > > > > implied,
> > > > > as some definitions already use true/false.
> > > > > This improves code clarity and aligns with the kernel’s bool
> > > > > type usage.
> > > > >
> > > > > Signed-off-by: Erick Karanja <karanja99erick@gmail.com>
> > > > > ---
> > > > > drivers/staging/rtl8723bs/core/rtw_recv.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
> > > > > b/drivers/staging/rtl8723bs/core/rtw_recv.c
> > > > > index a389ba5ecc6f..fd04dbacb50f 100644
> > > > > --- a/drivers/staging/rtl8723bs/core/rtw_recv.c
> > > > > +++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
> > > > > @@ -1358,7 +1358,7 @@ static signed int
> > > > > validate_80211w_mgmt(struct adapter *adapter, union recv_frame
> > > > > u8 *mgmt_DATA;
> > > > > u32 data_len = 0;
> > > > >
> > > > > - pattrib->bdecrypted = 0;
> > > > > + pattrib->bdecrypted = false;
> > > >
> > > > but bdecrypted is a u8, not a boolean type. So setting it to
> > > > "false"
> > > > does not seem correct here, right?
> > >
> > > Is false different than 0?
> >
> > Does C guarantee that? I can never remember. I don't think it
> > guarantees that a 'bool' will only be 8 bits, or am I mistaken there
> > too?
> >
> > > Elsewhere there is an assignment to true.
> >
> > Was that in the original driver?
> >
> > If this doesn't come from the hardware, then it's fine to make the
> > change. If it does, it needs to be verified that the layout and bit
> > values are identical.
> >
> > thanks,
> I have compared the generated assembly code
> before and after and I have observed the only
> change is the comment below.
> -# drivers/staging/rtl8723bs/core/rtw_recv.c:1361:
> pattrib->bdecrypted = 0;
> +# drivers/staging/rtl8723bs/core/rtw_recv.c:1361:
> pattrib->bdecrypted = false;
> There is no change in the assembly instructions.
Showing the assembly is key, not just a comment :)
next prev parent reply other threads:[~2025-04-04 8:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 17:16 [PATCH v2 0/3] staging: rtl8723bs: Code cleanup patches Erick Karanja
2025-04-02 17:16 ` [PATCH v2 1/3] staging: rtl8723bs: Modify struct rx_pkt_attrib attribute bdecrypted Erick Karanja
2025-04-02 19:21 ` Greg KH
2025-04-02 20:34 ` Julia Lawall
2025-04-02 20:41 ` Greg KH
2025-04-02 21:02 ` Julia Lawall
2025-04-03 12:13 ` Dan Carpenter
2025-04-04 6:58 ` Erick Karanja
2025-04-04 8:00 ` Greg KH [this message]
2025-04-04 8:21 ` Erick Karanja
2025-04-02 17:16 ` [PATCH v2 2/3] staging: rtl8723bs: Modify struct sta_info attribute qos_option Erick Karanja
2025-04-02 17:16 ` [PATCH v2 3/3] staging: rtl8723bs: Modify struct sta_info attribute qos_option and ieee8021x_blocked Erick Karanja
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=2025040440-provolone-uncertain-77a0@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=julia.lawall@inria.fr \
--cc=karanja99erick@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=outreachy@lists.linux.dev \
--cc=philipp.g.hortmann@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.