Reword comment to make it clear what the variable is for

Move physmap_idx addition further down

int32_t -> uint32_t

Remove the now redundant cast to void.

Should be good to go. Although I just realized one of the callers explicitly casts this to void. That should be removed too.

Change efi_map_regs to an int32_t.

Remove the tunable, always map the first page.

Move max77620 and as3722's gpio_attach functions to their original place,
and use gpiobus_add_bus instead.

Revert the max77620 and as3722 changes. They are handled differently.

In D51088#1167027, @vexeduxr wrote:

Hmm, is there a reason we need to add a child in max77620_gpio_attach/as3722_gpio_attach specifically? I think we should just move the gpiobus_attach_bus call after hw init is done.

In D51088#1166892, @mmel wrote:

max77620 and as3722 are much more problematic. I think each function expects the other functions to have HW initialized before they can be consumed.

Move as3722_gpio_attach and max77620_gpio_attach back up, and instead swap them with *_rtc_create.
It's hard to tell if the interrupt is needed by the controller's children (presumably it is), but
they're both currently unimplemented.

In D51088#1166439, @mmel wrote:

and another for changes to pl061 (the ACPI/WDT interrupt changes seems unrelated).

They're required to move the intr_pic_register call to pl061_attach.

Landed as rGb670c9bafc0e31c7609969bf374b2e80bdc00211. I think I messed up the Differential Revision: tag.

In D26407#1162606, @aokblast wrote:

Oops, please forget the problem. The acpi infoactaully binding to iichid. So the bus can pretty easy to get the acpi information. But we still need a interface for setting a interrupt on the gpio side, right? Because we cannot use INTR_NG and bus_setup_intr need the iichid to be a children of gpio bus? I didn't see the code on the gpiobus have the ability to handle cross-tree reference. I see it needs either INTR_NG or a children of a gpio bus to enable it.

Convert null check to KASSERT

rebase

I went for a KASSERT instead of a panic since it's what the other gpio_* functions do. On a non-INVARIANTS kernel, if gpio is actually NULL, it will panic when we try to dereference it anyways.

Convert checks to KASSERTs

Motivation? Why do we need gpio_pin_release to return errors?

re-add comment.

fixup function declaration

I don't really see why it would cause problems. With the current implementation at least.
Thinking about this some more, it's very possible that a future change to gpiobus_acquire_pin or gpio_pin_acquire can break this though...