All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Zhengqiang <zhengqiang10@huawei.com>,
	mchehab@kernel.org, toshi.kani@hpe.com,
	linux-edac@vger.kernel.org, linuxarm@huawei.com,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: ghes_edac: enable HIP08 platform edac driver
Date: Mon, 14 May 2018 16:12:08 +0100	[thread overview]
Message-ID: <cb24735c-d251-4dd2-a02f-91e476776824@arm.com> (raw)

Hi Borislav,

(CC: +linux-arm list, just in case there is wider discussion)

On 14/05/18 10:47, Borislav Petkov wrote:
> On Mon, May 14, 2018 at 12:11:28PM +0800, Zhengqiang wrote:
>> In ARM64 defconfig, ghes_edac is default load. memory error report to
>> user space rasdaemon tool through function ghes_edac_report_mem_error,
>> we need it.
> 
> So depending on whether there will be an ARM64 edac driver, we can do

I'm afraid there could be a mix: The v8.2 CPU RAS Extensions mean the kernel can
do kernel first. (I agree for those systems there should only be one edac driver).
For systems without the v8.2 CPU RAS Extensions firmware-first is the only way
of doing it.


> the platform whitelisting on x86 only if ARM prefers to do the reporting
> through ghes_edac. James?

I'm afraid I'd like to keep both doors open. Kernel-first handling will require
some ACPI-table/DT property as some aspects of the CPU extensions aren't
discover-able. Can't we use this to pick up whether the platform supports
firmware-first (HEST and GHES entries) or kernel-first via some as-yet-undefined
HEST bits?

Without GHES entries this code would never be run. So we 'just' need to catch
systems that are describing both. (which can be the platform specific kernel
first bits problem to do)


Thanks,

James
---
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ghes_edac: enable HIP08 platform edac driver
Date: Mon, 14 May 2018 16:12:08 +0100	[thread overview]
Message-ID: <cb24735c-d251-4dd2-a02f-91e476776824@arm.com> (raw)
In-Reply-To: <20180514094709.GC23049@pd.tnic>

Hi Borislav,

(CC: +linux-arm list, just in case there is wider discussion)

On 14/05/18 10:47, Borislav Petkov wrote:
> On Mon, May 14, 2018 at 12:11:28PM +0800, Zhengqiang wrote:
>> In ARM64 defconfig, ghes_edac is default load. memory error report to
>> user space rasdaemon tool through function ghes_edac_report_mem_error,
>> we need it.
> 
> So depending on whether there will be an ARM64 edac driver, we can do

I'm afraid there could be a mix: The v8.2 CPU RAS Extensions mean the kernel can
do kernel first. (I agree for those systems there should only be one edac driver).
For systems without the v8.2 CPU RAS Extensions firmware-first is the only way
of doing it.


> the platform whitelisting on x86 only if ARM prefers to do the reporting
> through ghes_edac. James?

I'm afraid I'd like to keep both doors open. Kernel-first handling will require
some ACPI-table/DT property as some aspects of the CPU extensions aren't
discover-able. Can't we use this to pick up whether the platform supports
firmware-first (HEST and GHES entries) or kernel-first via some as-yet-undefined
HEST bits?

Without GHES entries this code would never be run. So we 'just' need to catch
systems that are describing both. (which can be the platform specific kernel
first bits problem to do)


Thanks,

James

             reply	other threads:[~2018-05-14 15:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 15:12 James Morse [this message]
2018-05-14 15:12 ` [PATCH] ghes_edac: enable HIP08 platform edac driver James Morse
  -- strict thread matches above, loose matches on Subject: below --
2018-05-22  2:10 EDAC, ghes: Make platform-based whitelisting x86-only Tyler Baicar
2018-05-22  2:10 ` [PATCH] " Tyler Baicar
2018-05-21 20:44 Borislav Petkov
2018-05-21 20:44 ` [PATCH] " Borislav Petkov
2018-05-21 20:34 Tyler Baicar
2018-05-21 20:34 ` [PATCH] " Tyler Baicar
2018-05-21 17:15 Borislav Petkov
2018-05-21 17:15 ` [PATCH] " Borislav Petkov
2018-05-21 13:48 Tyler Baicar
2018-05-21 13:48 ` [PATCH] " Tyler Baicar
2018-05-21  9:39 Zhengqiang
2018-05-21  9:39 ` [PATCH] " Zhengqiang
2018-05-18 11:20 Borislav Petkov
2018-05-18 11:20 ` [PATCH] " Borislav Petkov
2018-05-18 11:11 ghes_edac: enable HIP08 platform edac driver Borislav Petkov
2018-05-18 11:11 ` [PATCH] " Borislav Petkov
2018-05-18  7:13 Zhengqiang
2018-05-18  7:13 ` [PATCH] " Zhengqiang
2018-05-17 18:02 James Morse
2018-05-17 18:02 ` [PATCH] " James Morse
2018-05-16 18:29 Borislav Petkov
2018-05-16 18:29 ` [PATCH] " Borislav Petkov
2018-05-16 13:38 James Morse
2018-05-16 13:38 ` [PATCH] " James Morse
2018-05-14 16:47 Borislav Petkov
2018-05-14 16:47 ` [PATCH] " Borislav Petkov
2018-05-14  9:47 Borislav Petkov
2018-05-14  4:11 Zhengqiang
2018-05-11 12:19 Borislav Petkov
2018-05-11 11:52 Zhengqiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb24735c-d251-4dd2-a02f-91e476776824@arm.com \
    --to=james.morse@arm.com \
    --cc=bp@alien8.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mchehab@kernel.org \
    --cc=toshi.kani@hpe.com \
    --cc=zhengqiang10@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.