From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C10A9D2CDE6 for ; Tue, 22 Oct 2024 15:54:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8AkVLCCPZxZ1fApkqmTMKj62SttuuqmnYfplcOKZMck=; b=HOpOTTApbfNijGdn3jASLizmib 2drB9aUph1tzN4JGsUex7Puie7phCmmD//I9uou5shaGswnNshy0wqd4pEl0bFhp+cCVkzEz29eD4 vXc87FekAi3nzR3jMvTRbuOurB4mu4MUFljrNQBNhGZvK+WIXia8dVlb3Ouuat82uEQWsqLmAn75h xmxgkvRJYHGUUNyOaweA0/X12H3miPQiGuinDyfafsP2DTRl3fk8nvdk4CAcR3SKtKEQvusp1kmtK SpmT31rBVF6wJ+yqulhqiBiqn1mQQMYih5xDqGI/ciRDkgG3cZILrZTtduHcUt7/IKyeQIDbVlJtX UH3bdudw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3HCj-0000000BK3b-0yRI; Tue, 22 Oct 2024 15:53:53 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3HB8-0000000BJgx-2UQH for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 15:52:15 +0000 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-20c77459558so49727065ad.0 for ; Tue, 22 Oct 2024 08:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1729612333; x=1730217133; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8AkVLCCPZxZ1fApkqmTMKj62SttuuqmnYfplcOKZMck=; b=PHsJke+fQ9GkRBiNjmY9YXqPR2B+QBj94VvktYz6EIOjWgC1lNAVP8ZAE6Pw+aCk7A 3PD/mOVzqqbsExIg7DwmEdamMKS9kxpSD9bjXnDgFdJyDDBdVlIq3efwYWZknsgScqlB uhyx/xhhLssjRUuNDTBOiBlD8AHFkB86yxK1c3d7MZJN4/TSwnhaYzaRdKVgKpUQXCmh kHskf9jXxhTHbXFDZCfBtCDxeorYmHfUxXxFhfgBrBq7uc6JJqWcoSCZbRCrXYC0cgbW baDWo3aTuTV/W6nYQeuuattffIPX/87qOG2CVsbMRVa3Eipj3Kvj77Pxrwr4g0sHmfra HSwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729612333; x=1730217133; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8AkVLCCPZxZ1fApkqmTMKj62SttuuqmnYfplcOKZMck=; b=nABdY2L0rMLM360FyVkLf0gpfhaqbXNV6qMfca4Djk7xRfwZ+FPuWHrvlHVsBtNgGi jbRLmBfRWW+ntXwXd73TTxDMffax8NzQadj+BbpdhoIcfHGpsB5HPQp8DEW3R3hXUTIF QJvH2i+8Sb4Jt8JEO9TTzP2hX4baFev7bcIdRwXpzzc+5ed0nCkEtK45ZbFNkpqIV4MY BguzjLHq99TKaex3m22bgfhoDfpjwSI3rVYOsA+/F+JNb748i+qFacZzP5CVpvmIPUPw r3sEfw1i1n8tgZvRSLK6Tk4KTTksQ/tQrOSsSlXtKqWV887k1w0a5pqqMc8f0CIBFfEK QB5A== X-Forwarded-Encrypted: i=1; AJvYcCV5LgMf0ZNAhBRQPJBANHhYCqQY4XcJmnxGEM21l+dwz01BDgHvU60m9rl+xwMCZiks4WlMN40mgU4+USObl06U@lists.infradead.org X-Gm-Message-State: AOJu0YyA9AnHDJEy1aIaSztONj/BtE280RjqFjXQMWeB2QPJ3iUUrdW9 cH0AGYYzSs6LUAJsZW9t6aHvEGSicxSIED2mrPkDXT0vByalS4DNBAIVnPLEy5M= X-Google-Smtp-Source: AGHT+IEsN3+xGI76q2s1diRf4iXLrreaf3Jeckwsh5L0/TmOy3pREL6E0A6kjoW8nKAID3UtRLL8+w== X-Received: by 2002:a17:903:1cc:b0:20c:c880:c3b0 with SMTP id d9443c01a7336-20e948aefd1mr44835425ad.21.1729612332913; Tue, 22 Oct 2024 08:52:12 -0700 (PDT) Received: from p14s ([2604:3d09:148c:c800:567b:4c87:a9aa:a404]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20e7ef0c5e4sm44510525ad.97.2024.10.22.08.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 08:52:12 -0700 (PDT) Date: Tue, 22 Oct 2024 09:52:09 -0600 From: Mathieu Poirier To: Arnaud Pouliquen Cc: Bjorn Andersson , Jens Wiklander , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org Subject: Re: [PATCH v11 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware Message-ID: References: <20241009080108.4170320-1-arnaud.pouliquen@foss.st.com> <20241009080108.4170320-8-arnaud.pouliquen@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241009080108.4170320-8-arnaud.pouliquen@foss.st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241022_085214_659516_8B330172 X-CRM114-Status: GOOD ( 35.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 09, 2024 at 10:01:08AM +0200, Arnaud Pouliquen wrote: > The new TEE remoteproc driver is used to manage remote firmware in a > secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is > introduced to delegate the loading of the firmware to the trusted > execution context. In such cases, the firmware should be signed and > adhere to the image format defined by the TEE. > > Signed-off-by: Arnaud Pouliquen > --- > updates vs v9 revision: > - rename tee_interface to tee_rproc_itf > - in stm32_rproc_probe(), test and use rproc->tee_rproc_itf instead of > trproc in the tee_rproc_unregister() call > - initialize release_fw ops > --- > drivers/remoteproc/stm32_rproc.c | 63 ++++++++++++++++++++++++++++++-- > 1 file changed, 60 insertions(+), 3 deletions(-) > > diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c > index 288bd70c7861..cb7093de41df 100644 > --- a/drivers/remoteproc/stm32_rproc.c > +++ b/drivers/remoteproc/stm32_rproc.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -255,6 +256,19 @@ static int stm32_rproc_release(struct rproc *rproc) > return 0; > } > > +static int stm32_rproc_tee_stop(struct rproc *rproc) > +{ > + int err; > + > + stm32_rproc_request_shutdown(rproc); > + > + err = tee_rproc_stop(rproc); > + if (err) > + return err; > + > + return stm32_rproc_release(rproc); > +} > + > static int stm32_rproc_prepare(struct rproc *rproc) > { > struct device *dev = rproc->dev.parent; > @@ -691,8 +705,20 @@ static const struct rproc_ops st_rproc_ops = { > .get_boot_addr = rproc_elf_get_boot_addr, > }; > > +static const struct rproc_ops st_rproc_tee_ops = { > + .prepare = stm32_rproc_prepare, > + .start = tee_rproc_start, > + .stop = stm32_rproc_tee_stop, > + .kick = stm32_rproc_kick, > + .load = tee_rproc_load_fw, > + .parse_fw = tee_rproc_parse_fw, > + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table, > + .release_fw = tee_rproc_release_fw, > +}; > + > static const struct of_device_id stm32_rproc_match[] = { > { .compatible = "st,stm32mp1-m4" }, > + { .compatible = "st,stm32mp1-m4-tee" }, > {}, > }; > MODULE_DEVICE_TABLE(of, stm32_rproc_match); > @@ -851,17 +877,42 @@ static int stm32_rproc_probe(struct platform_device *pdev) > struct device *dev = &pdev->dev; > struct stm32_rproc *ddata; > struct device_node *np = dev->of_node; > + struct tee_rproc *trproc = NULL; The cleaner this patchset get, the more obvious it is (at least to me) that struct tee_rproc needs to be changed to struct rproc_tee. Otherwise I keep wondering if this is coming from the TEE subsystem or the remoteproc subsystem. > struct rproc *rproc; > unsigned int state; > + u32 proc_id; > int ret; > > ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > if (ret) > return ret; > > - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata)); > - if (!rproc) > - return -ENOMEM; > + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) { > + /* > + * Delegate the firmware management to the secure context. > + * The firmware loaded has to be signed. > + */ > + ret = of_property_read_u32(np, "st,proc-id", &proc_id); > + if (ret) { > + dev_err(dev, "failed to read st,rproc-id property\n"); > + return ret; > + } > + > + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, NULL, sizeof(*ddata)); > + if (!rproc) > + return -ENOMEM; > + > + trproc = tee_rproc_register(dev, rproc, proc_id); This should return an integer rather than a struct tee_rproc * since the latter is available through rproc->tee_rproc_itf. In line with my comment above, this should be changed to rproc_tee_register() since it belongs to the remoteproc subsystem. Before when I asked for tee_remoteproc.c to be changed to remoteproc_tee.c, I thought we could get by without changing the inside but now I think it is clear that we can't - this needs to be addressed. > + if (IS_ERR(trproc)) { > + dev_err_probe(dev, PTR_ERR(trproc), > + "signed firmware not supported by TEE\n"); > + return PTR_ERR(trproc); return dev_err_probe(...); > + } > + } else { > + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata)); > + if (!rproc) > + return -ENOMEM; > + } > > ddata = rproc->priv; > > @@ -913,6 +964,9 @@ static int stm32_rproc_probe(struct platform_device *pdev) > dev_pm_clear_wake_irq(dev); > device_init_wakeup(dev, false); > } > + if (rproc->tee_rproc_itf) > + tee_rproc_unregister(rproc->tee_rproc_itf); > + If I read Bjorn's comment properly, this should probably be: rproc_tee_unregister(rproc); with the if() inside the function. > return ret; > } > > @@ -933,6 +987,9 @@ static void stm32_rproc_remove(struct platform_device *pdev) > dev_pm_clear_wake_irq(dev); > device_init_wakeup(dev, false); > } > + if (rproc->tee_rproc_itf) > + tee_rproc_unregister(rproc->tee_rproc_itf); > + Same here. I am done reviewing this set. Thanks, Mathieu > } > > static int stm32_rproc_suspend(struct device *dev) > -- > 2.25.1 >