linux-kernel - Re: [RFC PATCH] microblaze/irq: Change NO

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

Message-ID: <CA+55aFzz2SMvKJcRzOU0+Rd1MHMtygTmT9rDcyy7qGjuVFJKHg@mail.gmail.com>
Date:	Wed, 7 Dec 2011 08:05:49 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	Michal Simek <monstr@...str.eu>, John Linn <John.Linn@...inx.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Ingo Molnar <mingo@...e.hu>, Jeff Garzik <jgarzik@...hat.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	devicetree-discuss@...ts.ozlabs.org,
	LKML <linux-kernel@...r.kernel.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Anton Vorontsov <anton.vorontsov@...aro.org>
Subject: Re: [RFC PATCH] microblaze/irq: Change NO_IRQ to 0

On Wed, Dec 7, 2011 at 6:41 AM, Rob Herring <robherring2@...il.com> wrote:
>
> This patch changes the Microblaze NO_IRQ setting from -1 to 0 to bring
> it in line with most of the rest of the kernel.  It also prepares for
> Microblaze eventually supporting multiple interrupt controllers by
> breaking the assumption that hwirq# == Linux IRQ#.  The Linux IRQ
> number is just a cookie with no guarantee of a direct relationship
> with the hardware irq arrangement.

This looks really nice and would probably be a great example for other
architectures with the same issue.

My only (small) nit is that just from a debuggability standpoint I'd
actually suggest keeping the "translated" and "hardware" interrupt
numbers totally disjoint, which would seem to be trivial - make the
offset be 32 instead of 1. Sure, some NR_IRQ arrays would end up being
a bit bigger that way, but it would allow for trivially seeing whether
anybody reports the raw or translated irq numbers by just looking at
the number. That could reduce lots of confusion if somebody ends up
having the old non-translated number hardcoded etc.

It would also potentially allow for actual debug checks - having code
like "WARN_ON_ONCE(irq < 32)" in some arch-specific irq controller
registration path etc, which is much harder to do with the overlapping
numbers.

But it's nice to see how small the patch *can* be.

               Linus
--
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/