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]
Date:	Fri, 7 Mar 2014 10:47:47 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	David Barksdale <dbarksdale@...ogix.com>,
	Antonio Ospite <ao2@....it>,
	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] HID: cp2112: remove various hid_out_raw_report calls

Hi

On Wed, Mar 5, 2014 at 10:18 PM, Benjamin Tissoires
<benjamin.tissoires@...hat.com> wrote:
> hid_out_raw_report is going to be obsoleted as it is not part of the
> unified HID low level transport documentation
> (Documentation/hid/hid-transport.txt)
>
>   hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT);
> is strictly equivalent to:
>   hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
>                 HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

This time you might be right that feature-reports always put the
report-id into the first byte, but I'd still prefer if we avoid using
this. Besides, the code is much nicer imho if we pass the ID directly,
see below..

>
> So use the new api.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> ---
>
> no changes since v1
>
>  drivers/hid/hid-cp2112.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 1025982..860db694 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -185,8 +185,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
>         buf[1] &= ~(1 << offset);
>         buf[2] = gpio_push_pull;
>
> -       ret = hdev->hid_output_raw_report(hdev, buf, sizeof(buf),
> -                                         HID_FEATURE_REPORT);
> +       ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
> +                                HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

buf[0] => CP2112_GPIO_CONFIG

>         if (ret < 0) {
>                 hid_err(hdev, "error setting GPIO config: %d\n", ret);
>                 return ret;
> @@ -207,8 +207,8 @@ static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
>         buf[1] = value ? 0xff : 0;
>         buf[2] = 1 << offset;
>
> -       ret = hdev->hid_output_raw_report(hdev, buf, sizeof(buf),
> -                                         HID_FEATURE_REPORT);
> +       ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
> +                                HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

Here buf[0] seems fine as it is set explicitly just 3 lines above to
CP2112_GPIO_SET.

>         if (ret < 0)
>                 hid_err(hdev, "error setting GPIO values: %d\n", ret);
>  }
> @@ -253,8 +253,8 @@ static int cp2112_gpio_direction_output(struct gpio_chip *chip,
>         buf[1] |= 1 << offset;
>         buf[2] = gpio_push_pull;
>
> -       ret = hdev->hid_output_raw_report(hdev, buf, sizeof(buf),
> -                                         HID_FEATURE_REPORT);
> +       ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
> +                                HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

Here an explicit CP2112_GPIO_CONFIG seems nicer, imho.

Thanks
David

>         if (ret < 0) {
>                 hid_err(hdev, "error setting GPIO config: %d\n", ret);
>                 return ret;
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ