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: <4731C71A.4000406@rtr.ca>
Date:	Wed, 07 Nov 2007 09:09:30 -0500
From:	Mark Lord <lkml@....ca>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	linuxsh-dev@...ts.sourceforge.net
Subject: Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

Paul Mundt wrote:
> On Wed, Nov 07, 2007 at 01:09:40PM +0000, Alan Cox wrote:
>> On Wed, 7 Nov 2007 17:10:52 +0900
>> Paul Mundt <lethal@...ux-sh.org> wrote:
>>> By default ata_host_activate() expects a valid IRQ in order to
>>> successfully register the host. This patch enables a special case
>>> for registering polling-only hosts that either don't have IRQs
>>> or have buggy IRQ generation (either in terms of handling or
>>> sensing), which otherwise work fine.
>>>
>>> Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
>>> and pass in a NULL IRQ handler or invalid (< 0) IRQ.
>> NAK
>>
>> Zero is "no IRQ", please use that for polling not "< 0"
>>
> However, platform_get_irq() will happily return IRQ#0, and it's a valid
> vector on plenty of machines. NO_IRQ is also < 0 on at least FR-V, ARM,
> blackin, PA-RISC, some PowerPC, and even IDE.

Too bad.  The Penultimate Penguin wants zero to continue to mean "no IRQ".

Dig into the archives for multiple threads on this exact topic.
The end result is that "0" means "no IRQ".  If your physical IRQ actually
is the number 0, then reencode it to some other value for this purpose.

Yes, a bit of pain, but that's how many parts of the kernel expect it,
and in the end it's no more overall hassle than doing it differently might
have been.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ