From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 785B92C08DA for ; Tue, 24 Jun 2025 13:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772373; cv=none; b=sOSJDg7j/fUmOvTKKntp0Px+AuNgG2WdgMH6gMng89Nwq2Z3Qf0Suo4+VrTLm6K5H9HjDlAVB/HupCezasjhXVz4y9E5G9T9qi11jLHlJbs7QFA7WeqXNOnmncReD/ztOAZCXL09aTTTVUbq6kFI4hNmQyGhDrKA5zFfJx3pqOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772373; c=relaxed/simple; bh=A6LKHXBUG4iUTzGnKK5661G16ikKPC/56/HUtV07NJs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g7YVzcTxvPyoMc5gPh8ijX1S3NL/H6JiX7s6bMeXKmlLSwzEF/lcw61L3O3jPUpBPNUzOQ4H+sTK0rtrhs9lo9m7z7q+ChY9F4M2lr4hKPdo6ool+A9X77YGI7SYh7oujKexg3n7bHwK98mIPTnF/lYGi50eslELwnnH5IVjaGw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=FRHzr7Du; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="FRHzr7Du" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-3a528e301b0so283405f8f.1 for ; Tue, 24 Jun 2025 06:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772370; x=1751377170; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=G8OYkNwJziYcgoiRcCAHS+W9j9ESRdVu8lYPwRcMBHY=; b=FRHzr7DuAjoRUeQd9yt5fimv/BBC54RLBV9boEgV+68y7uaZjiiXy2ioPwOmXcHfHu iTX0LzwpY+157yynfG7qTV3rPUup0gXBjNot9+6lc57/tJ02hFZoYDKMst2ByG0pYHrk vB9eUX62ouS1sNms8PJ6S3JMZXq18a+aE7IlJ5HbOeI/rTSTpXVL2Yny9XuEMKyQvXU2 jobFpZcer2CMqemG3eNXseGV8NBgnRaDdzeDx9DW54GXC30kLNb1Z6BfNCgUizFIZB8a +MEHG/D4PUoU4cSzy40/aiz6qDq9RCyVmAOtDVf1GWSKsdFGfTHAJnQ2Cv9+nwiL1taI evDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772370; x=1751377170; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G8OYkNwJziYcgoiRcCAHS+W9j9ESRdVu8lYPwRcMBHY=; b=eQzGGY3qVENyqYkmI1ZxyhLK2Mh0rEnlCUk5LoRfTNFNTIlXCY5Jc4ZQ5A0Nxgy7/a 0h92YcjmqFygHlDwYPy9JtCOHFHcO513g4qbDZz1vp+Q8VWUzctgabOtRb7hker1zWUt +mfbeNMb53cR1CpUWFWOu0gBO1/5PS3BIYlS/dH3swgWOOmvXMtadGMSOUgYelOAfWPy Q15TzcgI5CRptii4+n8I/wA0VFZd+yswDkDSk4gpuwsJluGxKpErJneAFg47Y8ZneQWS cPdxwOAMDQBE4WmBLFK8gafK6bYcXhqh0QoWhxdKGsCgj4sqjNMdHkaLsjwHzpIZDPBk UcLg== X-Forwarded-Encrypted: i=1; AJvYcCX2/8tS5fhv9ooQC1DjrsQKghfRcuttfXfOCxAwaMhdrhxuF3bXIUnqd4rFnxd4aa6tF7PJOotqQcPvTOw=@vger.kernel.org X-Gm-Message-State: AOJu0YzssCwLmmcpNeUGBNLUsiJ0fdJMF96iNzGxisdfVXMJgGqoFwWh w6rz0ZYZ4lnZUHhYQ2+OqeRzKDlDmGJvgQF9dS9cVAS2CO7HOgQRbzeheiZIuXwWnGo= X-Gm-Gg: ASbGncsRBCl/BNcmx8DuOi4MhXQTEDJwGZanITQwOT4T0HE2AJa7U9uJkGM3301I5Tv WBTHZew0pN759y6WaaG90qaNBpmkftLcodKIdC9r//VH4tU/nUNc/8bZNEdbKjD0U+8zptDGemu v6CqvSCHCwMmzeHXE1Jx9Bjm0Ve8yQ70fKHkG3dN4Ud/edBUZFwPezweYevbGSHmgpcOw/suBqZ kzjUK61OSFzM2IITxW8j8v2S0d4iLDuynE3D9dvY0AtX30R9kFvhhKUk5aC6yoBSTOfWw9wrctb OKuCi6U66q/rk31j8KBeTcDspCoNzn5Tz2PWppNUTw5ziqtE7ND7OV0+jtPuv/+woqPTLt0rkUC 2/ellhFvHNNnZUW9ahstf2N2YRpwzNELkjR4XPN2DoepUI8wkQWdO X-Google-Smtp-Source: AGHT+IEIwFSHwaoj31PtLeuWDl43hdEdyv9aVZ6WqShd2YpoPc0pFXp6GwtI5lbLwyI31derXkrYlg== X-Received: by 2002:a5d:5f4b:0:b0:3a4:da29:d13f with SMTP id ffacd0b85a97d-3a6d12e1dc6mr5124726f8f.3.1750772369659; Tue, 24 Jun 2025 06:39:29 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a6e805d5f4sm1928629f8f.27.2025.06.24.06.39.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:29 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 1/8] docs: dma-api: use "DMA API" consistently throughout the document Date: Tue, 24 Jun 2025 15:39:16 +0200 Message-ID: <20250624133923.1140421-2-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Make sure that all occurrences are spelled "DMA API" (all uppercase, no hyphen, no underscore). Signed-off-by: Petr Tesarik Reviewed-by: Randy Dunlap --- Documentation/core-api/dma-api.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index 2ad08517e626..97f42c15f5e4 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -13,10 +13,10 @@ machines. Unless you know that your driver absolutely = has to support non-consistent platforms (this is usually only legacy platforms) you should only use the API described in part I. =20 -Part I - dma_API +Part I - DMA API ---------------- =20 -To get the dma_API, you must #include . This +To get the DMA API, you must #include . This provides dma_addr_t and the interfaces described below. =20 A dma_addr_t can hold any valid DMA address for the platform. It can be @@ -76,7 +76,7 @@ may only be called with IRQs enabled. Part Ib - Using small DMA-coherent buffers ------------------------------------------ =20 -To get this part of the dma_API, you must #include +To get this part of the DMA API, you must #include =20 Many drivers need lots of small DMA-coherent memory regions for DMA descriptors or I/O buffers. Rather than allocating in units of a page @@ -247,7 +247,7 @@ Maps a piece of processor virtual memory so it can be a= ccessed by the device and returns the DMA address of the memory. =20 The direction for both APIs may be converted freely by casting. -However the dma_API uses a strongly typed enumerator for its +However the DMA API uses a strongly typed enumerator for its direction: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -775,19 +775,19 @@ memory or doing partial flushes. of two for easy alignment. =20 =20 -Part III - Debug drivers use of the DMA-API +Part III - Debug drivers use of the DMA API ------------------------------------------- =20 -The DMA-API as described above has some constraints. DMA addresses must be +The DMA API as described above has some constraints. DMA addresses must be released with the corresponding function with the same size for example. W= ith the advent of hardware IOMMUs it becomes more and more important that driv= ers do not violate those constraints. In the worst case such a violation can result in data corruption up to destroyed filesystems. =20 -To debug drivers and find bugs in the usage of the DMA-API checking code c= an +To debug drivers and find bugs in the usage of the DMA API checking code c= an be compiled into the kernel which will tell the developer about those violations. If your architecture supports it you can select the "Enable -debugging of DMA-API usage" option in your kernel configuration. Enabling = this +debugging of DMA API usage" option in your kernel configuration. Enabling = this option has a performance impact. Do not enable it in production kernels. =20 If you boot the resulting kernel will contain code which does some bookkee= ping @@ -826,7 +826,7 @@ example warning message may look like this:: <4>---[ end trace f6435a98e2a38c0e ]--- =20 The driver developer can find the driver and the device including a stackt= race -of the DMA-API call which caused this warning. +of the DMA API call which caused this warning. =20 Per default only the first error will result in a warning message. All oth= er errors will only silently counted. This limitation exist to prevent the co= de @@ -834,7 +834,7 @@ from flooding your kernel log. To support debugging a d= evice driver this can be disabled via debugfs. See the debugfs interface documentation below for details. =20 -The debugfs directory for the DMA-API debugging code is called dma-api/. In +The debugfs directory for the DMA API debugging code is called dma-api/. In this directory the following files can currently be found: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D @@ -882,7 +882,7 @@ dma-api/driver_filter You can write a name of a driver= into this file =20 If you have this code compiled into your kernel it will be enabled by defa= ult. If you want to boot without the bookkeeping anyway you can provide -'dma_debug=3Doff' as a boot parameter. This will disable DMA-API debugging. +'dma_debug=3Doff' as a boot parameter. This will disable DMA API debugging. Notice that you can not enable it again at runtime. You have to reboot to = do so. =20 --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 858FA2C158E for ; Tue, 24 Jun 2025 13:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772374; cv=none; b=P6zO04KhYAxFX2MwvY5r/1XHulyLzSNhRr39THlvFIRNLH87aWE/vEB/5qkNnbvIKc6I5yfHB9CzVOOCDoxt8QjsnP0IdkOqiAw+NJU/BYU6CWGO6c/1FUGusHN0H0qzC8Zj9shDjRaC+bL02yNbgPezomuVdHNHgqv65D45u6M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772374; c=relaxed/simple; bh=g80pHHSVJTrphogPoK2EcViQY6ILssLsaF7KfxzqW6Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FjKXAveyQN9K8gCR5IYBjL6TDtVfgEMFFgEc2KRQhrg+Lb0Pa++862TjfgrrYPRwSA+9KTol4Na42fcvhCoIILgQyZMHVid47IdDexWSDn/0U9FF2byT3PrbRFA01x3tHZ+01CWnw2r42uhWXNAsERvBI0D+CwF34utIx6gWb2E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=UIEjifHr; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="UIEjifHr" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3a4e575db1aso266668f8f.2 for ; Tue, 24 Jun 2025 06:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772371; x=1751377171; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PpIY03qJBh52r3AMjs7uQiwUhbrX9UUcbgb904orePg=; b=UIEjifHrOgepU1yHWlYF3bBvmmoPj96WfYk8rGQdDcTTUyxDgoBHmtP/QUDovvVKJ3 8qc2gIGBlIJaO9ecSgjYz8m7NZA2bMo4Wlpcfnd8YL7zE5FxPAr6VIOtB14qg1y5XMjP yAe0xd1HQmJjR5b/121d3QHqt2CBTgjAaZXS/kGd+9QBCdqM+PKrjZYfquPkVB6oPDp7 OnFQoZF82ZmR2WJ8NzLxun7rV08U6re30WEHzwusq74ADOFyJP/04CcEROv/HSlJ9fqG o8ECCx48m01mbdUgZAnjpWJEK5+F8STdXpSglvf3/q9O2sxc0SS7C3JZTOrG+KaYilnW jYvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772371; x=1751377171; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PpIY03qJBh52r3AMjs7uQiwUhbrX9UUcbgb904orePg=; b=bHNM58FIQrYwdwkhMHbvmSRdVNba2dfdI2emuFmtP2V0lZ1Lxu1CratI93XRRUp/3n xj121zLeXfrrRM+YWIMNTlvWwuVMMtZMm5KqRhfsKjQ0eyR9VZTKuNhXcUQN9tN0f3qT lJwjnECOUdNjABbaghYtlsMNPhuLPOMdBCIy3L5EXXmfWh7TiewxUn+M+/mBUWc26qmv 3J8JfgK3VYShxyAsao7OwdEbRaUmu9ZEUeuNHNGUosBAL96WwKjeULcA2wU6Ba9KRduJ aSAKaxULCu9vleXXoOsn+dwrDJO5a/kZ4D0H3jmeVGwlvEdqofzw44TfoYleCzmO7l99 NG+Q== X-Forwarded-Encrypted: i=1; AJvYcCUsMd3ELJPk1GSQHRZLZZPcz+kTKZuRD8PfdauroHDF+wM6TEJLhqHBqfXwjTKQVNFIUu6Nd9aJAOTvXUo=@vger.kernel.org X-Gm-Message-State: AOJu0YyAK3CgWaUtyi3x7x0fJX0DutwO7Kod53O+7G7pNJef36jf4rDE RbQOOfRXjyHKcY+wGTN722cv+iDXYwMcsN/TaFMdPLmtSf1/nXfCeJr5t8j1bmV7nTk= X-Gm-Gg: ASbGncvdOcoleomgIgpZdyrTHIJELHBI1QP6r/BfyRL8ECOIxV9jtW55iys4qGVVZT6 PuNBd32ns5LYdt/LfPL4mn4EMrCPKMIA6kmYWfVMYsXf2V7n99IMHpRt4hdw5HSFxD2hOcWh/Zm QnXf8v0BoQ5cof5VACoE5hWUMvIM7RzXEmi8y9jH2mw6RVD/utzFwmF/ic91Bfwq5iq/4PYdT+D qgj0WQ5LriPeFAj23UvSEadNlFLm2rdsd+BY7pFR6+0h2g5nTFRpfGn0722AwO738FqQ/mGMFvm 4ftlDJ/0hxu5pxTu2Wtdyf2AJDL+vpYOG9qKApYtbAXXa25xs60mejI6O4BI1lXVGrvN7+O06Te NQ20bNDFRhCWneKcIZtvW5gBAOGZ2iqsR/akZHiYLbWwuMw9fDLFk X-Google-Smtp-Source: AGHT+IG98SXlX8rKY55D5CjUPBbSPU4w+ruylNw7sqxOxZSzqk2mxBWEoEspfGDhb4FlcYBZi1AECw== X-Received: by 2002:a05:6000:2013:b0:3a3:6a3f:bc61 with SMTP id ffacd0b85a97d-3a6d12f9a28mr5299210f8f.7.1750772370725; Tue, 24 Jun 2025 06:39:30 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-4535eac8e19sm175939225e9.21.2025.06.24.06.39.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:30 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 2/8] docs: dma-api: replace consistent with coherent Date: Tue, 24 Jun 2025 15:39:17 +0200 Message-ID: <20250624133923.1140421-3-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For consistency, always use the term "coherent" when talking about memory that is not subject to CPU caching effects. The term "consistent" is a relic of a long-removed pci_alloc_consistent() function. Signed-off-by: Petr Tesarik --- Documentation/core-api/dma-api-howto.rst | 36 ++++++++++++------------ Documentation/core-api/dma-api.rst | 14 ++++----- mm/dmapool.c | 6 ++-- 3 files changed, 28 insertions(+), 28 deletions(-) diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-= api/dma-api-howto.rst index 0bf31b6c4383..96fce2a9aa90 100644 --- a/Documentation/core-api/dma-api-howto.rst +++ b/Documentation/core-api/dma-api-howto.rst @@ -155,7 +155,7 @@ a device with limitations, it needs to be decreased. =20 Special note about PCI: PCI-X specification requires PCI-X devices to supp= ort 64-bit addressing (DAC) for all transactions. And at least one platform (= SGI -SN2) requires 64-bit consistent allocations to operate correctly when the = IO +SN2) requires 64-bit coherent allocations to operate correctly when the IO bus is in PCI-X mode. =20 For correct operation, you must set the DMA mask to inform the kernel about @@ -174,7 +174,7 @@ used instead: =20 int dma_set_mask(struct device *dev, u64 mask); =20 - The setup for consistent allocations is performed via a call + The setup for coherent allocations is performed via a call to dma_set_coherent_mask():: =20 int dma_set_coherent_mask(struct device *dev, u64 mask); @@ -241,7 +241,7 @@ it would look like this:: =20 The coherent mask will always be able to set the same or a smaller mask as the streaming mask. However for the rare case that a device driver only -uses consistent allocations, one would have to check the return value from +uses coherent allocations, one would have to check the return value from dma_set_coherent_mask(). =20 Finally, if your device can only drive the low 24-bits of @@ -298,20 +298,20 @@ Types of DMA mappings =20 There are two types of DMA mappings: =20 -- Consistent DMA mappings which are usually mapped at driver +- Coherent DMA mappings which are usually mapped at driver initialization, unmapped at the end and for which the hardware should guarantee that the device and the CPU can access the data in parallel and will see updates made by each other without any explicit software flushing. =20 - Think of "consistent" as "synchronous" or "coherent". + Think of "coherent" as "synchronous". =20 - The current default is to return consistent memory in the low 32 + The current default is to return coherent memory in the low 32 bits of the DMA space. However, for future compatibility you should - set the consistent mask even if this default is fine for your + set the coherent mask even if this default is fine for your driver. =20 - Good examples of what to use consistent mappings for are: + Good examples of what to use coherent mappings for are: =20 - Network card DMA ring descriptors. - SCSI adapter mailbox command data structures. @@ -320,13 +320,13 @@ There are two types of DMA mappings: =20 The invariant these examples all require is that any CPU store to memory is immediately visible to the device, and vice - versa. Consistent mappings guarantee this. + versa. Coherent mappings guarantee this. =20 .. important:: =20 - Consistent DMA memory does not preclude the usage of + Coherent DMA memory does not preclude the usage of proper memory barriers. The CPU may reorder stores to - consistent memory just as it may normal memory. Example: + coherent memory just as it may normal memory. Example: if it is important for the device to see the first word of a descriptor updated before the second, you must do something like:: @@ -365,10 +365,10 @@ Also, systems with caches that aren't DMA-coherent wi= ll work better when the underlying buffers don't share cache lines with other data. =20 =20 -Using Consistent DMA mappings -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D +Using Coherent DMA mappings +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 -To allocate and map large (PAGE_SIZE or so) consistent DMA regions, +To allocate and map large (PAGE_SIZE or so) coherent DMA regions, you should do:: =20 dma_addr_t dma_handle; @@ -385,10 +385,10 @@ __get_free_pages() (but takes size instead of a page = order). If your driver needs regions sized smaller than a page, you may prefer using the dma_pool interface, described below. =20 -The consistent DMA mapping interfaces, will by default return a DMA address +The coherent DMA mapping interfaces, will by default return a DMA address which is 32-bit addressable. Even if the device indicates (via the DMA ma= sk) -that it may address the upper 32-bits, consistent allocation will only -return > 32-bit addresses for DMA if the consistent DMA mask has been +that it may address the upper 32-bits, coherent allocation will only +return > 32-bit addresses for DMA if the coherent DMA mask has been explicitly changed via dma_set_coherent_mask(). This is true of the dma_pool interface as well. =20 @@ -497,7 +497,7 @@ program address space. Such platforms can and do repor= t errors in the kernel logs when the DMA controller hardware detects violation of the permission setting. =20 -Only streaming mappings specify a direction, consistent mappings +Only streaming mappings specify a direction, coherent mappings implicitly have a direction attribute setting of DMA_BIDIRECTIONAL. =20 diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index 97f42c15f5e4..c0a2cc7d0b95 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -8,9 +8,9 @@ This document describes the DMA API. For a more gentle int= roduction of the API (and actual examples), see Documentation/core-api/dma-api-howto= .rst. =20 This API is split into two pieces. Part I describes the basic API. -Part II describes extensions for supporting non-consistent memory +Part II describes extensions for supporting non-coherent memory machines. Unless you know that your driver absolutely has to support -non-consistent platforms (this is usually only legacy platforms) you +non-coherent platforms (this is usually only legacy platforms) you should only use the API described in part I. =20 Part I - DMA API @@ -33,13 +33,13 @@ Part Ia - Using large DMA-coherent buffers dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flag) =20 -Consistent memory is memory for which a write by either the device or +Coherent memory is memory for which a write by either the device or the processor can immediately be read by the processor or device without having to worry about caching effects. (You may however need to make sure to flush the processor's write buffers before telling devices to read that memory.) =20 -This routine allocates a region of bytes of consistent memory. +This routine allocates a region of bytes of coherent memory. =20 It returns a pointer to the allocated region (in the processor's virtual address space) or NULL if the allocation failed. @@ -48,9 +48,9 @@ It also returns a which may be cast to an un= signed integer the same width as the bus and given to the device as the DMA address base of the region. =20 -Note: consistent memory can be expensive on some platforms, and the +Note: coherent memory can be expensive on some platforms, and the minimum allocation length may be as big as a page, so you should -consolidate your requests for consistent memory as much as possible. +consolidate your requests for coherent memory as much as possible. The simplest way to do that is to use the dma_pool calls (see below). =20 The flag parameter (dma_alloc_coherent() only) allows the caller to @@ -64,7 +64,7 @@ the returned memory, like GFP_DMA). dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) =20 -Free a region of consistent memory you previously allocated. dev, +Free a region of coherent memory you previously allocated. dev, size and dma_handle must all be the same as those passed into dma_alloc_coherent(). cpu_addr must be the virtual address returned by the dma_alloc_coherent(). diff --git a/mm/dmapool.c b/mm/dmapool.c index 5be8cc1c6529..5d8af6e29127 100644 --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -200,7 +200,7 @@ static void pool_block_push(struct dma_pool *pool, stru= ct dma_block *block, =20 =20 /** - * dma_pool_create_node - Creates a pool of consistent memory blocks, for = dma. + * dma_pool_create_node - Creates a pool of coherent DMA memory blocks. * @name: name of pool, for diagnostics * @dev: device that will be doing the DMA * @size: size of the blocks in this pool. @@ -210,7 +210,7 @@ static void pool_block_push(struct dma_pool *pool, stru= ct dma_block *block, * Context: not in_interrupt() * * Given one of these pools, dma_pool_alloc() - * may be used to allocate memory. Such memory will all have "consistent" + * may be used to allocate memory. Such memory will all have coherent * DMA mappings, accessible by the device and its driver without using * cache flushing primitives. The actual size of blocks allocated may be * larger than requested because of alignment. @@ -395,7 +395,7 @@ void dma_pool_destroy(struct dma_pool *pool) EXPORT_SYMBOL(dma_pool_destroy); =20 /** - * dma_pool_alloc - get a block of consistent memory + * dma_pool_alloc - get a block of coherent memory * @pool: dma pool that will produce the block * @mem_flags: GFP_* bitmask * @handle: pointer to dma address of block --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F7902C15A4 for ; Tue, 24 Jun 2025 13:39:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772375; cv=none; b=S1SwPLABSR0Ws7rSxNcIrMmz8Y7UeyCcp0WOT5ZAVWhF5Ca1ersJnsQuQ5m5V70noD/VRS0kU7INWpxOVTysBXdKToFD24rJMwmw6UpNF60DCWCpJlqrA8z7fqsb66qZ/X0qy3shK7sMziKeZY5ioSw5qnpioD1Zl9UgYHCU7K0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772375; c=relaxed/simple; bh=upmwj8n4ZMOQPPUNURbAWXmJiyyO05PQ3fhNj+QN7p0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OLl23sAxLS7ejX588ZBnTd+fxHmfbBAUIe3623oEBjjTNe3h9Yz/JYqWcwn8JYCanfFqE3i7a8XY4hMYGkduTyjeKzTS+25esx3OcCopZotkO2VFDX8q6wByWutek3z/M3RShsViafW8f7jeToYFyk2NjmzJ+IQVfnK26AqyW3g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=XVg8v/Ik; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="XVg8v/Ik" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3a4e749d7b2so946205f8f.0 for ; Tue, 24 Jun 2025 06:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772372; x=1751377172; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IHvhAvi5eCUp/ybstJnQHmjXO3pY/1hXWEhrYPlflFU=; b=XVg8v/IkHwyE4YqRc85n4dFwyp9awxf/ILl7OOSpKGG8RF37+v20NTNpCLmuJprIeI rAQMU7hues0eTcD3v/mwnSTBM9adKnF2dwqdQVk9Qoxfj+GiiGNugfSRLXYM6wlrWc8I ZFOcetHgqV85ZWYprfJWmOXk/3owTIzCHRMpCQQOh31xEeY/1F1XdYcyRS0gsrGopXVX JLl/hXzfKQ6gqe4xrijvxcASLPkP/Dwrz2H5I0gfeKHgtHo5gH1FBtOaRkT0lJ4f3ko7 rCYR/SyZXZCnBjhz6ppXC/4gPOhgr/yF00pKzO67jG35a+8vYBqPpfoWiwvHvfqNym6U LNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772372; x=1751377172; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IHvhAvi5eCUp/ybstJnQHmjXO3pY/1hXWEhrYPlflFU=; b=g1g6Fq8bJFOfAOIhFmFu0f4gv4KWqtyNOAn98VjDKZqPopqafOpIG4uBBSqxJ/r8eO rZhLxG6K4Gjy1XnIjJ8sPBJnDKz/VM2QhA5oYBqFAYgzH/MFCBr1shYAMOCM90PVqHEd /6E3d7FbnGD7C1jSvxkt/2D86Z714sBQiAxDeJBMcKrFyNZiOvMxN96LQ835YjvdPydZ 9fHoaioj1wRlGiY0vGYA1AJ/FbZ423UYeVMkruDb9X2jMpY6TqzZAEn1FjnUlCGHTDbP H52TOKKcHr5glAOZIqXhI02AW70DaBd3E6xVmB1rzr6A0IJYmln3wL4BAfvsTTQ56DgK 1vmQ== X-Forwarded-Encrypted: i=1; AJvYcCWy4kz1a6UVoOMVDgroOgMs28A17b7+WSLKYKBMsxb2Yys3IpHdwqlqBY2xw3OSo/O9VN+f40Inx4HWNBo=@vger.kernel.org X-Gm-Message-State: AOJu0YyQWN5ey3tFutJMVUAI8ftOEqZNrzHcLc+mHSlDVWSOVXY6WmrM t8sHNaYUukIGZLMLyRqN1SZZ160Uo4gUfDSHfZqh2N4xeeOpU91ZwCiw5ZKlOb1tc50= X-Gm-Gg: ASbGnct6bW0QEF2rSvo9y02kQmi7qwRUOMZzNvFaqbhZE58oDAw9MLiIlrBoPntNc3T bPL1jZ0zxsA//4V+2rZXHP1U7/tnqGWDEB1223jsEtD8rNcDhV6ntC16oZ4uzA+I0rX1FiZG7bi 91AT/iIqDWiwzDbvMjitGJYAWAQF4nJ6SBhHLTuV/HgC3EylDUZedeiyss7t8PspJ5uF86152Hc fYueklD1iYk06A0cw62YthGlqooW+TnSHjw6m0WpHmZcSyr0/24dng0IyAic4mrTwWeLtFK/7Pq /cHUY5RAyBdS12GqRUJzV37SZPO1CGgGTrTji5lkK9FCAFImMDBb8yuPju7zAkphGzhBUi5lfFB MIm2ZAUobqecVQjZXtD0gooPXU7f3pfptv3XdNTfE0+NdXv6N9wz8 X-Google-Smtp-Source: AGHT+IHg37TDJn0ybirhMSzgiCvKi7BYNHT5VAEQ6KF0RJ85EgIsRWvQC3Z7Ra12tDoOlf0Dg9NQPA== X-Received: by 2002:a05:6000:2f83:b0:3a4:f7ea:a638 with SMTP id ffacd0b85a97d-3a6d128bc58mr4861104f8f.3.1750772371648; Tue, 24 Jun 2025 06:39:31 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-4536fefd2b4sm84782955e9.36.2025.06.24.06.39.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:31 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 3/8] docs: dma-api: remove remnants of PCI DMA API Date: Tue, 24 Jun 2025 15:39:18 +0200 Message-ID: <20250624133923.1140421-4-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The wording sometimes suggests there are multiple functions for an operation. This was in fact the case before PCI DMA API was removed, but since there is only one API now, the documentation has become confusing. To improve readability: * Remove implicit references to the PCI DMA API (plurals, use of "both", etc.) * Where possible, refer to an actual function rather than a more generic description of the operation. Signed-off-by: Petr Tesarik Reviewed-by: Bagas Sanjaya --- Documentation/core-api/dma-api.rst | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index c0a2cc7d0b95..3e89e3b0ecfd 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -53,10 +53,9 @@ minimum allocation length may be as big as a page, so yo= u should consolidate your requests for coherent memory as much as possible. The simplest way to do that is to use the dma_pool calls (see below). =20 -The flag parameter (dma_alloc_coherent() only) allows the caller to -specify the ``GFP_`` flags (see kmalloc()) for the allocation (the -implementation may choose to ignore flags that affect the location of -the returned memory, like GFP_DMA). +The flag parameter allows the caller to specify the ``GFP_`` flags (see +kmalloc()) for the allocation (the implementation may ignore flags that af= fect +the location of the returned memory, like GFP_DMA). =20 :: =20 @@ -64,13 +63,12 @@ the returned memory, like GFP_DMA). dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) =20 -Free a region of coherent memory you previously allocated. dev, -size and dma_handle must all be the same as those passed into -dma_alloc_coherent(). cpu_addr must be the virtual address returned by -the dma_alloc_coherent(). +Free a previously allocated region of coherent memory. dev, size and dma_= handle +must all be the same as those passed into dma_alloc_coherent(). cpu_addr = must +be the virtual address returned by dma_alloc_coherent(). =20 -Note that unlike their sibling allocation calls, these routines -may only be called with IRQs enabled. +Note that unlike the sibling allocation call, this routine may only be cal= led +with IRQs enabled. =20 =20 Part Ib - Using small DMA-coherent buffers @@ -246,9 +244,7 @@ Part Id - Streaming DMA mappings Maps a piece of processor virtual memory so it can be accessed by the device and returns the DMA address of the memory. =20 -The direction for both APIs may be converted freely by casting. -However the DMA API uses a strongly typed enumerator for its -direction: +The DMA API uses a strongly typed enumerator for its direction: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DMA_NONE no direction (used for debugging) @@ -325,8 +321,7 @@ DMA_BIDIRECTIONAL direction isn't known enum dma_data_direction direction) =20 Unmaps the region previously mapped. All the parameters passed in -must be identical to those passed in (and returned) by the mapping -API. +must be identical to those passed to (and returned by) dma_map_single(). =20 :: =20 --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 316462C374E for ; Tue, 24 Jun 2025 13:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772377; cv=none; b=UDauTECByhISqZXeHoKbgR342xsN+I5lSX93zdHFK8uzhlTvjgmRGGhslv3yiipEQfWSxO4dRwuDdgYq9Pc2fV9aBDYjIoS+aMpoOToUdO9Uzx8KGBdyHp8I0Jvq/JOOSpDX2TjtCfnw6xXgpQDFxpAERQ7gjxHKFNs3kHLyaM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772377; c=relaxed/simple; bh=VXYHGpM05rGE//h/apw7eqoewOcMeRXmxyRdC/GTHL0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jxrk4+vl1OQiN18vuKB4NGMH9f3hdMmJHRHIB24UehGZ+fkd4w9GEghYgmK4czezvabjhL41oEgZInXW6CkY/079/ooUcQgosSJXzah6IMkYX+uQZKO06OAvRCS5ZXVCrjjs4eukjsQIeGigZUs2PaBxGgRo2aQBuYYDzQRhiiM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=XS8120qE; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="XS8120qE" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4535fc0485dso6948075e9.0 for ; Tue, 24 Jun 2025 06:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772373; x=1751377173; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oeJkbEKgM0HHbkRMH9B3w8A15xaUkHynZ4iVjI/7IZk=; b=XS8120qE/rfT4p73GPsmp98ILIOvAvl7fs27jSl/BWMt+3E/RflmdI/eP2+TihBq+e GGPnwTZmlpYs3HQsXp0UkXLzCQpg/kx0p7U0HUaMhyUly8xDTXiVgBTl/HFey1Up5QCD eTpx71aBFZP44DeZC+WiQAnvbtbNyczm1uvZfn/wbFkJlNhrpnS+RXxvtuZddohCum6g UdyukphSlzCH4IOUxk4/SN+Hs7bUV5+AsTt9o+7i/mU+AtHjEjBktZkP6E437hUUP6yy SpiCLdCVnKZnfMn8M/T0Kt9XYwZtUdoQTfZQ5F7OvC6ZWwqYX+wDOahw+bd7+vcSRPpC Hkuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772373; x=1751377173; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oeJkbEKgM0HHbkRMH9B3w8A15xaUkHynZ4iVjI/7IZk=; b=sx+862FCJFXy+TuRgWaIc+jiJCgocR/ECKEyQ3QnbyfMs3RzCOUVYDRFvUIj9cRi7g DiesrnUTH0f+YA5KWnWaCSlQlL70k7k3KkgDOduEdf0jDHOzS6ag9/tJx4rVrku2xxhg SA5eq8Y6GxESbc7aTqrMbtIJpdapd8wAMTPdoHUVwvrSD+4FGfE0yGFti00oByy39LiP J2cjz8osjYMOuo0yfP4abxwROaRU/f9AxkFZ5ShUjGHCyWEzFSQLxPTxda64AyCokgZS jqU/5EQ/n/XGY+nDhJbJE3Per57Ugqe4kyHr4IPwrXy6l/vCkA/O8LR0SmbnaJGj1YCl sQPQ== X-Forwarded-Encrypted: i=1; AJvYcCXr07xxd6TrkWBQdQ8HrH/TYRi4JThIYGNzx2bITo6waQGww8ERIvIFfVixYxTdh4SPv1iUk48UAZgVuTY=@vger.kernel.org X-Gm-Message-State: AOJu0YzZs4FPSo2eHI7RG34+y0G6VogHWJi7c8fOo0PnbXmhsurpeltU TkDdT/qu5zixpk93ki66dcuWCstt22x47RF7li8/rw2V6+ZEHPlOmZNbOLd5tISqgX4= X-Gm-Gg: ASbGncvbNNFFd7EGVE8stErf6EFeGBkiXL3v8XE82P40yRlsW0k2OgX0fYm+tH1gGPN N1xgaT8JV7yC03Ymv3IQdp4MOwnBTseLe/mlS9Za8gIe1x9ClFZ8VRrh+FTuwVNfKxJDaljNqdv ivESFmPeus8z/cEZHuy+4f7rJbz33xDtWhbz6knozS9/eIxlPl53N9uiz7QVyihxvG/E1NbokWu QuqxK8PGWkVC7kpa+B/O61JN7GLEDgT6R+twpPXnyXDVBXn89DV1BC86BkDBlmNiEu9JTJxnQeQ qntptixrgjwNYuILwR2Xj8MwwRNxkFZi+A52yaQKL1vAgpdK08g+SkWX7SrngQ2nJvFlz8rzyOI SdYfgWPoPIebP/DRaqotVnSGw/HVN/yXk3sh7jm14hvK3y1KWAqn/ X-Google-Smtp-Source: AGHT+IGHQNhqIB3JgmwwepWbvWA2111RF5PUV4yxQGXON8tqDIklGy8e/Cjdf3HtwXlEs0xEqbFKrw== X-Received: by 2002:a05:6000:430e:b0:3a6:d403:6429 with SMTP id ffacd0b85a97d-3a6d4036867mr5219824f8f.4.1750772373456; Tue, 24 Jun 2025 06:39:33 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-453646d1391sm143209275e9.9.2025.06.24.06.39.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:32 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 4/8] docs: dma-api: add a kernel-doc comment for dma_pool_zalloc() Date: Tue, 24 Jun 2025 15:39:19 +0200 Message-ID: <20250624133923.1140421-5-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Document the dma_pool_zalloc() wrapper. Signed-off-by: Petr Tesarik --- Documentation/core-api/mm-api.rst | 2 ++ include/linux/dmapool.h | 8 ++++++++ 2 files changed, 10 insertions(+) diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-= api.rst index af8151db88b2..a61766328ac0 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -97,6 +97,8 @@ DMA pools .. kernel-doc:: mm/dmapool.c :export: =20 +.. kernel-doc:: include/linux/dmapool.h + More Memory Management Functions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h index 06c4de602b2f..c0c7717d3ae7 100644 --- a/include/linux/dmapool.h +++ b/include/linux/dmapool.h @@ -60,6 +60,14 @@ static inline struct dma_pool *dma_pool_create(const cha= r *name, NUMA_NO_NODE); } =20 +/** + * dma_pool_zalloc - Get a zero-initialized block of DMA coherent memory. + * @pool: dma pool that will produce the block + * @mem_flags: GFP_* bitmask + * @handle: pointer to dma address of block + * + * Same as @dma_pool_alloc, but the returned memory is zeroed. + */ static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags, dma_addr_t *handle) { --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40B8E2D1F7C for ; Tue, 24 Jun 2025 13:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772380; cv=none; b=Hr4QNtwcwfYLdZuZGHlqF+Pi7wn9NE1G8o2CRFeG7jLOdciAHqy+DacRtB7kFptk2N0SX+lWYg5TYu9nf3z1cUdyEc8VkBcu7No1aVYot3RL7qCaOH+NdF7JbzcVRCGKmqN++uskaY7GJ5UPi2JL2mqqJocQoXRnsaP7kT8+VDY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772380; c=relaxed/simple; bh=j/lxvBE0W8RtTSwNWKrFB81pW4iq0UIccw1Ghb9PK6Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r8GKRL9u3Vcg0Qc5b+3CkyuhYaaFx/GUuWW2p7w6mHHtHOkpcMm22LoQ6UhHlJftcq0rh2v+Hjcbz78NFr549oDf6eT+ruC7uKzii++bMHgvIKeoQ07aH4qqm+EbaIJbE7BPPYihQ1v8qOmcOvL8hX0HEoGIYhsALy7G9o8ImHM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=SLNOunRH; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="SLNOunRH" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-45360a81885so1931405e9.2 for ; Tue, 24 Jun 2025 06:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772374; x=1751377174; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=SMoobju51S3yheRJ4nJb50lwjewYooD5+oD7p0lsIPI=; b=SLNOunRHP6SCuVgfQ8GbZUpNZiUJWrBqvSIladPPuo2blIty134Qs2A6ARfTcZuv0Q tbDTfBeXYyNeGU2O+8CWtQ+zseQDkpnXBIk8XUkhoUlnfkuA8i1Ze7cE+VDZi2m+ioTO FDYRM6AZh4XO+ZaW175gWY/V6R+EcpOx2C4o39KKcEbslSmJFot5GO0GbzYvl8Wfckhk YNgBW9PTbrFCLiM1m5rc3uxaCiGbIVn8kxq17IF7ASL39M+Bzu8m4p5ChpEZGtE90bUP 9YDmYRKWdyYg4Ax7Xzfy2AiYx66KlhKXLUs9/mcoq95Krlx6lCmaDDIMYOqsDoF7peve +RGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772374; x=1751377174; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SMoobju51S3yheRJ4nJb50lwjewYooD5+oD7p0lsIPI=; b=Jp543XmBKm4NjYYrfuGC6JTVbcZ0ZLHUpim9ihQXBh3j8/yL6OSCzPuH4XiZv8ZDhk JEluXf11bU1r2JLZywuM3Ajp3/0sbRt/W88ESqRvy8f0Gy+HPps+otc0fXNfAQla3C2V pc2yBAORkaiCM9Tou3J+VVh/JDPYji9GI+njPMx+QYipibKItsUf/Qpg0bYzB/fq3L2q gbzbIHf1pwjmhLhLZ1b/lqRqo2CO3haUkhGYc89D1aVwSWE2RpKxr2zsjdmjcjXVrfs5 l0DmISfgS33CnRB9+y8ce2zM0BeHJOfYeJPK9WP1FufhoQiPmULFIg06YbFbTbASaG40 1q9w== X-Forwarded-Encrypted: i=1; AJvYcCWo5huDn6B/I3m83+4XzynyL0UEz1MhgWoa4iK3TonRU/EBlz7fALK+eLLlmcmP/cOGmd8AqapRjVn8a1E=@vger.kernel.org X-Gm-Message-State: AOJu0YwAE24rlgIwr+pJxFsuDAmKNF6TCWw0B0iQmQlTyM42tiIN+CQX VWVanhK3Da4VC8N9xGNDBEaFgQePUzywJV5jWmUZsPx7910TH11OJ1YlPYmPSJbVvag= X-Gm-Gg: ASbGncs98/uDrXeEcmRs3kOQPexppWyUvG4vQLn+bTq2IsXwnGToWR1E2HxzhxdXonS gFc6S1lgZqhqCsX415eFFpnjOYCsVPSNsSGzjG0cSZkEW3K/t0MD2apyqiql8FyRXiPasQMVciN KWMDFXv/vhJF1D31zeL+48JpFiVCCElPEMTuFIdOl/Z34hX1v7x0PAPZgPpTELf/1WBlZ6MkYtj v473az4VYwTb7axFlbumjAyXE+DbL4932tivZmPnT1HHILftbzpzQWBUFvL/oTAX/errDPhpYrI 4fQRlxVxK/8vyGr+yym6OyDi/HHO0nIQt7xFCUi+UMgXDRg8jKzwDSAriSbFWWdVsNLuJRPl/EH e1898ywCafKM5s0x5K7+Gk6usk/DE0kbATUXbrYBGRNwuqD3JSGoe X-Google-Smtp-Source: AGHT+IEJyYo9lnu2Mk5wM3vEKd7mlfp5WCsbwymCeOMIaa9JZYjSHQ3akdWqQqS/IC1aMCHvKzNu3w== X-Received: by 2002:a05:600c:4747:b0:441:b397:e324 with SMTP id 5b1f17b1804b1-453659ca904mr62554965e9.9.1750772374485; Tue, 24 Jun 2025 06:39:34 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-4535eac8e19sm175941015e9.21.2025.06.24.06.39.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:34 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 5/8] docs: dma-api: remove duplicate description of the DMA pool API Date: Tue, 24 Jun 2025 15:39:20 +0200 Message-ID: <20250624133923.1140421-6-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The DMA pool API is documented in Memory Management APIs. Do not duplicate it in DMA API documentation. Signed-off-by: Petr Tesarik --- Documentation/core-api/dma-api.rst | 62 +----------------------------- Documentation/core-api/mm-api.rst | 2 + 2 files changed, 4 insertions(+), 60 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index 3e89e3b0ecfd..f7fddaf7510c 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -83,66 +83,8 @@ much like a struct kmem_cache, except that they use the = DMA-coherent allocator, not __get_free_pages(). Also, they understand common hardware constraints for alignment, like queue heads needing to be aligned on N-byte boundaries. =20 - -:: - - struct dma_pool * - dma_pool_create(const char *name, struct device *dev, - size_t size, size_t align, size_t alloc); - -dma_pool_create() initializes a pool of DMA-coherent buffers -for use with a given device. It must be called in a context which -can sleep. - -The "name" is for diagnostics (like a struct kmem_cache name); dev and size -are like what you'd pass to dma_alloc_coherent(). The device's hardware -alignment requirement for this type of data is "align" (which is expressed -in bytes, and must be a power of two). If your device has no boundary -crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated -from this pool must not cross 4KByte boundaries. - -:: - - void * - dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags, - dma_addr_t *handle) - -Wraps dma_pool_alloc() and also zeroes the returned memory if the -allocation attempt succeeded. - - -:: - - void * - dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags, - dma_addr_t *dma_handle); - -This allocates memory from the pool; the returned memory will meet the -size and alignment requirements specified at creation time. Pass -GFP_ATOMIC to prevent blocking, or if it's permitted (not -in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow -blocking. Like dma_alloc_coherent(), this returns two values: an -address usable by the CPU, and the DMA address usable by the pool's -device. - -:: - - void - dma_pool_free(struct dma_pool *pool, void *vaddr, - dma_addr_t addr); - -This puts memory back into the pool. The pool is what was passed to -dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what -were returned when that routine allocated the memory being freed. - -:: - - void - dma_pool_destroy(struct dma_pool *pool); - -dma_pool_destroy() frees the resources of the pool. It must be -called in a context which can sleep. Make sure you've freed all allocated -memory back to the pool before you destroy it. +See :ref:`Documentation/core-api/mm-api.rst ` for a detailed +description of the DMA pools API. =20 =20 Part Ic - DMA addressing limitations diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-= api.rst index a61766328ac0..de0bab6e3fdd 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -91,6 +91,8 @@ Memory pools .. kernel-doc:: mm/mempool.c :export: =20 +.. _dma_pools: + DMA pools =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 63C142D23AB for ; Tue, 24 Jun 2025 13:39:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772381; cv=none; b=UPeIHakxvrYNHVORejYLXypAY0m0+O6QqftSAWsviPiIiy2ciKUcuxquk95cioRNWYh4LXPpYpIT7szo2IZDRLQiXOJYQ0H42XHfz4a0nb0JhbBcP5XyPEoevKdrMcQEzaDWtuENO5LKoWE/6mpWfUHsm1pXiR23LHFhxW2Svdc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772381; c=relaxed/simple; bh=E+REAvkImx2ZVSFP5+sd6SOFCvTY9h9klgMb4XpdM7w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EXtXEPkEon5aST1N8QhhwYzQ/fc7ilNCWvtnSFTf33kK6+OuXw8ylZ+dx2OgPfPdiickboTAG97WtbFTm/eA8iuLYk7xjTsrqxuko7Tsb54s2fX9kTFZ3df08kLBtHGS91iion3AiX3Tbzv0OPUTS8eupb4QkyyrVtWE7jHSPoM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=UBUU6j6n; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="UBUU6j6n" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3a4e749d7b2so946229f8f.0 for ; Tue, 24 Jun 2025 06:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772377; x=1751377177; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tmoyTuVu4akx78qVJi6bTRvxekKYdC1/i6FSJLO9Fsw=; b=UBUU6j6nnj0Szuf+M8JmLAdrdrvLDpUMOep51yQcUkVPSSEFhm0wnxXGzFXsCUAufN kC4q9SY56+F7jLweMWjBok2iBzFGAKt1yniQY9YOiaOlJw+ZpWOILfzqlOB6bBks5oJD LdQy6gX6S279rUG6QjjawM/Ptq5fDiRRiw+LYdEBxuORU7EvnNFd4wDBFVEGwimlPZyD YPUB9ItUV9+bYfLEziTsZx5jpfq/tBePGtUUQILJacefOVpjbUV6jOrdRR874ykwUzyO +U0xiJHcA2hAVQ+XWf6enxQsST1o9JhEwverGcuC+IucjoPSNwxUa0uEWASm/FeQn9OI J+wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772377; x=1751377177; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tmoyTuVu4akx78qVJi6bTRvxekKYdC1/i6FSJLO9Fsw=; b=Rvuydl7IcfgGr3ybjDWwQ0GP2CcSM4vvHCZ3e6/7l1wTHIK5JPAltUtRG1CPrIA8aX nKU50FCJi/xBenNF4mulzYfXm4ZxpCpy2ZpiUTs8K+HR7+aMXbJAXBVY7elA85mVXY+n gquwWjHAu7K8jQYxJeg7UOr88ga1GFg34uAsbDmIMfJxxdzhuufZuI9GyT0RUi9q2Ygv mlsUwOfKDC/w2kLEZFz+xF21YCW6cQxVjsjNx5Th+GmmeFUYjpogQ1mVwpeSr0xxayaJ oGUry6MaBIJY9sXUeeiKXGlkwASBzK4BK2ugrUFzCwgDxgC97Bey6L2sbIGF/Xl5XRVz +Z0A== X-Forwarded-Encrypted: i=1; AJvYcCWjMVnG8eQhXHfQ++BD3U05Y8M4Z29lpYlRWQkURB+PB7464TzwN/ce4HwU+c8QC2bJCebXN8xQhzvy3tI=@vger.kernel.org X-Gm-Message-State: AOJu0YyNaZafYyum2a956Jq6HCGKDW9+KOT2LeZTUYofcCh7YFs8MQXs EWhuM/aY25rHfJGfPodrtNBwwTjqb7VkMbXnup8/bmCVCrIqQWC7lEFjxFDPADF7ZzY= X-Gm-Gg: ASbGncuz0byTw07JD6IlgwVeciV4rK6duiOw+o6yeRpFbq0WhFxvujsulbTKdf1Wh7w YYSQXMMApPL+fFWlSOGwbnHE+LBxJF5fhOFAXLtvRjhDZyabMDzctwZ59N/ruS09KmAWocxCE45 FhiY1WZHNrUhsEBPAW1JG5h59iCL8TStGfYLGQ0wcdlySsOA2P+tLR/cqcTTCsB2AtSv0tpbC0a 6W8X8eRPBeUCd18e53AIUQwWFoOdDNzE+cjxASyqc+4PweCz97/7b9C24bDlIiOTx9XGkLmE6XD cKmJ41DTVwPKpMDiMWPGuBBIR3+7bTH55kMsPZHsUauDWFaCoaElxZYikyJM00wn9eeGdFMxikd 55tUSicKw1sKI+wy4/m4kx2U8wiaHyfRg0e3RAjB9+6TZ/Hqungqo X-Google-Smtp-Source: AGHT+IGkZrplpRBlcgMXcjw1DbH2uA7Xgft+a5isw/zKi2IcP2PXv5geqjz1FHC5se+KenSl4WGZcQ== X-Received: by 2002:a05:6000:4412:b0:3a5:7895:7f7e with SMTP id ffacd0b85a97d-3a6d12ebe7fmr3683192f8f.15.1750772376600; Tue, 24 Jun 2025 06:39:36 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a6e80f2274sm1961890f8f.48.2025.06.24.06.39.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:35 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 6/8] docs: dma-api: clarify DMA addressing limitations Date: Tue, 24 Jun 2025 15:39:21 +0200 Message-ID: <20250624133923.1140421-7-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the description of DMA mask from the documentation of dma_map_single() to Part Ic - DMA addressing limitations and improve the wording. Explain when a mask setting function may fail, and do not repeat this explanation for each individual function. Clarify which device parameters are updated by each mask setting function. Signed-off-by: Petr Tesarik Reviewed-by: Bagas Sanjaya --- Documentation/core-api/dma-api.rst | 35 +++++++++++++++--------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index f7fddaf7510c..cd432996949c 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -90,13 +90,20 @@ description of the DMA pools API. Part Ic - DMA addressing limitations ------------------------------------ =20 +DMA mask is a bit mask of the addressable region for the device. In other = words, +if applying the DMA mask (a bitwise AND operation) to the DMA address of a +memory region does not clear any bits in the address, then the device can +perform DMA to that memory region. + +All the below functions which set a DMA mask may fail if the requested mask +cannot be used with the device, or if the device is not capable of doing D= MA. + :: =20 int dma_set_mask_and_coherent(struct device *dev, u64 mask) =20 -Checks to see if the mask is possible and updates the device -streaming and coherent DMA mask parameters if it is. +Updates both streaming and coherent DMA masks. =20 Returns: 0 if successful and a negative error if not. =20 @@ -105,8 +112,7 @@ Returns: 0 if successful and a negative error if not. int dma_set_mask(struct device *dev, u64 mask) =20 -Checks to see if the mask is possible and updates the device -parameters if it is. +Updates only the streaming DMA mask. =20 Returns: 0 if successful and a negative error if not. =20 @@ -115,8 +121,7 @@ Returns: 0 if successful and a negative error if not. int dma_set_coherent_mask(struct device *dev, u64 mask) =20 -Checks to see if the mask is possible and updates the device -parameters if it is. +Updates only the coherent DMA mask. =20 Returns: 0 if successful and a negative error if not. =20 @@ -171,7 +176,7 @@ transfer memory ownership. Returns %false if those cal= ls can be skipped. unsigned long dma_get_merge_boundary(struct device *dev); =20 -Returns the DMA merge boundary. If the device cannot merge any the DMA add= ress +Returns the DMA merge boundary. If the device cannot merge any DMA address segments, the function returns 0. =20 Part Id - Streaming DMA mappings @@ -205,16 +210,12 @@ DMA_BIDIRECTIONAL direction isn't known this API should be obtained from sources which guarantee it to be physically contiguous (like kmalloc). =20 - Further, the DMA address of the memory must be within the - dma_mask of the device (the dma_mask is a bit mask of the - addressable region for the device, i.e., if the DMA address of - the memory ANDed with the dma_mask is still equal to the DMA - address, then the device can perform DMA to the memory). To - ensure that the memory allocated by kmalloc is within the dma_mask, - the driver may specify various platform-dependent flags to restrict - the DMA address range of the allocation (e.g., on x86, GFP_DMA - guarantees to be within the first 16MB of available DMA addresses, - as required by ISA devices). + Further, the DMA address of the memory must be within the dma_mask of + the device. To ensure that the memory allocated by kmalloc is within + the dma_mask, the driver may specify various platform-dependent flags + to restrict the DMA address range of the allocation (e.g., on x86, + GFP_DMA guarantees to be within the first 16MB of available DMA + addresses, as required by ISA devices). =20 Note also that the above constraints on physical contiguity and dma_mask may not apply if the platform has an IOMMU (a device which --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 921282D23B2 for ; Tue, 24 Jun 2025 13:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772381; cv=none; b=PxKS1zSYw6aBc0laEepv2Bm3CxJPIytHogg5PcDkjQytrOdD3QAKRxDuhAYF2UE7aRaH3Vmv/7akZjW6JezBQ6y5tbngA0YOO43JkflbsCiHkx6HaWaU73UTniVafLvfiTcVp+VE5AGe+NCyOVd/s1knoTrP8AtAH3MGt/S4cfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772381; c=relaxed/simple; bh=csFIrfXy0fedNjjmAddrddMk/Vqb6fR+cfz6pIU/Vd4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gGy1HiFW0yWcJgzvSHJuAHqWwscLHp+hvTtX80wMggr8RBDwjwx1VUBWoK4c1PZ7YiH6IAPNWnJxjPxyHDFcUp21vmUcm4rk6t+y8ssBNMUXtL7goFHFg2DH898MnoQoUjSNzzUIc+Yk90rZ61doJu99zFakSK4tFYi8kYfkOkY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=f4tyvbx2; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="f4tyvbx2" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-3a528e301b0so283421f8f.1 for ; Tue, 24 Jun 2025 06:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772378; x=1751377178; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MIxqpUsJs9BGJgIKtRsM8twkmF7DXFUM7UQBjMXgiB8=; b=f4tyvbx2EL05OH4YlSJFuhpYGb+NE9wRaMAYGctPhke4zkdkb1Zp5zrka1OHb2nq25 ZFbbIZi9YdHbgRukaIiy1xQnzXbmXixxY7VNZ/aqHk3i4WNgmaAoIfKtDD115cXsAg8C FWOMPMIqNt2P2rEwEHHrS1LqF7MvszrUv+XrTOsg0RJt/3tHMLLUfGEghN6J6FBoKh5m 4wNhPGn7Bru60IhC2wYPEVYgMluXsMvqT/3bGdBx4tAbTuf3bj36ulI7OdeH3j495j3a CwaDDWwOnwCdHgih+0GFWXL+OwzgJ6LvvinTGG7pcZBEzFEY6xoiDkFh14apxLCytZwF Qvkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772378; x=1751377178; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MIxqpUsJs9BGJgIKtRsM8twkmF7DXFUM7UQBjMXgiB8=; b=JAIZe81Z+woG0HbkYI3nIDE9Zen5tRUvTFyHl5Zeen6PAmQEmDvIyBqiqbWtt8MGYw lMBwLzKKWzsyEZ9CUGpX1Mk3mlV5n0sFXI5Y1/CTiqSPtbdGfIpm8f8Hg5WBimlKmgYO mEkmBwx6QFaJQvNSqXXT6BjE6K1kiIoVCFlzcmcCxUfH1UyP0G8ddwNX3o7JBoGY6rrB Iu3dkbTOSLVqwzC8TejHLymZfXdVVCdYRM3jr4c6ztuYaL2QyxKUFBKf53deIfNEj4qR vPThHPPdoAzn2l7OiAQe4toRj16hxSIqttCBMSXRx0jbcmJlIMZFIbqahibsSoVbuvZK g21w== X-Forwarded-Encrypted: i=1; AJvYcCUw34pUO0sD4pHmrYOkZZ3d6/aOH4y8ClXM9CFbChMZ21GXTPrCuAxSX+TM1qMsnLlwnj4x1t9FGbr2Rn0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4lRU2aSuIkmNVrAFHm47T2OMYKgMCuEprqYfCELNYWkFS5Z7N p0ArLaSrMxmt5Z9VML8JrpzkTQzeTOrtXV1rq0WuTYxc5piZIEo3kh7dMieEBJa4GfY= X-Gm-Gg: ASbGnctRQZhe2rTrwiNuNKtB0dDBDqxCCm6k4IbiuAV1michbcy8EMXexL0wG18BMIO Z1Czj4RHIY3nC5uTmWve45su5IdNLdVp4uv886Q0OICTPXJCOK1S+1NruyUneM2R+/bM1+VJADg s5wO7ssVtsKFr7mtFsoLOlNW3UKYwRVXLxROsomg2dCv+7TgtrXmdq8w+WDOhcdJKIXjDcGjUsF wBNORqh7ODR2DN0oq5u1k4RK0ITP5TkEoPE1XApjaiqOSXfBEUvrq4Q2ywuvhM/PytBI55U8JkO d1U1oobQTWuE+/EZZdliMII2biieBQptxH090ZXC63jkO4Y8ixB/LVc9Dc4kH1HTWQCzbN5yaDB Eid3WfMgBa5VSd+45k81xZgX5IF/AFr+oqYE+qCQ1AEgkkX6sZ3+f X-Google-Smtp-Source: AGHT+IEjaxkBLFq2C7HKp7UXXzPUtMdjdq0jQWl+WGokmC3baJpMc/moJUhdPmwtbE7N5mn13G5tFA== X-Received: by 2002:a05:6000:2013:b0:3a3:6a3f:bc61 with SMTP id ffacd0b85a97d-3a6d12f9a28mr5299380f8f.7.1750772377699; Tue, 24 Jun 2025 06:39:37 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-4535eac8e19sm175942315e9.21.2025.06.24.06.39.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:37 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 7/8] docs: dma-api: update streaming DMA API physical address constraints Date: Tue, 24 Jun 2025 15:39:22 +0200 Message-ID: <20250624133923.1140421-8-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Clarify that SWIOTLB also allows to use any physical address with the streaming DMA API. Remove the requirement to use platform-dependent flags to allocate buffers for dma_map_single(). Do not claim that platforms with an IOMMU may not require physically contiguous buffers. Although the claim is generally correct, it is misleading, because the current implementation of the streaming DMA API explicitly rejects vmalloc addresses, no matter if an IOMMU is present or not. Signed-off-by: Petr Tesarik Reviewed-by: Bagas Sanjaya --- Documentation/core-api/dma-api.rst | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index cd432996949c..65132ec88104 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -210,18 +210,12 @@ DMA_BIDIRECTIONAL direction isn't known this API should be obtained from sources which guarantee it to be physically contiguous (like kmalloc). =20 - Further, the DMA address of the memory must be within the dma_mask of - the device. To ensure that the memory allocated by kmalloc is within - the dma_mask, the driver may specify various platform-dependent flags - to restrict the DMA address range of the allocation (e.g., on x86, - GFP_DMA guarantees to be within the first 16MB of available DMA - addresses, as required by ISA devices). - - Note also that the above constraints on physical contiguity and - dma_mask may not apply if the platform has an IOMMU (a device which - maps an I/O DMA address to a physical memory address). However, to be - portable, device driver writers may *not* assume that such an IOMMU - exists. + Mapping may also fail if the memory is not within the DMA mask of the + device. However, this constraint does not apply if the platform has + an IOMMU (a device which maps an I/O DMA address to a physical memory + address), or the kernel is configured with SWIOTLB (bounce buffers). + It is reasonable to assume that at least one of these mechanisms + allows streaming DMA to any physical address. =20 .. warning:: =20 --=20 2.49.0 From nobody Wed Oct 8 20:55:29 2025 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A024C2C375A for ; Tue, 24 Jun 2025 13:39:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772382; cv=none; b=Jr9QuU8qSvyan/6Y8z266LOLEYJTMS35x7cTCWgKhrl1hGLxEVqZLCxKqpXGdlyX3726keVGYwpbbu9EH4LVUKOv5J5syueSXkXiW0tUoy1Xec8l3KUamhNHVY+S/ZTqdeWOvAHw2cghS1HZqaKen4f+j/DGyb0Al34J5Ax9SRQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750772382; c=relaxed/simple; bh=QT9inBggY1If/sJ/J64i0f/T+fZ+JZCkAwwWoVQBbug=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Tp+i655fT4qNYMRjWH5XX5xJeqpofTDsWkrlhC7MV7fXU198U7IkKQEfoBJVwWgWdpay7jBjjuluyfiy3iqqaqnaUpGScuDPwvvdzBsSgX1LXm6rKFOz4BIthqeyfWFhpQbtx8QEmcakiEcYh9tayKQogpxDB3gX62PFth3dZWE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=BCWI0PGy; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="BCWI0PGy" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-453486940fdso2223575e9.1 for ; Tue, 24 Jun 2025 06:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1750772379; x=1751377179; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4sx2Gr9jg00N7+zRyz0IpMFfOiCDQPryj3aB7m6WADE=; b=BCWI0PGyCv0/xS3ddpxHK7jaMwd/iSqoufKjDIul00unT+kyGM51soBla8Ulns7pfZ q/exk4su2PBT2r4To2uKqAxJYhpdVjom9ZPpGEXxCrHBL8C2/OFV20QoRWXcp1CxL02A RJ+1daq3yWKV1wu3XbmZwhnuao9+dRTnKg1puo8om0SRMwTvNCXSvY0SvZjh1KqxsWDK svNIKd2vvExxyqRWS0QoPxXkEMkLZJBuh7DPltGbH32FW3Q5PXM4xVzaumK6hoHemcjo 3v7b5kbXlIVm4EeWFwAnEtaF8PYA5TnbJaJiIRtoINCUEiRIT6px4ksTUFKuw01wd0ZC 0jtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750772379; x=1751377179; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4sx2Gr9jg00N7+zRyz0IpMFfOiCDQPryj3aB7m6WADE=; b=muCUHZoagzepg9Dx9gZMEdYusvYddvlcGsqBQeSvyNCxOVOXLYECH+9pnVQWgAFQX1 CIrJ4HyUqE3Fw20DdIWYykLE9sFGIF8R/2RY9/sDJO8VslA7VyRt5e6EADwMXwtYD01e AfnChqj/1Bv8BHOLPhkY/g+mwl2uMFw61fYWy7B0gJzFBonM1oZYnc0/uez3qtgRoyLG Q1eDjCvj+aLk4DKzt6PkQ/ITfp5SqpnB+g31FTwco9Sn+2C3j+ZtZZjvVrNeTuzsF0cm LVfyDuvBdxBOO7nPugiCCysbWzOfD37IJEZ0ikt9hoiD6OI6bLFhdPuJbw6CS56a8zY5 mNtQ== X-Forwarded-Encrypted: i=1; AJvYcCWmLV+dPxIhj/wTnd/GevRd2vF6+ItBfP4/IP9CziId8esuTtauAf7nqXFyY3bPdJIMqgVZ+P2rwybSI18=@vger.kernel.org X-Gm-Message-State: AOJu0YyfPyp/QVRTF9kf20jiGSEQmFK63k8esqX3rrMOz1Hkqvwg3yUN F245h/lF/uN7n+Ez89U7tm0Tp3QnJwblc3wgINMRTnMb68HXG2KCWMd7tdr2RJHfhbs= X-Gm-Gg: ASbGncul1N/nQhcTWCItTYXr/m93hb4qfYsWd+1cGa7qI29LJguBZJJ672VViQ9T4xr T+uDrMR9ndi2YK8Fk644G1ROwwnFdu5wvUMyXUkENZtkpFNjn03JrN8WiwrQy3XWBVC6WrGq7c1 ksFqRn0TrEsKN0fMo8HE+HE+JOv24g6Y+XWIHLVmkN/ZvxeIQ8BeSuEiupjEVkQjvt9a+gGPanb iF4k0/JyvwqCyAF6MDTlUu1fVuyJhl8yEhCjYqLsZuSj7I2yxApOik10jveGXWm1wPG2/+cYRNq 6fprI5qo6HD1Dq5s2YvVjwTJgfwWPox5zsZ/CLeWStjydpuBGJIPIDmT2beG2WtE/oyLHy57W22 NUJlxTQiA7e0X9+LcoYHIQ5w1nQsTzDnydRfSdKY7dxDIowUghdWT X-Google-Smtp-Source: AGHT+IHjfatN3aA0WosLoWdQDyKydeoZw/uVFREpIVO7tEoIVnSxxs5IGUHXJ6h6lYlWKWIGlOYciQ== X-Received: by 2002:a05:600c:4e8a:b0:451:eed7:6d76 with SMTP id 5b1f17b1804b1-453659ca55cmr57962935e9.8.1750772378926; Tue, 24 Jun 2025 06:39:38 -0700 (PDT) Received: from localhost (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a6e805100dsm2044971f8f.18.2025.06.24.06.39.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 06:39:38 -0700 (PDT) From: Petr Tesarik To: Jonathan Corbet , Morton Cc: Marek Szyprowski , Leon Romanovsky , Keith Busch , Caleb Sander Mateos , Sagi Grimberg , Jens Axboe , John Garry , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-mm@kvack.org (open list:MEMORY MANAGEMENT), Petr Tesarik Subject: [PATCH 8/8] docs: dma-api: clean up documentation of dma_map_sg() Date: Tue, 24 Jun 2025 15:39:23 +0200 Message-ID: <20250624133923.1140421-9-ptesarik@suse.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250624133923.1140421-1-ptesarik@suse.com> References: <20250624133923.1140421-1-ptesarik@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Describe in one sentence what the function does. Do not repeat example situations when the returned number is lower than the number of segments on input. Signed-off-by: Petr Tesarik Reviewed-by: Bagas Sanjaya --- Documentation/core-api/dma-api.rst | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dm= a-api.rst index 65132ec88104..f5aadb7f8626 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -308,10 +308,10 @@ action (e.g. reduce current DMA mapping usage or dela= y and try again later). dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) =20 -Returns: the number of DMA address segments mapped (this may be shorter -than passed in if some elements of the scatter/gather list are -physically or virtually adjacent and an IOMMU maps them with a single -entry). +Maps a scatter/gather list for DMA. Returns the number of DMA address segm= ents +mapped, which may be smaller than passed in if several consecutive +sglist entries are merged (e.g. with an IOMMU, or if some adjacent segments +just happen to be physically contiguous). =20 Please note that the sg cannot be mapped again if it has been mapped once. The mapping process is allowed to destroy information in the sg. @@ -335,9 +335,8 @@ With scatterlists, you use the resulting mapping like t= his:: where nents is the number of entries in the sglist. =20 The implementation is free to merge several consecutive sglist entries -into one (e.g. with an IOMMU, or if several pages just happen to be -physically contiguous) and returns the actual number of sg entries it -mapped them to. On failure 0, is returned. +into one. The returned number is the actual number of sg entries it +mapped them to. On failure, 0 is returned. =20 Then you should loop count times (note: this can be less than nents times) and use sg_dma_address() and sg_dma_len() macros where you previously --=20 2.49.0