Linux IOMMU Development
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>
Cc: "open list:AMD IOMMU \(AMD-VI\)"
	<iommu@lists.linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: dma-mapping: use bit macros
Date: Fri, 29 Nov 2019 21:27:26 +0100	[thread overview]
Message-ID: <1519de9e-0bd6-c7e7-a911-d51481dfb415@gmail.com> (raw)

Not necessarily a big leap for mankind, but using bit macros makes
the code better readable, especially the definition of DMA_BIT_MASK
is more intuitive.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 include/linux/dma-mapping.h | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a4930310d..a39a6a8d5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -2,6 +2,7 @@
 #ifndef _LINUX_DMA_MAPPING_H
 #define _LINUX_DMA_MAPPING_H
 
+#include <linux/bits.h>
 #include <linux/sizes.h>
 #include <linux/string.h>
 #include <linux/device.h>
@@ -21,51 +22,51 @@
  * DMA_ATTR_WEAK_ORDERING: Specifies that reads and writes to the mapping
  * may be weakly ordered, that is that reads and writes may pass each other.
  */
-#define DMA_ATTR_WEAK_ORDERING		(1UL << 1)
+#define DMA_ATTR_WEAK_ORDERING		BIT(1)
 /*
  * DMA_ATTR_WRITE_COMBINE: Specifies that writes to the mapping may be
  * buffered to improve performance.
  */
-#define DMA_ATTR_WRITE_COMBINE		(1UL << 2)
+#define DMA_ATTR_WRITE_COMBINE		BIT(2)
 /*
  * DMA_ATTR_NON_CONSISTENT: Lets the platform to choose to return either
  * consistent or non-consistent memory as it sees fit.
  */
-#define DMA_ATTR_NON_CONSISTENT		(1UL << 3)
+#define DMA_ATTR_NON_CONSISTENT		BIT(3)
 /*
  * DMA_ATTR_NO_KERNEL_MAPPING: Lets the platform to avoid creating a kernel
  * virtual mapping for the allocated buffer.
  */
-#define DMA_ATTR_NO_KERNEL_MAPPING	(1UL << 4)
+#define DMA_ATTR_NO_KERNEL_MAPPING	BIT(4)
 /*
  * DMA_ATTR_SKIP_CPU_SYNC: Allows platform code to skip synchronization of
  * the CPU cache for the given buffer assuming that it has been already
  * transferred to 'device' domain.
  */
-#define DMA_ATTR_SKIP_CPU_SYNC		(1UL << 5)
+#define DMA_ATTR_SKIP_CPU_SYNC		BIT(5)
 /*
  * DMA_ATTR_FORCE_CONTIGUOUS: Forces contiguous allocation of the buffer
  * in physical memory.
  */
-#define DMA_ATTR_FORCE_CONTIGUOUS	(1UL << 6)
+#define DMA_ATTR_FORCE_CONTIGUOUS	BIT(6)
 /*
  * DMA_ATTR_ALLOC_SINGLE_PAGES: This is a hint to the DMA-mapping subsystem
  * that it's probably not worth the time to try to allocate memory to in a way
  * that gives better TLB efficiency.
  */
-#define DMA_ATTR_ALLOC_SINGLE_PAGES	(1UL << 7)
+#define DMA_ATTR_ALLOC_SINGLE_PAGES	BIT(7)
 /*
  * DMA_ATTR_NO_WARN: This tells the DMA-mapping subsystem to suppress
  * allocation failure reports (similarly to __GFP_NOWARN).
  */
-#define DMA_ATTR_NO_WARN	(1UL << 8)
+#define DMA_ATTR_NO_WARN		BIT(8)
 
 /*
  * DMA_ATTR_PRIVILEGED: used to indicate that the buffer is fully
  * accessible at an elevated privilege level (and ideally inaccessible or
  * at least read-only at lesser-privileged levels).
  */
-#define DMA_ATTR_PRIVILEGED		(1UL << 9)
+#define DMA_ATTR_PRIVILEGED		BIT(9)
 
 /*
  * A dma_addr_t can hold any valid DMA or bus address for the platform.
@@ -136,7 +137,7 @@ struct dma_map_ops {
 extern const struct dma_map_ops dma_virt_ops;
 extern const struct dma_map_ops dma_dummy_ops;
 
-#define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+#define DMA_BIT_MASK(n)	GENMASK_ULL(n - 1, 0)
 
 #define DMA_MASK_NONE	0x0ULL
 
-- 
2.24.0

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

             reply	other threads:[~2019-11-29 20:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 20:27 Heiner Kallweit [this message]
2019-11-30  8:18 ` dma-mapping: use bit macros Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1519de9e-0bd6-c7e7-a911-d51481dfb415@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox