From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753306AbdHOQT6 (ORCPT ); Tue, 15 Aug 2017 12:19:58 -0400 Received: from g4t3427.houston.hpe.com ([15.241.140.73]:40090 "EHLO g4t3427.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753105AbdHOQTz (ORCPT ); Tue, 15 Aug 2017 12:19:55 -0400 From: "Kani, Toshimitsu" To: "bp@alien8.de" CC: "linux-edac@vger.kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-acpi@vger.kernel.org" Subject: Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk() Thread-Topic: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk() Thread-Index: AQHTDKTuWyxK/OMe00e0Ovda8CeGBqJzlIKAgAEZcQCAAIyugIAD9yeAgAW2iQCABSfDgIAACkUAgAAEFwCAAAdxAIAACkmAgAAGWwCAAAC7gIAAB8WAgAAEpwCAAAu+AIAACWYAgAAIzwCAATq3AIAABq0AgAAFnYA= Date: Tue, 15 Aug 2017 16:19:50 +0000 Message-ID: <1502813405.2042.153.camel@hpe.com> References: <20170814170552.j3lhzvnwlpz75y4g@pd.tnic> <1502732561.2042.141.camel@hpe.com> <20170814180526.wtfjzgc6uye2qtx6@pd.tnic> <1502734083.2042.143.camel@hpe.com> <20170814183551.sgk2i7lxpmpyodhv@pd.tnic> <1502736750.2042.145.camel@hpe.com> <20170814193432.mjldfhfal5ba5dt7@pd.tnic> <1502741290.2042.147.camel@hpe.com> <20170814203942.6t3mrq3hc324blab@pd.tnic> <1502810766.2042.149.camel@hpe.com> <20170815155000.d57hwki5jbixjuj6@pd.tnic> In-Reply-To: <20170815155000.d57hwki5jbixjuj6@pd.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.211.195.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DF4PR84MB0185;6:OXroxGUPrQ8sIp7tqaFxLILrWerBzNmoWnpePnDjjQ92+7PaSO6OuLAdrC458LgXla4xwzVVVhDnl9wHxETXipOsAcRjq/0Aa78k+u3A2UvclGnpsMMxh/sJJpWPb/Ws7Hr2dexcx4Z/d+tf+jrodWT+GNsm18bpl6KRbFmO6CJwDDhd1lQt9pyDNxb5WoKD3ih1UQvZfv13lnGOouQX1Ly3xL23OKgvlOaX0r8hII8lwPC4qN0NeQiyYm6+PIY4mjrgke7bbveSFkUaPXkv3mYoFVZSvJ0lOhIB+T0xBcYGpaQ09C3BUm3uT7gYMz48A/IXKLsISHPu1zafbZBANQ==;5:xQycxsYecsyERcOeCFPs04SijFkH3S1hiJQwYmSBA7az4mAhXBgD1V0yropt92lfyHgbq0UtjvXXt9nU6ZmZ+rhmr/PQdVjIbEos/N47Cr8OAnodEByGDlMo5zpKMzg568V65gp1c4xWB6rkF4JmgQ==;24:Ni1S4zfdbSfyj97wpYbTlIvkEulQ1xH+EeY7od25am/dUs5ctMHXMavQgBUzjakLnwynlxf7wGXPasNpLSRdp20GblEw50jnOMrzfQzjKKg=;7:vi0t9Ng/0FgMF14+ohKQTr9rLCOMod41BY2ylOfauN6fH+g6EXubVwY/eQB/eg28al5ULo5aTLy8uaxmwRpierLYDdViNso1bBLPyMxMIar6FJqaDf7SXZVj1ysG7NLtNmS5150Y4zFpxbv2C+a4fKRoW5Fbwp8eE7JO7LN0eZX+G8YFfi7ezIq5OPmgmN39LklxWwJp2muAtJNHYGO72Uh6B/HAv2ub3rCcvjTiueQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e1a4e052-b360-4345-dbfb-08d4e3f97448 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:DF4PR84MB0185; x-ms-traffictypediagnostic: DF4PR84MB0185: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0185;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0185; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(57704003)(199003)(377424004)(189002)(24454002)(189998001)(54356999)(101416001)(2950100002)(76176999)(305945005)(50986999)(66066001)(103116003)(6512007)(110136004)(6246003)(2900100001)(5640700003)(97736004)(93886004)(77096006)(2351001)(4326008)(53936002)(54906002)(33646002)(36756003)(106356001)(6506006)(3660700001)(86362001)(105586002)(25786009)(14454004)(68736007)(478600001)(8936002)(2906002)(3846002)(2501003)(102836003)(3280700002)(6116002)(6486002)(6436002)(81156014)(229853002)(6916009)(7736002)(1730700003)(5890100001)(5660300001)(81166006)(8676002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0185;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: <33DFDD5BF152414397A3860B5E1D21D8@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 16:19:50.2126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0185 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 v7FGK4aN000422 On Tue, 2017-08-15 at 17:50 +0200, Borislav Petkov wrote: > On Tue, Aug 15, 2017 at 03:35:51PM +0000, Kani, Toshimitsu wrote: > > ghes_edac instantiates an mci as a pseudo device representing a > > GHES error source.  Each error source associates with all DIMMs, > > and may report errors independently.  As ghes_edac is an GHES > > error-reporting wrapper to edac, this abstraction makes sense. > > Bullshit. > > An MCI is a memory controller descriptor. That doesn't fit the GHES > platform devices that get probed. GHES platform device != MCI. How > many times do I need to say this for it to get through to you? Right, but it has to be a "pseudo" device for ghes_edac. There is no memory controller info available. A single mci does not make it a real memory controller, either. > > I do not see a problem in having counters for each GHES error > > source. > > And the error counters of that "simulated" mci get incremented > depending on which pointer gets passed in from GHES? More bullshit. > > > This is just statistics info, and ghes_edac does not expect any OS > > action from the counters. > > So let me know if you don't want to do it and rather would prefer to > pointlessly debate. I certainly don't want to waste my time debating. Yes, ghes_edac refactoring like this should be considered a separate item. My patchset is aimed to introduce a platform-check to attach ghes_edac on supported platforms. Thanks, -Toshi