Re: Fwd: [RFC] IRQ type flags

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Good question - I'm not sure currently.  In the places where set_irq_type
> is used on ARM, we're mainly interested in setting the input according
> to rising/falling edge or high/low levels rather than switching between
> edge and level mode.
> 
> We could do as you suggest, but my concern would be adding extra
> complexity to drivers, causing them to do something like:
> 
> 	ret = request_irq(..., SA_TRIGGER_HIGH, ...);
> 	if (ret == -E<whatever>)
> 		ret = request_irq(..., SA_TRIGGER_RISING, ...);
> 
> The alternative is:
> 
> 	ret = request_irq(..., SA_TRIGGER_HIGH | SA_TRIGGER_RISING, ...);
> 
> at which point the driver is telling the IRQ layer what it can support,
> and allowing the IRQ layer to select the most appropriate type given
> the driver and hardware constraints.

We have similar things on ppc but dealt differently. The type of
interrupt sense supported depends on the PIC (and you can have more than
one PIC around). On Open Firmware based machines at least, the
device-tree tells us the sense setting to use on all devices in the
system, we program our PIC based on that information.

Your proposal though is interesting as it would allow individual to
override that setting (it may be broken, firmware occasionally are), and
would probably be useful for embedded PPCs as well.

However, I would suggest defining the absence of explicit trigger (0) as
a constant rather than 0 (SA_TRIGGER_DEFAULT), just for consistency.That
means using whatever the platform considers as a good default for this
interrupt. In addition, I would still add a get_irq_trigger() function
for a driver to enquire the kind of sense that was set by default by the
platfrom for a given irq line.

Ben.