All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: James Morse <james.morse@arm.com>
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 18:47:20 +0200	[thread overview]
Message-ID: <20180514164720.GH23049@pd.tnic> (raw)

On Mon, May 14, 2018 at 04:12:08PM +0100, James Morse wrote:
> 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?

So how you detect those platforms is largely undefined as we're walking
new grounds here with the FF crap on the one hand and platform-specific
drivers on the other. So whatever works for you and as long as the
ugliness is nicely hidden. :-)

> 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)

So the reason why we're doing this on x86 is that the majority of
GHES-advertizing platforms out there are a serious turd when it comes
to functioning fw.

So we've opted for known-good platforms list where there's backing from
the vendor to have firmware which is getting fixes and is being tested
properly.

And everything else we assume is crap. Thus we use the platform-specific
EDAC driver which we know it works and we can fix if there's an issue.
VS firmware which we can't. (I doubt anyone can, for that matter. :)...)

Anyway, this is the story in x86 land. JFYI guys in case it helps making
some decisions.

Thx.

WARNING: multiple messages have this Message-ID (diff)
From: bp@alien8.de (Borislav Petkov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ghes_edac: enable HIP08 platform edac driver
Date: Mon, 14 May 2018 18:47:20 +0200	[thread overview]
Message-ID: <20180514164720.GH23049@pd.tnic> (raw)
In-Reply-To: <cb24735c-d251-4dd2-a02f-91e476776824@arm.com>

On Mon, May 14, 2018 at 04:12:08PM +0100, James Morse wrote:
> 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?

So how you detect those platforms is largely undefined as we're walking
new grounds here with the FF crap on the one hand and platform-specific
drivers on the other. So whatever works for you and as long as the
ugliness is nicely hidden. :-)

> 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)

So the reason why we're doing this on x86 is that the majority of
GHES-advertizing platforms out there are a serious turd when it comes
to functioning fw.

So we've opted for known-good platforms list where there's backing from
the vendor to have firmware which is getting fixes and is being tested
properly.

And everything else we assume is crap. Thus we use the platform-specific
EDAC driver which we know it works and we can fix if there's an issue.
VS firmware which we can't. (I doubt anyone can, for that matter. :)...)

Anyway, this is the story in x86 land. JFYI guys in case it helps making
some decisions.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

             reply	other threads:[~2018-05-14 16:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 16:47 Borislav Petkov [this message]
2018-05-14 16:47 ` [PATCH] ghes_edac: enable HIP08 platform edac driver Borislav Petkov
  -- 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 15:12 James Morse
2018-05-14 15:12 ` [PATCH] " James Morse
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=20180514164720.GH23049@pd.tnic \
    --to=bp@alien8.de \
    --cc=james.morse@arm.com \
    --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.