Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp132593pxp; Fri, 4 Mar 2022 23:52:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfSoHqToQAVdglkwm8qp1cJ6kxzzi3n70pPucM+jk4sC9S6qe0Zhw45PThtntbwdCvl5wg X-Received: by 2002:a17:902:e5ce:b0:151:9c5a:3c87 with SMTP id u14-20020a170902e5ce00b001519c5a3c87mr2294160plf.59.1646466757136; Fri, 04 Mar 2022 23:52:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646466757; cv=none; d=google.com; s=arc-20160816; b=f2E8RuKrW2t9DRynJWlGGXrtXsle7SrUwClljifp+p3wbYg+q/540X0KurJwK+e2ea i/1C7NsKrmyFdj9RM0QuCuMinRyELqeQ/OOplXdbOtOaaBrNasTo9EDNqOzQUibI4oHB tAok+ubGgTipt5XEeifksowaJup1Ng9QA1JnL1kaLImBlNjhKrDoTbW6FK+0xyBF19NF mBnqZKbDLBQ2dhNUai4ie6wR0EJrOedR7C5CXHYuRq8YGS9SCqMv2jrLsXjsxDVIkLtC Wsu31KD46mgfeAu91Di6J1DyXSezzT3KcUea1F4HiPqBEl2eEoeR9+ReTRLp6PL9Gwo/ tXqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ZKtu9j1W1l5fErOnTKxeDyt6ZV+hDyFV0xVStS569ig=; b=rF9EJ/Tsu7BP9OSAPzUZi6bOGgBUQgDFHZVN+Un/1tFOTGD73rN/FwDDixQa1XIP+Q 4gDVwan4E/hd3RaaKFGAdv7kumJfp8Qj5NrkuFOeU4ZDXdHc2kbqnsSrCZpTqMw4sQVx IwlSW+bPba5CZ3lPk1P/XsXiQ5/a1uzi5f3XMqaBirPwsGr19LdVoHt5QYZj1TaJHjrP S2di/e6fepR68LZvIuVRXJATtrbLt7RnTBktcXvdaQpwdoBe1iGAMY/vsnh4K1xFVhT/ +JSbp6HudO9+6gu4AnJ4hpPuOcl1njJFqHBVtF7SNWxMAIdAWbuak4BG8tfFwcKM60tw 1e3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Z+YMJ0zn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e5-20020a170902ef4500b001519c62e00dsi6976755plx.8.2022.03.04.23.52.21; Fri, 04 Mar 2022 23:52:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Z+YMJ0zn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbiCEBjh (ORCPT + 99 others); Fri, 4 Mar 2022 20:39:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbiCEBjf (ORCPT ); Fri, 4 Mar 2022 20:39:35 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8622554695; Fri, 4 Mar 2022 17:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646444325; x=1677980325; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=T1BLLpcj77s9dl2kYpzLwwHh62xO9d6FgWuFJjNZukw=; b=Z+YMJ0zn+VcEamc/u78Y7VBYBlryljjNxwMOjbqvSXP6zkcUEfH929CB Nq/NHfXdHAY1f0VgT/JJXddVLidS/Hgvn71NEJWkwRFJHcvoszxoXmkJZ htnf/C7MEuah4caxLb9cQM/b4QdXDqhPQfkuweik4lJawE9v9MSYpPeDb qz67qzxNzWD1tdD/XAFoJiGYz8wRTes4JvsL2pDnF7U7aIu4xZxnBhjot la/+BNbqBGEtaTW+73/qdbbeDueBbnHWUKZOOt75Rj+o5dGFy2CwHHItx rZTCNG5NxAoPqd+NTiwuBpxznpA6ynHPGGbX83mRd9fbMNGEEd8R4jeon A==; X-IronPort-AV: E=McAfee;i="6200,9189,10276"; a="254035892" X-IronPort-AV: E=Sophos;i="5.90,156,1643702400"; d="scan'208";a="254035892" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 17:38:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,156,1643702400"; d="scan'208";a="779805083" Received: from pglc00012.png.intel.com ([10.221.207.32]) by fmsmga006.fm.intel.com with ESMTP; 04 Mar 2022 17:38:42 -0800 From: niravkumar.l.rabara@intel.com To: dinh.nguyen@kernel.org, bp@alien8.de, mchehab@kernel.org, tony.luck@intel.com, james.morse@arm.com, rric@kernel.org, niravkumar.l.rabara@intel.com, linux-edac@vger.kernel.org Cc: linux-kernel@vger.kernel.org Subject: [PATCH] EDAC: altera: Add SDRAM ECC check for U-Boot Date: Sat, 5 Mar 2022 09:38:39 +0800 Message-Id: <20220305013839.30740-1-niravkumar.l.rabara@intel.com> X-Mailer: git-send-email 2.19.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rabara Niravkumar L A bug in legacy U-Boot causes a crash during SDRAM boot if ECC is not enabled in the bitstream but enabled in the Linux config. Memory mapped read of the ECC Enabled bit was only enabled if U-Boot determined ECC was enabled in the bitstream. The Linux driver checks the ECC enable bit using a memory map read. In the ECC disabled bitstream case, U-Boot didn't enable ECC register memory map reads and since they are not allowed this results in a crash. This patch always reads the ECC Enable register through a SMC call which is always allowed and it works with legacy and current U-Boot. Signed-off-by: Rabara Niravkumar L --- drivers/edac/altera_edac.c | 40 +++++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c index 5dd29789f97d..e7e8e624a436 100644 --- a/drivers/edac/altera_edac.c +++ b/drivers/edac/altera_edac.c @@ -1083,8 +1083,46 @@ static int __init __maybe_unused altr_init_a10_ecc_device_type(char *compat) #ifdef CONFIG_EDAC_ALTERA_SDRAM +/* + * A legacy U-Boot bug only enabled memory mapped access to the ECC Enable + * register if ECC is enabled. Linux checks the ECC Enable register to + * determine ECC status. + * Use an SMC call (which always works) to determine ECC enablement. + */ +static int altr_s10_sdram_check_ecc_deps(struct altr_edac_device_dev *device) +{ + const struct edac_device_prv_data *prv = device->data; + unsigned long sdram_ecc_addr; + struct arm_smccc_res result; + struct device_node *np; + phys_addr_t sdram_addr; + u32 read_reg; + int ret; + + np = of_find_compatible_node(NULL, NULL, "altr,sdr-ctl"); + if (!np) + goto sdram_err; + + sdram_addr = of_translate_address(np, of_get_address(np, 0, + NULL, NULL)); + of_node_put(np); + sdram_ecc_addr = (unsigned long)sdram_addr + prv->ecc_en_ofst; + arm_smccc_smc(INTEL_SIP_SMC_REG_READ, sdram_ecc_addr, + 0, 0, 0, 0, 0, 0, &result); + read_reg = (unsigned int)result.a1; + ret = (int)result.a0; + if (!ret && (read_reg & prv->ecc_enable_mask)) + return 0; + +sdram_err: + edac_printk(KERN_ERR, EDAC_DEVICE, + "%s: No ECC present or ECC disabled.\n", + device->edac_dev_name); + return -ENODEV; +} + static const struct edac_device_prv_data s10_sdramecc_data = { - .setup = altr_check_ecc_deps, + .setup = altr_s10_sdram_check_ecc_deps, .ce_clear_mask = ALTR_S10_ECC_SERRPENA, .ue_clear_mask = ALTR_S10_ECC_DERRPENA, .ecc_enable_mask = ALTR_S10_ECC_EN, -- 2.19.0