All of
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: David Woodhouse <>
Cc: Alan <>, Jeff Garzik <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers
Date: Thu, 25 Jan 2007 17:28:32 -0800 (PST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 26 Jan 2007, David Woodhouse wrote:
> You're thinking of MMIO, while the case we were discussing was PIO. My
> laptop is perfectly happy to assign PIO resources from zero.

I was indeed thinking MMIO, but I really think it should extend to PIO 
also. It certainly is (again) true on PC's, where the low IO space is 
special and reserved for motherboard/system devices.

If you want to be different, that's YOUR problem. Some architectures have 
tried to look different, and then drivers break on them, but they have 
only themselves to blame.

> I believe PCMCIA just uses the generic resource code, which also seems
> to lack any knowledge of this hackish special case for zero.

The resource code actually knows what "enabled" means. A lot of other code 
does not.

> > kernel and all devices are concerned, "!dev->irq" means that the irq 
> > doesn't exist or hasn't been mapped for that device yet).
> So again you end up in a situation where zero is a strange special case.

No. We end up in a situation where *drivers* never have any strange or 
special cases. 

You need to have a "no irq" thing. It might as well be zero, since that is 
not just the de-facto standard, it's also the one and only value that 
leads to easily readable source-code (ie test it as a boolean in C).

The exact same thing has been true of MMIO. I would be not at all 
surprised if several drivers do the same for PIO.

It's something you can trust on a PC. See above on your problems if you 
decide that you want to be "generic" and use a value that is illegal on 
99% of all hardware.

> It doesn't need to be per-architecture; it can just be -1.

Bollocks. People tried that. People tried to force this idiotic notion of 
"NO_IRQ" down my throat for several years. I even accepted it.

And then, after several years, when it was clear that it still didn't 
work, and drivers just weren't getting updated, it was time to just face 
reality: if the choice is between 0 and -1, 0 is simply much easier for 
the bulk of the code.

Live with it, or don't. I really don't care what you do on your hardware. 
But if you can't face that

	if (!dev->irq)

is simpler for people to write, and that it's what we've done for a long 
time, then that really is YOUR problem.

The exact same issues have been true in MMIO. Some code will keep track of 
separate "enabled" bits: the resource management code is such code. Guess 
what? Not a lot of drivers tend to do that. You can try to fight 
windmills, or you can just accept that the very language we use (namely, 
C) has made 0 be special, and tends to be used to say "nobody home" simply 
because it has that special meaning for a C compiler.

And I bet there are PIO devices out there that consider address zero to be 
disabled. For EXACTLY the same reason.

(And yes, hardware actually tends to do the same thing. For PCI irq 
routing registers, an irq value of 0 pretty much universally means 
"disabled". In fact, even your lovely Cardbus example actually is an 
example of exactly this: the very IO limit registers are DEFINED IN 
HARDWARE to special-case address zero - so that making the base/limit 
registers be zero actually disables the IO window, rather than making it 
mean "four IO bytes at address zero").

But hey, if it works for you, go wild. Just don't expect drivers to always 


  reply	other threads:[~2007-01-26  1:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 15:09 [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers Alan
2007-01-25 16:14 ` David Woodhouse
2007-01-25 16:17   ` Jeff Garzik
2007-01-25 16:19     ` David Woodhouse
2007-01-25 16:22     ` Russell King
2007-01-25 16:26       ` David Woodhouse
2007-01-25 17:27   ` Alan
2007-01-25 17:56     ` Linus Torvalds
2007-01-26  0:23       ` David Woodhouse
2007-01-26  1:28         ` Linus Torvalds [this message]
2007-01-26  1:45           ` Jeff Garzik
2007-01-26  2:01             ` Linus Torvalds
2007-01-26  2:11               ` Jeff Garzik
2007-01-26 10:37               ` Alan
2007-01-28 23:01               ` Benjamin Herrenschmidt
2007-01-28 22:57             ` Benjamin Herrenschmidt
2007-01-26  2:23           ` David Woodhouse
2007-01-26  2:58             ` Linus Torvalds
2007-01-26  3:28               ` David Woodhouse
2007-01-26  4:00                 ` Linus Torvalds
2007-01-26  4:19                   ` David Woodhouse
2007-01-26  4:48                     ` Linus Torvalds
2007-01-26  5:09                       ` David Woodhouse
2007-01-26  6:01                         ` Linus Torvalds
2007-01-26  6:18                           ` Linus Torvalds
2007-01-26  8:17                             ` David Miller
2007-01-26  8:20                         ` David Miller
2007-01-26  4:53                 ` Jeff Garzik
2007-01-26 15:32                 ` Mark Lord
2007-01-26 15:29               ` Mark Lord
2007-01-28 23:04               ` Benjamin Herrenschmidt
2007-01-28 22:49       ` Benjamin Herrenschmidt
2007-01-25 23:36 ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.