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
next 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