Hi,
On 07/06/2018 12:27 PM, Mika Westerberg wrote:
On Fri, Jul 06, 2018 at 11:52:51AM +0200, Hans de Goede wrote:
Hi,
On 07/06/2018 11:46 AM, Mika Westerberg wrote:
On Fri, Jul 06, 2018 at 11:32:29AM +0200, Hans de Goede wrote:
+
+ /*
+ * Make sure we trigger the initial state of the IRQ when
+ * using RISING or FALLING.
+ */
+ if (((irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
+ ((irqflags & IRQF_TRIGGER_FALLING) && value == 0))
+ handler(-1, event);
+
While I don't have anything against this it makes me wonder how it is
handled in Windows side? Any idea?
I guess Windows does the same, otherwise it should have similar issues,
but that is just a guess.
I see. Is this the ACPI control method lid device (PNP0C0D)? Maybe we
can read its initial state using _LID method?
No the problem is the _LID method reads an APCI variable which gets set
by the _AEI handler. So if the _AEI handler has not run that variable will
just be 0, which may or may not reflect the actual LID state.
The 2nd case described in the commit message is the _AIE handler driving
a GPIO and that GPIO / the mux controlled by that GPIO not reflecting the
cable-type plugged into the micro-usb until the handler runs (this is the
one I still need to verify it is actually fixed by this patch).
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
