On Thu, Feb 02, 2017 at 02:27:28PM +0100, Hans de Goede wrote: > > Actually what is wrong here is that your gpiod_get(dev, "power") falls > > back to use plain indexes and returns the first GPIO even though it > > should not as the driver specifically requests GPIO with name "power" > > and there is no _DSD. > > There is no clear "binding" for this device in ACPI, so the fallback > is actually used as a feature by the Silead driver (more or less), > the use of "power" as name here is for the ARM + devicetree usage > of the driver really, so IOW the series: > > > > > Andy (Cc'd) has a patch that tries to make the fallback mechanism more > > stricter which should in theory fix the problem as well. The patch > > series is here: > > > > https://bitbucket.org/andy-shev/linux/commits/338c0226b631b8b497d143070a301d8b8883c349?at=master > > You are referring to might fix this, but then we may need to add an > attempt to get the gpio by index for some boards which do not control > it themselves from _PS#. > > I can give the linked series a try, but I would still like a fallback > plan if we indeed encounter boards where we need to fallback to > getting the gpio by index. Once we do that we're back to having the > same problem as then we would do the same fallback on boards where > the pin is reserved for _PS# usage, and end up with an -EBUSY error > again. I guess we could ignore -EBUSY in the fallback path, or only > do the fallback if acpi_bus_power_manageable() returns false. I don't think using acpi_bus_power_manageable() is a proper way to fix this. This can be fixed without the fallback so that for the boards you know need to handle the GPIO themselves (based on the _HID for example), they will call acpi_dev_add_driver_gpios() passing the mapping for "power". The other boards then just don't get the GPIO. We really want to get rid of the whole fallback mess. -- 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
