Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2153581pxb; Sat, 21 Nov 2020 10:42:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJzSVvKIoj+geH6d6u2kdRJJoJdpdJK6Gpf1BHmQUNaqHdZowmJn/S9bWzjhkR0HJL8SPPqO X-Received: by 2002:aa7:cb58:: with SMTP id w24mr40611436edt.35.1605984162568; Sat, 21 Nov 2020 10:42:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605984162; cv=none; d=google.com; s=arc-20160816; b=cPIL+imLv8cyqOA9fRl31NsgccvGRd+zpfXYHnEGTcPStJ3hudv/hgDF/n66k8zfhk 5QTqrZxlq05LjPkFK21UWr8FUg5NPh4QabkqeREQwGn5mYJRxEgfknsb1Fmgw8JZhnwp Dcv6nqOYUecFdtZw+YWxEJBv3fBNlJNW8yRCwqwl3t26Gnhs4fuc0HxfGSNvd9cgJ2Bv evxaWchr0wOGoXcubj7Uy2d5LsApK0PFsJblwkrx/xvGqTuYwy6B+PZV4vaWSao7cXtw /YiGVt4Ic96GL3/VjfQHXLC6S+hpwJMnOUZdvrBYexdAJ4pEixy7mHfcpCIc7058QhXa J9wg== 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:cc:to:subject:from:date; bh=XimLmXNi5Bek2UsERnDoLmEoXGN5ExlBxLJFqatP5rk=; b=tkzc348lQ5H6Ikmf+ACDVBtI4tm+C5UOKDQyxpOfhcqPkp48HZBtUgHAHUhIDgVw21 1P76Pkc8QbMlHEm3lZ9f6Je8YsZjKU0HWpNGkZfOriyGeoU5udM5dRjcdveCwNqI1qwk cxGqElCVU4bVj8S7qphFZOUIvx8fsdjk1Ho/cj78ZOb9t5d0LY6sDzCNgLurnnhbpmVP PXDxB/Z0PP7LEIdFyc5GYqrJx0HqM0AKNxaHRfqjC2WsFT627qQQ9lqZCXLjx2VDckqs ht0dLkfy+f7NbhFrDFMajoN61kqdyzkRYta4tIdCefLjYjQN8Dr8qYEMHILHsMS/bzAR wn6A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y9si146878edq.302.2020.11.21.10.42.20; Sat, 21 Nov 2020 10:42:42 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728223AbgKUSjC convert rfc822-to-8bit (ORCPT + 99 others); Sat, 21 Nov 2020 13:39:02 -0500 Received: from aposti.net ([89.234.176.197]:49176 "EHLO aposti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727032AbgKUSjC (ORCPT ); Sat, 21 Nov 2020 13:39:02 -0500 Date: Sat, 21 Nov 2020 18:38:49 +0000 From: Paul Cercueil Subject: Re: [PATCH] remoteproc: Add module parameter 'auto_boot' To: Mathieu Poirier Cc: Ohad Ben-Cohen , Bjorn Andersson , od@zcrc.me, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <20201120223701.GF4137289@xps15> References: <20201115115056.83225-1-paul@crapouillou.net> <20201120223701.GF4137289@xps15> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mathieu, Le ven. 20 nov. 2020 ? 15:37, Mathieu Poirier a ?crit : > Hi Paul, > > On Sun, Nov 15, 2020 at 11:50:56AM +0000, Paul Cercueil wrote: >> Until now the remoteproc core would always default to trying to >> boot the >> remote processor at startup. The various remoteproc drivers could >> however override that setting. >> >> Whether or not we want the remote processor to boot, really depends >> on >> the nature of the processor itself - a processor built into a WiFi >> chip >> will need to be booted for the WiFi hardware to be usable, for >> instance, >> but a general-purpose co-processor does not have any predeterminated >> function, and as such we cannot assume that the OS will want the >> processor to be booted - yet alone that we have a single do-it-all >> firmware to load. >> > > If I understand correctly you have various remote processors that use > the same firmware > but are serving different purposes - is this correct? That's the opposite actually. I have one remote processor which is general-purpose, and as such userspace may or may not want it started at boot time - depending on what it wants to do with it. The kernel shouldn't decide itself whether or not the remote processor should be started, because that's policy. > >> Add a 'auto_boot' module parameter that instructs the remoteproc >> whether >> or not it should auto-boot the remote processor, which will default >> to >> "true" to respect the previous behaviour. >> > > Given that the core can't be a module I wonder if this isn't > something that > would be better off in the specific platform driver or the device > tree... Other > people might have an opinion as well. Hardcoded in the platform driver or flagged in the device tree, doesn't change the fundamental problem - it should be up to the userspace to decide whether or not the remote processor should boot. Cheers, -Paul > >> Signed-off-by: Paul Cercueil >> --- >> drivers/remoteproc/remoteproc_core.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/remoteproc/remoteproc_core.c >> b/drivers/remoteproc/remoteproc_core.c >> index dab2c0f5caf0..687b1bfd49db 100644 >> --- a/drivers/remoteproc/remoteproc_core.c >> +++ b/drivers/remoteproc/remoteproc_core.c >> @@ -44,6 +44,11 @@ >> >> #define HIGH_BITS_MASK 0xFFFFFFFF00000000ULL >> >> +static bool auto_boot = true; >> +module_param(auto_boot, bool, 0400); >> +MODULE_PARM_DESC(auto_boot, >> + "Auto-boot the remote processor [default=true]"); >> + >> static DEFINE_MUTEX(rproc_list_mutex); >> static LIST_HEAD(rproc_list); >> static struct notifier_block rproc_panic_nb; >> @@ -2176,7 +2181,7 @@ struct rproc *rproc_alloc(struct device *dev, >> const char *name, >> return NULL; >> >> rproc->priv = &rproc[1]; >> - rproc->auto_boot = true; >> + rproc->auto_boot = auto_boot; >> rproc->elf_class = ELFCLASSNONE; >> rproc->elf_machine = EM_NONE; >> >> -- >> 2.29.2 >>