From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Pietrasiewicz Subject: Re: [PATCHv2 0/7] Support inhibiting input devices Date: Wed, 3 Jun 2020 15:07:29 +0200 Message-ID: References: <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> <2d224833-3a7e-bc7c-af15-1f803f466697@collabora.com> <20200527063430.GJ89269@dtor-ws> <88f939cd-1518-d516-59f2-8f627a6a70d2@collabora.com> <20200602175241.GO89269@dtor-ws> <82e9f2ab-a16e-51ee-1413-bedf0122026a@collabora.com> <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <8f97d2e1-497a-495d-bc82-f46dbeba440c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Content-Language: en-US Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Hans de Goede , Dmitry Torokhov Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, patches-yzvPICuk2AA4QjBA90+/kJqQE7yCjDx5@public.gmane.org, ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Rafael J . Wysocki" , Len Brown , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Kukjin Kim , Krzysztof Kozlowski , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP List-Id: linux-tegra@vger.kernel.org Hi Hans, hi Dmitry, W dniu 02.06.2020 o 22:19, Hans de Goede pisze: > Hi, > > On 6/2/20 8:50 PM, Andrzej Pietrasiewicz wrote: >> Hi Dmitry, >> >> W dniu 02.06.2020 o 19:52, Dmitry Torokhov pisze: >>> Hi Andrzej, >>> >>> On Tue, Jun 02, 2020 at 06:56:40PM +0200, Andrzej Pietrasiewicz wrote: >>>> Hi Dmitry, >>>> >>>> W dniu 27.05.2020 o 08:34, Dmitry Torokhov pisze: >>>>> That said, I think the way we should handle inhibit/uninhibit, is that >>>>> if we have the callback defined, then we call it, and only call open and >>>>> close if uninhibit or inhibit are _not_ defined. >>>>> >>>> >>>> If I understand you correctly you suggest to call either inhibit, >>>> if provided or close, if inhibit is not provided, but not both, >>>> that is, if both are provided then on the inhibit path only >>>> inhibit is called. And, consequently, you suggest to call either >>>> uninhibit or open, but not both. The rest of my mail makes this >>>> assumption, so kindly confirm if I understand you correctly. >>> >>> Yes, that is correct. If a driver wants really fine-grained control, it >>> will provide inhibit (or both inhibit and close), otherwise it will rely >>> on close in place of inhibit. >>> >>>> >>>> In my opinion this idea will not work. >>>> >>>> The first question is should we be able to inhibit a device >>>> which is not opened? In my opinion we should, in order to be >>>> able to inhibit a device in anticipation without needing to >>>> open it first. >>> >>> I agree. >>> >>>> >>>> Then what does opening (with input_open_device()) an inhibited >>>> device mean? Should it succeed or should it fail? >>> >>> It should succeed. >>> >>>> If it is not >>>> the first opening then effectively it boils down to increasing >>>> device's and handle's counters, so we can allow it to succeed. >>>> If, however, the device is being opened for the first time, >>>> the ->open() method wants to be called, but that somehow >>>> contradicts the device's inhibited state. So a logical thing >>>> to do is to either fail input_open_device() or postpone ->open() >>>> invocation to the moment of uninhibiting - and the latter is >>>> what the patches in this series currently do. >>>> >>>> Failing input_open_device() because of the inhibited state is >>>> not the right thing to do. Let me explain. Suppose that a device >>>> is already inhibited and then a new matching handler appears >>>> in the system. Most handlers (apm-power.c, evbug.c, input-leds.c, >>>> mac_hid.c, sysrq.c, vt/keyboard.c and rfkill/input.c) don't create >>>> any character devices (only evdev.c, joydev.c and mousedev.c do), >>>> so for them it makes no sense to delay calling input_open_device() >>>> and it is called in handler's ->connect(). If input_open_device() >>>> now fails, we have lost the only chance for this ->connect() to >>>> succeed. >>>> >>>> Summarizing, IMO the uninhibit path should be calling both >>>> ->open() and ->uninhibit() (if provided), and conversely, the inhibit >>>> path should be calling both ->inhibit() and ->close() (if provided). >>> >>> So what you are trying to say is that you see inhibit as something that >>> is done in addition to what happens in close. But what exactly do you >>> want to do in inhibit, in addition to what close is doing? >> >> See below (*). >> >>> >>> In my view, if we want to have a dedicated inhibit callback, then it >>> will do everything that close does, they both are aware of each other >>> and can sort out the state transitions between them. For drivers that do >>> not have dedicated inhibit/uninhibit, we can use open and close >>> handlers, and have input core sort out when each should be called. That >>> means that we should not call dev->open() in input_open_device() when >>> device is inhibited (and same for dev->close() in input_close_device). >>> And when uninhibiting, we should not call dev->open() when there are no >>> users for the device, and no dev->close() when inhibiting with no users. >>> >>> Do you see any problems with this approach? >> >> My concern is that if e.g. both ->open() and ->uninhibit() are provided, >> then in certain circumstances ->open() won't be called: >> >> 1. users == 0 >> 2. inhibit happens >> 3. input_open_device() happens, ->open() not called >> 4. uninhibit happens >> 5. as part of uninhibit ->uninhibit() is only called, but ->open() is not. >> >> They way I understand your answer is that we implicitly impose requirements >> on drivers which choose to implement e.g. both ->open() and ->uninhibit(): >> in such a case ->uninhibit() should be doing exactly the same things as >> ->open() does. Which leads to a conclusion that in practice no drivers >> should choose to implement both, otherwise they must be aware that >> ->uninhibit() can be sometimes called instead of ->open(). Then ->open() >> becomes synonymous with ->uninhibit(), and ->close() with ->inhibit(). >> Or, maybe, then ->inhibit() can be a superset of ->close() and >> ->uninhibit() a superset of ->open(). >> >> If such an approach is ok with you, it is ok with me, too. >> >> (*) >> Calling both ->inhibit() and ->close() (if they are provided) allows >> drivers to go fancy and fail inhibiting (which is impossible using >> only ->close() as it does not return a value, but ->inhibit() by design >> does). Then ->uninhibit() is mostly for symmetry. > > All the complications discussed above are exactly why I still > believe that there should be only open and close. > > If error propagation on inhibit is considered as something > really important to have then we can make the input driver close > callback return an error (*), note I'm talking about the > driver close callback here, not the system call. > > If the close callback is called for actually closing the fd > referring to the input node, then the new error return code > can be ignored, as we already do for errors on close atm > since the driver close callback returns void. > > I still have not seen a very convincing argument for having > separate inhibit and close callbacks and as the messy discussion > above shows, having 2 such very similar yet subtly different > calls seems like a bad idea... > > Regards, > > Hans > > > *) This will require a flag day where "return 0" is added > to all current close handlers > I'm taking one step back and looking at the ->open() and ->close() driver callbacks. They are called from input_open_device() and input_close_device(), respectively: input_open_device(): "This function should be called by input handlers when they want to start receive events from given input device." ->open() callback: "this method is called when the very first user calls input_open_device(). The driver must prepare the device to start generating events (start polling thread, request an IRQ, submit URB, etc.)" input_close_device(): "This function should be called by input handlers when they want to stop receive events from given input device." ->close() callback: "this method is called when the very last user calls input_close_device()" It seems to me that the callback names do not reflect their purpose: their meaning is not to "open" or to "close" but to give drivers a chance to control when they start or stop providing events to the input core. What would you say about changing the callbacks' names? I'd envsion: ->provide_events() instead of ->open() and ->stop_events() instead of ->close(). Of course drivers can exploit the fact of knowing that nobody wants any events from them and do whatever they consider appropriate, for example go into a low power mode - but the latter is beyond the scope of the input subsystem and is driver-specific. With such a naming change in mind let's consider inhibiting. We want to be able to control when to disregard events from a given device. It makes sense to do it at device level, otherwise such an operation would have to be invoked in all associated handlers (those that have an open handle associating them with the device in question). But of course we can do better than merely ignoring the events received: we can tell the drivers that we don't want any events from them, and later, at uninhibit time, tell them to start providing the events again. Conceptually, the two operations (provide or don't provide envents) are exactly the same thing we want to be happening at input_open_device() and input_close_device() time. To me, changing the names of ->open() and ->close() exposes this fact very well. Consequently, ->inhibit() and ->uninhibit() won't be needed, and drivers which already implement ->provide_events() (formerly ->open()) and ->stop_events() (formerly ->close()) will receive full inhibit/uninhibit support for free (subject to how well they implement ->provide_events()/->stop_events()). Unless we can come up with what the drivers might be doing on top of ->stop_events() and ->provide_events() when inhibiting/uninhibiting, but it seems to me we can't. Can we? Optionally ->close() (only the callback, not input_close_device()) can be made return a value, just as Hans suggests. The value can be ignored in input_close_device() but used in input_inhibit(). No strong opinion here, though. (btw it seems to me that input_inhibit() should be renamed to input_inhibit_device()). Regards, Andrzej 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.2 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 63525C433E2 for ; Wed, 3 Jun 2020 13:07:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CB7920738 for ; Wed, 3 Jun 2020 13:07:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725936AbgFCNHi (ORCPT ); Wed, 3 Jun 2020 09:07:38 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:38064 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725854AbgFCNHh (ORCPT ); Wed, 3 Jun 2020 09:07:37 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 6958A2A3C84 Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Hans de Goede , Dmitry Torokhov Cc: 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, "Rafael J . Wysocki" , Len Brown , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Kukjin Kim , Krzysztof Kozlowski , 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: <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> <2d224833-3a7e-bc7c-af15-1f803f466697@collabora.com> <20200527063430.GJ89269@dtor-ws> <88f939cd-1518-d516-59f2-8f627a6a70d2@collabora.com> <20200602175241.GO89269@dtor-ws> <82e9f2ab-a16e-51ee-1413-bedf0122026a@collabora.com> <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com> From: Andrzej Pietrasiewicz Message-ID: Date: Wed, 3 Jun 2020 15:07:29 +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: <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Hans, hi Dmitry, W dniu 02.06.2020 o 22:19, Hans de Goede pisze: > Hi, > > On 6/2/20 8:50 PM, Andrzej Pietrasiewicz wrote: >> Hi Dmitry, >> >> W dniu 02.06.2020 o 19:52, Dmitry Torokhov pisze: >>> Hi Andrzej, >>> >>> On Tue, Jun 02, 2020 at 06:56:40PM +0200, Andrzej Pietrasiewicz wrote: >>>> Hi Dmitry, >>>> >>>> W dniu 27.05.2020 o 08:34, Dmitry Torokhov pisze: >>>>> That said, I think the way we should handle inhibit/uninhibit, is that >>>>> if we have the callback defined, then we call it, and only call open and >>>>> close if uninhibit or inhibit are _not_ defined. >>>>> >>>> >>>> If I understand you correctly you suggest to call either inhibit, >>>> if provided or close, if inhibit is not provided, but not both, >>>> that is, if both are provided then on the inhibit path only >>>> inhibit is called. And, consequently, you suggest to call either >>>> uninhibit or open, but not both. The rest of my mail makes this >>>> assumption, so kindly confirm if I understand you correctly. >>> >>> Yes, that is correct. If a driver wants really fine-grained control, it >>> will provide inhibit (or both inhibit and close), otherwise it will rely >>> on close in place of inhibit. >>> >>>> >>>> In my opinion this idea will not work. >>>> >>>> The first question is should we be able to inhibit a device >>>> which is not opened? In my opinion we should, in order to be >>>> able to inhibit a device in anticipation without needing to >>>> open it first. >>> >>> I agree. >>> >>>> >>>> Then what does opening (with input_open_device()) an inhibited >>>> device mean? Should it succeed or should it fail? >>> >>> It should succeed. >>> >>>> If it is not >>>> the first opening then effectively it boils down to increasing >>>> device's and handle's counters, so we can allow it to succeed. >>>> If, however, the device is being opened for the first time, >>>> the ->open() method wants to be called, but that somehow >>>> contradicts the device's inhibited state. So a logical thing >>>> to do is to either fail input_open_device() or postpone ->open() >>>> invocation to the moment of uninhibiting - and the latter is >>>> what the patches in this series currently do. >>>> >>>> Failing input_open_device() because of the inhibited state is >>>> not the right thing to do. Let me explain. Suppose that a device >>>> is already inhibited and then a new matching handler appears >>>> in the system. Most handlers (apm-power.c, evbug.c, input-leds.c, >>>> mac_hid.c, sysrq.c, vt/keyboard.c and rfkill/input.c) don't create >>>> any character devices (only evdev.c, joydev.c and mousedev.c do), >>>> so for them it makes no sense to delay calling input_open_device() >>>> and it is called in handler's ->connect(). If input_open_device() >>>> now fails, we have lost the only chance for this ->connect() to >>>> succeed. >>>> >>>> Summarizing, IMO the uninhibit path should be calling both >>>> ->open() and ->uninhibit() (if provided), and conversely, the inhibit >>>> path should be calling both ->inhibit() and ->close() (if provided). >>> >>> So what you are trying to say is that you see inhibit as something that >>> is done in addition to what happens in close. But what exactly do you >>> want to do in inhibit, in addition to what close is doing? >> >> See below (*). >> >>> >>> In my view, if we want to have a dedicated inhibit callback, then it >>> will do everything that close does, they both are aware of each other >>> and can sort out the state transitions between them. For drivers that do >>> not have dedicated inhibit/uninhibit, we can use open and close >>> handlers, and have input core sort out when each should be called. That >>> means that we should not call dev->open() in input_open_device() when >>> device is inhibited (and same for dev->close() in input_close_device). >>> And when uninhibiting, we should not call dev->open() when there are no >>> users for the device, and no dev->close() when inhibiting with no users. >>> >>> Do you see any problems with this approach? >> >> My concern is that if e.g. both ->open() and ->uninhibit() are provided, >> then in certain circumstances ->open() won't be called: >> >> 1. users == 0 >> 2. inhibit happens >> 3. input_open_device() happens, ->open() not called >> 4. uninhibit happens >> 5. as part of uninhibit ->uninhibit() is only called, but ->open() is not. >> >> They way I understand your answer is that we implicitly impose requirements >> on drivers which choose to implement e.g. both ->open() and ->uninhibit(): >> in such a case ->uninhibit() should be doing exactly the same things as >> ->open() does. Which leads to a conclusion that in practice no drivers >> should choose to implement both, otherwise they must be aware that >> ->uninhibit() can be sometimes called instead of ->open(). Then ->open() >> becomes synonymous with ->uninhibit(), and ->close() with ->inhibit(). >> Or, maybe, then ->inhibit() can be a superset of ->close() and >> ->uninhibit() a superset of ->open(). >> >> If such an approach is ok with you, it is ok with me, too. >> >> (*) >> Calling both ->inhibit() and ->close() (if they are provided) allows >> drivers to go fancy and fail inhibiting (which is impossible using >> only ->close() as it does not return a value, but ->inhibit() by design >> does). Then ->uninhibit() is mostly for symmetry. > > All the complications discussed above are exactly why I still > believe that there should be only open and close. > > If error propagation on inhibit is considered as something > really important to have then we can make the input driver close > callback return an error (*), note I'm talking about the > driver close callback here, not the system call. > > If the close callback is called for actually closing the fd > referring to the input node, then the new error return code > can be ignored, as we already do for errors on close atm > since the driver close callback returns void. > > I still have not seen a very convincing argument for having > separate inhibit and close callbacks and as the messy discussion > above shows, having 2 such very similar yet subtly different > calls seems like a bad idea... > > Regards, > > Hans > > > *) This will require a flag day where "return 0" is added > to all current close handlers > I'm taking one step back and looking at the ->open() and ->close() driver callbacks. They are called from input_open_device() and input_close_device(), respectively: input_open_device(): "This function should be called by input handlers when they want to start receive events from given input device." ->open() callback: "this method is called when the very first user calls input_open_device(). The driver must prepare the device to start generating events (start polling thread, request an IRQ, submit URB, etc.)" input_close_device(): "This function should be called by input handlers when they want to stop receive events from given input device." ->close() callback: "this method is called when the very last user calls input_close_device()" It seems to me that the callback names do not reflect their purpose: their meaning is not to "open" or to "close" but to give drivers a chance to control when they start or stop providing events to the input core. What would you say about changing the callbacks' names? I'd envsion: ->provide_events() instead of ->open() and ->stop_events() instead of ->close(). Of course drivers can exploit the fact of knowing that nobody wants any events from them and do whatever they consider appropriate, for example go into a low power mode - but the latter is beyond the scope of the input subsystem and is driver-specific. With such a naming change in mind let's consider inhibiting. We want to be able to control when to disregard events from a given device. It makes sense to do it at device level, otherwise such an operation would have to be invoked in all associated handlers (those that have an open handle associating them with the device in question). But of course we can do better than merely ignoring the events received: we can tell the drivers that we don't want any events from them, and later, at uninhibit time, tell them to start providing the events again. Conceptually, the two operations (provide or don't provide envents) are exactly the same thing we want to be happening at input_open_device() and input_close_device() time. To me, changing the names of ->open() and ->close() exposes this fact very well. Consequently, ->inhibit() and ->uninhibit() won't be needed, and drivers which already implement ->provide_events() (formerly ->open()) and ->stop_events() (formerly ->close()) will receive full inhibit/uninhibit support for free (subject to how well they implement ->provide_events()/->stop_events()). Unless we can come up with what the drivers might be doing on top of ->stop_events() and ->provide_events() when inhibiting/uninhibiting, but it seems to me we can't. Can we? Optionally ->close() (only the callback, not input_close_device()) can be made return a value, just as Hans suggests. The value can be ignored in input_close_device() but used in input_inhibit(). No strong opinion here, though. (btw it seems to me that input_inhibit() should be renamed to input_inhibit_device()). Regards, Andrzej 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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,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 28FFBC433E3 for ; Wed, 3 Jun 2020 13:07:40 +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 F1BBC20679 for ; Wed, 3 Jun 2020 13:07:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vCNZCQtR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1BBC20679 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+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=KuHUIYuy5bv7Bw2y2wrGUDVcdI/9goGLRDC/5uV21as=; b=vCNZCQtRgel2ysBnWrQtdJoK2 Z4yKgCYWHENZ6jmxY3LtG4yb+ljJHZos0lGhEHuegFjDfLz3M4wy4NpxbzVWOJuZpMPha2zMKFXfL syKTvMDihmXvCsIzgvODahYjmWrHNgnEMXW9gsqywCDqcG02zfW9IpMi32BHLyGU7sUpLcr4Qg8Tz Qhxjn0+LVDXCyc9ym+DzDSp4sgsLtbtfXGrqUk2IDp+//OEAPep0olFrohsgEqZlMG5oH1RFRKeQs Gmg1nb+FL/xkLOgb5LkM2OCM1W7HZTQLX4/gbussbP0jgI1cU/PAJwkZXxUnaOFx0UyS3dKyrhsez i4GX4bsbg==; 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 1jgT7L-000851-KC; Wed, 03 Jun 2020 13:07:39 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgT7H-00084P-KG for linux-arm-kernel@lists.infradead.org; Wed, 03 Jun 2020 13:07:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 6958A2A3C84 Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Hans de Goede , Dmitry Torokhov References: <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> <2d224833-3a7e-bc7c-af15-1f803f466697@collabora.com> <20200527063430.GJ89269@dtor-ws> <88f939cd-1518-d516-59f2-8f627a6a70d2@collabora.com> <20200602175241.GO89269@dtor-ws> <82e9f2ab-a16e-51ee-1413-bedf0122026a@collabora.com> <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com> From: Andrzej Pietrasiewicz Message-ID: Date: Wed, 3 Jun 2020 15:07:29 +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: <8f97d2e1-497a-495d-bc82-f46dbeba440c@redhat.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200603_060735_932052_7BF7D691 X-CRM114-Status: GOOD ( 32.95 ) 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: Nick Dyer , linux-iio@vger.kernel.org, Benjamin Tissoires , platform-driver-x86@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, Laxman Dewangan , Peter Meerwald-Stadler , kernel@collabora.com, Fabio Estevam , linux-samsung-soc@vger.kernel.org, Krzysztof Kozlowski , Jonathan Hunter , linux-acpi@vger.kernel.org, Kukjin Kim , NXP Linux Team , linux-input@vger.kernel.org, Len Brown , Peter Hutterer , Michael Hennerich , Sascha Hauer , Sylvain Lemieux , Henrique de Moraes Holschuh , Vladimir Zapolskiy , Lars-Peter Clausen , linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Barry Song , Ferruh Yigit , patches@opensource.cirrus.com, "Rafael J . Wysocki" , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgSGFucywgaGkgRG1pdHJ5LAoKVyBkbml1IDAyLjA2LjIwMjAgb8KgMjI6MTksIEhhbnMgZGUg R29lZGUgcGlzemU6Cj4gSGksCj4gCj4gT24gNi8yLzIwIDg6NTAgUE0sIEFuZHJ6ZWogUGlldHJh c2lld2ljeiB3cm90ZToKPj4gSGkgRG1pdHJ5LAo+Pgo+PiBXIGRuaXUgMDIuMDYuMjAyMCBvwqAx OTo1MiwgRG1pdHJ5IFRvcm9raG92IHBpc3plOgo+Pj4gSGkgQW5kcnplaiwKPj4+Cj4+PiBPbiBU dWUsIEp1biAwMiwgMjAyMCBhdCAwNjo1Njo0MFBNICswMjAwLCBBbmRyemVqIFBpZXRyYXNpZXdp Y3ogd3JvdGU6Cj4+Pj4gSGkgRG1pdHJ5LAo+Pj4+Cj4+Pj4gVyBkbml1IDI3LjA1LjIwMjAgb8Kg MDg6MzQsIERtaXRyeSBUb3Jva2hvdiBwaXN6ZToKPj4+Pj4gVGhhdCBzYWlkLCBJIHRoaW5rIHRo ZSB3YXkgd2Ugc2hvdWxkIGhhbmRsZSBpbmhpYml0L3VuaW5oaWJpdCwgaXMgdGhhdAo+Pj4+PiBp ZiB3ZSBoYXZlIHRoZSBjYWxsYmFjayBkZWZpbmVkLCB0aGVuIHdlIGNhbGwgaXQsIGFuZCBvbmx5 IGNhbGwgb3BlbiBhbmQKPj4+Pj4gY2xvc2UgaWYgdW5pbmhpYml0IG9yIGluaGliaXQgYXJlIF9u b3RfIGRlZmluZWQuCj4+Pj4+Cj4+Pj4KPj4+PiBJZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3Rs eSB5b3Ugc3VnZ2VzdCB0byBjYWxsIGVpdGhlciBpbmhpYml0LAo+Pj4+IGlmIHByb3ZpZGVkIG9y IGNsb3NlLCBpZiBpbmhpYml0IGlzIG5vdCBwcm92aWRlZCwgYnV0IG5vdCBib3RoLAo+Pj4+IHRo YXQgaXMsIGlmIGJvdGggYXJlIHByb3ZpZGVkIHRoZW4gb24gdGhlIGluaGliaXQgcGF0aCBvbmx5 Cj4+Pj4gaW5oaWJpdCBpcyBjYWxsZWQuIEFuZCwgY29uc2VxdWVudGx5LCB5b3Ugc3VnZ2VzdCB0 byBjYWxsIGVpdGhlcgo+Pj4+IHVuaW5oaWJpdCBvciBvcGVuLCBidXQgbm90IGJvdGguIFRoZSBy ZXN0IG9mIG15IG1haWwgbWFrZXMgdGhpcwo+Pj4+IGFzc3VtcHRpb24sIHNvIGtpbmRseSBjb25m aXJtIGlmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5Lgo+Pj4KPj4+IFllcywgdGhhdCBpcyBj b3JyZWN0LiBJZiBhIGRyaXZlciB3YW50cyByZWFsbHkgZmluZS1ncmFpbmVkIGNvbnRyb2wsIGl0 Cj4+PiB3aWxsIHByb3ZpZGUgaW5oaWJpdCAob3IgYm90aCBpbmhpYml0IGFuZCBjbG9zZSksIG90 aGVyd2lzZSBpdCB3aWxsIHJlbHkKPj4+IG9uIGNsb3NlIGluIHBsYWNlIG9mIGluaGliaXQuCj4+ Pgo+Pj4+Cj4+Pj4gSW4gbXkgb3BpbmlvbiB0aGlzIGlkZWEgd2lsbCBub3Qgd29yay4KPj4+Pgo+ Pj4+IFRoZSBmaXJzdCBxdWVzdGlvbiBpcyBzaG91bGQgd2UgYmUgYWJsZSB0byBpbmhpYml0IGEg ZGV2aWNlCj4+Pj4gd2hpY2ggaXMgbm90IG9wZW5lZD8gSW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQs IGluIG9yZGVyIHRvIGJlCj4+Pj4gYWJsZSB0byBpbmhpYml0IGEgZGV2aWNlIGluIGFudGljaXBh dGlvbiB3aXRob3V0IG5lZWRpbmcgdG8KPj4+PiBvcGVuIGl0IGZpcnN0Lgo+Pj4KPj4+IEkgYWdy ZWUuCj4+Pgo+Pj4+Cj4+Pj4gVGhlbiB3aGF0IGRvZXMgb3BlbmluZyAod2l0aCBpbnB1dF9vcGVu X2RldmljZSgpKSBhbiBpbmhpYml0ZWQKPj4+PiBkZXZpY2UgbWVhbj8gU2hvdWxkIGl0IHN1Y2Nl ZWQgb3Igc2hvdWxkIGl0IGZhaWw/Cj4+Pgo+Pj4gSXQgc2hvdWxkIHN1Y2NlZWQuCj4+Pgo+Pj4+ IElmIGl0IGlzIG5vdAo+Pj4+IHRoZSBmaXJzdCBvcGVuaW5nIHRoZW4gZWZmZWN0aXZlbHkgaXQg Ym9pbHMgZG93biB0byBpbmNyZWFzaW5nCj4+Pj4gZGV2aWNlJ3MgYW5kIGhhbmRsZSdzIGNvdW50 ZXJzLCBzbyB3ZSBjYW4gYWxsb3cgaXQgdG8gc3VjY2VlZC4KPj4+PiBJZiwgaG93ZXZlciwgdGhl IGRldmljZSBpcyBiZWluZyBvcGVuZWQgZm9yIHRoZSBmaXJzdCB0aW1lLAo+Pj4+IHRoZSAtPm9w ZW4oKSBtZXRob2Qgd2FudHMgdG8gYmUgY2FsbGVkLCBidXQgdGhhdCBzb21laG93Cj4+Pj4gY29u dHJhZGljdHMgdGhlIGRldmljZSdzIGluaGliaXRlZCBzdGF0ZS4gU28gYSBsb2dpY2FsIHRoaW5n Cj4+Pj4gdG8gZG8gaXMgdG8gZWl0aGVyIGZhaWwgaW5wdXRfb3Blbl9kZXZpY2UoKSBvciBwb3N0 cG9uZSAtPm9wZW4oKQo+Pj4+IGludm9jYXRpb24gdG8gdGhlIG1vbWVudCBvZiB1bmluaGliaXRp bmcgLSBhbmQgdGhlIGxhdHRlciBpcwo+Pj4+IHdoYXQgdGhlIHBhdGNoZXMgaW4gdGhpcyBzZXJp ZXMgY3VycmVudGx5IGRvLgo+Pj4+Cj4+Pj4gRmFpbGluZyBpbnB1dF9vcGVuX2RldmljZSgpIGJl Y2F1c2Ugb2YgdGhlIGluaGliaXRlZCBzdGF0ZSBpcwo+Pj4+IG5vdCB0aGUgcmlnaHQgdGhpbmcg dG8gZG8uIExldCBtZSBleHBsYWluLiBTdXBwb3NlIHRoYXQgYSBkZXZpY2UKPj4+PiBpcyBhbHJl YWR5IGluaGliaXRlZCBhbmQgdGhlbiBhIG5ldyBtYXRjaGluZyBoYW5kbGVyIGFwcGVhcnMKPj4+ PiBpbiB0aGUgc3lzdGVtLiBNb3N0IGhhbmRsZXJzIChhcG0tcG93ZXIuYywgZXZidWcuYywgaW5w dXQtbGVkcy5jLAo+Pj4+IG1hY19oaWQuYywgc3lzcnEuYywgdnQva2V5Ym9hcmQuYyBhbmQgcmZr aWxsL2lucHV0LmMpIGRvbid0IGNyZWF0ZQo+Pj4+IGFueSBjaGFyYWN0ZXIgZGV2aWNlcyAob25s eSBldmRldi5jLCBqb3lkZXYuYyBhbmQgbW91c2VkZXYuYyBkbyksCj4+Pj4gc28gZm9yIHRoZW0g aXQgbWFrZXMgbm8gc2Vuc2UgdG8gZGVsYXkgY2FsbGluZyBpbnB1dF9vcGVuX2RldmljZSgpCj4+ Pj4gYW5kIGl0IGlzIGNhbGxlZCBpbiBoYW5kbGVyJ3MgLT5jb25uZWN0KCkuIElmIGlucHV0X29w ZW5fZGV2aWNlKCkKPj4+PiBub3cgZmFpbHMsIHdlIGhhdmUgbG9zdCB0aGUgb25seSBjaGFuY2Ug Zm9yIHRoaXMgLT5jb25uZWN0KCkgdG8KPj4+PiBzdWNjZWVkLgo+Pj4+Cj4+Pj4gU3VtbWFyaXpp bmcsIElNTyB0aGUgdW5pbmhpYml0IHBhdGggc2hvdWxkIGJlIGNhbGxpbmcgYm90aAo+Pj4+IC0+ b3BlbigpIGFuZCAtPnVuaW5oaWJpdCgpIChpZiBwcm92aWRlZCksIGFuZCBjb252ZXJzZWx5LCB0 aGUgaW5oaWJpdAo+Pj4+IHBhdGggc2hvdWxkIGJlIGNhbGxpbmcgYm90aCAtPmluaGliaXQoKSBh bmQgLT5jbG9zZSgpIChpZiBwcm92aWRlZCkuCj4+Pgo+Pj4gU28gd2hhdCB5b3UgYXJlIHRyeWlu ZyB0byBzYXkgaXMgdGhhdCB5b3Ugc2VlIGluaGliaXQgYXMgc29tZXRoaW5nIHRoYXQKPj4+IGlz IGRvbmUgaW4gYWRkaXRpb24gdG8gd2hhdCBoYXBwZW5zIGluIGNsb3NlLiBCdXQgd2hhdCBleGFj dGx5IGRvIHlvdQo+Pj4gd2FudCB0byBkbyBpbiBpbmhpYml0LCBpbiBhZGRpdGlvbiB0byB3aGF0 IGNsb3NlIGlzIGRvaW5nPwo+Pgo+PiBTZWUgYmVsb3cgKCopLgo+Pgo+Pj4KPj4+IEluIG15IHZp ZXcsIGlmIHdlIHdhbnQgdG8gaGF2ZSBhIGRlZGljYXRlZCBpbmhpYml0IGNhbGxiYWNrLCB0aGVu IGl0Cj4+PiB3aWxsIGRvIGV2ZXJ5dGhpbmcgdGhhdCBjbG9zZSBkb2VzLCB0aGV5IGJvdGggYXJl IGF3YXJlIG9mIGVhY2ggb3RoZXIKPj4+IGFuZCBjYW4gc29ydCBvdXQgdGhlIHN0YXRlIHRyYW5z aXRpb25zIGJldHdlZW4gdGhlbS4gRm9yIGRyaXZlcnMgdGhhdCBkbwo+Pj4gbm90IGhhdmUgZGVk aWNhdGVkIGluaGliaXQvdW5pbmhpYml0LCB3ZSBjYW4gdXNlIG9wZW4gYW5kIGNsb3NlCj4+PiBo YW5kbGVycywgYW5kIGhhdmUgaW5wdXQgY29yZSBzb3J0IG91dCB3aGVuIGVhY2ggc2hvdWxkIGJl IGNhbGxlZC4gVGhhdAo+Pj4gbWVhbnMgdGhhdCB3ZSBzaG91bGQgbm90IGNhbGwgZGV2LT5vcGVu KCkgaW4gaW5wdXRfb3Blbl9kZXZpY2UoKSB3aGVuCj4+PiBkZXZpY2UgaXMgaW5oaWJpdGVkIChh bmQgc2FtZSBmb3IgZGV2LT5jbG9zZSgpIGluIGlucHV0X2Nsb3NlX2RldmljZSkuCj4+PiBBbmQg d2hlbiB1bmluaGliaXRpbmcsIHdlIHNob3VsZCBub3QgY2FsbCBkZXYtPm9wZW4oKSB3aGVuIHRo ZXJlIGFyZSBubwo+Pj4gdXNlcnMgZm9yIHRoZSBkZXZpY2UsIGFuZCBubyBkZXYtPmNsb3NlKCkg d2hlbiBpbmhpYml0aW5nIHdpdGggbm8gdXNlcnMuCj4+Pgo+Pj4gRG8geW91IHNlZSBhbnkgcHJv YmxlbXMgd2l0aCB0aGlzIGFwcHJvYWNoPwo+Pgo+PiBNeSBjb25jZXJuIGlzIHRoYXQgaWYgZS5n LiBib3RoIC0+b3BlbigpIGFuZCAtPnVuaW5oaWJpdCgpIGFyZSBwcm92aWRlZCwKPj4gdGhlbiBp biBjZXJ0YWluIGNpcmN1bXN0YW5jZXMgLT5vcGVuKCkgd29uJ3QgYmUgY2FsbGVkOgo+Pgo+PiAx LiB1c2VycyA9PSAwCj4+IDIuIGluaGliaXQgaGFwcGVucwo+PiAzLiBpbnB1dF9vcGVuX2Rldmlj ZSgpIGhhcHBlbnMsIC0+b3BlbigpIG5vdCBjYWxsZWQKPj4gNC4gdW5pbmhpYml0IGhhcHBlbnMK Pj4gNS4gYXMgcGFydCBvZiB1bmluaGliaXQgLT51bmluaGliaXQoKSBpcyBvbmx5IGNhbGxlZCwg YnV0IC0+b3BlbigpIGlzIG5vdC4KPj4KPj4gVGhleSB3YXkgSSB1bmRlcnN0YW5kIHlvdXIgYW5z d2VyIGlzIHRoYXQgd2UgaW1wbGljaXRseSBpbXBvc2UgcmVxdWlyZW1lbnRzCj4+IG9uIGRyaXZl cnMgd2hpY2ggY2hvb3NlIHRvIGltcGxlbWVudCBlLmcuIGJvdGggLT5vcGVuKCkgYW5kIC0+dW5p bmhpYml0KCk6Cj4+IGluIHN1Y2ggYSBjYXNlIC0+dW5pbmhpYml0KCkgc2hvdWxkIGJlIGRvaW5n IGV4YWN0bHkgdGhlIHNhbWUgdGhpbmdzIGFzCj4+IC0+b3BlbigpIGRvZXMuIFdoaWNoIGxlYWRz IHRvIGEgY29uY2x1c2lvbiB0aGF0IGluIHByYWN0aWNlIG5vIGRyaXZlcnMKPj4gc2hvdWxkIGNo b29zZSB0byBpbXBsZW1lbnQgYm90aCwgb3RoZXJ3aXNlIHRoZXkgbXVzdCBiZSBhd2FyZSB0aGF0 Cj4+IC0+dW5pbmhpYml0KCkgY2FuIGJlIHNvbWV0aW1lcyBjYWxsZWQgaW5zdGVhZCBvZiAtPm9w ZW4oKS4gVGhlbiAtPm9wZW4oKQo+PiBiZWNvbWVzIHN5bm9ueW1vdXMgd2l0aCAtPnVuaW5oaWJp dCgpLCBhbmQgLT5jbG9zZSgpIHdpdGggLT5pbmhpYml0KCkuCj4+IE9yLCBtYXliZSwgdGhlbiAt PmluaGliaXQoKSBjYW4gYmUgYSBzdXBlcnNldCBvZiAtPmNsb3NlKCkgYW5kCj4+IC0+dW5pbmhp Yml0KCkgYSBzdXBlcnNldCBvZiAtPm9wZW4oKS4KPj4KPj4gSWYgc3VjaCBhbiBhcHByb2FjaCBp cyBvayB3aXRoIHlvdSwgaXQgaXMgb2sgd2l0aCBtZSwgdG9vLgo+Pgo+PiAoKikKPj4gQ2FsbGlu ZyBib3RoIC0+aW5oaWJpdCgpIGFuZCAtPmNsb3NlKCkgKGlmIHRoZXkgYXJlIHByb3ZpZGVkKSBh bGxvd3MKPj4gZHJpdmVycyB0byBnbyBmYW5jeSBhbmQgZmFpbCBpbmhpYml0aW5nICh3aGljaCBp cyBpbXBvc3NpYmxlIHVzaW5nCj4+IG9ubHkgLT5jbG9zZSgpIGFzIGl0IGRvZXMgbm90IHJldHVy biBhIHZhbHVlLCBidXQgLT5pbmhpYml0KCkgYnkgZGVzaWduCj4+IGRvZXMpLiBUaGVuIC0+dW5p bmhpYml0KCkgaXMgbW9zdGx5IGZvciBzeW1tZXRyeS4KPiAKPiBBbGwgdGhlIGNvbXBsaWNhdGlv bnMgZGlzY3Vzc2VkIGFib3ZlIGFyZSBleGFjdGx5IHdoeSBJIHN0aWxsCj4gYmVsaWV2ZSB0aGF0 IHRoZXJlIHNob3VsZCBiZSBvbmx5IG9wZW4gYW5kIGNsb3NlLgo+IAo+IElmIGVycm9yIHByb3Bh Z2F0aW9uIG9uIGluaGliaXQgaXMgY29uc2lkZXJlZCBhcyBzb21ldGhpbmcKPiByZWFsbHkgaW1w b3J0YW50IHRvIGhhdmUgdGhlbiB3ZSBjYW4gbWFrZSB0aGUgaW5wdXQgZHJpdmVyIGNsb3NlCj4g Y2FsbGJhY2sgcmV0dXJuIGFuIGVycm9yICgqKSwgbm90ZSBJJ20gdGFsa2luZyBhYm91dCB0aGUK PiBkcml2ZXIgY2xvc2UgY2FsbGJhY2sgaGVyZSwgbm90IHRoZSBzeXN0ZW0gY2FsbC4KPiAKPiBJ ZiB0aGUgY2xvc2UgY2FsbGJhY2sgaXMgY2FsbGVkIGZvciBhY3R1YWxseSBjbG9zaW5nIHRoZSBm ZAo+IHJlZmVycmluZyB0byB0aGUgaW5wdXQgbm9kZSwgdGhlbiB0aGUgbmV3IGVycm9yIHJldHVy biBjb2RlCj4gY2FuIGJlIGlnbm9yZWQsIGFzIHdlIGFscmVhZHkgZG8gZm9yIGVycm9ycyBvbiBj bG9zZSBhdG0KPiBzaW5jZSB0aGUgZHJpdmVyIGNsb3NlIGNhbGxiYWNrIHJldHVybnMgdm9pZC4K PiAKPiBJIHN0aWxsIGhhdmUgbm90IHNlZW4gYSB2ZXJ5IGNvbnZpbmNpbmcgYXJndW1lbnQgZm9y IGhhdmluZwo+IHNlcGFyYXRlIGluaGliaXQgYW5kIGNsb3NlIGNhbGxiYWNrcyBhbmQgYXMgdGhl IG1lc3N5IGRpc2N1c3Npb24KPiBhYm92ZSBzaG93cywgaGF2aW5nIDIgc3VjaCB2ZXJ5IHNpbWls YXIgeWV0IHN1YnRseSBkaWZmZXJlbnQKPiBjYWxscyBzZWVtcyBsaWtlIGEgYmFkIGlkZWEuLi4K PiAKPiBSZWdhcmRzLAo+IAo+IEhhbnMKPiAKPiAKPiAqKSBUaGlzIHdpbGwgcmVxdWlyZSBhIGZs YWcgZGF5IHdoZXJlICJyZXR1cm4gMCIgaXMgYWRkZWQKPiB0byBhbGwgY3VycmVudCBjbG9zZSBo YW5kbGVycwo+IAoKSSdtIHRha2luZyBvbmUgc3RlcCBiYWNrIGFuZCBsb29raW5nIGF0IHRoZSAt Pm9wZW4oKSBhbmQgLT5jbG9zZSgpCmRyaXZlciBjYWxsYmFja3MuIFRoZXkgYXJlIGNhbGxlZCBm cm9tIGlucHV0X29wZW5fZGV2aWNlKCkgYW5kCmlucHV0X2Nsb3NlX2RldmljZSgpLCByZXNwZWN0 aXZlbHk6CgppbnB1dF9vcGVuX2RldmljZSgpOgoiVGhpcyBmdW5jdGlvbiBzaG91bGQgYmUgY2Fs bGVkIGJ5IGlucHV0IGhhbmRsZXJzIHdoZW4gdGhleQp3YW50IHRvIHN0YXJ0IHJlY2VpdmUgZXZl bnRzIGZyb20gZ2l2ZW4gaW5wdXQgZGV2aWNlLiIKCi0+b3BlbigpIGNhbGxiYWNrOgoidGhpcyBt ZXRob2QgaXMgY2FsbGVkIHdoZW4gdGhlIHZlcnkgZmlyc3QgdXNlciBjYWxscwppbnB1dF9vcGVu X2RldmljZSgpLiBUaGUgZHJpdmVyIG11c3QgcHJlcGFyZSB0aGUgZGV2aWNlIHRvIHN0YXJ0Cmdl bmVyYXRpbmcgZXZlbnRzIChzdGFydCBwb2xsaW5nIHRocmVhZCwgcmVxdWVzdCBhbiBJUlEsIHN1 Ym1pdApVUkIsIGV0Yy4pIgoKaW5wdXRfY2xvc2VfZGV2aWNlKCk6CiJUaGlzIGZ1bmN0aW9uIHNo b3VsZCBiZSBjYWxsZWQgYnkgaW5wdXQgaGFuZGxlcnMgd2hlbiB0aGV5CndhbnQgdG8gc3RvcCBy ZWNlaXZlIGV2ZW50cyBmcm9tIGdpdmVuIGlucHV0IGRldmljZS4iCgotPmNsb3NlKCkgY2FsbGJh Y2s6CiJ0aGlzIG1ldGhvZCBpcyBjYWxsZWQgd2hlbiB0aGUgdmVyeSBsYXN0IHVzZXIgY2FsbHMK aW5wdXRfY2xvc2VfZGV2aWNlKCkiCgpJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBjYWxsYmFjayBu YW1lcyBkbyBub3QgcmVmbGVjdCB0aGVpcgpwdXJwb3NlOiB0aGVpciBtZWFuaW5nIGlzIG5vdCB0 byAib3BlbiIgb3IgdG8gImNsb3NlIiBidXQgdG8KZ2l2ZSBkcml2ZXJzIGEgY2hhbmNlIHRvIGNv bnRyb2wgd2hlbiB0aGV5IHN0YXJ0IG9yIHN0b3AKcHJvdmlkaW5nIGV2ZW50cyB0byB0aGUgaW5w dXQgY29yZS4KCldoYXQgd291bGQgeW91IHNheSBhYm91dCBjaGFuZ2luZyB0aGUgY2FsbGJhY2tz JyBuYW1lcz8KSSdkIGVudnNpb246IC0+cHJvdmlkZV9ldmVudHMoKSBpbnN0ZWFkIG9mIC0+b3Bl bigpIGFuZAotPnN0b3BfZXZlbnRzKCkgaW5zdGVhZCBvZiAtPmNsb3NlKCkuIE9mIGNvdXJzZSBk cml2ZXJzIGNhbgpleHBsb2l0IHRoZSBmYWN0IG9mIGtub3dpbmcgdGhhdCBub2JvZHkgd2FudHMg YW55IGV2ZW50cwpmcm9tIHRoZW0gYW5kIGRvIHdoYXRldmVyIHRoZXkgY29uc2lkZXIgYXBwcm9w cmlhdGUsIGZvcgpleGFtcGxlIGdvIGludG8gYSBsb3cgcG93ZXIgbW9kZSAtIGJ1dCB0aGUgbGF0 dGVyIGlzIGJleW9uZAp0aGUgc2NvcGUgb2YgdGhlIGlucHV0IHN1YnN5c3RlbSBhbmQgaXMgZHJp dmVyLXNwZWNpZmljLgoKV2l0aCBzdWNoIGEgbmFtaW5nIGNoYW5nZSBpbiBtaW5kIGxldCdzIGNv bnNpZGVyIGluaGliaXRpbmcuCldlIHdhbnQgdG8gYmUgYWJsZSB0byBjb250cm9sIHdoZW4gdG8g ZGlzcmVnYXJkIGV2ZW50cyBmcm9tCmEgZ2l2ZW4gZGV2aWNlLiBJdCBtYWtlcyBzZW5zZSB0byBk byBpdCBhdCBkZXZpY2UgbGV2ZWwsIG90aGVyd2lzZQpzdWNoIGFuIG9wZXJhdGlvbiB3b3VsZCBo YXZlIHRvIGJlIGludm9rZWQgaW4gYWxsIGFzc29jaWF0ZWQKaGFuZGxlcnMgKHRob3NlIHRoYXQg aGF2ZSBhbiBvcGVuIGhhbmRsZSBhc3NvY2lhdGluZyB0aGVtIHdpdGgKdGhlIGRldmljZSBpbiBx dWVzdGlvbikuIEJ1dCBvZiBjb3Vyc2Ugd2UgY2FuIGRvIGJldHRlciB0aGFuCm1lcmVseSBpZ25v cmluZyB0aGUgZXZlbnRzIHJlY2VpdmVkOiB3ZSBjYW4gdGVsbCB0aGUgZHJpdmVycwp0aGF0IHdl IGRvbid0IHdhbnQgYW55IGV2ZW50cyBmcm9tIHRoZW0sIGFuZCBsYXRlciwgYXQgdW5pbmhpYml0 CnRpbWUsIHRlbGwgdGhlbSB0byBzdGFydCBwcm92aWRpbmcgdGhlIGV2ZW50cyBhZ2Fpbi4gQ29u Y2VwdHVhbGx5LAp0aGUgdHdvIG9wZXJhdGlvbnMgKHByb3ZpZGUgb3IgZG9uJ3QgcHJvdmlkZSBl bnZlbnRzKSBhcmUgZXhhY3RseQp0aGUgc2FtZSB0aGluZyB3ZSB3YW50IHRvIGJlIGhhcHBlbmlu ZyBhdCBpbnB1dF9vcGVuX2RldmljZSgpIGFuZAppbnB1dF9jbG9zZV9kZXZpY2UoKSB0aW1lLiBU byBtZSwgY2hhbmdpbmcgdGhlIG5hbWVzIG9mCi0+b3BlbigpIGFuZCAtPmNsb3NlKCkgZXhwb3Nl cyB0aGlzIGZhY3QgdmVyeSB3ZWxsLgoKQ29uc2VxdWVudGx5LCAtPmluaGliaXQoKSBhbmQgLT51 bmluaGliaXQoKSB3b24ndCBiZSBuZWVkZWQsCmFuZCBkcml2ZXJzIHdoaWNoIGFscmVhZHkgaW1w bGVtZW50IC0+cHJvdmlkZV9ldmVudHMoKSAoZm9ybWVybHkKLT5vcGVuKCkpIGFuZCAtPnN0b3Bf ZXZlbnRzKCkgKGZvcm1lcmx5IC0+Y2xvc2UoKSkgd2lsbCByZWNlaXZlCmZ1bGwgaW5oaWJpdC91 bmluaGliaXQgc3VwcG9ydCBmb3IgZnJlZSAoc3ViamVjdCB0byBob3cgd2VsbCB0aGV5CmltcGxl bWVudCAtPnByb3ZpZGVfZXZlbnRzKCkvLT5zdG9wX2V2ZW50cygpKS4gVW5sZXNzIHdlIGNhbiBj b21lCnVwIHdpdGggd2hhdCB0aGUgZHJpdmVycyBtaWdodCBiZSBkb2luZyBvbiB0b3Agb2YgLT5z dG9wX2V2ZW50cygpCmFuZCAtPnByb3ZpZGVfZXZlbnRzKCkgd2hlbiBpbmhpYml0aW5nL3VuaW5o aWJpdGluZywgYnV0IGl0IHNlZW1zCnRvIG1lIHdlIGNhbid0LiBDYW4gd2U/CgpPcHRpb25hbGx5 IC0+Y2xvc2UoKSAob25seSB0aGUgY2FsbGJhY2ssIG5vdCBpbnB1dF9jbG9zZV9kZXZpY2UoKSkK Y2FuIGJlIG1hZGUgcmV0dXJuIGEgdmFsdWUsIGp1c3QgYXMgSGFucyBzdWdnZXN0cy4gVGhlIHZh bHVlCmNhbiBiZSBpZ25vcmVkIGluIGlucHV0X2Nsb3NlX2RldmljZSgpIGJ1dCB1c2VkIGluIGlu cHV0X2luaGliaXQoKS4KTm8gc3Ryb25nIG9waW5pb24gaGVyZSwgdGhvdWdoLiAoYnR3IGl0IHNl ZW1zIHRvIG1lIHRoYXQKaW5wdXRfaW5oaWJpdCgpIHNob3VsZCBiZSByZW5hbWVkIHRvIGlucHV0 X2luaGliaXRfZGV2aWNlKCkpLgoKUmVnYXJkcywKCkFuZHJ6ZWoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK