Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10914446ybi; Thu, 25 Jul 2019 07:01:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqyH8bqXBWpg5oNU2ZI+PjcI6bTYE2/uYR8ux22l95eHTHWfREsGK7532dK15KLBQcWSGPdB X-Received: by 2002:a63:de4f:: with SMTP id y15mr89616087pgi.239.1564063301360; Thu, 25 Jul 2019 07:01:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564063301; cv=none; d=google.com; s=arc-20160816; b=VVtfc8tBmw+QqQCh/ptLPLaKg7cCsIF44T+/zvj4MXCNuye2qMWPErUOKzp1/JTwdB oLB9vx/MN5gIjD159DUxKo+m++DCh7RcU2iUgwHygc+JWuF6lBoI/7ChROjyi+iLtpGv 6dSzXy5r2PFht/SdYfajaXca529iDuTiR39l5HLHIRUaBxN4o77s5UGtyrqCfb7tCTZm bO0Obni9uEBcE3dAV4uCki+qxyIkRXNxLvs/w/0yYoLZI8Ft8qmSq5EYP2FgAphV1usg zrkri/TSarxHDUpJxoFUCBEN/xGsiBYY7+Gn1LyWuNR6MCaHiC7w5BAmlwu8hp1YPlhI jI7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=ewt25qjFY6y5j/IFBx5C5D7IvySQcpTiD0LfhRsptjs=; b=DOtJkQLbaAgFA/PMCqXXmZ1K//bQH2ga9eXdRdFwPtVcp5WC/LZrjAJEOio7ADy/z2 KNq834Ccwi+Gw0m9K2P3azn+upKAqC8vesTqbMrqrSo/urCp/d8dDCaik/FRpc5FPru5 /Wd3HFvtv3TbKjVK1SnMkCvILw/RHjQz1JBbeojbA3mn1+H4Q5y4IhSkok6X2kBdfgB9 wPA837RPxffI9sVZ/jz/pHrnqQxZF5y5vwt7tHtyNKkVOWPRIHc0v1lE2Er1T9qCCQGL A0H8ygQEauEHwOgOIoyLhrBGtrLKi1fKWH2fJPhX8R6HrdBUsFDH+TvvQWG9o+FPqR81 gdYg== ARC-Authentication-Results: i=1; mx.google.com; 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 g6si17518342pll.82.2019.07.25.07.01.26; Thu, 25 Jul 2019 07:01: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; 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 S2389156AbfGYMrB (ORCPT + 99 others); Thu, 25 Jul 2019 08:47:01 -0400 Received: from foss.arm.com ([217.140.110.172]:56622 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388497AbfGYMrA (ORCPT ); Thu, 25 Jul 2019 08:47:00 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 17377152D; Thu, 25 Jul 2019 05:47:00 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A80E3F71F; Thu, 25 Jul 2019 05:46:59 -0700 (PDT) Subject: Re: [PATCHv2] EDAC, altera: Move Stratix10 SDRAM ECC to peripheral To: thor.thayer@linux.intel.com Cc: bp@alien8.de, mchehab@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org References: <1562956123-23640-1-git-send-email-thor.thayer@linux.intel.com> From: James Morse Message-ID: Date: Thu, 25 Jul 2019 13:46:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <1562956123-23640-1-git-send-email-thor.thayer@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thor, On 12/07/2019 19:28, thor.thayer@linux.intel.com wrote: > From: Thor Thayer > > ARM32 SoCFPGAs had separate IRQs for SDRAM. ARM64 SoCFPGAs > send all DBEs to SError so filtering by source is necessary. > > The Stratix10 SDRAM ECC is a better match with the generic > Altera peripheral ECC framework because the linked list can > be searched to find the ECC block offset and printout > the DBE Address. > diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c > index c2e693e34d43..09a80b53acea 100644 > --- a/drivers/edac/altera_edac.c > +++ b/drivers/edac/altera_edac.c > @@ -2231,13 +2275,15 @@ static int altr_edac_a10_probe(struct platform_device *pdev) > of_device_is_compatible(child, "altr,socfpga-dma-ecc") || > of_device_is_compatible(child, "altr,socfpga-usb-ecc") || > of_device_is_compatible(child, "altr,socfpga-qspi-ecc") || > +#ifdef CONFIG_EDAC_ALTERA_SDRAM > + of_device_is_compatible(child, "altr,sdram-edac-s10") || > +#endif > of_device_is_compatible(child, "altr,socfpga-sdmmc-ecc")) I'm just curious: This list looks suspiciously like the altr_edac_a10_device_of_match[] list. Is there a reason it can't use of_match_device() here? > > altr_edac_a10_device_add(edac, child); > > #ifdef CONFIG_EDAC_ALTERA_SDRAM > - else if ((of_device_is_compatible(child, "altr,sdram-edac-a10")) || > - (of_device_is_compatible(child, "altr,sdram-edac-s10"))) > + else if (of_device_is_compatible(child, "altr,sdram-edac-a10")) > of_platform_populate(pdev->dev.of_node, > altr_sdram_ctrl_of_match, > NULL, &pdev->dev); Acked-by: James Morse Thanks, James