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] [day] [month] [year] [list]

Date:	Thu, 25 Aug 2011 12:13:22 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Richard <rz@...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 Richard,

On Wed, Aug 24, 2011 at 00:16, Richard <rz@...ux-m68k.org> wrote:
>> 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?

I'm solving the problem that m68k still doesn't use genirq (and is the single
architecture still doing so, except for s390, which is "different" anyway).

> 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

Thanks! This confirms my findings.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/