[Top] [All Lists]

Re: [PATCH] add dispatch_i8259_irq() to i8259.c

To: Jun Sun <>
Subject: Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: "Maciej W. Rozycki" <>
Date: Wed, 18 Dec 2002 19:14:20 +0100 (MET)
Cc: Ralf Baechle <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
On Wed, 18 Dec 2002, Jun Sun wrote:

> > do_IRQ(poll_8259A_irq(), regs);
> I actually don't like the new semantic.  The main drawback is that we can't
> dispatch a 8259A interrupt from assemably code, which is often needed.

 You can't do that with your original code either, unless you arrange a
call to your dispatch_i8259_irq() C function.  This can still be done with
a trivial wrapper like:

asmlinkage void foo_dispatch_i8259_irq(struct pt_regs *regs)
        do_IRQ(poll_8259A_irq(), regs);

which results in code like you proposed.

> What is wrong with original way of dispatching?  The general interrupt 
> dispatching flow is that you chase the routing path until you find the final
> source and do a do_IRQ().  That seems fine with i8259A case here.

 It does too much and is therefore useful for a single specific case only. 
I focused on handling the chip only and the resulting function may be used
however desired, including your specific case.  Not all platforms need to
want to call do_IRQ() immediately after getting an IRQ number, including
code already in existence. 

> While there is certain urge to create asm/i8259a.h file, if in the end all 
> there
> is two function declarations (i8259_init() and dispatch_i8259_irq()), it is 
> not
> really worth it.

 The header issue is orthogonal -- for lone init_i8259_irqs() it should
exist.  Otherwise you'll be doomed upon the next interface change.


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>