From patchwork Wed Jun 17 10:18:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrzej Pietrasiewicz X-Patchwork-Id: 11609563 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8B9D313A0 for ; Wed, 17 Jun 2020 10:18:45 +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 68DA3208B8 for ; Wed, 17 Jun 2020 10:18:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hFEVPqq3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68DA3208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.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-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:References: In-Reply-To:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=TUVjfSm8GkS0CjQJIg7e2KmT16zTW43ECA5e6PQKv2g=; b=hFEVPqq3TjDveFzU2F36z6zglO Bjh09cVqxPc1ymwLXgE3gAwMszVzBrolVcHQE9Io8gawqhwbCzdxEjlFmHb4uB+DoRC6u2L+mttj6 Xr59wa5SJI0pZXF0zFj1P1p0uMpWp1uTlrzDD87qCHjuB2N0DVoVYtIFi5AxxtBUjJc/7HSdyc5BD 1tjTtt+s1Crr5ZOrxX2HaXWx5ZjkCfcNG0HHrXFHz+0zR4ua0i/F/3r5B8AmWe8UZ5+DaoMWWtheq yU/5brtmKlCuu0j3KBxLdztXyqQ3PFg7w2ypUts1pZlYYCoSrm1V5fPo9S3ghG7DRG5C7rQo6Ia0l fBIr5QpA==; 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 1jlV9U-0006Fk-Sk; Wed, 17 Jun 2020 10:18:40 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jlV9O-000670-9L for linux-arm-kernel@lists.infradead.org; Wed, 17 Jun 2020 10:18:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 95B322A395D From: Andrzej Pietrasiewicz To: 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 Subject: [PATCH v2] Input: document inhibiting Date: Wed, 17 Jun 2020 12:18:22 +0200 Message-Id: <20200617101822.8558-1-andrzej.p@collabora.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200617_031834_496602_52BDF04A X-CRM114-Status: GOOD ( 12.44 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.4 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [46.235.227.227 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 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: kernel@collabora.com, Nick Dyer , Laxman Dewangan , Peter Meerwald-Stadler , Peter Hutterer , Fabio Estevam , Lars-Peter Clausen , Krzysztof Kozlowski , Jonathan Hunter , Kukjin Kim , NXP Linux Team , Sylvain Lemieux , Len Brown , Michael Hennerich , Sascha Hauer , Henrique de Moraes Holschuh , Vladimir Zapolskiy , Hans de Goede , =?utf-8?b?TWljaGHFgiBNaXJvc8WCYXc=?= , Barry Song , Dmitry Torokhov , "Rafael J . Wysocki" , Andrzej Pietrasiewicz , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org Document inhibiting input devices and its relation to being a wakeup source. Signed-off-by: Andrzej Pietrasiewicz Reviewed-by: Hans de Goede Reviewed-by: Randy Dunlap --- v1..v2: - Addressed editorial comments from Randy - Added a paragraph by Hans Documentation/input/input-programming.rst | 40 +++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst index 45a4c6e05e39..7432315cc829 100644 --- a/Documentation/input/input-programming.rst +++ b/Documentation/input/input-programming.rst @@ -164,6 +164,46 @@ 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 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. + +Calling the device's close() method on inhibit (if there are users) allows the driver +to save power. Either by directly powering down the device or by releasing the +runtime-pm reference it got in open() when the driver is using runtime-pm. + +Inhibiting and uninhibiting are orthogonal to opening and closing the device by input +handlers. Userspace might want to inhibit a device in anticipation before any handler is +positively matched against it. + +Inhibiting and uninhibiting are orthogonal to device's being a wakeup source, too. Being a +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 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 +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 to provide any wakeup events. The device is going to sleep anyway. + Basic event types ~~~~~~~~~~~~~~~~~