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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,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 718B4C433E0 for ; Tue, 19 May 2020 09:03:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BF2B2088E for ; Tue, 19 May 2020 09:03:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728477AbgESJDK (ORCPT ); Tue, 19 May 2020 05:03:10 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:49894 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726333AbgESJDI (ORCPT ); Tue, 19 May 2020 05:03:08 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 7A8D02A1ED2 Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Hans de Goede , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@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" , 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 , Ferruh Yigit , Sangwon Jee , Henrique de Moraes Holschuh , kernel@collabora.com, Peter Hutterer , Benjamin Tissoires References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <6d9921fc-5c2f-beda-4dcd-66d6970a22fe@redhat.com> <09679de4-75d3-1f29-ec5f-8d42c84273dd@collabora.com> From: Andrzej Pietrasiewicz Message-ID: <2d224833-3a7e-bc7c-af15-1f803f466697@collabora.com> Date: Tue, 19 May 2020 11:02:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org Hi Hans, Hi Dmitry, W dniu 18.05.2020 o 16:23, Hans de Goede pisze: > Hi, >>>>> >>>>> So I wonder what this series actually adds for functionality for >>>>> userspace which can not already be achieved this way? >>>>> >>>>> I also noticed that you keep the device open (do not call the >>>>> input_device's close callback) when inhibited and just throw away >>>> >>>> I'm not sure if I understand you correctly, it is called: >>>> >>>> +static inline void input_stop(struct input_dev *dev) >>>> +{ >>>> +    if (dev->poller) >>>> +        input_dev_poller_stop(dev->poller); >>>> +    if (dev->close) >>>> +        dev->close(dev); >>>>                  ^^^^^^^^^^^^^^^^ >>>> +static int input_inhibit(struct input_dev *dev) >>>> +{ >>>> +    int ret = 0; >>>> + >>>> +    mutex_lock(&dev->mutex); >>>> + >>>> +    if (dev->inhibited) >>>> +        goto out; >>>> + >>>> +    if (dev->users) { >>>> +        if (dev->inhibit) { >>>> +            ret = dev->inhibit(dev); >>>> +            if (ret) >>>> +                goto out; >>>> +        } >>>> +        input_stop(dev); >>>>                  ^^^^^^^^^^^^^^^^ >>>> >>>> It will not be called when dev->users is zero, but if it is zero, >>>> then nobody has opened the device yet so there is nothing to close. >>> >>> Ah, I missed that. >>> >>> So if the device implements the inhibit call back then on >>> inhibit it will get both the inhibit and close callback called? >>> >> >> That's right. And conversely, upon uninhibit open() and uninhibit() >> callbacks will be invoked. Please note that just as with open()/close(), >> providing inhibit()/uninhibit() is optional. > > Ack. > >>> And what happens if the last user goes away and the device >>> is not inhibited? >> >> close() is called as usually. > > But not inhibit, hmm, see below. > >>> I'm trying to understand here what the difference between the 2 >>> is / what the goal of having a separate inhibit callback ? >>> >> >> Drivers have very different ideas about what it means to suspend/resume >> and open/close. The optional inhibit/uninhibit callbacks are meant for >> the drivers to know that it is this particular action going on. > > So the inhibit() callback triggers the "suspend" behavior ? > But shouldn't drivers which are capable of suspending the device > always do so on close() ? > > Since your current proposal also calls close() on inhibit() I > really see little difference between an inhibit() and the last > user of the device closing it and IMHO unless there is a good > reason to actually differentiate the 2 it would be better > to only stick with the existing close() and in cases where > that does not put the device in a low-power mode yet, fix > the existing close() callback to do the low-power mode > setting instead of adding a new callback. > >> For inhibit() there's one more argument: close() does not return a value, >> so its meaning is "do some last cleanup" and as such it is not allowed >> to fail - whatever its effect is, we must deem it successful. inhibit() >> does return a value and so it is allowed to fail. > > Well, we could make close() return an error and at least in the inhibit() > case propagate that to userspace. I wonder if userspace is going to > do anything useful with that error though... > > In my experience errors during cleanup/shutdown are best logged > (using dev_err) and otherwise ignored, so that we try to clean up > as much possible. Unless the very first step of the shutdown process > fails the device is going to be in some twilight zone state anyways > at this point we might as well try to cleanup as much as possible. What you say makes sense to me. @Dmitry? > >> All in all, it is up to the drivers to decide which callback they >> provide. Based on my work so far I would say that there are tens >> of simple cases where open() and close() are sufficient, out of total >> ~400 users of input_allocate_device(): >> >> $ git grep "input_allocate_device(" | grep -v ^Documentation | \ >> cut -f1 -d: | sort | uniq | wc >>      390     390   13496 > > So can you explain a bit more about the cases where only having > open/close is not sufficient?  So far I have the feeling that > those are all we need and that we really do not need separate > [un]inhibit callbacks. My primary concern was not being able to propagate inhibit() error to userspace, and then if we have inhibit(), uninhibit() should be there for completeness. If propagating the error to userspace can be neglected then yes, it seems open/close should be sufficient, even more because the real meaning of "open" is "prepare the device for generating input events". To validate the idea of not introducing inhibit()/uninhibit() callbacks to implement device inhibiting/uninhibiting let's look at drivers/input/mouse/elan_i2c_core.c (PATCH 7/7): static int elan_inhibit(struct input_dev *input) { [...] ret = mutex_lock_interruptible(&data->sysfs_mutex); if (ret) return ret; disable_irq(client->irq); ret = elan_disable_power(data); if (ret) enable_irq(client->irq); [...] } First, close() does not exist in this driver. Of course this can be fixed. Then it doesn't return a value. Then, if either taking the mutex or disabling the power fails, the close() is still deemed successful. Is it ok? @Dmitry? Regards, Andrzej