On Sat, Jul 04, 2015 at 06:54:40AM -0700, Dan Williams wrote: > On Fri, Jul 3, 2015 at 11:17 AM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: > > I have no idea why its not picking up asm-generic ioremap_uc() for x86, > > x86 does not use "include/asm-generic/io.h". That's a helper-include > for archs that want to use it, but it's incomplete, see the patch > referenced below... Ah it includes iomap.h not io.h odd... > > although this is the right thing to do the guard should not work as we never > > define ioremap_uc() as a macro but we do as an exported symbol. The way > > archs do their ioremap calls is they define externs and then they include > > asm-generic to pick up the things they don't define. In the extern calls > > for ioremap_uc() we never add a define there. Adding a simple one line > > #define right after the extern declaration to itself should suffice to > > fix paranoia but curious why this does work as-is right now. > > > > I'd like review and consensus from other architecture folks if this is > > the Right Thing To Do (TM) and if it is decide how we want to fix this. > > For instance my preference would be to just add this fix as-is after > > we've figured out the guard thing above, and then define these variants > > in the documentation on the asm-generic file as safe to not have, and > > safe to map to the default ioremap call. If you don't have a safe call > > like this we should set out different expectations, for instance having > > it depend on Kconfig symbol and then drivers depend on it, archs then > > implement the symbols and can HAVE_ARCH_FOO. If everyone agrees with > > this then there is quite a bit of cleanup possible as tons of archs do > > tons of their own variant mapping definitions. > > We're also discussing this issue in the patch here: > > https://lkml.org/lkml/2015/6/22/98 > "[PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases": Great, you've done all the exact work I expected we needed to do ;) > Russell mentioned wanting to fix up ioremap_wt() for ARM [1], after > which I would look to re-spin this patch with the interface proposed > by Christoph [2]. > > [1]: https://lkml.org/lkml/2015/7/1/125 > [2]: https://lkml.org/lkml/2015/6/22/391 OK thanks I guess I'll jump in there as I have some feedback. Luis -- 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
