From: Randy Dunlap <rdunlap@infradead.org>
To: Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-input@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" <rjw@rjwysocki.net>,
"Len Brown" <lenb@kernel.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Hartmut Knaack" <knaack.h@gmx.de>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Peter Meerwald-Stadler" <pmeerw@pmeerw.net>,
"Kukjin Kim" <kgene@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"NXP Linux Team" <linux-imx@nxp.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Sylvain Lemieux" <slemieux.tyco@gmail.com>,
"Laxman Dewangan" <ldewangan@nvidia.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Barry Song" <baohua@kernel.org>,
"Michael Hennerich" <michael.hennerich@analog.com>,
"Nick Dyer" <nick@shmanahar.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Sangwon Jee" <jeesw@melfas.com>,
"Peter Hutterer" <peter.hutterer@redhat.com>,
"Henrique de Moraes Holschuh" <ibm-acpi@hmh.eng.br>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
kernel@collabora.com
Subject: Re: [PATCH] Input: document inhibiting
Date: Tue, 16 Jun 2020 10:38:25 -0700 [thread overview]
Message-ID: <d51a16b9-9ebd-1150-7d47-6296dcd2989b@infradead.org> (raw)
In-Reply-To: <20200616172909.21625-1-andrzej.p@collabora.com>
On 6/16/20 10:29 AM, Andrzej Pietrasiewicz wrote:
> Document inhibiting input devices and its relation to being
> a wakeup source.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
Hi,
I have some editorial comments. Please see below.
> @Hans, @Dmitry,
>
> My fist attempt at documenting inhibiting. Kindly look at it to see if I haven't got anything
> wrong.
>
> Andrzej
>
> Documentation/input/input-programming.rst | 36 +++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
> index 45a4c6e05e39..0cd1ad4504fb 100644
> --- a/Documentation/input/input-programming.rst
> +++ b/Documentation/input/input-programming.rst
> @@ -164,6 +164,42 @@ disconnects. Calls to both callbacks are serialized.
> The open() callback should return a 0 in case of success or any nonzero value
> in case of failure. The close() callback (which is void) must always succeed.
>
> +Inhibiting input devices
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Inhibiting a device means ignoring input events from it. As such it is about maintaining
> +relationships with input handlers - either an already existing relationships, or
> +relationships to be established while the device is in inhibited state.
> +
> +If a device is inhibited, no input handler will receive events from it.
> +
> +The fact that nobody wants events from the device is exploited further, by calling device's
> +close() (if there are users) and open() (if there are users) on inhibit and uninhibit
> +operations, respectively. Indeed, the meaning of close() is to stop providing events
> +to the input core and that of open() is to start providing events to the input core.
> +
> +Inhibiting and uninhibiting is orthogonal to opening and closing the device by input
are
> +handlers. Userspace might want to inhibit a device in anticipation before any handler is
> +positively matched against it.
> +
> +Inhibiting and uninhibiting is orthogonal to device's being a wakeup source, too. Being a
are
> +wakeup source plays a role when the system is sleeping, not when the system is operating.
> +How drivers should program their interaction between inhibiting, sleeping and being a wakeup
> +source is driver-specific.
> +
> +Taking the analogy with the network devices - bringing a network interface down doesn't mean
> +that it should be impossible to be wake the system up on LAN through this interface. So, there
> +may be input drivers which should be considered wakeup sources even when inhibited. Actually,
> +in many i2c input devices their interrupt is declared a wakeup interrupt and its handling
I2C
> +happens in driver's core, which is not aware of input-specific inhibit (nor should it be).
> +Composite devices containing several interfaces can be inhibited on a per-interface basis and
> +e.g. inhibiting one interface shouldn't affect the device's capability of being a wakeup source.
> +
> +If a device is to be considered a wakeup source while inhibited, special care must be taken when
> +programming its suspend(), as it might need to call device's open(). Depending on what close()
> +means for the device in question not opening() it before going to sleep might make it impossible
in question, not
> +to provide any wakeup events. The device is going to sleep anyway.
> +
> Basic event types
> ~~~~~~~~~~~~~~~~~
>
>
thanks for documentation.
--
~Randy
next prev parent reply other threads:[~2020-06-16 17:39 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200506002746.GB89269@dtor-ws>
2020-05-15 16:49 ` [PATCHv2 0/7] Support inhibiting input devices Andrzej Pietrasiewicz
2020-05-15 16:51 ` [PATCHv2 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-05-15 16:52 ` [PATCHv2 4/7] iio: adc: exynos: Use input_device_enabled() Andrzej Pietrasiewicz
2020-05-15 16:52 ` [PATCHv2 6/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-05-15 18:19 ` [PATCHv2 0/7] Support inhibiting input devices Hans de Goede
2020-05-17 22:55 ` Peter Hutterer
2020-05-18 2:40 ` Dmitry Torokhov
2020-05-18 7:36 ` Hans de Goede
2020-05-22 15:35 ` Andrzej Pietrasiewicz
2020-05-27 6:13 ` Peter Hutterer
2020-05-18 10:48 ` Andrzej Pietrasiewicz
2020-05-18 12:24 ` Hans de Goede
2020-05-18 13:49 ` Andrzej Pietrasiewicz
2020-05-18 14:23 ` Hans de Goede
2020-05-19 9:02 ` Andrzej Pietrasiewicz
2020-05-19 9:36 ` Hans de Goede
2020-05-27 6:34 ` Dmitry Torokhov
2020-06-02 16:56 ` Andrzej Pietrasiewicz
2020-06-02 17:52 ` Dmitry Torokhov
2020-06-02 18:50 ` Andrzej Pietrasiewicz
2020-06-02 20:19 ` Hans de Goede
2020-06-03 13:07 ` Andrzej Pietrasiewicz
2020-06-03 17:38 ` Hans de Goede
2020-06-03 17:54 ` Andrzej Pietrasiewicz
2020-06-03 19:37 ` Hans de Goede
2020-06-04 7:28 ` Dmitry Torokhov
2020-06-05 17:33 ` [PATCH v3 " Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 2/7] Input: use input_device_enabled() Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 3/7] ACPI: button: Access input device's users under appropriate mutex Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 4/7] ACPI: button: Use input_device_enabled() helper Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 5/7] iio: adc: exynos: Use input_device_enabled() Andrzej Pietrasiewicz
2020-06-05 19:49 ` Michał Mirosław
2020-06-05 17:33 ` [PATCH v3 6/7] platform/x86: thinkpad_acpi: " Andrzej Pietrasiewicz
2020-06-05 17:33 ` [PATCH v3 7/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-06-05 17:41 ` Hans de Goede
2020-06-08 11:22 ` [PATCH v4 0/7] Support inhibiting input devices Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 1/7] Input: add input_device_enabled() Andrzej Pietrasiewicz
2020-12-03 6:25 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 2/7] Input: use input_device_enabled() Andrzej Pietrasiewicz
2020-12-03 6:26 ` Dmitry Torokhov
[not found] ` <CGME20201207133237eucas1p26f8484944760a14e51dc7353ed33cd28@eucas1p2.samsung.com>
2020-12-07 13:32 ` Marek Szyprowski
2020-12-07 15:50 ` Andrzej Pietrasiewicz
2020-12-08 10:05 ` Marek Szyprowski
2020-12-09 6:37 ` Dmitry Torokhov
2020-12-11 7:09 ` [PATCH] Input: cyapa - do not call input_device_enabled from power mode handler Dmitry Torokhov
2020-12-11 8:22 ` Marek Szyprowski
2020-12-11 8:31 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 3/7] ACPI: button: Access input device's users under appropriate mutex Andrzej Pietrasiewicz
2020-06-24 15:00 ` Rafael J. Wysocki
2020-06-25 5:23 ` Dmitry Torokhov
2020-06-25 10:55 ` Rafael J. Wysocki
2020-10-05 5:08 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 4/7] ACPI: button: Use input_device_enabled() helper Andrzej Pietrasiewicz
2020-06-25 5:24 ` Dmitry Torokhov
2020-10-05 5:06 ` Dmitry Torokhov
2020-06-08 11:22 ` [PATCH v4 5/7] iio: adc: exynos: Use input_device_enabled() Andrzej Pietrasiewicz
2020-06-10 1:28 ` Michał Mirosław
2020-06-10 7:52 ` [FIXED PATCH " Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 6/7] platform/x86: thinkpad_acpi: " Andrzej Pietrasiewicz
2020-06-08 11:22 ` [PATCH v4 7/7] Input: Add "inhibited" property Andrzej Pietrasiewicz
2020-10-05 18:10 ` Dmitry Torokhov
2020-10-06 13:04 ` Andrzej Pietrasiewicz
2020-10-07 1:11 ` Dmitry Torokhov
2020-10-07 1:12 ` Dmitry Torokhov
2020-12-03 6:26 ` Dmitry Torokhov
2020-06-10 9:49 ` [PATCH v4 0/7] Support inhibiting input devices Hans de Goede
2020-06-10 10:38 ` Rafael J. Wysocki
2020-06-10 13:12 ` Andrzej Pietrasiewicz
2020-06-10 13:21 ` Hans de Goede
2020-06-10 13:41 ` Andrzej Pietrasiewicz
2020-06-12 8:30 ` Hans de Goede
2020-06-12 8:47 ` Andrzej Pietrasiewicz
2020-06-16 17:29 ` [PATCH] Input: document inhibiting Andrzej Pietrasiewicz
2020-06-16 17:38 ` Randy Dunlap [this message]
2020-06-17 7:44 ` Hans de Goede
2020-06-17 10:18 ` [PATCH v2] " Andrzej Pietrasiewicz
2020-06-17 10:21 ` Hans de Goede
2020-06-17 16:52 ` Randy Dunlap
2020-06-23 13:35 ` Pavel Machek
2020-12-03 6:27 ` Dmitry Torokhov
2020-06-10 14:01 ` [PATCH v4 0/7] Support inhibiting input devices Rafael J. Wysocki
2020-06-10 13:52 ` Hans de Goede
2020-06-10 18:28 ` Dmitry Torokhov
2020-06-12 8:14 ` Hans de Goede
2020-06-12 8:17 ` Hans de Goede
2020-08-03 14:40 ` Andrzej Pietrasiewicz
2020-06-07 20:24 ` [PATCH v3 " Pavel Machek
2020-06-08 5:37 ` Dmitry Torokhov
2020-06-08 9:28 ` Andrzej Pietrasiewicz
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=d51a16b9-9ebd-1150-7d47-6296dcd2989b@infradead.org \
--to=rdunlap@infradead.org \
--cc=andrzej.p@collabora.com \
--cc=baohua@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=festevam@gmail.com \
--cc=hdegoede@redhat.com \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ibm-acpi@hmh.eng.br \
--cc=jeesw@melfas.com \
--cc=jic23@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kernel@collabora.com \
--cc=kernel@pengutronix.de \
--cc=kgene@kernel.org \
--cc=knaack.h@gmx.de \
--cc=krzk@kernel.org \
--cc=lars@metafoo.de \
--cc=ldewangan@nvidia.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=mirq-linux@rere.qmqm.pl \
--cc=nick@shmanahar.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.hutterer@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=rjw@rjwysocki.net \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=slemieux.tyco@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=vz@mleia.com \
/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).