Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8794347rwb; Tue, 13 Dec 2022 10:28:34 -0800 (PST) X-Google-Smtp-Source: AA0mqf6tJxO5ElBNF4bUndhspF6nCTF5mCHRAiabCEJRoLP5CjxNzxiyaS+NmxsJAKLxfceX70gK X-Received: by 2002:a62:1d0f:0:b0:56c:3fbb:dd8 with SMTP id d15-20020a621d0f000000b0056c3fbb0dd8mr18122770pfd.11.1670956114620; Tue, 13 Dec 2022 10:28:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670956114; cv=none; d=google.com; s=arc-20160816; b=FNVmK4GNs6nKQBMaAOVT23beFXywibOYQv/QKrpaWlPzpU9zJ5M0SIQ3DSMACT225G HrBvjeFnh9PX5OtIjT5kcGdcX1w7TEiuQU8rG/fudisI/ARDYeOx5eGweg/Hs8j1PHSq 3J/UofuHw9f8ZaQF0tdAzMjt/w4xXPtjGACrjxMF+E+NihDF9eflwn3ZrtgpdrWm6wlZ uJSVuwcXruQESKrVnBB66malH42msI8CULeMDAttt4w7XKRiU3IB2mY1Jfk8Enh8G4F9 CZsGFTz4zcaiNJNEH3KM4jGcG2LEcAnRLPtU1p0454cqNO4CjfQfrsQGZjjHip7XKAMm b/Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=opAga5NytnN90LYH/jNZqiNTmgPT7NfAYJd2Euocw8U=; b=M/CnvcQ8lNI/CcE7mX1FQwzhX6JhHsSZDJgScslpHwwvpdGR4I/PNd5dhN1+D2CV60 ZssUaOEHowhWE6gFg93lGgOzsNDLo1/TyCm5o2G/C9MwW+20WN9O4uQFnkjc7K1Fpc5T 3hQmXimv7QBdAA1nffxgB7er/Q9ZMwPmvpaazd3fV25UCKlz2QJbjs8ede05d3efNerc SGqSWm6cSkrXfxyE8VxqhIL4tx96law8IlQZCS4PCcxTtGVTKEBk+MNa4Dl1FND9OzKw rjUMNACM67v8IIE0AvgB0SUTRnHibb7J5/ETF06iP+BZIaPlfpzJjCKW97THr18aJsw1 rAxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=h5lH2SaA; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f15-20020a056a00228f00b0057a7415ab1bsi2993664pfe.69.2022.12.13.10.28.25; Tue, 13 Dec 2022 10:28:34 -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=@linaro.org header.s=google header.b=h5lH2SaA; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236048AbiLMR5v (ORCPT + 72 others); Tue, 13 Dec 2022 12:57:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235844AbiLMR5s (ORCPT ); Tue, 13 Dec 2022 12:57:48 -0500 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2742265D6 for ; Tue, 13 Dec 2022 09:57:46 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id 65so2731682pfx.9 for ; Tue, 13 Dec 2022 09:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=opAga5NytnN90LYH/jNZqiNTmgPT7NfAYJd2Euocw8U=; b=h5lH2SaAjfj5nZRgT3MlmV0bU4ktCOBs1Us5zj/vVE/eHkYdKdWHa9z2rOsNxE23Zp AvEASOnPtLEGudWCQE2Aou29D4FLJKnsu8EZ177IllFGVSqEu88pq6wR1wfudFu21/47 OXkLOZuGm7c4zCDnCT810zUnH9DkhWZIWgnc66Dm8lfmKyuDURNCgk+c7dmSxzcNZ+4i oh8tnabQghXCOI02SQFz71NmJW92BfTj7hd3S3yjUXxwS4WXoIb5awcV9blzVnKSW4YR PIvNcH1iQ/Pz02G6EBxYZYFx1Jgrbe6lx5w/Q1W3Y9QDzoVOS8/JoRtc+iQAN1PYzxcB bLqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=opAga5NytnN90LYH/jNZqiNTmgPT7NfAYJd2Euocw8U=; b=Phnul0HMTyE5674/7Irqp5ZIbfYtjaSzfbDQgTzJhES+cylu7JwYmytQ5KlZxCmcWt UApAnL+X564hLPMRp3AppZRaEL45pH67cQyUOwRGHWjmyZzsonnVHNwJNYmqUWmihO3L 4azk4rBiDTKLnSkAv1jC27FmucSwo9o1o1RMvAobVeUD8EH65KUW2TYsKqaiLyB2P5+x Ootn7Prg0AqNloTksoKb4QZg40fej6XjOiiuNFartyLX3yWTPzH6FdIMdtDx9fetdlQn iMYHeX8c4ZAC3KP41/Bg+T6nqWnFF9tLL+s28oAFXhHfS8ZBhdUewet3TPzOsMUTr7Zl GjhQ== X-Gm-Message-State: ANoB5pnjCzbpoxeWxwXWXWUUnLrkEGoo+vYWlRrYIUMl5TTd7sZLNsQC aTHgHaUVDDW912ih6ifapk4b X-Received: by 2002:aa7:828d:0:b0:574:9a46:6306 with SMTP id s13-20020aa7828d000000b005749a466306mr21729213pfm.20.1670954265596; Tue, 13 Dec 2022 09:57:45 -0800 (PST) Received: from thinkpad ([27.111.75.5]) by smtp.gmail.com with ESMTPSA id x8-20020aa79ac8000000b0056da63c8515sm8179465pfp.91.2022.12.13.09.57.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Dec 2022 09:57:44 -0800 (PST) Date: Tue, 13 Dec 2022 23:27:38 +0530 From: Manivannan Sadhasivam To: Krzysztof Kozlowski Cc: Andrew Halaney , andersson@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, bp@alien8.de, tony.luck@intel.com, quic_saipraka@quicinc.com, konrad.dybcio@linaro.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, james.morse@arm.com, mchehab@kernel.org, rric@kernel.org, linux-edac@vger.kernel.org, quic_ppareek@quicinc.com, luca.weiss@fairphone.com Subject: Re: [PATCH v2 00/13] Qcom: LLCC/EDAC: Fix base address used for LLCC banks Message-ID: <20221213175738.GI4862@thinkpad> References: <20221212123311.146261-1-manivannan.sadhasivam@linaro.org> <20221212192340.evgtbpzmw7hcdolb@halaney-x13s> <20221213052802.GB4862@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS 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 On Tue, Dec 13, 2022 at 05:54:56PM +0100, Krzysztof Kozlowski wrote: > On 13/12/2022 06:28, Manivannan Sadhasivam wrote: > > On Mon, Dec 12, 2022 at 01:23:40PM -0600, Andrew Halaney wrote: > >> On Mon, Dec 12, 2022 at 06:02:58PM +0530, Manivannan Sadhasivam wrote: > >>> The Qualcomm LLCC/EDAC drivers were using a fixed register stride for > >>> accessing the (Control and Status Regsiters) CSRs of each LLCC bank. > >>> This offset only works for some SoCs like SDM845 for which driver support > >>> was initially added. > >>> > >>> But the later SoCs use different register stride that vary between the > >>> banks with holes in-between. So it is not possible to use a single register > >>> stride for accessing the CSRs of each bank. By doing so could result in a > >>> crash with the current drivers. So far this crash is not reported since > >>> EDAC_QCOM driver is not enabled in ARM64 defconfig and no one tested the > >>> driver extensively by triggering the EDAC IRQ (that's where each bank > >>> CSRs are accessed). > >>> > >>> For fixing this issue, let's obtain the base address of each LLCC bank from > >>> devicetree and get rid of the fixed stride. > >>> > >>> This series affects multiple platforms but I have only tested this on > >>> SM8250 and SM8450. Testing on other platforms is welcomed. > >>> > >> > >> Tested-by: Andrew Halaney # sa8540p-ride > >> > > > > Thanks! > > > >> I took this for a quick spin on the qdrive3 I've got access to without > >> any issue: > >> > >> [root@localhost ~]# modprobe qcom_edac > >> [root@localhost ~]# dmesg | grep -i edac > >> [ 0.620723] EDAC MC: Ver: 3.0.0 > >> [ 1.165417] ghes_edac: GHES probing device list is empty > >> [ 594.688103] EDAC DEVICE0: Giving out device to module qcom_llcc_edac controller llcc: DEV qcom_llcc_edac (INTERRUPT) > >> [root@localhost ~]# cat /proc/interrupts | grep ecc > >> 174: 0 0 0 0 0 0 0 0 GICv3 614 Level llcc_ecc > >> [root@localhost ~]# > >> > >> Potentially stupid question, but are users expected to manually load the > >> driver as I did? I don't see how it would be loaded automatically in the > >> current state, but thought it was funny that I needed to modprobe > >> myself. > >> > >> Please let me know if you want me to do any more further testing! > >> > > > > Well, I always ended up using the driver as a built-in. I do make it module for > > build test but never really used it as a module, so didn't catch this issue. > > > > This is due to the module alias not exported by the qcom_edac driver. Below > > diff allows kernel to autoload it: > > > > diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c > > index f7afb5375293..13919d01c22d 100644 > > --- a/drivers/edac/qcom_edac.c > > +++ b/drivers/edac/qcom_edac.c > > @@ -419,3 +419,4 @@ module_platform_driver(qcom_llcc_edac_driver); > > > > MODULE_DESCRIPTION("QCOM EDAC driver"); > > MODULE_LICENSE("GPL v2"); > > +MODULE_ALIAS("platform:qcom_llcc_edac"); > > While this is a way to fix it, but instead of creating aliases for wrong > names, either a correct name should be used or driver should receive ID > table. > I'm not sure how you'd fix it with a _correct_ name here. Also, the id table is an overkill since there is only one driver that is making use of it. And moreover, there is no definite ID to use. Thanks, Mani > Best regards, > Krzysztof > -- மணிவண்ணன் சதாசிவம்