lkml.org 
[lkml]   [2007]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers


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
work.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-01-26 02:31    [W:0.062 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site