On Tue, Jul 7, 2015 at 12:13 PM, Russell King - ARM Linux <li...@arm.linux.org.uk> wrote: > Another issue is... the use of memcpy()/memset() directly on memory > returned from ioremap*(). The pmem driver does this. This fails sparse > checks. However, years ago, x86 invented the memcpy_fromio()/memcpy_toio() > memset_io() functions, which took a __iomem pointer (which /presumably/ > means they're supposed to operate on the memory associated with an > ioremap'd region.) > > Should these functions always be used for mappings via ioremap*(), and > the standard memcpy()/memset() be avoided? To me, that sounds like a > very good thing, because that gives us more control over the > implementation of the functions used to access ioremap'd regions, > and the arch can decide to prevent GCC inlining its own memset() or > memcpy() code if desired.
Yes they should. Not doing that is a typical portability bug (works on x86, not everywhere). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/