[Skiboot] [PATCH v8 12/24] MPIPL: Add OPAL API to register for dump

[Nicholas Piggin]

Vasant Hegde's on June 28, 2019 8:13 pm:
> On 06/28/2019 07:09 AM, Nicholas Piggin wrote:
>> Vasant Hegde's on June 17, 2019 3:10 am:
>>> This patch add new API to register for dump.
>>>    u64 opal_mpipl_update(u8 ops, u64 src, u64 dest, u64 size)
>>>
>>>    ops :
>>>      OPAL_MPIPL_REGISTER_TAG
>>>        Kernel metadata pointer. Kernel will send this to OPAL during MPIPL
>>>        registration. Post MPIPL, kernel will request for this tag via
>>>        mpipl_query_tag API.
>>>          src  = kernel metadata address
>>>          dest = ignore
>>>          size = ignore
>>>
>>>      OPAL_MPIPL_ADD_RANGE
>>>        Add new entry to MPIPL table. Kernel will send src, dest and size.
>>>        During MPIPL content from source address is moved to destination address.
>>>          src  = Source start address
>>>          dest = Destination start address
>>>          size = size
>>>
>>>      OPAL_MPIPL_REMOVE_RANGE
>>>        Remove kernel requested entry from MPIPL table.
>>>          src  = Source start address
>>>          dest = Destination start address
>>>          size = ignore
>>>
>>>      OPAL_MPIPL_REMOVE_ALL
>>>        Remove all kernel passed entry from MPIPL table.
>>>          src  = ignore
>>>          dest = ignore
>>>          size = ignore
>>>
>>>      OPAL_MPIPL_FREE_PRESERVED_MEMORY
>>>        Post MPIPL, kernel will indicate OPAL that it has processed dump and
>>>        it can clear/release metadata area.
>>>          src  = ignore
>>>          dest = ignore
>>>          size = ignore
>>>
>>> Return values:
>>>    OPAL_SUCCESS   : Operation success
>>>    OPAL_PARAMETER : Payload passed invalid data
>>>    OPAL_RESOURCE  : Ran out of MDST or MDDT table size
>>>    OPAL_HARDWARE  : MPIPL not supported
>> 
>> Thanks very much for working on this, I'm a lot happier with the API
>> now. It would be important if everybody interested can take a look at
>> the proposed DT and OPAL call APIs even if you aren't able to review
>> code and details carefully.
>> 
> 
> Thanks!
> 
>> Do we undo a level of indirection and make each of these options its
>> own OPAL_ call? I think that would be nicer and you'd get proper
>> parameters, etc.
> 
> I don't think we gain much from individual APIs compared to what we have now.

You get proper prototype types though, so the question is what do
you gain from having a multiplexer API?

Thanks,
Nick