LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type
@ 2018-01-19 14:33 Andy Shevchenko
  2018-01-23  0:32 ` Mehta, Sohil
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Andy Shevchenko @ 2018-01-19 14:33 UTC (permalink / raw)
  To: Thomas Gleixner, H. Peter Anvin, Ingo Molnar, x86, linux-kernel
  Cc: Andy Shevchenko, Hitoshi Mitake, Mehta, Sohil

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.

Reported-by: lkp <lkp@intel.com>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: "Mehta, Sohil" <sohil.mehta@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 arch/x86/include/asm/io.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 95e948627fd0..365f5ba9222b 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -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)
-- 
2.15.1

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-19 14:33 [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type Andy Shevchenko
@ 2018-01-23  0:32 ` Mehta, Sohil
  2018-01-23  0:46   ` hpa
  2018-02-13 16:58 ` [tip:x86/urgent] " tip-bot for Andy Shevchenko
  2018-03-31 10:20 ` [tip:x86/platform] " tip-bot for Andy Shevchenko
  2 siblings, 1 reply; 16+ messages in thread
From: Mehta, Sohil @ 2018-01-23  0:32 UTC (permalink / raw)
  To: tglx, hpa, andriy.shevchenko, mingo, x86, linux-kernel; +Cc: mitake

On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote:
> 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.
> 
> Reported-by: lkp <lkp@intel.com>
> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
> Cc: "Mehta, Sohil" <sohil.mehta@intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  arch/x86/include/asm/io.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 95e948627fd0..365f5ba9222b 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -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)

The patch works for me:

Tested-by: Sohil Mehta <sohil.mehta@intel.com>

Sohil

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-23  0:32 ` Mehta, Sohil
@ 2018-01-23  0:46   ` hpa
  2018-01-23  8:32     ` Andy Shevchenko
  0 siblings, 1 reply; 16+ messages in thread
From: hpa @ 2018-01-23  0:46 UTC (permalink / raw)
  To: Mehta, Sohil, tglx, andriy.shevchenko, mingo, x86, linux-kernel; +Cc: mitake

On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil" <sohil.mehta@intel.com> wrote:
>On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote:
>> 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.
>> 
>> Reported-by: lkp <lkp@intel.com>
>> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
>> Cc: "Mehta, Sohil" <sohil.mehta@intel.com>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> ---
>>  arch/x86/include/asm/io.h | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
>> index 95e948627fd0..365f5ba9222b 100644
>> --- a/arch/x86/include/asm/io.h
>> +++ b/arch/x86/include/asm/io.h
>> @@ -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)
>
>The patch works for me:
>
>Tested-by: Sohil Mehta <sohil.mehta@intel.com>
>
>Sohil

Wouldn't simply u64 make more sense?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-23  0:46   ` hpa
@ 2018-01-23  8:32     ` Andy Shevchenko
  2018-01-29 15:45       ` Andy Shevchenko
  0 siblings, 1 reply; 16+ messages in thread
From: Andy Shevchenko @ 2018-01-23  8:32 UTC (permalink / raw)
  To: hpa, Mehta, Sohil, tglx, mingo, x86, linux-kernel; +Cc: mitake

On Mon, 2018-01-22 at 16:46 -0800, hpa@zytor.com wrote:
> On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil" <sohil.mehta@intel.
> com> wrote:
> > On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote:

> > > +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:
> > 
> > Tested-by: Sohil Mehta <sohil.mehta@intel.com>
> > 

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

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-23  8:32     ` Andy Shevchenko
@ 2018-01-29 15:45       ` Andy Shevchenko
  0 siblings, 0 replies; 16+ messages in thread
From: Andy Shevchenko @ 2018-01-29 15:45 UTC (permalink / raw)
  To: hpa, Mehta, Sohil, tglx, mingo, x86, linux-kernel; +Cc: mitake

On Tue, 2018-01-23 at 10:32 +0200, Andy Shevchenko wrote:
> On Mon, 2018-01-22 at 16:46 -0800, hpa@zytor.com wrote:
> > On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil"
> > <sohil.mehta@intel.com> wrote:
> > > On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote:
> > > > +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", )

> > > The patch works for me:
> > > Tested-by: Sohil Mehta <sohil.mehta@intel.com>

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

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-19 14:33 [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type Andy Shevchenko
  2018-01-23  0:32 ` Mehta, Sohil
@ 2018-02-13 16:58 ` tip-bot for Andy Shevchenko
  2018-03-27 15:10   ` Andy Shevchenko
  2018-03-31 10:20 ` [tip:x86/platform] " tip-bot for Andy Shevchenko
  2 siblings, 1 reply; 16+ messages in thread
From: tip-bot for Andy Shevchenko @ 2018-02-13 16:58 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: andriy.shevchenko, peterz, hpa, mingo, tglx, linux-kernel,
	torvalds, lkp, sohil.mehta, mitake

Commit-ID:  0fc8483b698620ea3d8cc6635b54eccc613c23a3
Gitweb:     https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54eccc613c23a3
Author:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
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.

Reported-by: lkp <lkp@intel.com>
Tested-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mehta, Sohil <sohil.mehta@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180119143322.16555-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/include/asm/io.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 95e9486..365f5ba 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -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)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-02-13 16:58 ` [tip:x86/urgent] " tip-bot for Andy Shevchenko
@ 2018-03-27 15:10   ` Andy Shevchenko
  2018-03-31 10:19     ` Ingo Molnar
  0 siblings, 1 reply; 16+ messages in thread
From: Andy Shevchenko @ 2018-03-27 15:10 UTC (permalink / raw)
  To: hpa, peterz, tglx, mingo, torvalds, linux-kernel, lkp,
	sohil.mehta, mitake, linux-tip-commits

On Tue, 2018-02-13 at 08:58 -0800, tip-bot for Andy Shevchenko wrote:
> Commit-ID:  0fc8483b698620ea3d8cc6635b54eccc613c23a3
> Gitweb:     https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc
> c613c23a3
> Author:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200
> Committer:  Ingo Molnar <mingo@kernel.org>
> 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?

> 
> 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.
> 
> Reported-by: lkp <lkp@intel.com>
> Tested-by: Sohil Mehta <sohil.mehta@intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mehta, Sohil <sohil.mehta@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: http://lkml.kernel.org/r/20180119143322.16555-1-andriy.shevchenk
> o@linux.intel.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>  arch/x86/include/asm/io.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 95e9486..365f5ba 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -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)

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-27 15:10   ` Andy Shevchenko
@ 2018-03-31 10:19     ` Ingo Molnar
  2018-03-31 10:22       ` Ingo Molnar
  2018-03-31 12:05       ` Andy Shevchenko
  0 siblings, 2 replies; 16+ messages in thread
From: Ingo Molnar @ 2018-03-31 10:19 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: hpa, peterz, tglx, torvalds, linux-kernel, lkp, sohil.mehta,
	mitake, linux-tip-commits


* Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Tue, 2018-02-13 at 08:58 -0800, tip-bot for Andy Shevchenko wrote:
> > Commit-ID:  0fc8483b698620ea3d8cc6635b54eccc613c23a3
> > Gitweb:     https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc
> > c613c23a3
> > Author:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200
> > Committer:  Ingo Molnar <mingo@kernel.org>
> > 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?

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [tip:x86/platform] x86/io: Define readq()/writeq() to use 64-bit type
  2018-01-19 14:33 [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type Andy Shevchenko
  2018-01-23  0:32 ` Mehta, Sohil
  2018-02-13 16:58 ` [tip:x86/urgent] " tip-bot for Andy Shevchenko
@ 2018-03-31 10:20 ` tip-bot for Andy Shevchenko
  2 siblings, 0 replies; 16+ messages in thread
From: tip-bot for Andy Shevchenko @ 2018-03-31 10:20 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: sohil.mehta, lkp, hpa, tglx, mitake, peterz, torvalds,
	linux-kernel, mingo, andriy.shevchenko

Commit-ID:  3d94548927a96f35da57984e3410f8b53757435a
Gitweb:     https://git.kernel.org/tip/3d94548927a96f35da57984e3410f8b53757435a
Author:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
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.

Reported-by: lkp <lkp@intel.com>
Tested-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mehta, Sohil <sohil.mehta@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180119143322.16555-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/include/asm/io.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 95e948627fd0..365f5ba9222b 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -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)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 10:19     ` Ingo Molnar
@ 2018-03-31 10:22       ` Ingo Molnar
  2018-03-31 12:06         ` Andy Shevchenko
  2018-03-31 12:05       ` Andy Shevchenko
  1 sibling, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2018-03-31 10:22 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: hpa, peterz, tglx, torvalds, linux-kernel, lkp, sohil.mehta,
	mitake, linux-tip-commits


* Ingo Molnar <mingo@kernel.org> wrote:

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 10:19     ` Ingo Molnar
  2018-03-31 10:22       ` Ingo Molnar
@ 2018-03-31 12:05       ` Andy Shevchenko
  1 sibling, 0 replies; 16+ messages in thread
From: Andy Shevchenko @ 2018-03-31 12:05 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andy Shevchenko, H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits

On Sat, Mar 31, 2018 at 1:19 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
>> On Tue, 2018-02-13 at 08:58 -0800, tip-bot for Andy Shevchenko wrote:
>> > Commit-ID:  0fc8483b698620ea3d8cc6635b54eccc613c23a3
>> > Gitweb:     https://git.kernel.org/tip/0fc8483b698620ea3d8cc6635b54ecc
>> > c613c23a3
>> > Author:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> > AuthorDate: Fri, 19 Jan 2018 16:33:22 +0200
>> > Committer:  Ingo Molnar <mingo@kernel.org>
>> > 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?
>
> 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? )

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

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 10:22       ` Ingo Molnar
@ 2018-03-31 12:06         ` Andy Shevchenko
  2018-03-31 12:15           ` Andy Shevchenko
  0 siblings, 1 reply; 16+ messages in thread
From: Andy Shevchenko @ 2018-03-31 12:06 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andy Shevchenko, H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits

On Sat, Mar 31, 2018 at 1:22 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
>> > 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?
>>
>> 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.

Ah, yes. This one I fixed.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 12:06         ` Andy Shevchenko
@ 2018-03-31 12:15           ` Andy Shevchenko
  2018-03-31 18:45             ` Ingo Molnar
  0 siblings, 1 reply; 16+ messages in thread
From: Andy Shevchenko @ 2018-03-31 12:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andy Shevchenko, H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits

On Sat, Mar 31, 2018 at 3:06 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Sat, Mar 31, 2018 at 1:22 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Ingo Molnar <mingo@kernel.org> 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.

https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 12:15           ` Andy Shevchenko
@ 2018-03-31 18:45             ` Ingo Molnar
  2018-04-02 14:55               ` Andy Shevchenko
  2018-04-24 16:51               ` Andy Shevchenko
  0 siblings, 2 replies; 16+ messages in thread
From: Ingo Molnar @ 2018-03-31 18:45 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Andy Shevchenko, H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits


* Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Sat, Mar 31, 2018 at 3:06 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Sat, Mar 31, 2018 at 1:22 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >> * Ingo Molnar <mingo@kernel.org> 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.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 18:45             ` Ingo Molnar
@ 2018-04-02 14:55               ` Andy Shevchenko
  2018-04-24 16:51               ` Andy Shevchenko
  1 sibling, 0 replies; 16+ messages in thread
From: Andy Shevchenko @ 2018-04-02 14:55 UTC (permalink / raw)
  To: Ingo Molnar, Andy Shevchenko
  Cc: H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits

On Sat, 2018-03-31 at 20:45 +0200, Ingo Molnar wrote:
> * Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> 
> > On Sat, Mar 31, 2018 at 3:06 PM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Sat, Mar 31, 2018 at 1:22 PM, Ingo Molnar <mingo@kernel.org>
> > > wrote:
> > > > * Ingo Molnar <mingo@kernel.org> 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.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit
> > /?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9
> 
> 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?

Sure. Thanks!

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [tip:x86/urgent] x86/io: Define readq()/writeq() to use 64-bit type
  2018-03-31 18:45             ` Ingo Molnar
  2018-04-02 14:55               ` Andy Shevchenko
@ 2018-04-24 16:51               ` Andy Shevchenko
  1 sibling, 0 replies; 16+ messages in thread
From: Andy Shevchenko @ 2018-04-24 16:51 UTC (permalink / raw)
  To: Ingo Molnar, Andy Shevchenko
  Cc: H. Peter Anvin, Peter Zijlstra (Intel),
	Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	kbuild test robot, sohil.mehta, mitake, linux-tip-commits

On Sat, 2018-03-31 at 20:45 +0200, Ingo Molnar wrote:
> * Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> 
> > On Sat, Mar 31, 2018 at 3:06 PM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Sat, Mar 31, 2018 at 1:22 PM, Ingo Molnar <mingo@kernel.org>
> > > wrote:
> > > > * Ingo Molnar <mingo@kernel.org> 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.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit
> > /?h=for-next&id=71591d1280e5ef02c2af2ffb9801d0c842973be9
> 
> 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?

Btw, should I recend or you can still pick it up from linux-next or
mailing list?

I can resend tomorrow if needed.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2018-04-24 16:51 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-19 14:33 [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type Andy Shevchenko
2018-01-23  0:32 ` Mehta, Sohil
2018-01-23  0:46   ` hpa
2018-01-23  8:32     ` Andy Shevchenko
2018-01-29 15:45       ` Andy Shevchenko
2018-02-13 16:58 ` [tip:x86/urgent] " tip-bot for Andy Shevchenko
2018-03-27 15:10   ` Andy Shevchenko
2018-03-31 10:19     ` Ingo Molnar
2018-03-31 10:22       ` Ingo Molnar
2018-03-31 12:06         ` Andy Shevchenko
2018-03-31 12:15           ` Andy Shevchenko
2018-03-31 18:45             ` Ingo Molnar
2018-04-02 14:55               ` Andy Shevchenko
2018-04-24 16:51               ` Andy Shevchenko
2018-03-31 12:05       ` Andy Shevchenko
2018-03-31 10:20 ` [tip:x86/platform] " tip-bot for Andy Shevchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).