On Wed, May 5, 2021 at 4:00 PM Hans de Goede [off-list ref] wrote:

Hi,

On 5/5/21 3:40 PM, Benjamin Tissoires wrote:

quoted

Hi Hans,

On Sat, Mar 6, 2021 at 2:37 PM Hans de Goede [off-list ref] wrote:

quoted

Disable event reporting on suspend when our parent is not
a wakeup-source. This should help save some extra power in
this case.

Signed-off-by: Hans de Goede <redacted>
---
 drivers/hid/Kconfig          |  2 +-
 drivers/hid/hid-multitouch.c | 23 ++++++++++++++++++++++-
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 786b71ef7738..5cbe4adfd816 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig

@@ -675,7 +675,7 @@ config HID_MONTEREY

 config HID_MULTITOUCH
        tristate "HID Multitouch panels"
-       depends on HID
+       depends on USB_HID

I tried really hard during the past 8 years to not have a usbhid
dependency on hid-multitouch.

The code below should not break the test suite, but still I am not
that happy about the Kconfig change.

I don't see an immediate and better way of doing what you are
achieving here, but maybe you have some magic I did not think about
that would help to no pull USB_HID with HID_MULTITOUCH.

FTR, I think the use case of hid-multitouch *without* USB is rather
non-existent, but there might be some weird systems with I2C only
(edge computing?).

Interesting how you often manage to pick out the bits of patches
which I'm not 100% happy with myself either. I was thinking the
same thing myself.

:)

We have this: "hid_is_using_ll_driver(hdev, &usb_hid_driver)" check
in various drivers under drivers/hid and so far the dependency fix
of adding a "depends on USB_HID" was not pretty but ok, because it
would be weird to enable those HID drivers on a system without
USB_HID being enabled. But I agree with you that hid-multitouch
is different. So I did try to come up with something better and
failed.

But now that I look at this with fresh eyes I think I see a
nice solution for this.

I propose to add a hid_is_usb_device() helper which is defined
in hid-core.c (1) and this helper would look like this:

bool hid_is_usb_device(struct hid_device *hid)
{
#if IS_ENABLED(CONFIG_USB_HID)
        return hid_is_using_ll_driver(hid, &usb_hid_driver);
#else
        return false;
#endif
}

And then I can use this helper function instead of directly doing
the hid_is_using_ll_driver() check in hid-multitouch.c fixing
this dependency ugliness.

1) hid-core.c is controlled by CONFIG_HID which gets selected at
the Kconfig level by CONFIG_USB_HID so there is no chance of
builtin vs module issues.

OK, sounds good enough to me. The one thing I dislike about IS_ENABLED
is that it is not very friendly with out of the tree modules. But
here, I guess if you have a system without CONFIG_USB_HID, you will
probably never need to enable it without recompiling your tree.

So ack by me.

As an added bonus I can then also do a follow-up patch-set to
remove more depends on USB_HID stuff by switching to the helper
in other places too.

That would be wonderful :)

###

Unrelated but something else which I was wondering about while
working on this patch.

I think that it might also be useful to change the
mt_parent_may_wake() helper introduced here into a generic
hid_parent_may_wakeup() helper in case we need a similar thing
in other places. I decided it may be best to do that once we
have a second driver needing such a check, but since we're
discussing this anyways, what is your opinion on this ?

I can definitely see the benefit of it, but OTOH, I would stick to
your first approach. If we are just needing it for one driver, we
probably want to keep it local to this one driver.

Cheers,
Benjamin

Regards,

Hans

quoted

quoted

        help
          Generic support for HID multitouch panels.

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index cfb68e443ddd..7926295bab81 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c

@@ -1759,12 +1759,33 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
 }

 #ifdef CONFIG_PM
+
+/* Check if the parent which has the power/wakeup* sysfs attributes may wake the hdev */
+static bool mt_parent_may_wake(struct hid_device *hdev)
+{
+       struct device *parent = hdev->dev.parent;
+
+       /*
+        * USB-HID is attached to the usb_interface (our parent), the
+        * power/wakeup* attr are part of the usb-device which is its parent.
+        */
+       if (hid_is_using_ll_driver(hdev, &usb_hid_driver) && parent)
+               parent = parent->parent;
+
+       if (parent)
+               return device_may_wakeup(parent);
+
+       /* Huh? Play it safe and keep reporting events. */
+       return true;
+}
+
 static int mt_suspend(struct hid_device *hdev, pm_message_t state)
 {
        struct mt_device *td = hid_get_drvdata(hdev);

        /* High latency is desirable for power savings during S3/S0ix */
-       if (td->mtclass.quirks & MT_QUIRK_DISABLE_WAKEUP)
+       if ((td->mtclass.quirks & MT_QUIRK_DISABLE_WAKEUP) ||
+           !mt_parent_may_wake(hdev))
                mt_set_modes(hdev, HID_LATENCY_HIGH, false, false);
        else
                mt_set_modes(hdev, HID_LATENCY_HIGH, true, true);
--

2.30.1