Hi, acpi_gpiochip_request_irq() has this code: /* Make sure we trigger the initial state of edge-triggered IRQs */ value = gpiod_get_raw_value_cansleep(event->desc); if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) || ((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0)) event->handler(event->irq, event); Originally introduced in: commit ca876c7483b697b498868b1f575997191b077885 Author: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> Date: Thu Jul 12 17:25:06 2018 +0200 gpiolib-acpi: make sure we trigger edge events at least once on boot This code is causing a problem on a new consumer laptop, which is based on the new ACPI reduced hardware standard. Under this design, the power button is now just an ordinary GPIO that should be handled by software: ACPI's _AEI method lists this GPIO as one that the OS should monitor for changes, and the OS is expected to call the corresponding _EVT method when that happens, which will in turn raise a Notify event on the power button device. Here, the GpioInt defined in _AEI is Edge-triggered, ActiveHigh. The GPIO level is ordinarily high, but goes low when the button is pressed. We checked this definition and behaviour with the vendor, even suggesting that it should maybe be ActiveLow instead, but they responded that this is correct and by-design. These conditions set the IRQF_TRIGGER_RISING flag and cause the _EVT event handler to be called by the code above as soon as the pinctrl module is loaded. In other words, loading the pinctrl driver causes the system to incorrectly believe the power button has been pressed so it will immediately go into suspend or shutdown. Fortunately this is perhaps not a serious issue, as at least Ubuntu and Endless build the corresponding pinctrl drivers directly into the kernel image. They are then loaded in early boot, and despite a power button event being reported, it's so early that userspace doesn't notice and no action is taken. But I raise this anyway as a potential problem should that ever change, it may also become a more widespead issue as the ACPI reduced hardware standard becomes more and more common in consumer devices. Any ideas for how we can better deal with this issue? I can see the rationale for handling the specific cases mentioned in the original commit message, but at the same time this code seems to be assuming that an edge transition has happened, which is not true in this case. Thanks, Daniel