linux-kernel - Re: [PATCH] usb: storage: Checkpatch fix done and Clean up coding style

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: <2025072526-guru-reacquire-408d@gregkh>
Date: Fri, 25 Jul 2025 15:58:31 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: "Darshan R." <rathod.darshan.0896@...il.com>
Cc: stern@...land.harvard.edu, linux-usb@...r.kernel.org,
	usb-storage@...ts.one-eyed-alien.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: storage: Checkpatch fix done and Clean up coding
 style

On Fri, Jul 25, 2025 at 01:55:33PM +0000, Darshan R. wrote:
> The shuttle_usbat.c driver has several coding style inconsistencies that deviate from the Linux kernel standard.
> This makes the code harder to read and maintain.
> 
> This patch is a pure cleanup effort to address these style issues.
> The changes include:
> 
> - Adding proper spacing around operators (=, *, +, !=, etc.).
> - Adjusting pointer declarations to the standard type *var style.
> - Fixing spacing in pointer casts, e.g., (struct usbat_info *).
> - Removing the redundant = 0 initializer for the static transferred
>   variable, as it's guaranteed to be zero-initialized.
> - Tidying up miscellaneous whitespace and removing extra blank lines.
> 
> These changes were guided by checkpatch.pl.
> No functional changes have been made.
> 
> Signed-off-by: Darshan R. <rathod.darshan.0896@...il.com>
> ---
>  drivers/usb/storage/shuttle_usbat.c | 252 +++++++++++++---------------
>  1 file changed, 120 insertions(+), 132 deletions(-)

Please do not run checkpatch.pl on existing subsystems and old kernel
code and then send a huge patch to "fix them all!".  That's not going to
work well for many kernel subsystems as they do not welcome the constant
churn that would cause.

If you are interested in doing this type of work, do so in the
drivers/staging/ subsystem, which welcomes it.

thanks,

greg k-h