Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3275588pxb; Wed, 14 Apr 2021 01:14:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnaIrzq9cqtawJbs+R8LHLZKAC7z2SJn/GRG0stBJ4WiyKP1ZwRGHi/8vli7lbZvsJzd/E X-Received: by 2002:a63:570e:: with SMTP id l14mr36218445pgb.159.1618388083658; Wed, 14 Apr 2021 01:14:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618388083; cv=none; d=google.com; s=arc-20160816; b=ey78E6E1rDoVGs6IMDTwSupUgrTlruVeE13Kw6LcV6PjpYqppQiORKpo7n3pU+V6Pj DTVDNRGRz9tPxqliB75ttSUctistndpOCHO5pXJadPkFp0HrxBtaebwwOmHsM/7XeGsg KGMCXhZ547nCF5mUZObeZW1R9wo0Onw9w0bBgOUQw7NL03n6YLiBwDf3162vDf+2n9F2 OfNR/xDfqP8MAh99EjFAO0C1JEWVnETfbjTgYBdnph1BBst4eE5N2liVLvMizatTyDxI tCk4DLj78RG2knU79Jc5+UkjWB8Qxi+gDhmF6hQ+3ZIs3VGeChNF4sUi+J2qchstRJVt fRWQ== 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=BADcf3smBQPBGql3mN7VdZeMYEdWGQAgGXkly2TDUSE=; b=U/KaKwQPgBsI0fIm8SCBxwJr2ZisZTGVzsHERSq+pdDAYZ9aX7N4CA7w+gLhjySrvg z62hH1TxU9/p6BNyDIGNbrnh/uHIzVwE9gV3z3vgrPhDkOvk6a682snSj14iTm2K5rQT 7zfttSWUHuCq89Id0M+1q9QZVeCwq3EAVPV5/i9IYNFoivQGRdu7V8ZT0DdWzF0tZ/SI aU53EU6v7nltOD9t31/qaY3lgd/fiwr+eYPMTMK4GrsivQC+7Ziz+w3mM8UAd2VEvdZR wkM2Zi4xEqNi1ZjtVGjeqknX1czcyZJTcM2S3fcNGro+5QV1T+8zrjaPMgeJvfp9gszX m5ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uuxDg30Z; 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 x17si15725296pgi.122.2021.04.14.01.14.31; Wed, 14 Apr 2021 01:14:43 -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=uuxDg30Z; 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 S244562AbhDMUv6 (ORCPT + 99 others); Tue, 13 Apr 2021 16:51:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239774AbhDMUvv (ORCPT ); Tue, 13 Apr 2021 16:51:51 -0400 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EDEEC061756 for ; Tue, 13 Apr 2021 13:51:27 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id p6-20020a9d69460000b029028bb7c6ff64so1283257oto.10 for ; Tue, 13 Apr 2021 13:51:27 -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=BADcf3smBQPBGql3mN7VdZeMYEdWGQAgGXkly2TDUSE=; b=uuxDg30ZNvq808mIE+x2+zZ9PmfAzxWCz4NaEpIgfbIUetY6YxRh4dz1U5PkEkv6rs zrhgGwEISnucLuHbcK1lxvIqsr4iL+b0g8nWSASoFVLKTEzq2gqgN2r0EwrUjLi7qYws LQIaNmOmF4BnXZ8ddWRq4PVsCWduKxXPxHLGWhFOAMin3tsWQVm0pp0S2b3zNbBn40MS o+rboo+H051Xqzb6GW99Tf+gUT3dcZ6TQ48KB/fCBVUdpELFvD7RrjiVmHMV8qomgt98 bLrJS36gRoL8N/IayVzcWGtaieCS5MDET8EEvy75rpZIyIxx9XmNG7ux0gEFb+54le6q DR6Q== 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=BADcf3smBQPBGql3mN7VdZeMYEdWGQAgGXkly2TDUSE=; b=hs+GSz1kzicU1rnMuWu6NZo/zdCAGvPvbhpl0/09SO4D5XE0T+02edkR1pxd0PvGO7 QlKLKiZ44YmxoMTDsQYmhDwP8S4Y095/+X+hRT8CHxdNu+9g6CB0qYBtf5XDF0Ic2zpt 4Ewi/ek5xUki48R786K/UXoggv4s1TMSYwx5EPcCw2dENUUDDnM8AAVF+hbULexbu23z dWBDKxHl9L2IFkamEK4XF0Oy9BBxeiCsvQcoqUv4KqpbpCjoAAMxbUYhY9GZA1CU1dV8 Fb6YQCT1vsH1+Ptu7ZjLnjvGpt9ZU5NrTdLYOpA+dcOtYF7KsSlQiJw8kenAfttaxvVz sSeg== X-Gm-Message-State: AOAM532k2nkvveFLoiHRczdX/nIaO8eK4GO9OMWWxPoJdtKEY7f4ldhU eHAeBp5M+aIuA8XboVTCdRWiEOJMoTIRFA== X-Received: by 2002:a9d:928:: with SMTP id 37mr24297744otp.98.1618347086349; Tue, 13 Apr 2021 13:51:26 -0700 (PDT) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id w5sm2433153oos.43.2021.04.13.13.51.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Apr 2021 13:51:25 -0700 (PDT) Date: Tue, 13 Apr 2021 15:51:23 -0500 From: Bjorn Andersson To: Arnaud Pouliquen Cc: Ohad Ben-Cohen , Mathieu Poirier , Rob Herring , Alexandre Torgue , devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] remoteproc: stm32: add capability to detach Message-ID: References: <20210318145923.31936-1-arnaud.pouliquen@foss.st.com> <20210318145923.31936-3-arnaud.pouliquen@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210318145923.31936-3-arnaud.pouliquen@foss.st.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 18 Mar 09:59 CDT 2021, Arnaud Pouliquen wrote: > From: Arnaud Pouliquen > > A mechanism similar to the shutdown mailbox signal is implemented to > detach a remote processor. > > Upon detachment, a signal is sent to the remote firmware, allowing it > to perform specific actions such as stopping RPMsg communication. > > The Cortex-M hold boot is also disabled to allow the remote processor > to restart in case of crash. > > Notice that for this feature to be supported, the remote firmware > resource table must be stored at the beginning of a 1kB section > (default size provided to the remoteproc core). > > This restriction should be lifted in the future by using a backup register > to store the actual size of the resource table. > > Signed-off-by: Arnaud Pouliquen > --- > drivers/remoteproc/stm32_rproc.c | 38 ++++++++++++++++++++++++++++++-- > 1 file changed, 36 insertions(+), 2 deletions(-) > > diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c > index 3d45f51de4d0..298ef5b19e27 100644 > --- a/drivers/remoteproc/stm32_rproc.c > +++ b/drivers/remoteproc/stm32_rproc.c > @@ -28,7 +28,7 @@ > #define RELEASE_BOOT 1 > > #define MBOX_NB_VQ 2 > -#define MBOX_NB_MBX 3 > +#define MBOX_NB_MBX 4 > > #define STM32_SMC_RCC 0x82001000 > #define STM32_SMC_REG_WRITE 0x1 > @@ -38,6 +38,7 @@ > #define STM32_MBX_VQ1 "vq1" > #define STM32_MBX_VQ1_ID 1 > #define STM32_MBX_SHUTDOWN "shutdown" > +#define STM32_MBX_DETACH "detach" > > #define RSC_TBL_SIZE 1024 > > @@ -336,6 +337,15 @@ static const struct stm32_mbox stm32_rproc_mbox[MBOX_NB_MBX] = { > .tx_done = NULL, > .tx_tout = 500, /* 500 ms time out */ > }, > + }, > + { > + .name = STM32_MBX_DETACH, > + .vq_id = -1, > + .client = { > + .tx_block = true, > + .tx_done = NULL, > + .tx_tout = 200, /* 200 ms time out to detach should be fair enough */ > + }, > } > }; > > @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc) > return stm32_rproc_set_hold_boot(rproc, true); > } > > +static int stm32_rproc_detach(struct rproc *rproc) > +{ > + struct stm32_rproc *ddata = rproc->priv; > + int err, dummy_data, idx; > + > + /* Inform the remote processor of the detach */ > + idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH); > + if (idx >= 0 && ddata->mb[idx].chan) { > + /* A dummy data is sent to allow to block on transmit */ > + err = mbox_send_message(ddata->mb[idx].chan, > + &dummy_data); Isn't it the stm32_ipcc driver on the other side of this call? In which case I believe "data" is ignored, and you would be able to just pass NULL here. As long as "data" isn't dereferenced it's probably better to send some bugus value, than an address to this variable on the stack. If on the other hand you pair this with one of the mailbox drivers that dereferences "data", you should initialize it... Apart from this, I think the patch looks good! Regards, Bjorn > + if (err < 0) > + dev_warn(&rproc->dev, "warning: remote FW detach without ack\n"); > + } > + > + /* Allow remote processor to auto-reboot */ > + return stm32_rproc_set_hold_boot(rproc, false); > +} > + > static int stm32_rproc_stop(struct rproc *rproc) > { > struct stm32_rproc *ddata = rproc->priv; > @@ -597,7 +626,11 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz) > } > > done: > - /* Assuming the resource table fits in 1kB is fair */ > + /* > + * Assuming the resource table fits in 1kB is fair. > + * Notice for the detach, that this 1 kB memory area has to be reserved in the coprocessor > + * firmware for the resource table. A clean of this whole area is done on detach. > + */ > *table_sz = RSC_TBL_SIZE; > return (struct resource_table *)ddata->rsc_va; > } > @@ -607,6 +640,7 @@ static const struct rproc_ops st_rproc_ops = { > .start = stm32_rproc_start, > .stop = stm32_rproc_stop, > .attach = stm32_rproc_attach, > + .detach = stm32_rproc_detach, > .kick = stm32_rproc_kick, > .load = rproc_elf_load_segments, > .parse_fw = stm32_rproc_parse_fw, > -- > 2.17.1 >