Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1702537

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From "Kani, Toshimitsu" <toshi.kani@hpe.com>
Newsgroups linux.kernel
Subject Re: [PATCH 3/3] EDAC, ghes: Make it a proper module
Date Thu, 03 Aug 2017 00:50:02 +0200
Message-ID <uaaCK-7MS-3@gated-at.bofh.it> (permalink)
References <u7qb0-6t0-7@gated-at.bofh.it> <u7qkG-6w4-9@gated-at.bofh.it> <u8iEp-7vB-9@gated-at.bofh.it> <u8tJv-6SE-7@gated-at.bofh.it> <u9pku-2jJ-13@gated-at.bofh.it> <u9BYl-1SZ-1@gated-at.bofh.it> <u9PHX-2zV-13@gated-at.bofh.it> <u9Smu-4n4-5@gated-at.bofh.it>
Thread-Topic [PATCH 3/3] EDAC, ghes: Make it a proper module
Thread-Index AQHTBewsoOaHQfQgAk6o+lOz407qJKJplmgAgADKxoCABAT2gIAA5AgAgADxV4CAADTDAIABQh2A
Accept-Language en-US
Content-Language en-US
Authentication-Results spf=none (sender IP is ) smtp.mailfrom=toshi.kani@hpe.com;
X-Originating-IP [15.203.227.8]
X-Ms-Publictraffictype Email
X-Microsoft-Exchange-Diagnostics 1;DF4PR84MB0186;7:lMwfNFaBNzD7qY4YoUi9drEMFkjvRMYGvHOr07mU+zOzK5Df4JY0f6tO6DX8r7/CX0M/Iks7Sy+C0cEX5sqyowyhVm7eI7KVf3An37LvMgXXgKjFHTbZuaQmIKBX0WVDzQ0mvuV3fX1nw2ZHE4DfiLVMMTxLZprERNV/xQnAiz2GcjvC6slSgdsV2nEzDDgSVb+loFb5jVxF7pTYEwBrG9BbcZtaFvAXXpwiXG+rKwYOH3lc7yK/bpSVoowOsP6UTbE89EEeF47WqO3gU2KdC6FdiKtUOOuk/4e/vty+kyXK53vdXeGVO/tK4p8i4AUPT9GQ95ZsF1iGegxB4sAoef2rA9IL5KTqv+w7d0t6puleSHJxyD49ZcQTGofoXjibCvlCQibquRvRsXl0J/71Z0Jvh2h5U5saSzMt213tPdMmvOjcai/kR0BdSel1jA8zpMOA66n7Tw19lvhYgIMulr1azMrDj0Txv38HGgwx9pQVKm2DO9Ov01oHyRJDb3D++33pNP7GXuhTh3Wascly0tYhJccYAnpvPhyRPRajNf3FO7aauFxaCYtAB8OKO1l85qHQVFdfH2wWvwk1iYJkle6Tqg9q6v5EqezsAVMvQbfEtgPF+GgJNIDEOyMgNDQ3iD2WOuv5uA45pqae9R+WafQ+TGn8rjo4pdWun4Q9uRu9M6yPQ9/oYBlRn7hIaHcOGhcI3f4ZXGljjd9+uQOtBh7aShA8suEPp39o/kvohMONhIwuD/VPoSqwCtW8TMKPsacp46slB7ogNm5Cm/E7GxRKNZ+zdPDG8QAlWli1oNM=
X-Ms-Office365-Filtering-Correlation-ID f03467f6-5242-4d2c-023e-08d4d9f79505
X-Ms-Office365-Filtering-Ht Tenant
X-Microsoft-Antispam UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0186;
X-Ms-Traffictypediagnostic DF4PR84MB0186:
X-Exchange-Antispam-Report-Test UriScan:(211171220733660);
X-Microsoft-Antispam-Prvs <DF4PR84MB0186D07B192B04E4085C0D0E82B00@DF4PR84MB0186.NAMPRD84.PROD.OUTLOOK.COM>
X-Exchange-Antispam-Report-Cfa-Test BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0186;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0186;
X-Forefront-Prvs 0387D64A71
X-Forefront-Antispam-Report SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(39850400002)(39840400002)(39400400002)(39450400003)(39410400002)(189002)(24454002)(377424004)(199003)(5660300001)(8936002)(3846002)(2900100001)(106356001)(5640700003)(81156014)(81166006)(33646002)(1730700003)(8676002)(110136004)(38730400002)(6436002)(103116003)(102836003)(6116002)(2950100002)(6916009)(6506006)(86362001)(305945005)(54906002)(7736002)(6486002)(6512007)(77096006)(2501003)(36756003)(2351001)(6246003)(93886004)(53936002)(229853002)(97736004)(2906002)(3660700001)(3280700002)(14454004)(4326008)(189998001)(25786009)(68736007)(478600001)(101416001)(66066001)(54356999)(76176999)(50986999)(105586002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0186;H:DF4PR84MB0187.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
Received-Spf None (protection.outlook.com: hpe.com does not designate permitted sender hosts)
Spamdiagnosticoutput 1:99
Spamdiagnosticmetadata NSPM
Content-Type text/plain; charset="utf-8"
Content-ID <832D228D00007C4C889539D624FFD5AC@NAMPRD84.PROD.OUTLOOK.COM>
Content-Transfer-Encoding base64
MIME-Version 1.0
X-Ms-Exchange-Crosstenant-Originalarrivaltime 02 Aug 2017 22:41:14.5427 (UTC)
X-Ms-Exchange-Crosstenant-Fromentityheader Hosted
X-Ms-Exchange-Crosstenant-ID 105b2061-b669-4b31-92ac-24d304d195dc
X-Ms-Exchange-Transport-Crosstenantheadersstamped DF4PR84MB0186
X-Originatororg hpe.com
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 43
Organization linux.* mail to news gateway
X-Original-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>
X-Original-Date Wed, 2 Aug 2017 22:41:14 +0000
X-Original-Message-ID <1501713103.2042.107.camel@hpe.com>
X-Original-References <20170726084827.11447-1-bp@alien8.de> <20170726084827.11447-4-bp@alien8.de> <1501267290.2042.89.camel@hpe.com> <20170729064715.GB30603@nazgul.tnic> <1501531803.2042.95.camel@hpe.com> <20170801094612.GA18647@nazgul.tnic> <1501632599.2042.104.camel@hpe.com> <20170802031850.GA4331@nazgul.tnic>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1702537

Show key headers only | View raw


On Wed, 2017-08-02 at 05:18 +0200, Borislav Petkov wrote:
> 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.

Agreed. I think the current model aimed at this direction while it was
needed to depend on EDAC.

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

Sounds good. I will keep the current model and address the above
points.

Thanks,
-Toshi

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-07-31 22:20 +0200
  Re: [PATCH 3/3] EDAC, ghes: Make it a proper module Borislav Petkov <bp@alien8.de> - 2017-08-01 11:50 +0200
    Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-08-02 02:30 +0200
      Re: [PATCH 3/3] EDAC, ghes: Make it a proper module Borislav Petkov <bp@alien8.de> - 2017-08-02 05:20 +0200
        Re: [PATCH 3/3] EDAC, ghes: Make it a proper module "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2017-08-03 00:50 +0200

csiph-web