On Wed, 31 Jul 2019, Greg Ungerer wrote:

> > 
> > Here's the patch I tested.
> > 
> > diff --git a/arch/m68k/include/asm/atarihw.h
> > b/arch/m68k/include/asm/atarihw.h
> > index 533008262b69..ba1889c1a933 100644
> > --- a/arch/m68k/include/asm/atarihw.h
> > +++ b/arch/m68k/include/asm/atarihw.h
> > @@ -22,7 +22,6 @@
> >  #include <linux/types.h>
> >  #include <asm/bootinfo-atari.h>
> > -#include <asm/raw_io.h>
> >  #include <asm/kmap.h>
> >  extern u_long atari_mch_cookie;
> > diff --git a/arch/m68k/include/asm/macintosh.h
> > b/arch/m68k/include/asm/macintosh.h
> > index d9a08bed4b12..f653b60f2afc 100644
> > --- a/arch/m68k/include/asm/macintosh.h
> > +++ b/arch/m68k/include/asm/macintosh.h
> > @@ -4,6 +4,7 @@
> >  #include <linux/seq_file.h>
> >  #include <linux/interrupt.h>
> > +#include <linux/irq.h>
> >  #include <asm/bootinfo-mac.h>
> > 
> > I built 4 configurations - coldfire (mmu), atari, mac, atari + mac.
> > 
> > It's hard to imagine that removing those extra #defines would be a problem
> > given that doing so doesn't lead to compiler warnings or errors. The atari
> > build booted up okay in aranym.
> 
> Works for me too. I prefer this solution.
> 
> Do you want to resend that patch with commit message and signed-off-by?
> 

Sure, but I would like to understand this problem a bit better first.

I wanted to be able to safely #include <asm/atarihw.h> but this solution 
begs the question, why can't we safely #include <asm/raw_io.h>?

$ git grep -w asm/raw_io.h arch/m68k/
arch/m68k/include/asm/atarihw.h:#include <asm/raw_io.h>
arch/m68k/include/asm/io_mm.h:#include <asm/raw_io.h>
arch/m68k/include/asm/nubus.h:#include <asm/raw_io.h>
arch/m68k/include/asm/q40_master.h:#include <asm/raw_io.h>
arch/m68k/include/asm/vga.h:#include <asm/raw_io.h>
arch/m68k/include/asm/zorro.h:#include <asm/raw_io.h>
$ 

It looks like asm/vga.h has exactly the same redefinition problem that 
asm/atarihw.h has. Apparently it never shows up due to #undef readb etc.
My suspicion is that #undef directives are always unsafe, given the usual 
unpredictable ordering of #include directives.

BTW, I see that asm/io_mm.h conditionally includes asm/atarihw.h, which 
suggests to me that unconditionally including asm/atarihw.h is not 
desirable for some reason (c.f. your original solution).

-- 

> Regards
> Greg
> 
> 

Reply via email to