linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Schwab <schwab@linux-m68k.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: linuxppc-dev@lists.ozlabs.org, Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH] powerpc/64s: power4 nap fixup in C
Date: Mon, 29 Mar 2021 13:56:28 +0200	[thread overview]
Message-ID: <87czvikwb7.fsf@igel.home> (raw)
In-Reply-To: <236a67a4-1609-5fec-3c68-41db02cd1a4c__18973.8760514714$1617008745$gmane$org@csgroup.eu> (Christophe Leroy's message of "Mon, 29 Mar 2021 11:04:52 +0200")

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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

  parent reply	other threads:[~2021-03-29 11:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12  1:20 [PATCH] powerpc/64s: power4 nap fixup in C Nicholas Piggin
2021-03-16  7:16 ` Christophe Leroy
2021-03-16  8:11   ` Nicholas Piggin
2021-03-29  4:40 ` Michael Ellerman
2021-03-29  8:33 ` Benjamin Herrenschmidt
2021-03-29  9:04   ` Christophe Leroy
     [not found]   ` <236a67a4-1609-5fec-3c68-41db02cd1a4c__18973.8760514714$1617008745$gmane$org@csgroup.eu>
2021-03-29 11:56     ` Andreas Schwab [this message]
     [not found]     ` <87czvikwb7.fsf__13924.9042653077$1617019017$gmane$org@igel.home>
2021-03-29 16:51       ` Andreas Schwab
     [not found] ` <87y2e6fu7v.fsf__9754.75274478725$1616992871$gmane$org@mpe.ellerman.id.au>
2021-03-29 15:30   ` Andreas Schwab
     [not found]   ` <87v99aj7tr.fsf__47134.2879392736$1617031867$gmane$org@igel.home>
2021-03-29 16:23     ` Andreas Schwab
2021-04-01  7:36       ` Nicholas Piggin
2021-04-05 12:56         ` Nicholas Piggin
2021-04-05 16:40           ` Andreas Schwab
2021-04-06  2:45             ` Nicholas Piggin
2021-04-10 14:28 ` Michael Ellerman
2021-04-19  5:16   ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czvikwb7.fsf@igel.home \
    --to=schwab@linux-m68k.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).