mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@inria.fr>
To: Erick Karanja <karanja99erick@gmail.com>
Cc: gregkh@linuxfoundation.org, outreachy@lists.linux.dev,
	 philipp.g.hortmann@gmail.com, linux-staging@lists.linux.dev,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] staging: rtl8723bs: Improve code readability
Date: Wed, 9 Apr 2025 11:39:13 -0400 (EDT)	[thread overview]
Message-ID: <a97e7851-31f7-e493-fe1a-749f27c879f0@inria.fr> (raw)
In-Reply-To: <4cf642ebb8d0859676230bae06a4914a57428ec3.camel@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

> > > @@ -729,10 +721,9 @@ static void hal_ReadEFuse_WiFi(
> > >  		}
> > >
> > >  		if (offset < EFUSE_MAX_SECTION_8723B) {
> > > -			u16 addr;
> > > +			u16 addr = offset * PGPKT_DATA_SIZE;
> > >  			/*  Get word enable value from PG header
> > > */
> > >
> > > -			addr = offset * PGPKT_DATA_SIZE;
> >
> > I'm not sure about this one, due to the comment.
> Hello Julia, I have observed in some scenarios where the semantic patch
> deletes the comments that exist between the declaration and
> initialization which I think it's not okay and in this scenario where
> the comments are left dangling such as this. How do I go about this
> instances.
> Thank you.

Making the right choice depends on the semantics of the comment, which is
out of the scope of Coccinelle.  Generally, if a complete block of code is
dropped, any comments within it are dropped as well.  Here the comment is
kept, which seems reasonable.  The issue is that you may have moved code
that is relevant to the comment up above the comment.  Ultimately, you have
to decide what to do and what not to do.  If you let Coccinelle make a
patch, and then apply the patch, in the meantime you can just remove the
parts of the patch you don't like.  If you make the changes in place, you
can use git add -p to add the changes you like, and not add the others, and
then use git checkout to remove the changes you don't want to do.  I would
take the former approach, but some people may take the latter.

julia

  reply	other threads:[~2025-04-09 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 10:04 [PATCH v2 0/2] Improve code readability in rtl8723bs module Erick Karanja
2025-04-09 10:04 ` [PATCH v2 1/2] staging: rtl8723bs: Improve code readability Erick Karanja
2025-04-09 11:04   ` Julia Lawall
2025-04-09 11:11     ` Dan Carpenter
2025-04-09 11:22       ` Erick Karanja
2025-04-09 11:32     ` Erick Karanja
2025-04-09 15:39       ` Julia Lawall [this message]
2025-04-09 10:04 ` [PATCH v2 2/2] staging: rtl8723bs: Initializing variables at declaration Erick Karanja
2025-04-09 15:41   ` Julia Lawall
2025-04-10  5:39     ` 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=a97e7851-31f7-e493-fe1a-749f27c879f0@inria.fr \
    --to=julia.lawall@inria.fr \
    --cc=gregkh@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®