From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1441117C for ; Fri, 24 Jan 2025 22:30:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737757847; cv=none; b=FJMwYcStxGVB7l/TnLmWpAjhu4yP85bSjk/olKAcxqxYLsz/W3OOFbyDdCEk+UrsXyqR8e/wSS5F2qtITwO9H9keua9g7VdmIjeXW53HCNUG5KDQuQAU11hViCpVwHbNCSrWqRX1x78KLiYt/IUOME3BZ42qvwjLmCBJdpTsQ68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737757847; c=relaxed/simple; bh=FgB4LXpxo6geqsVUx2MuopKecF2NdlgS186UjbPa+r8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FlYHQRA1DNfsxs0i1B3+ifuxfJ45nXYeZf7Jl3SdVS8D6kOxjwlnRltaaGZE9gKs7K7WbNKEETOWFTCXJ/1pxjHF/JnBgWNCdkf25eIQDw6Mq5fiC7HD/qdWFy3MM+19IqNiw+ASCo3tmyMwtw9WrUQ+hQ3m1zz6Be0hkxEavHE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eztnz89x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eztnz89x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 632A4C4CED2; Fri, 24 Jan 2025 22:30:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737757846; bh=FgB4LXpxo6geqsVUx2MuopKecF2NdlgS186UjbPa+r8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eztnz89xMtKSacfX/dv7YPIkQVuORAibDekeNZl6OhA8yZXPAEEJwwjCN3E4D7uxs eb7abgbKCnfhWrfemwHBNPEwUP6FReJ0O292DFJSneXlFex+xTar55/cnkMrn/h3il o0JY/k7E+z7QCMncJIiGq0vuZlAev6GfA1NAb1LC5ETmiqG9Mh+Zexx2UpMUZG5yb2 Hc/Kyi0YygXyR0pTAieteajWiD16rVXz+hDr+cmA6iLtN9b3OJX3ySJuNqK7AnqHJL ewniUkmhEMTnfJYtcTKXi88AxGx/ICiU2GFvgdx+91HqahS5lCHGjJXoYwvluH9vDh 8gkC0mF49JKuQ== Date: Fri, 24 Jan 2025 16:30:45 -0600 From: Rob Herring To: Viresh Kumar Cc: Sudeep Holla , Vincent Guittot , Alex =?iso-8859-1?Q?Benn=E9e?= , Bill Mills , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] firmware: arm_ffa: Setup of_node for ffa devices Message-ID: <20250124223045.GA2512712-robh@kernel.org> References: <0e863a4baea59865aff0d1b5657f548bc0aa8d2a.1737441631.git.viresh.kumar@linaro.org> <20250121100946.ouzeuh5fopkgmf55@vireshk-i7> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250121100946.ouzeuh5fopkgmf55@vireshk-i7> On Tue, Jan 21, 2025 at 03:39:46PM +0530, Viresh Kumar wrote: > On 21-01-25, 09:59, Sudeep Holla wrote: > > On Tue, Jan 21, 2025 at 12:26:39PM +0530, Viresh Kumar wrote: > > > Match and bind the of_node for the FFA device. > > > > I am bit confused and need more details than the above line 😄, because > > > > 1. We don't have any binding for FF-A and compatible "arm,ffa" is not yet > > defined > > Realized now that you weren't cc'd on 1/3. Bounced it to your email id > now. > > > 2. Even if we have binding, we will not have vm_id and UUID which are > > discoverable from the firmware > > Hmm.. > > > 3. DT maintainers rejected the bindings when it was initially proposed > > as it is discoverable. If we need it for a valid reason, we need more > > info, this patch doesn't provide full picture to change their stance. For background, go read this thread[1]. :) > We are working on FFA based Virtio bus/devices. The > dma_alloc_coherent() helpers for the virtqueue (and other DMA-ble > memory helpers) end up calling the dma-core for the parent device, > which is FFA device in our case. > > We want to avoid separate mapping for each buffer sent by the guest > and keep a reserved mem (via DT) for the specific FFA device. With > that, the memory can be mapped at once at the host (shared over FFA) > and all the following DMA allocations can happen from that > memory-region. Well, that's a better explanation than the patches have as they just appear to ignore all the history here. But I still don't really understand. I know next to 0 about FF-A. Sounds like OS specific problems to me though. Rob [1] https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhlifi@arm.com/#r