What's this brace doing here?

why BUS_ADD_CHILD and not bus_add_child? The usual pattern is to add the child with the ivars... So I'm a bit confused below that you get the ivards... Am I missing something here?

Doesn't this rely on the fact that type is initialized to 0 in the malloc? Maybe making that more explicit would help?

It's so I don't pollute the rest of the function with the 4 aei variables.

gpiobus_add_child_common (which is called from acpi_gpiobus' bus_add_child) deals with allocating the ivars and calling device_set_ivars. So all we have to do after that is set the acpi specific bits and set the pins needed by _AEI.

why BUS_ADD_CHILD and not bus_add_child?

s/bus_add_child/device_add_child ?
Before we were doing device_add_child_ordered then initializing the resource list and calling device_set_ivars. But all of that is already done in gpiobus_add_child_common, which we can either call directly or call through BUS_ADD_CHILD, so I thought this would be better.

Yes and Yes :)

Looking through the code again, we could just remove the M_ZERO and initialize type and intr_rid explicitly.

If you don't want to move the variables to the top of the function moving this into a new function might be cleaner. It's uncommon to put these into the middle of a function.

Why M_NOWAIT when you don't handle it returning NULL?

It looks like you're implementing SLIST_FOREACH_SAFE

This function gets called by ACPICA. While I tested M_WAITOK and it seemed to work fine, I'd rather not assume it's not doing anything else (e.g holding a mutex).

when you don't handle it returning NULL?

Not sure what else to do other than an assertion.

Ah, looks like I am.