linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the generic-ioremap tree
@ 2019-12-18  2:30 Stephen Rothwell
  2019-12-21  8:32 ` Christoph Hellwig
  2020-01-06  5:02 ` Stephen Rothwell
  0 siblings, 2 replies; 4+ messages in thread
From: Stephen Rothwell @ 2019-12-18  2:30 UTC (permalink / raw)
  To: Andrew Morton, Christoph Hellwig
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/hexagon/include/asm/io.h

between commit:

  1188dd7d3fbd ("remove ioremap_nocache and devm_ioremap_nocache")

from the generic-ioremap tree and commit:

  a632c00ae02c ("hexagon: define ioremap_uc")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/hexagon/include/asm/io.h
index f42d9973e7d6,b0dbc3473172..000000000000
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@@ -172,7 -172,10 +172,8 @@@ static inline void writel(u32 data, vol
  #define writel_relaxed __raw_writel
  
  void __iomem *ioremap(unsigned long phys_addr, unsigned long size);
 -#define ioremap_nocache ioremap
+ #define ioremap_uc(X, Y) ioremap((X), (Y))
  
 -
  #define __raw_writel writel
  
  static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

* Re: linux-next: manual merge of the akpm-current tree with the generic-ioremap tree
  2019-12-18  2:30 linux-next: manual merge of the akpm-current tree with the generic-ioremap tree Stephen Rothwell
@ 2019-12-21  8:32 ` Christoph Hellwig
  2019-12-23 22:01   ` Andrew Morton
  2020-01-06  5:02 ` Stephen Rothwell
  1 sibling, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2019-12-21  8:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Christoph Hellwig, Linux Next Mailing List,
	Linux Kernel Mailing List, Nick Desaulniers

Andrew,

do you plan to send this to Linus for 5.5 to fix the warning from the
new devm_ioremap_uc addition in this cycle?  If so I can rebase the
ioremap tree one more time.

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

* Re: linux-next: manual merge of the akpm-current tree with the generic-ioremap tree
  2019-12-21  8:32 ` Christoph Hellwig
@ 2019-12-23 22:01   ` Andrew Morton
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Morton @ 2019-12-23 22:01 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Nick Desaulniers

On Sat, 21 Dec 2019 09:32:11 +0100 Christoph Hellwig <hch@lst.de> wrote:

> Andrew,
> 
> do you plan to send this to Linus for 5.5 to fix the warning from the
> new devm_ioremap_uc addition in this cycle?  If so I can rebase the
> ioremap tree one more time.

I'm not sure what to do about this because of
https://lore.kernel.org/lkml/CAMuHMdUO=cZMsFx4t_uULNRuwnGLjbRYOJAo7j5gC-iSV3wy5w@mail.gmail.com/

I'd rather just drop the patch.  Can you please take care of it all?  


From: Nick Desaulniers <ndesaulniers@google.com>
Subject: hexagon: define ioremap_uc

Similar to commit 38e45d81d14e ("sparc64: implement ioremap_uc") define
ioremap_uc for hexagon to avoid errors from
-Wimplicit-function-definition.

Link: http://lkml.kernel.org/r/20191209222956.239798-2-ndesaulniers@google.com
Link: https://github.com/ClangBuiltLinux/linux/issues/797
Fixes: e537654b7039 ("lib: devres: add a helper function for ioremap_uc")
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Brian Cain <bcain@codeaurora.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Tuowen Zhao <ztuowen@gmail.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexios Zavras <alexios.zavras@intel.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Will Deacon <will@kernel.org>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/hexagon/include/asm/io.h |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/hexagon/include/asm/io.h~hexagon-define-ioremap_uc
+++ a/arch/hexagon/include/asm/io.h
@@ -173,6 +173,7 @@ static inline void writel(u32 data, vola
 
 void __iomem *ioremap(unsigned long phys_addr, unsigned long size);
 #define ioremap_nocache ioremap
+#define ioremap_uc(X, Y) ioremap((X), (Y))
 
 
 #define __raw_writel writel
_


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

* Re: linux-next: manual merge of the akpm-current tree with the generic-ioremap tree
  2019-12-18  2:30 linux-next: manual merge of the akpm-current tree with the generic-ioremap tree Stephen Rothwell
  2019-12-21  8:32 ` Christoph Hellwig
@ 2020-01-06  5:02 ` Stephen Rothwell
  1 sibling, 0 replies; 4+ messages in thread
From: Stephen Rothwell @ 2020-01-06  5:02 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Hi all,

On Wed, 18 Dec 2019 13:30:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/hexagon/include/asm/io.h
> 
> between commit:
> 
>   1188dd7d3fbd ("remove ioremap_nocache and devm_ioremap_nocache")
> 
> from the generic-ioremap tree and commit:
> 
>   a632c00ae02c ("hexagon: define ioremap_uc")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/hexagon/include/asm/io.h
> index f42d9973e7d6,b0dbc3473172..000000000000
> --- a/arch/hexagon/include/asm/io.h
> +++ b/arch/hexagon/include/asm/io.h
> @@@ -172,7 -172,10 +172,8 @@@ static inline void writel(u32 data, vol
>   #define writel_relaxed __raw_writel
>   
>   void __iomem *ioremap(unsigned long phys_addr, unsigned long size);
>  -#define ioremap_nocache ioremap
> + #define ioremap_uc(X, Y) ioremap((X), (Y))
>   
>  -
>   #define __raw_writel writel
>   
>   static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,

This is now a conflict between Linus' tree and the generic-ioremap tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

end of thread, other threads:[~2020-01-06  5:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-18  2:30 linux-next: manual merge of the akpm-current tree with the generic-ioremap tree Stephen Rothwell
2019-12-21  8:32 ` Christoph Hellwig
2019-12-23 22:01   ` Andrew Morton
2020-01-06  5:02 ` Stephen Rothwell

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