linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>, Jiri Kosina <jikos@kernel.org>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH 1/4] HID: core: Add hid_hw_may_wakeup() function
Date: Thu, 24 Jun 2021 14:16:49 +0200	[thread overview]
Message-ID: <1837eed3-8f99-d9be-0d35-d4b21c0e6f4e@redhat.com> (raw)
In-Reply-To: <20210529151424.12212-2-hdegoede@redhat.com>

Hi Hans,

On 5/29/21 5:14 PM, Hans de Goede wrote:
> Add a hid_hw_may_wakeup() function, which is the equivalent of
> hid_hw_may_wakeup() for hid devices.

nitpick here, but I think the second `hid_hw_may_wakeup()` is probably 
wrong.

> 
> In most cases this just returns device_may_wakeup(hdev->dev.parent),
> but for some ll-drivers this is not correct. E.g. usb_hid_driver
> instantiated hid devices have their parent set to the usb-interface
> to which the usb_hid_driver is bound, but the power/wakeup* sysfs
> attributes are part of the usb-device, which is the usb-interface's
> parent.

I never spent enough time in suspend/resume. But isn't the big consumer 
of wakeup sources be USB? Is there a point having a generic return path 
when returning false earlier will keep the same code path for all other 
transport layers (I2C and bluetooth)?

Other than those two questions, I like the series and the approach to 
not break the existing:

For the series:
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Cheers,
Benjamin

> 
> For these special cases a new may_wakeup callback is added to
> hid_ll_driver, so that ll-drivers can override the default behavior.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>   include/linux/hid.h | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)
> 
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 271021e20a3f..4d2b2212f079 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -800,6 +800,7 @@ struct hid_driver {
>    * @raw_request: send raw report request to device (e.g. feature report)
>    * @output_report: send output report to device
>    * @idle: send idle request to device
> + * @may_wakeup: return if device may act as a wakeup source during system-suspend
>    */
>   struct hid_ll_driver {
>   	int (*start)(struct hid_device *hdev);
> @@ -824,6 +825,7 @@ struct hid_ll_driver {
>   	int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len);
>   
>   	int (*idle)(struct hid_device *hdev, int report, int idle, int reqtype);
> +	bool (*may_wakeup)(struct hid_device *hdev);
>   };
>   
>   extern struct hid_ll_driver i2c_hid_ll_driver;
> @@ -1149,6 +1151,22 @@ static inline int hid_hw_idle(struct hid_device *hdev, int report, int idle,
>   	return 0;
>   }
>   
> +/**
> + * hid_may_wakeup - return if the hid device may act as a wakeup source during system-suspend
> + *
> + * @hdev: hid device
> + */
> +static inline bool hid_hw_may_wakeup(struct hid_device *hdev)
> +{
> +	if (hdev->ll_driver->may_wakeup)
> +		return hdev->ll_driver->may_wakeup(hdev);
> +
> +	if (hdev->dev.parent)
> +		return device_may_wakeup(hdev->dev.parent);
> +
> +	return false;
> +}
> +
>   /**
>    * hid_hw_wait - wait for buffered io to complete
>    *
> 


  reply	other threads:[~2021-06-24 12:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29 15:14 [PATCH 0/4] HID: multitouch: Disable event reporting on suspend when the device is not a wakeup-source Hans de Goede
2021-05-29 15:14 ` [PATCH 1/4] HID: core: Add hid_hw_may_wakeup() function Hans de Goede
2021-06-24 12:16   ` Benjamin Tissoires [this message]
2021-06-24 15:59     ` Hans de Goede
2021-06-25 12:03       ` Jiri Kosina
2021-05-29 15:14 ` [PATCH 2/4] HID: usbhid: Implement may_wakeup ll-driver callback Hans de Goede
2021-05-29 15:14 ` [PATCH 3/4] HID: logitech-dj: " Hans de Goede
2021-05-29 15:14 ` [PATCH 4/4] HID: multitouch: Disable event reporting on suspend when the device is not a wakeup-source Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1837eed3-8f99-d9be-0d35-d4b21c0e6f4e@redhat.com \
    --to=benjamin.tissoires@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).