[PATCH v5 11/31] powernv/fadump: add fadump support on powernv

[Michael Ellerman]

Hari Bathini <hbathini at linux.ibm.com> writes:
> On 03/09/19 10:01 PM, Hari Bathini wrote:
>> 
> [...]
>>>> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
>>>> index f7c8073..b8061fb9 100644
>>>> --- a/arch/powerpc/kernel/fadump.c
>>>> +++ b/arch/powerpc/kernel/fadump.c
>>>> @@ -114,6 +114,9 @@ int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
>>>>  	if (strcmp(uname, "rtas") == 0)
>>>>  		return rtas_fadump_dt_scan(&fw_dump, node);
>>>>  
>>>> +	if (strcmp(uname, "ibm,opal") == 0)
>>>> +		return opal_fadump_dt_scan(&fw_dump, node);
>>>> +
>>>
>>> ie this would become:
>>>
>>> 	if (strcmp(uname, "ibm,opal") == 0 && opal_fadump_dt_scan(&fw_dump, node))
>>>             return 1;
>>>
>> 
>> Yeah. Will update accordingly...
>
> On second thoughts, we don't need a return type at all here. fw_dump struct and callbacks are
> populated based on what we found in the DT. And irrespective of what we found in DT, we got
> to return `1` once the particular depth and node is processed..

True. It's a little unclear because you're looking for "rtas" and
"ibm,opal" in the same function. But we know™ that no platform should
have both an "rtas" and an "ibm,opal" node, so once we find either we
are done scanning, regardless of whether the foo_fadump_dt_scan()
succeeds or fails.

cheers