From: Robert Richter <rrichter@marvell.com>
To: James Morse <james.morse@arm.com>
Cc: Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 12/21] EDAC, ghes: Add support for legacy API counters
Date: Thu, 20 Jun 2019 06:55:37 +0000 [thread overview]
Message-ID: <20190620065527.qqulgpk6k5wva4mj@rric.localdomain> (raw)
In-Reply-To: <c08290d8-3690-efa9-3bc7-37f8b1fdbfd4@arm.com>
On 19.06.19 18:22:32, James Morse wrote:
> > In any case, this patch cleans up code as old API's counter code is
> > isolated and moved to common code. Making the counter's work for ghes
> > is actually a side-effect here. The cleanup is a prerequisit for
> > follow on patches.
>
> I'm all for removing/warning-its-broken it when ghes_edac is in use. But the convincing
> argument is debian ships a 'current' version of edac-utils that predates 199747106934,
> (that made all this fake csrow stuff deprecated), and debian's popcon says ~1000 people
> have it installed.
All arm64 distribution kernels that I have checked come with:
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_GHES=y
CONFIG_EDAC_LAYERSCAPE=m
CONFIG_EDAC_THUNDERX=m
CONFIG_EDAC_XGENE=m
> If you want it fixed, please don't do it as a side effect of cleanup. Fixes need to be a
> small separate series that can be backported. (unless we're confident no-one uses it, in
> which case, why fix it?)
It is not that I am keen on fixing legacy edac sysfs. It just happens
while unifying the error handlers in ghes_edac and edac_mc. As I see
you are reluctant on just letting it go, let's just disable
EDAC_LEGACY_SYSFS for ARM64. Though, I don't agree with it as there
still could be some userland tools that use this interface that cannot
be used any longer after a transition from x86 to arm64. I leave that
decision up to you. Please just ACK a patch with the Kconfig change
which I will add to my v2 series.
Thanks,
-Robert
next prev parent reply other threads:[~2019-06-20 6:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 8:44 [PATCH 00/21] EDAC, mc, ghes: Fixes and updates to improve memory error reporting Robert Richter
2019-05-29 8:44 ` [PATCH 01/21] EDAC, mc: Fix edac_mc_find() in case no device is found Robert Richter
2019-05-29 8:44 ` [PATCH 02/21] EDAC: Fixes to use put_device() after device_add() errors Robert Richter
2019-06-11 17:28 ` Borislav Petkov
2019-06-12 17:17 ` Robert Richter
2019-05-29 8:44 ` [PATCH 03/21] EDAC: Kill EDAC_DIMM_PTR() macro Robert Richter
2019-05-29 8:44 ` [PATCH 04/21] EDAC: Kill EDAC_DIMM_OFF() macro Robert Richter
2019-05-29 8:44 ` [PATCH 05/21] EDAC: Introduce mci_for_each_dimm() iterator Robert Richter
2019-05-29 8:44 ` [PATCH 06/21] EDAC, mc: Cleanup _edac_mc_free() code Robert Richter
2019-05-29 8:44 ` [PATCH 07/21] EDAC, mc: Remove per layer counters Robert Richter
2019-05-29 8:44 ` [PATCH 08/21] EDAC, mc: Rework edac_raw_mc_handle_error() to use struct dimm_info Robert Richter
2019-05-29 8:44 ` [PATCH 09/21] EDAC, ghes: Use standard kernel macros for page calculations Robert Richter
2019-05-29 15:13 ` James Morse
2019-05-29 8:44 ` [PATCH 10/21] EDAC, ghes: Remove pvt->detail_location string Robert Richter
2019-05-29 15:13 ` James Morse
2019-06-12 18:13 ` Robert Richter
2019-05-29 8:44 ` [PATCH 11/21] EDAC, ghes: Unify trace_mc_event() code with edac_mc driver Robert Richter
2019-05-29 15:12 ` James Morse
2019-06-03 13:10 ` Robert Richter
2019-06-04 17:15 ` James Morse
2019-06-13 22:23 ` Robert Richter
2019-05-29 8:44 ` [PATCH 12/21] EDAC, ghes: Add support for legacy API counters Robert Richter
2019-05-29 15:13 ` James Morse
2019-06-12 18:41 ` Robert Richter
2019-06-19 17:22 ` James Morse
2019-06-20 6:55 ` Robert Richter [this message]
2019-06-26 9:33 ` James Morse
2019-06-26 10:27 ` Robert Richter
2019-05-29 8:44 ` [PATCH 13/21] EDAC, ghes: Rework memory hierarchy detection Robert Richter
2019-05-29 15:06 ` James Morse
2019-05-31 13:41 ` Robert Richter
2019-05-29 8:44 ` [PATCH 14/21] EDAC, ghes: Extract numa node information for each dimm Robert Richter
2019-05-29 17:51 ` James Morse
2019-06-13 20:52 ` Robert Richter
2019-05-29 8:44 ` [PATCH 15/21] EDAC, ghes: Moving code around ghes_edac_register() Robert Richter
2019-05-29 8:44 ` [PATCH 16/21] EDAC, ghes: Create one memory controller device per node Robert Richter
2019-05-29 8:44 ` [PATCH 17/21] EDAC, ghes: Fill sysfs with the DMI DIMM label information Robert Richter
2019-05-29 8:44 ` [PATCH 18/21] EDAC, mc: Introduce edac_mc_alloc_by_dimm() for per dimm allocation Robert Richter
2019-05-29 8:44 ` [PATCH 19/21] EDAC, ghes: Identify dimm by node, card, module and handle Robert Richter
2019-05-29 8:44 ` [PATCH 20/21] EDAC, ghes: Enable per-layer reporting based on card/module Robert Richter
2019-05-29 8:44 ` [PATCH 21/21] EDAC, Documentation: Describe CPER module definition and DIMM ranks Robert Richter
2019-05-29 14:54 ` [PATCH 00/21] EDAC, mc, ghes: Fixes and updates to improve memory error reporting Borislav Petkov
2019-05-31 14:48 ` Robert Richter
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=20190620065527.qqulgpk6k5wva4mj@rric.localdomain \
--to=rrichter@marvell.com \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).