linux-kernel - Re: [PATCH] ata: Don't use NO_IRQ in pata_of

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:	Tue, 6 Dec 2011 10:55:03 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Dave Martin <dave.martin@...aro.org>
Cc:	Rob Herring <robherring2@...il.com>,
	Anton Vorontsov <cbouatmailru@...il.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Pawel Moll <pawel.moll@....com>,
	devicetree-discuss@...ts.ozlabs.org,
	LKML <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jgarzik@...hat.com>, linux-ide@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>,
	linux-next@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jonas Bonn <jonas@...thpole.se>,
	Michal Simek <monstr@...str.eu>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver

On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
> 
> Those drivers would be pain points since they would need to understand
> both conventions.
> 
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ.  Tracking down exactly
> which boards and drivers this applies to could be hard.  We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.

You're digging too deeply into this.

Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'.  These are the drivers which have problems because of the -1 vs
0 thing.

That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().

So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't.  We just need to make sure that we're not passing a zero IRQ
number to any driver.

On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.

So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer.  Everything else should
not pass IRQ0 outside core platform code.
--
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/