Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp8923490rwb; Tue, 13 Dec 2022 12:15:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf437x2xUrI5aY8R+PDAwRwZPCqmNK3daDcg5BSjO7vgSPSwfvf7OuzyaN8N8Bva/WWjXER6 X-Received: by 2002:a05:6402:540b:b0:461:cc5b:2570 with SMTP id ev11-20020a056402540b00b00461cc5b2570mr18471676edb.1.1670962537904; Tue, 13 Dec 2022 12:15:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670962537; cv=none; d=google.com; s=arc-20160816; b=Ycta1JBX7EuDabuXCpbejrJ8KLfEtpESG+czuAI6IPRWVJurW8eL2umjYGSwWJGwc2 dJcmiF6vhOUYOeedEHK3Rtcuu9xuGDzedZIcRMDKO0O0LcZ++Oy5OFMD04gyiMDVXRsu PPaSCgsiy1mTgUB9jOZ9elcWhEEdlEd6zvhVqURu3I2whP+J9+gvcOzJeBBCxL93SZc5 b6FffZmaENBwy9Mx3sYpcCvFDVX/989F9e/T1i6+6gckW7YLWBtY0agdRSFmdPe0rC3m aBmqvCqrrizKl4OHCsCdnMh0DroARdHVn6MYwHUKKLHklg4+CIPDmVkh6uHbJjSMBU7l 65vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=YRwOpyUTyKwZUBQY9S8LUeQA/QLa8sJtEGHZbXqLC9M=; b=XKapSbEwbspSjx6TTuSS0x84nY6mgLDCtoGB0kPbc14asIBAoaKzkEIBq5utdxCzKQ EugFXGk2Aw57esL4NaJFRLt/TE0hfvFWgDW/8RpGZ+c9Y1+f/0lbzGNuQoGukvsyQqAQ 3VOhLN3BtN6lLkMN/30ow97kitNyBeCcnO7wFUuQQIH+vKgcxt4GtdhTIsTEmXvP7LJS BgGCk4LRtX4muF/nRs3ODb53Oq5kH1bWtfRdntN4lxSSwYzRFS46DXp6ykYP0HymEKIc xTsKanC+gIJIbij7M9SYQVQtqS3/e3rSh9FxowBJw9k6ColA3Ku4D0mF3vUN1R8QWXDs d10A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=sGK1i122; 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 m13-20020a056402430d00b0046a7ad0bb17si11742309edc.586.2022.12.13.12.15.21; Tue, 13 Dec 2022 12:15: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=@linaro.org header.s=google header.b=sGK1i122; 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 S235536AbiLMSry (ORCPT + 72 others); Tue, 13 Dec 2022 13:47:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236692AbiLMSrW (ORCPT ); Tue, 13 Dec 2022 13:47:22 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42CFC25284 for ; Tue, 13 Dec 2022 10:47:21 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id p8so6393219lfu.11 for ; Tue, 13 Dec 2022 10:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YRwOpyUTyKwZUBQY9S8LUeQA/QLa8sJtEGHZbXqLC9M=; b=sGK1i122jhMTjX3eHGkDcjeDAPF73PChEdmzvJsp5X/8qyzjl0rYuKS8H8KKD1St1M 3OmZ+wPhD4Vlm2UelB8tfS06WQqTNEtXjAHhQgZiwTReGH5hXqz8js+HUGvCTVS+2Dbg q1NXNe9Ze62Kr5/Rqg/5/fhnnp2ixYRQDqwhQpQXiBHHyQBPzJe+I7shXo6Tz7v5Szk3 yV6Et3779dABbPSG/Rksz3t1F2hDgaWsMah3p2sgIkjr/W23kqr57Lt6Ao9m44BPsdOH tKEw1IN1sGiQ6SoYx0GwhYSuB0v9RmrnlC9/NrH2T0JoMp/sHXtDC/nl70lZ1f3nc7As kUmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YRwOpyUTyKwZUBQY9S8LUeQA/QLa8sJtEGHZbXqLC9M=; b=odtWzuAUrUqXzkFm+7qjRizmA/rieDE/a9iVqMIWLJEvRwSTVNiOKSjc2BxnzXWKx0 4bmakFLBEb1OlxekduSLBVWv4dYgEvVwBfBgPD04yPOdtlUUY3KrG0NE5Lq2fDc4RjCF gvEIE1AtogB7UO+4b+Q9eyfbiHbm3uBDH6wCysdAFX4B6rE92caf9iugwfFOObl6kQXj fcUrh3nR8X3CJzFe1B903g+cmEzVCny8Dq13wMTt8h0yIvR9DRsBsZw6LvwrUPzdbUBl 9MYBaKVpBQyRBm08uwzRe3lfXPS3KNoQZ2WHZ1x4Z1lGoMFIVwzcndPDAzoGmTisxIFt iFiQ== X-Gm-Message-State: ANoB5plro3jKnaRQlBxfymBEMrPhHJg+yoL0vvgWE66wyOwMq+kIjAVX KAOSgH1CvCPYQGA/ak9OO4eG+A== X-Received: by 2002:ac2:4c24:0:b0:4b4:900c:3a28 with SMTP id u4-20020ac24c24000000b004b4900c3a28mr5168648lfq.60.1670957239616; Tue, 13 Dec 2022 10:47:19 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id 25-20020ac25699000000b004b58d457f2dsm471838lfr.61.2022.12.13.10.47.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Dec 2022 10:47:19 -0800 (PST) Message-ID: <195a55f1-76e7-3f00-da1f-4ae84f7943c0@linaro.org> Date: Tue, 13 Dec 2022 19:47:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v2 00/13] Qcom: LLCC/EDAC: Fix base address used for LLCC banks Content-Language: en-US To: Manivannan Sadhasivam 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 References: <20221212123311.146261-1-manivannan.sadhasivam@linaro.org> <20221212192340.evgtbpzmw7hcdolb@halaney-x13s> <20221213052802.GB4862@thinkpad> <20221213175738.GI4862@thinkpad> From: Krzysztof Kozlowski In-Reply-To: <20221213175738.GI4862@thinkpad> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 13/12/2022 18:57, Manivannan Sadhasivam wrote: > 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. Hm, I assumed that it would be enough if driver name would match device name. Currently these two are not in sync. Maybe it's not enough when built as module? > 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. Every driver with a single device support has usually ID table and it's not a problem... Best regards, Krzysztof