Messages in this thread | | | Date | Tue, 7 Jul 2015 12:27:43 +0200 | Subject | Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases | From | Geert Uytterhoeven <> |
| |
On Tue, Jul 7, 2015 at 12:13 PM, Russell King - ARM Linux <linux@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 -- geert@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
| |