[Skiboot] [PATCH] occ: hbrt: Change the OCC reset order
Stewart Smith
stewart at linux.vnet.ibm.com
Wed Oct 14 17:17:42 AEDT 2015
Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
> Modify the OCC reset order such that master OCC is reset after the
> slave OCCs are reset. In Tuleta/Alpine systems 'proc0' will always be
> the master OCC, which has to be stopped last when FSP sends OCC_RESET
> command to Opal.
Is this also true for all OpenPower machines?
What about for Venice and Naples (and other future chips)?
(and why would we be asked to stop OCCs anyway I wonder... in what
circumstances does this happen?)
I'd *much* prefer us to have a way programatically to work this out
rather than just assuming - it smells like a way to get this subtley
incorrect on random future machines.
also, isn't for_each_chip() in chip-id order anyway? next_chip() (used
by for_each_chip) does go in-order through the chips[] array which is
referenced by chip id, so I wonder why the sort is needed.
your thoughts?
More information about the Skiboot
mailing list