Re: Going beyond 256 PCI buses

David S. Miller
2001-06-14T14:25:23Z

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
davem@redhat.com