linux-kernel - Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction

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: <20171106081120.GC9728@mail.corp.redhat.com>
Date:   Mon, 6 Nov 2017 09:11:20 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Sébastien Szymanski 
        <sebastien.szymanski@...adeus.com>
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jiri Kosina <jikos@...nel.org>,
        Julien Boibessot <julien.boibessot@...adeus.com>
Subject: Re: [PATCH 3/3] HID: cp2112: fix broken gpio_direction_input callback

On Nov 02 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@...adeus.com>
> ---
>  drivers/hid/hid-cp2112.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..f7754a6 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -205,12 +205,13 @@ static int cp2112_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
>  	ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>  				 CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>  				 HID_REQ_SET_REPORT);
> -	if (ret < 0) {
> +	if (ret != CP2112_GPIO_CONFIG_LENGTH) {

Ack for this.

>  		hid_err(hdev, "error setting GPIO config: %d\n", ret);
>  		goto exit;
>  	}
>  
> -	ret = 0;
> +	mutex_unlock(&dev->lock);
> +	return 0;

Wouldn't it be better to just turn
- return ret < 0 ? ret : -EIO;
into
+ return ret <= 0 ? ret : -EIO;
at the end of the function?

I'd rather keep the same exit path in both cases, error or success.

Cheers,
Benjamin


>  
>  exit:
>  	mutex_unlock(&dev->lock);
> -- 
> 2.7.3
>