Netdev List
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Lucas Poupeau <lucasp.linux@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] llc: fix coding style and memory barrier documentation
Date: Tue, 5 May 2026 22:19:20 +0200	[thread overview]
Message-ID: <c731ce37-e5d8-4259-8b6c-46b01c257fbd@lunn.ch> (raw)
In-Reply-To: <20260505192549.74382-1-lucasp.linux@gmail.com>

On Tue, May 05, 2026 at 09:25:49PM +0200, Lucas Poupeau wrote:
> Fix multiple style issues reported by checkpatch.pl to improve code
> maintainability and compliance with kernel standards.
> 
> Changes included:
> - Add mandatory explanatory comments to memory barriers, specifying
>   the reasoning and pairing context.
> - Insert missing blank lines after variable declarations to improve
>   readability.
> - Relocate EXPORT_SYMBOL macros to immediately follow their respective
>   function definitions as per the modern kernel coding style.
> 
> Note: Some indentation warnings from checkpatch.pl persist in this
> commit. Despite several attempts to align them, the tool remains
> capricious regarding these specific blocks, and further manual
> refinement proved counterproductive.
> 
> Reported-by: checkpatch.pl
> Signed-off-by: Lucas Poupeau <lucasp.linux@gmail.com>

Please take a read of

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

The Subject line needs to indicate what tree it is for.

Please also break this patch up. One patch per type of fix. You are
aiming for patches which are obviously correct. Such patches are
generally small, and have good commit messages.

> -#if 0
> -#define dprintk(args...) printk(KERN_DEBUG args)
> -#else
> -#define dprintk(args...)
> -#endif

It is not obvious why this is correct. Is dprintk() not actually used
in this file? That would be something you would say in the commit
message.

> +    /*
> +     * This barrier ensures that any previous memory operations
> +     * are visible before the handler is executed.
> +     * Pairs with the smp_wmb() in [indiquez ici la fonction ou le fichier].
> +     */

Please do specify the function here. Otherwise the comment is useless.

	Andrew

  reply	other threads:[~2026-05-05 20:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05 19:25 [PATCH] llc: fix coding style and memory barrier documentation Lucas Poupeau
2026-05-05 20:19 ` Andrew Lunn [this message]
2026-05-05 23:16 ` Jakub Kicinski
2026-05-10  9:01 ` kernel test robot
2026-05-10 15:47   ` Lucas
2026-05-10 23:57 ` kernel test robot

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=c731ce37-e5d8-4259-8b6c-46b01c257fbd@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucasp.linux@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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