Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH v2 28/76] ARC: I/O and DMA Mappings | Date | Mon, 21 Jan 2013 14:26:26 +0000 |
| |
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
| |