gpiobus: Support non-child interrupt resource consumers

[obiwac]

Summary

Make gpiobus_alloc_resource() accept a 'child' that is not a child of
'bus'. This will be needed for cousin interrupt consumers, which may not
be a decendant of the interrupt source.

Sponsored by: The FreeBSD Foundation

[avg]

When I thought about these things, what concerned me is dependencies between a device and its non-child consumers.
With parent-child relationships many ordering things are obvious.
But with arbitrary relations something may not be set-up enough or already torn down etc.

I think that Linux has a concept of devlink or something like that.
It's a way to register producer-consumer (or some other kind) dependencies between devices and can be thought of as a generalization of parent-child dependencies.
That the dependency graph can be topologically sorted so that devices are initialized and torn down in the correct order.

In the end, I support this change but I think that it can open dangerous holes without additional dependency mechanism.

[rz_fabmicro.ru]

I tested this stack of diffs on my laptop, it also has I2C HID touchpad with IRQ connected to GPIO pin (pin #144, which resides in upper 32 bit word). Stack works, but with some issues:

1. I discovered a bug in parent D57968, an AMD_GPIO_INTR_MASK was wrongly calculated so it did not work right away on my setup. Update to D57968 already uploaded.

2. In acpi_gpiobus_attach() resource handler is not stored into pin_intr->intr_res, this makes system panic when interrupt provider detaches (kldunload amdgpio) because NULL pointer fed into BUS_TEARDOWN_INTR().

3. After fixing #2, I noticed another issue: reloading amdgpio makes system panic again with the following:

panic: /usr/home/rz/FreeBSD-src/src-current/sys/kern/subr_rman.c:137: rman_init: Bad tailq NEXT(0xffffffff81ae49f0->tqh_last) != NULL

Looks like it is trying to do second allocation of already allocated resource.