Re: irq-type-flags.patch

[Russell King <rmk@arm.linux.org.uk>]

On Wed, Nov 09, 2005 at 03:13:47PM +0000, David Howells wrote:
> Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Neither the arch not the bus dictates what the
> > device manufacturer decides to do with their interrupt output.
> 
> On the other hand, the device manufacturer does not decree what the arch and
> supporting chipset will *accept*.

David, you have completely the wrong idea about this.  The driver does
not decree anything.  The driver is telling the IRQ subsystem what type
of interrupt the chip produces.

If an _architecture_ wants to indirect that through something, all well
and good - it can, but that's up to the architectures request_irq()
internals.

> There's no guarantee that all trigger types
> will be supported. For instance on my ASB2305 board, I've got an on-chip PIC
> that will accept any of the four trigger types, but the PCI bus interrupt line
> attached to one of the external interrupt pins will *only* accept low-level
> triggered. In such a case, the bus *must* override anything set by one of the
> devices.

We have this scenario on ARM today - for years - and it isn't a problem
there.  So why is it such a massive problem here?

I think the root of this issue is that you're thinking that the driver
uses this to dictate to the interrupt controller what it wants the
controller to program itself for.  It's more a case that the driver is
saying "my device produces this kind of interrupt, please configure
the input appropriately."

Maybe the real issue here is that we should have dev_request_irq which
takes a struct device?  That's another, separate, orthogonal interface
extension which those who require it can work on.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core