lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Changing pci_iounmap to take 'bar' argument


On Thu, 26 May 2005, Benjamin Herrenschmidt wrote:
>
> foo = pci_iomap(dev, bar, pci_resource_len(dev, bar));

Btw, this kind of code should be just

foo = pci_iomap(dev, bar, 0);

because the third argument is _not_ a length, it's a _maximum_ length we
need to map, with zero meaning "everything" (as does ~0ul, of course, but
zero is obviously easier).

The only people who want to use non-zero are things like frame-buffers
that might have hundreds of megabytes of memory, but the kernel only needs
to map the actual thing visible on the screen.

> And in a completely different function, a simple
>
> pci_iounmap(dev, foo);
>
> It may be simpler indeed for me to actually only complicate the ppc &
> ppc64 pci_iounmap() implementation and have it compare the virtual
> address against known PCI IO spaces...

Yeah. It shouldn't be a problem on 64-bit architectures, and even on
32-bit ones the IO-port range really _should_ be fairly small, and a small
amount of special casing should hopefully fix it.

A lot of architectures end up having to separate PIO and MMIO anyway,
which is - together with hysterical raisins, of course - why the existing
interfaces just assumed that was possible.

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: 2009-11-18 23:46    [W:0.053 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site