From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751685AbdHBAUu (ORCPT ); Tue, 1 Aug 2017 20:20:50 -0400 Received: from g9t5008.houston.hpe.com ([15.241.48.72]:53238 "EHLO g9t5008.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbdHBAUs (ORCPT ); Tue, 1 Aug 2017 20:20:48 -0400 From: "Kani, Toshimitsu" To: "bp@alien8.de" CC: "mchehab@infradead.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "linux-edac@vger.kernel.org" , "rjw@rjwysocki.net" Subject: Re: [PATCH 3/3] EDAC, ghes: Make it a proper module Thread-Topic: [PATCH 3/3] EDAC, ghes: Make it a proper module Thread-Index: AQHTBewsoOaHQfQgAk6o+lOz407qJKJplmgAgADKxoCABAT2gIAA5AgAgADxV4A= Date: Wed, 2 Aug 2017 00:19:29 +0000 Message-ID: <1501632599.2042.104.camel@hpe.com> 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> In-Reply-To: <20170801094612.GA18647@nazgul.tnic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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;DF4PR84MB0188;7:Nsb5ktZ9RJ0klj1rrmZ3P4iRdSZ8LjiA2E4GbWX1/JD1hsHyA8MR8eiByq334NZawzgSL7hvl1Uq8hmpwLrFO3BnfZWJ3dtfWeAqDo0E9q4aicA4O9gapPNHw65/gZWCGjYIEJnyT+Hk09IOitbTRxkj6HhbLrxACvdSjSJXxdPaBqGQx/y7GUniGN03gA6Gd8Ke7nQv46WhT2Me2z0zCRpSImLkXIVgmjfw4eA8hk7PEWaa7a+a6bzm94NA7Bm7mmdrFgaUcxGEA5LUg20dkogm4aaA2MfWNGbTg4SlNBWm346tYJEzORqAH9r8b9T7Sw/ncND6wRtSw1pXrs2fvlB9cNA0e30m1l+XPc75FmIQRyMRwRXynxmPhMLAN5fIKSReYtZdebDF8sRXncefgJsq/suxjEbKYysJYNubpxjjZkvzpQmNekOKr6aUrYAqBsJfUJKhZVIWA6voD2RdNTZEi2TOxj7fYCm4Z+yRO3r/32MgXc2Gsfe/nVAXWj+2lu15zwEbXEyHo4Rp91EWK2aG2qSj7RXrZKlrilysaH3+I1dJtcsqDZmgDdi2UQvE/P3v4DNG+aaIpzJw/7CHBUs8zVQQAi4VC0K9tUFXWAxoQS0ox0zVVBVgq5juwiZqKVGzUs4PNU6ecupdK8RURJjwk78yTybyTjLLWPRSJEATIAp9xVT6BPD4H6StOfTxiBt12HChgS1fsRJgzTwQrVCmU8mcPnpsNyaLKXzBBseH4c3cui8BbvDaiMb1FA+8gjoOpQkk0556zh5bDxsMpKUYQWmVeQuyoIldhwhgofk= x-ms-office365-filtering-correlation-id: 0dff4d3f-e455-4423-a52e-08d4d93c2489 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0188; x-ms-traffictypediagnostic: DF4PR84MB0188: x-exchange-antispam-report-test: UriScan:(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0188;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0188; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39840400002)(39860400002)(39400400002)(39450400003)(39850400002)(39410400002)(199003)(24454002)(377424004)(189002)(101416001)(50986999)(81166006)(6246003)(8936002)(5640700003)(4326008)(1730700003)(305945005)(8676002)(7736002)(68736007)(66066001)(6512007)(54356999)(25786009)(53936002)(36756003)(3846002)(2351001)(105586002)(106356001)(6436002)(33646002)(103116003)(81156014)(102836003)(6116002)(2501003)(54906002)(2950100002)(2900100001)(97736004)(6916009)(77096006)(6486002)(6506006)(93886004)(478600001)(76176999)(229853002)(189998001)(2906002)(5660300001)(3280700002)(110136004)(14454004)(38730400002)(3660700001)(86362001);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0188;H:DF4PR84MB0187.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2B0DC0EDA16F6743AB32029AC9D3B787@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 00:19:29.9410 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0188 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v720KsU2006827 On Tue, 2017-08-01 at 11:46 +0200, Borislav Petkov wrote: > On Mon, Jul 31, 2017 at 08:19:32PM +0000, Kani, Toshimitsu wrote: > > I'd prefer to add the whitelist check to ghes_edac first.  This > > makes the existing code to work.  We can then work on refactoring > > changes like this on top of it without breaking the functionality. > > Yes, but we want only the whitelist - not the FF testing because, as > we said, BIOS is notoriously buggy so we're going to load ghes_edac > only on known-good platforms. This GHES-probe itself is appropriate and should remain. Since not all GHES firmware can be trusted, we will add the white-list as an additional condition to complement this check. > Which brings the question about the priority. > > And I *think* the easiest would be if the whitelist were in the core > edac.ko module, perhaps in edac_module.c (even though it doesn't > really matter, technically). I agree that adding the white-list into the core edac module is the easiest when we make the change on top of yours. Thinking further on this, though, I now think that keeping the current implementation is more reasonable with the reasons below. 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. 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. 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. Thanks, -Toshi