Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2517632ybt; Sun, 21 Jun 2020 23:43:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYbyRMMb+MvBkDBjrPwLOPOcHWMsuFV+/7JoGtOkVvq95Cz4fi8ZH6oR1uMkr6YPrUzeI6 X-Received: by 2002:a05:6402:30ae:: with SMTP id df14mr15092485edb.310.1592808219648; Sun, 21 Jun 2020 23:43:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592808219; cv=none; d=google.com; s=arc-20160816; b=gGK79J5FTZsi9dJpxJOFYmel/oy/sZt2Scz6d3A2FH0e3kpejYxKBacA/ECpAPAqUc 8oRkQkGdHB7qgqA0OtRuimP4JWsR8jCBcwx49xt2fHsrUR4Teqed6y6M4Xyyb7pBzoda QkQ2XkssY7c6mxYufCRYz62dL63uPk5OCBjDaxs2IvxrjY6VWMCXOPEaIVAKtzvACJtr rfScXiLghM2V9xOO/UEN/A4ZuqHAVao5cBmZ5Q3xWUZNNWetS56MXpHKIQ+xuGNDzH9u o9Qyuy9Sg5lUT6v9/Y+xHJWH9JZgXtU3tYu68l7E5qSNg2SnPPdcRHhb+CVc9I1hYiTa ycrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=dNuMdqRwrLz9vD8xRJNwtGlXJp39SHPqNF0e6VyJIxM=; b=GsmdYKk/UNnro3AwuJxwIUxMnbV9IGbdmyxBDpVPDlIVstjEyQd6Rf3brQu3nJQKYV J7WeitNcAYOjiqHfsQn/YZTKiCDYcWu/HtAXeIZQEahk1JG8z290j8XwtxDRPkrM9I6V /YqujUTxXUu/dDh4p2Md0XkRK0cexZ8XKusUc7bM2e6O6L42lbrF3HZfMlY5/yCtocPf RHqP5s7HxaD3vd9TCaOEBitXGEgrJHrHcJWuWdjMCGgqbwf7+bv0Lq397oAStIuC51Uf FhkYz9iOffspISOjEJ2YAQKM3FEaos5RR8EWoEbcj2pmaabdnQDilW985/QVlc8rdXRV GsPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bv4KyCep; 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 w17si3535553edx.522.2020.06.21.23.43.17; Sun, 21 Jun 2020 23:43:39 -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=bv4KyCep; 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 S1726765AbgFVGj0 (ORCPT + 99 others); Mon, 22 Jun 2020 02:39:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726738AbgFVGjZ (ORCPT ); Mon, 22 Jun 2020 02:39:25 -0400 Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70B50C061794 for ; Sun, 21 Jun 2020 23:39:25 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id 64so1275168oti.5 for ; Sun, 21 Jun 2020 23:39:25 -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=dNuMdqRwrLz9vD8xRJNwtGlXJp39SHPqNF0e6VyJIxM=; b=bv4KyCepxXxyrUB07sqH9I911+MDHV9RKlAjq4QDoSgiSZCLomrGM4kqhCvgqbIm7w x2cWkwy2Krx0Y9QOlBsAlJ6SjOlyuxDncP/pKu/83xR+NkBtQ2aZdoH9bsO2vsGLmq7/ DoIODaVtZPysg9dV78iybpIHuMrxrbPvwDiOfkJOh2aB8KlSRthYpFKSMOXaGr/4y8Ox UkHhPvRFEpsyYr932fUEedU2G90zwQc7Rf8WMfx5EdWBDJHZCCyPwzwYOktLytK2+LX2 B7OpdS+q+tBaaTSK1BOzaxe0iUkKbz5oAnQypR/G41UqpUPCDQBv8nr0St5JfmymPvap lPvQ== 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=dNuMdqRwrLz9vD8xRJNwtGlXJp39SHPqNF0e6VyJIxM=; b=somBJifjxApC/plgnE7ic9QjsG/w//3AEPsaTL+PoSkC/kDcEKiBoLBBDGgstIVeT2 Esv7G6r9W8HZgz45T6aSZSqUIeMjct2KC03uVLk6PrJNeDPHTTAHy3N14x1Vlvk0sVAd mFCZ77nEyBsAwHpvDWRgwcLS+N/nBg8nkGvrBQPtzFgzGlSJSbpePvBO0wOX5FOYC5cw uJcYAiw1v6QtJbgd6jJhWByPpRE6YUDue0za9AfZjMSx2+xTUijQ0VBGQGCSFwuZNsnY h40Di7cWc51UiJXu6y/oS52MxvI9K8+yL5j2iyt+X8ncBdsXr6e1dzA2Z8b7b44Srfdc AnDw== X-Gm-Message-State: AOAM530j7gF/finR+eXg1Yjcva2BkA/pUPSEuPDDjiypIAqWDvNRQqNT GvUZNHtdm3WGnu7uU4DfG12nsQ== X-Received: by 2002:a05:6830:1e61:: with SMTP id m1mr12271701otr.13.1592807964696; Sun, 21 Jun 2020 23:39:24 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id g12sm3271301oos.8.2020.06.21.23.39.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2020 23:39:24 -0700 (PDT) Date: Sun, 21 Jun 2020 23:36:38 -0700 From: Bjorn Andersson To: Mathieu Poirier Cc: ohad@wizery.com, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, loic.pallardy@st.com, arnaud.pouliquen@st.com, s-anna@ti.com Subject: Re: [PATCH v4 2/9] remoteproc: Add new attach() remoteproc operation Message-ID: <20200622063638.GC149351@builder.lan> References: <20200601175139.22097-1-mathieu.poirier@linaro.org> <20200601175139.22097-3-mathieu.poirier@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200601175139.22097-3-mathieu.poirier@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 01 Jun 10:51 PDT 2020, Mathieu Poirier wrote: > Add an new attach() operation in order to properly deal with > scenarios where the remoteproc core needs to attach to a > remote processor that has been booted by another entity. > > Signed-off-by: Mathieu Poirier > --- > drivers/remoteproc/remoteproc_internal.h | 8 ++++++++ > include/linux/remoteproc.h | 2 ++ > 2 files changed, 10 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h > index 4ba7cb59d3e8..fc710866f8ce 100644 > --- a/drivers/remoteproc/remoteproc_internal.h > +++ b/drivers/remoteproc/remoteproc_internal.h > @@ -79,6 +79,14 @@ static inline int rproc_unprepare_device(struct rproc *rproc) > return 0; > } > > +static inline int rproc_attach_device(struct rproc *rproc) > +{ > + if (rproc->ops->attach) > + return rproc->ops->attach(rproc); > + > + return 0; Afaict we don't allow the registration of a remoteproc in DETACHED state without an "attach" function specified and as such we shouldn't be able to end up here. On the other hand I think it would make sense to have a system where "attach" simply just means bring up the communication with the remote processor, so let's keep it as is and we can adjust it as necessary later. Reviewed-by: Bjorn Andersson Regards, Bjorn > +} > + > static inline > int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw) > { > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index 21182ad2d059..bf6a310ba870 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -359,6 +359,7 @@ enum rsc_handling_status { > * @unprepare: unprepare device after stop > * @start: power on the device and boot it > * @stop: power off the device > + * @attach: attach to a device that his already powered up > * @kick: kick a virtqueue (virtqueue id given as a parameter) > * @da_to_va: optional platform hook to perform address translations > * @parse_fw: parse firmware to extract information (e.g. resource table) > @@ -379,6 +380,7 @@ struct rproc_ops { > int (*unprepare)(struct rproc *rproc); > int (*start)(struct rproc *rproc); > int (*stop)(struct rproc *rproc); > + int (*attach)(struct rproc *rproc); > void (*kick)(struct rproc *rproc, int vqid); > void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len); > int (*parse_fw)(struct rproc *rproc, const struct firmware *fw); > -- > 2.20.1 >