Re: RFC: Changes for PCI

[Jeff Garzik]

Todd Inglett wrote:
> 
> "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.

2.5 is right around the corner, and sysdata should handle PCI
domains/segments just fine in 2.4.

Why do we need to patch 2.4 at all right now?   Since 2.5 is close I
don't think it's a big deal saying "use 2.5+ for >256 physical buses"

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |