Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp129327ybz; Fri, 24 Apr 2020 13:03:39 -0700 (PDT) X-Google-Smtp-Source: APiQypLDyzvBR94gqVsaijpdyXyX2yghidlYx+hbPsff/Gu/tP9ekd6Qw48/2hMBsAF2tbp+k8Wl X-Received: by 2002:a17:906:7c11:: with SMTP id t17mr8968524ejo.73.1587758618881; Fri, 24 Apr 2020 13:03:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587758618; cv=none; d=google.com; s=arc-20160816; b=J+zLEXKGz9BFn41PeVyXSPEUqQH9BVN+lnf53CFKdfnIh69K9FdZT3ttqdpJ5AT+At aok3qCdFAYEwbSII3g6uKz1vy7aVsMLqbGwFMhUWAxUFTBSfItdNUKJC9m59BW7EGQNX UzewRL2QEgjmquMfSEyXUMIUnhStx8JcagkjoFnq9J5q5CG+Evwxz1WveJKGKuzHE0En xBAh3ynw8DbQPlm6Rvp2apn73tMcjspP8jyr1EuGTaopUfVZPSPi6rx34JbELQ5k7nRI xlF4yvb5EQeG1EF4PwwAjDHbeH35aXNYiaKPm1rpK/8QqC4Tg2ovaGyNm7Zx42qvVuO1 dyBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=waQEaUAc8T/vBKYd/zXfwKYFWqlxffUg008FrjfIrmw=; b=Gx9nyahEdaTSmKY+uwvmB2gdXGyBwtzC4QHXHZWxO0HnzOufcnghG4HDj21cb+LQzF CJ0c72Ll+J/vuwUyl9CzTCvtcHmxI75fznFhIyoTG56Fpbrg0inXhQZcNCJpMhspllNo 9aBYXl+ay1o+zXZLXqqXhbuGr4MAUlwX7E+HRgReA2Y0FXELuhYgyT2/5i0qWfCCEDZq kFXepGE0G2ILX1cG9KH4XCGnyXLVkXzu7u4Lh7bNlZyiOjA43JgLwDMlz69bOMsnr472 biKvrYmbqbJAvO1jYnl/nBdpB3oodeJpf7G/U4M397/yArAK1kSkPJSnaHo+QHb25IQJ 2ZJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hTGfqd8y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ba9si3711060edb.114.2020.04.24.13.03.07; Fri, 24 Apr 2020 13:03:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hTGfqd8y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1729397AbgDXUBn (ORCPT + 99 others); Fri, 24 Apr 2020 16:01:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729359AbgDXUBk (ORCPT ); Fri, 24 Apr 2020 16:01:40 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9545AC09B04B for ; Fri, 24 Apr 2020 13:01:40 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id d184so5314453pfd.4 for ; Fri, 24 Apr 2020 13:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=waQEaUAc8T/vBKYd/zXfwKYFWqlxffUg008FrjfIrmw=; b=hTGfqd8yUCMrEdbo4rCuRrcxrgEuIVxsi1FKpsn5N9UVWk0yhp8NSaQUCiTweALuTl nSsjV+VSYO34bwnqqtZVCDRTL1kN6AZ/b2OmfeMgy13IG8dHrg7cgyE0a88sR1mMoywU Rkf3TXu2y2l9NgvP5jlyQRXcTjLLdpsEGmp1spmaHKWht3WF+oaFfxr3NDvCABivdKDw wB2B7y6DKbqoOoevPhDD9+sWs4AZr1deXLnLmUWvvifSKPwfsyjQzN6g+o7qN40U9k2B v3Y5xi26tYT2O3tApbY+hsoralVI34cTrxMeJYG4pyYpMPor+ewEgJO3BMWx9UE9r7DU xJzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=waQEaUAc8T/vBKYd/zXfwKYFWqlxffUg008FrjfIrmw=; b=lFLsZpkC6jQOfJjO7PM0BALRj6a8HgDjXAltdz2grtebjm9nGYFfGZyNQdIfYNBlm4 5MfakmokeZV6Q0+6xR+Bq5hHpylLuP/KdAW/Gm+Lrb02/WbEnR5N7OTpkN/yCFUjG8Pr fKBamRCkyF1Kd0o7Dyr3Mh6lXo3g9ywUrU5GAGE5Gf5aZfRcAXA5F+i1XYJLNhfMkLgZ j8GayimFGGu7jBQ5RyA78cjj8XOSI5EKFWlSs2Mgl9euWFrJO7mAU7SuWbB988o81fdQ D43sAuLJCnVBPfPiQQfKf3tCcObVUrjzc0kV4FTa9YWVzjg0xPptcXFGvpUezUdOQU0s uAHg== X-Gm-Message-State: AGi0PuaMPiv9yAjR0imGQeETer6HxpTXR3U+smvDP7HW/1fSyshjdtAH Adp4T1LCV9T5ziNf79DnDWDzCg== X-Received: by 2002:a63:6285:: with SMTP id w127mr3451248pgb.449.1587758500035; Fri, 24 Apr 2020 13:01:40 -0700 (PDT) Received: from xps15.cg.shawcable.net (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id o11sm5532224pgd.58.2020.04.24.13.01.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2020 13:01:39 -0700 (PDT) From: Mathieu Poirier To: bjorn.andersson@linaro.org, ohad@wizery.com Cc: loic.pallardy@st.com, arnaud.pouliquen@st.com, s-anna@ti.com, linux-remoteproc@vger.kernel.org, corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 02/14] remoteproc: Introduce function rproc_alloc_internals() Date: Fri, 24 Apr 2020 14:01:23 -0600 Message-Id: <20200424200135.28825-3-mathieu.poirier@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200424200135.28825-1-mathieu.poirier@linaro.org> References: <20200424200135.28825-1-mathieu.poirier@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In scenarios where the remote processor's lifecycle is entirely managed by another entity there is no point in allocating memory for a firmware name since it will never be used. The same goes for a core set of operations. As such introduce function rproc_alloc_internals() to decide if the allocation of a firmware name and the core operations need to be done. That way rproc_alloc() can be kept as clean as possible. Signed-off-by: Mathieu Poirier --- drivers/remoteproc/remoteproc_core.c | 31 +++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 448262470fc7..1b4756909584 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -2076,6 +2076,30 @@ static int rproc_alloc_ops(struct rproc *rproc, const struct rproc_ops *ops) return 0; } +static int rproc_alloc_internals(struct rproc *rproc, + const struct rproc_ops *ops, + const char *name, const char *firmware) +{ + int ret; + + /* + * In scenarios where the remote processor's lifecycle is entirely + * managed by another entity there is no point in carrying a set + * of operations that will never be used. + * + * And since no firmware will ever be loaded, there is no point in + * allocating memory for it either. + */ + if (!ops) + return 0; + + ret = rproc_alloc_firmware(rproc, name, firmware); + if (ret) + return ret; + + return rproc_alloc_ops(rproc, ops); +} + /** * rproc_alloc() - allocate a remote processor handle * @dev: the underlying device @@ -2105,7 +2129,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name, { struct rproc *rproc; - if (!dev || !name || !ops) + if (!dev || !name) return NULL; rproc = kzalloc(sizeof(struct rproc) + len, GFP_KERNEL); @@ -2128,10 +2152,7 @@ struct rproc *rproc_alloc(struct device *dev, const char *name, if (!rproc->name) goto put_device; - if (rproc_alloc_firmware(rproc, name, firmware)) - goto put_device; - - if (rproc_alloc_ops(rproc, ops)) + if (rproc_alloc_internals(rproc, ops, name, firmware)) goto put_device; /* Assign a unique device index and name */ -- 2.20.1