Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp7493796imm; Tue, 28 Aug 2018 13:06:41 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYa8BUlEjnv3c1ILLUcp3pt0LnVA4PIXs0Ovbd2xaCBWSmpPYhVslNcCvAY6+hdLGnO3d5z X-Received: by 2002:a17:902:8bc4:: with SMTP id r4-v6mr2841332plo.124.1535486801321; Tue, 28 Aug 2018 13:06:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535486801; cv=none; d=google.com; s=arc-20160816; b=rKRlr+itRQgDrj+KNJuLEK3jEs/cPu3psRMdPZMrQcDYWawCB8U/++432F1iucmtX8 yL6zAQk/A0ZDJ9R+VjAcliHHSzxD2nkCuT7S1KFWtcpAFIqd7Rq/CEwWhboeRPf9QNtC qVNICUhoLfp4D2Zhq1ql+IUwKaKNI/AXo992ytBtWnN6ndgMiL2vff1SB9OxMimcCIQl e4f8dsAic6kYJNupJ6eamBwS3pTPEGSoNDszLRAVxsORtjvspKRS0Reu1yiST39YdtLY CsqurgIba2HePPUskuZ7x8J1Qzj1Z4IRYZzyFzU+zQAD0+kbdYyhhE4UjttdYzfwn1sV iceg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=C2PlMf+238WuEND21yZhJRCFMzq+hVAx4mHDLuyO9UA=; b=cBOx0ud7JGhrHQspXz57vARB3hapwOi/vTit/tJX9MVem44SN5BonY5YGDkP2liz1L 0I8aBaEXWR8UfIIHWkJKaqUStQHzvrGT2ZPni9aP5BJaZeermBFLKfuJhBRQMOjqaITd JAHWzRw5suESNZTh4mcMoMjMtuLCkc7peGpYe2y3DmO9SupXfM6IJnUwPKjng4Kmqfha gwzYMrliNJRpmzg6gT9H2HUdf9VwbmFg5dihTgMLZH08MEovj3WxQLXSwvA0cyYQiwBL AVd+k+Hs/nF9ovAEy3Qeq9fGFN330ehDLnfYTLe2I42X5I+7A7RQEWapGBBa1+vsqhMV BlUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Xpykmlbu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si1793461plw.99.2018.08.28.13.06.24; Tue, 28 Aug 2018 13:06:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Xpykmlbu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727312AbeH1X5z (ORCPT + 99 others); Tue, 28 Aug 2018 19:57:55 -0400 Received: from mail-ua1-f65.google.com ([209.85.222.65]:42313 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727054AbeH1X5z (ORCPT ); Tue, 28 Aug 2018 19:57:55 -0400 Received: by mail-ua1-f65.google.com with SMTP id w7-v6so1802401uan.9; Tue, 28 Aug 2018 13:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C2PlMf+238WuEND21yZhJRCFMzq+hVAx4mHDLuyO9UA=; b=XpykmlbuNsRM+KCvZNhRxpFqqO+/3Yzv1FY+Hh/K4W7zGl4044tC7UiTGNsZ1GSWE8 4t4wjGUVmvpuakNlfWC1MGRHjhiSl3KME22S1sEMDAbTiZclTfdVnudPUORzWXasG3w9 L+AWEhoaZ6et2ffUsJVzf4y9XbzRGq3GxBB7r19Slbg4rr5uApWOh+wD93ddUIapwUCY /Bhk5Nzigb914RdfWci8omIV+Xgs6TOzVryV41tvJmabLZM4ng50or+Afc+pyIqFJwpP y8HLi2GwMSDWfBiVSNk0lkjYMn62FAfWg8c8RWIpDsYIETdz4AbFj6+3GGBaHNFG6Bpf rpsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C2PlMf+238WuEND21yZhJRCFMzq+hVAx4mHDLuyO9UA=; b=JxVXBRI87hHnHy7oa+02vNhXehjhKMUOLegoSILnCq1vKh+NCoRu3uJqav9tcCJkDB sQZ5TCiRgwfkfV7A2bVm0oAkDCXp/ViYxFZmbXzYKYQo3OT5euOA+FUFap76dBGlHscA pQZtKbH1aezwD7hsmUD+z9zWeV+t4IK+cTvD/cUWgEYFGQEUOd4V/MD5eq00igENgAmh N1NyJleBnM+DqqbSL3+S5z9SrF+jBcM1L9VT3ez6L12j9slQGapdcOaPcfGC8DaahKC5 ktBd3AtCjsnCaob+iPUUmH/WaAxW1MdlOsSiP/Q9KuKzALonohk8KutT9V6sBJukfeSA GU6A== X-Gm-Message-State: APzg51BsonYOkrnDs3O7gitBuxGD0xMJkqYI19fWy2Lr2zKzuTXi8Pii ajlLzzoRRCqKnopvGRGGQkzQyr1dzE2tQN8KfCQ= X-Received: by 2002:ab0:48a4:: with SMTP id x33-v6mr66647uac.138.1535486681931; Tue, 28 Aug 2018 13:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:5e5c:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 13:04:41 -0700 (PDT) In-Reply-To: References: <1531762009-15112-1-git-send-email-tbaicar@codeaurora.org> <20180719140102.GB25185@nazgul.tnic> <94e3a0fb-9b7d-045f-733b-9f063dcb39e4@arm.com> <45fefe7d-c6ea-5791-4477-13ecce39ce48@codeaurora.org> <68a800c7-446e-9b6b-1847-6e45a1d17262@arm.com> From: Tyler Baicar Date: Tue, 28 Aug 2018 16:04:41 -0400 Message-ID: Subject: Re: [RFC PATCH] EDAC, ghes: Enable per-layer error reporting for ARM To: James Morse Cc: Tyler Baicar , wufan@codeaurora.org, Linux Kernel Mailing List , harba@qti.qualcomm.com, Borislav Petkov , mchehab@kernel.org, arm-mail-list , linux-edac@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 28, 2018 at 1:11 PM, James Morse wrote: > On 24/08/18 16:14, Tyler Baicar wrote: >> On Fri, Aug 24, 2018 at 5:48 AM, James Morse wrote: >>> On 23/08/18 16:46, Tyler Baicar wrote: >>> so edac_raw_mc_handle_error() has no clue where the error happened. (I haven't >>> read what it does with this information yet). >>> >>> ghes_edac_report_mem_error() does check CPER_MEM_VALID_MODULE_HANDLE, and if its >>> set, it uses the handle to find the bank/device strings and prints them out. >> >> Yes, I think this is where we need to add support to increment the >> count based on that module handle. > > If layer[0] is EDAC_MC_LAYER_ALL_MEM, sized for num_dimm, don't we just put the > dimm number in e->top_layer and flip e->enable_per_layer_report? Yes, that is all we would need to do. Figuring out that DIMM number is the issue, but that can be done with the map of module handles to DIMM index. >>> Naively I thought we could generate some index during ghes_edac_count_dimms(), >>> and use this as e->${whichever}_layer. I hoped there would be something we could >>> already use as the index, but I can't spot it, so this will be more than the >>> one-liner I was hoping for! >> >> We could use what ghes_edac_register does by setting up a single layer >> with all memory and >> then keep a map of which module handle maps to which index into that >> layer. From that it would >> be easy to increment the proper sysfs exposed DIMM counters using the >> single layer > > Yes, I think this is what we should do! Sounds good, I'll start working on this! Thanks, Tyler