I can't test the pwrbutton stuff, but rtc and musb behave...

With one issue:  the usb transceiver glue misbehaves on
startup if the device is connected.  (Again.)  I looked at
this a bit, and I think the issue is probably caused by
not actually using key USB registers ... IRQ trigger
mode state transitions are at best a fragile proxy for the
real state.

(This is similar to the GPIO patch I just sent, but simpler
except for the impact on the few drivers thinking oddly
about IRQs.  Those patches cover the key SIH modules, and
a similar one affects the PIH in twl4030-core.)

- Dave

================================
Streamline the "power irq" code, and some of the mechanisms
it uses:

 - Support IRQ masking, not just unmasking; simpler code.
 - Use the standard handle_edge_irq() handler for these edge IRQs.
 - Use generic_handle_irq() instead of a manual expansion thereof.
 - Provide a missing spinlock for the shared data.

In short, use more of the standard genirq code ... more correctly.

Also, update the drivers using the "power IRQ" accordingly:

 - Don't request IRQF_DISABLED if the handler makes I2C calls;
   and defend against lockdep forcing it on us.

 - Let the irq_chip handle IRQ mask/unmask; it handles mutual
   exclusion between drivers, among other things.

 - (Unrelated) remove useless MODULE_ALIAS in pwrbutton.

The USB transceiver driver still places some dodgey games with IRQ
enable/disable, and IRQ trigger flags.  At least some of them seem
like they'd be simplified by using USB transceiver registers ...
notably, startup code, which doesn't seem to check state before
it enters an irq-driven mode.

For the moment, these drivers still (wrongly) try to configure IRQ
trigger modes themselves ... again, that's something that an irq_chip
handles (but not yet, for this one).

NOTE:  tested (MUSB and RTC only) along with the init/retry hack
to make twl4030-pwrirq work around the i2c-omap timeout problems.