GPIO: Add ACPI _AEI support

[cperciva]

Summary

Changes to acpi_gpiobus.c handle discovering and parsing the _AEI
objects and storing necessary data in device ivars. A new gpioaei.c
file implements the device, which simply requests an interrupt when
the pin is triggered and invokes the appropriate _Exx or _Lxx ACPI
method.

This makes the GPIO "power button" work on arm64 Graviton systems,
allowing EC2 "Stop"/"Reboot" instance calls to be handled cleanly.
(Prior to this change, those requests would time out after 4 minutes
and the instance would be forcibly killed.)

Sponsored by: Amazon

[cperciva]

sys/dev/gpio/acpi_gpiobus.c

184

This flag is added in D47239.

[andrew]

sys/dev/gpio/gpioaei.c

87–88

Can we check this object exists? I have a board that uses an _EVT method so will likely fail trying to call a method that doesn't exist.

[cperciva]

sys/dev/gpio/gpioaei.c

87–88

Ah, I didn't have access to any hardware using the newer _EVT option. We should implement support for that (necessary for the pins > 255 case I flagged a few lines earlier as well) but without hardware I can't do that right now. Can you add that support?

Until we implement support for _EVT methods it's probably better to print an error when we fail to invoke a nonexistent _Exx method than to simply do nothing though?

I'd like to get this driver into the tree -- with or without _EVT method support -- in time for 14.2 because it's a major pain point for EC2.

[ahmadkhalifa570_gmail.com]

sys/dev/gpio/acpi_gpiobus.c

50

This is accessible through sc->sc_busdev.

164

There should be a check here to make sure we have the correct controller, like the one in acpi_gpiobus_enumerate_res.
e.g gpiobus0 should only interact with pins on GPO0.

This becomes more of a problem when you have multiple controllers with the same pin numbers then gpiobus0 tries to take ownership of both.

189

Sometimes ACPI provides us with flags that aren't accepted by the GPIO controller's driver. e.g bytgpio only accepts GPIO_PIN_INPUT or GPIO_PIN_OUTPUT. ACPI may give us either one of those along with GPIO_PIN_PULLUP for example. This makes GPIOBUS_PIN_SETFLAGS fail.

Maybe we can use GPIO_PIN_SETFLAGS with GPIO_PIN_GETCAPS to weed out the flags we don't need.
We should probably also be doing this in acpi_gpiobus_enumerate_res instead of passing the flags directly.

339

This should be updated since we also check for _AEI now. Preferably to something more generic.

[ahmadkhalifa570_gmail.com]

sys/dev/gpio/acpi_gpiobus.c

339

Actually, "GPIO resources" works for both. Not sure why I thought it didn't :p
Nevermind.