gpio: implement bus_setup_intr and bus_teardown_intr

[vexeduxr]

Summary

Implement bus_setup_intr and bus_teardown_intr as bus_generic_setup_intr
and bus_generic_teardown_intr respectively for GPIO drivers that support
interrupts. This allows children to setup interrupts.

Reported by: Evgenii Ivanov <[e-mail]>

[mmel]

I just found a similar problem with rockchip gpio. Implementing interrupt methods is not enough, we also need all the methods for resources. This led me to the idea that we could create a new class in which all these methods (interrupts and resources) would be implemented (by using bus_generic_<foo>), and then subclass all bus-like drivers from it. It's clean, simple, and saves a lot of lines...
@jhb, do you have any comments on this?

[vexeduxr]

Which functions are giving you problems?
The resource handling is done by gpiobus, but bus_setup_intr and bus_teardown_intr need to get to nexus.

[andrew]

I expect we would need bus_activate_resource as it's called via bus_generic_rman_alloc_resource in gpiobus_alloc_resource.

[vexeduxr]

It calls bus_activate_resource on the child device, which should just go through gpiobus' implementation, bus_generic_rman_activate_resource.

[mmel]

These are needed for cross-tree allocation of interrupts (and probably also pins). For example, in FDT, a device from another tree path, typically an I2C or SPI, may have its IRQ pin connected to GPIO.
A driver from another tree path can therefore use an GPIO based interrupt. These allocations are processed by the controller itself (due to FDT references), but by gpiobus.
@andrew is right, at least (de)activate_resource is necessary, but I'm not sure yet whether other resource list oriented methods are also needed.

[vexeduxr]

In D52197#1193109, @mmel wrote:

These are needed for cross-tree allocation of interrupts (and probably also pins). For example, in FDT, a device from another tree path, typically an I2C or SPI, may have its IRQ pin connected to GPIO.
A driver from another tree path can therefore use an GPIO based interrupt. These allocations are processed by the controller itself (due to FDT references), but by gpiobus.

Sorry, I think I'm missing something. I don't see how the call can end up in the GPIO driver.
Take for example the following hierarchy:

├── gpio0
│   └── gpiobus0
└── rk_i2c0
    └── iicbus0
        └── dev0

And say dev0 has the following:

#interrupt-cells=<2>;
interrupt-parent = <&gpio>;
interrupts = <4 2>;

ofw_iicbus would call ofw_bus_intr_to_rl to get the pins into dev0's resource list. So when dev0 attempts to allocate a resource, it would end up in iicbus' bus_generic_rl_alloc_resource, which ends up doing BUS_ALLOC_RESOURCE(device_get_parent(bus), child, .... At that point, it's rk_i2c0's job to pass the call up to nexus.

@andrew is right, at least (de)activate_resource is necessary, but I'm not sure yet whether other resource list oriented methods are also needed.

[vexeduxr]

Bump
Userspace GPIO interrupts are currently broken because of this. (after D51932)
I believe that we do need to implement the resource allocation functions too (for cross-tree consumers), just not on the GPIO controller.

[imp]

This looks good to me.