lkml.org 
[lkml]   [1999]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: More linker magic..


On Fri, 6 Aug 1999, David Hinds wrote:
>
> A couple questions / things to think about...
>
> - I see that you've done away with the old /proc/pci

I haven't. Martin wants to get rid of it, but I actually like it, and
don't see it hurting.

The PCI names are _also_ used to name the IO resources for /proc, quite
regardless of /proc/pci.

So I'm going to try to make sure that the kernel lists are kept
up-to-date, and I made the format easier to do that in. If Martin doesn't
want to do it, somebody else will.

> - There are PCI devices with additional resources that aren't covered
> by the base address registers. They can be handled in the PCI fixup
> code, but I'm not sure about where to put their resource structures.

I've thought about it. I considered adding a "fixup" entry to the same
device table that holds the name, but that may be overkill, so I haven't
decided.

Usually the resources that aren't covered by the regular PCI registers are
"motherboard resources", ie usually things like the southbridge extensions
etc, and they show up in the IO region 0-0x3ff. I suspect that we can
avoid most common problems simply by making sure that we don't allocate
any new dynamic areas in this region unless we just know that something is
at that address.

> The devices I know about like this don't use some/most of their base
> address registers, so we could just use those unused structures??
> Or will this cause trouble??

I suspect we might just want to extend the device structure to have more
than the "standard PCI" resources - I'd hate to play games with them.

Linus


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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.275 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site