> -----Original Message----- > From: Wood Scott-B07421 > Sent: Tuesday, January 21, 2014 9:06 AM > To: Wang Dongsheng-B40534 > Cc: b...@kernel.crashing.org; Zhao Chenhui-B35336; an...@enomsg.org; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore > the > core registers > > On Mon, 2014-01-20 at 00:03 -0600, Wang Dongsheng-B40534 wrote: > > > > > > + /* > > > > > > + * Need to save float-point registers if MSR[FP] = 1. > > > > > > + */ > > > > > > + mfmsr r12 > > > > > > + andi. r12, r12, MSR_FP > > > > > > + beq 1f > > > > > > + do_sr_fpr_regs(save) > > > > > > > > > > C code should have already ensured that MSR[FP] is not 1 (and thus the > FP > > > > > context has been saved). > > > > > > > > > > > > > Yes, right. But I mean if the FP still use in core save flow, we need to > save > > > it. > > > > In this process, i don't care what other code do, we need to focus on > > > > not > > > losing > > > > valuable data. > > > > > > It is not allowed to use FP at that point. > > > > > If MSR[FP] not active, that is FP not allowed to use. > > But here is a normal judgment, if MSR[FP] is active, this means that the > floating > > point module is being used. I offer is a function of the interface, we don't > know > > where is the function will be called. Just because we call this function in > the > > context of uncertainty, we need this judgment to ensure that no data is > > lost. > > The whole point of calling enable_kernel_fp() in C code before > suspending is to ensure that the FP state gets saved. If FP is used > after that point it is a bug. If you're worried about such bugs, then > clear MSR[FP] after calling enable_kernel_fp(), rather than adding > redundant state saving. >
enable_kernel_fp() calling in MEM suspend flow. Hibernation is different with MEM suspend, and I'm not sure where will call this interface, so we need to ensure the integrity of the core saving. I don't think this code is *redundant*. I trust that the kernel can keep the FP related operations, that's why a judgment is here. :) Thanks, -Dongsheng _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
