From: Borislav Petkov <bp@alien8.de>
To: "Kani, Toshimitsu" <toshi.kani@hpe.com>
Cc: "mchehab@infradead.org" <mchehab@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Subject: Re: [PATCH 3/3] EDAC, ghes: Make it a proper module
Date: Wed, 2 Aug 2017 05:18:50 +0200 [thread overview]
Message-ID: <20170802031850.GA4331@nazgul.tnic> (raw)
In-Reply-To: <1501632599.2042.104.camel@hpe.com>
On Wed, Aug 02, 2017 at 12:19:29AM +0000, Kani, Toshimitsu wrote:
> 1. Device-probing-logic should belong to a driver, and should remain
> private to a driver. When we add the white-list, it should be added to
> ghes_edac.
Nonsense. There are a lot of examples where driver probing depends on
outside modalities like built-in quirks and such.
> 2. ghes_edac is an extension to the ghes driver as they both are
> specific to ghes. ghes_edac is merely ghes driver's edac error-
> reporting wrapper than an independent edac driver. It looks OK to let
> ghes_edac get registered as part of ghes_probe() and leave it as an
> unconventional edac driver.
Except that GHES wants to report into the EDAC infrastructure so it
better has a wrapper for it.
One of the directions I explored when looking at this is to stick
ghes_edac functionality into ghes.c or so and make it completely
independent from EDAC. Would've been much cleaner.
> 3. EDAC does not have its managed probe-chain. All edac drivers are
> called from module_init list. They independently probe the hardware
> and get unloaded when not needed. The core edac is simply a set of
> library to them. I think it's good to keep them independent, and not
> to introduce a new central mechanism for a special case like ghes_edac.
They're independent because before GHES we needed to load one driver per
system. Until the bolted-on thing came. And it is bolted on because the
already overwhelmed firmware decided to do error reporting too.
So the only real reason why I'm fine with keeping the current situation
is the whitelist. Because then, we can at least control what loads and
what not.
But then we need:
1. A clean mechanism for the platform drivers to query whether another
agent is loaded (ghes_edac) and not do any probing then.
2. ghes_edac needs to drop that multiple probing thing as its
dmi_walk(ghes_edac_count_dimms, &num_dimm) already probes *all* DIMMs on
the system so no need to do that multiple times.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2017-08-02 3:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 8:48 [PATCH 0/3] EDAC: Convert ghes_edac to a normal module Borislav Petkov
2017-07-26 8:48 ` [PATCH 1/3] EDAC: Add edac_pr_err/info macros Borislav Petkov
2017-07-26 8:48 ` [PATCH 2/3] ACPI/GHES: Add an EDAC notifier chain Borislav Petkov
2017-07-26 8:48 ` [PATCH 3/3] EDAC, ghes: Make it a proper module Borislav Petkov
2017-07-26 10:24 ` Mauro Carvalho Chehab
2017-07-26 10:37 ` Borislav Petkov
2017-07-26 10:51 ` Mauro Carvalho Chehab
2017-07-26 17:27 ` Luck, Tony
2017-07-26 18:17 ` Mauro Carvalho Chehab
2017-07-26 19:24 ` Kani, Toshimitsu
2017-07-27 5:20 ` Borislav Petkov
2017-07-26 19:49 ` Kani, Toshimitsu
2017-07-28 18:50 ` Kani, Toshimitsu
2017-07-29 6:47 ` Borislav Petkov
2017-07-31 20:19 ` Kani, Toshimitsu
2017-08-01 9:46 ` Borislav Petkov
2017-08-02 0:19 ` Kani, Toshimitsu
2017-08-02 3:18 ` Borislav Petkov [this message]
2017-08-02 22:41 ` Kani, Toshimitsu
2017-07-27 5:54 ` [PATCH 0/3] EDAC: Convert ghes_edac to a normal module Borislav Petkov
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=20170802031850.GA4331@nazgul.tnic \
--to=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.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