Re: 2.6.25-rc8-mm1 panic in rpaphp_register_slot()

[Alex Chiang <achiang@hp.com>]

* Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> 
> On Sat, 2008-04-19 at 00:38 -0600, Alex Chiang wrote:
> > So I'm not sure how much we can use of your slot infrastructure, I'll
> > have
> > > to look, I suspect it can cover some cases but not all of them.
> > 
> > *poke*
> > 
> > Any update on this?
> > 
> > Anything I can do to help?
> 
> Not yet no. I've looked a bit, but ran out of time, I'll look more this
> week-end or next week. I'm also trying to figure out who in IBM is
> responsible for that hotplug stuff so they can get involved too.
> 
> BTW. How would you do if the answer was we simply can't declare hotplug
> "slots" ? ie. if I end up finding out (which is what I think will
> happen) that there is simply no way for us to know in advance any
> concept of "slot" with a devfn for hotplug ?

Hm, I may be getting lost in the twisty maze of pseries, but I
guess I don't really understand this statement.

Today, before calling rpaphp_register_slot, we first call
rpaphp_enable_slot. rpaphp_enable_slot makes a call to
pcibios_find_pci_bus which must succeed before we ever try to
register the slot.

So if there is a pci_bus, then it must have a ->self, which means
it has a ->devfn. Right?

Are you saying that it is not accurate to use this
pci_bus->self->devfn to keep track of slots?

> Basically, when doing hotplug, the hypervisor sends us new bits of
> device-tree with things potentially ranging from host bridges, P2P
> bridges to devices, but I'm not certain at this stage we can know in
> advance where they'll hook up (in fact, for PHBs, we can't for sure) and
> thus even if we end up supporting hotplug of actual slots, we don't even
> know in advance the devfn where devices will appear. It's all hidden
> from us by the hypervisor.
> 
> How would that fit in your infrastructure ? Can we just disable usage of
> your slots abstraction in our case ?

I suppose you could just pass in 0 as slot_nr/devfn. That is what
my fixup patch did if it couldn't find a pci_bus->self. The
result would be that for a given pci_bus, you would only see the
first "slot" with this 0 slot_nr appear in sysfs, and it would
have whatever name originally associated with your dn.

I think if I were to understand more about this issue, we could
figure out a better solution...

thanks,

/ac