Re: RFC: Changes for PCI

[Todd Inglett <tinglett@vnet.ibm.com>]

"David S. Miller" wrote:
> 
> Tom Gall writes:
>  >   The first part changes number, primary, and secondary to unsigned ints from
>  > chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
>  > pci controller in with the bus number. In our case we do it like this:
>  >
>  > pci_controller=dev->bus->number>>8) &0xFF0000
>  > bus_number= dev->bus->number&0x0000FF),
>  >
>  >   Is this reasonable for everyone?
> 
> This is totally unreasonable.

Well, back in the "Going beyond 256 PCI buses" thread two weeks ago when
you argued that Linux not supporting >256 busses was a fallacy...

"David S. Miller" wrote:
> 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. 

Yes it is mindless work and is in that patch.  Should we attempt to go
beyond 256 physical busses in 2.4?  Maybe not.  But it is a simple
change and it does work and it works around the existing drivers which
compare busid+devfn for uniqueness when they really should compare
pci_dev pointers.  Should it be redone the correct way (domains) in
2.5?  Absolutely.

The patch does not handle the user mode case.  This leaves the X server
broken.  We could probably weed out busses beyond 256 under
/proc/bus/pci as a workaround -- meaning the video adapter (if any --
rare in these boxes) must be in one of the first I/O drawers.

The added pci_op functions are probably not needed if the code probes
ahead in pcibios_fixup_bus().

> What you want are PCI domains.

Correct.  This is 2.5.

-- 
-todd