Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp348292rwe; Wed, 31 Aug 2022 04:03:57 -0700 (PDT) X-Google-Smtp-Source: AA6agR7ydxbrHjsg95yxKkByUJbie09xIUTayHJcSDhv/xfbcorvl7LHMscprAuSRbrmM/y7DPox X-Received: by 2002:a17:907:3e07:b0:741:81ba:13f1 with SMTP id hp7-20020a1709073e0700b0074181ba13f1mr10458297ejc.226.1661943837032; Wed, 31 Aug 2022 04:03:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661943837; cv=none; d=google.com; s=arc-20160816; b=rOmhXfs4Gvc+7RJ9nvt6GTZc4vBjTgvN72d+N0w64O3ClDdCqRcipoAjpqbdTRRWip qHL9JYyKEuwuXiJjLbmdF2gJAWr7IINvHfbWXqYgXE2iwFBVawhBpsjZ/mCwcUKSSnIK d0C5UPIvC/0Jx4EQ+mtT9h7fgMxONYDbGQjQqF86mJjVU194u/uTgsATxHQEXmHkApYF rKGEKiZRcrzRNppUfASJ9hhsMHJh3pAgPSMR//GUoMzYFI6HLMSBWnmDmbndZmSWgaId muUsk2uP+nhStrQGoC9nf10TPY5Z0IlgKq4MIpqRM9WCphae27qnT1QiswL68Il54Mxn iHZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=w7LRoVcd9BLwWbUBCGZiiEDMoNflqnBENh2m6L91/iw=; b=OmGIYscAinD3PaoEELkAC0ixWG7CCeBk0FdZmaaLtCDjE/WDn9j+bw5AloJfa+aI5l 9hCsfhyTpzPz48peI/oLzlRbW8vFEk1+nunBssLH58SPDSE0bPmgTy7scaKqWX6g+b0W RcPeLch9YXnySuNgbcuqM0AM5KElpw6rFoaWLOSBwABxAESkWOfpR+zP+NmwEVBHRh8u f9nNeaLgzGm1zwwUWaZccu9a4Z+yIxgQdnoGGmCxWHhP5K6koYRkkUT0MXR8M1G91xhW DwULaskfvzoMBcYbzr3imQaTjAjqoQLzY1T7b0Psn4PlveiUYKqaILqNAZ9reKiigxM+ UrLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dVGV7u7T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc20-20020a1709078a1400b0072a72bb6f80si11253797ejc.744.2022.08.31.04.03.30; Wed, 31 Aug 2022 04:03:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dVGV7u7T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229786AbiHaKqZ (ORCPT + 99 others); Wed, 31 Aug 2022 06:46:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229607AbiHaKqY (ORCPT ); Wed, 31 Aug 2022 06:46:24 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA1F0C7F84 for ; Wed, 31 Aug 2022 03:46:22 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id z29so10779807lfb.13 for ; Wed, 31 Aug 2022 03:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=w7LRoVcd9BLwWbUBCGZiiEDMoNflqnBENh2m6L91/iw=; b=dVGV7u7T5VilLehTAFMbXWUy00y2JBJH0myB0WeUV66VShZMq4LTXsQAilglVayiRQ 7/WrsaGsovbhL+Yus5kvm4JuMhmlf4pN6WV7VyJtGZw/rUrQN+TyTvdMVoZ+NOsNBX5g tRzreOGLBWrPTPI8+YcbMNFx1IlqP7kfT2fzExSWoRdg/0Z1N8T1zutf6Vk5ETkmQdqP Y9Mg+DmQG/vmntyH5DC68torDWKHUhomGmT/iEEnNjBzzdfk5iK7Y16rOHD11WJThML5 cmdsmronTZ2m6ncHin+xgy1PGD/Ey0HmkKHu7wTorjJm4madmVwaUPa7QIk5EHnx9Afv HrvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=w7LRoVcd9BLwWbUBCGZiiEDMoNflqnBENh2m6L91/iw=; b=nYh/RncEkub6o+g+jxPVS63h4pt3zijzr4ZCsQLT2mRBSettayRpiVVyJ7hZ23YD5A 8hlxiMAww5XCL2QaPKtx6I9jdeyaJI1DryQxN2ApK8++oMJqm+g3fp/QAkCbIqFa9Qf6 By6STJcpVNbGAcoC+gFakexXRSqVlvSZjSK8XQQpjqef4g3PTXXGGij07BWG37JrtSvr NzRrD4PoZdJNLtSbcyh7eNJcS7DviY5l8uRlaXemmpI8Mp/Vm59ehNPaO8DYXFyNRFR9 27T4rMvPD31x4qGpXudRgXycu6p8hEN9TAmJLbMqI/g0xlK8Egn3Fx4enmgGHpzCtXtm x5pA== X-Gm-Message-State: ACgBeo3HdWM5qTBcveRwaGcGFdRvrPXfasqJXXzzEt7/vR6lzZc6L02h tFVvcbMnSUP82tS58ykN4zwoCxNeMFL33enXAiNGzg== X-Received: by 2002:ac2:4901:0:b0:494:88dc:7efc with SMTP id n1-20020ac24901000000b0049488dc7efcmr986101lfi.408.1661942780284; Wed, 31 Aug 2022 03:46:20 -0700 (PDT) MIME-Version: 1.0 References: <20220830100700.344594-1-sudeep.holla@arm.com> <20220830100700.344594-7-sudeep.holla@arm.com> In-Reply-To: <20220830100700.344594-7-sudeep.holla@arm.com> From: Sumit Garg Date: Wed, 31 Aug 2022 16:16:09 +0530 Message-ID: Subject: Re: [PATCH 6/9] firmware: arm_ffa: Make memory apis ffa_device independent To: Sudeep Holla Cc: linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org, Marc Bonnici , Valentin Laurent , Lukas Hanel , Coboy Chen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sudeep, On Tue, 30 Aug 2022 at 15:39, Sudeep Holla wrote: > > There is a requirement to make memory APIs independent of the ffa_device. > One of the use-case is to have a common memory driver that manages the > memory for all the ffa_devices. That commom memory driver won't be a s/commom/common/ > ffa_driver or won't have any ffa_device associated with it. So having > these memory APIs accessible without a ffa_device is needed and should > be possible as most of these are handled by the partition manager(SPM > or hypervisor). > > Drop the ffa_device argument to the memory APIs and make them ffa_device > independent. > > Signed-off-by: Sudeep Holla > --- > drivers/firmware/arm_ffa/driver.c | 6 ++---- > drivers/tee/optee/ffa_abi.c | 2 +- > include/linux/arm_ffa.h | 6 ++---- > 3 files changed, 5 insertions(+), 9 deletions(-) > > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c > index 5f02b670e964..5c8484b05c50 100644 > --- a/drivers/firmware/arm_ffa/driver.c > +++ b/drivers/firmware/arm_ffa/driver.c > @@ -640,8 +640,7 @@ static int ffa_sync_send_receive(struct ffa_device *dev, > dev->mode_32bit, data); > } > > -static int > -ffa_memory_share(struct ffa_device *dev, struct ffa_mem_ops_args *args) > +static int ffa_memory_share(struct ffa_mem_ops_args *args) > { > if (drv_info->mem_ops_native) > return ffa_memory_ops(FFA_FN_NATIVE(MEM_SHARE), args); > @@ -649,8 +648,7 @@ ffa_memory_share(struct ffa_device *dev, struct ffa_mem_ops_args *args) > return ffa_memory_ops(FFA_MEM_SHARE, args); > } > > -static int > -ffa_memory_lend(struct ffa_device *dev, struct ffa_mem_ops_args *args) > +static int ffa_memory_lend(struct ffa_mem_ops_args *args) > { > /* Note that upon a successful MEM_LEND request the caller > * must ensure that the memory region specified is not accessed > diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c > index 4c3b5d0008dd..7ec0a2f9a63b 100644 > --- a/drivers/tee/optee/ffa_abi.c > +++ b/drivers/tee/optee/ffa_abi.c > @@ -294,7 +294,7 @@ static int optee_ffa_shm_register(struct tee_context *ctx, struct tee_shm *shm, > if (rc) > return rc; > args.sg = sgt.sgl; > - rc = ffa_ops->memory_share(ffa_dev, &args); > + rc = ffa_ops->memory_share(&args); > sg_free_table(&sgt); > if (rc) > return rc; > diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h > index 556f50f27fb1..eafab07c9f58 100644 > --- a/include/linux/arm_ffa.h > +++ b/include/linux/arm_ffa.h > @@ -262,10 +262,8 @@ struct ffa_dev_ops { > int (*sync_send_receive)(struct ffa_device *dev, > struct ffa_send_direct_data *data); > int (*memory_reclaim)(u64 g_handle, u32 flags); > - int (*memory_share)(struct ffa_device *dev, > - struct ffa_mem_ops_args *args); > - int (*memory_lend)(struct ffa_device *dev, > - struct ffa_mem_ops_args *args); > + int (*memory_share)(struct ffa_mem_ops_args *args); > + int (*memory_lend)(struct ffa_mem_ops_args *args); > }; > Since these are included under "struct ffa_dev_ops", wouldn't it be better to rename the struct (ffa_ops?) as well? -Sumit > #endif /* _LINUX_ARM_FFA_H */ > -- > 2.37.2 >