On Fri, Jun 17, 2005 at 01:00:20AM +0200, Andi Kleen wrote:
> On Thu, Jun 16, 2005 at 03:42:23PM -0700, Greg KH wrote:
> > On Thu, Jun 16, 2005 at 03:34:06PM -0700, Rajesh Shah wrote:
> > > On Tue, Jun 14, 2005 at 10:32:14PM -0700, Greg KH wrote:
> > > >
> > > > + for (i = 0; i < pci_mmcfg_config_num; ++i) {
> > > > + pci_mmcfg_virt[i].cfg = &pci_mmcfg_config[i];
> > > > + pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address, MMCONFIG_APER_SIZE);
> > >
> > > This will map 256MB for each mmcfg aperture, probably better
> > > to restrict it based on bus number range for this aperture.
> >
> > It should be 1MB per bus number, right?
Yes.
>
> It shouldn't make much difference anyways - we have plenty of vmalloc
> space on x86-64
>
Depends on how much you trust firmware :-). In the worst case, it
could create one such entry for each bus.
I noticed this because I worked on picking up resources for root
bridges from firmware recently, and noticed more than one system
in which firmware created ~10 entries for resources that were
adjacent to each other and could be coalesced into a single
resource range. Not illegal, just not optimal.
Rajesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
