linux-kernel - Re: m68k: Convert to genirq (WIP)

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]

Date:	Wed, 10 Aug 2011 11:59:08 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Brad Boyer <flar@...andria.com>
Cc:	Finn Thain <fthain@...egraphics.com.au>,
	"Linux/m68k" <linux-m68k@...ts.linux-m68k.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: Re: m68k: Convert to genirq (WIP)

On Sun, Jun 5, 2011 at 08:27, Brad Boyer <flar@...andria.com> wrote:
> If we could really map all the interrupt controllers, we could probably
> cut down on the largest interrupt number. Most Macs really only have
> 20 or 30 actual interrupt sources. The problem is the two or three
> layers of cascaded mess. None of them have just a single layer. Just
> getting rid of the fixed global mapping could take us down to 64 since
> nothing has both Baboon and PSC, but we have unique numbers for them.
> We have 3 whole blocks of 8 just for PSC, even though that's just in
> two models. We don't even know what most of those do, if anything.

While looking into optimizing interrupts using chain handlers (which cannot
be shared), I noticed several of these cascades are hung on the same interrupt.
Hence we cannot use the optimization of chain handlers for them.

Knowing which are mutually exclusive helps a lot, but my Mac knowledge is
very limited.

I derived from the code this list of cascade handlers and the
interrupts they use:

baboon_irq
    IRQ_NUBUS_C

oss_irq
    OSS_IRQLEV_SCSI = IRQ_AUTO_2                conflict: via2_irq
    OSS_IRQLEV_SOUND = IRQ_AUTO_5               conflict: psc_irq

oss_nubus_irq
    OSS_IRQLEV_NUBUS = IRQ_AUTO_3               conflict: psc_irq

psc_irq
    IRQ_AUTO_3                                  conflict: oss_nubus_irq
    IRQ_AUTO_4
    IRQ_AUTO_5                                  conflict: oss_irq
    IRQ_AUTO_6                                  conflict: via1_irq

via1_irq
    OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq

    IRQ_AUTO_1                                  conflict: iop_ism_irq
    IRQ_AUTO_6 (if via_alt_mapping)             conflict: psc_irq

via2_irq
    IRQ_AUTO_2                                  conflict: oss_irq

via_nubus_irq
    IRQ_MAC_NUBUS = IRQ_VIA2_1

These are other interrupts using in the Mac core code, which may use the same
interrupts as some of the cascades above:

iop_ism_irq
    OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
    IRQ_VIA2_0 (on !oss)

mac_nmi_handler
    IRQ_AUTO_7

timer handler
    IRQ_MAC_TIMER_1 = IRQ_VIA1_6

So baboon and PSC are mutually exclusive? But they don't conflict w.r.t. to
interrupt lines anyway, so they're not an issue.

>From the code, OSS and VIA are also mutually exclusive (except for via1_irq)?

But PSC can coexist with OSS? That's where most of the conflicts are.

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/