From: bp@alien8.de (Borislav Petkov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
Date: Mon, 1 Jun 2015 20:31:14 +0200 [thread overview]
Message-ID: <20150601183114.GE10169@pd.tnic> (raw)
In-Reply-To: <CAPw-ZTm+1hfh4b-opq=HQDek-wc4A4nT=B6DcuyUBWsm8a-ZbQ@mail.gmail.com>
On Mon, Jun 01, 2015 at 10:46:55AM -0700, Loc Ho wrote:
> You are right... Let me just prints the error code instead. Anyone who
> care will have to do post processing.
Don't forget about the usability of the driver. If a user has to go
open manuals when an error happens, you could just as well report naked
register values and have a tool decode them.
And this strategy (mcelog) turned out to be a real PITA, IMO.
> Future or existent next generation may re-define them.
You could easily have a strings array of per-family or per-soc error
descriptions. For an example, take a look at drivers/edac/mce_amd.c
which decodes MCEs on all relevant AMD machines. This is much more
user-friendly than dumping register values which most people have no
idea of where to start looking (and they don't really need to).
HTH.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
To: Loc Ho <lho-qTEPVZfXA3Y@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Doug Thompson
<dougthompson-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
Mauro Carvalho Chehab
<mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"patches-qTEPVZfXA3Y@public.gmane.org"
<patches-qTEPVZfXA3Y@public.gmane.org>
Subject: Re: [PATCH 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
Date: Mon, 1 Jun 2015 20:31:14 +0200 [thread overview]
Message-ID: <20150601183114.GE10169@pd.tnic> (raw)
In-Reply-To: <CAPw-ZTm+1hfh4b-opq=HQDek-wc4A4nT=B6DcuyUBWsm8a-ZbQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jun 01, 2015 at 10:46:55AM -0700, Loc Ho wrote:
> You are right... Let me just prints the error code instead. Anyone who
> care will have to do post processing.
Don't forget about the usability of the driver. If a user has to go
open manuals when an error happens, you could just as well report naked
register values and have a tool decode them.
And this strategy (mcelog) turned out to be a real PITA, IMO.
> Future or existent next generation may re-define them.
You could easily have a strings array of per-family or per-soc error
descriptions. For an example, take a look at drivers/edac/mce_amd.c
which decodes MCEs on all relevant AMD machines. This is much more
user-friendly than dumping register values which most people have no
idea of where to start looking (and they don't really need to).
HTH.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-06-01 18:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 22:04 [PATCH 0/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver Loc Ho
2015-05-29 22:04 ` Loc Ho
2015-05-29 22:04 ` [PATCH 1/3] Documentation: Update the APM X-Gene SoC EDAC DTS binding for L3/SoC subnodes Loc Ho
2015-05-29 22:04 ` Loc Ho
2015-05-29 22:04 ` [PATCH 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver Loc Ho
2015-05-29 22:04 ` Loc Ho
2015-05-29 22:04 ` [PATCH 3/3] arm64: Add L3/SoC DT subnodes to the APM X-Gene SoC EDAC node Loc Ho
2015-05-29 22:04 ` Loc Ho
2015-06-01 11:43 ` [PATCH 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver Borislav Petkov
2015-06-01 11:43 ` Borislav Petkov
2015-06-01 17:26 ` Loc Ho
2015-06-01 17:26 ` Loc Ho
2015-06-01 14:39 ` Arnd Bergmann
2015-06-01 14:39 ` Arnd Bergmann
2015-06-01 17:46 ` Loc Ho
2015-06-01 17:46 ` Loc Ho
2015-06-01 18:31 ` Borislav Petkov [this message]
2015-06-01 18:31 ` Borislav Petkov
2015-06-01 18:37 ` Arnd Bergmann
2015-06-01 18:37 ` Arnd Bergmann
2015-06-01 18:59 ` Loc Ho
2015-06-01 18:59 ` Loc Ho
2015-06-01 14:39 ` [PATCH 1/3] Documentation: Update the APM X-Gene SoC EDAC DTS binding for L3/SoC subnodes Arnd Bergmann
2015-06-01 14:39 ` Arnd Bergmann
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=20150601183114.GE10169@pd.tnic \
--to=bp@alien8.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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.