linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Schwab <schwab@linux-m68k.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v14 6/9] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
Date: Sat, 26 Dec 2020 10:49:57 +0100	[thread overview]
Message-ID: <87czywsxq2.fsf@linux-m68k.org> (raw)
In-Reply-To: <20201126131006.2431205-6-mpe__7176.90246399201$1606398872$gmane$org@ellerman.id.au> (Michael Ellerman's message of "Fri, 27 Nov 2020 00:10:03 +1100")

On Nov 27 2020, Michael Ellerman wrote:

> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
> new file mode 100644
> index 000000000000..43dd1dc47c37
> --- /dev/null
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_POWERPC_VDSO_GETTIMEOFDAY_H
> +#define _ASM_POWERPC_VDSO_GETTIMEOFDAY_H
> +
> +#ifdef __ASSEMBLY__
> +
> +#include <asm/ppc_asm.h>
> +
> +/*
> + * The macros sets two stack frames, one for the caller and one for the callee
> + * because there are no requirement for the caller to set a stack frame when
> + * calling VDSO so it may have omitted to set one, especially on PPC64
> + */
> +
> +.macro cvdso_call funct
> +  .cfi_startproc
> +	PPC_STLU	r1, -PPC_MIN_STKFRM(r1)
> +	mflr		r0
> +  .cfi_register lr, r0
> +	PPC_STLU	r1, -PPC_MIN_STKFRM(r1)
> +	PPC_STL		r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> +	get_datapage	r5, r0
> +	addi		r5, r5, VDSO_DATA_OFFSET
> +	bl		DOTSYM(\funct)
> +	PPC_LL		r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> +	cmpwi		r3, 0
> +	mtlr		r0
> +  .cfi_restore lr
> +	addi		r1, r1, 2 * PPC_MIN_STKFRM
> +	crclr		so
> +	beqlr+
> +	crset		so
> +	neg		r3, r3
> +	blr
> +  .cfi_endproc
> +.endm
> +
> +.macro cvdso_call_time funct
> +  .cfi_startproc
> +	PPC_STLU	r1, -PPC_MIN_STKFRM(r1)
> +	mflr		r0
> +  .cfi_register lr, r0
> +	PPC_STLU	r1, -PPC_MIN_STKFRM(r1)
> +	PPC_STL		r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> +	get_datapage	r4, r0
> +	addi		r4, r4, VDSO_DATA_OFFSET
> +	bl		DOTSYM(\funct)
> +	PPC_LL		r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> +	crclr		so
> +	mtlr		r0
> +  .cfi_restore lr
> +	addi		r1, r1, 2 * PPC_MIN_STKFRM
> +	blr
> +  .cfi_endproc
> +.endm
> +
> +#else
> +
> +#include <asm/vdso/timebase.h>
> +#include <asm/barrier.h>
> +#include <asm/unistd.h>
> +#include <uapi/linux/time.h>
> +
> +#define VDSO_HAS_CLOCK_GETRES		1
> +
> +#define VDSO_HAS_TIME			1
> +
> +static __always_inline int do_syscall_2(const unsigned long _r0, const unsigned long _r3,
> +					const unsigned long _r4)
> +{
> +	register long r0 asm("r0") = _r0;
> +	register unsigned long r3 asm("r3") = _r3;
> +	register unsigned long r4 asm("r4") = _r4;
> +	register int ret asm ("r3");
> +
> +	asm volatile(
> +		"       sc\n"
> +		"	bns+	1f\n"
> +		"	neg	%0, %0\n"
> +		"1:\n"
> +	: "=r" (ret), "+r" (r4), "+r" (r0)
> +	: "r" (r3)
> +	: "memory", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "cr0", "ctr");
> +
> +	return ret;
> +}
> +
> +static __always_inline
> +int gettimeofday_fallback(struct __kernel_old_timeval *_tv, struct timezone *_tz)
> +{
> +	return do_syscall_2(__NR_gettimeofday, (unsigned long)_tv, (unsigned long)_tz);
> +}
> +
> +static __always_inline
> +int clock_gettime_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
> +{
> +	return do_syscall_2(__NR_clock_gettime, _clkid, (unsigned long)_ts);

Doesn't that need to be __NR_clock_gettime64 for ppc32?

> +}
> +
> +static __always_inline
> +int clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
> +{
> +	return do_syscall_2(__NR_clock_getres, _clkid, (unsigned long)_ts);

And here __NR_clock_getres_time64?

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:[~2020-12-26  9:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 13:09 [PATCH v14 1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features Michael Ellerman
2020-11-26 13:09 ` [PATCH v14 2/9] powerpc/processor: Move cpu_relax() into asm/vdso/processor.h Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 3/9] powerpc/time: Move timebase functions into new asm/vdso/timebase.h Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 4/9] powerpc/time: Fix mftb()/get_tb() for use with the compat VDSO Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 5/9] powerpc/barrier: Use CONFIG_PPC64 for barrier selection Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 6/9] powerpc/vdso: Prepare for switching VDSO to generic C implementation Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 7/9] powerpc/vdso: Save and restore TOC pointer on PPC64 Michael Ellerman
2020-11-26 13:10 ` [PATCH v14 8/9] powerpc/vdso: Switch VDSO to generic C implementation Michael Ellerman
2020-11-26 13:20   ` Christophe Leroy
2020-11-26 13:10 ` [PATCH v14 9/9] powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32 Michael Ellerman
2020-12-10 11:30 ` [PATCH v14 1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features Michael Ellerman
     [not found] ` <20201126131006.2431205-6-mpe__7176.90246399201$1606398872$gmane$org@ellerman.id.au>
2020-12-26  9:49   ` Andreas Schwab [this message]

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=87czywsxq2.fsf@linux-m68k.org \
    --to=schwab@linux-m68k.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /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).