[Skiboot] [PATCH v10 16/17] core/opal: Use PCI slot and new APIs for slot states

Stewart Smith stewart at linux.vnet.ibm.com
Fri May 13 10:59:15 AEST 2016

Gavin Shan <gwshan at linux.vnet.ibm.com> writes:
> On Thu, May 12, 2016 at 04:13:58PM +1000, Stewart Smith wrote:
>>Alistair Popple <alistair at popple.id.au> writes:
>>>> +	rc = slot->ops.set_power_status(slot, *power_state);
>>> As we discussed offline there needs to be much better separation of the
>>> platform specific parts and the generic parts of setting the power state.
>>> At the moment the calls to update device tree, etc. are all in the platform
>>> specific code but they should really appear here as it will apply to all platforms
>>> that eventually support hotplug. The platform specific code should only deal with
>>> platform dependent functions such as actually removing power from the slots which
>>> is completely different on say an FSP system versus a non-FSP system.
>>My thought that is for P9 (as we can change ABI to kernel there :) we
>>could *always* hotplug - detect nothing before starting linux, just hotplug
>>it all in at runtime.
> It's a intresting idea. Before discussing it further, I have to understand
> your idea. Stewart, could you please confirm below is something you want
> to see?
> (A) skiboot boots without PCI enumeration. It means no device nodes for
>     PCI devices are created;
> (B) kernel is loaded and booted. Prior to PCI enumeration, the PHB is
>     hot added by OPAL API. After the OPAL API finishes, the PCI devices
>     behind the PHB is probed and the device nodes are created. After
>     that, the Linux PCI subsystem starts the enumeration.

We could at least provide PHBs to linux and hotplug everything beneath

But yes, basically, that flow.

> A serious question is: what's the benefit from it? On the other hand,
> It's going to change current PCI subsystem (skiboot) greatly. That part
> written by Ben works well.

and I don't want to break what works.

My most naive implementation idea would be to have pci_scan_phb() jobs
run asynchronously to linux, with linux calling into OPAL until that's
done, and then as long as linux can understand the new hungs of DT being
passed to it, we may just win on boot time a bit - or at least on
*perceived* boot time :)

Stewart Smith
OPAL Architect, IBM.

More information about the Skiboot mailing list