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. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
