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=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 7F4E2C433E0 for ; Wed, 17 Jun 2020 07:44:55 +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 5072F21475 for ; Wed, 17 Jun 2020 07:44:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Vnd3CQuI"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="E0n7SLeE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5072F21475 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=xwpfpxjGAhR6Tt9ylaYeMKuUA3FGKDW4q4pcZt/CvvQ=; b=Vnd3CQuIV31TYKXodbVkJtRjY rTNHG+FMkTS3FSBndlLsF2WdmQj3T2O0XdGBN9s0iivVZ/nlS0zQ6UtnqUaLeQDtqQSkV/5/FpLen ZN84iLw+QfohwfoQzcwI8DY0r5C3nc4CIxV94nJNfEj8vnLoxMdiH+E9DQS0nNArcvSQO9NZxKOMq Dru33CVy/BWTDfCaMI/vtyHWbSvEu54uW8EOFUvBup4IfXVSBQJFGogi9Cvk7OzdWWk6vQIEzvamE 3ZOfoVhequjuRB79Ahr9I/tJkZVkIBcT0MUAvKq9mylgioMNzInx3UIGKgZ9TpybVZrQJaoEiLK/c MLkPw5cDA==; 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 1jlSkY-0005Wg-JX; Wed, 17 Jun 2020 07:44:46 +0000 Received: from us-smtp-2.mimecast.com ([205.139.110.61] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jlSkV-0005VL-9e for linux-arm-kernel@lists.infradead.org; Wed, 17 Jun 2020 07:44:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592379880; 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=LdQWvEMUJWYJ0ayIlG9RiKefcYkYap4fRHuTq5TItU8=; b=E0n7SLeEUnJIeWiXfh5C7gE/EROJVhAdJvR6bcAak5whHcOTpmJIF0jLf0lkogWa1DzmY+ BNwyBFgkj4YamkhdVk6Dm6DeiRppQk4qA/0XSHYgr6t+iGw+6eOQ33RZeNySouE4w2Pi0v yEhQkuTjMk+ZOuGf6CtQ42SdzRsbzuw= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-504-mGYahv3rNuO2fs3h6hUiEg-1; Wed, 17 Jun 2020 03:44:38 -0400 X-MC-Unique: mGYahv3rNuO2fs3h6hUiEg-1 Received: by mail-ej1-f71.google.com with SMTP id gr26so632438ejb.22 for ; Wed, 17 Jun 2020 00:44:38 -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=LdQWvEMUJWYJ0ayIlG9RiKefcYkYap4fRHuTq5TItU8=; b=R3hRHluJTO45b/89WhH7yCkkEflxJrpkTRZDXiOusNgDqlzkHqoe8mk4mhoTCiQVbW P2Nw71YCThEPpQTE0IHAOzwfxBqmC/DyrvmfhFBfB8sb3d6Lvr7Hh6MwE19GTDWOdkwh aSAZmdTyuz9pKUJzO5qkNg/jMW39CQLr6MQ3R5aqS0S42Re2wxowoARUFKhTPPlmcYch nPMK4srvJSXIcybRPf4r2IEGrHTsEht8ugEzN8zaPB99iSUF4vY1XfnTCnGuZ6tjLF5f njTxKikG6u0+18JgXA/2hHUq0szzKm90MQfxvH7tJCjU8rOg/yjb/NX8fknAbwIZZtLB zOJw== X-Gm-Message-State: AOAM53284oP5ACC0087eWkYDYAcTQFUuWj/XxZshUDLDuCtq+swVmBqz X9OKl0qajHJ7Y4mrl9WA0NiFbqHUJ+YSNpOHHgOXCb2kQIaLtbQYvLsgMnoP4tQQI3vLGZ0cguQ vbonGq3xk2/dMNUM3kbtO7wbuUpvUwXI89qg= X-Received: by 2002:a17:906:e47:: with SMTP id q7mr6349229eji.279.1592379877129; Wed, 17 Jun 2020 00:44:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztAsLsgDaFxPRHVMxQyWpwuzemyHiIKlOYzD7aKaYp8CK5bsLlyAMtEHuAjaMc+cKU/OAdZw== X-Received: by 2002:a17:906:e47:: with SMTP id q7mr6349200eji.279.1592379876894; Wed, 17 Jun 2020 00:44:36 -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 i12sm12619661ejz.122.2020.06.17.00.44.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2020 00:44:36 -0700 (PDT) Subject: Re: [PATCH] Input: document inhibiting To: Andrzej Pietrasiewicz , 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 References: <40988408-8f36-3a52-6439-34084de6b129@redhat.com> <20200616172909.21625-1-andrzej.p@collabora.com> From: Hans de Goede Message-ID: Date: Wed, 17 Jun 2020 09:44:34 +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: <20200616172909.21625-1-andrzej.p@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-20200617_004443_411752_C2253111 X-CRM114-Status: GOOD ( 26.84 ) 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 , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Barry Song , Dmitry Torokhov , "Rafael J . Wysocki" , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 6/16/20 7:29 PM, Andrzej Pietrasiewicz wrote: > Document inhibiting input devices and its relation to being > a wakeup source. > > Signed-off-by: Andrzej Pietrasiewicz > --- > > @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. Maybe add the following here? : 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. Otherwise this looks good to me. Thank you for doing this, we (including myself) really need to get better at doucmenting all sorts of kernel things. Often we have these long discussions about something on the mailinglist and then everyone is expected to just know what was decided from the on, which really doesn't work all that well. > + > +Inhibiting and uninhibiting is 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 is 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 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 > +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 > ~~~~~~~~~~~~~~~~~ > > Regards, Hans _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel