* [PULL 2/3] Renesas driver updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 12:03 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190802120355.1430-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v5.4-tag1
for you to fetch changes up to 0ed0eb0171d7c19310d9f7b06a6dee82a4fb8ab6:
soc: renesas: rcar-sysc: Use [] to denote a flexible array member (2019-07-29 15:36:56 +0200)
----------------------------------------------------------------
Renesas driver updates for v5.4
- Fix a flexible array member definition in the R-Car SYSC driver.
----------------------------------------------------------------
Geert Uytterhoeven (1):
soc: renesas: rcar-sysc: Use [] to denote a flexible array member
drivers/soc/renesas/rcar-sysc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 0/3] Renesas SoC updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 12:03 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
Hi arm-soc folks,
This is my first pull request for the inclusion of Renesas SoC updates
for v5.4. As this is also my first pull request for arm-soc, I wanted
to start with something small. You can expect more later.
It consists of 3 parts:
[PULL 1/3] Renesas ARM64 DT updates for v5.4
- CAN support for the HiHope RZ/G2E board,
- BT and WLAN support for the HiHope RZ/G2[MN] boards,
- Sound support for RZ/G2M,
- Sort nodes in various SoC and board DTSes,
- Small fixes and improvements.
[PULL 2/3] Renesas driver updates for v5.4
- Fix a flexible array member definition in the R-Car SYSC driver.
[PULL 3/3] Renesas DT binding updates for v5.4
- RZ/G2 updates for the R-Car CAN and CANFD DT bindings.
For now I more or less followed Simon's way of structuring the branches,
but I'm open for change. Hence if you have any comments, or suggestions
for improving the workflow, please let me know.
Thanks for pulling, and for your comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/imx: Drop unused imx-ipuv3-crtc.o build
From: Philipp Zabel @ 2019-08-02 12:03 UTC (permalink / raw)
To: Fabio Estevam, Guido Günther
Cc: Daniel Vetter, David Airlie, Sascha Hauer, linux-kernel,
DRI mailing list, NXP Linux Team, Pengutronix Kernel Team,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5BipmSPR1jz3ov8ESSJPsHMViMw42di-WKOdqhyONLK6Q@mail.gmail.com>
Hi Guido, Fabio,
On Fri, 2019-08-02 at 08:03 -0300, Fabio Estevam wrote:
> Hi Guido,
>
> Good catch!
>
> On Fri, Aug 2, 2019 at 7:55 AM Guido Günther <agx@sigxcpu.org> wrote:
> >
> > Since
> >
> > commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module")
> >
> > imx-ipuv3-crtc.o is built via imxdrm-objs. So there's no need to keep an
>
> Actually, it is ipuv3-crtc.o that is built via imxdrm-objs, not
> imx-ipuv3-crtc.o.
>
> Apart from that:
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Thank you, applied to imx-drm/next with Fabio's R-b, and added Fixes:
tag, and the commit message changed as follows:
drm/imx: Drop unused imx-ipuv3-crtc.o build
Since
commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module")
the former contents of imx-ipuv3-crtc.o are built via imxdrm-objs. So
there's no need to keep an extra entry with a non existing config value
(CONFIG_DRM_IMX_IPUV3).
Fixes: 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
no action necessary if you agree, otherwise just send a v2 and I'll
replace it.
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kvm-unit-tests: psci_cpu_on_test FAILed
From: Andrew Jones @ 2019-08-02 11:32 UTC (permalink / raw)
To: Zenghui Yu
Cc: kvm, suzuki.poulose, Marc Zyngier, James Morse, linux-arm-kernel,
Wanghaibin (D), kvmarm, julien.thierry.kdev
In-Reply-To: <3ddf8766-6f02-b655-1b80-d8a7fd016509@huawei.com>
On Fri, Aug 02, 2019 at 06:56:51PM +0800, Zenghui Yu wrote:
> Hi folks,
>
> Running kvm-unit-tests with Linux 5.3.0-rc2 on Kunpeng 920, we will get
> the following fail info:
>
> [...]
> FAIL psci (4 tests, 1 unexpected failures)
> [...]
> and
> [...]
> INFO: unexpected cpu_on return value: caller=CPU9, ret=-2
> FAIL: cpu-on
> SUMMARY: 4 tests, 1 unexpected failures
>
>
> I think this is an issue had been fixed once by commit 6c7a5dce22b3
> ("KVM: arm/arm64: fix races in kvm_psci_vcpu_on"), which makes use of
> kvm->lock mutex to fix the race between two PSCI_CPU_ON calls - one
> does reset on the MPIDR register whilst another reads it.
>
> But commit 358b28f09f0 ("arm/arm64: KVM: Allow a VCPU to fully reset
> itself") later moves the reset work into check_vcpu_requests(), by
> making a KVM_REQ_VCPU_RESET request in PSCI code. Thus the reset work
> has not been protected by kvm->lock mutex anymore, and the race shows up
> again...
>
> Do we need a fix for this issue? At least achieve a mutex execution
> between the reset of MPIDR and kvm_mpidr_to_vcpu()?
>
>
I noticed this too, but I put it pretty low on my TODO because it's a
safe failure (no host crash, just an unexpected PSCI_RET_INVALID_PARAMS
gets returned because the valid MPIDR doesn't look valid for a moment.)
Also, the test is quite pathological, especially when the host has many
CPUs, so I wouldn't expect this to show up on a sane guest. I agree
it would be nice to get it fixed eventually though.
Thanks,
drew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets
From: Arnd Bergmann @ 2019-08-02 11:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andrew Lunn, LINUXWATCHDOG, LKML, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Gregory Clement, USB list, Russell King,
Vladimir Zapolskiy, linux-gpio, soc, netdev, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Lee Jones,
Linus Walleij, arm-soc, Sebastian Hesselbarth
In-Reply-To: <CAMpxmJWFfT_vrDas2fzW5tnxskk9kmgHQpGnGQ-_C20UaS_jhA@mail.gmail.com>
On Fri, Aug 2, 2019 at 9:10 AM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> > -#include <mach/hardware.h>
> > -#include <mach/platform.h>
> > +#define _GPREG(x) (x)
>
> What purpose does this macro serve?
>
> >
> > #define LPC32XX_GPIO_P3_INP_STATE _GPREG(0x000)
> > #define LPC32XX_GPIO_P3_OUTP_SET _GPREG(0x004)
In the existing code base, this macro converts a register offset to
an __iomem pointer for a gpio register. I changed the definition of the
macro here to keep the number of changes down, but I it's just
as easy to remove it if you prefer.
> > @@ -167,14 +166,26 @@ struct lpc32xx_gpio_chip {
> > struct gpio_regs *gpio_grp;
> > };
> >
> > +void __iomem *gpio_reg_base;
>
> Any reason why this can't be made part of struct lpc32xx_gpio_chip?
It could be, but it's the same for each instance, and not known until
probe() time, so the same pointer would need to be copied into each
instance that is otherwise read-only.
Let me know if you'd prefer me to rework these two things or leave
them as they are.
> > +static inline u32 gpreg_read(unsigned long offset)
>
> Here and elsewhere: could you please keep the lpc32xx_gpio prefix for
> all symbols?
Sure.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 7/8] arm64/sve: Don't disable SVE on syscalls return
From: Julien Grall @ 2019-08-02 11:06 UTC (permalink / raw)
To: Catalin Marinas, Dave Martin
Cc: Anton.Kirilov, will.deacon, oleg, zhang.lei, alex.bennee,
linux-arm-kernel, Daniel.Kiss
In-Reply-To: <20190704141559.GA51773@arrakis.emea.arm.com>
Hi Catalin,
On 04/07/2019 15:15, Catalin Marinas wrote:
> On Fri, Jun 21, 2019 at 04:33:16PM +0100, Dave P Martin wrote:
>> On Thu, Jun 13, 2019 at 05:16:55PM +0100, Julien Grall wrote:
>>> Per the syscalls ABI, SVE registers will be unknown after a syscalls. In
>>
>> This patch is quite hard to understand, though this is more down to the
>> code being modified than the patch itself. So, I may ask some stupid
>> questions...
>>
>> In particular, we now have up to 8 task states (all the combinations of
>> TIF_FOREIGN_FPSTATE, TIF_SVE and TIF_SVE_NEEDS_FLUSH). Sketching out
>> the state machine and highlighting any states that we consider invalid
>> may be a useful exercise, but I've not attempted that yes.
>
> We definitely need a state machine sketched out (and a formal model as I
> can't really get all of it in my head at once). I don't fully understand
> the need for a new TIF_SVE_NEEDS_FLUSH. Maybe it becomes obvious if we
> had a state machine description.
Dave and I drafted a state machine on a whiteboard recently. I will clean it up
and send it on the ML. But I am not sure the state machine will help to
understand the approach :/.
I realize that I didn't explain why I chose this approach over another one. See
more below.
>
> So, we currently have (IIUC):
>
> TIF_SVE - tells us whether the user space can access SVE registers
> without a fault (doesn't CPACR_EL1 tell us this already on kernel entry?
> I guess we'd need to store it in a TIF flag anyway for switch_to). The
That's correct CPACR_EL1 will tell us on entry whether SVE has been enabled or
not. But as you pointed out we need to save on context switch but we may also
disable/enable it via ptrace.
> implications of TIF_SVE on kernel entry is that the SVE state could have
> been touched by the user. If entering via syscall, we discard this state
> in sve_user_discard().
>
> TIF_FOREIGN_FPSTATE - tells us whether the hardware state is out of sync
> with the current thread.
Note that in this case, TIF_SVE will indicate where the context has been saved
(fpsimd_state vs sve_state).
>
> For flushing the SVE state on return from syscall, can we not handle
> this entirely in el0_svc_handler while enabling the SVE access at the
> same time to avoid a subsequent trap? We need to know whether the SVE
> state is valid when we do the context switching but we have TIF_SVE for
> this, cleared on syscall entry but can be set again on return from
> syscall if we enable access in CPACR_EL1 (sve_user_enable()).
If we were to handle it in el0_svc_handler(), we would need to do a similar job
as fpsimd_restore_current_state().
Indeed, the task may have been switched out (when using PREEMPT and PREEMPT_RT).
Above you suggested to clear TIF_SVE on syscall entry, so the state would be
saved in fpsimd_state. We would need to convert the state back to SVE. Ideally,
this should be done in hardware (see patch #6) as this is likely going to be
faster than the software version (see fpsimd_to_sve()). This means the state
would need to be loaded by el0_svc_handler().
Furthermore, handling everything in el0_svc_handler() means that you are mostly
optimizing for fully preemptible kernel (PREEMPT_RT) and preemptible kernel
(PREEMPT). Although, you have the risk to get the kernel preempted after you
return from the el0_svc_handler() and before you return to userspace. So you
would end up to save the full SVE context (even the zeroed bits) which takes
longer than just saving the first 128-bits. I will admit, I haven't really
looked how often this condition can happen.
For voluntary preemptible kernel, they will suffer the same problem when as the
PREEMPT_RT and PREEMPT when rescheduled in do_notify_resume().
So it feels to me that do_notify_resume() is a better fit to handle the flush
(i.e zeroing all SVE state but the first 128-bits of each vector). This would
have the advantage to use the optimize other places (such as the trap to enable
SVE as done by patch #8).
Handling in do_notify_resume() will require an extra flag because we need to
know when to flush the SVE state.
To summarize, el0_svc_handler() is a possibility but result to leave some cases
unoptimized. I don't have any numbers to back this yet, so I don't know whether
this is a major concerns.
>
> It probably needs some more thinking on signal handling.
The signal handling is quite tricky in all the cases :). We need to ensure the
SVE state is not flushed.
Cheers,
--
Julien Grall
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/imx: Drop unused imx-ipuv3-crtc.o build
From: Fabio Estevam @ 2019-08-02 11:03 UTC (permalink / raw)
To: Guido Günther
Cc: Philipp Zabel, David Airlie, Sascha Hauer, linux-kernel,
DRI mailing list, NXP Linux Team, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <e5484fa33bffec220fd0590b502a962da17c9c72.1564743270.git.agx@sigxcpu.org>
Hi Guido,
Good catch!
On Fri, Aug 2, 2019 at 7:55 AM Guido Günther <agx@sigxcpu.org> wrote:
>
> Since
>
> commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module")
>
> imx-ipuv3-crtc.o is built via imxdrm-objs. So there's no need to keep an
Actually, it is ipuv3-crtc.o that is built via imxdrm-objs, not
imx-ipuv3-crtc.o.
Apart from that:
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* kvm-unit-tests: psci_cpu_on_test FAILed
From: Zenghui Yu @ 2019-08-02 10:56 UTC (permalink / raw)
To: Marc Zyngier, drjones, James Morse, julien.thierry.kdev,
suzuki.poulose
Cc: linux-arm-kernel, Wanghaibin (D), kvmarm, kvm
Hi folks,
Running kvm-unit-tests with Linux 5.3.0-rc2 on Kunpeng 920, we will get
the following fail info:
[...]
FAIL psci (4 tests, 1 unexpected failures)
[...]
and
[...]
INFO: unexpected cpu_on return value: caller=CPU9, ret=-2
FAIL: cpu-on
SUMMARY: 4 tests, 1 unexpected failures
I think this is an issue had been fixed once by commit 6c7a5dce22b3
("KVM: arm/arm64: fix races in kvm_psci_vcpu_on"), which makes use of
kvm->lock mutex to fix the race between two PSCI_CPU_ON calls - one
does reset on the MPIDR register whilst another reads it.
But commit 358b28f09f0 ("arm/arm64: KVM: Allow a VCPU to fully reset
itself") later moves the reset work into check_vcpu_requests(), by
making a KVM_REQ_VCPU_RESET request in PSCI code. Thus the reset work
has not been protected by kvm->lock mutex anymore, and the race shows up
again...
Do we need a fix for this issue? At least achieve a mutex execution
between the reset of MPIDR and kvm_mpidr_to_vcpu()?
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/imx: Drop unused imx-ipuv3-crtc.o build
From: Guido Günther @ 2019-08-02 10:55 UTC (permalink / raw)
To: Philipp Zabel, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, dri-devel, linux-arm-kernel, linux-kernel
Since
commit 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one module")
imx-ipuv3-crtc.o is built via imxdrm-objs. So there's no need to keep an
extra entry with a non existing config value (CONFIG_DRM_IMX_IPUV3).
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
drivers/gpu/drm/imx/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index ab6c83caceb7..21cdcc2faabc 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -8,5 +8,4 @@ obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
-obj-$(CONFIG_DRM_IMX_IPUV3) += imx-ipuv3-crtc.o
obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 5/6] coresight: etm4x: save/restore state across CPU low power states
From: Suzuki K Poulose @ 2019-08-02 10:54 UTC (permalink / raw)
To: andrew.murray, mathieu.poirier, alexander.shishkin
Cc: Al.Grant, coresight, leo.yan, Sudeep.Holla, linux-arm-kernel,
mike.leach
In-Reply-To: <20190730125157.884-6-andrew.murray@arm.com>
On 30/07/2019 13:51, Andrew Murray wrote:
> Some hardware will ignore bit TRCPDCR.PU which is used to signal
> to hardware that power should not be removed from the trace unit.
> Let's mitigate against this by conditionally saving and restoring
> the trace unit state when the CPU enters low power states.
>
> This patchset introduces a firmware property named
> 'arm,coresight-needs-save-restore' - when this is present the
> hardware state will be conditionally saved and restored.
>
> A module parameter 'pm_save_enable' is also introduced which can
> be configured to override the firmware property. This can be set
> to never allow save/restore, to conditionally allow it, or to
> do as the firmware indicates (default).
>
> We avoid saving the hardware state when coresight isn't in use
> to reduce PM latency - we can't determine this by reading the
> claim tags (TRCCLAIMCLR) as these are 'trace' registers which need
> power and clocking, something we can't easily provide in the PM
> context. Therefore we rely on the existing drvdata->mode internal
> state that is set when self-hosted coresight is used (and powered).
>
> As we do not have a simple way of determining if an external agent
> is using coresight, we don't save/restore for this use case.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x.c | 322 ++++++++++++++++++
> drivers/hwtracing/coresight/coresight-etm4x.h | 64 ++++
> 2 files changed, 386 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index a128b5063f46..30f118792289 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> +static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> + void *v)
> +{
> + struct etmv4_drvdata *drvdata;
> + unsigned int cpu = smp_processor_id();
> +
> + if (!etmdrvdata[cpu])
> + return 0;
> +
> + drvdata = etmdrvdata[cpu];
> +
> + if (!drvdata->save_state)
> + return NOTIFY_OK;
> +
> + if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
> + return NOTIFY_BAD;
minor nit: you may skip the second call to smp_processor_id() as this is called
on from non-preemptible context.
> +
> + switch (cmd) {
> + case CPU_PM_ENTER:
> + /* save the state if self-hosted coresight is in use */
> + if (local_read(&drvdata->mode))
> + if (etm4_cpu_save(drvdata))
> + return NOTIFY_BAD;
> + break;
> + case CPU_PM_EXIT:
> + case CPU_PM_ENTER_FAILED:
> + /* trcclaimset is set when there is state to restore */
> + if (drvdata->state_needs_restore)
> + etm4_cpu_restore(drvdata);
> + break;
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> +static void etm4_cpu_pm_unregister(void)
> +{
> + cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
> +}
> +#else
> +static int etm4_cpu_pm_register(void) { return 0; }
> +static void etm4_cpu_pm_unregister(void) { }
> +#endif
> +
> +static inline bool etm4_needs_save_restore(struct device *dev)
> +{
> + return fwnode_property_present(dev->fwnode,
nit: It may be safe to use dev_fwnode(dev), instead of dev->fwnode. But I
see a lot of existing users of dev->fwnode. Not sure it does have an impact.
Looks fine to me ,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v19 02/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
From: Catalin Marinas @ 2019-08-02 10:50 UTC (permalink / raw)
To: Dave Hansen
Cc: Mark Rutland, kvm, Szabolcs Nagy, Will Deacon, dri-devel,
linux-mm, Khalid Aziz, linux-kselftest, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Ramana Radhakrishnan, Dave Martin, Evgeniy Stepanov, linux-media,
Kees Cook, Ruben Ayrapetyan, Andrey Konovalov, Kevin Brodsky,
Alex Williamson, Mauro Carvalho Chehab, linux-arm-kernel,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, linux-kernel,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <88c59d1e-eda9-fcfe-5ee3-64a331f34313@intel.com>
On Thu, Aug 01, 2019 at 09:45:05AM -0700, Dave Hansen wrote:
> On 8/1/19 5:38 AM, Kevin Brodsky wrote:
> > This patch series only changes what is allowed or not at the syscall
> > interface. It does not change the address space size. On arm64, TBI (Top
> > Byte Ignore) has always been enabled for userspace, so it has never been
> > possible to use the upper 8 bits of user pointers for addressing.
>
> Oh, so does the address space that's available already chop that out?
Yes. Currently the hardware only supports 52-bit virtual addresses. It
could be expanded (though it needs a 5th page table level) to 56-bit VA
but it's not currently on our (hardware) plans. Beyond 56-bit, it cannot
be done without breaking the software expectations (and hopefully I'll
retire before we need this ;)).
> > If other architectures were to support a similar functionality, then I
> > agree that a common and more generic interface (if needed) would be
> > helpful, but as it stands this is an arm64-specific prctl, and on arm64
> > the address tag is defined by the architecture as bits [63:56].
>
> It should then be an arch_prctl(), no?
I guess you just want renaming SET_TAGGED_ADDR_CTRL() to
arch_prctl_tagged_addr_ctrl_set()? (similarly for 'get')
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/10] drivers, provide a way to add sysfs groups easily
From: Greg Kroah-Hartman @ 2019-08-02 10:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: x86, linux-input, linux-fbdev, Andy Shevchenko,
Bartlomiej Zolnierkiewicz, Sudeep Holla, linux-kernel, dri-devel,
platform-driver-x86, Tony Prisk, Andy Shevchenko,
Florian Fainelli, Borislav Petkov, H. Peter Anvin, Darren Hart,
Thomas Gleixner, Richard Gong, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20190731131045.GB147138@dtor-ws>
On Wed, Jul 31, 2019 at 06:10:45AM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 31, 2019 at 02:43:39PM +0200, Greg Kroah-Hartman wrote:
> > This patch originally started out just as a way for platform drivers to
> > easily add a sysfs group in a race-free way, but thanks to Dmitry's
> > patch, this series now is for all drivers in the kernel (hey, a unified
> > driver model works!!!)
> >
> > I've only converted a few platform drivers here in this series to show
> > how it works, but other busses can be converted after the first patch
> > goes into the tree.
> >
> > Here's the original 00 message, for people to get an idea of what is
> > going on here:
> >
> > If a platform driver wants to add a sysfs group, it has to do so in a
> > racy way, adding it after the driver is bound. To resolve this issue,
> > have the platform driver core do this for the driver, making the
> > individual drivers logic smaller and simpler, and solving the race at
> > the same time.
> >
> > All of these patches depend on the first patch. I'll take the first one
> > through my driver-core tree, and any subsystem maintainer can either ack
> > their individul patch and I will be glad to also merge it, or they can
> > wait until after 5.4-rc1 when the core patch hits Linus's tree and then
> > take it, it's up to them.
>
> Maybe make an immutable branch off 5.2 with just patch 1/10 so that
> subsystems (and the driver core tree itself) could pull it in at their
> leisure into their "*-next" branches and did not have to wait till 5.4
> or risk merge clashes?
I have now done this with patch 1/10. Here's the pull info if any
subsystem maintainer wants to suck this into their tree to provide the
ability for drivers to add/remove attribute groups easily.
This is part of my driver-core tree now, and will go to Linus for
5.4-rc1, along with a few platform drivers that have been acked by their
various subsystem maintainers that convert them to use this new
functionality.
If anyone has any questions about this, please let me know.
thanks,
greg k-h
-------------------
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/dev_groups_all_drivers
for you to fetch changes up to 23b6904442d08b7dbed7622ed33b236d41a3aa8b:
driver core: add dev_groups to all drivers (2019-08-02 12:37:53 +0200)
----------------------------------------------------------------
dev_groups added to struct driver
Persistent tag for others to pull this branch from
This is the first patch in a longer series that adds the ability for the
driver core to create and remove a list of attribute groups
automatically when the device is bound/unbound from a specific driver.
See:
https://lore.kernel.org/r/20190731124349.4474-2-gregkh@linuxfoundation.org
for details on this patch, and examples of how to use it in other
drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Dmitry Torokhov (1):
driver core: add dev_groups to all drivers
drivers/base/dd.c | 14 ++++++++++++++
include/linux/device.h | 3 +++
2 files changed, 17 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Suzuki K Poulose @ 2019-08-02 10:40 UTC (permalink / raw)
To: andrew.murray, mathieu.poirier, alexander.shishkin
Cc: Al.Grant, coresight, leo.yan, Sudeep.Holla, linux-arm-kernel,
mike.leach
In-Reply-To: <20190730125157.884-7-andrew.murray@arm.com>
Hi Andrew,
On 30/07/2019 13:51, Andrew Murray wrote:
> Some coresight components, because of choices made during hardware
> integration, require their state to be saved and restored across CPU low
> power states.
>
> The software has no reliable method of detecting when save/restore is
> required thus let's add a binding to inform the kernel.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index fcc3bacfd8bc..7cbdb7893af8 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -92,6 +92,9 @@ its hardware characteristcs.
> * arm,cp14: must be present if the system accesses ETM/PTM management
> registers via co-processor 14.
>
> + * arm,coresight-needs-save-restore: boolean. Indicates that software
> + should save/restore state across power down.
> +
Do you think we could be a bit more descriptive here about when people could add
it to the DT ? Here we don't mention when someone should use this property and
it may be added to platforms where it may be absolutely unnecessary. How about :
"Indicates that the hardware implementation may not honor the Powerup request
from the software and thus might loose the register context on CPU power down
(e.g, during CPUIdle). Software must save/restore the context during a CPU power
transition cycle."
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
From: Will Deacon @ 2019-08-02 10:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, Michael Ellerman, linuxppc-dev, Russell King,
linux-kernel, iommu, Catalin Marinas, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190802081441.GA9725@lst.de>
On Fri, Aug 02, 2019 at 10:14:41AM +0200, Christoph Hellwig wrote:
> On Thu, Aug 01, 2019 at 05:44:12PM +0100, Will Deacon wrote:
> > > > Although arch_dma_mmap_pgprot() is a bit of a misnomer now that it only
> > > > gets involved in the non-coherent case.
> > >
> > > A better name is welcome.
> >
> > How about arch_dma_noncoherent_mmap_pgprot() ? Too long?
>
> Sounds a little long yes. And doesn't fix the additional problem that
> we don't just it for mmap but also for the in-kernel remapping these
> days.
Hmm. Maybe just arch_dma_noncoherent_pgprot() then.
> > > But my worry is how this interacts with architectures that have an
> > > uncached segment (mips, nios2, microblaze, extensa) where we'd have
> > > the kernel access DMA_ATTR_WRITE_COMBINE mappigns using the uncached
> > > segment, and userspace mmaps using pgprot_writecombine, which could
> > > lead to aliasing issues. But then again mips already supports
> > > DMA_ATTR_WRITE_COMBINE, so this must be ok somehow. I guess I'll
> > > need to field that question to the relevant parties.
> >
> > Or it's always been busted and happens to work out in practice...
>
> I've sent a ping to the mips folks. While we'are at it: arm64
> and arm32 (optionally) map dma coherent allocations as write combine.
> I suspect this hasn't always just been busted but intentional (of course!),
> but is there any chance to get a quote from the arm architecture spec
> on why this is fine as it looks rather confusion?
So this boils down to a terminology mismatch. The Arm architecture doesn't have
anything called "write combine", so in Linux we instead provide what the Arm
architecture calls "Normal non-cacheable" memory for pgprot_writecombine().
Amongst other things, this memory type permits speculation, unaligned accesses
and merging of writes. I found something in the architecture spec about
non-cachable memory, but it's written in Armglish[1].
pgprot_noncached(), on the other hand, provides what the architecture calls
Strongly Ordered or Device-nGnRnE memory. This is intended for mapping MMIO
(i.e. PCI config space) and therefore forbids speculation, preserves access
size, requires strict alignment and also forces write responses to come from
the endpoint.
I think the naming mismatch is historical, but on arm64 we wanted to use the
same names as arm32 so that any drivers using these things directly would get
the same behaviour.
Will
[1]
B2.4.4 Implication of caches for the application programmer
[...]
Data coherency issues
Software can ensure the data coherency of caches in the following ways:
* By not using the caches in situations where coherency issues can arise.
This can be achieved by:
- Using Non-cacheable or, in some cases, Write-Through Cacheable memory.
- Not enabling caches in the system.
* By using cache maintenance instructions to manage the coherency issues
in software.
* By using hardware coherency mechanisms to ensure the coherency of data
accesses to memory for cacheable locations by observers within the
different shareability domains.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 6/6] ARM: dts: mmp2: add OLPC XO 1.75 machine
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This is a fairly complete description of an OLPC XO 1.75 laptop.
What's missing for now is the GPU, LCD controller, DCON, the panel and
audio.
The machine is booted with OpenFirmware and thus has a devicetree.
However, older versions are unable to create a valid FDT and don't
follow the Linux bindings. Having an device tree in the kernel tree
makes it easier to use mainline kernels on such machines, test changes
with CONFIG_ARM_APPENDED_DTB and give a good reference on what bindings
are used on the machine without an access to one.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 244 ++++++++++++++++++++++++
2 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90c..65213b5265187 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -336,7 +336,8 @@ dtb-$(CONFIG_MACH_MESON8) += \
dtb-$(CONFIG_ARCH_MMP) += \
pxa168-aspenite.dtb \
pxa910-dkb.dtb \
- mmp2-brownstone.dtb
+ mmp2-brownstone.dtb \
+ mmp2-olpc-xo-1-75.dtb
dtb-$(CONFIG_ARCH_MPS2) += \
mps2-an385.dtb \
mps2-an399.dtb
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
new file mode 100644
index 0000000000000..6cfa0d4a18845
--- /dev/null
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * OLPC XO 1.75 Laptop.
+ *
+ * Copyright (C) 2018,2019 Lubomir Rintel <lkundrak@v3.sk>
+ */
+
+/dts-v1/;
+#include "mmp2.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ model = "OLPC XO-1.75";
+ compatible = "olpc,xo-1.75", "mrvl,mmp2";
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@1fc00000 {
+ compatible = "simple-framebuffer";
+ reg = <0x1fc00000 (1200 * 900 * 2)>;
+ width = <1200>;
+ height = <900>;
+ stride = <(1200 * 2)>;
+ format = "r5g6b5";
+ clocks = <&soc_clocks MMP2_CLK_DISP0_LCDC>,
+ <&soc_clocks MMP2_CLK_DISP0>;
+ };
+ };
+
+ memory {
+ linux,usable-memory = <0x0 0x1f800000>;
+ available = <0xcf000 0x1ef31000 0x1000 0xbf000>;
+ reg = <0x0 0x20000000>;
+ device_type = "memory";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ lid {
+ label = "Lid";
+ gpios = <&gpio 129 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ wakeup-source;
+ };
+
+ tablet_mode {
+ label = "E-Book Mode";
+ gpios = <&gpio 128 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_TABLET_MODE>;
+ wakeup-source;
+ };
+
+ microphone_insert {
+ label = "Microphone Plug";
+ gpios = <&gpio 96 GPIO_ACTIVE_HIGH>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_MICROPHONE_INSERT>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+
+ headphone_insert {
+ label = "Headphone Plug";
+ gpios = <&gpio 97 GPIO_ACTIVE_HIGH>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_HEADPHONE_INSERT>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+ };
+
+ camera_i2c {
+ compatible = "i2c-gpio";
+ gpios = <&gpio 109 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>,
+ <&gpio 108 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-gpio,timeout-ms = <1000>;
+ status = "okay";
+
+ camera@21 {
+ compatible = "ovti,ov7670";
+ reg = <0x21>;
+ reset-gpios = <&gpio 102 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&gpio 150 GPIO_ACTIVE_LOW>;
+ clocks = <&camera0>;
+ clock-names = "xclk";
+
+ port {
+ ov7670_0: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ remote-endpoint = <&camera0_0>;
+ };
+ };
+ };
+ };
+
+ battery {
+ compatible = "olpc,xo1.5-battery", "olpc,xo1-battery";
+ };
+
+ wlan_reg: fixedregulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 34 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ wlan_pwrseq: pwrseq0 {
+ compatible = "mmc-pwrseq-sd8787";
+ powerdown-gpios = <&gpio 57 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 58 GPIO_ACTIVE_HIGH>;
+ };
+
+ soc {
+ axi@d4200000 {
+ ap-sp@d4290000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "olpc,ap-sp";
+ interrupts = <40>;
+ reg = <0xd4290000 0x1000>;
+ data-gpios = <&gpio 72 GPIO_ACTIVE_HIGH>;
+ clk-gpios = <&gpio 71 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+ };
+ };
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&rtc {
+ status = "okay";
+};
+
+&usb_phy0 {
+ status = "okay";
+};
+
+&usb_otg0 {
+ status = "okay";
+};
+
+&mmc1 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ mrvl,clk-delay-cycles = <31>;
+ broken-cd;
+ status = "okay";
+};
+
+&mmc2 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ bus-width = <4>;
+ non-removable;
+ broken-cd;
+ wakeup-source;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&wlan_pwrseq>;
+ vmmc-supply = <&wlan_reg>;
+ status = "okay";
+};
+
+&mmc3 {
+ clock-frequency = <50000000>;
+ no-1-8-v;
+ bus-width = <8>;
+ non-removable;
+ broken-cd;
+ mrvl,clk-delay-cycles = <31>;
+ status = "okay";
+};
+
+&twsi1 {
+ status = "okay";
+
+ audio-codec@1a {
+ compatible = "realtek,alc5631";
+ reg = <0x1a>;
+ status = "okay";
+ };
+};
+
+&twsi2 {
+ status = "okay";
+
+ rtc@68 {
+ compatible = "dallas,ds1338";
+ reg = <0x68>;
+ status = "okay";
+ };
+};
+
+&twsi6 {
+ status = "okay";
+
+ accelerometer@1d {
+ compatible = "st,lis331dlh", "st,lis3lv02d";
+ reg = <0x1d>;
+ status = "okay";
+ };
+};
+
+&ssp3 {
+ #address-cells = <0>;
+ spi-slave;
+ status = "okay";
+ ready-gpio = <&gpio 125 GPIO_ACTIVE_HIGH>;
+
+ slave {
+ compatible = "olpc,xo1.75-ec";
+ spi-cpha;
+ cmd-gpio = <&gpio 155 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&camera0 {
+ status = "okay";
+
+ port {
+ camera0_0: endpoint {
+ remote-endpoint = <&ov7670_0>;
+ };
+ };
+};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: mmp2: specify reg-shift for the UARTs
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This makes the 8250_of driver happy. There are two more drivers in the
tree that bind to mrvl,mmp-uart compatibles: pxa and 8250_pxa and
neither of them requires the reg-shift property, assuming it's always 2.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
Changes since v1:
- Updated the subject to fit the style of the DTS updates
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 68b5470773232..6a2f072c1d0a8 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -214,6 +214,7 @@
interrupts = <27>;
clocks = <&soc_clocks MMP2_CLK_UART0>;
resets = <&soc_clocks MMP2_CLK_UART0>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -223,6 +224,7 @@
interrupts = <28>;
clocks = <&soc_clocks MMP2_CLK_UART1>;
resets = <&soc_clocks MMP2_CLK_UART1>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -232,6 +234,7 @@
interrupts = <24>;
clocks = <&soc_clocks MMP2_CLK_UART2>;
resets = <&soc_clocks MMP2_CLK_UART2>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -241,6 +244,7 @@
interrupts = <46>;
clocks = <&soc_clocks MMP2_CLK_UART3>;
resets = <&soc_clocks MMP2_CLK_UART3>;
+ reg-shift = <2>;
status = "disabled";
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: mmp2: fix the SPI nodes
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
The SPI bus has a single address cell and not size cells.
Also, dtc thinks the SPI nodes are preferrably called "spi" and it is
right to think so.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 50b6c38b39cc3..e64639ce57a91 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -346,35 +346,43 @@
status = "disabled";
};
- ssp1: ssp@d4035000 {
+ ssp1: spi@d4035000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4035000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP0>;
interrupts = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp2: ssp@d4036000 {
+ ssp2: spi@d4036000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4036000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP1>;
interrupts = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp3: ssp@d4037000 {
+ ssp3: spi@d4037000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4037000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP2>;
interrupts = <20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp4: ssp@d4039000 {
+ ssp4: spi@d4039000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4039000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP3>;
interrupts = <21>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: mmp2: rename the USB PHY node
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
This device is not an OTG phy, it's a regular USB HS phy. Follow the
generic node name recommendation, and rename it to "usb-phy".
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index e64639ce57a91..21432cb9143f7 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -117,7 +117,7 @@
mrvl,intc-nr-irqs = <2>;
};
- usb_otg_phy0: usb-otg-phy@d4207000 {
+ usb_phy0: usb-phy@d4207000 {
compatible = "marvell,mmp2-usb-phy";
reg = <0xd4207000 0x40>;
#phy-cells = <0>;
@@ -130,7 +130,7 @@
interrupts = <44>;
clocks = <&soc_clocks MMP2_CLK_USB>;
clock-names = "USBCLK";
- phys = <&usb_otg_phy0>;
+ phys = <&usb_phy0>;
phy-names = "usb";
status = "disabled";
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/6] ARM: dts: mmp2: add camera interfaces
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
Supported by the mmp-camera driver.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 21432cb9143f7..68b5470773232 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -170,6 +170,28 @@
interrupts = <54>;
status = "disabled";
};
+
+ camera0: camera@d420a000 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a000 0x800>;
+ interrupts = <42>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
+
+ camera1: camera@d420a800 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a800 0x800>;
+ interrupts = <30>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC1>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
};
apb@d4000000 { /* APB */
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/6] ARM: dts: mmp2: devicetree updates
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring, Pavel Machek,
linux-arm-kernel
Hi,
Here's a couple of updates for the MMP2 SoC devicetree files.
The only change from the last submission is the addition of the
OLPC XO 1.75 dts file. Apart from that one, the patches are
independent of each other, can be applied in any order.
Hopefully I'm sending the patch set in the correct direction.
Lubo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/6] ARM: dts: mmp2: trivial whitespace fix
From: Lubomir Rintel @ 2019-08-02 10:33 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, Pavel Machek, linux-arm-kernel
In-Reply-To: <20190802103326.531250-1-lkundrak@v3.sk>
A missing space before a curly brace.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index b6f40743e07b0..50b6c38b39cc3 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -379,7 +379,7 @@
};
};
- soc_clocks: clocks{
+ soc_clocks: clocks {
compatible = "marvell,mmp2-clock";
reg = <0xd4050000 0x1000>,
<0xd4282800 0x400>,
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 00/59] KVM: arm64: ARMv8.3 Nested Virtualization support
From: Andrew Jones @ 2019-08-02 10:30 UTC (permalink / raw)
To: Alexandru Elisei
Cc: kvm@vger.kernel.org, Marc Zyngier, Andre Przywara,
kvmarm@lists.cs.columbia.edu, Dave P Martin,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <69cf1fe7-912c-1767-ff1b-dfcc7f549e44@arm.com>
On Fri, Aug 02, 2019 at 10:11:38AM +0000, Alexandru Elisei wrote:
> These are the changes that I made to kvm-unit-tests (the diff can be applied on
> top of upstream master, 2130fd4154ad ("tscdeadline_latency: Check condition
> first before loop")):
It's great to hear that you're doing this. You may find these bit-rotted
commits useful too
https://github.com/rhdrjones/kvm-unit-tests/commits/arm64/hyp-mode
Thanks,
drew
>
> diff --git a/arm/cstart64.S b/arm/cstart64.S
> index b0e8baa1a23a..a7631b5a1801 100644
> --- a/arm/cstart64.S
> +++ b/arm/cstart64.S
> @@ -51,6 +51,17 @@ start:
> b 1b
>
> 1:
> + mrs x4, CurrentEL
> + cmp x4, CurrentEL_EL2
> + b.ne 1f
> + mrs x4, mpidr_el1
> + msr vmpidr_el2, x4
> + mrs x4, midr_el1
> + msr vpidr_el2, x4
> + ldr x4, =(HCR_EL2_TGE | HCR_EL2_E2H)
> + msr hcr_el2, x4
> + isb
> +1:
> /* set up stack */
> mov x4, #1
> msr spsel, x4
> @@ -101,6 +112,17 @@ get_mmu_off:
>
> .globl secondary_entry
> secondary_entry:
> + mrs x0, CurrentEL
> + cmp x0, CurrentEL_EL2
> + b.ne 1f
> + mrs x0, mpidr_el1
> + msr vmpidr_el2, x0
> + mrs x0, midr_el1
> + msr vpidr_el2, x0
> + ldr x0, =(HCR_EL2_TGE | HCR_EL2_E2H)
> + msr hcr_el2, x0
> + isb
> +1:
> /* Enable FP/ASIMD */
> mov x0, #(3 << 20)
> msr cpacr_el1, x0
> diff --git a/lib/arm/asm/psci.h b/lib/arm/asm/psci.h
> index 7b956bf5987d..07297a27e0ce 100644
> --- a/lib/arm/asm/psci.h
> +++ b/lib/arm/asm/psci.h
> @@ -3,6 +3,15 @@
> #include <libcflat.h>
> #include <linux/psci.h>
>
> +enum psci_conduit {
> + PSCI_CONDUIT_HVC,
> + PSCI_CONDUIT_SMC,
> +};
> +
> +extern void psci_init(void);
> +extern void psci_set_conduit(enum psci_conduit conduit);
> +extern enum psci_conduit psci_get_conduit(void);
> +
> extern int psci_invoke(unsigned long function_id, unsigned long arg0,
> unsigned long arg1, unsigned long arg2);
> extern int psci_cpu_on(unsigned long cpuid, unsigned long entry_point);
> diff --git a/lib/arm/psci.c b/lib/arm/psci.c
> index c3d399064ae3..20ad4b944738 100644
> --- a/lib/arm/psci.c
> +++ b/lib/arm/psci.c
> @@ -6,13 +6,14 @@
> *
> * This work is licensed under the terms of the GNU LGPL, version 2.
> */
> +#include <devicetree.h>
> +#include <string.h>
> #include <asm/psci.h>
> #include <asm/setup.h>
> #include <asm/page.h>
> #include <asm/smp.h>
>
> -__attribute__((noinline))
> -int psci_invoke(unsigned long function_id, unsigned long arg0,
> +static int psci_invoke_hvc(unsigned long function_id, unsigned long arg0,
> unsigned long arg1, unsigned long arg2)
> {
> asm volatile(
> @@ -22,6 +23,63 @@ int psci_invoke(unsigned long function_id, unsigned long arg0,
> return function_id;
> }
>
> +static int psci_invoke_smc(unsigned long function_id, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + asm volatile(
> + "smc #0"
> + : "+r" (function_id)
> + : "r" (arg0), "r" (arg1), "r" (arg2));
> + return function_id;
> +}
> +
> +/*
> + * Initialize to something sensible, so the exit fallback psci_system_off still
> + * works before calling psci_init when booted at EL1.
> + */
> +static enum psci_conduit psci_conduit = PSCI_CONDUIT_HVC;
> +static int (*psci_fn)(unsigned long, unsigned long, unsigned long,
> + unsigned long) = &psci_invoke_hvc;
> +
> +void psci_set_conduit(enum psci_conduit conduit)
> +{
> + psci_conduit = conduit;
> + if (conduit == PSCI_CONDUIT_HVC)
> + psci_fn = &psci_invoke_hvc;
> + else
> + psci_fn = &psci_invoke_smc;
> +}
> +
> +enum psci_conduit psci_get_conduit(void)
> +{
> + return psci_conduit;
> +}
> +
> +int psci_invoke(unsigned long function_id, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + return psci_fn(function_id, arg0, arg1, arg2);
> +}
> +
> +void psci_init(void)
> +{
> + const char *conduit;
> + int ret;
> +
> + ret = dt_get_psci_conduit(&conduit);
> + assert(ret == 0 || ret == -FDT_ERR_NOTFOUND);
> +
> + if (ret == -FDT_ERR_NOTFOUND)
> + conduit = "hvc";
> +
> + assert(strcmp(conduit, "hvc") == 0 || strcmp(conduit, "smc") == 0);
> +
> + if (strcmp(conduit, "hvc") == 0)
> + psci_set_conduit(PSCI_CONDUIT_HVC);
> + else
> + psci_set_conduit(PSCI_CONDUIT_SMC);
> +}
> +
> int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
> {
> #ifdef __arm__
> diff --git a/lib/arm/setup.c b/lib/arm/setup.c
> index 4f02fca85607..e0dc9e4801b0 100644
> --- a/lib/arm/setup.c
> +++ b/lib/arm/setup.c
> @@ -21,6 +21,7 @@
> #include <asm/setup.h>
> #include <asm/page.h>
> #include <asm/smp.h>
> +#include <asm/psci.h>
>
> #include "io.h"
>
> @@ -164,7 +165,11 @@ void setup(const void *fdt)
> freemem += initrd_size;
> }
>
> - /* call init functions */
> + /*
> + * call init functions. psci_init goes first so psci_system_off fallback
> + * works in case of an assert failure
> + */
> + psci_init();
> mem_init(PAGE_ALIGN((unsigned long)freemem));
> cpu_init();
>
> diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
> index 1d9223f728a5..18c5d29ddd1f 100644
> --- a/lib/arm64/asm/processor.h
> +++ b/lib/arm64/asm/processor.h
> @@ -16,6 +16,9 @@
> #define SCTLR_EL1_A (1 << 1)
> #define SCTLR_EL1_M (1 << 0)
>
> +#define HCR_EL2_TGE (1 << 27)
> +#define HCR_EL2_E2H (1 << 34)
> +
> #ifndef __ASSEMBLY__
> #include <asm/ptrace.h>
> #include <asm/esr.h>
> diff --git a/lib/devicetree.c b/lib/devicetree.c
> index 2b89178a109b..4e684c7100b2 100644
> --- a/lib/devicetree.c
> +++ b/lib/devicetree.c
> @@ -263,6 +263,27 @@ int dt_get_bootargs(const char **bootargs)
> return 0;
> }
>
> +int dt_get_psci_conduit(const char **conduit)
> +{
> + const struct fdt_property *prop;
> + int node, len;
> +
> + *conduit = NULL;
> +
> + node = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-0.2");
> + if (node < 0)
> + return node;
> +
> + prop = fdt_get_property(fdt, node, "method", &len);
> + if (!prop)
> + return len;
> + if (len < 4)
> + return -FDT_ERR_NOTFOUND;
> +
> + *conduit = prop->data;
> + return 0;
> +}
> +
> int dt_get_default_console_node(void)
> {
> const struct fdt_property *prop;
> diff --git a/lib/devicetree.h b/lib/devicetree.h
> index 93c7ebc63bd8..236035eb777d 100644
> --- a/lib/devicetree.h
> +++ b/lib/devicetree.h
> @@ -211,6 +211,15 @@ extern int dt_get_reg(int fdtnode, int regidx, struct
> dt_reg *reg);
> extern int dt_get_bootargs(const char **bootargs);
>
> /*
> + * dt_get_psci_conduit gets the conduit for PSCI function invocations from
> + * /psci/method
> + * returns
> + * - zero on success
> + * - a negative FDT_ERR_* value on failure, and @conduit will be set to null
> + */
> +extern int dt_get_psci_conduit(const char **conduit);
> +
> +/*
> * dt_get_default_console_node gets the node of the path stored in
> * /chosen/stdout-path (or the deprecated /chosen/linux,stdout-path)
> * returns
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/6] coresight: etm4x: use module_param instead of module_param_named
From: Suzuki K Poulose @ 2019-08-02 10:23 UTC (permalink / raw)
To: andrew.murray, mathieu.poirier, alexander.shishkin
Cc: Al.Grant, coresight, leo.yan, Sudeep.Holla, linux-arm-kernel,
mike.leach
In-Reply-To: <20190730125157.884-4-andrew.murray@arm.com>
On 30/07/2019 13:51, Andrew Murray wrote:
> Given that the user-exposed module parameter for 'boot_enable' matches
> the variable that it sets, let's use module_param instead of
> module_param_named.
>
> Let's also use octal permissions (checkpatch recommends this) and
> provide a module parameter description.
>
> Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-etm4x.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index ec9468880c71..615bdbf7c9b7 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -34,7 +34,8 @@
> #include "coresight-etm-perf.h"
>
> static int boot_enable;
> -module_param_named(boot_enable, boot_enable, int, S_IRUGO);
> +module_param(boot_enable, int, 0444);
> +MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
>
> /* The number of ETMv4 currently registered */
> static int etm4_count;
>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2019-08-02 10:20 UTC (permalink / raw)
To: Dave Hansen
Cc: Mark Rutland, kvm, Szabolcs Nagy, Will Deacon, dri-devel,
Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Ramana Radhakrishnan, Dave Martin, Evgeniy Stepanov, linux-media,
Kees Cook, Ruben Ayrapetyan, Andrey Konovalov, Kevin Brodsky,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <96fd8da4-a912-f6cc-2b32-5791027dbbd5@intel.com>
On Thu, Aug 01, 2019 at 08:36:47AM -0700, Dave Hansen wrote:
> On 8/1/19 5:48 AM, Andrey Konovalov wrote:
> > On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
> >> On 31/07/2019 17:50, Dave Hansen wrote:
> >>> On 7/23/19 10:58 AM, Andrey Konovalov wrote:
> >>>> The mmap and mremap (only new_addr) syscalls do not currently accept
> >>>> tagged addresses. Architectures may interpret the tag as a background
> >>>> colour for the corresponding vma.
> >>>
> >>> What the heck is a "background colour"? :)
> >>
> >> Good point, this is some jargon that we started using for MTE, the idea being that
> >> the kernel could set a tag value (specified during mmap()) as "background colour" for
> >> anonymous pages allocated in that range.
> >>
> >> Anyway, this patch series is not about MTE. Andrey, for v20 (if any), I think it's
> >> best to drop this last sentence to avoid any confusion.
Indeed, the part with the "background colour" and even the "currently"
adverb should be dropped.
Also, if we merge the patches via different trees anyway, I don't think
there is a need for Andrey to integrate them with his series. We can
pick them up directly in the arm64 tree (once the review finished).
> OK, but what does that mean for tagged addresses getting passed to
> mmap/mremap? That sentence read to me like "architectures might allow
> tags for ...something...". So do we accept tagged addresses into those
> syscalls?
If mmap() does not return a tagged address, the reasoning is that it
should not accept one as an address hint (with or without MAP_FIXED).
Note that these docs should only describe the top-byte-ignore ABI while
leaving the memory tagging for a future patchset.
In that future patchset, we may want to update the mmap() ABI to allow,
only in conjunction with PROT_MTE, a tagged pointer as an address
argument. In such case mmap() will return a tagged address and the pages
pre-coloured (on fault) with the tag requested by the user. As I said,
that's to be discussed later in the year.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/59] KVM: arm64: ARMv8.3 Nested Virtualization support
From: Alexandru Elisei @ 2019-08-02 10:11 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: Andre Przywara, Dave P Martin
In-Reply-To: <20190621093843.220980-1-marc.zyngier@arm.com>
Hi,
On 6/21/19 10:37 AM, Marc Zyngier wrote:
> I've taken over the maintenance of this series originally written by
> Jintack and Christoffer. Since then, the series has been substantially
> reworked, new features (and most probably bugs) have been added, and
> the whole thing rebased multiple times. If anything breaks, please
> blame me, and nobody else.
>
> As you can tell, this is quite big. It is also remarkably incomplete
> (we're missing many critical bits for fully emulate EL2), but the idea
> is to start merging things early in order to reduce the maintenance
> headache. What we want to achieve is that with NV disabled, there is
> no performance overhead and no regression. The only thing I intend to
> merge ASAP is the first patch in the series, because it should have
> zero effect and is a reasonable cleanup.
>
> The series is roughly divided in 4 parts: exception handling, memory
> virtualization, interrupts and timers. There are of course some
> dependencies, but you'll hopefully get the gist of it.
>
> For the most courageous of you, I've put out a branch[1] containing this
> and a bit more. Of course, you'll need some userspace. Andre maintains
> a hacked version of kvmtool[1] that takes a --nested option, allowing
> the guest to be started at EL2. You can run the whole stack in the
> Foundation model. Don't be in a hurry ;-).
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nv-wip-5.2-rc5
> [2] git://linux-arm.org/kvmtool.git nv/nv-wip-5.2-rc5
>
> Andre Przywara (4):
> KVM: arm64: nv: Handle virtual EL2 registers in
> vcpu_read/write_sys_reg()
> KVM: arm64: nv: Save/Restore vEL2 sysregs
> KVM: arm64: nv: Handle traps for timer _EL02 and _EL2 sysregs
> accessors
> KVM: arm64: nv: vgic: Allow userland to set VGIC maintenance IRQ
>
> Christoffer Dall (16):
> KVM: arm64: nv: Introduce nested virtualization VCPU feature
> KVM: arm64: nv: Reset VCPU to EL2 registers if VCPU nested virt is set
> KVM: arm64: nv: Allow userspace to set PSR_MODE_EL2x
> KVM: arm64: nv: Add nested virt VCPU primitives for vEL2 VCPU state
> KVM: arm64: nv: Handle trapped ERET from virtual EL2
> KVM: arm64: nv: Emulate PSTATE.M for a guest hypervisor
> KVM: arm64: nv: Trap EL1 VM register accesses in virtual EL2
> KVM: arm64: nv: Only toggle cache for virtual EL2 when SCTLR_EL2
> changes
> KVM: arm/arm64: nv: Support multiple nested stage 2 mmu structures
> KVM: arm64: nv: Implement nested Stage-2 page table walk logic
> KVM: arm64: nv: Handle shadow stage 2 page faults
> KVM: arm64: nv: Unmap/flush shadow stage 2 page tables
> KVM: arm64: nv: arch_timer: Support hyp timer emulation
> KVM: arm64: nv: vgic-v3: Take cpu_if pointer directly instead of vcpu
> KVM: arm64: nv: vgic: Emulate the HW bit in software
> KVM: arm64: nv: Add nested GICv3 tracepoints
>
> Dave Martin (1):
> KVM: arm64: Migrate _elx sysreg accessors to msr_s/mrs_s
>
> Jintack Lim (21):
> arm64: Add ARM64_HAS_NESTED_VIRT cpufeature
> KVM: arm64: nv: Add EL2 system registers to vcpu context
> KVM: arm64: nv: Support virtual EL2 exceptions
> KVM: arm64: nv: Inject HVC exceptions to the virtual EL2
> KVM: arm64: nv: Trap SPSR_EL1, ELR_EL1 and VBAR_EL1 from virtual EL2
> KVM: arm64: nv: Trap CPACR_EL1 access in virtual EL2
> KVM: arm64: nv: Set a handler for the system instruction traps
> KVM: arm64: nv: Handle PSCI call via smc from the guest
> KVM: arm64: nv: Respect virtual HCR_EL2.TWX setting
> KVM: arm64: nv: Respect virtual CPTR_EL2.TFP setting
> KVM: arm64: nv: Respect the virtual HCR_EL2.NV bit setting
> KVM: arm64: nv: Respect virtual HCR_EL2.TVM and TRVM settings
> KVM: arm64: nv: Respect the virtual HCR_EL2.NV1 bit setting
> KVM: arm64: nv: Emulate EL12 register accesses from the virtual EL2
> KVM: arm64: nv: Configure HCR_EL2 for nested virtualization
> KVM: arm64: nv: Pretend we only support larger-than-host page sizes
> KVM: arm64: nv: Introduce sys_reg_desc.forward_trap
> KVM: arm64: nv: Rework the system instruction emulation framework
> KVM: arm64: nv: Trap and emulate AT instructions from virtual EL2
> KVM: arm64: nv: Trap and emulate TLBI instructions from virtual EL2
> KVM: arm64: nv: Nested GICv3 Support
>
> Marc Zyngier (17):
> KVM: arm64: Move __load_guest_stage2 to kvm_mmu.h
> KVM: arm64: nv: Reset VMPIDR_EL2 and VPIDR_EL2 to sane values
> KVM: arm64: nv: Handle SPSR_EL2 specially
> KVM: arm64: nv: Refactor vcpu_{read,write}_sys_reg
> KVM: arm64: nv: Don't expose SVE to nested guests
> KVM: arm64: nv: Hide RAS from nested guests
> KVM: arm/arm64: nv: Factor out stage 2 page table data from struct kvm
> KVM: arm64: nv: Move last_vcpu_ran to be per s2 mmu
> KVM: arm64: nv: Don't always start an S2 MMU search from the beginning
> KVM: arm64: nv: Propagate CNTVOFF_EL2 to the virtual EL1 timer
> KVM: arm64: nv: Load timer before the GIC
> KVM: arm64: nv: Implement maintenance interrupt forwarding
> arm64: KVM: nv: Add handling of EL2-specific timer registers
> arm64: KVM: nv: Honor SCTLR_EL2.SPAN on entering vEL2
> arm64: KVM: nv: Handle SCTLR_EL2 RES0/RES1 bits
> arm64: KVM: nv: Restrict S2 RD/WR permissions to match the guest's
> arm64: KVM: nv: Allow userspace to request KVM_ARM_VCPU_NESTED_VIRT
>
> .../admin-guide/kernel-parameters.txt | 4 +
> .../virtual/kvm/devices/arm-vgic-v3.txt | 9 +
> arch/arm/include/asm/kvm_asm.h | 5 +-
> arch/arm/include/asm/kvm_emulate.h | 3 +
> arch/arm/include/asm/kvm_host.h | 31 +-
> arch/arm/include/asm/kvm_hyp.h | 25 +-
> arch/arm/include/asm/kvm_mmu.h | 83 +-
> arch/arm/include/asm/kvm_nested.h | 9 +
> arch/arm/include/uapi/asm/kvm.h | 1 +
> arch/arm/kvm/hyp/switch.c | 11 +-
> arch/arm/kvm/hyp/tlb.c | 13 +-
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/esr.h | 4 +-
> arch/arm64/include/asm/kvm_arm.h | 28 +-
> arch/arm64/include/asm/kvm_asm.h | 9 +-
> arch/arm64/include/asm/kvm_coproc.h | 2 +-
> arch/arm64/include/asm/kvm_emulate.h | 157 +-
> arch/arm64/include/asm/kvm_host.h | 105 +-
> arch/arm64/include/asm/kvm_hyp.h | 82 +-
> arch/arm64/include/asm/kvm_mmu.h | 62 +-
> arch/arm64/include/asm/kvm_nested.h | 68 +
> arch/arm64/include/asm/sysreg.h | 143 +-
> arch/arm64/include/uapi/asm/kvm.h | 2 +
> arch/arm64/kernel/cpufeature.c | 26 +
> arch/arm64/kvm/Makefile | 4 +
> arch/arm64/kvm/emulate-nested.c | 223 +++
> arch/arm64/kvm/guest.c | 6 +
> arch/arm64/kvm/handle_exit.c | 76 +-
> arch/arm64/kvm/hyp/Makefile | 1 +
> arch/arm64/kvm/hyp/at.c | 217 +++
> arch/arm64/kvm/hyp/switch.c | 86 +-
> arch/arm64/kvm/hyp/sysreg-sr.c | 267 ++-
> arch/arm64/kvm/hyp/tlb.c | 129 +-
> arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 2 +-
> arch/arm64/kvm/inject_fault.c | 12 -
> arch/arm64/kvm/nested.c | 551 +++++++
> arch/arm64/kvm/regmap.c | 4 +-
> arch/arm64/kvm/reset.c | 7 +
> arch/arm64/kvm/sys_regs.c | 1460 +++++++++++++++--
> arch/arm64/kvm/sys_regs.h | 6 +
> arch/arm64/kvm/trace.h | 58 +-
> include/kvm/arm_arch_timer.h | 6 +
> include/kvm/arm_vgic.h | 28 +-
> virt/kvm/arm/arch_timer.c | 158 +-
> virt/kvm/arm/arm.c | 62 +-
> virt/kvm/arm/hyp/vgic-v3-sr.c | 35 +-
> virt/kvm/arm/mmio.c | 12 +-
> virt/kvm/arm/mmu.c | 445 +++--
> virt/kvm/arm/trace.h | 6 +-
> virt/kvm/arm/vgic/vgic-init.c | 30 +
> virt/kvm/arm/vgic/vgic-kvm-device.c | 22 +
> virt/kvm/arm/vgic/vgic-nested-trace.h | 137 ++
> virt/kvm/arm/vgic/vgic-v2.c | 10 +-
> virt/kvm/arm/vgic/vgic-v3-nested.c | 236 +++
> virt/kvm/arm/vgic/vgic-v3.c | 40 +-
> virt/kvm/arm/vgic/vgic.c | 74 +-
> 56 files changed, 4683 insertions(+), 612 deletions(-)
> create mode 100644 arch/arm/include/asm/kvm_nested.h
> create mode 100644 arch/arm64/include/asm/kvm_nested.h
> create mode 100644 arch/arm64/kvm/emulate-nested.c
> create mode 100644 arch/arm64/kvm/hyp/at.c
> create mode 100644 arch/arm64/kvm/nested.c
> create mode 100644 virt/kvm/arm/vgic/vgic-nested-trace.h
> create mode 100644 virt/kvm/arm/vgic/vgic-v3-nested.c
>
When working on adding support for EL2 to kvm-unit-tests I was able to trigger
the following warning:
# ./lkvm run -f psci.flat -m 128 -c 8 --console serial --irqchip gicv3 --nested
# lkvm run --firmware psci.flat -m 128 -c 8 --name guest-151
Info: Placing fdt at 0x80200000 - 0x80210000
# Warning: The maximum recommended amount of VCPUs is 4
chr_testdev_init: chr-testdev: can't find a virtio-console
INFO: PSCI version 1.0
PASS: invalid-function
PASS: affinity-info-on
PASS: affinity-info-off
[ 24.381266] WARNING: CPU: 3 PID: 160 at
arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
kvm_timer_irq_can_fire+0xc/0x30
[ 24.381366] Modules linked in:
[ 24.381466] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Not tainted
5.2.0-rc5-00060-g7dbce63bd1c7 #145
[ 24.381566] Hardware name: Foundation-v8A (DT)
[ 24.381566] pstate: 40400009 (nZcv daif +PAN -UAO)
[ 24.381666] pc : kvm_timer_irq_can_fire+0xc/0x30
[ 24.381766] lr : timer_emulate+0x24/0x98
[ 24.381766] sp : ffff000013d8b780
[ 24.381866] x29: ffff000013d8b780 x28: ffff80087a639b80
[ 24.381966] x27: ffff000010ba8648 x26: ffff000010b71b40
[ 24.382066] x25: ffff80087a63a100 x24: 0000000000000000
[ 24.382111] x23: 000080086ca54000 x22: ffff0000100ce260
[ 24.382166] x21: ffff800875e7c918 x20: ffff800875e7a800
[ 24.382275] x19: ffff800875e7ca08 x18: 0000000000000000
[ 24.382366] x17: 0000000000000000 x16: 0000000000000000
[ 24.382466] x15: 0000000000000000 x14: 0000000000002118
[ 24.382566] x13: 0000000000002190 x12: 0000000000002280
[ 24.382566] x11: 0000000000002208 x10: 0000000000000040
[ 24.382666] x9 : ffff000012dc3b38 x8 : 0000000000000000
[ 24.382766] x7 : 0000000000000000 x6 : ffff80087ac00248
[ 24.382866] x5 : 000080086ca54000 x4 : 0000000000002118
[ 24.382966] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
[ 24.383066] x1 : 0000000000000001 x0 : ffff800875e7ca08
[ 24.383066] Call trace:
[ 24.383166] kvm_timer_irq_can_fire+0xc/0x30
[ 24.383266] kvm_timer_vcpu_load+0x9c/0x1a0
[ 24.383366] kvm_arch_vcpu_load+0xb0/0x1f0
[ 24.383366] kvm_sched_in+0x1c/0x28
[ 24.383466] finish_task_switch+0xd8/0x1d8
[ 24.383566] __schedule+0x248/0x4a0
[ 24.383666] preempt_schedule_irq+0x60/0x90
[ 24.383666] el1_irq+0xd0/0x180
[ 24.383766] kvm_handle_guest_abort+0x0/0x3a0
[ 24.383866] kvm_arch_vcpu_ioctl_run+0x41c/0x688
[ 24.383866] kvm_vcpu_ioctl+0x4c0/0x838
[ 24.383966] do_vfs_ioctl+0xb8/0x878
[ 24.384077] ksys_ioctl+0x84/0x90
[ 24.384166] __arm64_sys_ioctl+0x18/0x28
[ 24.384166] el0_svc_common.constprop.0+0xb0/0x168
[ 24.384266] el0_svc_handler+0x28/0x78
[ 24.384366] el0_svc+0x8/0xc
[ 24.384366] ---[ end trace 37a32293e43ac12c ]---
[ 24.384666] WARNING: CPU: 3 PID: 160 at
arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
kvm_timer_irq_can_fire+0xc/0x30
[ 24.384766] Modules linked in:
[ 24.384866] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
5.2.0-rc5-00060-g7dbce63bd1c7 #145
[ 24.384966] Hardware name: Foundation-v8A (DT)
[ 24.384966] pstate: 40400009 (nZcv daif +PAN -UAO)
[ 24.385066] pc : kvm_timer_irq_can_fire+0xc/0x30
[ 24.385166] lr : timer_emulate+0x24/0x98
[ 24.385166] sp : ffff000013d8b780
[ 24.385266] x29: ffff000013d8b780 x28: ffff80087a639b80
[ 24.385366] x27: ffff000010ba8648 x26: ffff000010b71b40
[ 24.385466] x25: ffff80087a63a100 x24: 0000000000000000
[ 24.385466] x23: 000080086ca54000 x22: ffff0000100ce260
[ 24.385566] x21: ffff800875e7c918 x20: ffff800875e7a800
[ 24.385666] x19: ffff800875e7ca80 x18: 0000000000000000
[ 24.385766] x17: 0000000000000000 x16: 0000000000000000
[ 24.385866] x15: 0000000000000000 x14: 0000000000002118
[ 24.385966] x13: 0000000000002190 x12: 0000000000002280
[ 24.385966] x11: 0000000000002208 x10: 0000000000000040
[ 24.386066] x9 : ffff000012dc3b38 x8 : 0000000000000000
[ 24.386166] x7 : 0000000000000000 x6 : ffff80087ac00248
[ 24.386266] x5 : 000080086ca54000 x4 : 0000000000002118
[ 24.386366] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
[ 24.386466] x1 : 0000000000000001 x0 : ffff800875e7ca80
[ 24.386466] Call trace:
[ 24.386566] kvm_timer_irq_can_fire+0xc/0x30
[ 24.386666] kvm_timer_vcpu_load+0xa8/0x1a0
[ 24.386666] kvm_arch_vcpu_load+0xb0/0x1f0
[ 24.386898] kvm_sched_in+0x1c/0x28
[ 24.386966] finish_task_switch+0xd8/0x1d8
[ 24.387166] __schedule+0x248/0x4a0
[ 24.387354] preempt_schedule_irq+0x60/0x90
[ 24.387366] el1_irq+0xd0/0x180
[ 24.387466] kvm_handle_guest_abort+0x0/0x3a0
[ 24.387566] kvm_arch_vcpu_ioctl_run+0x41c/0x688
[ 24.387566] kvm_vcpu_ioctl+0x4c0/0x838
[ 24.387666] do_vfs_ioctl+0xb8/0x878
[ 24.387766] ksys_ioctl+0x84/0x90
[ 24.387866] __arm64_sys_ioctl+0x18/0x28
[ 24.387866] el0_svc_common.constprop.0+0xb0/0x168
[ 24.387966] el0_svc_handler+0x28/0x78
[ 24.388066] el0_svc+0x8/0xc
[ 24.388066] ---[ end trace 37a32293e43ac12d ]---
PASS: cpu-on
SUMMARY: 4 te[ 24.390266] WARNING: CPU: 3 PID: 160 at
arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
kvm_timer_irq_can_fire+0xc/0x30
s[ 24.390366] Modules linked in:
ts[ 24.390366] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
5.2.0-rc5-00060-g7dbce63bd1c7 #145
[ 24.390566] Hardware name: Foundation-v8A (DT)
[ 24.390795] pstate: 40400009 (nZcv daif +PAN -UAO)
[ 24.390866] pc : kvm_timer_irq_can_fire+0xc/0x30
[ 24.390966] lr : timer_emulate+0x24/0x98
[ 24.391066] sp : ffff000013d8b780
[ 24.391066] x29: ffff000013d8b780 x28: ffff80087a639b80
[ 24.391166] x27: ffff000010ba8648 x26: ffff000010b71b40
[ 24.391266] x25: ffff80087a63a100 x24: 0000000000000000
[ 24.391366] x23: 000080086ca54000 x22: 0000000000000003
[ 24.391466] x21: ffff800875e7c918 x20: ffff800875e7a800
[ 24.391466] x19: ffff800875e7ca08 x18: 0000000000000000
[ 24.391566] x17: 0000000000000000 x16: 0000000000000000
[ 24.391666] x15: 0000000000000000 x14: 0000000000002118
[ 24.391766] x13: 0000000000002190 x12: 0000000000002280
[ 24.391866] x11: 0000000000002208 x10: 0000000000000040
[ 24.391942] x9 : ffff000012dc3b38 x8 : 0000000000000000
[ 24.391966] x7 : 0000000000000000 x6 : ffff80087ac00248
[ 24.392066] x5 : 000080086ca54000 x4 : 0000000000002118
[ 24.392166] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
[ 24.392269] x1 : 0000000000000001 x0 : ffff800875e7ca08
[ 24.392366] Call trace:
[ 24.392433] kvm_timer_irq_can_fire+0xc/0x30
[ 24.392466] kvm_timer_vcpu_load+0x9c/0x1a0
[ 24.392597] kvm_arch_vcpu_load+0xb0/0x1f0
[ 24.392666] kvm_sched_in+0x1c/0x28
[ 24.392766] finish_task_switch+0xd8/0x1d8
[ 24.392766] __schedule+0x248/0x4a0
[ 24.392866] preempt_schedule_irq+0x60/0x90
[ 24.392966] el1_irq+0xd0/0x180
[ 24.392966] kvm_handle_guest_abort+0x0/0x3a0
[ 24.393066] kvm_arch_vcpu_ioctl_run+0x41c/0x688
[ 24.393166] kvm_vcpu_ioctl+0x4c0/0x838
[ 24.393266] do_vfs_ioctl+0xb8/0x878
[ 24.393266] ksys_ioctl+0x84/0x90
[ 24.393366] __arm64_sys_ioctl+0x18/0x28
[ 24.393466] el0_svc_common.constprop.0+0xb0/0x168
[ 24.393566] el0_svc_handler+0x28/0x78
[ 24.393566] el0_svc+0x8/0xc
[ 24.393666] ---[ end trace 37a32293e43ac12e ]---
[ 24.393866] WARNING: CPU: 3 PID: 160 at
arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
kvm_timer_irq_can_fire+0xc/0x30
[ 24.394066] Modules linked in:
[ 24.394266] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
5.2.0-rc5-00060-g7dbce63bd1c7 #145
[ 24.394366] Hardware name: Foundation-v8A (DT)
[ 24.394466] pstate: 40400009 (nZcv daif +PAN -UAO)
[ 24.394466] pc : kvm_timer_irq_can_fire+0xc/0x30
[ 24.394566] lr : timer_emulate+0x24/0x98
[ 24.394666] sp : ffff000013d8b780
[ 24.394727] x29: ffff000013d8b780 x28: ffff80087a639b80
[ 24.394766] x27: ffff000010ba8648 x26: ffff000010b71b40
[ 24.394866] x25: ffff80087a63a100 x24: 0000000000000000
[ 24.394966] x23: 000080086ca54000 x22: 0000000000000003
[ 24.394966] x21: ffff800875e7c918 x20: ffff800875e7a800
[ 24.395066] x19: ffff800875e7ca80 x18: 0000000000000000
[ 24.395166] x17: 0000000000000000 x16: 0000000000000000
[ 24.395266] x15: 0000000000000000 x14: 0000000000002118
[ 24.395383] x13: 0000000000002190 x12: 0000000000002280
[ 24.395466] x11: 0000000000002208 x10: 0000000000000040
[ 24.395547] x9 : ffff000012dc3b38 x8 : 0000000000000000
[ 24.395666] x7 : 0000000000000000 x6 : ffff80087ac00248
[ 24.395866] x5 : 000080086ca54000 x4 : 0000000000002118
[ 24.395966] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
[ 24.396066] x1 : 0000000000000001 x0 : ffff800875e7ca80
[ 24.396066] Call trace:
[ 24.396166] kvm_timer_irq_can_fire+0xc/0x30
[ 24.396266] kvm_timer_vcpu_load+0xa8/0x1a0
[ 24.396366] kvm_arch_vcpu_load+0xb0/0x1f0
[ 24.396366] kvm_sched_in+0x1c/0x28
[ 24.396466] finish_task_switch+0xd8/0x1d8
[ 24.396566] __schedule+0x248/0x4a0
[ 24.396666] preempt_schedule_irq+0x60/0x90
[ 24.396666] el1_irq+0xd0/0x180
[ 24.396766] kvm_handle_guest_abort+0x0/0x3a0
[ 24.396866] kvm_arch_vcpu_ioctl_run+0x41c/0x688
[ 24.396866] kvm_vcpu_ioctl+0x4c0/0x838
[ 24.397021] do_vfs_ioctl+0xb8/0x878
[ 24.397066] ksys_ioctl+0x84/0x90
[ 24.397166] __arm64_sys_ioctl+0x18/0x28
[ 24.397348] el0_svc_common.constprop.0+0xb0/0x168
[ 24.397366] el0_svc_handler+0x28/0x78
[ 24.397566] el0_svc+0x8/0xc
[ 24.397676] ---[ end trace 37a32293e43ac12f ]---
# KVM compatibility warning.
virtio-9p device was not detected.
While you have requested a virtio-9p device, the guest kernel did not
initialize it.
Please make sure that the guest kernel was compiled with
CONFIG_NET_9P_VIRTIO=y enabled in .config.
# KVM compatibility warning.
virtio-net device was not detected.
While you have requested a virtio-net device, the guest kernel did not
initialize it.
Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y
enabled in .config.
These are the changes that I made to kvm-unit-tests (the diff can be applied on
top of upstream master, 2130fd4154ad ("tscdeadline_latency: Check condition
first before loop")):
diff --git a/arm/cstart64.S b/arm/cstart64.S
index b0e8baa1a23a..a7631b5a1801 100644
--- a/arm/cstart64.S
+++ b/arm/cstart64.S
@@ -51,6 +51,17 @@ start:
b 1b
1:
+ mrs x4, CurrentEL
+ cmp x4, CurrentEL_EL2
+ b.ne 1f
+ mrs x4, mpidr_el1
+ msr vmpidr_el2, x4
+ mrs x4, midr_el1
+ msr vpidr_el2, x4
+ ldr x4, =(HCR_EL2_TGE | HCR_EL2_E2H)
+ msr hcr_el2, x4
+ isb
+1:
/* set up stack */
mov x4, #1
msr spsel, x4
@@ -101,6 +112,17 @@ get_mmu_off:
.globl secondary_entry
secondary_entry:
+ mrs x0, CurrentEL
+ cmp x0, CurrentEL_EL2
+ b.ne 1f
+ mrs x0, mpidr_el1
+ msr vmpidr_el2, x0
+ mrs x0, midr_el1
+ msr vpidr_el2, x0
+ ldr x0, =(HCR_EL2_TGE | HCR_EL2_E2H)
+ msr hcr_el2, x0
+ isb
+1:
/* Enable FP/ASIMD */
mov x0, #(3 << 20)
msr cpacr_el1, x0
diff --git a/lib/arm/asm/psci.h b/lib/arm/asm/psci.h
index 7b956bf5987d..07297a27e0ce 100644
--- a/lib/arm/asm/psci.h
+++ b/lib/arm/asm/psci.h
@@ -3,6 +3,15 @@
#include <libcflat.h>
#include <linux/psci.h>
+enum psci_conduit {
+ PSCI_CONDUIT_HVC,
+ PSCI_CONDUIT_SMC,
+};
+
+extern void psci_init(void);
+extern void psci_set_conduit(enum psci_conduit conduit);
+extern enum psci_conduit psci_get_conduit(void);
+
extern int psci_invoke(unsigned long function_id, unsigned long arg0,
unsigned long arg1, unsigned long arg2);
extern int psci_cpu_on(unsigned long cpuid, unsigned long entry_point);
diff --git a/lib/arm/psci.c b/lib/arm/psci.c
index c3d399064ae3..20ad4b944738 100644
--- a/lib/arm/psci.c
+++ b/lib/arm/psci.c
@@ -6,13 +6,14 @@
*
* This work is licensed under the terms of the GNU LGPL, version 2.
*/
+#include <devicetree.h>
+#include <string.h>
#include <asm/psci.h>
#include <asm/setup.h>
#include <asm/page.h>
#include <asm/smp.h>
-__attribute__((noinline))
-int psci_invoke(unsigned long function_id, unsigned long arg0,
+static int psci_invoke_hvc(unsigned long function_id, unsigned long arg0,
unsigned long arg1, unsigned long arg2)
{
asm volatile(
@@ -22,6 +23,63 @@ int psci_invoke(unsigned long function_id, unsigned long arg0,
return function_id;
}
+static int psci_invoke_smc(unsigned long function_id, unsigned long arg0,
+ unsigned long arg1, unsigned long arg2)
+{
+ asm volatile(
+ "smc #0"
+ : "+r" (function_id)
+ : "r" (arg0), "r" (arg1), "r" (arg2));
+ return function_id;
+}
+
+/*
+ * Initialize to something sensible, so the exit fallback psci_system_off still
+ * works before calling psci_init when booted at EL1.
+ */
+static enum psci_conduit psci_conduit = PSCI_CONDUIT_HVC;
+static int (*psci_fn)(unsigned long, unsigned long, unsigned long,
+ unsigned long) = &psci_invoke_hvc;
+
+void psci_set_conduit(enum psci_conduit conduit)
+{
+ psci_conduit = conduit;
+ if (conduit == PSCI_CONDUIT_HVC)
+ psci_fn = &psci_invoke_hvc;
+ else
+ psci_fn = &psci_invoke_smc;
+}
+
+enum psci_conduit psci_get_conduit(void)
+{
+ return psci_conduit;
+}
+
+int psci_invoke(unsigned long function_id, unsigned long arg0,
+ unsigned long arg1, unsigned long arg2)
+{
+ return psci_fn(function_id, arg0, arg1, arg2);
+}
+
+void psci_init(void)
+{
+ const char *conduit;
+ int ret;
+
+ ret = dt_get_psci_conduit(&conduit);
+ assert(ret == 0 || ret == -FDT_ERR_NOTFOUND);
+
+ if (ret == -FDT_ERR_NOTFOUND)
+ conduit = "hvc";
+
+ assert(strcmp(conduit, "hvc") == 0 || strcmp(conduit, "smc") == 0);
+
+ if (strcmp(conduit, "hvc") == 0)
+ psci_set_conduit(PSCI_CONDUIT_HVC);
+ else
+ psci_set_conduit(PSCI_CONDUIT_SMC);
+}
+
int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
{
#ifdef __arm__
diff --git a/lib/arm/setup.c b/lib/arm/setup.c
index 4f02fca85607..e0dc9e4801b0 100644
--- a/lib/arm/setup.c
+++ b/lib/arm/setup.c
@@ -21,6 +21,7 @@
#include <asm/setup.h>
#include <asm/page.h>
#include <asm/smp.h>
+#include <asm/psci.h>
#include "io.h"
@@ -164,7 +165,11 @@ void setup(const void *fdt)
freemem += initrd_size;
}
- /* call init functions */
+ /*
+ * call init functions. psci_init goes first so psci_system_off fallback
+ * works in case of an assert failure
+ */
+ psci_init();
mem_init(PAGE_ALIGN((unsigned long)freemem));
cpu_init();
diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
index 1d9223f728a5..18c5d29ddd1f 100644
--- a/lib/arm64/asm/processor.h
+++ b/lib/arm64/asm/processor.h
@@ -16,6 +16,9 @@
#define SCTLR_EL1_A (1 << 1)
#define SCTLR_EL1_M (1 << 0)
+#define HCR_EL2_TGE (1 << 27)
+#define HCR_EL2_E2H (1 << 34)
+
#ifndef __ASSEMBLY__
#include <asm/ptrace.h>
#include <asm/esr.h>
diff --git a/lib/devicetree.c b/lib/devicetree.c
index 2b89178a109b..4e684c7100b2 100644
--- a/lib/devicetree.c
+++ b/lib/devicetree.c
@@ -263,6 +263,27 @@ int dt_get_bootargs(const char **bootargs)
return 0;
}
+int dt_get_psci_conduit(const char **conduit)
+{
+ const struct fdt_property *prop;
+ int node, len;
+
+ *conduit = NULL;
+
+ node = fdt_node_offset_by_compatible(fdt, -1, "arm,psci-0.2");
+ if (node < 0)
+ return node;
+
+ prop = fdt_get_property(fdt, node, "method", &len);
+ if (!prop)
+ return len;
+ if (len < 4)
+ return -FDT_ERR_NOTFOUND;
+
+ *conduit = prop->data;
+ return 0;
+}
+
int dt_get_default_console_node(void)
{
const struct fdt_property *prop;
diff --git a/lib/devicetree.h b/lib/devicetree.h
index 93c7ebc63bd8..236035eb777d 100644
--- a/lib/devicetree.h
+++ b/lib/devicetree.h
@@ -211,6 +211,15 @@ extern int dt_get_reg(int fdtnode, int regidx, struct
dt_reg *reg);
extern int dt_get_bootargs(const char **bootargs);
/*
+ * dt_get_psci_conduit gets the conduit for PSCI function invocations from
+ * /psci/method
+ * returns
+ * - zero on success
+ * - a negative FDT_ERR_* value on failure, and @conduit will be set to null
+ */
+extern int dt_get_psci_conduit(const char **conduit);
+
+/*
* dt_get_default_console_node gets the node of the path stored in
* /chosen/stdout-path (or the deprecated /chosen/linux,stdout-path)
* returns
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox