[PATCH 13/15] ARM: make mach/io.h include optional
H Hartley Sweeten
hartleys at visionengravers.com
Tue Feb 14 12:38:44 EST 2012
On Monday, February 13, 2012 6:07 PM, Arnd Bergmann wrote:
> On Monday 13 February 2012, H Hartley Sweeten wrote:
>>> +#ifdef CONFIG_NEED_MACH_IO_H
>>> #include <mach/io.h>
>>> +#else
>>> +#define __io(a) ({ (void)(a); __typesafe_io(0); })
>>> +#define __mem_pci(a) (a)
>>> +#endif
>>
>> Rob,
>>
>> I compile and boot tested these patches on EP93xxbut did not check them
>> with sparse.
>>
>> Most of the mach/io.h headers you remove in Patch 14/15 have the __io
>> macro defined like:
>>
>> #define __io(a) __typesafe_io(a)
>>
>> Does your change above still keep the __io macro typesafe?
>>
>> They don't appear equivalent to me...
>
> It's not equivalent, but the new version is more correct for most
> platforms because it turns a random pointer dereference into a NULL
> pointer dereference.
>
> If you have none of PCI/ISA/PCMCIA, then inb/outb should never be
> used. Ideally we would undefine __io in that case, which results
> in the inb/outb stuff also not getting defined, but some drivers
> like 8250 serial then fail to build even for systems that only
> use the readl/writel path.
Sorry... I don't quite understand the change here.
__typesafe_io is an inline function in asm/io.h. Most of the mach/io.h
headers simply define __io to be __typesafe_io so they basically get
this:
void __iomem *__io(unsigned long addr)
{
return (void __iomem *)addr;
}
With the change in Rob's patch they will get this:
void __iomem *__io(unsigned long addr)
{
(void)addr;
return (void __iomem *)(0);
}
If you then push these into something like the outb macro you get this:
#define outb(v,p) ({ __iowmb(); __raw_writeb(v,__io(p)); })
Original:
outb(v,p)
{
__iowmb();
__raw_writeb(v, (void __iomem*)p);
}
Rob's change:
outb(v,p)
{
__iowmb();
__raw_writeb(v, /* not sure what happens to the (void)p */ (void __iomem *)0);
}
To me the original one looks more correct. With Rob's change it looks to me like all
the in/out macros end up reading/writing to address 0.
I don't get what's happening in Rob's change. Could you enlighten me?
Regards,
Hartley
More information about the linux-arm-kernel
mailing list