linux-kernel - Re: Q40 interrupts (and genirq)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110823221631.GA6827@rz>
Date:	Wed, 24 Aug 2011 00:16:31 +0200
From:	Richard <rz@...ux-m68k.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Linux/m68k <linux-m68k@...r.kernel.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Q40 interrupts (and genirq)

Hi Geert,

> I'm a bit puzzled by the Q40 interrupt architecture.
> 
> arch/m68k/q40/q40ints.c says:
> 
>  * Q40 IRQs are defined as follows:
>  *            3,4,5,6,7,10,11,14,15 : ISA dev IRQs
> 
> Yep, that's _9_ interrupts.

11 conflicts with q40_irq_startup() but I am not quite sure at the moment which
one is right. Iirc some of the irqs are shared/indistinguishable as sources but were
still defined both separately just in case the number is needed.

> In the "new" interrupt code, by Roman Zippel, all interrupts sources are handled
> through q40_irq_handler().
> Only autovector IRQs IRQ_AUTO_2 and IRQ_AUTO_4 are enabled.
> 
> In the old (pre-2006) interrupt code, only internal (master) and ISA interrupts
> go through q40_irq2_handler on IRQ_AUTO_2.
> Q40_IRQ_SAMPLE goes via both IRQ_AUTO_4 and IRQ_AUTO_6.
> 
> Why doesn't the new code use IRQ_AUTO_6? Does the new code work?

iirc IRQ_AUTO_6 was needed for some very early versions of the master chip,
should work without. 

I will need to verify this points but don't have the HW manual right here.

> For the genirq conversion, I was first thinking about using a custom
> chain-alike flow handler.
> But it looks like this is not possible, as the Q40 handler remaps
> autovector interrupts to
> conflicting numbers (it handles IRQ_AUTO_4 = 4, but ISA interrupt 4 is also 4).
> So if the custom flow handler would call generic_handle_irq(4) for ISA
> interrupt 4,
> it would recurse into the flow handler set up for autovector IRQ 4 :-(

The numbers are equal but they mean different things at different stages 
of abstraction/translation/mapping which is normally no concern as long as 
it is clear at which stage it is. 

Perhaps the new algorithm would need an extra flag to keep track of what it
is dealing with. 
What are the problems you are trying to solve with the new handler?

For the Q40, IRQ_AUTO_4 should be translated to "34   : sample int (10/20 KHz periodic timer)"
IRQ_AUTO_2 needs further decoding before it can be decided what should be handled. 
It can be any of the ISA irqs or one of 32,33.

So as long as ISA drivers can use the numbers 1-15 and the Q40 specific
drivers 32-34 nothing there should not be a problem

> Changing the numbers is not trivial, as ISA assumes interrupts 1-15 everywhere.

indeed, would be a major incovenience.

Richard

---
Name and OpenPGP keys available from pgp key servers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/