Message ID | 1673428065-22356-1-git-send-email-quic_mojha@quicinc.com |
---|---|
State | New |
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 p1csp3212091wrt; Wed, 11 Jan 2023 01:12:50 -0800 (PST) X-Google-Smtp-Source: AMrXdXvVr9g/cxQZhfTuqL8upNfcuCIztPWTxl2kc5amRu4B6+GdzjkG1LqomGe8ocNZWZyrICxX X-Received: by 2002:a05:6402:4506:b0:46d:35f6:5a9b with SMTP id ez6-20020a056402450600b0046d35f65a9bmr21203662edb.24.1673428370565; Wed, 11 Jan 2023 01:12:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673428370; cv=none; d=google.com; s=arc-20160816; b=gf3b2zLbg+DdftX1W/xQuYBn0XlybWJcIRYR7xlmIGy13Hk4/zuXNQkFJJutoTNxqe 6rGU314IfEk6ehsrY2ufnrKM3e8qYk64pX1/UOgLZ7M4K4ZWdM3qdgJgwvY1v7QRs8Fj 6AY8aiPkWqa3z/+LPU/XRTvYWaLYuvvgWi+IzYo4HAqA8/qcENs2wimV7Ou9RsHyzoq9 +59Q3QtE/Ilf4FoB7dsNLPSRzcZKA2eZrbGUHwx6+plsnHaUfZxa/4V9XDqd4yjrcHtq yQWgP4aiXNxehYRcblqkAiHg4jHCsJHiinf5kdK9yJq9dNAl/h7MiB0MM00BV+NqX3BW q1Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=ktldcXxVnrk9cNFDRaUOrMoWTA9I+bDZmJoMwZ8rRTk=; b=QTC2OjDiG4O61Sbxkr9f2LrvxnZaty+1mQ+hu1YF/sXBQnGphMDfNSylJIUOVuyHWJ /AsJJK3M4I3XK1UWqoRvU0tfN+/iLTS1SC2/h1uvaSmcQ0e8qWTjCjTM7f++KJOyxVcr jm1kDBOhb2aVyn2uYG9+sv4tKVDaWmckcIGiDg/SqJgbimw3C2DWjUsK8OujfUkRv+Gl rT7dm5sz5CIVBt6R7LspEK40hxmLeAnBz4bf2bsxvEiQqlFhiyZLViAAEsaCTSwHyMii Wt8S1Is/5F6JXwuaOigND+Hh8xBcABJtQNoehPlojtyItWcgNGWenJBlw9Jh2uup4x62 AY9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=jY0aKZHg; 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=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i9-20020a05640242c900b0046c8d52c79asi18391270edc.357.2023.01.11.01.12.26; Wed, 11 Jan 2023 01:12:50 -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=@quicinc.com header.s=qcdkim header.b=jY0aKZHg; 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=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238563AbjAKJMQ (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Wed, 11 Jan 2023 04:12:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238479AbjAKJLb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Jan 2023 04:11:31 -0500 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D797B15737; Wed, 11 Jan 2023 01:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1673428086; x=1704964086; h=from:to:cc:subject:date:message-id:mime-version; bh=ktldcXxVnrk9cNFDRaUOrMoWTA9I+bDZmJoMwZ8rRTk=; b=jY0aKZHgFzuPiJNiox9aDrF+Z/wp6DADw+byMOX/gKbyo+JYfAPg46Hf G+vUY7mDiX3wssdTiXP35nvAfh3lgRq5QIB/7yLnDRRCPOWtFxZuca486 GTO6s4MHMDUWM2TGnegaXRppPrUGshCqisPq2TYolRl/3fMT1gEVVX8Tl s=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-01.qualcomm.com with ESMTP; 11 Jan 2023 01:08:06 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.45.79.139]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2023 01:08:06 -0800 Received: from hu-mojha-hyd.qualcomm.com (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Wed, 11 Jan 2023 01:08:04 -0800 From: Mukesh Ojha <quic_mojha@quicinc.com> To: <keescook@chromium.org>, <tony.luck@intel.com>, <gpiccoli@igalia.com> CC: <linux-hardening@vger.kernel.org>, <linux-kernel@vger.kernel.org>, "Mukesh Ojha" <quic_mojha@quicinc.com> Subject: [PATCH] pstore/ram: Rework logic for detecting ramoops Date: Wed, 11 Jan 2023 14:37:45 +0530 Message-ID: <1673428065-22356-1-git-send-email-quic_mojha@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01c.na.qualcomm.com (10.45.79.139) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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?1754716827322895163?= X-GMAIL-MSGID: =?utf-8?q?1754716827322895163?= |
Series |
pstore/ram: Rework logic for detecting ramoops
|
|
Commit Message
Mukesh Ojha
Jan. 11, 2023, 9:07 a.m. UTC
The reserved memory region for ramoops is assumed to be at a fixed
and known location when read from the devicetree. This is not desirable
in environments where it is preferred the region to be dynamically
allocated at runtime, as opposed to being fixed at compile time.
Also, Some of the platforms might be still expecting dedicated
memory region for ramoops node where the region is known
beforehand and platform_get_resource() is used in that case.
So, Add logic to detect the start and size of the ramoops memory
region by looking up reserved memory region with
of_reserved_mem_lookup() when platform_get_resource() failed.
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
fs/pstore/ram.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
Comments
Thanks for the patch Mukesh! I don't have a DT hardware at hand right now, so cannot test this one myself. I'll just provide a (really) minor feedback, something to address in a potential V2 or even in merge time, see below. On 11/01/2023 06:07, Mukesh Ojha wrote: > The reserved memory region for ramoops is assumed to be at a fixed > and known location when read from the devicetree. This is not desirable > in environments where it is preferred the region to be dynamically > allocated at runtime, as opposed to being fixed at compile time. > > Also, Some of the platforms might be still expecting dedicated I'd write "Also, some" instead of upper "Some". > memory region for ramoops node where the region is known > beforehand and platform_get_resource() is used in that case. > > So, Add logic to detect the start and size of the ramoops memory Same here, maybe "So, add". Really minor nits, though! Cheers, Guilherme
Hi Guilherme, On 1/11/2023 6:31 PM, Guilherme G. Piccoli wrote: > Thanks for the patch Mukesh! I don't have a DT hardware at hand right > now, so cannot test this one myself. I'll just provide a (really) minor > feedback, something to address in a potential V2 or even in merge time, > see below. > > > On 11/01/2023 06:07, Mukesh Ojha wrote: >> The reserved memory region for ramoops is assumed to be at a fixed >> and known location when read from the devicetree. This is not desirable >> in environments where it is preferred the region to be dynamically >> allocated at runtime, as opposed to being fixed at compile time. >> >> Also, Some of the platforms might be still expecting dedicated > > I'd write "Also, some" instead of upper "Some". > >> memory region for ramoops node where the region is known >> beforehand and platform_get_resource() is used in that case. >> >> So, Add logic to detect the start and size of the ramoops memory > > Same here, maybe "So, add". > Thanks for the review. Will fix it along with other comments. Also, let me know if we need to change binding or document update as well. -Mukesh > Really minor nits, though! > Cheers > > > Guilherme
On Wed, Jan 11, 2023 at 02:37:45PM +0530, Mukesh Ojha wrote: > The reserved memory region for ramoops is assumed to be at a fixed > and known location when read from the devicetree. This is not desirable > in environments where it is preferred the region to be dynamically > allocated at runtime, as opposed to being fixed at compile time. > > Also, Some of the platforms might be still expecting dedicated > memory region for ramoops node where the region is known > beforehand and platform_get_resource() is used in that case. > > So, Add logic to detect the start and size of the ramoops memory > region by looking up reserved memory region with > of_reserved_mem_lookup() when platform_get_resource() failed. > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Thanks for the patch! Notes below... > --- > fs/pstore/ram.c | 19 ++++++++++++++----- > 1 file changed, 14 insertions(+), 5 deletions(-) > > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c > index ade66db..e4bbba1 100644 > --- a/fs/pstore/ram.c > +++ b/fs/pstore/ram.c > @@ -20,6 +20,7 @@ > #include <linux/compiler.h> > #include <linux/of.h> > #include <linux/of_address.h> > +#include <linux/of_reserved_mem.h> > > #include "internal.h" > #include "ram_internal.h" > @@ -643,6 +644,7 @@ static int ramoops_parse_dt(struct platform_device *pdev, > { > struct device_node *of_node = pdev->dev.of_node; > struct device_node *parent_node; > + struct reserved_mem *rmem; > struct resource *res; > u32 value; > int ret; > @@ -651,13 +653,20 @@ static int ramoops_parse_dt(struct platform_device *pdev, > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > if (!res) { > - dev_err(&pdev->dev, > - "failed to locate DT /reserved-memory resource\n"); > - return -EINVAL; > + rmem = of_reserved_mem_lookup(of_node); > + if (rmem) { > + pdata->mem_size = rmem->size; > + pdata->mem_address = rmem->base; > + } else { > + dev_err(&pdev->dev, > + "failed to locate DT /reserved-memory resource\n"); > + return -EINVAL; > + } Since the "else" case returns, the traditional code pattern is to leave the other case "inline" (an indented), like so: if (!rmem) { dev_err(&pdev->dev, "failed to locate DT /reserved-memory resource\n"); return -EINVAL; } pdata->mem_size = rmem->size; pdata->mem_address = rmem->base; > + } else { > + pdata->mem_size = resource_size(res); > + pdata->mem_address = res->start; > } Since this change the potential interface with DT, can you also update the documentation in: Documentation/devicetree/bindings/reserved-memory/ramoops.yaml Or maybe my understanding of DT parsing is lacking and this change is doing something slightly different? -Kees > > - pdata->mem_size = resource_size(res); > - pdata->mem_address = res->start; > /* > * Setting "unbuffered" is deprecated and will be ignored if > * "mem_type" is also specified. > -- > 2.7.4 >
Hi Kees, Thanks for your comments. On 1/13/2023 3:09 AM, Kees Cook wrote: > On Wed, Jan 11, 2023 at 02:37:45PM +0530, Mukesh Ojha wrote: >> The reserved memory region for ramoops is assumed to be at a fixed >> and known location when read from the devicetree. This is not desirable >> in environments where it is preferred the region to be dynamically >> allocated at runtime, as opposed to being fixed at compile time. >> >> Also, Some of the platforms might be still expecting dedicated >> memory region for ramoops node where the region is known >> beforehand and platform_get_resource() is used in that case. >> >> So, Add logic to detect the start and size of the ramoops memory >> region by looking up reserved memory region with >> of_reserved_mem_lookup() when platform_get_resource() failed. >> >> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > > Thanks for the patch! Notes below... > >> --- >> fs/pstore/ram.c | 19 ++++++++++++++----- >> 1 file changed, 14 insertions(+), 5 deletions(-) >> >> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c >> index ade66db..e4bbba1 100644 >> --- a/fs/pstore/ram.c >> +++ b/fs/pstore/ram.c >> @@ -20,6 +20,7 @@ >> #include <linux/compiler.h> >> #include <linux/of.h> >> #include <linux/of_address.h> >> +#include <linux/of_reserved_mem.h> >> >> #include "internal.h" >> #include "ram_internal.h" >> @@ -643,6 +644,7 @@ static int ramoops_parse_dt(struct platform_device *pdev, >> { >> struct device_node *of_node = pdev->dev.of_node; >> struct device_node *parent_node; >> + struct reserved_mem *rmem; >> struct resource *res; >> u32 value; >> int ret; >> @@ -651,13 +653,20 @@ static int ramoops_parse_dt(struct platform_device *pdev, >> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> if (!res) { >> - dev_err(&pdev->dev, >> - "failed to locate DT /reserved-memory resource\n"); >> - return -EINVAL; >> + rmem = of_reserved_mem_lookup(of_node); >> + if (rmem) { >> + pdata->mem_size = rmem->size; >> + pdata->mem_address = rmem->base; >> + } else { >> + dev_err(&pdev->dev, >> + "failed to locate DT /reserved-memory resource\n"); >> + return -EINVAL; >> + } > > Since the "else" case returns, the traditional code pattern is to leave > the other case "inline" (an indented), like so: > > if (!rmem) { > dev_err(&pdev->dev, > "failed to locate DT /reserved-memory resource\n"); > return -EINVAL; > } > pdata->mem_size = rmem->size; > pdata->mem_address = rmem->base; > Fixed it in v2. > >> + } else { >> + pdata->mem_size = resource_size(res); >> + pdata->mem_address = res->start; >> } > > Since this change the potential interface with DT, can you also update > the documentation in: > > Documentation/devicetree/bindings/reserved-memory/ramoops.yaml > > Or maybe my understanding of DT parsing is lacking and this change is > doing something slightly different? > Have updated the docs in v2; -Mukesh
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index ade66db..e4bbba1 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -20,6 +20,7 @@ #include <linux/compiler.h> #include <linux/of.h> #include <linux/of_address.h> +#include <linux/of_reserved_mem.h> #include "internal.h" #include "ram_internal.h" @@ -643,6 +644,7 @@ static int ramoops_parse_dt(struct platform_device *pdev, { struct device_node *of_node = pdev->dev.of_node; struct device_node *parent_node; + struct reserved_mem *rmem; struct resource *res; u32 value; int ret; @@ -651,13 +653,20 @@ static int ramoops_parse_dt(struct platform_device *pdev, res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { - dev_err(&pdev->dev, - "failed to locate DT /reserved-memory resource\n"); - return -EINVAL; + rmem = of_reserved_mem_lookup(of_node); + if (rmem) { + pdata->mem_size = rmem->size; + pdata->mem_address = rmem->base; + } else { + dev_err(&pdev->dev, + "failed to locate DT /reserved-memory resource\n"); + return -EINVAL; + } + } else { + pdata->mem_size = resource_size(res); + pdata->mem_address = res->start; } - pdata->mem_size = resource_size(res); - pdata->mem_address = res->start; /* * Setting "unbuffered" is deprecated and will be ignored if * "mem_type" is also specified.