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

[Vasant Hegde]

On 06/28/2019 04:40 PM, Nicholas Piggin wrote:
> 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?

Well, I don't really gain anything with either approach. IMO single API is 
better as its easy to manage one (and document just one API :-) )

-Vasant