Hi, Jason, On Fri, Jun 3, 2022 at 10:14 PM WANG Xuerui <kernel@xxxxxxxxxx> wrote: > > On 6/3/22 22:01, Jason A. Donenfeld wrote: > > Hi Arnd, > > > > On Fri, Jun 03, 2022 at 03:55:27PM +0200, Arnd Bergmann wrote: > >> On Fri, Jun 3, 2022 at 3:40 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > >>> On Fri, Jun 03, 2022 at 03:20:39PM +0800, Huacai Chen wrote: > >>>> diff --git a/arch/loongarch/include/asm/timex.h b/arch/loongarch/include/asm/timex.h > >>> "Currently only used on SMP for scheduling" isn't quite correct. It's > >>> also used by random_get_entropy(). And anything else that uses > >>> get_cycles() for, e.g., benchmarking, might use it too. > >>> > >>> You wrote also, "we know that all SMP capable CPUs have cycle counters", > >>> so if I gather from this statement that some !SMP CPUs don't have a > >>> cycle counter, though some do. If that's a correct supposition, then > >>> you may need to rewrite this file to be something like: > >> The file is based on the mips version that deals with a variety of > >> implementations > >> and has the same comment. > >> > >> I assume the loongarch chips all behave the same way here, and won't need > >> a special case for non-SMP. > > Oh good. In that case, the code is fine and I suppose the comment could > > just be removed. > > In addition, the rdtime family of instructions is in fact guaranteed to > be available on LoongArch; LoongArch's subsets all contain them, even > the 32-bit "Primary" subset intended for university teaching -- they > provide the rdtimeh.w and rdtimel.w pair of instructions that access the > same 64-bit counter. So I think the comments are probably just leftovers > from a very early port; the LoongArch development started way before it > was publicized. > > And yes, the comment block re get_cycles usage can be removed altogether. Thanks for catching this; what Arnd and Xuerui said is right, and I agree it would be better to remove the comment. As the PR has already been tagged before your reply, this will get fixed in rc2. Thanks for your review again. Huacai >
