Message ID | 20230118150904.26913-18-manivannan.sadhasivam@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2399112wrn; Wed, 18 Jan 2023 07:27:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXsE4hLBycvQSJ7X9YBE5hFegRGT3B4lUzNAVHEiUbCWv5sXqP3tuhCNQTm6bngT8U43gcwQ X-Received: by 2002:a05:6a20:7d8d:b0:b7:9612:709f with SMTP id v13-20020a056a207d8d00b000b79612709fmr9591714pzj.9.1674055652032; Wed, 18 Jan 2023 07:27:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674055652; cv=none; d=google.com; s=arc-20160816; b=LTYPYbPc1TFZbA1dPygNZTisX7ZQrr1IrdZBBEUc66n63CiuBJe7rp6bxkIhv37y9M 1Kfsw19ITnSr86CT0fXlSRCgEaoFkW6vJjOHWYrr28uZcRSJDw4+YUcnM4n6CPaUt8kK pAmA9hWsUXz7LOb7WpB0ptylGnfKRkoVNHllFJ7jAe+gXSMRZUTvRdK5PsPa3TmzV6qA Fo3hPMVxoyKmh2REAQKfR4M7ZPqw5QW6qSB5Tv6ldl0HsDBtCAQ4gh+M+GniEw5cms8T llYE2aL25El7rXIRA32EbCNp71+UA7cLAgo3gdLfHnKrwLdzY40wDS4QrPjmmUm3E7C1 p0MA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=t4t3wjs91jqYDdhcaBgIoHHF665G49/NIuIJvlGrcfA=; b=0cM3IAa6CJ1WL3MumGoXGHKYbu8ujzkVgDw2pBiIaDJoO7ZM2X8+zAvjqki7lqOe79 ZHkqkeSXgG/sDu+9N/JNHKTIH75h+M6EabT+EFptit0XPDIiLLDclVMamueulXbhc8HC lTkhBj18v2PkWHQDQjHeaflQqC8On2FWXuIWfCBNRRvQs/I8fPdbih7P9CeMB/73rImn JGRhubxWKilHi+gIGc+zTRftE0ldsfU01m1hRHl9w8lRKv7YOkqM74AXT38o7lTHW/nZ 0G+w8xCjeS0plOrRN9NriMbgsu4LQ0FVZ6Hd8v9HZkQXcXJuWYBdVSDw6+AzSIowjWj6 6/sQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Do9F396S; 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 e18-20020a63ee12000000b004b6db45d035si23288843pgi.232.2023.01.18.07.27.20; Wed, 18 Jan 2023 07:27:32 -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=Do9F396S; 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 S231833AbjARPOt (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Wed, 18 Jan 2023 10:14:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231843AbjARPNV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 18 Jan 2023 10:13:21 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 105B445BE2 for <linux-kernel@vger.kernel.org>; Wed, 18 Jan 2023 07:10:48 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id g205so9328332pfb.6 for <linux-kernel@vger.kernel.org>; Wed, 18 Jan 2023 07:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=t4t3wjs91jqYDdhcaBgIoHHF665G49/NIuIJvlGrcfA=; b=Do9F396SRyFEV5JxNfbhAFqRMWeNzyfD1WsRYMmoSI5NQ0nbug+TxY3SaKiPs5a9Pw fdR8QaB4M85v9GsVqYcqCnDclRF/RVSxmYBMgKF1l3LucUAiXBAf/086AwtifvXmAe/B MZBjJxOX4wrbKnG+PlVFDYcKiKCT09DhEsY/KikbgL/WiS1cQA2NFIM4RkmK+hru+Gfi m/hpxzgMjZ8x8brdl3PgOhZaKWJszwS+5Rthb8IF4PjcH/k+wjpkYOT8XEB5cUv/G0Oy 1rcXFiGcE7RMaXs+ngfiDoWQqYvsrtt66hh3TzWLSVaDUTVKKlC/JhgxoeuhfqMu4NAS UTnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=t4t3wjs91jqYDdhcaBgIoHHF665G49/NIuIJvlGrcfA=; b=uudhVfrFpCWH7mowHm4qb5JZrLbUw6aKNtHFW+RK0nDaAJCLoRJjU4H8MRxyKCC7cj D4i4z5Ras2UTj4JnW4bFR0H0ch3Z0XAGS54dnYHeEsYb2FCqsrP/YUHgW5F5wvAPI1y1 b+DTar4mTJOWNcZr8j0/djFu+11UwSaeBnfuuPA0at/fQJNX3IrfiOGkitHfNYm/Qcz7 tSwA+Vv9SGb0ykJLxb1qCllKFuILj7mM4LfnTgTa1XxamBukcHRlNdK9EbixwB59A1Wo 9TtvRNhpTXBRt1gvn25Hj5B4Z7tTD8GPdEy0WMZVDNzV6ThFPYcgNT9amd7n+URWn+Y4 dCsQ== X-Gm-Message-State: AFqh2krMyT6XFv4gFH93OJ95XKngrOhkfNIJVuH3j8fjeK5co/J32wbl rsmaD1b8+UZsW+iJ384/cZnK X-Received: by 2002:a05:6a00:2986:b0:58c:8bdd:2e3c with SMTP id cj6-20020a056a00298600b0058c8bdd2e3cmr7663075pfb.20.1674054648177; Wed, 18 Jan 2023 07:10:48 -0800 (PST) Received: from localhost.localdomain ([27.111.75.61]) by smtp.gmail.com with ESMTPSA id i15-20020aa796ef000000b0058d9623e7f1sm6721544pfq.73.2023.01.18.07.10.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 07:10:47 -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>, stable@vger.kernel.org Subject: [PATCH v6 17/17] soc: qcom: llcc: Do not create EDAC platform device on SDM845 Date: Wed, 18 Jan 2023 20:39:04 +0530 Message-Id: <20230118150904.26913-18-manivannan.sadhasivam@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230118150904.26913-1-manivannan.sadhasivam@linaro.org> References: <20230118150904.26913-1-manivannan.sadhasivam@linaro.org> 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=unavailable 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?1755374579446295475?= X-GMAIL-MSGID: =?utf-8?q?1755374579446295475?= |
Series |
Qcom: LLCC/EDAC: Fix base address used for LLCC banks
|
|
Commit Message
Manivannan Sadhasivam
Jan. 18, 2023, 3:09 p.m. UTC
The platforms based on SDM845 SoC locks the access to EDAC registers in the
bootloader. So probing the EDAC driver will result in a crash. Hence,
disable the creation of EDAC platform device on all SDM845 devices.
The issue has been observed on Lenovo Yoga C630 and DB845c.
Cc: <stable@vger.kernel.org> # 5.10
Reported-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
Comments
On 18/01/2023 16:09, Manivannan Sadhasivam wrote: > The platforms based on SDM845 SoC locks the access to EDAC registers in the > bootloader. So probing the EDAC driver will result in a crash. Hence, > disable the creation of EDAC platform device on all SDM845 devices. > > The issue has been observed on Lenovo Yoga C630 and DB845c. > > Cc: <stable@vger.kernel.org> # 5.10 > Reported-by: Steev Klimaszewski <steev@kali.org> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > --- > drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c > index 7b7c5a38bac6..8d840702df50 100644 > --- a/drivers/soc/qcom/llcc-qcom.c > +++ b/drivers/soc/qcom/llcc-qcom.c > @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) > > drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); > > - llcc_edac = platform_device_register_data(&pdev->dev, > - "qcom_llcc_edac", -1, drv_data, > - sizeof(*drv_data)); > - if (IS_ERR(llcc_edac)) > - dev_err(dev, "Failed to register llcc edac driver\n"); > + /* > + * The platforms based on SDM845 SoC locks the access to EDAC registers > + * in bootloader. So probing the EDAC driver will result in a crash. > + * Hence, disable the creation of EDAC platform device on SDM845. > + */ > + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { Don't spread of_device_is_compatible() in driver code. You have driver data for this. Best regards, Krzysztof
On Wed, Jan 18, 2023 at 04:37:29PM +0100, Krzysztof Kozlowski wrote: > On 18/01/2023 16:09, Manivannan Sadhasivam wrote: > > The platforms based on SDM845 SoC locks the access to EDAC registers in the > > bootloader. So probing the EDAC driver will result in a crash. Hence, > > disable the creation of EDAC platform device on all SDM845 devices. > > > > The issue has been observed on Lenovo Yoga C630 and DB845c. > > > > Cc: <stable@vger.kernel.org> # 5.10 > > Reported-by: Steev Klimaszewski <steev@kali.org> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > --- > > drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++----- > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c > > index 7b7c5a38bac6..8d840702df50 100644 > > --- a/drivers/soc/qcom/llcc-qcom.c > > +++ b/drivers/soc/qcom/llcc-qcom.c > > @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) > > > > drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); > > > > - llcc_edac = platform_device_register_data(&pdev->dev, > > - "qcom_llcc_edac", -1, drv_data, > > - sizeof(*drv_data)); > > - if (IS_ERR(llcc_edac)) > > - dev_err(dev, "Failed to register llcc edac driver\n"); > > + /* > > + * The platforms based on SDM845 SoC locks the access to EDAC registers > > + * in bootloader. So probing the EDAC driver will result in a crash. > > + * Hence, disable the creation of EDAC platform device on SDM845. > > + */ > > + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { > > Don't spread of_device_is_compatible() in driver code. You have driver > data for this. > Yeah, but there is no ID to in the driver data to identify an SoC. I could add one but is that really worth doing so? Is using of_device_is_compatible() in drivers discouraged nowadays? Thanks, Mani > Best regards, > Krzysztof >
On 18/01/2023 16:59, Manivannan Sadhasivam wrote: > On Wed, Jan 18, 2023 at 04:37:29PM +0100, Krzysztof Kozlowski wrote: >> On 18/01/2023 16:09, Manivannan Sadhasivam wrote: >>> The platforms based on SDM845 SoC locks the access to EDAC registers in the >>> bootloader. So probing the EDAC driver will result in a crash. Hence, >>> disable the creation of EDAC platform device on all SDM845 devices. >>> >>> The issue has been observed on Lenovo Yoga C630 and DB845c. >>> >>> Cc: <stable@vger.kernel.org> # 5.10 >>> Reported-by: Steev Klimaszewski <steev@kali.org> >>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> >>> --- >>> drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++----- >>> 1 file changed, 12 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c >>> index 7b7c5a38bac6..8d840702df50 100644 >>> --- a/drivers/soc/qcom/llcc-qcom.c >>> +++ b/drivers/soc/qcom/llcc-qcom.c >>> @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) >>> >>> drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); >>> >>> - llcc_edac = platform_device_register_data(&pdev->dev, >>> - "qcom_llcc_edac", -1, drv_data, >>> - sizeof(*drv_data)); >>> - if (IS_ERR(llcc_edac)) >>> - dev_err(dev, "Failed to register llcc edac driver\n"); >>> + /* >>> + * The platforms based on SDM845 SoC locks the access to EDAC registers >>> + * in bootloader. So probing the EDAC driver will result in a crash. >>> + * Hence, disable the creation of EDAC platform device on SDM845. >>> + */ >>> + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { >> >> Don't spread of_device_is_compatible() in driver code. You have driver >> data for this. >> > > Yeah, but there is no ID to in the driver data to identify an SoC. What do you mean there is no? You use exactly the same compatible as the one in driver data. > I could add > one but is that really worth doing so? Is using of_device_is_compatible() in > drivers discouraged nowadays? Because it spreads variant matching all over. It does not scale. drv data fields are the way or better quirks/flags. Best regards, Krzysztof
On Wed, Jan 18, 2023 at 05:05:28PM +0100, Krzysztof Kozlowski wrote: > On 18/01/2023 16:59, Manivannan Sadhasivam wrote: > > On Wed, Jan 18, 2023 at 04:37:29PM +0100, Krzysztof Kozlowski wrote: > >> On 18/01/2023 16:09, Manivannan Sadhasivam wrote: > >>> The platforms based on SDM845 SoC locks the access to EDAC registers in the > >>> bootloader. So probing the EDAC driver will result in a crash. Hence, > >>> disable the creation of EDAC platform device on all SDM845 devices. > >>> > >>> The issue has been observed on Lenovo Yoga C630 and DB845c. > >>> > >>> Cc: <stable@vger.kernel.org> # 5.10 > >>> Reported-by: Steev Klimaszewski <steev@kali.org> > >>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > >>> --- > >>> drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++----- > >>> 1 file changed, 12 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c > >>> index 7b7c5a38bac6..8d840702df50 100644 > >>> --- a/drivers/soc/qcom/llcc-qcom.c > >>> +++ b/drivers/soc/qcom/llcc-qcom.c > >>> @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) > >>> > >>> drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); > >>> > >>> - llcc_edac = platform_device_register_data(&pdev->dev, > >>> - "qcom_llcc_edac", -1, drv_data, > >>> - sizeof(*drv_data)); > >>> - if (IS_ERR(llcc_edac)) > >>> - dev_err(dev, "Failed to register llcc edac driver\n"); > >>> + /* > >>> + * The platforms based on SDM845 SoC locks the access to EDAC registers > >>> + * in bootloader. So probing the EDAC driver will result in a crash. > >>> + * Hence, disable the creation of EDAC platform device on SDM845. > >>> + */ > >>> + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { > >> > >> Don't spread of_device_is_compatible() in driver code. You have driver > >> data for this. > >> > > > > Yeah, but there is no ID to in the driver data to identify an SoC. > > What do you mean there is no? You use exactly the same compatible as the > one in driver data. > Right, but I was saying that there is no unique field to identify an SoC. > > > I could add > > one but is that really worth doing so? Is using of_device_is_compatible() in > > drivers discouraged nowadays? > > Because it spreads variant matching all over. It does not scale. drv > data fields are the way or better quirks/flags. > The driver quirk/flags are usually beneficial if it applies to multiple platforms, otherwise they are a bit overkill IMO just like in this case. One can argue that this matching could spread to other SoCs in the future, but I don't think that could happen for this case. Thanks, Mani > Best regards, > Krzysztof >
On 18/01/2023 17:26, Manivannan Sadhasivam wrote: > On Wed, Jan 18, 2023 at 05:05:28PM +0100, Krzysztof Kozlowski wrote: >> On 18/01/2023 16:59, Manivannan Sadhasivam wrote: >>> On Wed, Jan 18, 2023 at 04:37:29PM +0100, Krzysztof Kozlowski wrote: >>>> On 18/01/2023 16:09, Manivannan Sadhasivam wrote: >>>>> The platforms based on SDM845 SoC locks the access to EDAC registers in the >>>>> bootloader. So probing the EDAC driver will result in a crash. Hence, >>>>> disable the creation of EDAC platform device on all SDM845 devices. >>>>> >>>>> The issue has been observed on Lenovo Yoga C630 and DB845c. >>>>> >>>>> Cc: <stable@vger.kernel.org> # 5.10 >>>>> Reported-by: Steev Klimaszewski <steev@kali.org> >>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> >>>>> --- >>>>> drivers/soc/qcom/llcc-qcom.c | 17 ++++++++++++----- >>>>> 1 file changed, 12 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c >>>>> index 7b7c5a38bac6..8d840702df50 100644 >>>>> --- a/drivers/soc/qcom/llcc-qcom.c >>>>> +++ b/drivers/soc/qcom/llcc-qcom.c >>>>> @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) >>>>> >>>>> drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); >>>>> >>>>> - llcc_edac = platform_device_register_data(&pdev->dev, >>>>> - "qcom_llcc_edac", -1, drv_data, >>>>> - sizeof(*drv_data)); >>>>> - if (IS_ERR(llcc_edac)) >>>>> - dev_err(dev, "Failed to register llcc edac driver\n"); >>>>> + /* >>>>> + * The platforms based on SDM845 SoC locks the access to EDAC registers >>>>> + * in bootloader. So probing the EDAC driver will result in a crash. >>>>> + * Hence, disable the creation of EDAC platform device on SDM845. >>>>> + */ >>>>> + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { >>>> >>>> Don't spread of_device_is_compatible() in driver code. You have driver >>>> data for this. >>>> >>> >>> Yeah, but there is no ID to in the driver data to identify an SoC. >> >> What do you mean there is no? You use exactly the same compatible as the >> one in driver data. >> > > Right, but I was saying that there is no unique field to identify an SoC. > >> >>> I could add >>> one but is that really worth doing so? Is using of_device_is_compatible() in >>> drivers discouraged nowadays? >> >> Because it spreads variant matching all over. It does not scale. drv >> data fields are the way or better quirks/flags. >> > > The driver quirk/flags are usually beneficial if it applies to multiple > platforms, otherwise they are a bit overkill IMO just like in this case. > > One can argue that this matching could spread to other SoCs in the future, but > I don't think that could happen for this case. That's the argument for every flag/quirk/field. Driver already uses it - see need_llcc_cfg being set for only one (!!!) variant. Now you add orthogonal field just as of_device_is_compatible(). No, that's why we have driver data and as I said - it is already used. Best regards, Krzysztof
diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c index 7b7c5a38bac6..8d840702df50 100644 --- a/drivers/soc/qcom/llcc-qcom.c +++ b/drivers/soc/qcom/llcc-qcom.c @@ -1012,11 +1012,18 @@ static int qcom_llcc_probe(struct platform_device *pdev) drv_data->ecc_irq = platform_get_irq_optional(pdev, 0); - llcc_edac = platform_device_register_data(&pdev->dev, - "qcom_llcc_edac", -1, drv_data, - sizeof(*drv_data)); - if (IS_ERR(llcc_edac)) - dev_err(dev, "Failed to register llcc edac driver\n"); + /* + * The platforms based on SDM845 SoC locks the access to EDAC registers + * in bootloader. So probing the EDAC driver will result in a crash. + * Hence, disable the creation of EDAC platform device on SDM845. + */ + if (!of_device_is_compatible(dev->of_node, "qcom,sdm845-llcc")) { + llcc_edac = platform_device_register_data(&pdev->dev, + "qcom_llcc_edac", -1, drv_data, + sizeof(*drv_data)); + if (IS_ERR(llcc_edac)) + dev_err(dev, "Failed to register llcc edac driver\n"); + } return 0; err: