[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