All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 06/10] powerpc/powernv: opal use new opal call entry point if it exists
Date: Wed, 6 May 2020 12:32:02 +0530	[thread overview]
Message-ID: <20200506070202.GC23268@in.ibm.com> (raw)
In-Reply-To: <20200502111914.166578-7-npiggin@gmail.com>

Hello Nicholas,

On Sat, May 02, 2020 at 09:19:10PM +1000, Nicholas Piggin wrote:
> OPAL may advertise new endian-specific entry point which has different
> calling conventions including using the caller's stack, but otherwise
> provides the standard OPAL call API without any changes required to
> the OS.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---

[..snip..]

> index 506b1798081a..32857254d268 100644
> --- a/arch/powerpc/platforms/powernv/opal-call.c
> +++ b/arch/powerpc/platforms/powernv/opal-call.c
> @@ -92,6 +92,18 @@ static s64 __opal_call_trace(s64 a0, s64 a1, s64 a2, s64 a3,
>  #define DO_TRACE false
>  #endif /* CONFIG_TRACEPOINTS */
> 
> +struct opal {
> +	u64 base;
> +	u64 entry;
> +	u64 size;
> +	u64 v4_le_entry;
> +};
> +extern struct opal opal;
> +
> +typedef int64_t (*opal_v4_le_entry_fn)(uint64_t r3, uint64_t r4, uint64_t r5,
> +                               uint64_t r6, uint64_t r7, uint64_t r8,
> +                               uint64_t r9, uint64_t r10);
> +
>  static int64_t opal_call(int64_t a0, int64_t a1, int64_t a2, int64_t a3,
>  	     int64_t a4, int64_t a5, int64_t a6, int64_t a7, int64_t opcode)
>  {
> @@ -99,6 +111,30 @@ static int64_t opal_call(int64_t a0, int64_t a1, int64_t a2, int64_t a3,
>  	unsigned long msr = mfmsr();
>  	bool mmu = (msr & (MSR_IR|MSR_DR));
>  	int64_t ret;
> +	opal_v4_le_entry_fn fn;

fn should be initialized to NULL here to ensure correctness when
kernel is built with CONFIG_CPU_BIG_ENDIAN.

> +
> +	if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
> +		fn = (opal_v4_le_entry_fn)(opal.v4_le_entry);
> +
> +	if (fn) {
> +		if (!mmu) {
> +			BUG_ON(msr & MSR_EE);
> +			ret = fn(opcode, a0, a1, a2, a3, a4, a5, a6);
> +			return ret;
> +		}
> +
> +		local_irq_save(flags);
> +		hard_irq_disable(); /* XXX r13 */
> +		msr &= ~MSR_EE;
> +		mtmsr(msr & ~(MSR_IR|MSR_DR));
> +
> +		ret = fn(opcode, a0, a1, a2, a3, a4, a5, a6);
> +
> +		mtmsr(msr);
> +		local_irq_restore(flags);
> +
> +		return ret;
> +	}
> 
>  	msr &= ~MSR_EE;
> 

--
Thanks and Regards
gautham.

  parent reply	other threads:[~2020-05-06  7:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02 11:19 [RFC PATCH 00/10] OPAL V4 Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 01/10] kallsyms: architecture specific symbol lookups Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 02/10] powerpc/powernv: Wire up OPAL address lookups Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 03/10] powerpc/powernv: Use OPAL_REPORT_TRAP to cope with trap interrupts from OPAL Nicholas Piggin
2020-05-02 14:30   ` kbuild test robot
2020-05-02 11:19 ` [RFC PATCH 04/10] powerpc/powernv: avoid polling in opal_get_chars Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 05/10] powerpc/powernv: Don't translate kernel addresses to real addresses for OPAL Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 06/10] powerpc/powernv: opal use new opal call entry point if it exists Nicholas Piggin
2020-05-02 16:25   ` kbuild test robot
2020-05-06  7:02   ` Gautham R Shenoy [this message]
2020-05-02 11:19 ` [RFC PATCH 07/10] powerpc/powernv: Add OPAL_FIND_VM_AREA API Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 08/10] powerpc/powernv: Set up an mm context to call OPAL in Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 09/10] powerpc/powernv: OPAL V4 OS services Nicholas Piggin
2020-05-02 11:19 ` [RFC PATCH 10/10] powerpc/powernv: OPAL V4 Implement vm_map/unmap service Nicholas Piggin

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=20200506070202.GC23268@in.ibm.com \
    --to=ego@linux.vnet.ibm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.