Re: Going beyond 256 PCI buses

[David S. Miller]

Jeff Garzik writes:
 > According to the PCI spec it is -impossible- to have more than 256 buses
 > on a single "hose", so you simply have to implement multiple hoses, just
 > like Alpha (and Sparc64?) already do.  That's how the hardware is forced
 > to implement it...

Right, what userspace had to become aware of are "PCI domains" which
is just another fancy term for a "hose" or "controller".

All you have to do is (right now, the kernel supports this fully)
open up a /proc/bus/pci/${BUS}/${DEVICE} node and then go:

	domain = ioctl(fd, PCIIOC_CONTROLLER, 0);

Viola.

There are only two real issues:

1) Extending the type bus numbers use inside the kernel.

   Basically how most multi-controller platforms work now
   is they allocate bus numbers in the 256 bus space as
   controllers are probed.  If we change the internal type
   used by the kernel to "u32" or whatever, we expand that
   available space accordingly.

   For the lazy, basically go into include/linux/pci.h
   and change the "unsigned char"s in struct pci_bus into
   some larger type.  This is mindless work.

2) Figure out what to do wrt. sys_pciconfig_{read,write}()

   They ought to really be deprecated and the /proc/bus/pci
   way is the expected way to go about doing these things.
   The procfs interface is more intelligent, less clumsy, and
   even allows you to mmap() PCI cards portably (instead of
   doing crap like mmap()s on /dev/mem, yuck).

   Actually, there only real issue here is what happens when
   userspace does PCI config space reads to things which talk
   about "bus numbers" since those will be 8-bit as this is a
   hardware imposed type.  These syscalls take long args already
   so they could use >256 bus numbers just fine.

Basically, this 256 bus limit in Linux is a complete fallacy.

Later,
David S. Miller
[e-mail]