Re: Going beyond 256 PCI buses

[Jonathan Lundell <jlundell@pobox.com>]

At 7:24 AM -0700 2001-06-14, David S. Miller wrote:
>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.

There's also the question of pci_ops() (PCI config space access 
routines). Alpha (titan in this example) uses:

	struct pci_controler *hose = dev->sysdata;

but the general idea is that you need the hose info to do 
config-space access on PCI.

The 256-bus fallacy is caused in part by an ambiguity in what we mean 
by "bus". In PCI spec talk, a bus is a very specify thing with an 
8-bit bus number, and this is reflected in various registers and 
address formats. On the other hand we have the general concept of 
buses, which includes the possibility of multiple PCI controllers, 
and thus multiple domains of 256 buses each.

As I recall, even a midline chipset such as the ServerWorks LE 
supports the use of two north bridges, which implies two PCI bus 
domains.

I'd favor adopting something like the Alpha approach, but with a 
dedicated struct pci_device item (and with "controller" spelled 
correctly). And I suppose "domain" sounds a little more sober than 
"hose". But since the domain information is necessary to access 
configuration registers, it really needs to be included in struct 
pci_device.
-- 
/Jonathan Lundell.