Re: [GIT PATCH] more Driver core patches for 2.6.19

[Thomas Gleixner <tglx@linutronix.de>]

Linus,

On Thu, 2006-12-14 at 14:59 -0800, Linus Torvalds wrote:
> > The kernel part of the UIO driver also knows how to shut the interrupt
> > up, so where is the difference ?
> 
> Thomas, you've been discussing some totally different and private 
> Thomas-only thread than everybody else in this thread has been.

Yeah, I even looked at different code than others, until they noticed
that email before coffee is bad. :)

> The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the 
> post that STARTED this whole thread. Go and read the "example driver". 
> 
> The example driver was complete crap and drivel. 

Sigh, I accept and also Greg has done this before, that the example
driver based on the LPT port was not a fortunate choice. It was done to
provide some example which is reproducible on COTS hardware. 

Real world drivers like the sercos example I provided - and I do it
again - are aware of that problem:

/*
 * The chip specific portion of the interrupt handler. The framework code
 * takes care of userspace notification when we return IRQ_HANDLED
 */
static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg)
{
        /* Check, if this interrupt is originated from the SERCOS chip */
        if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK))
                return IRQ_NONE;

---------^ Makes it safe for IRQ sharing

        /* Acknowledge the chip interrupts */
        sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1);
        sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2);

----------^
	Actually prevents the box is dead scenario, as it disables the
interrupt from that device until it is reenabled from the user space
driver code. This covers also the case where the user space driver dies,
as the kernel still has the portion of code to shut this thing up for
ever.
        return IRQ_HANDLED;
}

The concept requires, that 
- the interrupt handling is in the kernel _AND_ open source
- the mapping of the device is done via the kernel controlled mapping
function rather than by poking in the PCI regs

I really regret that I ever came up with this LPT example, but cutting
the whole discussion down to that ugly example driver does not get us
anywhere.

	tglx