On Tue, Oct 15, 2013 at 3:45 PM, Christian Ruppert
[off-list ref] wrote:

On Wed, Oct 09, 2013 at 02:19:17PM +0200, Linus Walleij wrote:

quoted

It's not like I'm 100% certain on where to use one or the other
construct (a mechanism like the above is needed for threaded
IRQs I've noticed) but the chained handler seems more to the
point does it not?

The only downside I've seen is that the parent IRQ does not get
a name and the accumulated IRQ stats in /proc/interrupts but
surely we can live without that (or fix it).

Since I'm a bit rusty on chained IRQs correct me if I'm wrong...

OK, it took me a while to figure this back out again because as far as
I'm familiar with the IRQ framework you're right. The reason I'm not
using irq_set_chained_handler is that we have one driver instance per
GPIO bank and all GPIO banks share the same interrupt line. This means
every driver instance needs its own (different) user data and a simple
call to irq_set_handler_data(tb10x_gpio) won't suffice. I'm not aware of
any mechanism that allows interrupt sharing with the
irq_set_chained_handler() mechanism.

OK yes makes perfect sense. We'll live with this then.

I didn't see a new version of this patch with the other two, shall
I just apply this last version in the pin control tree with the
two other patches?

Yours,
Linus Walleij