linux-kernel - Re: [RFC PATCH] irq: handle private interrupt registration

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: <20100602054104.GE6465@nokia.com>
Date:	Wed, 2 Jun 2010 08:41:04 +0300
From:	Felipe Balbi <felipe.balbi@...ia.com>
To:	ext Thomas Gleixner <tglx@...utronix.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"adharmap@...eaurora.org" <adharmap@...eaurora.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	Pavel Machek <pavel@....cz>,
	Brian Swetland <swetland@...gle.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
	"t.fujak@...sung.com" <t.fujak@...sung.com>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>,
	David Brownell <david-b@...bell.net>,
	Daniel Ribeiro <drwyrm@...il.com>,
	"arve@...roid.com" <arve@...roid.com>,
	Barry Song <21cnbao@...il.com>,
	Russell King <linux@....linux.org.uk>,
	Bryan Huntsman <bryanh@...cinc.com>,
	Iliyan Malchev <malchev@...gle.com>,
	Michael Buesch <mb@...sch.de>,
	Bruno Premont <bonbons@...ux-vserver.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] irq: handle private interrupt registration

Hi,

On Wed, Jun 02, 2010 at 01:14:32AM +0200, ext Thomas Gleixner wrote:
>1) Use PER_CPU offsets for the irq numbers. The generic irq code does
>   not care whether the interrupt number is matching any physical
>   numbering scheme in the hardware, as long as the arch specific chip
>   implementation knows how to deal with it, which is not rocket
>   science to do.

FWIW, I think (1) is a better approach as the problem will vanish 
altogether and to me it sounds like the simpler approach as well. Archs 
which have more than one IRQ chip (like OMAP with the twl4030 family) 
will already use sequencial numbering anyway, so using the same approach 
for N cpus, to me, sounds like a good deal.

While at that, a question from my side: do we have a generic way of 
fetching the last IRQ number so we can easily use that to calculate the 
physical number of the IRQ line on the chip ?

On OMAP, we have been passing that number down to twl4030 via 
platform_data, but it would be better to ask genirq to tell us which was 
the last irq number "claimed".

-- 
balbi

DefectiveByDesign.org
--
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/