From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E7A9F3451A7; Tue, 26 May 2026 08:28:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779784095; cv=none; b=Bq/9tCfetgubNFXu+DAtK8ENSzHLfAqv+fyDNSspLCwOQSml8bX7VBIROU8AOG2nlCirq8x2g+gqpCrzv47/3GS1Hvf3uv7s55YKuwV3/tvDvvQzQdUBAZzxyEhLqty1/APJF9svoSoka7oIOJ1CuoNt10Qd6NJiAvVjFOJWA7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779784095; c=relaxed/simple; bh=789CkO4abUnWovDkP2BY7XJfp5tN4S/x1EX3kh83RhQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HBt+ZpkQY7JLR/rS+HRGQspnKEuvPwrxHzjDxj2OKhkfbybvWy+/cJYQWN+d7YdfkB4Dt+y1ceETgXbzv19+g70Cf8dNb7aM+N7fgmGcCI2WiHMxVA02adfABDVj5eogIkY3dYazxMWB8H9CKuDpOIQ/jF8s73jvnmYNiNsj8NM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GKuEXGos; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GKuEXGos" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5B851F000E9; Tue, 26 May 2026 08:28:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779784093; bh=LT5Q0GcrI3IDVOP/iwdLProaGoCzh8gCBMqgxT/KQJs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GKuEXGosoZPcQB0Bio3ESczf16muO3sgtFDuLtbJBRGqyHFxNeC3YCvjmZ58Xdhag CXP+CGVVhETUa3XmaLRR+YYtuMnuA/UMipJh99IR5EIOuwKkjkpMv/jdogKqS5Z7Uu ArqnhxusbbJQmEm7gB5vj62fI96Lz4gx2zNKCELyfD/W8NJgU2eEe6/gHZEM/m/SZ0 TTUdPt2UqQc5mmviJImcT9ga35q0J9BLn1WUrnsvjcws5Zr/ONlSAZY9luPaJXDM1f G4Fi+F1N7QjFSZKysllhI+hCQjx6N7tc2/UuUZPWEnka4CPkw5eTjFm7DDFr5fPJCG JRCVwGTug8BqQ== Date: Tue, 26 May 2026 10:28:07 +0200 From: Niklas Cassel To: Koichiro Den , Shawn Lin Cc: Manivannan Sadhasivam , Frank Li , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Kishon Vijay Abraham I , Bjorn Helgaas , Jonathan Corbet , Shuah Khan , Vinod Koul , Arnd Bergmann , Damien Le Moal , Marek Vasut , Yoshihiro Shimoda , linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org Subject: Re: [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3) Message-ID: References: <20260525063456.3317509-1-den@valinux.co.jp> <3dkicfydmrlm2i6ks34kwjdmlvb22ryftkfw2yj62o4rtj5xvl@f4gby5vlwtdf> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 26, 2026 at 03:23:57PM +0900, Koichiro Den wrote: > On Tue, May 26, 2026 at 07:35:06AM +0200, Niklas Cassel wrote: > > Yes, I also think the architecture of this series is much cleaner. The option 2 > series may look like it overloads and complicates vNTB a bit too much, and the > auxiliary device created from ntb_hw_epf only for the channel delegation purpose > may look awkward to some. > > The coverage concern is a real downside of this direction though. This is a > trade-off between a cleaner PCI/DMA model and broader EPC coverage. On my side, > R-Car Gen4+ is the main target, so the multi-function requirement is acceptable. > In that sense, I am also curious whether future DWC-based SoCs will typically > support more than one function or not. It seems that the number of supported physical functions is controlled by the configurable PCIe IP-core synthesize parameter CX_NFUNC. Looking at the code, if the device tree property 'max-functions' is missing, it will set epc->max_functions to 1: $ git show f8aed6ec624f It has been like this since the initial EP support in the DWC driver, added in 2017. However, a missing 'max-functions' device tree property does not necessarily mean that the IP-core was configured with CX_NFUNC == 1. Right now, I don't see any register to get CX_NFUNC. Perhaps it is possible to write some code that figures out CX_NFUNC, by writing different values to the iATU registers, somewhat similar to how we detect the number of inbound and outbound iATUs: https://github.com/torvalds/linux/blob/v7.1-rc5/drivers/pci/controller/dwc/pcie-designware.c#L998-L1001 I added EP mode support for the pcie-dw-rockchip driver, but I don't know the CX_NFUNC parameter value, so I could not add a 'max-functions' property. While it is possible that some DWC-based PCIe endpoint controllers are configured with CX_NFUNC == 1, it is also possible that some people simply did now add a 'max-functions' property, because they did not know the CX_NFUNC value, just like me. Shawn Lin, do you perhaps know the CX_NFUNC value for rk3588 and rk3568 ? Kind regards, Niklas