From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Subject: Re: [PATCHv2 0/7] Support inhibiting input devices Date: Mon, 18 May 2020 16:23:21 +0200 Message-ID: References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <6d9921fc-5c2f-beda-4dcd-66d6970a22fe@redhat.com> <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org To: Andrzej Pietrasiewicz , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org Cc: "Rafael J . Wysocki" , Len Brown , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Kukjin Kim , Krzysztof Kozlowski , Dmitry Torokhov , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Vladimir Zapolskiy , Sylvain Lemieux , Laxman Dewangan , Thierry Reding , Jonathan Hunter , Barry List-Id: linux-tegra@vger.kernel.org Hi, On 5/18/20 3:49 PM, Andrzej Pietrasiewicz wrote: > Hi Hans, > > W dniu 18.05.2020 o 14:24, Hans de Goede pisze: >> Hi, >> >> On 5/18/20 12:48 PM, Andrzej Pietrasiewicz wrote: >>> Hi Hans, >>> >>> W dniu 15.05.2020 o 20:19, Hans de Goede pisze: >>>> Hi Andrezj, >>>> >>>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote: >>>>> Userspace might want to implement a policy to temporarily disregard input >>>>> from certain devices, including not treating them as wakeup sources. >>>>> >>>>> An example use case is a laptop, whose keyboard can be folded under the >>>>> screen to create tablet-like experience. The user then must hold the laptop >>>>> in such a way that it is difficult to avoid pressing the keyboard keys. It >>>>> is therefore desirable to temporarily disregard input from the keyboard, >>>>> until it is folded back. This obviously is a policy which should be kept >>>>> out of the kernel, but the kernel must provide suitable means to implement >>>>> such a policy. >>>> >>>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE >>>> generating evdev nodes and e.g. internal keyboards on devices with 360° >>>> hinges for this reason. libinput simply closes the /dev/input/event# >>>> node when folded and re-opens it when the keyboard should become active >>>> again. Thus not only suppresses events but allows e.g. touchpads to >>>> enter runtime suspend mode which saves power. Typically closing the >>>> /dev/input/event# node will also disable the device as wakeup source. >>>> >>>> So I wonder what this series actually adds for functionality for >>>> userspace which can not already be achieved this way? >>>> >>>> I also noticed that you keep the device open (do not call the >>>> input_device's close callback) when inhibited and just throw away >>> >>> I'm not sure if I understand you correctly, it is called: >>> >>> +static inline void input_stop(struct input_dev *dev) >>> +{ >>> +    if (dev->poller) >>> +        input_dev_poller_stop(dev->poller); >>> +    if (dev->close) >>> +        dev->close(dev); >>>                  ^^^^^^^^^^^^^^^^ >>> +static int input_inhibit(struct input_dev *dev) >>> +{ >>> +    int ret = 0; >>> + >>> +    mutex_lock(&dev->mutex); >>> + >>> +    if (dev->inhibited) >>> +        goto out; >>> + >>> +    if (dev->users) { >>> +        if (dev->inhibit) { >>> +            ret = dev->inhibit(dev); >>> +            if (ret) >>> +                goto out; >>> +        } >>> +        input_stop(dev); >>>                  ^^^^^^^^^^^^^^^^ >>> >>> It will not be called when dev->users is zero, but if it is zero, >>> then nobody has opened the device yet so there is nothing to close. >> >> Ah, I missed that. >> >> So if the device implements the inhibit call back then on >> inhibit it will get both the inhibit and close callback called? >> > > That's right. And conversely, upon uninhibit open() and uninhibit() > callbacks will be invoked. Please note that just as with open()/close(), > providing inhibit()/uninhibit() is optional. Ack. >> And what happens if the last user goes away and the device >> is not inhibited? > > close() is called as usually. But not inhibit, hmm, see below. >> I'm trying to understand here what the difference between the 2 >> is / what the goal of having a separate inhibit callback ? >> > > Drivers have very different ideas about what it means to suspend/resume > and open/close. The optional inhibit/uninhibit callbacks are meant for > the drivers to know that it is this particular action going on. So the inhibit() callback triggers the "suspend" behavior ? But shouldn't drivers which are capable of suspending the device always do so on close() ? Since your current proposal also calls close() on inhibit() I really see little difference between an inhibit() and the last user of the device closing it and IMHO unless there is a good reason to actually differentiate the 2 it would be better to only stick with the existing close() and in cases where that does not put the device in a low-power mode yet, fix the existing close() callback to do the low-power mode setting instead of adding a new callback. > For inhibit() there's one more argument: close() does not return a value, > so its meaning is "do some last cleanup" and as such it is not allowed > to fail - whatever its effect is, we must deem it successful. inhibit() > does return a value and so it is allowed to fail. Well, we could make close() return an error and at least in the inhibit() case propagate that to userspace. I wonder if userspace is going to do anything useful with that error though... In my experience errors during cleanup/shutdown are best logged (using dev_err) and otherwise ignored, so that we try to clean up as much possible. Unless the very first step of the shutdown process fails the device is going to be in some twilight zone state anyways at this point we might as well try to cleanup as much as possible. > All in all, it is up to the drivers to decide which callback they > provide. Based on my work so far I would say that there are tens > of simple cases where open() and close() are sufficient, out of total > ~400 users of input_allocate_device(): > > $ git grep "input_allocate_device(" | grep -v ^Documentation | \ > cut -f1 -d: | sort | uniq | wc >     390     390   13496 So can you explain a bit more about the cases where only having open/close is not sufficient? So far I have the feeling that those are all we need and that we really do not need separate [un]inhibit callbacks. Regards, Hans From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D9DAC433E0 for ; Mon, 18 May 2020 14:23:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3BD88207E8 for ; Mon, 18 May 2020 14:23:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gPkmNsYw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728119AbgEROX3 (ORCPT ); Mon, 18 May 2020 10:23:29 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:32252 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727122AbgEROX3 (ORCPT ); Mon, 18 May 2020 10:23:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589811806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N4kEWsurXWVRb491n6rW9nQFxH83gE62FpZ7K4CZ4Y8=; b=gPkmNsYwHcODmqrtBJ4fX+q6gqm7hHhnZd1/h8qfobbOeu3YlXQFsAnE2wZZxj0xhaPV51 jNMo9+kCK4Tve+MSZG3mFvkvps5lkf3CIgFUX2fytCqgvRmpIhVhqjOmoYt0A0drDh/WxI jDB/9aqRqq7NkjsQPZKXdg7B0I3A6oQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-275-ot5Q_mOTM520aOJ_-6F4hg-1; Mon, 18 May 2020 10:23:25 -0400 X-MC-Unique: ot5Q_mOTM520aOJ_-6F4hg-1 Received: by mail-wm1-f71.google.com with SMTP id l26so3164661wmh.3 for ; Mon, 18 May 2020 07:23:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N4kEWsurXWVRb491n6rW9nQFxH83gE62FpZ7K4CZ4Y8=; b=mlf56rpgiOUFKuHagn5xwiUELFoQOxeSO/yYfpq574cejmv9VWRQk1rFwAhz/+Sxd+ SsAiryIAEKi4e0t7qosUtXW4XLAzVt+++2fImN+e01dqUwZPAdrX+h0ngoaphFr9z6u2 8DOr/P6QhjvYVh/HuTL2I2XtgF7HmnUDOa8T1PWyjpqhROk0D8uXuNueRJkVMl/1tOzJ rPzev8f83l4Mrao2Z6kBr9Jej9pDfV2hyaBgYLX2Kqe/ulQjLRGFeni6r8lKIxGgZOoP P9zoOKd45HZg4U2OuRmD3DnAOB3NfL6/KsI2HOwUR7hUjvzMH49zjNoYN3DyaAtxVJ7k 1z2g== X-Gm-Message-State: AOAM533DD+1v33Qa1g0z38n4qM9LMlqoLLDPkdK+0W6jZL/wo8H50R4f 3CdUegU/MxTEszD88nXZ4I5G7sAE0Phf473PAINfN8oWNulEpwlzmn9RXngpk+z5KXNFxK+vx0K oBfxp/Q/TxULlCHeaFy17nA== X-Received: by 2002:adf:e388:: with SMTP id e8mr19930285wrm.174.1589811804153; Mon, 18 May 2020 07:23:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi/JVZYfBkPZCJ33i9pkkZ3Iw8Uks7lUYbBZX8naP80oeusj8a8mSkVZW0YdNpNt9SYero8A== X-Received: by 2002:adf:e388:: with SMTP id e8mr19930254wrm.174.1589811803884; Mon, 18 May 2020 07:23:23 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c0c-fe00-d2ea-f29d-118b-24dc.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:d2ea:f29d:118b:24dc]) by smtp.gmail.com with ESMTPSA id g187sm16732224wmf.30.2020.05.18.07.23.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 07:23:23 -0700 (PDT) Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Andrzej Pietrasiewicz , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org Cc: "Rafael J . Wysocki" , Len Brown , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Kukjin Kim , Krzysztof Kozlowski , Dmitry Torokhov , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Vladimir Zapolskiy , Sylvain Lemieux , Laxman Dewangan , Thierry Reding , Jonathan Hunter , Barry Song , Michael Hennerich , Nick Dyer , Ferruh Yigit , Sangwon Jee , Henrique de Moraes Holschuh , kernel@collabora.com, Peter Hutterer , Benjamin Tissoires References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <6d9921fc-5c2f-beda-4dcd-66d6970a22fe@redhat.com> <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> From: Hans de Goede Message-ID: Date: Mon, 18 May 2020 16:23:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi, On 5/18/20 3:49 PM, Andrzej Pietrasiewicz wrote: > Hi Hans, > > W dniu 18.05.2020 o 14:24, Hans de Goede pisze: >> Hi, >> >> On 5/18/20 12:48 PM, Andrzej Pietrasiewicz wrote: >>> Hi Hans, >>> >>> W dniu 15.05.2020 o 20:19, Hans de Goede pisze: >>>> Hi Andrezj, >>>> >>>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote: >>>>> Userspace might want to implement a policy to temporarily disregard input >>>>> from certain devices, including not treating them as wakeup sources. >>>>> >>>>> An example use case is a laptop, whose keyboard can be folded under the >>>>> screen to create tablet-like experience. The user then must hold the laptop >>>>> in such a way that it is difficult to avoid pressing the keyboard keys. It >>>>> is therefore desirable to temporarily disregard input from the keyboard, >>>>> until it is folded back. This obviously is a policy which should be kept >>>>> out of the kernel, but the kernel must provide suitable means to implement >>>>> such a policy. >>>> >>>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE >>>> generating evdev nodes and e.g. internal keyboards on devices with 360° >>>> hinges for this reason. libinput simply closes the /dev/input/event# >>>> node when folded and re-opens it when the keyboard should become active >>>> again. Thus not only suppresses events but allows e.g. touchpads to >>>> enter runtime suspend mode which saves power. Typically closing the >>>> /dev/input/event# node will also disable the device as wakeup source. >>>> >>>> So I wonder what this series actually adds for functionality for >>>> userspace which can not already be achieved this way? >>>> >>>> I also noticed that you keep the device open (do not call the >>>> input_device's close callback) when inhibited and just throw away >>> >>> I'm not sure if I understand you correctly, it is called: >>> >>> +static inline void input_stop(struct input_dev *dev) >>> +{ >>> +    if (dev->poller) >>> +        input_dev_poller_stop(dev->poller); >>> +    if (dev->close) >>> +        dev->close(dev); >>>                  ^^^^^^^^^^^^^^^^ >>> +static int input_inhibit(struct input_dev *dev) >>> +{ >>> +    int ret = 0; >>> + >>> +    mutex_lock(&dev->mutex); >>> + >>> +    if (dev->inhibited) >>> +        goto out; >>> + >>> +    if (dev->users) { >>> +        if (dev->inhibit) { >>> +            ret = dev->inhibit(dev); >>> +            if (ret) >>> +                goto out; >>> +        } >>> +        input_stop(dev); >>>                  ^^^^^^^^^^^^^^^^ >>> >>> It will not be called when dev->users is zero, but if it is zero, >>> then nobody has opened the device yet so there is nothing to close. >> >> Ah, I missed that. >> >> So if the device implements the inhibit call back then on >> inhibit it will get both the inhibit and close callback called? >> > > That's right. And conversely, upon uninhibit open() and uninhibit() > callbacks will be invoked. Please note that just as with open()/close(), > providing inhibit()/uninhibit() is optional. Ack. >> And what happens if the last user goes away and the device >> is not inhibited? > > close() is called as usually. But not inhibit, hmm, see below. >> I'm trying to understand here what the difference between the 2 >> is / what the goal of having a separate inhibit callback ? >> > > Drivers have very different ideas about what it means to suspend/resume > and open/close. The optional inhibit/uninhibit callbacks are meant for > the drivers to know that it is this particular action going on. So the inhibit() callback triggers the "suspend" behavior ? But shouldn't drivers which are capable of suspending the device always do so on close() ? Since your current proposal also calls close() on inhibit() I really see little difference between an inhibit() and the last user of the device closing it and IMHO unless there is a good reason to actually differentiate the 2 it would be better to only stick with the existing close() and in cases where that does not put the device in a low-power mode yet, fix the existing close() callback to do the low-power mode setting instead of adding a new callback. > For inhibit() there's one more argument: close() does not return a value, > so its meaning is "do some last cleanup" and as such it is not allowed > to fail - whatever its effect is, we must deem it successful. inhibit() > does return a value and so it is allowed to fail. Well, we could make close() return an error and at least in the inhibit() case propagate that to userspace. I wonder if userspace is going to do anything useful with that error though... In my experience errors during cleanup/shutdown are best logged (using dev_err) and otherwise ignored, so that we try to clean up as much possible. Unless the very first step of the shutdown process fails the device is going to be in some twilight zone state anyways at this point we might as well try to cleanup as much as possible. > All in all, it is up to the drivers to decide which callback they > provide. Based on my work so far I would say that there are tens > of simple cases where open() and close() are sufficient, out of total > ~400 users of input_allocate_device(): > > $ git grep "input_allocate_device(" | grep -v ^Documentation | \ > cut -f1 -d: | sort | uniq | wc >     390     390   13496 So can you explain a bit more about the cases where only having open/close is not sufficient? So far I have the feeling that those are all we need and that we really do not need separate [un]inhibit callbacks. Regards, Hans From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05FDEC433DF for ; Mon, 18 May 2020 14:23:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C165520657 for ; Mon, 18 May 2020 14:23:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZP142UQV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gPkmNsYw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C165520657 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vGqcuUwktP9zciDecZBtGem+KL2tBtd1nIzMaf9oYk4=; b=ZP142UQV1yAO5Sr0AKJbQGZiv sTDJ+yTLm6pYTlfmZJdIK/zdksQ7CXQMGrowHmgshueG0EeKNUnSig4/FWdpqgfL23aVsA5LsQQK+ piyK++om+s09UTFDs85YUJ3LsBv84jzzXlvIWpyXwi6Wck4CvpBNcUVO6lMQc5e8gcHwj21SSW97s CXVmg15PKjM8w6MWMmks8Zb+uhl3jOs1rZHqP0BU4Awfd1myiZ7yS7+JHD57a9PbXtnf4MZbPjALo 4I7RRkglre3QPWvjqqIr/P+heOkUT2wS8E0wZlwVeAIXfS2Lia/kxfGFvBafMqst0StU+e4egrZXl Gw1EeZh1A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jagg1-00022g-5x; Mon, 18 May 2020 14:23:33 +0000 Received: from us-smtp-1.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jagfy-000222-8J for linux-arm-kernel@lists.infradead.org; Mon, 18 May 2020 14:23:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589811806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N4kEWsurXWVRb491n6rW9nQFxH83gE62FpZ7K4CZ4Y8=; b=gPkmNsYwHcODmqrtBJ4fX+q6gqm7hHhnZd1/h8qfobbOeu3YlXQFsAnE2wZZxj0xhaPV51 jNMo9+kCK4Tve+MSZG3mFvkvps5lkf3CIgFUX2fytCqgvRmpIhVhqjOmoYt0A0drDh/WxI jDB/9aqRqq7NkjsQPZKXdg7B0I3A6oQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-423-qEXj0okBPwmtggCCtv68LQ-1; Mon, 18 May 2020 10:23:25 -0400 X-MC-Unique: qEXj0okBPwmtggCCtv68LQ-1 Received: by mail-wm1-f69.google.com with SMTP id t82so3065236wmf.4 for ; Mon, 18 May 2020 07:23:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N4kEWsurXWVRb491n6rW9nQFxH83gE62FpZ7K4CZ4Y8=; b=Kkb6QXYF4pXB9vYm4WhyV21Xmj2u6G8YUiV6pQN4VeOybxDeqzCj6IvlWyVuO3K/Ep DCbSdC6u5Qynt/u+cbS+uKQvb+4AylBqUI5Elo8Cz8YJuFkcAcGyZrlMJnunlNIIGLpL Zrr9h4WCIRCOGLsUPcvqWwek/AtwMDUyV98wmoysSnLJeEvp6CPrPQVGGxPefcBv/Qhe Oyk6S8DVuzdlQUNSAUzVkMqjqT2lKW2p2pdMMN3GUTFUB4AXv8ic4x8NuEUgP1JchgCN k5eZwCiX2FC23hF61CZal/6ENqPsU1KqhDzL2phL9GDkB3RJtK7Ue6KVFYlkFjnHrk/2 FSuA== X-Gm-Message-State: AOAM533yoCE0zv54Lqp+PaeNrU2NR4OmpHgjGkYsD5YbKwC9FIlwpBoG PKN9c8uXegQ3VpkVm86a8vrixIN/ybRnV7kLf8nc32cX3pbh4QJ6UfBA2Myyw9S4Krhq7Uu59iq q/lxMJkIwxKkZndbGUsFi2TtAdigEyrbNIAc= X-Received: by 2002:adf:e388:: with SMTP id e8mr19930283wrm.174.1589811804154; Mon, 18 May 2020 07:23:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi/JVZYfBkPZCJ33i9pkkZ3Iw8Uks7lUYbBZX8naP80oeusj8a8mSkVZW0YdNpNt9SYero8A== X-Received: by 2002:adf:e388:: with SMTP id e8mr19930254wrm.174.1589811803884; Mon, 18 May 2020 07:23:23 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c0c-fe00-d2ea-f29d-118b-24dc.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:d2ea:f29d:118b:24dc]) by smtp.gmail.com with ESMTPSA id g187sm16732224wmf.30.2020.05.18.07.23.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 07:23:23 -0700 (PDT) Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Andrzej Pietrasiewicz , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <6d9921fc-5c2f-beda-4dcd-66d6970a22fe@redhat.com> <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> From: Hans de Goede Message-ID: Date: Mon, 18 May 2020 16:23:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200518_072330_373582_50FC5E95 X-CRM114-Status: GOOD ( 30.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nick Dyer , Benjamin Tissoires , Laxman Dewangan , Peter Meerwald-Stadler , kernel@collabora.com, Fabio Estevam , Lars-Peter Clausen , Krzysztof Kozlowski , Jonathan Hunter , Kukjin Kim , NXP Linux Team , Sylvain Lemieux , Len Brown , Peter Hutterer , Michael Hennerich , Sascha Hauer , Henrique de Moraes Holschuh , Vladimir Zapolskiy , Barry Song , Ferruh Yigit , Dmitry Torokhov , "Rafael J . Wysocki" , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGksCgpPbiA1LzE4LzIwIDM6NDkgUE0sIEFuZHJ6ZWogUGlldHJhc2lld2ljeiB3cm90ZToKPiBI aSBIYW5zLAo+IAo+IFcgZG5pdSAxOC4wNS4yMDIwIG/CoDE0OjI0LCBIYW5zIGRlIEdvZWRlIHBp c3plOgo+PiBIaSwKPj4KPj4gT24gNS8xOC8yMCAxMjo0OCBQTSwgQW5kcnplaiBQaWV0cmFzaWV3 aWN6IHdyb3RlOgo+Pj4gSGkgSGFucywKPj4+Cj4+PiBXIGRuaXUgMTUuMDUuMjAyMCBvwqAyMDox OSwgSGFucyBkZSBHb2VkZSBwaXN6ZToKPj4+PiBIaSBBbmRyZXpqLAo+Pj4+Cj4+Pj4gT24gNS8x NS8yMCA2OjQ5IFBNLCBBbmRyemVqIFBpZXRyYXNpZXdpY3ogd3JvdGU6Cj4+Pj4+IFVzZXJzcGFj ZSBtaWdodCB3YW50IHRvIGltcGxlbWVudCBhIHBvbGljeSB0byB0ZW1wb3JhcmlseSBkaXNyZWdh cmQgaW5wdXQKPj4+Pj4gZnJvbSBjZXJ0YWluIGRldmljZXMsIGluY2x1ZGluZyBub3QgdHJlYXRp bmcgdGhlbSBhcyB3YWtldXAgc291cmNlcy4KPj4+Pj4KPj4+Pj4gQW4gZXhhbXBsZSB1c2UgY2Fz ZSBpcyBhIGxhcHRvcCwgd2hvc2Uga2V5Ym9hcmQgY2FuIGJlIGZvbGRlZCB1bmRlciB0aGUKPj4+ Pj4gc2NyZWVuIHRvIGNyZWF0ZSB0YWJsZXQtbGlrZSBleHBlcmllbmNlLiBUaGUgdXNlciB0aGVu IG11c3QgaG9sZCB0aGUgbGFwdG9wCj4+Pj4+IGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBpcyBkaWZm aWN1bHQgdG8gYXZvaWQgcHJlc3NpbmcgdGhlIGtleWJvYXJkIGtleXMuIEl0Cj4+Pj4+IGlzIHRo ZXJlZm9yZSBkZXNpcmFibGUgdG8gdGVtcG9yYXJpbHkgZGlzcmVnYXJkIGlucHV0IGZyb20gdGhl IGtleWJvYXJkLAo+Pj4+PiB1bnRpbCBpdCBpcyBmb2xkZWQgYmFjay4gVGhpcyBvYnZpb3VzbHkg aXMgYSBwb2xpY3kgd2hpY2ggc2hvdWxkIGJlIGtlcHQKPj4+Pj4gb3V0IG9mIHRoZSBrZXJuZWws IGJ1dCB0aGUga2VybmVsIG11c3QgcHJvdmlkZSBzdWl0YWJsZSBtZWFucyB0byBpbXBsZW1lbnQK Pj4+Pj4gc3VjaCBhIHBvbGljeS4KPj4+Pgo+Pj4+IEFjdHVhbGx5IGxpYmlucHV0IGFscmVhZHkg YmluZHMgdG9nZXRoZXIgKGluc2lkZSBsaWJpbnB1dCkgU1dfVEFCTEVUX01PREUKPj4+PiBnZW5l cmF0aW5nIGV2ZGV2IG5vZGVzIGFuZCBlLmcuIGludGVybmFsIGtleWJvYXJkcyBvbiBkZXZpY2Vz IHdpdGggMzYwwrAKPj4+PiBoaW5nZXMgZm9yIHRoaXMgcmVhc29uLiBsaWJpbnB1dCBzaW1wbHkg Y2xvc2VzIHRoZSAvZGV2L2lucHV0L2V2ZW50Iwo+Pj4+IG5vZGUgd2hlbiBmb2xkZWQgYW5kIHJl LW9wZW5zIGl0IHdoZW4gdGhlIGtleWJvYXJkIHNob3VsZCBiZWNvbWUgYWN0aXZlCj4+Pj4gYWdh aW4uIFRodXMgbm90IG9ubHkgc3VwcHJlc3NlcyBldmVudHMgYnV0IGFsbG93cyBlLmcuIHRvdWNo cGFkcyB0bwo+Pj4+IGVudGVyIHJ1bnRpbWUgc3VzcGVuZCBtb2RlIHdoaWNoIHNhdmVzIHBvd2Vy LiBUeXBpY2FsbHkgY2xvc2luZyB0aGUKPj4+PiAvZGV2L2lucHV0L2V2ZW50IyBub2RlIHdpbGwg YWxzbyBkaXNhYmxlIHRoZSBkZXZpY2UgYXMgd2FrZXVwIHNvdXJjZS4KPj4+Pgo+Pj4+IFNvIEkg d29uZGVyIHdoYXQgdGhpcyBzZXJpZXMgYWN0dWFsbHkgYWRkcyBmb3IgZnVuY3Rpb25hbGl0eSBm b3IKPj4+PiB1c2Vyc3BhY2Ugd2hpY2ggY2FuIG5vdCBhbHJlYWR5IGJlIGFjaGlldmVkIHRoaXMg d2F5Pwo+Pj4+Cj4+Pj4gSSBhbHNvIG5vdGljZWQgdGhhdCB5b3Uga2VlcCB0aGUgZGV2aWNlIG9w ZW4gKGRvIG5vdCBjYWxsIHRoZQo+Pj4+IGlucHV0X2RldmljZSdzIGNsb3NlIGNhbGxiYWNrKSB3 aGVuIGluaGliaXRlZCBhbmQganVzdCB0aHJvdyBhd2F5Cj4+Pgo+Pj4gSSdtIG5vdCBzdXJlIGlm IEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5LCBpdCBpcyBjYWxsZWQ6Cj4+Pgo+Pj4gK3N0YXRp YyBpbmxpbmUgdm9pZCBpbnB1dF9zdG9wKHN0cnVjdCBpbnB1dF9kZXYgKmRldikKPj4+ICt7Cj4+ PiArwqDCoMKgIGlmIChkZXYtPnBvbGxlcikKPj4+ICvCoMKgwqDCoMKgwqDCoCBpbnB1dF9kZXZf cG9sbGVyX3N0b3AoZGV2LT5wb2xsZXIpOwo+Pj4gK8KgwqDCoCBpZiAoZGV2LT5jbG9zZSkKPj4+ ICvCoMKgwqDCoMKgwqDCoCBkZXYtPmNsb3NlKGRldik7Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBeXl5eXl5eXl5eXl5eXl5eCj4+PiArc3RhdGljIGludCBpbnB1dF9pbmhp Yml0KHN0cnVjdCBpbnB1dF9kZXYgKmRldikKPj4+ICt7Cj4+PiArwqDCoMKgIGludCByZXQgPSAw Owo+Pj4gKwo+Pj4gK8KgwqDCoCBtdXRleF9sb2NrKCZkZXYtPm11dGV4KTsKPj4+ICsKPj4+ICvC oMKgwqAgaWYgKGRldi0+aW5oaWJpdGVkKQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGdvdG8gb3V0Owo+ Pj4gKwo+Pj4gK8KgwqDCoCBpZiAoZGV2LT51c2Vycykgewo+Pj4gK8KgwqDCoMKgwqDCoMKgIGlm IChkZXYtPmluaGliaXQpIHsKPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldCA9IGRldi0+ aW5oaWJpdChkZXYpOwo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKHJldCkKPj4+ICvC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZ290byBvdXQ7Cj4+PiArwqDCoMKgwqDCoMKg wqAgfQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGlucHV0X3N0b3AoZGV2KTsKPj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIF5eXl5eXl5eXl5eXl5eXl4KPj4+Cj4+PiBJdCB3aWxsIG5v dCBiZSBjYWxsZWQgd2hlbiBkZXYtPnVzZXJzIGlzIHplcm8sIGJ1dCBpZiBpdCBpcyB6ZXJvLAo+ Pj4gdGhlbiBub2JvZHkgaGFzIG9wZW5lZCB0aGUgZGV2aWNlIHlldCBzbyB0aGVyZSBpcyBub3Ro aW5nIHRvIGNsb3NlLgo+Pgo+PiBBaCwgSSBtaXNzZWQgdGhhdC4KPj4KPj4gU28gaWYgdGhlIGRl dmljZSBpbXBsZW1lbnRzIHRoZSBpbmhpYml0IGNhbGwgYmFjayB0aGVuIG9uCj4+IGluaGliaXQg aXQgd2lsbCBnZXQgYm90aCB0aGUgaW5oaWJpdCBhbmQgY2xvc2UgY2FsbGJhY2sgY2FsbGVkPwo+ Pgo+IAo+IFRoYXQncyByaWdodC4gQW5kIGNvbnZlcnNlbHksIHVwb24gdW5pbmhpYml0IG9wZW4o KSBhbmQgdW5pbmhpYml0KCkKPiBjYWxsYmFja3Mgd2lsbCBiZSBpbnZva2VkLiBQbGVhc2Ugbm90 ZSB0aGF0IGp1c3QgYXMgd2l0aCBvcGVuKCkvY2xvc2UoKSwKPiBwcm92aWRpbmcgaW5oaWJpdCgp L3VuaW5oaWJpdCgpIGlzIG9wdGlvbmFsLgoKQWNrLgoKPj4gQW5kIHdoYXQgaGFwcGVucyBpZiB0 aGUgbGFzdCB1c2VyIGdvZXMgYXdheSBhbmQgdGhlIGRldmljZQo+PiBpcyBub3QgaW5oaWJpdGVk Pwo+IAo+IGNsb3NlKCkgaXMgY2FsbGVkIGFzIHVzdWFsbHkuCgpCdXQgbm90IGluaGliaXQsIGht bSwgc2VlIGJlbG93LgoKPj4gSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIGhlcmUgd2hhdCB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSAyCj4+IGlzIC8gd2hhdCB0aGUgZ29hbCBvZiBoYXZpbmcg YSBzZXBhcmF0ZSBpbmhpYml0IGNhbGxiYWNrID8KPj4KPiAKPiBEcml2ZXJzIGhhdmUgdmVyeSBk aWZmZXJlbnQgaWRlYXMgYWJvdXQgd2hhdCBpdCBtZWFucyB0byBzdXNwZW5kL3Jlc3VtZQo+IGFu ZCBvcGVuL2Nsb3NlLiBUaGUgb3B0aW9uYWwgaW5oaWJpdC91bmluaGliaXQgY2FsbGJhY2tzIGFy ZSBtZWFudCBmb3IKPiB0aGUgZHJpdmVycyB0byBrbm93IHRoYXQgaXQgaXMgdGhpcyBwYXJ0aWN1 bGFyIGFjdGlvbiBnb2luZyBvbi4KClNvIHRoZSBpbmhpYml0KCkgY2FsbGJhY2sgdHJpZ2dlcnMg dGhlICJzdXNwZW5kIiBiZWhhdmlvciA/CkJ1dCBzaG91bGRuJ3QgZHJpdmVycyB3aGljaCBhcmUg Y2FwYWJsZSBvZiBzdXNwZW5kaW5nIHRoZSBkZXZpY2UKYWx3YXlzIGRvIHNvIG9uIGNsb3NlKCkg PwoKU2luY2UgeW91ciBjdXJyZW50IHByb3Bvc2FsIGFsc28gY2FsbHMgY2xvc2UoKSBvbiBpbmhp Yml0KCkgSQpyZWFsbHkgc2VlIGxpdHRsZSBkaWZmZXJlbmNlIGJldHdlZW4gYW4gaW5oaWJpdCgp IGFuZCB0aGUgbGFzdAp1c2VyIG9mIHRoZSBkZXZpY2UgY2xvc2luZyBpdCBhbmQgSU1ITyB1bmxl c3MgdGhlcmUgaXMgYSBnb29kCnJlYXNvbiB0byBhY3R1YWxseSBkaWZmZXJlbnRpYXRlIHRoZSAy IGl0IHdvdWxkIGJlIGJldHRlcgp0byBvbmx5IHN0aWNrIHdpdGggdGhlIGV4aXN0aW5nIGNsb3Nl KCkgYW5kIGluIGNhc2VzIHdoZXJlCnRoYXQgZG9lcyBub3QgcHV0IHRoZSBkZXZpY2UgaW4gYSBs b3ctcG93ZXIgbW9kZSB5ZXQsIGZpeAp0aGUgZXhpc3RpbmcgY2xvc2UoKSBjYWxsYmFjayB0byBk byB0aGUgbG93LXBvd2VyIG1vZGUKc2V0dGluZyBpbnN0ZWFkIG9mIGFkZGluZyBhIG5ldyBjYWxs YmFjay4KCj4gRm9yIGluaGliaXQoKSB0aGVyZSdzIG9uZSBtb3JlIGFyZ3VtZW50OiBjbG9zZSgp IGRvZXMgbm90IHJldHVybiBhIHZhbHVlLAo+IHNvIGl0cyBtZWFuaW5nIGlzICJkbyBzb21lIGxh c3QgY2xlYW51cCIgYW5kIGFzIHN1Y2ggaXQgaXMgbm90IGFsbG93ZWQKPiB0byBmYWlsIC0gd2hh dGV2ZXIgaXRzIGVmZmVjdCBpcywgd2UgbXVzdCBkZWVtIGl0IHN1Y2Nlc3NmdWwuIGluaGliaXQo KQo+IGRvZXMgcmV0dXJuIGEgdmFsdWUgYW5kIHNvIGl0IGlzIGFsbG93ZWQgdG8gZmFpbC4KCldl bGwsIHdlIGNvdWxkIG1ha2UgY2xvc2UoKSByZXR1cm4gYW4gZXJyb3IgYW5kIGF0IGxlYXN0IGlu IHRoZSBpbmhpYml0KCkKY2FzZSBwcm9wYWdhdGUgdGhhdCB0byB1c2Vyc3BhY2UuIEkgd29uZGVy IGlmIHVzZXJzcGFjZSBpcyBnb2luZyB0bwpkbyBhbnl0aGluZyB1c2VmdWwgd2l0aCB0aGF0IGVy cm9yIHRob3VnaC4uLgoKSW4gbXkgZXhwZXJpZW5jZSBlcnJvcnMgZHVyaW5nIGNsZWFudXAvc2h1 dGRvd24gYXJlIGJlc3QgbG9nZ2VkCih1c2luZyBkZXZfZXJyKSBhbmQgb3RoZXJ3aXNlIGlnbm9y ZWQsIHNvIHRoYXQgd2UgdHJ5IHRvIGNsZWFuIHVwCmFzIG11Y2ggcG9zc2libGUuIFVubGVzcyB0 aGUgdmVyeSBmaXJzdCBzdGVwIG9mIHRoZSBzaHV0ZG93biBwcm9jZXNzCmZhaWxzIHRoZSBkZXZp Y2UgaXMgZ29pbmcgdG8gYmUgaW4gc29tZSB0d2lsaWdodCB6b25lIHN0YXRlIGFueXdheXMKYXQg dGhpcyBwb2ludCB3ZSBtaWdodCBhcyB3ZWxsIHRyeSB0byBjbGVhbnVwIGFzIG11Y2ggYXMgcG9z c2libGUuCgo+IEFsbCBpbiBhbGwsIGl0IGlzIHVwIHRvIHRoZSBkcml2ZXJzIHRvIGRlY2lkZSB3 aGljaCBjYWxsYmFjayB0aGV5Cj4gcHJvdmlkZS4gQmFzZWQgb24gbXkgd29yayBzbyBmYXIgSSB3 b3VsZCBzYXkgdGhhdCB0aGVyZSBhcmUgdGVucwo+IG9mIHNpbXBsZSBjYXNlcyB3aGVyZSBvcGVu KCkgYW5kIGNsb3NlKCkgYXJlIHN1ZmZpY2llbnQsIG91dCBvZiB0b3RhbAo+IH40MDAgdXNlcnMg b2YgaW5wdXRfYWxsb2NhdGVfZGV2aWNlKCk6Cj4gCj4gJCBnaXQgZ3JlcCAiaW5wdXRfYWxsb2Nh dGVfZGV2aWNlKCIgfCBncmVwIC12IF5Eb2N1bWVudGF0aW9uIHwgXAo+IGN1dCAtZjEgLWQ6IHwg c29ydCB8IHVuaXEgfCB3Ywo+ICDCoMKgwqAgMzkwwqDCoMKgwqAgMzkwwqDCoCAxMzQ5NgoKU28g Y2FuIHlvdSBleHBsYWluIGEgYml0IG1vcmUgYWJvdXQgdGhlIGNhc2VzIHdoZXJlIG9ubHkgaGF2 aW5nCm9wZW4vY2xvc2UgaXMgbm90IHN1ZmZpY2llbnQ/ICBTbyBmYXIgSSBoYXZlIHRoZSBmZWVs aW5nIHRoYXQKdGhvc2UgYXJlIGFsbCB3ZSBuZWVkIGFuZCB0aGF0IHdlIHJlYWxseSBkbyBub3Qg bmVlZCBzZXBhcmF0ZQpbdW5daW5oaWJpdCBjYWxsYmFja3MuCgpSZWdhcmRzLAoKSGFucwoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1r ZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpo dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJu ZWwK