[PATCH] powerpc/64s: power4 nap fixup in C
Andreas Schwab
schwab at linux-m68k.org
Tue Mar 30 03:51:51 AEDT 2021
On Mär 29 2021, Andreas Schwab wrote:
> On Mär 29 2021, Christophe Leroy wrote:
>
>> Le 29/03/2021 à 10:33, Benjamin Herrenschmidt a écrit :
>>> On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>>>>
>>>> +static inline void nap_adjust_return(struct pt_regs *regs)
>>>>
>>>> +{
>>>>
>>>> +#ifdef CONFIG_PPC_970_NAP
>>>>
>>>> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
>>>> + /* Can avoid a test-and-clear because NMIs do not call this */
>>>> + clear_thread_local_flags(_TLF_NAPPING);
>>>> + regs->nip = (unsigned long)power4_idle_nap_return;
>>>> + }
>>> Is this a pointer to a function descriptor or the actual code ?
>>>
>>
>> --- a/arch/powerpc/kernel/idle_book3s.S
>> +++ b/arch/powerpc/kernel/idle_book3s.S
>> @@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
>> mtmsrd r7
>> isync
>> b 1b
>> +
>> + .globl power4_idle_nap_return
>> +power4_idle_nap_return:
>> + blr
>> #endif
>
> The problem is not the definition, it is the reference. In C, a
> function symbol always resolves to the address of the descriptor.
Sorry, this is wrong, I have misremembered how function descriptors work
on ppc64. The address is really pointing to the actual code.
Andreas.
--
Andreas Schwab, schwab at linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
More information about the Linuxppc-dev
mailing list