Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp584125ybl; Fri, 13 Dec 2019 01:07:06 -0800 (PST) X-Google-Smtp-Source: APXvYqzYz3wPxGO7pOEEBVj7ul23g1pwAvS5Pdunp6vMUHmT2+MLDHNVMq6eKO2FxWXuxUzBO7mk X-Received: by 2002:a9d:6b06:: with SMTP id g6mr13656716otp.93.1576228025959; Fri, 13 Dec 2019 01:07:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576228025; cv=none; d=google.com; s=arc-20160816; b=r4yi1FBQr0Ay5Z6h9RUwogOja1lqtbhmrSIr0ThrS4MqliJGSGrOGi0Z02uAY644iw E0zjiUrEEQX60ZgWLW9v5Sk5iYFnoahELyi8RlPyKaby4AR+8f87qvC4rOBlY0t5KvqN 0J89+7T4ksaORAPE2mg9AMZKm+2K7KT/m91E5a8f1xuwhVhDm8Dp/AH2UTn20FkfKrbU XjGDyHv7FCEzWbr2OyknrmVA/9V9H/MUYQCdE6Ne81nO1zCvmnpl6GzTih4eeWcIL85W f5A66FNmEW4et8etXAYemONwbf7pDRRzxq6m6x9PiOs9D5dodF2yYNc9eW9i57lt8CkR FEwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:subject:cc:to:from :date:content-transfer-encoding:mime-version:dkim-signature; bh=oiZ6N7do6DpLWyW7ai3fK8w8lB8Z4mhLsKqRpsecyYA=; b=IMTT684KKfgC9RSh9yxrsmmeTY0BF5vS65vVCZh13xhBFt81mD1ijfdqtgC9KTf0Tz gtU/lI30osiufvWZIrgFwVw5t7WZlJ4A2I/L20teYhWnHcFEXRfrFSgLXxSD9d0zgl+Z Iki+Zz54AQ0PwMjO05aE/qIeuRkPoDtqI+VEpnUz6v4DcQZfOcDYUxif5C/5SBB4unpy tiU9NJJVOfkZzwUP4EqOjMkCMxvYpmcalIP3h38gVj3JHkZn7RqglMaAWmrkb6Kch1/s NgLEmvmOMb75nnwq6d5z4lrViUF1ypzG0d2zsi/QmMWNDBAINgCJiY6vtY1N7p8RMghD hMlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b="BEkQwPG/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h18si5296967otj.114.2019.12.13.01.06.54; Fri, 13 Dec 2019 01:07:05 -0800 (PST) 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=fail header.i=@mg.codeaurora.org header.s=smtp header.b="BEkQwPG/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726743AbfLMJFj (ORCPT + 99 others); Fri, 13 Dec 2019 04:05:39 -0500 Received: from m228-5.mailgun.net ([159.135.228.5]:35544 "EHLO m228-5.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbfLMJFj (ORCPT ); Fri, 13 Dec 2019 04:05:39 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1576227938; h=Message-ID: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=oiZ6N7do6DpLWyW7ai3fK8w8lB8Z4mhLsKqRpsecyYA=; b=BEkQwPG/ipLYEf8Nq8qBlXXEjU9qWltzngcaNgDuX4RMhPFPsQtSpv/jNCx/28YdHAq3pWjU 4OVAL/CYC0EXMYhRl/WbG+QhwZttfZHw7picH2ajdlt2cyNXyqPLdBW5hKTTh7ZVUbsThEt9 a7nWM0JulI5Yu/UicSsOw4GiBnw= X-Mailgun-Sending-Ip: 159.135.228.5 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5df35462.7f8b5ffcff48-smtp-out-n01; Fri, 13 Dec 2019 09:05:38 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 34568C447A6; Fri, 13 Dec 2019 09:05:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 7D24FC43383; Fri, 13 Dec 2019 09:05:35 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 13 Dec 2019 14:35:35 +0530 From: Sai Prakash Ranjan To: Evan Green Cc: Andy Gross , Bjorn Andersson , Mark Rutland , Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Borislav Petkov , Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter , linux-edac@vger.kernel.org, linux-arm Mailing List , LKML , linux-arm-msm , Stephen Boyd , tsoni@codeaurora.org, psodagud@codeaurora.org Subject: Re: [PATCH 2/2] drivers: edac: Add EDAC support for Kryo CPU caches Message-ID: X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Evan, Thanks for the review comments. On 2019-12-12 01:02, Evan Green wrote: > > No name? > Will add them in next spin. > > A comment is warranted to indicate that err_type is indexed by the > enum, as this would be easy to mess up in later changes. > Will use array index as suggested by Stephen. >> +static const char *get_error_msg(u64 errxstatus) >> +{ >> + const struct error_record *rec; >> + u32 errxstatus_serr; >> + >> + errxstatus_serr = FIELD_GET(KRYO_ERRXSTATUS_SERR, errxstatus); >> + >> + for (rec = serror_record; rec->error_code; rec++) { > > It looks like you expect the table to be zero terminated, but it's > not. Add the missing zero entry. > Will add it. >> + >> +static inline void kryo_clear_error(u64 errxstatus) >> +{ >> + write_sysreg_s(errxstatus, SYS_ERXSTATUS_EL1); >> + isb(); > > Is the isb() necessary? If so, why not a dsb as well? > We usually use isb() with cache and system control registers. I do not see anything about isb or dsb mentioned in the TRM for error record registers so it's probably OK to remove this. James can help us here. >> + >> +static void kryo_check_l1_l2_ecc(void *info) >> +{ >> + struct edac_device_ctl_info *edev_ctl = info; >> + u64 errxstatus; >> + u64 errxmisc; >> + int cpu; >> + >> + cpu = smp_processor_id(); >> + /* We know record 0 is L1 and L2 */ >> + write_sysreg_s(0, SYS_ERRSELR_EL1); >> + isb(); > > Another isb I'm not sure about. Is this meant to provide a barrier > between ERRSELR and ERXSTATUS? Wouldn't that be dsb, not isb? > Same as above. I will repost with your comments addressed once I get more feedbacks from EDAC maintainers. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation