x86/io: Define readq()/writeq() to use 64-bit type
PATCH 1/1 x86/io: Define readq()/writeq() to use 64-bit type
Since non atomic readq() and writeq() were added some of the drivers would like to use it in a manner of:
#include <io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));
However, lo_hi_readq() always returns __u64 data, while readq() on x86_64 defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit on x86_64.
Convert readq() and writeq() on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using either unsigned long long, or u64 type for readq() / writeq(). This change propagates consistency in that sense.
While this is not an issue per se, though if someone wants to address it, the anchor could be the commit
797a796a13df ("asm-generic: architecture independent readq/writeq for 32bit environment")
where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
--- arch/x86/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/include/asm/io.h +4 -4
@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )#ifdef CONFIG_X86_64 -build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a) #define writeq_relaxed(v, a) __writeq(v, a)
Signature · 1 line
2.15.1
Quoted 59 lines · Andy Shevchenko
Since non atomic
readq()andwriteq()were added some of the drivers would like to use it in a manner of:#include <
io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));However,
lo_hi_readq()always returns__u64data, whilereadq()onx86_64defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit onx86_64.Convert
readq()andwriteq()on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using
either unsigned long long, or u64 type forreadq()/writeq(). This change propagates consistency in that sense.While this is not an issue per se, though if someone wants to address it,
the anchor could be the commit
797a796a13df("asm-generic: architecture independent readq/writeq for 32bit environment")where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
Reported-by lkp <[email protected]>Cc Hitoshi Mitake <[email protected]>Cc "Mehta, Sohil" <[email protected]>Signed-off-by Andy Shevchenko <[email protected]>---
arch/x86/include/asm/io.h | 8 ++++----1 file changed, 4 insertions(+), 4 deletions(-)arch/x86/include/asm/io.h +0
-0@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )
#ifdefCONFIG_X86_64arch/x86/include/asm/io.h +4
-4-build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", )
Quoted 3 lines
#definereadq_relaxed(a)__readq(a)
#definewriteq_relaxed(v, a)__writeq(v, a)
The patch works for me:
Sohil
[email protected]
reviewerQuoted 66 lines · Sohil
Quoted 59 lines · Andy Shevchenko
Since non atomic
readq()andwriteq()were added some of the drivers would like to use it in a manner of:#include <
io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));However,
lo_hi_readq()always returns__u64data, whilereadq()onx86_64defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit onx86_64.Convert
readq()andwriteq()on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using
either unsigned long long, or u64 type forreadq()/writeq(). This change propagates consistency in that sense.While this is not an issue per se, though if someone wants to address it,
the anchor could be the commit
797a796a13df("asm-generic: architecture independent readq/writeq for 32bit environment")where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
Reported-by lkp <[email protected]>Cc Hitoshi Mitake <[email protected]>Cc "Mehta, Sohil" <[email protected]>Signed-off-by Andy Shevchenko <[email protected]>---
arch/x86/include/asm/io.h | 8 ++++----1 file changed, 4 insertions(+), 4 deletions(-)arch/x86/include/asm/io.h +0
-0@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )
#ifdefCONFIG_X86_64arch/x86/include/asm/io.h +4
-4-build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", )Quoted 3 lines
#definereadq_relaxed(a)__readq(a)
#definewriteq_relaxed(v, a)__writeq(v, a)The patch works for me:
Quoted 3 lines
Tested-by Sohil Mehta <[email protected]>Sohil
Wouldn't simply u64 make more sense?
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Quoted 14 lines · On Mon, 2018-01-22 at 16:46 -0800, [email protected] wrote:
Quoted 12 lines · Sohil
arch/x86/include/asm/io.h build_mmio_write(__writel, "l", unsigned int, "r", ) · line 103
Quoted 7 lines · Andy Shevchenko
arch/x86/include/asm/io.h +4
-0+build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a) #define writeq_relaxed(v, a) __writeq(v, a)The patch works for me:
Quoted 4 lines
Quoted 2 lines
Tested-by Sohil Mehta <[email protected]>Wouldn't simply u64 make more sense?
It would break a common style used in this module for the rest of accessors.
So, I prefer to go with unsigned long long and change later, if needed, from POD types to uNN ones in entire file.
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 14 lines · Andy Shevchenko
Quoted 12 lines · On Mon, 2018-01-22 at 16:46 -0800, [email protected] wrote:
Quoted 10 lines · Sohil
Quoted 6 lines · Andy Shevchenko
+build_mmio_read(readq, "q", unsigned long long, "=r", :"memory")
(quoted diff) +2
-0+build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r",:"memory")
+build_mmio_write(__writeq, "q", unsigned long long, "r", )The patch works for me:
Tested-by Sohil Mehta <[email protected]>
Quoted 8 lines
Quoted 1 line
Wouldn't simply u64 make more sense?
It would break a common style used in this module for the rest of accessors.
So, I prefer to go with unsigned long long and change later, if needed,
from POD types to uNN ones in entire file.
So, Peter, Ingo, Thomas, can we move forward with this one?
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
tip-bot for Andy Shevchenko
merge botx86/io: Define readq()/writeq() to use 64-bit type
Commit-ID: 0fc8483b698620ea3d8cc6635b54eccc613c23a3 Gitweb: https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54eccc613c23a3 Author: Andy Shevchenko <[email protected]> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 13 Feb 2018 17:14:41 +0100
x86/io: Define readq()/writeq() to use 64-bit type
Since non atomic readq() and writeq() were added some of the drivers would like to use it in a manner of:
#include <io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));
However, lo_hi_readq() always returns __u64 data, while readq() on x86_64 defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit on x86_64.
Convert readq() and writeq() on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using either unsigned long long, or u64 type for readq() / writeq(). This change propagates consistency in that sense.
While this is not an issue per se, though if someone wants to address it, the anchor could be the commit
797a796a13df ("asm-generic: architecture independent readq/writeq for 32bit environment")
where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
--- arch/x86/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/include/asm/io.h +4 -4
@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )#ifdef CONFIG_X86_64 -build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a) #define writeq_relaxed(v, a) __writeq(v, a)
Quoted 7 lines · tip-bot for Andy Shevchenko
Commit-ID: 0fc8483b698620ea3d8cc6635b54eccc613c23a3 Gitweb: https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc c613c23a3 Author: Andy Shevchenko <[email protected]> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 13 Feb 2018 17:14:41 +0100
As of today I don't see this in linux-next
% git tag --contains 0fc8483b69862
next-20180214
next-20180215
next-20180216
What happened to this change?
Quoted 71 lines
x86/io: Define readq()/writeq() to use 64-bit type
Since non atomic
readq()andwriteq()were added some of the drivers would like to use it in a manner of:#include <
io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));However,
lo_hi_readq()always returns__u64data, whilereadq()onx86_64defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit onx86_64.Convert
readq()andwriteq()on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using either unsigned long long, or u64 type forreadq()/writeq(). This change propagates consistency in that sense.While this is not an issue per se, though if someone wants to address it,
the anchor could be the commit
797a796a13df("asm-generic: architecture independent readq/writeq
for 32bit environment")where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
Reported-by lkp <[email protected]>Tested-by Sohil Mehta <[email protected]>Signed-off-by Andy Shevchenko <[email protected]>Cc Hitoshi Mitake <[email protected]>Cc Linus Torvalds <[email protected]>Cc Mehta, Sohil <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Thomas Gleixner <[email protected]>Signed-off-by Ingo Molnar <[email protected]>--- arch/x86/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)arch/x86/include/asm/io.h +4
-4@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )#ifdef CONFIG_X86_64 -build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a)#define
writeq_relaxed(v, a)__writeq(v, a)
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 9 lines · Andy Shevchenko
Quoted 7 lines · tip-bot for Andy Shevchenko
Commit-ID: 0fc8483b698620ea3d8cc6635b54eccc613c23a3 Gitweb: https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc c613c23a3 Author: Andy Shevchenko <[email protected]> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 13 Feb 2018 17:14:41 +0100
Quoted 8 lines
As of today I don't see this in linux-next
% git tag --contains
0fc8483b69862
next-20180214
next-20180215
next-20180216What happened to this change?
Hm, so it's a real mystery: I merged it, then removed it 1.5 days later without reporting anything. According to the Git log timestamp the removal happened late at night, so maybe it was a tired typo?
Anyway, it's a good thing you kept out an eye for this: I re-applied the patch for v4.17 and will let you know if there's any problem in testing.
Thanks,
Ingo
Quoted 7 lines · Ingo Molnar
Quoted 7 lines
As of today I don't see this in linux-next
% git tag --contains
0fc8483b69862
next-20180214
next-20180215
next-20180216
Quoted 5 lines
Quoted 1 line
What happened to this change?
Hm, so it's a real mystery: I merged it, then removed it 1.5 days later without reporting anything. According to the Git log timestamp the removal happened late at night, so maybe it was a tired typo?
So just a few seconds after sending this I remembered why I zapped it: it was a Sparse failure reported by the kbuild-test robot.
Here's the report:
[tip:x86/urgent 14/14] drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse: incorrect type in argument 1 (different base types)
Since you were on Cc: of that report I assumed you'd take care of it.
Thanks,
Ingo
Quoted 16 lines · Ingo Molnar
Quoted 7 lines · Ingo Molnar
Quoted 7 lines
As of today I don't see this in linux-next
% git tag --contains
0fc8483b69862
next-20180214
next-20180215
next-20180216Quoted 5 lines
Quoted 1 line
What happened to this change?
Hm, so it's a real mystery: I merged it, then removed it 1.5 days later without reporting anything. According to the Git log timestamp the removal happened late at night, so maybe it was a tired typo?
Quoted 8 lines
So just a few seconds after sending this I remembered why I zapped it: it was a Sparse failure reported by the kbuild-test robot.
Here's the report:
[tip:x86/urgent 14/14]
drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse: incorrect type in argument 1 (different base types)Since you were on Cc: of that report I assumed you'd take care of it.
Ah, yes. This one I fixed.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 8 lines · Andy Shevchenko
Quoted 5 lines · Ingo Molnar
* Ingo Molnar <[email protected]> wrote:
[tip:x86/urgent 14/14]
drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse: incorrect type in argument 1 (different base types)Since you were on Cc: of that report I assumed you'd take care of it.
Ah, yes. This one I fixed.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 5 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Ingo Molnar
* Ingo Molnar <[email protected]> wrote:
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
[tip:x86/urgent 14/14]
drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse: incorrect type in argument 1 (different base types)Since you were on Cc: of that report I assumed you'd take care of it.
Ah, yes. This one I fixed.
Yeah, so this fix in the RDMA tree needs to go upstream first, before we can apply the changes to the interface. Could you resend at around v4.17-rc1 or so?
Thanks,
Ingo
Quoted 16 lines · Ingo Molnar
Quoted 14 lines · Andy Shevchenko
Quoted 11 lines · Andy Shevchenko
Quoted 7 lines · Ingo Molnar
* Ingo Molnar <[email protected]> wrote:
[tip:x86/urgent 14/14]drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse:
incorrect type in argument 1 (different base types)Since you were on Cc: of that report I assumed you'd take care of it.
Ah, yes. This one I fixed.
Quoted 7 lines
Quoted 2 lines
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit
/?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9Yeah, so this fix in the RDMA tree needs to go upstream first, before we can apply
the changes to the interface. Could you resend at around v4.17-rc1 or so?
Sure. Thanks!
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 16 lines · Ingo Molnar
Quoted 14 lines · Andy Shevchenko
Quoted 11 lines · Andy Shevchenko
Quoted 7 lines · Ingo Molnar
* Ingo Molnar <[email protected]> wrote:
[tip:x86/urgent 14/14]drivers/infiniband/hw/hns/hns_roce_hw_v1.c:1690:22: sparse:
incorrect type in argument 1 (different base types)Since you were on Cc: of that report I assumed you'd take care of it.
Ah, yes. This one I fixed.
Quoted 7 lines
Quoted 2 lines
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit
/?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9Yeah, so this fix in the RDMA tree needs to go upstream first, before we can apply
the changes to the interface. Could you resend at around v4.17-rc1 or so?
Btw, should I recend or you can still pick it up from linux-next or mailing list?
I can resend tomorrow if needed.
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Quoted 19 lines · Ingo Molnar
Quoted 16 lines · Andy Shevchenko
Quoted 7 lines · tip-bot for Andy Shevchenko
Commit-ID: 0fc8483b698620ea3d8cc6635b54eccc613c23a3 Gitweb: https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc c613c23a3 Author: Andy Shevchenko <[email protected]> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Tue, 13 Feb 2018 17:14:41 +0100As of today I don't see this in linux-next
% git tag --contains
0fc8483b69862
next-20180214
next-20180215
next-20180216
Quoted 5 lines
Quoted 1 line
What happened to this change?
Hm, so it's a real mystery: I merged it, then removed it 1.5 days later without reporting anything. According to the Git log timestamp the removal happened late at night, so maybe it was a tired typo?
Who knows? )
Quoted 2 lines
Anyway, it's a good thing you kept out an eye for this: I re-applied the patch for v4.17 and will let you know if there's any problem in testing.
Actually I got the same warning when tried to do some debug printings with readq() as a parameter.
That's why I have noticed.
Thank you for re-applying!
Signature · 2 lines
With Best Regards, Andy Shevchenko
tip-bot for Andy Shevchenko
merge botx86/io: Define readq()/writeq() to use 64-bit type
Commit-ID: 3d94548927a96f35da57984e3410f8b53757435a Gitweb: https://git.kernel.org/tip/3d94548927a96f35da57984e3410f8b53757435a Author: Andy Shevchenko <[email protected]> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Sat, 31 Mar 2018 11:41:43 +0200
x86/io: Define readq()/writeq() to use 64-bit type
Since non atomic readq() and writeq() were added some of the drivers would like to use it in a manner of:
#include <io-64-nonatomic-lo-hi.h>
...
pr_debug("Debug value of some register: %016llx\n", readq(addr));
However, lo_hi_readq() always returns __u64 data, while readq() on x86_64 defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit on x86_64.
Convert readq() and writeq() on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using either unsigned long long, or u64 type for readq() / writeq(). This change propagates consistency in that sense.
While this is not an issue per se, though if someone wants to address it, the anchor could be the commit
797a796a13df ("asm-generic: architecture independent readq/writeq for 32bit environment")
where non-atomic variants had been introduced.
Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code.
Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis.
--- arch/x86/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/include/asm/io.h +4 -4
@@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", )#ifdef CONFIG_X86_64 -build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a) #define writeq_relaxed(v, a) __writeq(v, a)