From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH v2] Input: document inhibiting Date: Tue, 23 Jun 2020 15:35:12 +0200 Message-ID: <20200623133512.GA2783@bug> References: <20200617101822.8558-1-andrzej.p@collabora.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200617101822.8558-1-andrzej.p@collabora.com> Sender: linux-acpi-owner@vger.kernel.org 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 List-Id: linux-tegra@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