Message ID | 20221228084028.46528-1-manivannan.sadhasivam@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1783285wrt; Wed, 28 Dec 2022 00:42:07 -0800 (PST) X-Google-Smtp-Source: AMrXdXtR64Cp73/Sjrq7QoRx7D7xxP3qpJG4zdwJ/QS9hmm2q/SAux3Zxa3sOb8EZtlaPpAac9Sp X-Received: by 2002:a05:6a20:13a0:b0:a5:df86:f2c3 with SMTP id w32-20020a056a2013a000b000a5df86f2c3mr39572803pzh.32.1672216927272; Wed, 28 Dec 2022 00:42:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672216927; cv=none; d=google.com; s=arc-20160816; b=Gb26iHTYrWB63EKM2G9Xbr6lnzqpcjzBRCFXd7RJnfAGqoyfOMF07QYW8hsoKmIiKq jRtDDR73+VgXGqVKKxToVEK6rf/dBwHzg9JXmbIPvR+cicN5FKVD9wCVPGiCg9vA00SF 7/nYtEuF7Usdb4rCIBbL68Nm7H1gdPiOZv3QErb98hoHKGPh2BPc1gaDj4vXxYSy45R8 XOM5it9kgA7EbO+AEDz3h6Hu99VHZvAzPWHQ7RTxPUf4bK+/cepPeucC65piyBBEjv7H k2olXlFJ4DNcN573G/zPqHdqz9RmCK7qk1GD9Gcy6gkjQyY/ZzhPj+VxjzGLaku9iT/M 917A== 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=upvEDusjxGXHtrTFd/h6/9Atzs+zFMDkhyOWz4mxZUs=; b=LVOzc8S4IZL5f5s43cNWO7zdhij/Q//FIZZaUISdxtZt8pvNryMNhzASERfO4luWss /sHd/JUHrHXjSAVE3e2CpSFOOllED8Cwoe0tF+YHJf80R09YhUqWhentKKBs68J+7OhN u1jkRaGVytV6/3ERtDxXjQEUK31d3rc8vGTSZ7ClAGlGOsVHKmYZkzbHsH/L8mxGWN4/ 95knLc8gwjGbCs+t1iaLI2K6Qko5lStDowcir+R1PR+k/PKwLJb4ii9hCkjD8k2TdSIF nSNj7fjeldbY08msG39fXt7omdBZnxC7L5+2NC+XQibJIapZvQb1f5D937ur47lj234J zdYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="o/avvO6t"; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i16-20020a63e450000000b0046f583c8c4asi16528028pgk.315.2022.12.28.00.41.55; Wed, 28 Dec 2022 00:42:07 -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="o/avvO6t"; 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 S232412AbiL1IlB (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Wed, 28 Dec 2022 03:41:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232493AbiL1Ikz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Dec 2022 03:40:55 -0500 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6A361C6 for <linux-kernel@vger.kernel.org>; Wed, 28 Dec 2022 00:40:42 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id e21so733533pfl.1 for <linux-kernel@vger.kernel.org>; Wed, 28 Dec 2022 00:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=upvEDusjxGXHtrTFd/h6/9Atzs+zFMDkhyOWz4mxZUs=; b=o/avvO6tpKj3lCeujTVVFi9HofNLe6IPJYloXe22hk7xEspCZZOvD7JnI9j7iVreB3 gskaHrfVZMrA+7RqU3wMFXT6eWLGhDGNJftq3TgYXDwJ7tgxoCgMJXfmfQ3aPk6P0R/f XC9KFNNbobE5vsQkFJAmb/StNTCgmqqJhG6vmHPoca6nYMpYpMmQKJN8T+d6Z0e5PQ6y WbkSjo2ECT/MDIxsR0cWfTxTHq4ZdQouFykwlprQnRzAsfQi55Qrm7W3shciI2jjZIMl tWUnbmcweASYjXdMx9crst7vplr3AHawmPCsLpXdRMv/wYCetbFwAOBgv7Dwzx7vtTaC pjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=upvEDusjxGXHtrTFd/h6/9Atzs+zFMDkhyOWz4mxZUs=; b=mpxoLhSmua+1bN47dII45I2u5QM9eVGada7MVBHFlzMaI5Di7jVGwOma0RlTlWNqLV Y5OunO5P3MCu09eOVyS2+pM0Q3O6kU4xGdvkLUxHtX/GcSM0li8Xi9NCOnCmsHpjR1r2 pFVHU7F6yNtCwr1CIYTdqrtPrqI0Z+Dr9fd7ldT1BSR3cRk1bmiK6zFgOOWlgIdH7FWC EtFv53uftSzuVEPLlIeMmxy/+/+/i3cT51u22Yqj4WCa3QPDzhzeH3PhJ4MlWOdF7dt2 1Ro1h71X3wnwzqUPbfmeiZ/3WfUc6N/DA0TwBSORUNCcd1H2GPoqNtchJepeyEorzW+V T8Qw== X-Gm-Message-State: AFqh2kqkDPOhwNww5GlZ851tN/+wXx4U6+RNmPlCDmXWaLWY889Unarl +TNunBzSh/asYCIOmMa/QG9G X-Received: by 2002:a62:5241:0:b0:56a:d3ff:f4b2 with SMTP id g62-20020a625241000000b0056ad3fff4b2mr25495156pfb.10.1672216842113; Wed, 28 Dec 2022 00:40:42 -0800 (PST) Received: from localhost.localdomain ([117.217.178.73]) by smtp.gmail.com with ESMTPSA id d188-20020a6236c5000000b0057a9b146592sm9786286pfa.186.2022.12.28.00.40.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Dec 2022 00:40:41 -0800 (PST) From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> To: andersson@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, bp@alien8.de, tony.luck@intel.com Cc: 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, ahalaney@redhat.com, steev@kali.org, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Subject: [PATCH v5 00/17] Qcom: LLCC/EDAC: Fix base address used for LLCC banks Date: Wed, 28 Dec 2022 14:10:11 +0530 Message-Id: <20221228084028.46528-1-manivannan.sadhasivam@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752920537161486119?= X-GMAIL-MSGID: =?utf-8?q?1753446536897052603?= |
Series |
Qcom: LLCC/EDAC: Fix base address used for LLCC banks
|
|
Message
Manivannan Sadhasivam
Dec. 28, 2022, 8:40 a.m. UTC
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 has been tested on SM8250, SM8450, SM6350, SC8280XP, SA8540P, and SDM845. Merging strategy ---------------- Patches 1/17, 2/17 and 3/17 can be merged independently to EDAC tree. Rest of the patches should be merged to qcom tree due to LLCC dependency. Thanks, Mani Changes in v5: * Reduced the size of llcc0 to 0x45000 on SDM845 due to overlapping with BWMON * Added a patch to disable creation of EDAC platform device on SDM845 * Rebase on top of v6.2-rc1 * Moved the EDAC specific patches to the start so that they can be applied independently of LLCC patches Changes in v4: * Added a patch that fixes the use-after-free bug in qcom_edac driver Changes in v3: * Brought back reg-names property for compatibility (Krzysztof) * Removed Fixes tag and stable list as backporting the drivers/binding/dts patches alone would break (Krzysztof) * Fixed the uninitialized variable issue (Kbot) * Added a patch to make use of driver supplied polling interval (Luca) * Added a patch for module autoloading (Andrew) * Didn't collect Review tags from Sai as the dts patches were changed. Changes in v2: * Removed reg-names property and used index of reg property to parse LLCC bank base address (Bjorn) * Collected Ack from Sai for binding * Added a new patch for polling mode (Luca) * Renamed subject of patches targeting SC7180 and SM6350 Manivannan Sadhasivam (17): EDAC/device: Make use of poll_msec value in edac_device_ctl_info struct EDAC/qcom: Add platform_device_id table for module autoloading EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info dt-bindings: arm: msm: Update the maintainers for LLCC dt-bindings: arm: msm: Fix register regions used for LLCC banks arm64: dts: qcom: sdm845: Fix the base addresses of LLCC banks arm64: dts: qcom: sc7180: Fix the base addresses of LLCC banks arm64: dts: qcom: sc7280: Fix the base addresses of LLCC banks arm64: dts: qcom: sc8280xp: Fix the base addresses of LLCC banks arm64: dts: qcom: sm8150: Fix the base addresses of LLCC banks arm64: dts: qcom: sm8250: Fix the base addresses of LLCC banks arm64: dts: qcom: sm8350: Fix the base addresses of LLCC banks arm64: dts: qcom: sm8450: Fix the base addresses of LLCC banks arm64: dts: qcom: sm6350: Fix the base addresses of LLCC banks qcom: llcc/edac: Fix the base address used for accessing LLCC banks qcom: llcc/edac: Support polling mode for ECC handling soc: qcom: llcc: Do not create EDAC platform device on SDM845 .../bindings/arm/msm/qcom,llcc.yaml | 128 ++++++++++++++++-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 5 +- arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 10 +- arch/arm64/boot/dts/qcom/sdm845.dtsi | 7 +- arch/arm64/boot/dts/qcom/sm6350.dtsi | 2 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 7 +- arch/arm64/boot/dts/qcom/sm8250.dtsi | 7 +- arch/arm64/boot/dts/qcom/sm8350.dtsi | 7 +- arch/arm64/boot/dts/qcom/sm8450.dtsi | 7 +- drivers/edac/edac_device.c | 2 +- drivers/edac/qcom_edac.c | 63 +++++---- drivers/soc/qcom/llcc-qcom.c | 80 ++++++----- include/linux/soc/qcom/llcc-qcom.h | 6 +- 14 files changed, 244 insertions(+), 89 deletions(-)
Comments
On Wed, Dec 28, 2022 at 02:10:11PM +0530, Manivannan Sadhasivam wrote: > Patches 1/17, 2/17 and 3/17 can be merged independently to EDAC tree. Rest of > the patches should be merged to qcom tree due to LLCC dependency. Why make it more complicated than it has to be? How about I review the EDAC bits and once they look ok, whoever takes care of the qcom tree can pick them up too and route the whole pile through there? This way there's no needless dependency between trees... Hmm.
On Wed, Dec 28, 2022 at 11:36:06AM +0100, Borislav Petkov wrote: > On Wed, Dec 28, 2022 at 02:10:11PM +0530, Manivannan Sadhasivam wrote: > > Patches 1/17, 2/17 and 3/17 can be merged independently to EDAC tree. Rest of > > the patches should be merged to qcom tree due to LLCC dependency. > > Why make it more complicated than it has to be? > > How about I review the EDAC bits and once they look ok, whoever takes > care of the qcom tree can pick them up too and route the whole pile > through there? > Well, some maintainers prefer to pick the independent patches through their tree. That's why I moved those patches to the start of the series. > This way there's no needless dependency between trees... > If you are fine with all patches going through qcom tree, I do not have any issue :) Thanks, Mani > Hmm. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Dec 28, 2022 at 10:17:11PM +0530, Manivannan Sadhasivam wrote: > Well, some maintainers prefer to pick the independent patches through their > tree. That's why I moved those patches to the start of the series. Once some maintainers experience a crazy dependency hell between trees, they would find routing it all through a single tree a lot easier the next time. > If you are fine with all patches going through qcom tree, I do not > have any issue :) I'm reviewing.
On Wed, Dec 28, 2022 at 06:55:47PM +0100, Borislav Petkov wrote: > On Wed, Dec 28, 2022 at 10:17:11PM +0530, Manivannan Sadhasivam wrote: > > Well, some maintainers prefer to pick the independent patches through their > > tree. That's why I moved those patches to the start of the series. > > Once some maintainers experience a crazy dependency hell between trees, > they would find routing it all through a single tree a lot easier the > next time. > > > If you are fine with all patches going through qcom tree, I do not > > have any issue :) > > I'm reviewing. > Ok! I'll wait for your reviews on the rest of the EDAC patches before doing the respin. Thanks, Mani > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Jan 02, 2023 at 11:00:45PM +0530, Manivannan Sadhasivam wrote: > On Wed, Dec 28, 2022 at 06:55:47PM +0100, Borislav Petkov wrote: > > On Wed, Dec 28, 2022 at 10:17:11PM +0530, Manivannan Sadhasivam wrote: > > > Well, some maintainers prefer to pick the independent patches through their > > > tree. That's why I moved those patches to the start of the series. > > > > Once some maintainers experience a crazy dependency hell between trees, > > they would find routing it all through a single tree a lot easier the > > next time. > > > > > If you are fine with all patches going through qcom tree, I do not > > > have any issue :) > > > > I'm reviewing. > > > > Ok! I'll wait for your reviews on the rest of the EDAC patches before doing the > respin. > Ping! Thanks, Mani > Thanks, > Mani > > > -- > > Regards/Gruss, > > Boris. > > > > https://people.kernel.org/tglx/notes-about-netiquette > > -- > மணிவண்ணன் சதாசிவம்