mptables and missing devices

[Eric W. Biederman]

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [030929 23:48]:
> > > > is there a reason why the mptable creation uses dev_find_slot()
> > > > to find the bridges instead of dev_find_device()? Since it does
> > > > not even check whether the device it finds is the one it wants
> > > > this sounds rather dangerous.
> > 
> > In the case of a specific motherboard it is safe, as long as all of 
> > the upper level bridges are taken into account.  dev_find_device,
> > is worse because you may have two devices with the same vendor
> > and device id.
>  
> But you can give it a starting point, and you probably want entries for
> both of them anyways...?
> 
> > It is on the todo list to generate all of this by walking the device
> > tree.  What we have now is a place holder that let's LinuxBIOS work
> > until we have generic code that will work for everyone.
>  
> Ok.. I think it's pretty easy doable if the bus number registers of the
> bridges are filled reliably. Is this the case?

Yes.  And the bus number values are also in the device tree.  Which
is where it would be better to read them from.  Just in case we have
a non-standard pci bus.  Like the Opteron's multiple host bridges
off of one cpu.

> > > Is this an internal convention, a hardware rule or just common sense
> > > that the ISA bus is the last bus in the mptable? An ISA bus has no 
> > > bus number in the PCI view of things, does it?
> > 
> > Right.  A lot of this was modeled on how existing mptables are setup.
> > I am not certain there needs to be a 1-1 mapping from bus numbers on
> > the pci bus to other bus numbers but it can't hurt.  And the ISA can
> > pretty much go anywhere else.
>  
> Hanging it at the end of the list should not hurt then as it keeps all
> the rest of constant.

Yes.

> > >         /* ISA backward compatibility interrupts  */
> > >         smp_write_intsrc(mc, mp_ExtINT, 
> > >                 MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT,
> > >                 bus_isa, 0x00, 0x02, 0x00);
> > >         ...
> > 
> > Almost. Interrupts off of the LPC/ISA bus are the same because the bus
> > generates them.   PCI interrupts that are routed through 8259 also vary.
> > I think the irq controller can also vary.   Although it may be special
> > cased.
>  
> So the above works only if you use an ioapic? at least for opteron/linux
> this is always the case. Linux/x86_64 wont boot with no ioapic enabled.

Yes.  The MPtables are IOAPIC specific.

> > It must be left over.  I have it yanked out of my tree.  After I finish
> > catching up on my email I will start synching the tress and kill it.
>  
> please do!! ;)
> 
> > > The interrupt src entries for the different PCI slots confuse me a bit..
> > > Is there a way to find out in the system how many pci slots a bridge
> > > has, or should the bridge entry in the config file get an entry similar to:
> > >         register "slots" = 2
> > 
> > We should probably hang a ``slot'' device of the device tree to model this.
>  
> this is in the openfirmware kind of view a device node vs node property
> consideration. Does a single slot need more information than the fact
> that it's there?

Yes.  Which the irq routing information.

> > All pci bridges have a maximum of 32 devices behind them.  And we need to know
> 
> > which ones are actually devices.
> 
> We get that information during bus enumeration already, don't we?

For the most part yes.  But an empty slot won't show up.  So at
least in the hot-plug case we need to force it's information to be present.

Saying to much is better than saying to little.

Eric