From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A4B75CCA47B for ; Thu, 14 Jul 2022 13:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/IjrlCBySFXsWaYb3KuvkTQ+grluY3REWk5fYIq29JM=; b=qIt5Z7/SOTpXfw L3BCHScczS1eKutyhAzRb9woL1ZE1mPa+a9FqLJ5yK/zvRmYUOVq3J0csCHUtOKo8H9de7uPZ0KKQ TXVE3KbZvGb7kke2IGzewxoIdRk2zC0O9l7qIMh12+Qhw11VewMjA5d27tpHEmuqAopsJcIfxi0fv XlTdHSotrEAZ+2W1MQBCxTvpZB/K2fIOCF5gfwrtiA4/PNpg8zzbx7CHDc0nCOXv2XHrjNNERw82c zrki8QaFWTiiJNYSOuoq+u6sP9Rbi4d5lEEsvUH0WDZJOWUzc6YMoHJFdfekqz6qigEvpIOKy/w75 6GJ5qGmtb8QICBn5Wdxg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBywt-00Ek0P-0d; Thu, 14 Jul 2022 13:32:11 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBywn-00EjuN-QD for linux-arm-kernel@lists.infradead.org; Thu, 14 Jul 2022 13:32:09 +0000 Received: from nazgul.tnic (unknown [193.86.92.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 5E9271EC064D; Thu, 14 Jul 2022 15:31:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1657805511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=lHLKg6dy+E2Uxp8MZ4B8ENOJdS38/GHHYZSNyRg96is=; b=mJVTnZKPet5KiOpUBcjQLVkdHplYc0gxIc9kyjP66sOUMqfRCHw/pUaDhPjZnBvTxHcmi2 ld8O+xBMKi45O2YeXVYceE4jlrAh3JOYPzZvPzoA2v0cKuhyY4FJq2NiRjVPhb7/LsQq+B a3taxcfo0N+fpL3IH2Gc2VIQN5XHsX8= Date: Thu, 14 Jul 2022 15:31:07 +0200 From: Borislav Petkov To: Arnd Bergmann Cc: Thierry Reding , arm-soc , SoC Team , Jon Hunter , "open list:TEGRA ARCHITECTURE SUPPORT" , Linux ARM , linux-edac@vger.kernel.org, Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter Subject: Re: [GIT PULL 1/7] soc/tegra: Changes for v5.20-rc1 Message-ID: References: <20220708185608.676474-1-thierry.reding@gmail.com> <20220708185608.676474-2-thierry.reding@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220714_063206_053615_DA69BCE1 X-CRM114-Status: GOOD ( 13.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 13, 2022 at 02:14:27PM +0200, Arnd Bergmann wrote: > I think this is just a reflection of what other hardware can do: > most machines only detect memory errors, but the EDAC subsystem > can work with any type in principle. There are also a lot of > conditions elsewhere that can be detected but not corrected. Just a couple of thoughts from looking at this: So the EDAC thing reports *hardware* errors by using the RAS capabilities built into an IP block. So it started with memory controllers but it is getting extended to other blocks. AMD are looking at how to integrate GPU hw errors reporting into it, for example. Looking at that CBB thing, it looks like it is supposed to report not so much hardware errors but operational errors. Some of the hw errors reported by RAS hw are also operation-related but not the majority. Then, EDAC has this counters exposed in: $ grep -r . /sys/devices/system/edac/ /sys/devices/system/edac/power/runtime_active_time:0 /sys/devices/system/edac/power/runtime_status:unsupported /sys/devices/system/edac/power/runtime_suspended_time:0 /sys/devices/system/edac/power/control:auto /sys/devices/system/edac/pci/edac_pci_log_pe:1 /sys/devices/system/edac/pci/pci0/pe_count:0 /sys/devices/system/edac/pci/pci0/npe_count:0 /sys/devices/system/edac/pci/pci_parity_count:0 /sys/devices/system/edac/pci/pci_nonparity_count:0 /sys/devices/system/edac/pci/edac_pci_log_npe:1 /sys/devices/system/edac/pci/edac_pci_panic_on_pe:0 /sys/devices/system/edac/pci/check_pci_errors:0 /sys/devices/system/edac/mc/power/runtime_active_time:0 /sys/devices/system/edac/mc/power/runtime_status:unsupported ... with the respective hierarchy: memory controllers, PCI errors, etc. So the main question is, does it make sense for you to fit this into the EDAC hierarchy and what would even be the advantage of making it part of EDAC? HTH. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel