[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <15be95b0-4cb2-1cf1-2fc1-ec313b9aa6f0@linux.ibm.com>
Date: Thu, 29 Aug 2019 10:58:16 +0530
From: Hari Bathini <hbathini@...ux.ibm.com>
To: Michal Suchanek <msuchanek@...e.de>, linuxppc-dev@...ts.ozlabs.org
Cc: Yangtao Li <tiny.windzz@...il.com>,
Mahesh Salgaonkar <mahesh@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
Hari Bathini <hbathini@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2] powerpc/fadump: when fadump is supported register the
fadump sysfs files.
On 28/08/19 10:57 PM, Michal Suchanek wrote:
> Currently it is not possible to distinguish the case when fadump is
> supported by firmware and disabled in kernel and completely unsupported
> using the kernel sysfs interface. User can investigate the devicetree
> but it is more reasonable to provide sysfs files in case we get some
> fadumpv2 in the future.
>
> With this patch sysfs files are available whenever fadump is supported
> by firmware.
>
> Signed-off-by: Michal Suchanek <msuchanek@...e.de>
> ---
[...]
> - if (!fw_dump.fadump_supported) {
> + if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
> printk(KERN_ERR "Firmware-assisted dump is not supported on"
> " this hardware\n");
> - return 0;
> }
The above hunk is redundant with similar message already logged during
early boot in fadump_reserve_mem() function. I am not strongly against
this though. So...
Acked-by: Hari Bathini <hbathini@...ux.ibm.com>
Powered by blists - more mailing lists