Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3664213pxj; Tue, 1 Jun 2021 10:17:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMeYycPiRiDjuD6ZmmfblCAY0lcgYS/4CgL9p3U+6zbT4YVuvlTyE0bpVF4BJX6w+tRZf4 X-Received: by 2002:a02:a312:: with SMTP id q18mr26277004jai.24.1622567829081; Tue, 01 Jun 2021 10:17:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622567829; cv=none; d=google.com; s=arc-20160816; b=sYgnzS7QmeggQhCJBbRuryCwHvivEdy50du9L73buDsQzsxgVb4SoffGbOs+63JnaB h4cGQkOcpH8/ILH/VLM2J5U7f6QUtQlHMU+6nkCidKpB8Lyxu77uogQ5JVnks686lkqW grfjlzHg9MiA9URRWfCpGjm7wzGCyLC5YyEfyx/45ZpSZTtZnyEDB0l/yINFVcGil0w+ cEzVuoWM/h9cV2XItRekUw7lonehSyXpw3EbGkqGlcObsmlBHfmBQ78NI0kDA1Nsg2ud 8RA3JL7etsTcq6eLzA06vTmV3sxPgwK9dSLNAs0kDMirXYRcu1rbO2/0O1yA9FUwpCPT 9qlg== 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=U65hdesdvDmorFbtO287+I+YEZ3urVVgKrKl2j6XaOE=; b=wob1bVUwIP+7jvmYvf0k6g/INCAZrHPqNeDNvvt5YGtJza0oKHDbUdD5x6kT7OC4uY 10LRCvs3dPq6lzFIPCy0niqOgZRVohEleffZXqJq9zUSM30bETDMpJaxqucJWBSuuP2Q 9QbWYgchW4PP9uHXABkjWTOCSS3G49nZcSH2MDV3xcwB2AUsJE5+QhWxLOAm8rV/qyra 6EZre5IIiAyECh/qBJ57OR+659zY8DelJ4MMbhtRkvsadJXAEsop0dh19VLHjqVw2Inj V+adrReydqI/UzjaB5b2kCbw2yxiL/TtrJ3mz4ND2xF7W7Gqjml9rx6ozy4v2wM9XWn4 n0Pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=lQ2a6yQO; 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 v19si18992252jan.91.2021.06.01.10.16.55; Tue, 01 Jun 2021 10:17:09 -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=lQ2a6yQO; 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 S231918AbhFARQy (ORCPT + 99 others); Tue, 1 Jun 2021 13:16:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233301AbhFARQy (ORCPT ); Tue, 1 Jun 2021 13:16:54 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DCE4C06174A for ; Tue, 1 Jun 2021 10:15:12 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id i22so99478pju.0 for ; Tue, 01 Jun 2021 10:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U65hdesdvDmorFbtO287+I+YEZ3urVVgKrKl2j6XaOE=; b=lQ2a6yQOhnzrehY6i6bUnFYQhtdk49xyq3u3DAqS0+a09Kuf5d8sBn1xy56r7yaWHt sBEmAsPdBN6igfc5WbwC0LP6Azup6KLjdcpK/8WAZNUq7C9VfjiQjSy8b0AYlHQ5lyN/ Vy1FMVcHCwms5Q2pMh5Rb71K/PqC+BoZrhonxDob60Bq6Q5frWNoTvycZsXsTINvgL31 9TmxjCbxehPCXkTNlqtt3YCrxT2+vL0j817NLmy+BE1JJD9V7EKWsfosQmesLTw5X5So D6mEn1oGlfW2IIJYnY773fUsJudSHJLNReG3vI7VfdUoBT5Y1iqOCvfBSZz3pjcc4lAn nKlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U65hdesdvDmorFbtO287+I+YEZ3urVVgKrKl2j6XaOE=; b=TdL4BqQdXaW8cfVCsJlhPCmaeg9pGHkZGJ8n1ARPvKBI2YIzxJVTMUmpIQbhX642Ro aNe4Z6SrW5AVaNx0GbE1Ii9hOWvfrZIz62lNVoV7YaMZN36BkqkjJ9LUb4ism5/pjoJm 97I6BD68+OLZXr9lATGiEDY7Jw/CbZOMW3PI6tQbkIVHvgZNqR07MpLguqX65mycHi/K j0FI4JYuTcGMhcfQP0Q6xsnVGpfRfhoVKKH8DhrwMP11emCABO66a9AjPL9A1o3IxU7W LZI3uebL4TeqxbsPUIbjZkLKYTbS2IvEIjJuoutFF7Gmj+82XGhy1BiHACvmCVTNSyKI 5ZXw== X-Gm-Message-State: AOAM530edczOoMDjpCI/xxORS9a/rqkR+S88TsI/OUewx8IYvK6h5fGp lMM1n4zI41U9iykDqR4UH+m27Q== X-Received: by 2002:a17:90b:4d82:: with SMTP id oj2mr25737050pjb.61.1622567712053; Tue, 01 Jun 2021 10:15:12 -0700 (PDT) Received: from xps15 (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id pg5sm13382530pjb.28.2021.06.01.10.15.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 10:15:10 -0700 (PDT) Date: Tue, 1 Jun 2021 11:15:08 -0600 From: Mathieu Poirier To: Suman Anna Cc: Bjorn Andersson , Lokesh Vutla , Tero Kristo , linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/6] remoteproc: Add support for detach-only during shutdown Message-ID: <20210601171508.GC1759269@xps15> References: <20210522000309.26134-1-s-anna@ti.com> <20210522000309.26134-3-s-anna@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey guys, On Fri, May 28, 2021 at 11:40:02AM -0500, Suman Anna wrote: > Hi Bjorn, > > On 5/27/21 11:11 PM, Bjorn Andersson wrote: > > On Fri 21 May 19:03 CDT 2021, Suman Anna wrote: > > > >> The remoteproc core has support for both stopping and detaching a > >> remote processor that was attached to previously, through both the > >> remoteproc sysfs and cdev interfaces. The rproc_shutdown() though > >> unconditionally only uses the stop functionality at present. This > >> may not be the default desired functionality for all the remoteproc > >> platform drivers. > >> > >> Introduce a new rproc state flag 'detach_on_shutdown' that individual > >> remoteproc drivers can set to only allow detach in rproc_shutdown() > >> that would have been invoked when the driver is uninstalled, so that > >> remote processor continues to run undisturbed even after the driver > >> removal. > >> > > > > I dislike the introduction of knobs for everything and would much rather > > see that we define some sound defaults. Can we make shutdown just do > > detach() if that's supported otherwise stop(). > > > > I maybe missing your point, but the change in remoteproc_core below exactly does > that, right? Are you saying drop the checks in remoteproc_cdev and remoteproc_sysfs? > > The asymmetry did bug me as well, but it is already existing even before this > patch. I personally would have preferred a cleaner and symmetrical attach, > start, stop, detach, but existing code has overloaded attach into start (keys > off by RPROC_OFFLINE/RPROC_DETACHED) while introducing a separate detach from > stop. I have retained the meaning of stop as shutdown from userspace interface > perspective, but enforcing the checks for detach only remoteprocs. > > The logic in rproc_shutdown is for driver paths. > > > This still allows userspace to explicitly stop the detachable remoteproc > > before shutdown, if for some reason that's what you want... > > This is the existing behavior and the difference between stop and detach. That > behavior is maintained for remoteprocs not setting the detach_on_shutdown flag. > I am only restricting the behavior for those that set it. > > Mathieu, > Your thoughts on this? Introducing knobs in such a way makes the code very difficult to understand and maintain. It is also a matter of time before another knob is introduced to modify the behavior of this knob. Function rproc_detach() is exported and should be used in the platform driver if the state of the remote processor mandates it. Function rproc_del() calls rproc_shutdown() but the latter will return immediately because of rproc->power. So calling rproc_detach() followed by rproc_del() will work as expected. The real fix is to de-couple rproc_shutdown from rproc_del() and do the right calls in the platform drivers using them. With regards to rproc_cdev_write(), the state of the remote processor is advertised in sysfs. As such it should be easy to write "stop" or "detach" to the character interface. If a command to stop the remote processor is not supported in a scenario then rproc_ops::stop should reflect that. If that is the case then rproc_shutdown() should be modified to return an error code, the same way rproc_detach() was done. > > regards > Suman > > > > > > > Regards, > > Bjorn > > > >> Signed-off-by: Suman Anna > >> --- > >> drivers/remoteproc/remoteproc_cdev.c | 7 +++++++ > >> drivers/remoteproc/remoteproc_core.c | 5 ++++- > >> drivers/remoteproc/remoteproc_sysfs.c | 6 ++++++ > >> include/linux/remoteproc.h | 3 +++ > >> 4 files changed, 20 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/remoteproc/remoteproc_cdev.c b/drivers/remoteproc/remoteproc_cdev.c > >> index 0b8a84c04f76..473467711a09 100644 > >> --- a/drivers/remoteproc/remoteproc_cdev.c > >> +++ b/drivers/remoteproc/remoteproc_cdev.c > >> @@ -42,6 +42,13 @@ static ssize_t rproc_cdev_write(struct file *filp, const char __user *buf, size_ > >> rproc->state != RPROC_ATTACHED) > >> return -EINVAL; > >> > >> + if (rproc->state == RPROC_ATTACHED && > >> + rproc->detach_on_shutdown) { > >> + dev_err(&rproc->dev, > >> + "stop not supported for this rproc, use detach\n"); > >> + return -EINVAL; > >> + } > >> + > >> rproc_shutdown(rproc); > >> } else if (!strncmp(cmd, "detach", len)) { > >> if (rproc->state != RPROC_ATTACHED) > >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > >> index 6019f46001c8..e8ab3eb41f00 100644 > >> --- a/drivers/remoteproc/remoteproc_core.c > >> +++ b/drivers/remoteproc/remoteproc_core.c > >> @@ -2074,7 +2074,10 @@ void rproc_shutdown(struct rproc *rproc) > >> if (!atomic_dec_and_test(&rproc->power)) > >> goto out; > >> > >> - ret = rproc_stop(rproc, false); > >> + if (rproc->detach_on_shutdown && rproc->state == RPROC_ATTACHED) > >> + ret = __rproc_detach(rproc); > >> + else > >> + ret = rproc_stop(rproc, false); > >> if (ret) { > >> atomic_inc(&rproc->power); > >> goto out; > >> diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c > >> index ea8b89f97d7b..1785fbcb1075 100644 > >> --- a/drivers/remoteproc/remoteproc_sysfs.c > >> +++ b/drivers/remoteproc/remoteproc_sysfs.c > >> @@ -206,6 +206,12 @@ static ssize_t state_store(struct device *dev, > >> rproc->state != RPROC_ATTACHED) > >> return -EINVAL; > >> > >> + if (rproc->state == RPROC_ATTACHED && > >> + rproc->detach_on_shutdown) { > >> + dev_err(&rproc->dev, "stop not supported for this rproc, use detach\n"); > >> + return -EINVAL; > >> + } > >> + > >> rproc_shutdown(rproc); > >> } else if (sysfs_streq(buf, "detach")) { > >> if (rproc->state != RPROC_ATTACHED) > >> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > >> index 42a1f30e33a7..35ef921676a1 100644 > >> --- a/include/linux/remoteproc.h > >> +++ b/include/linux/remoteproc.h > >> @@ -530,6 +530,8 @@ struct rproc_dump_segment { > >> * @elf_machine: firmware ELF machine > >> * @cdev: character device of the rproc > >> * @cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release > >> + * @detach_on_shutdown: flag to indicate if remoteproc cannot be shutdown in > >> + * attached state and _only_ support detach > >> */ > >> struct rproc { > >> struct list_head node; > >> @@ -569,6 +571,7 @@ struct rproc { > >> u16 elf_machine; > >> struct cdev cdev; > >> bool cdev_put_on_release; > >> + bool detach_on_shutdown; > >> }; > >> > >> /** > >> -- > >> 2.30.1 > >> >