On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang <xlp...@126.com> wrote: > From: Xunlei Pang <pang.xun...@linaro.org> > > As part of addressing the "y2038 problem" for in-kernel uses, > convert update_persistent_clock() to update_persistent_clock64(), > read_persistent_clock() to read_persistent_clock64() using > timespec64 for MN10300.
The arch changes look ok. > Add the common weak version of update_persistent_clock() to make > the compiler happy, since we don't have any update_persistent_clock() > defined for MN10300 after converting it to update_persistent_clock64(). So it wasn't immediately obvious why this was needed (compiler unhappiness isn't really a good explanation). Looking at it, it seems that the weak update_persistent_clock64() wants a update_persistent_clock() call to exist (which probably should have been added when the weak update_persistent_clock64 was added). So it looks like even if the arch defines a update_persistent_clock64(), the weak one still throws a undefined symbol compiler error, right? The weak update_persistent_clock() bit should probably be added in a separate patch, since its not really tied to this arch change (really any arch that switches to update_persistent_clock64 would have this issue, no?). thanks -john -- 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/
