[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025051046-ipad-overdrawn-8890@gregkh>
Date: Sat, 10 May 2025 18:45:53 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Thomas Andreatta <thomasandreatta2000@...il.com>
Cc: dpenkler@...il.com, linux-kernel@...r.kernel.org,
linux-staging@...ts.linux.dev,
Thomas Andreatta <thomas.andreatta2000@...il.com>
Subject: Re: [PATCH 2/2] Staging: common: gpib_os:
`request_system_control_ioctl` return value
On Sat, May 10, 2025 at 05:38:00PM +0200, Thomas Andreatta wrote:
> `request_system_control_ioctl` now returns the value returned from the
> function `ibrsc`, now int.
>
> Signed-off-by: Thomas Andreatta <thomas.andreatta2000@...il.com>
> ---
> drivers/staging/gpib/common/gpib_os.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/gpib/common/gpib_os.c b/drivers/staging/gpib/common/gpib_os.c
> index 8456b97290b8..dddf7a70084d 100644
> --- a/drivers/staging/gpib/common/gpib_os.c
> +++ b/drivers/staging/gpib/common/gpib_os.c
> @@ -1970,9 +1970,9 @@ static int request_system_control_ioctl(struct gpib_board *board, unsigned long
> if (retval)
> return -EFAULT;
>
> - ibrsc(board, request_control);
> + retval = ibrsc(board, request_control);
>
> - return 0;
> + return retval;
Why not:
return ibrsc(board, request_control);
?
But again, as this can not fail, why is this needed?
Start way back at the "ends" of the call chain. If they can fail, then
start propagating the error up all the way to here. As it is, your
patch series really didn't do anything that I can tell, sorry.
greg k-h
Powered by blists - more mailing lists