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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 2559FC433E0 for ; Tue, 23 Jun 2020 13:35:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B62E20724 for ; Tue, 23 Jun 2020 13:35:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732681AbgFWNfW (ORCPT ); Tue, 23 Jun 2020 09:35:22 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:59518 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732616AbgFWNfW (ORCPT ); Tue, 23 Jun 2020 09:35:22 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 5FFD01C0C0A; Tue, 23 Jun 2020 15:35:19 +0200 (CEST) Date: Tue, 23 Jun 2020 15:35:12 +0200 From: Pavel Machek To: Andrzej Pietrasiewicz Cc: 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, "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 , Hans de Goede , Sangwon Jee , Peter Hutterer , Henrique de Moraes Holschuh , Micha?? Miros??aw , kernel@collabora.com Subject: Re: [PATCH v2] Input: document inhibiting Message-ID: <20200623133512.GA2783@bug> References: <20200617101822.8558-1-andrzej.p@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617101822.8558-1-andrzej.p@collabora.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org Hi! > +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. Ok. > +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 I don't believe making interaction driver-specific is good idea. We should decide what reasonable behaviour is and then make drivers implement that... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html