linux-kernel - Re: [PATCH] USB: atm: speedtch: do not use assignment in if condition

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024100400-whiff-unspoiled-0e1a@gregkh>
Date: Fri, 4 Oct 2024 08:20:04 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Manuel Quintero F <sakunix@...oo.com>
Cc: duncan.sands@...e.fr, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: atm: speedtch: do not use assignment in if condition

On Thu, Oct 03, 2024 at 08:05:12PM -0700, Manuel Quintero F wrote:
> Fix checkpatch error "do not use assignment in if condition"
> 
> Signed-off-by: Manuel Quintero F <sakunix@...oo.com>
> Signed-off-by: Manuel Quintero F <sakunix@...oo.com>

Why twice?

> ---
>  drivers/usb/atm/speedtch.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/atm/speedtch.c b/drivers/usb/atm/speedtch.c
> index 973548b5c15c..dfd362abf602 100644
> --- a/drivers/usb/atm/speedtch.c
> +++ b/drivers/usb/atm/speedtch.c
> @@ -324,7 +324,9 @@ static int speedtch_upload_firmware(struct speedtch_instance_data *instance,
>  	   because we're in our own kernel thread anyway. */
>  	msleep_interruptible(1000);
>  
> -	if ((ret = usb_set_interface(usb_dev, INTERFACE_DATA, instance->params.altsetting)) < 0) {
> +	ret = usb_set_interface(usb_dev, INTERFACE_DATA, instance->params.altsetting
> +
> +	if (ret < 0) {

Why the extra blank line?

When learning to do kernel changes, I recommend doing so in
drivers/staging/ first, as that is what it is there for.  Only after
getting experience would I recommend doing this in other areas of the
kernel, and even then, only do checkpatch cleanups for code that you can
test, or that the subsystem maintainer has explicitly asked for.

good luck!

greg k-h