On Monday 21 January 2013, Vineet Gupta wrote:
> On Friday 18 January 2013 09:25 PM, Arnd Bergmann wrote:
> > ...
> So the comment above can be deleted, and we probably need a check in
> ioremap_prot() so that early ioremap bails out if called early - probably using
> slab_is_available()
Ok.
> >> +#include <asm-generic/io.h>
> > I think I commented before that asm-generic/io.h has a number of
> > problems and you should at least override the __raw_{read,write}{b,w,l,q}
> > functions with your own ones using inline assembly.
> >
> > You should also define a non-NULL PCI_IOBASE.
>
> Sorry for missing out on this one - this was indeed suggested in the private
> pre-list review you did. The 64-bit version certainly needs to be wrapped in a irq
> safe block.
>
> However others will be exactly same as generic ones. Given that these routines
> operate on __iomem memory which has to be uncached: either wired in uncached
> address space, or goes via an uncached MMU mapping, IMHO the inline-asm or 'C'
> version won't add any value. We do have uncached LD/ST, I've tried to avoid them
> so far as they have certain micro-architectural quirks and per previous argument
> it seems they would be redundant.
>
> Having said that I might be over-looking something important - so please let me know.
We just moved ARM to use inline assembly versions here, because there were bugs
with some gcc versions and undefined C code in the kernel using 'packed' pointers,
as well as problems in KVM interpreting the memory accessor instructions. I would
definetely recommend doing inline assembly for these on all architectures to spare
you trouble later.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
