From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mika Westerberg Subject: Re: [PATCH v2] Input: silead - Do not try to directly access the GPIO when using ACPI pm Date: Thu, 2 Feb 2017 14:10:18 +0200 Message-ID: <20170202121018.GN2053@lahna.fi.intel.com> References: <20170122200008.27027-1-hdegoede@redhat.com> <20170122222015.GA31009@dtor-ws> <8a23b7b2-a7aa-d62d-947d-31301a0c92cc@redhat.com> <20170201174257.GE40045@dtor-ws> <20170202104130.GJ2053@lahna.fi.intel.com> <8e91084e-e0ea-b055-5c62-67a4e0e56df4@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mga11.intel.com ([192.55.52.93]:40792 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbdBBMKW (ORCPT ); Thu, 2 Feb 2017 07:10:22 -0500 Content-Disposition: inline In-Reply-To: <8e91084e-e0ea-b055-5c62-67a4e0e56df4@redhat.com> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Hans de Goede Cc: Dmitry Torokhov , "russianneuromancer @ ya . ru" , Gregor Riepl , linux-input@vger.kernel.org, Linus Walleij On Thu, Feb 02, 2017 at 12:57:05PM +0100, Hans de Goede wrote: > Hi, > > On 02-02-17 11:41, Mika Westerberg wrote: > > On Wed, Feb 01, 2017 at 09:42:57AM -0800, Dmitry Torokhov wrote: > > > On Mon, Jan 23, 2017 at 11:05:14AM +0100, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 22-01-17 23:20, Dmitry Torokhov wrote: > > > > > On Sun, Jan 22, 2017 at 09:00:08PM +0100, Hans de Goede wrote: > > > > > > On some x86 tablets we cannot directly access the GPIOs as they are > > > > > > claimed by the ACPI tables, so check it the i2c client is not being > > > > > > power-managed by ACPI before trying to get the power pin GPIO. > > > > > > > > > > Why do we even get this GPIO if driver is not supposed to be using it? > > > > > I'd much rather gpio provider hid it from the driver instead of every > > > > > driver having this check. > > > > > > > > The problem is that the gpio subsys does not really know about ACPI > > > > managed GPIOs the way this works is that the firmware sets a special > > > > "reserved for firmware use" bit in the gpio control register and > > > > directly bit-bangs the gpio control register when it wants to toggle > > > > the gpio. So there is no awareness of these gpios being reserved > > > > (as gpios) at the ACPI level AFAICT. > > > > > > > > The hardware specific low-level gpio chip driver checks this bit > > > > when we request the gpio and returns -EBUSY. > > > > > > I'd say that, if GPIOs are reserved for firmware use, and kernel should > > > not or can not touch them, then they should not be visible, if not to > > > the gpio core, then to consumers for sure. > > > > > > Let's add Mika and Linus. > > > > It is not always possible for the GPIO driver to find out if a certain > > GPIO is reserved for the firmware use or not. I don't think we have any > > API in gpiolib that allows excluding certain GPIOs though. > > > > What we do for example with the ACPI OpRegion GPIOs is that gpiolib > > reserves those automatically thus preventing any consumer from using > > those. > > Right, but that would result in a -EBUSY error from gpiod_get, so > iow gpiod_get_optional would still fail and not just return NULL as it > would if the requested gpio does not exist? Yes, that's my understanding as well. > IOW even if that was happening here, we would still need to handle > either -EBUSY and treat it as gpiod_get_optional returning NULL, or > we need the acpi_bus_power_manageable check the patch from this > thread is adding, right ? I do not have a copy of the patch in this thread but sounds like something that might work.