Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2894080rwd; Wed, 14 Jun 2023 08:35:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4GDRgBWe/CfsSaOJunJKATVZ41ZMekZEGdDc2/XSnBUA+r55XNYTgDC2zpMmlJ5pdpCnuZ X-Received: by 2002:a17:902:e811:b0:1ad:f407:37d2 with SMTP id u17-20020a170902e81100b001adf40737d2mr15642403plg.5.1686756903135; Wed, 14 Jun 2023 08:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686756903; cv=none; d=google.com; s=arc-20160816; b=Tozih+G6wn0xAavL7v7+1LmhsTPvTmq0TCKFQ8Ufd1u2FDR03au6dFS8gXcb6i1bsF 80zvYg87Ond8LLykSyMZwAx+aK3D+7ZlqoFPnlXOMZRrOqcCwI+F0TF1n9l+eCqRDx3i b6+Y/niAqvyfu5qo2tcAX4X/IWNj48M4Zrd0PGvNmbhQcZt+qQlwxO+ph/+uzbao6MOT 7RXM/IWH8V8PoymLPd40JZMubrq+uwdcoygGxfj/zdLQ/sLXvf1qwQU8MxytFGEsVHD5 QFzgtKEu5gHSoXLC0Uu4+Kbxh3zGlKSr8Ka0PXVOf6UqYUP2dIUFLOjQA5i1FoDdnFMm y2Gg== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=5/lP4kfWXpPzA8fMnH5EBlGU0tsSX9Y60KAV8b+BgcQ=; b=hp5N50QJGeutVh68CvlS6LePT8Za1OU+I9282nkVeqIMnEFpEtTKZtBh4h7Wp1PE0Q afzEeWP7mNka1mlfHDD9UCUyTpQuSs7gRXpgpwgfBwLU/uiD+kXAtWkN32tYCnmsGpqP nTmsHZ4AcjxBeCz3JDBqdv8dzgkIqm8I7VKYMncpOjjvhN5VCtYXrUgsS1cmY/Pnt6S1 iWXTDg6TV6Sw629A9jPrBpYybGjWmD/ZU98lyxDGWsvtgB4dmwq9DIuT67jB06vyQqVG UXvLWfTRhAkki5Qa/qzDFIVfxd6rGSJ5a+YC+nraBX3bOsind41FAXJicmLHjEkXyyXw bZWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=bMl5x6pk; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n11-20020a1709026a8b00b001b049682a8dsi10857164plk.458.2023.06.14.08.34.51; Wed, 14 Jun 2023 08:35:03 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b=bMl5x6pk; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343512AbjFNPJ3 (ORCPT + 99 others); Wed, 14 Jun 2023 11:09:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343544AbjFNPJ0 (ORCPT ); Wed, 14 Jun 2023 11:09:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 883851FFF; Wed, 14 Jun 2023 08:08:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2434A64366; Wed, 14 Jun 2023 15:08:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F03E9C433C0; Wed, 14 Jun 2023 15:08:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686755331; bh=tUXMAMLTrnJ2iEJIE1fN4T5eZcn5N+chLeoszAhmb6I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bMl5x6pkHX2lUz4yqlAtawJF3Whci7a2OcNFy04dO8+Apql56gpiSxaRf9f4TZlcw xFfsjYc79qdpHkicd+y5IsYxauMnBI1ZrFFWNtmovv5bh6GAFNY+ZyEDv3XKcvxm66 jqv15dMj4zN67sswVLnwwItoKIPGax6m62RiLvALUd13OcHlIGIWaRLwDoZTEkhl+s k1zc+Pe7PkF5tnch5Gyn7NcV7AHCuXf80SJtflrYR2rq2yu1EcZxkwqfrMcTfHGh7H eXx32m5cjn6ut89XSVmD5Pf4R7kuNQxpx1k94BCgPnz/oGRC6WxsE4TvqwESTL/Yd1 8u8H3vYEbvuLA== Date: Wed, 14 Jun 2023 08:12:13 -0700 From: Bjorn Andersson To: Stephan Gerhold Cc: Andy Gross , Konrad Dybcio , Mathieu Poirier , linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] remoteproc: qcom: Use of_reserved_mem_lookup() Message-ID: <20230614151213.qiimwth3fkic5vct@ripper> References: <20230529-rproc-of-rmem-v1-1-5b1e38880aba@gerhold.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230529-rproc-of-rmem-v1-1-5b1e38880aba@gerhold.net> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 Wed, May 31, 2023 at 11:34:54AM +0200, Stephan Gerhold wrote: > Reserved memory can be either looked up using the generic function > of_address_to_resource() or using the special of_reserved_mem_lookup(). > The latter has the advantage that it ensures that the referenced memory > region was really reserved and is not e.g. status = "disabled". > > of_reserved_mem also supports allocating reserved memory dynamically at > boot time. This works only when using of_reserved_mem_lookup() since > there won't be a fixed address in the device tree. > > Switch the code to use of_reserved_mem_lookup(), similar to > qcom_q6v5_wcss.c which is using it already. There is no functional > difference for static reserved memory allocations. > > While at it this also adds two missing of_node_put() calls in > qcom_q6v5_pas.c. > > Signed-off-by: Stephan Gerhold > --- > See e.g. [1] for an example of dynamically allocated reserved memory. > (This patch does *not* depend on [1] and is useful without as well...) > > NOTE: Changes in qcom_q6v5_adsp.c and qcom_q6v5_pas.c are untested, > I only checked qcom_q6v5_mss.c and qcom_wcnss.c on MSM8916/DB410c. > The code changes are pretty similar for all of those though. > > [1]: https://lore.kernel.org/linux-arm-msm/20230510-dt-resv-bottom-up-v1-5-3bf68873dbed@gerhold.net/ > --- > drivers/remoteproc/qcom_q6v5_adsp.c | 22 ++++++++-------- > drivers/remoteproc/qcom_q6v5_mss.c | 35 +++++++++++++++---------- > drivers/remoteproc/qcom_q6v5_pas.c | 51 ++++++++++++++++++++----------------- > drivers/remoteproc/qcom_wcnss.c | 24 ++++++++--------- > 4 files changed, 69 insertions(+), 63 deletions(-) > > diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c > index 6777a3bd6226..948b3d00a564 100644 > --- a/drivers/remoteproc/qcom_q6v5_adsp.c > +++ b/drivers/remoteproc/qcom_q6v5_adsp.c > @@ -14,8 +14,8 @@ > #include > #include > #include > -#include > #include > +#include > #include > #include > #include > @@ -637,28 +637,26 @@ static int adsp_init_mmio(struct qcom_adsp *adsp, > > static int adsp_alloc_memory_region(struct qcom_adsp *adsp) > { > + struct reserved_mem *rmem = NULL; > struct device_node *node; > - struct resource r; > - int ret; > > node = of_parse_phandle(adsp->dev->of_node, "memory-region", 0); > + if (node) > + rmem = of_reserved_mem_lookup(node); > + of_node_put(node); > + > if (!node) { > - dev_err(adsp->dev, "no memory-region specified\n"); > + dev_err(adsp->dev, "unable to resolve memory-region\n"); > return -EINVAL; > } > > - ret = of_address_to_resource(node, 0, &r); > - of_node_put(node); > - if (ret) > - return ret; > - > - adsp->mem_phys = adsp->mem_reloc = r.start; > - adsp->mem_size = resource_size(&r); Aren't you missing a check for !rmem here? (The others has it) Regards, Bjorn