On Tuesday 27 February 2007, Eric W. Biederman wrote: > * Add a variation of the API in interrupt.h that uses > "struct irq *irq" instead of "unsigned int irq" > > Probably replacing request_irq with irq_request or something > trivial like that. > > This will need to touch all of different irq implementation back > ends, but only very lightly. > > * Convert the generic irq code to use struct irq * everywhere it > current uses "unsigned int irq". > > * Start on the conversions of drivers and subsystems picking on > the easy ones first :)
Introducing the irq_request() etc. functions that take a struct irq* instead of an int sounds good, but I'd hope we can avoid using those in device drivers and do a separate abstraction for each bus_type that deals with interrupts. I'm not sure if that's possible for each bus_type, but the ones I have worked with in the past should allow that: pci: each device/function has a unique irq, drivers need not know about it afaics. isa/pnp: numbers from 1 to 15 are the right abstraction here, that how isa has worked for ages. s390: got rid of irq numbers already ofw: an open firmware device can have a number of interrupts, but like PCI, the driver only needs to know things like 'first irq of this device', not how it's connected ps3: irqs are requested from the firmware for each device, this can happen under the covers. mmc, usb, phy, ieee1394: these already have a higl-level abstraction for interrupt events platform: dunno, probably these really should use the struct irq directly eisa, mca, pcmcia, zorro, ...: no idea, but possibly similar to PCI. Note that we can even start converting device drivers first, before moving away from irq numbers. A typical PCI driver should get somewhat simpler by the conversion, and when they are all converted, we can replace pci_dev->irq with a struct irq* under the covers. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/