* [PATCH 03/20] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Joel Stanley @ 2017-12-11 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2psgOYZEgO8O3H_xxpDTNd=ESJpSf4bs9kf0nPvKYqtQ@mail.gmail.com>
On Mon, Dec 11, 2017 at 6:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote:
>> This should have always been 8.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>
> As this is a bugfix, should we backport it to stable kernels? When you
> fix a bug,
> I generally recommend including a 'Fixes' tag with the commit ID of the patch
> that introduced the problem, and either a 'Cc: stable at vger.kernel.org' tag
> if you want it backported, or an explanation in the changelog why it should
> not get backported. This really helps Greg and the other stable maintainers
> trying to make a decision what to backport and what not.
We could do this, and I generally follow the practice of adding Fixes
tags. I hadn't because without an upstream clock driver, the Aspeed
port is not usable by anyone without making modifications. We're
really depending on getting that code merged.
I will send it as a fix to 4.15. Do you mind taking individual patches
for the arm dt tree, or would you prefer a pull request?
Cheers,
Joel
^ permalink raw reply
* [PATCH 05/20] ARM: dts: aspeed: Add proper clock references
From: Joel Stanley @ 2017-12-11 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a10wjXvFpE5zbwCfQNC-UiRCzKE+9-ENg-Sr577ZCF+Xw@mail.gmail.com>
On Mon, Dec 11, 2017 at 6:39 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote:
>> The existing device trees use fixed-clocks in order to boot without a
>> clk driver. The newly added clk driver provides proper clock support,
>> including gating, so we move the device trees over to properly request
>> clocks.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>
> Can you clarify here whether this will break running old kernels with
> new DT files or vice versa, and why this is ok here?
This device tree will break kernels that do not have the clk patches
applied (no clocksource, as we don't know the speed of the APB clock.
You can boot if you pass a lpj value on the command line, but won't
have a uart).
Older device trees running with the newer kernel will function as well
as pre-4.16 kernels. That is, that some IP blocks (i2c, pwm/tach, adc)
will not work as the kernel lacks reset controller and clock enabling.
> I assume you have thought about it carefully, but I'd still like to document
> every time we intentionally break compatibility like this. It looks like
> you too care to merge the driver changes and the DT binding change first,
> so we don't get any bisection problems.
Thanks for calling it out. I will modify the commit message to say
that this device tree change depends on the newer driver, and it will
not boot with kernels that lack the driver.
>
> What I'm not completely clear about is the difference between the
> "aspeed,g4-scu" binding and the "aspeed,ast2400-scu" binding.
> They are listed as equal in
> Documentation/devicetree/bindings/mfd/aspeed-scu.txt, so why do you
> change it here?
The g4-scu string made it into the tree before we had decided that we
would settle on aspeed,astX000-<ip> as the format for the strings. We
list both in the docs, but I would like to deprecate the old one.
If I was doing this again, I would make sure we had the clock driver
upstream before completing the other driver. It's caused a lot of
pain. Thanks for your help getting us there.
Cheers,
Joel
^ permalink raw reply
* [PATCH v2 20/36] KVM: arm64: Don't save the host ELR_EL2 and SPSR_EL2 on VHE systems
From: Marc Zyngier @ 2017-12-11 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207170630.592-21-christoffer.dall@linaro.org>
On 07/12/17 17:06, Christoffer Dall wrote:
> On non-VHE systems we need to save the ELR_EL2 and SPSR_EL2 so that we
> can return to the host in EL1 in the same state and location where we
> issued a hypercall to EL2, but these registers don't contain anything
> important on VHE, because all of the host runs in EL2. Therefore,
If I may refine the rational: ELR_EL2 and SPSR_EL2 are not useful here
because we never enter a guest as a result of an exception entry that
would be directly handled by KVM. The kernel entry code already saves
ELR_EL1/SPSR_EL1 on exception entry, which is enough.
> factor out these registers into separate save/restore functions, making
> it easy to exclude them from the VHE world-switch path later on.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/arm64/kvm/hyp/sysreg-sr.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index a12112494f75..479de0f0dd07 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -71,6 +71,10 @@ static void __hyp_text __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
> ctxt->gp_regs.sp_el1 = read_sysreg(sp_el1);
> ctxt->gp_regs.elr_el1 = read_sysreg_el1(elr);
> ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
> +}
> +
> +static void __hyp_text __sysreg_save_el2_return_state(struct kvm_cpu_context *ctxt)
> +{
> ctxt->gp_regs.regs.pc = read_sysreg_el2(elr);
> ctxt->gp_regs.regs.pstate = read_sysreg_el2(spsr);
> }
> @@ -80,6 +84,7 @@ void __hyp_text __sysreg_save_state_nvhe(struct kvm_cpu_context *ctxt)
> __sysreg_save_el1_state(ctxt);
> __sysreg_save_common_state(ctxt);
> __sysreg_save_user_state(ctxt);
> + __sysreg_save_el2_return_state(ctxt);
> }
>
> void sysreg_save_host_state_vhe(struct kvm_cpu_context *ctxt)
> @@ -93,6 +98,7 @@ void sysreg_save_guest_state_vhe(struct kvm_cpu_context *ctxt)
> __sysreg_save_el1_state(ctxt);
> __sysreg_save_common_state(ctxt);
> __sysreg_save_user_state(ctxt);
> + __sysreg_save_el2_return_state(ctxt);
> }
>
> static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> @@ -137,6 +143,11 @@ static void __hyp_text __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
> write_sysreg(ctxt->gp_regs.sp_el1, sp_el1);
> write_sysreg_el1(ctxt->gp_regs.elr_el1, elr);
> write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
> +}
> +
> +static void __hyp_text
> +__sysreg_restore_el2_return_state(struct kvm_cpu_context *ctxt)
> +{
> write_sysreg_el2(ctxt->gp_regs.regs.pc, elr);
> write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
> }
> @@ -146,6 +157,7 @@ void __hyp_text __sysreg_restore_state_nvhe(struct kvm_cpu_context *ctxt)
> __sysreg_restore_el1_state(ctxt);
> __sysreg_restore_common_state(ctxt);
> __sysreg_restore_user_state(ctxt);
> + __sysreg_restore_el2_return_state(ctxt);
> }
>
> void sysreg_restore_host_state_vhe(struct kvm_cpu_context *ctxt)
> @@ -159,6 +171,7 @@ void sysreg_restore_guest_state_vhe(struct kvm_cpu_context *ctxt)
> __sysreg_restore_el1_state(ctxt);
> __sysreg_restore_common_state(ctxt);
> __sysreg_restore_user_state(ctxt);
> + __sysreg_restore_el2_return_state(ctxt);
> }
>
> static void __hyp_text __fpsimd32_save_state(struct kvm_cpu_context *ctxt)
>
Otherwise:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
From: Mark Rutland @ 2017-12-11 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512957823-18064-2-git-send-email-shankerd@codeaurora.org>
Hi,
On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote:
> +/**
> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
> + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
> + */
> + .macro pre_disable_mmu_workaround
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
> + isb
> +alternative_else_nop_endif
> +#endif
> + .endm
There's really no need for this to be an alternative. It makes the
kernel larger and more complex due to all the altinstr data and probing
code.
As Will suggested last time [1], please just use the ifdef, and always
compile-in the extra ISB if CONFIG_QCOM_FALKOR_ERRATUM_E1041 is
selected. Get rid of the alternatives and probing code.
All you need here is:
/*
* Some Falkor parts make errant speculative instruction fetches
* when SCTLR_ELx.M is cleared. An ISB before the write to
* SCTLR_ELx prevents this.
*/
.macro pre_disable_mmu_workaround
#ifdef
isb
#endif
.endm
> +
> + .macro pre_disable_mmu_early_workaround
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
> + isb
> +#endif
> + .endm
> +
... and we don't need a special early variant.
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20171201112457.GE18083 at arm.com
^ permalink raw reply
* [PATCH v3 0/4] rtc: add mxc driver for i.MX53 SRTC
From: linux-kernel-dev at beckhoff.com @ 2017-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
This is driver enables support for the low power domain SRTC features:
- 32-bit MSB of non-rollover time counter
- 32-bit alarm register
Select the new config option RTC_DRV_MXC_V2 to build this driver
Based on:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
---
Open issue:
- naming of the device tree node "rtc" vs. "srtc"
v3:
- introduce new config option with the same patch, which adds the driver
- call rtc_update_irq() only if necessary
- merge mxc_rtc_write_alarm_locked() with mxc_rtc_set_alarm()
- only use clk_enable/disable (without "prepare") during operation
- rebase on v4.15-rc3
- consistently use rtc_tm_to_time64() and time64_t
- refactor mxc_rtc_read_time(): don't lock for readl() only;
don't rtc_valid_tm(); use time64_t
- check returncode of mxc_rtc_wait_for_flag()
- restructure mxc_rtc_sync_lp_locked() to replace pr_err() with
dev_err_once(); remove explicit 'inline'
- don't touch imx_v4_v5_defconfig, instead add to imx_v6_v7_defconfig
v2:
- have seperate patches for dt-binding, CONFIG option, imx53.dtsi and driver
- add SPDX-License-Identifier and cleanup copyright notice
- replace __raw_readl/writel() with readl/writel()
- fix PM_SLEEP callbacks
- add CONFIG_RTC_DRV_MXC_V2 to build rtc-mxc_v2.c
- remove misleading or obvious comments and fix style of the remaining
- avoid endless loop while waiting for hw
- implement consistent locking; make spinlock a member of dev struct
- enable clk only for register accesses
- remove all udelay() calls since they are obsolete or redundant
(we are already waiting for register flags to change)
- init platform_data before registering irq callback
- let set_time() fail, when 32 bit rtc counter exceeded
- make names more consistent
- cleanup and reorder includes
- cleanup and remove unused defines
To: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
Patrick Bruenn (4):
dt-bindings: rtc: add bindings for i.MX53 SRTC
ARM: dts: imx53: add srtc node
rtc: add mxc driver for i.MX53 SRTC
ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2
.../devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 +
arch/arm/boot/dts/imx53.dtsi | 7 +
arch/arm/configs/imx_v6_v7_defconfig | 1 +
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-mxc_v2.c | 422 +++++++++++++++++++++
6 files changed, 458 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
create mode 100644 drivers/rtc/rtc-mxc_v2.c
--
2.11.0
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: linux-kernel-dev at beckhoff.com @ 2017-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-1-linux-kernel-dev@beckhoff.com>
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Document the binding for i.MX53 SRTC implemented by rtc-mxc_v2
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com><Paste>
---
v2:
- added "Secure" and (SRTC) to the description
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
---
Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
new file mode 100644
index 000000000000..454a08918cc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
@@ -0,0 +1,17 @@
+* i.MX53 Secure Real Time Clock (SRTC)
+
+Required properties:
+- compatible: should be: "fsl,imx53-rtc"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks: should contain the phandle for the rtc clock
+- interrupts: rtc alarm interrupt
+
+Example:
+
+srtc at 53fa4000 {
+ compatible = "fsl,imx53-rtc";
+ reg = <0x53fa4000 0x4000>;
+ interrupts = <24>;
+ clocks = <&clks IMX5_CLK_SRTC_GATE>;
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/4] ARM: dts: imx53: add srtc node
From: linux-kernel-dev at beckhoff.com @ 2017-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-1-linux-kernel-dev@beckhoff.com>
From: Patrick Bruenn <p.bruenn@beckhoff.com>
rtc-mxc_v2 driver will add support for the i.MX53 SRTC
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
---
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
---
arch/arm/boot/dts/imx53.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 84f17f7abb71..e4ca9d9ba2fe 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -433,6 +433,13 @@
clock-names = "ipg", "per";
};
+ srtc: srtc at 53fa4000 {
+ compatible = "fsl,imx53-rtc";
+ reg = <0x53fa4000 0x4000>;
+ interrupts = <24>;
+ clocks = <&clks IMX5_CLK_SRTC_GATE>;
+ };
+
iomuxc: iomuxc at 53fa8000 {
compatible = "fsl,imx53-iomuxc";
reg = <0x53fa8000 0x4000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/4] rtc: add mxc driver for i.MX53 SRTC
From: linux-kernel-dev at beckhoff.com @ 2017-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-1-linux-kernel-dev@beckhoff.com>
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
This is driver enables support for the low power domain SRTC features:
- 32-bit MSB of non-rollover time counter
- 32-bit alarm register
Select the new config option RTC_DRV_MXC_V2 to build this driver
Based on:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
---
Open issue:
- naming of the device tree node "rtc" vs. "srtc"
v3:
- introduce new config option with the same patch, which adds the driver
- call rtc_update_irq() only if necessary
- merge mxc_rtc_write_alarm_locked() with mxc_rtc_set_alarm()
- only use clk_enable/disable (without "prepare") during operation
- rebase on v4.15-rc3
- consistently use rtc_tm_to_time64() and time64_t
- refactor mxc_rtc_read_time(): don't lock for readl() only;
don't rtc_valid_tm(); use time64_t
- check returncode of mxc_rtc_wait_for_flag()
- restructure mxc_rtc_sync_lp_locked() to replace pr_err() with
dev_err_once(); remove explicit 'inline'
- don't touch imx_v4_v5_defconfig, instead add to imx_v6_v7_defconfig
v2:
- have seperate patches for dt-binding, CONFIG option, imx53.dtsi and driver
- add SPDX-License-Identifier and cleanup copyright notice
- replace __raw_readl/writel() with readl/writel()
- fix PM_SLEEP callbacks
- add CONFIG_RTC_DRV_MXC_V2 to build rtc-mxc_v2.c
- remove misleading or obvious comments and fix style of the remaining
- avoid endless loop while waiting for hw
- implement consistent locking; make spinlock a member of dev struct
- enable clk only for register accesses
- remove all udelay() calls since they are obsolete or redundant
(we are already waiting for register flags to change)
- init platform_data before registering irq callback
- let set_time() fail, when 32 bit rtc counter exceeded
- make names more consistent
- cleanup and reorder includes
- cleanup and remove unused defines
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-mxc_v2.c | 422 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 433 insertions(+)
create mode 100644 drivers/rtc/rtc-mxc_v2.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b59a31b079a5..440edebf5c71 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1689,6 +1689,16 @@ config RTC_DRV_MXC
This driver can also be built as a module, if so, the module
will be called "rtc-mxc".
+config RTC_DRV_MXC_V2
+ tristate "Freescale MXC Real Time Clock for i.MX53"
+ depends on ARCH_MXC
+ help
+ If you say yes here you get support for the Freescale MXC
+ SRTC module in i.MX53 processor.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-mxc_v2".
+
config RTC_DRV_SNVS
tristate "Freescale SNVS RTC support"
select REGMAP_MMIO
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index f2f50c11dc38..dcf60e61ae5c 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_RTC_DRV_MT6397) += rtc-mt6397.o
obj-$(CONFIG_RTC_DRV_MT7622) += rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
+obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
obj-$(CONFIG_RTC_DRV_NUC900) += rtc-nuc900.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
diff --git a/drivers/rtc/rtc-mxc_v2.c b/drivers/rtc/rtc-mxc_v2.c
new file mode 100644
index 000000000000..b637095b0716
--- /dev/null
+++ b/drivers/rtc/rtc-mxc_v2.c
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Real Time Clock (RTC) Driver for i.MX53
+ * Copyright (c) 2004-2011 Freescale Semiconductor, Inc.
+ * Copyright (c) 2017 Beckhoff Automation GmbH & Co. KG
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#define SRTC_LPPDR_INIT 0x41736166 /* init for glitch detect */
+
+#define SRTC_LPCR_EN_LP BIT(3) /* lp enable */
+#define SRTC_LPCR_WAE BIT(4) /* lp wakeup alarm enable */
+#define SRTC_LPCR_ALP BIT(7) /* lp alarm flag */
+#define SRTC_LPCR_NSA BIT(11) /* lp non secure access */
+#define SRTC_LPCR_NVE BIT(14) /* lp non valid state exit bit */
+#define SRTC_LPCR_IE BIT(15) /* lp init state exit bit */
+
+#define SRTC_LPSR_ALP BIT(3) /* lp alarm flag */
+#define SRTC_LPSR_NVES BIT(14) /* lp non-valid state exit status */
+#define SRTC_LPSR_IES BIT(15) /* lp init state exit status */
+
+#define SRTC_LPSCMR 0x00 /* LP Secure Counter MSB Reg */
+#define SRTC_LPSCLR 0x04 /* LP Secure Counter LSB Reg */
+#define SRTC_LPSAR 0x08 /* LP Secure Alarm Reg */
+#define SRTC_LPCR 0x10 /* LP Control Reg */
+#define SRTC_LPSR 0x14 /* LP Status Reg */
+#define SRTC_LPPDR 0x18 /* LP Power Supply Glitch Detector Reg */
+
+/* max. number of retries to read registers, 120 was max during test */
+#define REG_READ_TIMEOUT 2000
+
+struct mxc_rtc_data {
+ struct rtc_device *rtc;
+ void __iomem *ioaddr;
+ struct clk *clk;
+ spinlock_t lock; /* protects register access */
+ int irq;
+};
+
+/*
+ * This function does write synchronization for writes to the lp srtc block.
+ * To take care of the asynchronous CKIL clock, all writes from the IP domain
+ * will be synchronized to the CKIL domain.
+ * The caller should hold the pdata->lock
+ */
+static void mxc_rtc_sync_lp_locked(struct device *dev, void __iomem *ioaddr)
+{
+ unsigned int i;
+
+ /* Wait for 3 CKIL cycles */
+ for (i = 0; i < 3; i++) {
+ const u32 count = readl(ioaddr + SRTC_LPSCLR);
+ unsigned int timeout = REG_READ_TIMEOUT;
+
+ while ((readl(ioaddr + SRTC_LPSCLR)) == count) {
+ if (!--timeout) {
+ dev_err_once(dev, "SRTC_LPSCLR stuck! Check your hw.\n");
+ return;
+ }
+ }
+ }
+}
+
+/* This function is the RTC interrupt service routine. */
+static irqreturn_t mxc_rtc_interrupt(int irq, void *dev_id)
+{
+ struct device *dev = dev_id;
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ void __iomem *ioaddr = pdata->ioaddr;
+ unsigned long flags;
+ u32 lp_status;
+ u32 lp_cr;
+
+ spin_lock_irqsave(&pdata->lock, flags);
+ if (clk_enable(pdata->clk)) {
+ spin_unlock_irqrestore(&pdata->lock, flags);
+ return IRQ_NONE;
+ }
+
+ lp_status = readl(ioaddr + SRTC_LPSR);
+ lp_cr = readl(ioaddr + SRTC_LPCR);
+
+ /* update irq data & counter */
+ if (lp_status & SRTC_LPSR_ALP) {
+ if (lp_cr & SRTC_LPCR_ALP)
+ rtc_update_irq(pdata->rtc, 1, RTC_AF | RTC_IRQF);
+
+ /* disable further lp alarm interrupts */
+ lp_cr &= ~(SRTC_LPCR_ALP | SRTC_LPCR_WAE);
+ }
+
+ /* Update interrupt enables */
+ writel(lp_cr, ioaddr + SRTC_LPCR);
+
+ /* clear interrupt status */
+ writel(lp_status, ioaddr + SRTC_LPSR);
+
+ mxc_rtc_sync_lp_locked(dev, ioaddr);
+ clk_disable(pdata->clk);
+ spin_unlock_irqrestore(&pdata->lock, flags);
+ return IRQ_HANDLED;
+}
+
+/*
+ * Enable clk and aquire spinlock
+ * @return 0 if successful; non-zero otherwise.
+ */
+static int mxc_rtc_lock(struct mxc_rtc_data *const pdata)
+{
+ int ret;
+
+ spin_lock_irq(&pdata->lock);
+ ret = clk_enable(pdata->clk);
+ if (ret) {
+ spin_unlock_irq(&pdata->lock);
+ return ret;
+ }
+ return 0;
+}
+
+static int mxc_rtc_unlock(struct mxc_rtc_data *const pdata)
+{
+ clk_disable(pdata->clk);
+ spin_unlock_irq(&pdata->lock);
+ return 0;
+}
+
+/*
+ * This function reads the current RTC time into tm in Gregorian date.
+ *
+ * @param tm contains the RTC time value upon return
+ *
+ * @return 0 if successful; non-zero otherwise.
+ */
+static int mxc_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ const int clk_failed = clk_enable(pdata->clk);
+
+ if (!clk_failed) {
+ const time64_t now = readl(pdata->ioaddr + SRTC_LPSCMR);
+
+ rtc_time64_to_tm(now, tm);
+ clk_disable(pdata->clk);
+ return 0;
+ }
+ return clk_failed;
+}
+
+/*
+ * This function sets the internal RTC time based on tm in Gregorian date.
+ *
+ * @param tm the time value to be set in the RTC
+ *
+ * @return 0 if successful; non-zero otherwise.
+ */
+static int mxc_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ time64_t time = rtc_tm_to_time64(tm);
+ int ret;
+
+ if (time > U32_MAX) {
+ dev_err(dev, "RTC exceeded by %llus\n", time - U32_MAX);
+ return -EINVAL;
+ }
+
+ ret = mxc_rtc_lock(pdata);
+ if (ret)
+ return ret;
+
+ writel(time, pdata->ioaddr + SRTC_LPSCMR);
+ mxc_rtc_sync_lp_locked(dev, pdata->ioaddr);
+ return mxc_rtc_unlock(pdata);
+}
+
+/*
+ * This function reads the current alarm value into the passed in \b alrm
+ * argument. It updates the \b alrm's pending field value based on the whether
+ * an alarm interrupt occurs or not.
+ *
+ * @param alrm contains the RTC alarm value upon return
+ *
+ * @return 0 if successful; non-zero otherwise.
+ */
+static int mxc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ void __iomem *ioaddr = pdata->ioaddr;
+ int ret;
+
+ ret = mxc_rtc_lock(pdata);
+ if (ret)
+ return ret;
+
+ rtc_time_to_tm(readl(ioaddr + SRTC_LPSAR), &alrm->time);
+ alrm->pending = !!(readl(ioaddr + SRTC_LPSR) & SRTC_LPSR_ALP);
+ return mxc_rtc_unlock(pdata);
+}
+
+/*
+ * Enable/Disable alarm interrupt
+ * The caller should hold the pdata->lock
+ */
+static void mxc_rtc_alarm_irq_enable_locked(struct mxc_rtc_data *pdata,
+ unsigned int enable)
+{
+ u32 lp_cr = readl(pdata->ioaddr + SRTC_LPCR);
+
+ if (enable)
+ lp_cr |= (SRTC_LPCR_ALP | SRTC_LPCR_WAE);
+ else
+ lp_cr &= ~(SRTC_LPCR_ALP | SRTC_LPCR_WAE);
+
+ writel(lp_cr, pdata->ioaddr + SRTC_LPCR);
+}
+
+static int mxc_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ int ret = mxc_rtc_lock(pdata);
+
+ if (ret)
+ return ret;
+
+ mxc_rtc_alarm_irq_enable_locked(pdata, enable);
+ return mxc_rtc_unlock(pdata);
+}
+
+/*
+ * This function sets the RTC alarm based on passed in alrm.
+ *
+ * @param alrm the alarm value to be set in the RTC
+ *
+ * @return 0 if successful; non-zero otherwise.
+ */
+static int mxc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ const time64_t time = rtc_tm_to_time64(&alrm->time);
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+ int ret = mxc_rtc_lock(pdata);
+
+ if (ret)
+ return ret;
+
+ if (time > U32_MAX) {
+ dev_err(dev, "Hopefully I am out of service by then :-(\n");
+ return -EINVAL;
+ }
+
+ writel((u32)time, pdata->ioaddr + SRTC_LPSAR);
+
+ /* clear alarm interrupt status bit */
+ writel(SRTC_LPSR_ALP, pdata->ioaddr + SRTC_LPSR);
+ mxc_rtc_sync_lp_locked(dev, pdata->ioaddr);
+
+ mxc_rtc_alarm_irq_enable_locked(pdata, alrm->enabled);
+ mxc_rtc_sync_lp_locked(dev, pdata->ioaddr);
+ mxc_rtc_unlock(pdata);
+ return ret;
+}
+
+static const struct rtc_class_ops mxc_rtc_ops = {
+ .read_time = mxc_rtc_read_time,
+ .set_time = mxc_rtc_set_time,
+ .read_alarm = mxc_rtc_read_alarm,
+ .set_alarm = mxc_rtc_set_alarm,
+ .alarm_irq_enable = mxc_rtc_alarm_irq_enable,
+};
+
+static int mxc_rtc_wait_for_flag(void *__iomem ioaddr, int flag)
+{
+ unsigned int timeout = REG_READ_TIMEOUT;
+
+ while (!(readl(ioaddr) & flag)) {
+ if (!--timeout)
+ return -EBUSY;
+ }
+ return 0;
+}
+
+static int mxc_rtc_probe(struct platform_device *pdev)
+{
+ struct mxc_rtc_data *pdata;
+ struct resource *res;
+ void __iomem *ioaddr;
+ int ret = 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ pdata->ioaddr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pdata->ioaddr))
+ return PTR_ERR(pdata->ioaddr);
+
+ ioaddr = pdata->ioaddr;
+
+ pdata->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pdata->clk)) {
+ dev_err(&pdev->dev, "unable to get rtc clock!\n");
+ return PTR_ERR(pdata->clk);
+ }
+
+ spin_lock_init(&pdata->lock);
+ pdata->irq = platform_get_irq(pdev, 0);
+ if (pdata->irq < 0)
+ return pdata->irq;
+
+ device_init_wakeup(&pdev->dev, 1);
+
+ ret = clk_prepare_enable(pdata->clk);
+ if (ret)
+ return ret;
+ /* initialize glitch detect */
+ writel(SRTC_LPPDR_INIT, ioaddr + SRTC_LPPDR);
+
+ /* clear lp interrupt status */
+ writel(0xFFFFFFFF, ioaddr + SRTC_LPSR);
+
+ /* move out of init state */
+ writel((SRTC_LPCR_IE | SRTC_LPCR_NSA), ioaddr + SRTC_LPCR);
+ ret = mxc_rtc_wait_for_flag(ioaddr + SRTC_LPSR, SRTC_LPSR_IES);
+ if (ret) {
+ dev_err(&pdev->dev, "Timeout waiting for SRTC_LPSR_IES\n");
+ clk_disable_unprepare(pdata->clk);
+ return ret;
+ }
+
+ /* move out of non-valid state */
+ writel((SRTC_LPCR_IE | SRTC_LPCR_NVE | SRTC_LPCR_NSA |
+ SRTC_LPCR_EN_LP), ioaddr + SRTC_LPCR);
+ ret = mxc_rtc_wait_for_flag(ioaddr + SRTC_LPSR, SRTC_LPSR_NVES);
+ if (ret) {
+ dev_err(&pdev->dev, "Timeout waiting for SRTC_LPSR_NVES\n");
+ clk_disable_unprepare(pdata->clk);
+ return ret;
+ }
+
+ clk_disable(pdata->clk);
+ platform_set_drvdata(pdev, pdata);
+ ret =
+ devm_request_irq(&pdev->dev, pdata->irq, mxc_rtc_interrupt, 0,
+ pdev->name, &pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "interrupt not available.\n");
+ clk_unprepare(pdata->clk);
+ return ret;
+ }
+
+ pdata->rtc =
+ devm_rtc_device_register(&pdev->dev, pdev->name, &mxc_rtc_ops,
+ THIS_MODULE);
+ if (IS_ERR(pdata->rtc)) {
+ clk_unprepare(pdata->clk);
+ return PTR_ERR(pdata->rtc);
+ }
+
+ return 0;
+}
+
+static int __exit mxc_rtc_remove(struct platform_device *pdev)
+{
+ struct mxc_rtc_data *pdata = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(pdata->clk);
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int mxc_rtc_suspend(struct device *dev)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+
+ if (device_may_wakeup(dev))
+ enable_irq_wake(pdata->irq);
+
+ return 0;
+}
+
+static int mxc_rtc_resume(struct device *dev)
+{
+ struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
+
+ if (device_may_wakeup(dev))
+ disable_irq_wake(pdata->irq);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(mxc_rtc_pm_ops, mxc_rtc_suspend, mxc_rtc_resume);
+
+static const struct of_device_id mxc_ids[] = {
+ { .compatible = "fsl,imx53-rtc", },
+ {}
+};
+
+static struct platform_driver mxc_rtc_driver = {
+ .driver = {
+ .name = "mxc_rtc_v2",
+ .of_match_table = mxc_ids,
+ .pm = &mxc_rtc_pm_ops,
+ },
+ .probe = mxc_rtc_probe,
+ .remove = mxc_rtc_remove,
+};
+
+module_platform_driver(mxc_rtc_driver);
+
+MODULE_AUTHOR("Freescale Semiconductor, Inc.");
+MODULE_DESCRIPTION("Real Time Clock (RTC) Driver for i.MX53");
+MODULE_LICENSE("GPL");
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/4] ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2
From: linux-kernel-dev at beckhoff.com @ 2017-12-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-1-linux-kernel-dev@beckhoff.com>
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Enable SRTC driver for i.MX53 in default config
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
---
v3:
- imx_v4_v5_defconfig was the wrong default config for i.MX53
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-rtc at vger.kernel.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
Cc: devicetree at vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: Noel Vellemans <Noel.Vellemans@visionbms.com>
Cc: Russell King <linux@armlinux.org.uk> (maintainer:ARM PORT)
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 0d4494922561..548c11142a4e 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -349,6 +349,7 @@ CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_M41T80=y
CONFIG_RTC_DRV_MC13XXX=y
CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_MXC_V2=y
CONFIG_RTC_DRV_SNVS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_EDMA=y
--
2.11.0
^ permalink raw reply related
* [PATCH v2 21/36] KVM: arm64: Change 32-bit handling of VM system registers
From: Marc Zyngier @ 2017-12-11 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207170630.592-22-christoffer.dall@linaro.org>
On 07/12/17 17:06, Christoffer Dall wrote:
> We currently handle 32-bit accesses to trapped VM system registers using
> the 32-bit index into the coproc array on the vcpu structure, which is a
> union of the coproc array and the sysreg array.
>
> Since all the 32-bit coproc indicies are created to correspond to the
indices?
> architectural mapping between 64-bit system registers and 32-bit
> coprocessor registers, and because the AArch64 system registers are the
> double in size of the AArch32 coprocessor registers, we can always find
> the system register entry that we must update by dividing the 32-bit
> coproc index by 2.
>
> This is going to make our lives much easier when we have to start
> accessing system registers that use deferred save/restore and might
> have to be read directly from the physical CPU.
>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 8 --------
> arch/arm64/kvm/sys_regs.c | 20 +++++++++++++++-----
> 2 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index c841eeeeb5c5..de0d55b30b61 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -290,14 +290,6 @@ struct kvm_vcpu_arch {
> #define vcpu_cp14(v,r) ((v)->arch.ctxt.copro[(r)])
> #define vcpu_cp15(v,r) ((v)->arch.ctxt.copro[(r)])
>
> -#ifdef CONFIG_CPU_BIG_ENDIAN
> -#define vcpu_cp15_64_high(v,r) vcpu_cp15((v),(r))
> -#define vcpu_cp15_64_low(v,r) vcpu_cp15((v),(r) + 1)
> -#else
> -#define vcpu_cp15_64_high(v,r) vcpu_cp15((v),(r) + 1)
> -#define vcpu_cp15_64_low(v,r) vcpu_cp15((v),(r))
> -#endif
> -
> struct kvm_vm_stat {
> ulong remote_tlb_flush;
> };
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 1830ebc227d1..62c12ab9e6c4 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -121,16 +121,26 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *r)
> {
> bool was_enabled = vcpu_has_cache_enabled(vcpu);
> + u64 val;
> + int reg = r->reg;
>
> BUG_ON(!p->is_write);
>
> - if (!p->is_aarch32) {
> - vcpu_sys_reg(vcpu, r->reg) = p->regval;
> + /* See the 32bit mapping in kvm_host.h */
> + if (p->is_aarch32)
> + reg = r->reg / 2;
> +
> + if (!p->is_aarch32 || !p->is_32bit) {
> + val = p->regval;
> } else {
> - if (!p->is_32bit)
> - vcpu_cp15_64_high(vcpu, r->reg) = upper_32_bits(p->regval);
> - vcpu_cp15_64_low(vcpu, r->reg) = lower_32_bits(p->regval);
> + val = vcpu_sys_reg(vcpu, reg);
> + if (r->reg % 2)
> + val = (p->regval << 32) | (u64)lower_32_bits(val);
> + else
> + val = ((u64)upper_32_bits(val) << 32) |
> + (u64)lower_32_bits(p->regval);
Nit: the u64 casts on lower_32_bits are superfluous.
> }
> + vcpu_sys_reg(vcpu, reg) = val;
>
> kvm_toggle_cache(vcpu, was_enabled);
> return true;
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 22/36] KVM: arm64: Prepare to handle traps on deferred VM sysregs
From: Marc Zyngier @ 2017-12-11 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207170630.592-23-christoffer.dall@linaro.org>
On 07/12/17 17:06, Christoffer Dall wrote:
> When we defer the save/restore of system registers to vcpu_load and
> vcpu_put, we need to take care of the emulation code that handles traps
> to these registers, since simply reading the memory array will return
> stale data.
>
> Therefore, introduce two functions to directly read/write the registers
> from the physical CPU when we're on a VHE system that has loaded the
> system registers onto the physical CPU.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
>
> Notes:
> Changes since v1:
> - Removed spurious white space
>
> arch/arm64/include/asm/kvm_host.h | 4 +++
> arch/arm64/kvm/sys_regs.c | 53 +++++++++++++++++++++++++++++++++++++--
> 2 files changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index de0d55b30b61..f6afe685a280 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -279,6 +279,10 @@ struct kvm_vcpu_arch {
>
> /* Detect first run of a vcpu */
> bool has_run_once;
> +
> + /* True when deferrable sysregs are loaded on the physical CPU,
> + * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> + bool sysregs_loaded_on_cpu;
> };
>
> #define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 62c12ab9e6c4..80adbec933de 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -35,6 +35,7 @@
> #include <asm/kvm_coproc.h>
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_host.h>
> +#include <asm/kvm_hyp.h>
> #include <asm/kvm_mmu.h>
> #include <asm/perf_event.h>
> #include <asm/sysreg.h>
> @@ -111,6 +112,54 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +static u64 read_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg)
> +{
> + if (vcpu->arch.sysregs_loaded_on_cpu) {
> + switch (reg) {
> + case SCTLR_EL1: return read_sysreg_el1(sctlr);
> + case TTBR0_EL1: return read_sysreg_el1(ttbr0);
> + case TTBR1_EL1: return read_sysreg_el1(ttbr1);
> + case TCR_EL1: return read_sysreg_el1(tcr);
> + case ESR_EL1: return read_sysreg_el1(esr);
> + case FAR_EL1: return read_sysreg_el1(far);
> + case AFSR0_EL1: return read_sysreg_el1(afsr0);
> + case AFSR1_EL1: return read_sysreg_el1(afsr1);
> + case MAIR_EL1: return read_sysreg_el1(mair);
> + case AMAIR_EL1: return read_sysreg_el1(amair);
> + case CONTEXTIDR_EL1: return read_sysreg_el1(contextidr);
> + case DACR32_EL2: return read_sysreg(dacr32_el2);
> + case IFSR32_EL2: return read_sysreg(ifsr32_el2);
> + default: BUG();
> + }
> + }
> +
> + return vcpu_sys_reg(vcpu, reg);
> +}
> +
> +static void write_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
> +{
> + if (vcpu->arch.sysregs_loaded_on_cpu) {
> + switch (reg) {
> + case SCTLR_EL1: write_sysreg_el1(val, sctlr); return;
> + case TTBR0_EL1: write_sysreg_el1(val, ttbr0); return;
> + case TTBR1_EL1: write_sysreg_el1(val, ttbr1); return;
> + case TCR_EL1: write_sysreg_el1(val, tcr); return;
> + case ESR_EL1: write_sysreg_el1(val, esr); return;
> + case FAR_EL1: write_sysreg_el1(val, far); return;
> + case AFSR0_EL1: write_sysreg_el1(val, afsr0); return;
> + case AFSR1_EL1: write_sysreg_el1(val, afsr1); return;
> + case MAIR_EL1: write_sysreg_el1(val, mair); return;
> + case AMAIR_EL1: write_sysreg_el1(val, amair); return;
> + case CONTEXTIDR_EL1: write_sysreg_el1(val, contextidr); return;
> + case DACR32_EL2: write_sysreg(val, dacr32_el2); return;
> + case IFSR32_EL2: write_sysreg(val, ifsr32_el2); return;
> + default: BUG();
> + }
> + }
> +
> + vcpu_sys_reg(vcpu, reg) = val;
> +}
> +
> /*
> * Generic accessor for VM registers. Only called as long as HCR_TVM
> * is set. If the guest enables the MMU, we stop trapping the VM
> @@ -133,14 +182,14 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
> if (!p->is_aarch32 || !p->is_32bit) {
> val = p->regval;
> } else {
> - val = vcpu_sys_reg(vcpu, reg);
> + val = read_deferrable_vm_reg(vcpu, reg);
> if (r->reg % 2)
> val = (p->regval << 32) | (u64)lower_32_bits(val);
> else
> val = ((u64)upper_32_bits(val) << 32) |
> (u64)lower_32_bits(p->regval);
> }
> - vcpu_sys_reg(vcpu, reg) = val;
> + write_deferrable_vm_reg(vcpu, reg, val);
>
> kvm_toggle_cache(vcpu, was_enabled);
> return true;
>
I'm slightly uneasy with this. It means that the rest of the KVM code
has to know whether a given register is deferrable or not (or face the
wrath of the BUG). I'd be more inclined to hide the "loaded on cpu"
magic in the vcpu_sys_reg() accessors.
Thoughts?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: DEBUG_LL options' description clean-up
From: Domenico Andreoli @ 2017-12-11 11:17 UTC (permalink / raw)
To: linux-arm-kernel
ARM: DEBUG_LL options' description clean-up
The Kconfig menu for ARM low-level debugging exposes enough variety of
description text which needs to be visually filtered out when searching
for the right option. Longer descriptions are not fully visible when
using menuconfig.
This patch removes the clutter and leaves (or adds, when missing)
the relevant info to identify the wanted option. As general pattern,
SoC/board is specified first then the UART details.
Signed-off-by: Domenico Andreoli <domenico.andreoli@linux.com>
Index: arm.git/arch/arm/Kconfig.debug
===================================================================
--- arm.git.orig/arch/arm/Kconfig.debug 2017-12-11 11:50:28.295893938 +0100
+++ arm.git/arch/arm/Kconfig.debug 2017-12-11 12:05:37.780982910 +0100
@@ -82,7 +82,7 @@ choice
depends on DEBUG_LL
config DEBUG_ALPINE_UART0
- bool "Kernel low-level debugging messages via Alpine UART0"
+ bool "Alpine UART0"
depends on ARCH_ALPINE
select DEBUG_UART_8250
help
@@ -90,7 +90,7 @@ choice
on Alpine based platforms.
config DEBUG_ASM9260_UART
- bool "Kernel low-level debugging via asm9260 UART"
+ bool "asm9260 UART"
depends on MACH_ASM9260
help
Say Y here if you want the debug print routines to direct
@@ -111,7 +111,7 @@ choice
0x80024000 | 0xf0024000 | UART9
config DEBUG_AT91_RM9200_DBGU
- bool "Kernel low-level debugging on AT91RM9200, AT91SAM9 DBGU"
+ bool "AT91RM9200, AT91SAM9 DBGU"
select DEBUG_AT91_UART
depends on SOC_AT91RM9200 || SOC_AT91SAM9
help
@@ -121,7 +121,7 @@ choice
at91sam9g10, at91sam9n12, at91sam9rl64, at91sam9x5
config DEBUG_AT91_SAM9263_DBGU
- bool "Kernel low-level debugging on AT91SAM{9263,9G45,A5D3} DBGU"
+ bool "AT91SAM{9263,9G45,A5D3} DBGU"
select DEBUG_AT91_UART
depends on SOC_AT91SAM9 || SOC_SAMA5D3
help
@@ -131,7 +131,7 @@ choice
sama5d3
config DEBUG_AT91_SAMA5D2_UART1
- bool "Kernel low-level debugging on SAMA5D2 UART1"
+ bool "SAMA5D2 UART1"
select DEBUG_AT91_UART
depends on SOC_SAMA5D2
help
@@ -139,7 +139,7 @@ choice
on the UART1 port of sama5d2.
config DEBUG_AT91_SAMA5D4_USART3
- bool "Kernel low-level debugging on SAMA5D4 USART3"
+ bool "SAMA5D4 USART3"
select DEBUG_AT91_UART
depends on SOC_SAMA5D4
help
@@ -147,7 +147,7 @@ choice
on the USART3 port of sama5d4.
config DEBUG_AT91_SAMV7_USART1
- bool "Kernel low-level debugging via SAMV7 USART1"
+ bool "SAMV7 USART1"
select DEBUG_AT91_UART
depends on SOC_SAMV7
help
@@ -156,27 +156,27 @@ choice
machines.
config DEBUG_BCM2835
- bool "Kernel low-level debugging on BCM2835 PL011 UART"
+ bool "BCM2835 PL011 UART"
depends on ARCH_BCM2835 && ARCH_MULTI_V6
select DEBUG_UART_PL01X
config DEBUG_BCM2836
- bool "Kernel low-level debugging on BCM2836 PL011 UART"
+ bool "BCM2836 PL011 UART"
depends on ARCH_BCM2835 && ARCH_MULTI_V7
select DEBUG_UART_PL01X
config DEBUG_BCM_5301X
- bool "Kernel low-level debugging on BCM5301X/NSP UART1"
+ bool "BCM5301X/NSP UART1"
depends on ARCH_BCM_5301X || ARCH_BCM_NSP
select DEBUG_UART_8250
config DEBUG_BCM_HR2
- bool "Kernel low-level debugging on Hurricane 2 UART2"
+ bool "Hurricane 2 UART2"
depends on ARCH_BCM_HR2
select DEBUG_UART_8250
config DEBUG_BCM_KONA_UART
- bool "Kernel low-level debugging messages via BCM KONA UART"
+ bool "BCM KONA UART"
depends on ARCH_BCM_MOBILE
select DEBUG_UART_8250
help
@@ -187,7 +187,7 @@ choice
bcm11351, etc...)
config DEBUG_BCM63XX_UART
- bool "Kernel low-level debugging on BCM63XX UART"
+ bool "BCM63XX UART"
depends on ARCH_BCM_63XX
config DEBUG_BERLIN_UART
@@ -199,7 +199,7 @@ choice
on Marvell Berlin SoC based platforms.
config DEBUG_BRCMSTB_UART
- bool "Use BRCMSTB UART for low-level debug"
+ bool "BRCMSTB UART"
depends on ARCH_BRCMSTB
help
Say Y here if you want the debug print routines to direct
@@ -211,21 +211,21 @@ choice
messages to appear over the UART, select this option.
config DEBUG_CLPS711X_UART1
- bool "Kernel low-level debugging messages via UART1"
+ bool "CLPS711X UART1"
depends on ARCH_CLPS711X
help
Say Y here if you want the debug print routines to direct
their output to the first serial port on these devices.
config DEBUG_CLPS711X_UART2
- bool "Kernel low-level debugging messages via UART2"
+ bool "CLPS711X UART2"
depends on ARCH_CLPS711X
help
Say Y here if you want the debug print routines to direct
their output to the second serial port on these devices.
config DEBUG_CNS3XXX
- bool "Kernel Kernel low-level debugging on Cavium Networks CNS3xxx"
+ bool "Cavium Networks CNS3xxx"
depends on ARCH_CNS3XXX
select DEBUG_UART_8250
help
@@ -233,7 +233,7 @@ choice
their output to the CNS3xxx UART0.
config DEBUG_DAVINCI_DA8XX_UART1
- bool "Kernel low-level debugging on DaVinci DA8XX using UART1"
+ bool "DaVinci DA8XX UART1"
depends on ARCH_DAVINCI_DA8XX
select DEBUG_UART_8250
help
@@ -241,7 +241,7 @@ choice
their output to UART1 serial port on DaVinci DA8XX devices.
config DEBUG_DAVINCI_DA8XX_UART2
- bool "Kernel low-level debugging on DaVinci DA8XX using UART2"
+ bool "DaVinci DA8XX UART2"
depends on ARCH_DAVINCI_DA8XX
select DEBUG_UART_8250
help
@@ -249,7 +249,7 @@ choice
their output to UART2 serial port on DaVinci DA8XX devices.
config DEBUG_DAVINCI_DMx_UART0
- bool "Kernel low-level debugging on DaVinci DMx using UART0"
+ bool "DaVinci DMx UART0"
depends on ARCH_DAVINCI_DMx
select DEBUG_UART_8250
help
@@ -257,21 +257,21 @@ choice
their output to UART0 serial port on DaVinci DMx devices.
config DEBUG_DC21285_PORT
- bool "Kernel low-level debugging messages via footbridge serial port"
+ bool "footbridge serial port"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the serial port in the DC21285 (Footbridge).
config DEBUG_DIGICOLOR_UA0
- bool "Kernel low-level debugging messages via Digicolor UA0"
+ bool "Digicolor UA0"
depends on ARCH_DIGICOLOR
help
Say Y here if you want the debug print routines to direct
their output to the UA0 serial port in the CX92755.
config DEBUG_EP93XX
- bool "Kernel low-level debugging messages via ep93xx UART"
+ bool "ep93xx UART"
depends on ARCH_EP93XX
select DEBUG_UART_PL01X
help
@@ -279,7 +279,7 @@ choice
on Cirrus Logic EP93xx based platforms.
config DEBUG_FOOTBRIDGE_COM1
- bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
+ bool "footbridge 8250 at PCI COM1"
depends on FOOTBRIDGE
select DEBUG_UART_8250
help
@@ -287,7 +287,7 @@ choice
their output to the 8250 at PCI COM1.
config DEBUG_GEMINI
- bool "Kernel low-level debugging messages via Cortina Systems Gemini UART"
+ bool "Cortina Systems Gemini UART"
depends on ARCH_GEMINI
select DEBUG_UART_8250
help
@@ -303,7 +303,7 @@ choice
on HI3620 UART.
config DEBUG_HIGHBANK_UART
- bool "Kernel low-level debugging messages via Highbank UART"
+ bool "Highbank UART"
depends on ARCH_HIGHBANK
select DEBUG_UART_PL01X
help
@@ -442,7 +442,7 @@ choice
on i.MX7D.
config DEBUG_INTEGRATOR
- bool "Kernel low-level debugging messages via ARM Integrator UART"
+ bool "ARM Integrator UART"
depends on ARCH_INTEGRATOR
select DEBUG_UART_PL01X
help
@@ -450,7 +450,7 @@ choice
on ARM Integrator platforms.
config DEBUG_KEYSTONE_UART0
- bool "Kernel low-level debugging on KEYSTONE2 using UART0"
+ bool "KEYSTONE2 UART0"
depends on ARCH_KEYSTONE
select DEBUG_UART_8250
help
@@ -458,7 +458,7 @@ choice
their output to UART0 serial port on KEYSTONE2 devices.
config DEBUG_KEYSTONE_UART1
- bool "Kernel low-level debugging on KEYSTONE2 using UART1"
+ bool "KEYSTONE2 UART1"
depends on ARCH_KEYSTONE
select DEBUG_UART_8250
help
@@ -473,7 +473,7 @@ choice
on KS8695.
config DEBUG_LPC18XX_UART0
- bool "Kernel low-level debugging via LPC18xx/43xx UART0"
+ bool "LPC18xx/43xx UART0"
depends on ARCH_LPC18XX
select DEBUG_UART_8250
help
@@ -481,7 +481,7 @@ choice
on NXP LPC18xx/43xx UART0.
config DEBUG_LPC32XX
- bool "Kernel low-level debugging messages via NXP LPC32xx UART"
+ bool "NXP LPC32xx UART"
depends on ARCH_LPC32XX
select DEBUG_UART_8250
help
@@ -489,14 +489,14 @@ choice
on NXP LPC32xx based platforms.
config DEBUG_MESON_UARTAO
- bool "Kernel low-level debugging via Meson6 UARTAO"
+ bool "Meson6 UARTAO"
depends on ARCH_MESON
help
Say Y here if you want kernel low-lever debugging support
on Amlogic Meson6 based platforms on the UARTAO.
config DEBUG_MMP_UART2
- bool "Kernel low-level debugging message via MMP UART2"
+ bool "MMP UART2"
depends on ARCH_MMP
select DEBUG_UART_8250
help
@@ -504,7 +504,7 @@ choice
on MMP UART2.
config DEBUG_MMP_UART3
- bool "Kernel low-level debugging message via MMP UART3"
+ bool "MMP UART3"
depends on ARCH_MMP
select DEBUG_UART_8250
help
@@ -512,7 +512,7 @@ choice
on MMP UART3.
config DEBUG_MVEBU_UART0
- bool "Kernel low-level debugging messages via MVEBU UART0 (old bootloaders)"
+ bool "MVEBU UART0 (old bootloaders)"
depends on ARCH_MVEBU
depends on ARCH_MVEBU && CPU_V7
select DEBUG_UART_8250
@@ -536,7 +536,7 @@ choice
silently crashes, with no serial output at all.
config DEBUG_MVEBU_UART0_ALTERNATE
- bool "Kernel low-level debugging messages via MVEBU UART0 (new bootloaders)"
+ bool "MVEBU UART0 (new bootloaders)"
depends on ARCH_MVEBU || ARCH_DOVE || ARCH_MV78XX0 || ARCH_ORION5X
select DEBUG_UART_8250
help
@@ -553,7 +553,7 @@ choice
silently crashes, with no serial output at all.
config DEBUG_MVEBU_UART1_ALTERNATE
- bool "Kernel low-level debugging messages via MVEBU UART1 (new bootloaders)"
+ bool "MVEBU UART1 (new bootloaders)"
depends on ARCH_MVEBU
select DEBUG_UART_8250
help
@@ -595,14 +595,14 @@ choice
for Mediatek mt8135 based platforms on UART3.
config DEBUG_NETX_UART
- bool "Kernel low-level debugging messages via NetX UART"
+ bool "NetX UART"
depends on ARCH_NETX
help
Say Y here if you want kernel low-level debugging support
on Hilscher NetX based platforms.
config DEBUG_NOMADIK_UART
- bool "Kernel low-level debugging messages via NOMADIK UART"
+ bool "NOMADIK UART"
depends on ARCH_NOMADIK
select DEBUG_UART_PL01X
help
@@ -610,7 +610,7 @@ choice
on NOMADIK based platforms.
config DEBUG_NSPIRE_CLASSIC_UART
- bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
+ bool "TI-NSPIRE 8250 UART"
depends on ARCH_NSPIRE
select DEBUG_UART_8250
help
@@ -618,7 +618,7 @@ choice
on TI-NSPIRE classic models.
config DEBUG_NSPIRE_CX_UART
- bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
+ bool "TI-NSPIRE PL011 UART"
depends on ARCH_NSPIRE
select DEBUG_UART_PL01X
help
@@ -626,7 +626,7 @@ choice
on TI-NSPIRE CX models.
config DEBUG_OMAP1UART1
- bool "Kernel low-level debugging via OMAP1 UART1"
+ bool "OMAP1 UART1"
depends on ARCH_OMAP1
select DEBUG_UART_8250
help
@@ -634,7 +634,7 @@ choice
on OMAP1 based platforms (except OMAP730) on the UART1.
config DEBUG_OMAP1UART2
- bool "Kernel low-level debugging via OMAP1 UART2"
+ bool "OMAP1 UART2"
depends on ARCH_OMAP1
select DEBUG_UART_8250
help
@@ -642,7 +642,7 @@ choice
on OMAP1 based platforms (except OMAP730) on the UART2.
config DEBUG_OMAP1UART3
- bool "Kernel low-level debugging via OMAP1 UART3"
+ bool "OMAP1 UART3"
depends on ARCH_OMAP1
select DEBUG_UART_8250
help
@@ -658,17 +658,17 @@ choice
omap3 torpedo and 3530 lv som.
config DEBUG_OMAP2UART2
- bool "Kernel low-level debugging messages via OMAP2/3/4 UART2"
+ bool "OMAP2/3/4 UART2"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_OMAP2UART3
- bool "Kernel low-level debugging messages via OMAP2 UART3 (n8x0)"
+ bool "OMAP2 UART3 (n8x0)"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_OMAP3UART3
- bool "Kernel low-level debugging messages via OMAP3 UART3 (most omap3 boards)"
+ bool "OMAP3 UART3 (most omap3 boards)"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
help
@@ -677,22 +677,22 @@ choice
and 3517evm.
config DEBUG_OMAP4UART3
- bool "Kernel low-level debugging messages via OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
+ bool "OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_OMAP3UART4
- bool "Kernel low-level debugging messages via OMAP36XX UART4"
+ bool "OMAP36XX UART4"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_OMAP4UART4
- bool "Kernel low-level debugging messages via OMAP4/5 UART4"
+ bool "OMAP4/5 UART4"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_OMAP7XXUART1
- bool "Kernel low-level debugging via OMAP730 UART1"
+ bool "OMAP730 UART1"
depends on ARCH_OMAP730
select DEBUG_UART_8250
help
@@ -700,7 +700,7 @@ choice
on OMAP730 based platforms on the UART1.
config DEBUG_OMAP7XXUART2
- bool "Kernel low-level debugging via OMAP730 UART2"
+ bool "OMAP730 UART2"
depends on ARCH_OMAP730
select DEBUG_UART_8250
help
@@ -708,7 +708,7 @@ choice
on OMAP730 based platforms on the UART2.
config DEBUG_OMAP7XXUART3
- bool "Kernel low-level debugging via OMAP730 UART3"
+ bool "OMAP730 UART3"
depends on ARCH_OMAP730
select DEBUG_UART_8250
help
@@ -716,33 +716,33 @@ choice
on OMAP730 based platforms on the UART3.
config DEBUG_TI81XXUART1
- bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)"
+ bool "TI81XX UART1 (ti8148evm)"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_TI81XXUART2
- bool "Kernel low-level debugging messages via TI81XX UART2"
+ bool "TI81XX UART2"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_TI81XXUART3
- bool "Kernel low-level debugging messages via TI81XX UART3 (ti8168evm)"
+ bool "TI81XX UART3 (ti8168evm)"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_AM33XXUART1
- bool "Kernel low-level debugging messages via AM33XX UART1"
+ bool "AM33XX UART1"
depends on ARCH_OMAP2PLUS
select DEBUG_UART_8250
config DEBUG_ZOOM_UART
- bool "Kernel low-level debugging messages via Zoom2/3 UART"
+ bool "Zoom2/3 UART"
depends on ARCH_OMAP2PLUS
select DEBUG_OMAP2PLUS_UART
config DEBUG_PICOXCELL_UART
depends on ARCH_PICOXCELL
- bool "Use PicoXcell UART for low-level debug"
+ bool "PicoXcell UART"
select DEBUG_UART_8250
help
Say Y here if you want kernel low-level debugging support
@@ -750,14 +750,14 @@ choice
config DEBUG_PXA_UART1
depends on ARCH_PXA
- bool "Use PXA UART1 for low-level debug"
+ bool "PXA UART1"
select DEBUG_UART_8250
help
Say Y here if you want kernel low-level debugging support
on PXA UART1.
config DEBUG_QCOM_UARTDM
- bool "Kernel low-level debugging messages via QCOM UARTDM"
+ bool "QCOM UARTDM"
depends on ARCH_QCOM
help
Say Y here if you want the debug print routines to direct
@@ -793,7 +793,7 @@ choice
PB1176 platform.
config DEBUG_RV1108_UART0
- bool "Kernel low-level debugging messages via Rockchip RV1108 UART0"
+ bool "Rockchip RV1108 UART0"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -801,7 +801,7 @@ choice
on Rockchip RV1108 based platforms.
config DEBUG_RV1108_UART1
- bool "Kernel low-level debugging messages via Rockchip RV1108 UART1"
+ bool "Rockchip RV1108 UART1"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -809,7 +809,7 @@ choice
on Rockchip RV1108 based platforms.
config DEBUG_RV1108_UART2
- bool "Kernel low-level debugging messages via Rockchip RV1108 UART2"
+ bool "Rockchip RV1108 UART2"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -817,7 +817,7 @@ choice
on Rockchip RV1108 based platforms.
config DEBUG_RK29_UART0
- bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
+ bool "Rockchip RK29 UART0"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -825,7 +825,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK29_UART1
- bool "Kernel low-level debugging messages via Rockchip RK29 UART1"
+ bool "Rockchip RK29 UART1"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -833,7 +833,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK29_UART2
- bool "Kernel low-level debugging messages via Rockchip RK29 UART2"
+ bool "Rockchip RK29 UART2"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -841,7 +841,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK3X_UART0
- bool "Kernel low-level debugging messages via Rockchip RK30/RK31 UART0"
+ bool "Rockchip RK30/RK31 UART0"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -849,7 +849,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK3X_UART1
- bool "Kernel low-level debugging messages via Rockchip RK30/RK31 UART1"
+ bool "Rockchip RK30/RK31 UART1"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -857,7 +857,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK3X_UART2
- bool "Kernel low-level debugging messages via Rockchip RK30/RK31 UART2"
+ bool "Rockchip RK30/RK31 UART2"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -865,7 +865,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK3X_UART3
- bool "Kernel low-level debugging messages via Rockchip RK30/RK31 UART3"
+ bool "Rockchip RK30/RK31 UART3"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -873,7 +873,7 @@ choice
on Rockchip based platforms.
config DEBUG_RK32_UART2
- bool "Kernel low-level debugging messages via Rockchip RK32 UART2"
+ bool "Rockchip RK32 UART2"
depends on ARCH_ROCKCHIP
select DEBUG_UART_8250
help
@@ -881,28 +881,28 @@ choice
on Rockchip RK32xx based platforms.
config DEBUG_R7S72100_SCIF2
- bool "Kernel low-level debugging messages via SCIF2 on R7S72100"
+ bool "R7S72100 SCIF2"
depends on ARCH_R7S72100
help
Say Y here if you want kernel low-level debugging support
via SCIF2 on Renesas RZ/A1H (R7S72100).
config DEBUG_RCAR_GEN1_SCIF0
- bool "Kernel low-level debugging messages via SCIF0 on R8A7778"
+ bool "R8A7778 SCIF0"
depends on ARCH_R8A7778
help
Say Y here if you want kernel low-level debugging support
via SCIF0 on Renesas R-Car M1A (R8A7778).
config DEBUG_RCAR_GEN1_SCIF2
- bool "Kernel low-level debugging messages via SCIF2 on R8A7779"
+ bool "R8A7779 SCIF2"
depends on ARCH_R8A7779
help
Say Y here if you want kernel low-level debugging support
via SCIF2 on Renesas R-Car H1 (R8A7779).
config DEBUG_RCAR_GEN2_SCIF0
- bool "Kernel low-level debugging messages via SCIF0 on R-Car Gen2 and RZ/G1"
+ bool "R-Car Gen2 and RZ/G1 SCIF0"
depends on ARCH_R8A7743 || ARCH_R8A7790 || ARCH_R8A7791 || \
ARCH_R8A7792 || ARCH_R8A7793
help
@@ -911,35 +911,35 @@ choice
M2-W (R8A7791), V2H (R8A7792), or M2-N (R8A7793).
config DEBUG_RCAR_GEN2_SCIF2
- bool "Kernel low-level debugging messages via SCIF2 on R8A7794"
+ bool "R8A7794 SCIF2"
depends on ARCH_R8A7794
help
Say Y here if you want kernel low-level debugging support
via SCIF2 on Renesas R-Car E2 (R8A7794).
config DEBUG_RCAR_GEN2_SCIF4
- bool "Kernel low-level debugging messages via SCIF4 on R8A7745"
+ bool "R8A7745 SCIF4"
depends on ARCH_R8A7745
help
Say Y here if you want kernel low-level debugging support
via SCIF4 on Renesas RZ/G1E (R8A7745).
config DEBUG_RMOBILE_SCIFA0
- bool "Kernel low-level debugging messages via SCIFA0 on R8A73A4"
+ bool "R8A73A4 SCIFA0"
depends on ARCH_R8A73A4
help
Say Y here if you want kernel low-level debugging support
via SCIFA0 on Renesas R-Mobile APE6 (R8A73A4).
config DEBUG_RMOBILE_SCIFA1
- bool "Kernel low-level debugging messages via SCIFA1 on R8A7740"
+ bool "R8A7740 SCIFA1"
depends on ARCH_R8A7740
help
Say Y here if you want kernel low-level debugging support
via SCIFA1 on Renesas R-Mobile A1 (R8A7740).
config DEBUG_RMOBILE_SCIFA4
- bool "Kernel low-level debugging messages via SCIFA4 on SH73A0"
+ bool "SH73A0 SCIFA4"
depends on ARCH_SH73A0
help
Say Y here if you want kernel low-level debugging support
@@ -951,7 +951,7 @@ choice
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
select DEBUG_S3C64XX_UART if ARCH_S3C64XX
select DEBUG_S5PV210_UART if ARCH_S5PV210
- bool "Use Samsung S3C UART 0 for low-level debug"
+ bool "Samsung S3C UART0"
help
Say Y here if you want the debug print routines to direct
their output to UART 0. The port must have been initialised
@@ -963,7 +963,7 @@ choice
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
select DEBUG_S3C64XX_UART if ARCH_S3C64XX
select DEBUG_S5PV210_UART if ARCH_S5PV210
- bool "Use Samsung S3C UART 1 for low-level debug"
+ bool "Samsung S3C UART1"
help
Say Y here if you want the debug print routines to direct
their output to UART 1. The port must have been initialised
@@ -975,7 +975,7 @@ choice
select DEBUG_S3C24XX_UART if ARCH_S3C24XX
select DEBUG_S3C64XX_UART if ARCH_S3C64XX
select DEBUG_S5PV210_UART if ARCH_S5PV210
- bool "Use Samsung S3C UART 2 for low-level debug"
+ bool "Samsung S3C UART2"
help
Say Y here if you want the debug print routines to direct
their output to UART 2. The port must have been initialised
@@ -986,7 +986,7 @@ choice
select DEBUG_EXYNOS_UART if ARCH_EXYNOS
select DEBUG_S3C64XX_UART if ARCH_S3C64XX
select DEBUG_S5PV210_UART if ARCH_S5PV210
- bool "Use Samsung S3C UART 3 for low-level debug"
+ bool "Samsung S3C UART3"
help
Say Y here if you want the debug print routines to direct
their output to UART 3. The port must have been initialised
@@ -995,7 +995,7 @@ choice
config DEBUG_S3C2410_UART0
depends on ARCH_S3C24XX
select DEBUG_S3C2410_UART
- bool "Use S3C2410/S3C2412 UART 0 for low-level debug"
+ bool "S3C2410/S3C2412 UART0"
help
Say Y here if you want the debug print routines to direct
their output to UART 0. The port must have been initialised
@@ -1004,7 +1004,7 @@ choice
config DEBUG_S3C2410_UART1
depends on ARCH_S3C24XX
select DEBUG_S3C2410_UART
- bool "Use S3C2410/S3C2412 UART 1 for low-level debug"
+ bool "S3C2410/S3C2412 UART1"
help
Say Y here if you want the debug print routines to direct
their output to UART 1. The port must have been initialised
@@ -1013,7 +1013,7 @@ choice
config DEBUG_S3C2410_UART2
depends on ARCH_S3C24XX
select DEBUG_S3C2410_UART
- bool "Use S3C2410/S3C2412 UART 2 for low-level debug"
+ bool "S3C2410/S3C2412 UART2"
help
Say Y here if you want the debug print routines to direct
their output to UART 2. The port must have been initialised
@@ -1021,7 +1021,7 @@ choice
config DEBUG_SA1100
depends on ARCH_SA1100
- bool "Use SA1100 UARTs for low-level debug"
+ bool "SA1100 UARTs"
help
Say Y here if you want kernel low-level debugging support
on SA-11x0 UART ports. The kernel will check for the first
@@ -1029,7 +1029,7 @@ choice
config DEBUG_SOCFPGA_UART0
depends on ARCH_SOCFPGA
- bool "Use SOCFPGA UART0 for low-level debug"
+ bool "SOCFPGA UART0"
select DEBUG_UART_8250
help
Say Y here if you want kernel low-level debugging support
@@ -1037,7 +1037,7 @@ choice
config DEBUG_SOCFPGA_UART1
depends on ARCH_SOCFPGA
- bool "Use SOCFPGA UART1 for low-level debug"
+ bool "SOCFPGA UART1"
select DEBUG_UART_8250
help
Say Y here if you want kernel low-level debugging support
@@ -1045,7 +1045,7 @@ choice
config DEBUG_SUN9I_UART0
- bool "Kernel low-level debugging messages via sun9i UART0"
+ bool "sun9i UART0"
depends on MACH_SUN9I
select DEBUG_UART_8250
help
@@ -1053,7 +1053,7 @@ choice
on Allwinner A80 based platforms on the UART0.
config DEBUG_SUNXI_UART0
- bool "Kernel low-level debugging messages via sunXi UART0"
+ bool "sunXi UART0"
depends on ARCH_SUNXI
select DEBUG_UART_8250
help
@@ -1061,7 +1061,7 @@ choice
on Allwinner A1X based platforms on the UART0.
config DEBUG_SUNXI_UART1
- bool "Kernel low-level debugging messages via sunXi UART1"
+ bool "sunXi UART1"
depends on ARCH_SUNXI
select DEBUG_UART_8250
help
@@ -1069,7 +1069,7 @@ choice
on Allwinner A1X based platforms on the UART1.
config DEBUG_SUNXI_R_UART
- bool "Kernel low-level debugging messages via sunXi R_UART"
+ bool "sunXi R_UART"
depends on MACH_SUN6I || MACH_SUN8I
select DEBUG_UART_8250
help
@@ -1077,7 +1077,7 @@ choice
on Allwinner A31/A23 based platforms on the R_UART.
config DEBUG_SIRFPRIMA2_UART1
- bool "Kernel low-level debugging messages via SiRFprimaII UART1"
+ bool "SiRFprimaII UART1"
depends on ARCH_PRIMA2
select DEBUG_SIRFSOC_UART
help
@@ -1085,7 +1085,7 @@ choice
their output to the uart1 port on SiRFprimaII devices.
config DEBUG_SIRFATLAS7_UART0
- bool "Kernel low-level debugging messages via SiRFatlas7 UART0"
+ bool "SiRFatlas7 UART0"
depends on ARCH_ATLAS7
select DEBUG_SIRFSOC_UART
help
@@ -1095,7 +1095,7 @@ choice
debug port can be very useful.
config DEBUG_SIRFATLAS7_UART1
- bool "Kernel low-level debugging messages via SiRFatlas7 UART1"
+ bool "SiRFatlas7 UART1"
depends on ARCH_ATLAS7
select DEBUG_SIRFSOC_UART
help
@@ -1103,7 +1103,7 @@ choice
their output to the uart1 port on SiRFATLAS7 devices.
config DEBUG_SPEAR3XX
- bool "Kernel low-level debugging messages via ST SPEAr 3xx/6xx UART"
+ bool "ST SPEAr 3xx/6xx UART"
depends on ARCH_SPEAR3XX || ARCH_SPEAR6XX
select DEBUG_UART_PL01X
help
@@ -1111,7 +1111,7 @@ choice
on ST SPEAr based platforms.
config DEBUG_SPEAR13XX
- bool "Kernel low-level debugging messages via ST SPEAr 13xx UART"
+ bool "ST SPEAr 13xx UART"
depends on ARCH_SPEAR13XX
select DEBUG_UART_PL01X
help
@@ -1119,7 +1119,7 @@ choice
on ST SPEAr13xx based platforms.
config STIH41X_DEBUG_ASC2
- bool "Use StiH415/416 ASC2 UART for low-level debug"
+ bool "StiH415/416 ASC2 UART"
depends on ARCH_STI
select DEBUG_STI_UART
help
@@ -1130,7 +1130,7 @@ choice
If unsure, say N.
config STIH41X_DEBUG_SBC_ASC1
- bool "Use StiH415/416 SBC ASC1 UART for low-level debug"
+ bool "StiH415/416 SBC ASC1 UART"
depends on ARCH_STI
select DEBUG_STI_UART
help
@@ -1141,7 +1141,7 @@ choice
If unsure, say N.
config TEGRA_DEBUG_UART_AUTO_ODMDATA
- bool "Kernel low-level debugging messages via Tegra UART via ODMDATA"
+ bool "Tegra UART via ODMDATA"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1153,7 +1153,7 @@ choice
are UART A/B/C/D/E.
config TEGRA_DEBUG_UARTA
- bool "Kernel low-level debugging messages via Tegra UART A"
+ bool "Tegra UART A"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1161,7 +1161,7 @@ choice
on Tegra based platforms.
config TEGRA_DEBUG_UARTB
- bool "Kernel low-level debugging messages via Tegra UART B"
+ bool "Tegra UART B"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1169,7 +1169,7 @@ choice
on Tegra based platforms.
config TEGRA_DEBUG_UARTC
- bool "Kernel low-level debugging messages via Tegra UART C"
+ bool "Tegra UART C"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1177,7 +1177,7 @@ choice
on Tegra based platforms.
config TEGRA_DEBUG_UARTD
- bool "Kernel low-level debugging messages via Tegra UART D"
+ bool "Tegra UART D"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1185,7 +1185,7 @@ choice
on Tegra based platforms.
config TEGRA_DEBUG_UARTE
- bool "Kernel low-level debugging messages via Tegra UART E"
+ bool "Tegra UART E"
depends on ARCH_TEGRA
select DEBUG_TEGRA_UART
help
@@ -1193,7 +1193,7 @@ choice
on Tegra based platforms.
config DEBUG_U300_UART
- bool "Kernel low-level debugging messages via U300 UART0"
+ bool "U300 UART0"
depends on ARCH_U300
select DEBUG_UART_PL01X
help
@@ -1202,13 +1202,13 @@ choice
config DEBUG_UX500_UART
depends on ARCH_U8500
- bool "Use Ux500 UART for low-level debug"
+ bool "Ux500 UART"
help
Say Y here if you want kernel low-level debugging support
on Ux500 based platforms.
config DEBUG_VERSATILE
- bool "Kernel low-level debugging messages via ARM Versatile UART"
+ bool "ARM Versatile UART"
depends on ARCH_VERSATILE
select DEBUG_UART_PL01X
help
@@ -1259,7 +1259,7 @@ choice
on Vybrid based platforms.
config DEBUG_VT8500_UART0
- bool "Use UART0 on VIA/Wondermedia SoCs"
+ bool "VIA/Wondermedia UART0"
depends on ARCH_VT8500
help
This option selects UART0 on VIA/Wondermedia System-on-a-chip
@@ -1278,14 +1278,14 @@ choice
and will be soon removed.
config DEBUG_ZYNQ_UART0
- bool "Kernel low-level debugging on Xilinx Zynq using UART0"
+ bool "Xilinx Zynq UART0"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
their output to UART0 on the Zynq platform.
config DEBUG_ZYNQ_UART1
- bool "Kernel low-level debugging on Xilinx Zynq using UART1"
+ bool "Xilinx Zynq UART1"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
@@ -1295,7 +1295,7 @@ choice
appear on the USB serial adaptor, select this option.
config DEBUG_ICEDCC
- bool "Kernel low-level debugging via EmbeddedICE DCC channel"
+ bool "EmbeddedICE DCC channel"
help
Say Y here if you want the debug print routines to direct
their output to the EmbeddedICE macrocell's DCC channel using
@@ -1306,7 +1306,7 @@ choice
is nothing connected to read from the DCC.
config DEBUG_SEMIHOSTING
- bool "Kernel low-level debug output via semihosting I/O"
+ bool "Semihosting I/O"
help
Semihosting enables code running on an ARM target to use
the I/O facilities on a host debugger/emulator through a
@@ -1322,7 +1322,7 @@ choice
chapter 8 of DUI0203I_rvct_developer_guide.pdf from ARM Ltd.
config DEBUG_LL_UART_8250
- bool "Kernel low-level debugging via 8250 UART"
+ bool "8250 UART"
help
Say Y here if you wish the debug print routes to direct
their output to an 8250 UART. You can use this option
@@ -1335,7 +1335,7 @@ choice
and will be soon removed.
config DEBUG_LL_UART_EFM32
- bool "Kernel low-level debugging via efm32 UART"
+ bool "efm32 UART"
depends on ARCH_EFM32
help
Say Y here if you want the debug print routines to direct
@@ -1349,7 +1349,7 @@ choice
0x4000e400 | UART1
config DEBUG_LL_UART_PL01X
- bool "Kernel low-level debugging via ARM Ltd PL01x Primecell UART"
+ bool "ARM Ltd PL01x Primecell UART"
help
Say Y here if you wish the debug print routes to direct
their output to a PL01x Primecell UART. You can use
^ permalink raw reply
* [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
From: ilialin at codeaurora.org @ 2017-12-11 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205115118.ekilgrzsp47fz5ua@lakrids.cambridge.arm.com>
Hello Mark,
Do you mean, I should send them as a single series to both lists?
Thanks,
Ilia
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Tuesday, December 5, 2017 1:51 PM
> To: ilialin at codeaurora.org
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
>
> On Tue, Dec 05, 2017 at 01:37:47PM +0200, ilialin at codeaurora.org wrote:
> > Hello Mark,
> >
> > > -----Original Message-----
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Tuesday, December 5, 2017 12:35 PM
> > > To: Ilia Lin <ilialin@codeaurora.org>
> > > Cc: linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH] soc: qcom: Separate kryo l2 accessors from PMU
> > > driver
> > >
> > > Hi,
> > >
> > > On Tue, Dec 05, 2017 at 08:33:50AM +0200, Ilia Lin wrote:
> > > > The driver provides kernel level API for other drivers to access
> > > > the
> > > > MSM8996 L2 cache registers.
> > > > Separating the L2 access code from the PMU driver and making it
> > > > public to allow other drivers use it.
> > > > The accesses must be separated with a single spinlock, maintained
> > > > in this driver.
> > > >
> > > > Change-Id: I2865e888491e85d678e298279400c371427e30ea
> > > > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> > >
> > > What other driver is going to use this?
> > >
> > > Until there is another driver, I don't see much point in factoring
> > > this
> > out.
> >
> > The other driver currently is the CPU clock driver, which needs
> > configuring the L2 registers. The clock driver will be submitted
> > through the linux-clk list and will depend on the kryo-l2-accessors
driver
> then.
>
> Ok,
>
> Please put the two in a series, and keep me (and Will Deacon) on Cc, so
that
> we can review both together.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v2 22/36] KVM: arm64: Prepare to handle traps on deferred VM sysregs
From: Christoffer Dall @ 2017-12-11 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f4ecd66-fca1-4da9-3524-ee64d999a501@arm.com>
On Mon, Dec 11, 2017 at 11:10:36AM +0000, Marc Zyngier wrote:
> On 07/12/17 17:06, Christoffer Dall wrote:
> > When we defer the save/restore of system registers to vcpu_load and
> > vcpu_put, we need to take care of the emulation code that handles traps
> > to these registers, since simply reading the memory array will return
> > stale data.
> >
> > Therefore, introduce two functions to directly read/write the registers
> > from the physical CPU when we're on a VHE system that has loaded the
> > system registers onto the physical CPU.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> >
> > Notes:
> > Changes since v1:
> > - Removed spurious white space
> >
> > arch/arm64/include/asm/kvm_host.h | 4 +++
> > arch/arm64/kvm/sys_regs.c | 53 +++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 55 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index de0d55b30b61..f6afe685a280 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -279,6 +279,10 @@ struct kvm_vcpu_arch {
> >
> > /* Detect first run of a vcpu */
> > bool has_run_once;
> > +
> > + /* True when deferrable sysregs are loaded on the physical CPU,
> > + * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> > + bool sysregs_loaded_on_cpu;
> > };
> >
> > #define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 62c12ab9e6c4..80adbec933de 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -35,6 +35,7 @@
> > #include <asm/kvm_coproc.h>
> > #include <asm/kvm_emulate.h>
> > #include <asm/kvm_host.h>
> > +#include <asm/kvm_hyp.h>
> > #include <asm/kvm_mmu.h>
> > #include <asm/perf_event.h>
> > #include <asm/sysreg.h>
> > @@ -111,6 +112,54 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
> > return true;
> > }
> >
> > +static u64 read_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg)
> > +{
> > + if (vcpu->arch.sysregs_loaded_on_cpu) {
> > + switch (reg) {
> > + case SCTLR_EL1: return read_sysreg_el1(sctlr);
> > + case TTBR0_EL1: return read_sysreg_el1(ttbr0);
> > + case TTBR1_EL1: return read_sysreg_el1(ttbr1);
> > + case TCR_EL1: return read_sysreg_el1(tcr);
> > + case ESR_EL1: return read_sysreg_el1(esr);
> > + case FAR_EL1: return read_sysreg_el1(far);
> > + case AFSR0_EL1: return read_sysreg_el1(afsr0);
> > + case AFSR1_EL1: return read_sysreg_el1(afsr1);
> > + case MAIR_EL1: return read_sysreg_el1(mair);
> > + case AMAIR_EL1: return read_sysreg_el1(amair);
> > + case CONTEXTIDR_EL1: return read_sysreg_el1(contextidr);
> > + case DACR32_EL2: return read_sysreg(dacr32_el2);
> > + case IFSR32_EL2: return read_sysreg(ifsr32_el2);
> > + default: BUG();
> > + }
> > + }
> > +
> > + return vcpu_sys_reg(vcpu, reg);
> > +}
> > +
> > +static void write_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
> > +{
> > + if (vcpu->arch.sysregs_loaded_on_cpu) {
> > + switch (reg) {
> > + case SCTLR_EL1: write_sysreg_el1(val, sctlr); return;
> > + case TTBR0_EL1: write_sysreg_el1(val, ttbr0); return;
> > + case TTBR1_EL1: write_sysreg_el1(val, ttbr1); return;
> > + case TCR_EL1: write_sysreg_el1(val, tcr); return;
> > + case ESR_EL1: write_sysreg_el1(val, esr); return;
> > + case FAR_EL1: write_sysreg_el1(val, far); return;
> > + case AFSR0_EL1: write_sysreg_el1(val, afsr0); return;
> > + case AFSR1_EL1: write_sysreg_el1(val, afsr1); return;
> > + case MAIR_EL1: write_sysreg_el1(val, mair); return;
> > + case AMAIR_EL1: write_sysreg_el1(val, amair); return;
> > + case CONTEXTIDR_EL1: write_sysreg_el1(val, contextidr); return;
> > + case DACR32_EL2: write_sysreg(val, dacr32_el2); return;
> > + case IFSR32_EL2: write_sysreg(val, ifsr32_el2); return;
> > + default: BUG();
> > + }
> > + }
> > +
> > + vcpu_sys_reg(vcpu, reg) = val;
> > +}
> > +
> > /*
> > * Generic accessor for VM registers. Only called as long as HCR_TVM
> > * is set. If the guest enables the MMU, we stop trapping the VM
> > @@ -133,14 +182,14 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
> > if (!p->is_aarch32 || !p->is_32bit) {
> > val = p->regval;
> > } else {
> > - val = vcpu_sys_reg(vcpu, reg);
> > + val = read_deferrable_vm_reg(vcpu, reg);
> > if (r->reg % 2)
> > val = (p->regval << 32) | (u64)lower_32_bits(val);
> > else
> > val = ((u64)upper_32_bits(val) << 32) |
> > (u64)lower_32_bits(p->regval);
> > }
> > - vcpu_sys_reg(vcpu, reg) = val;
> > + write_deferrable_vm_reg(vcpu, reg, val);
> >
> > kvm_toggle_cache(vcpu, was_enabled);
> > return true;
> >
>
> I'm slightly uneasy with this. It means that the rest of the KVM code
> has to know whether a given register is deferrable or not (or face the
> wrath of the BUG). I'd be more inclined to hide the "loaded on cpu"
> magic in the vcpu_sys_reg() accessors.
>
> Thoughts?
>
Yes, this is the main reservation I also have with the series.
I did start out with a giant "rewrite everything to vcpu_get_sys_reg and
vcpu_get_sys_reg" which hides this logic, and we may want to go back to
that.
That does mean that we need a giant switch statement which knows how to
read any deferrable EL1 (and EL0) system register from hardware, and
still BUG/WARN if someone adds a system register but forgets to add that
handler and test on VHE. Unless there's some fantastic auto-gen
mechanism that can take a hash define and figure out which sysreg
instruction to use - I couldn't think of that.
I'm happy to go back to that approach, but I didn't find it that much
nicer either.
How about I send you the small handful of patches that implement the
alternative approach and you have a look at that?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v6 4/6] clk: meson: make the spinlock naming more specific
From: Jerome Brunet @ 2017-12-11 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211064853.32111-5-yixun.lan@amlogic.com>
On Mon, 2017-12-11 at 14:48 +0800, Yixun Lan wrote:
> .ops = &clk_gate_ops,
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 1629da9b4141..87f06a801a4d 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -134,7 +134,7 @@ struct meson_clk_audio_divider {
> struct clk_gate _name = { \
> .reg = (void __iomem *) _reg, \
> .bit_idx = (_bit), \
> - .lock = &clk_lock, \
> + .lock = &meson_clk_lock, \
Something is not right here, line is over 80 characters
Remember to run checkpatch on your series please.
> .hw.init = &(struct clk_init_data) { \
> .name = #_name, \
> .ops = &clk_gate_ops, \
^ permalink raw reply
* [PATCH v3 3/4] rtc: add mxc driver for i.MX53 SRTC
From: Philippe Ombredanne @ 2017-12-11 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-4-linux-kernel-dev@beckhoff.com>
On Mon, Dec 11, 2017 at 11:56 AM, <linux-kernel-dev@beckhoff.com> wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
[...]
> v2:
[...]
> - add SPDX-License-Identifier and cleanup copyright notice
Thank you for using the SPDX ids in this patch series.
Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
From: Mark Rutland @ 2017-12-11 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002101d37272$60016a20$20043e60$@codeaurora.org>
On Mon, Dec 11, 2017 at 01:22:45PM +0200, ilialin at codeaurora.org wrote:
> Hello Mark,
>
> Do you mean, I should send them as a single series to both lists?
Yes please, with both myself adn Will Deacon explicitly CC'd.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 03/20] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Arnd Bergmann @ 2017-12-11 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfSxxVFT7y6M17LZhVO0GHuL1L=6KET75Qojg8rpgD9iw@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:44 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Mon, Dec 11, 2017 at 6:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote:
>>> This should have always been 8.
>>>
>>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>>
>> As this is a bugfix, should we backport it to stable kernels? When you
>> fix a bug,
>> I generally recommend including a 'Fixes' tag with the commit ID of the patch
>> that introduced the problem, and either a 'Cc: stable at vger.kernel.org' tag
>> if you want it backported, or an explanation in the changelog why it should
>> not get backported. This really helps Greg and the other stable maintainers
>> trying to make a decision what to backport and what not.
>
> We could do this, and I generally follow the practice of adding Fixes
> tags. I hadn't because without an upstream clock driver, the Aspeed
> port is not usable by anyone without making modifications. We're
> really depending on getting that code merged.
>
> I will send it as a fix to 4.15. Do you mind taking individual patches
> for the arm dt tree, or would you prefer a pull request?
For bugfixes, we don't distinguish between DT and other fixes. If it's
a single patch, a pull request works just as well as a emailed patch,
your choice.
Arnd
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs Use PTR_ERR_OR_ZERO()
From: Herbert Xu @ 2017-12-11 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511823966-5815-1-git-send-email-gomonovych@gmail.com>
On Tue, Nov 28, 2017 at 12:06:06AM +0100, Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> arch/arm/crypto/aes-neonbs-glue.c:184:1-3: WARNING: PTR_ERR_OR_ZERO can be used
> arch/arm/crypto/aes-neonbs-glue.c:261:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: stm32: fix module device table name
From: Herbert Xu @ 2017-12-11 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130110433.15811-1-clabbe.montjoie@gmail.com>
On Thu, Nov 30, 2017 at 12:04:33PM +0100, Corentin Labbe wrote:
> This patch fix the following build failure:
> CC [M] drivers/crypto/stm32/stm32-cryp.o
> In file included from drivers/crypto/stm32/stm32-cryp.c:11:0:
> drivers/crypto/stm32/stm32-cryp.c:1049:25: error: 'sti_dt_ids' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, sti_dt_ids);
>
> Let's replace sti_dt_ids with stm32_dt_ids which is just declared
> before.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 22/36] KVM: arm64: Prepare to handle traps on deferred VM sysregs
From: Marc Zyngier @ 2017-12-11 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211112436.GH910@cbox>
On 11/12/17 11:24, Christoffer Dall wrote:
> On Mon, Dec 11, 2017 at 11:10:36AM +0000, Marc Zyngier wrote:
>> On 07/12/17 17:06, Christoffer Dall wrote:
>>> When we defer the save/restore of system registers to vcpu_load and
>>> vcpu_put, we need to take care of the emulation code that handles traps
>>> to these registers, since simply reading the memory array will return
>>> stale data.
>>>
>>> Therefore, introduce two functions to directly read/write the registers
>>> from the physical CPU when we're on a VHE system that has loaded the
>>> system registers onto the physical CPU.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>>
>>> Notes:
>>> Changes since v1:
>>> - Removed spurious white space
>>>
>>> arch/arm64/include/asm/kvm_host.h | 4 +++
>>> arch/arm64/kvm/sys_regs.c | 53 +++++++++++++++++++++++++++++++++++++--
>>> 2 files changed, 55 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index de0d55b30b61..f6afe685a280 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -279,6 +279,10 @@ struct kvm_vcpu_arch {
>>>
>>> /* Detect first run of a vcpu */
>>> bool has_run_once;
>>> +
>>> + /* True when deferrable sysregs are loaded on the physical CPU,
>>> + * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
>>> + bool sysregs_loaded_on_cpu;
>>> };
>>>
>>> #define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>> index 62c12ab9e6c4..80adbec933de 100644
>>> --- a/arch/arm64/kvm/sys_regs.c
>>> +++ b/arch/arm64/kvm/sys_regs.c
>>> @@ -35,6 +35,7 @@
>>> #include <asm/kvm_coproc.h>
>>> #include <asm/kvm_emulate.h>
>>> #include <asm/kvm_host.h>
>>> +#include <asm/kvm_hyp.h>
>>> #include <asm/kvm_mmu.h>
>>> #include <asm/perf_event.h>
>>> #include <asm/sysreg.h>
>>> @@ -111,6 +112,54 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
>>> return true;
>>> }
>>>
>>> +static u64 read_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg)
>>> +{
>>> + if (vcpu->arch.sysregs_loaded_on_cpu) {
>>> + switch (reg) {
>>> + case SCTLR_EL1: return read_sysreg_el1(sctlr);
>>> + case TTBR0_EL1: return read_sysreg_el1(ttbr0);
>>> + case TTBR1_EL1: return read_sysreg_el1(ttbr1);
>>> + case TCR_EL1: return read_sysreg_el1(tcr);
>>> + case ESR_EL1: return read_sysreg_el1(esr);
>>> + case FAR_EL1: return read_sysreg_el1(far);
>>> + case AFSR0_EL1: return read_sysreg_el1(afsr0);
>>> + case AFSR1_EL1: return read_sysreg_el1(afsr1);
>>> + case MAIR_EL1: return read_sysreg_el1(mair);
>>> + case AMAIR_EL1: return read_sysreg_el1(amair);
>>> + case CONTEXTIDR_EL1: return read_sysreg_el1(contextidr);
>>> + case DACR32_EL2: return read_sysreg(dacr32_el2);
>>> + case IFSR32_EL2: return read_sysreg(ifsr32_el2);
>>> + default: BUG();
>>> + }
>>> + }
>>> +
>>> + return vcpu_sys_reg(vcpu, reg);
>>> +}
>>> +
>>> +static void write_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
>>> +{
>>> + if (vcpu->arch.sysregs_loaded_on_cpu) {
>>> + switch (reg) {
>>> + case SCTLR_EL1: write_sysreg_el1(val, sctlr); return;
>>> + case TTBR0_EL1: write_sysreg_el1(val, ttbr0); return;
>>> + case TTBR1_EL1: write_sysreg_el1(val, ttbr1); return;
>>> + case TCR_EL1: write_sysreg_el1(val, tcr); return;
>>> + case ESR_EL1: write_sysreg_el1(val, esr); return;
>>> + case FAR_EL1: write_sysreg_el1(val, far); return;
>>> + case AFSR0_EL1: write_sysreg_el1(val, afsr0); return;
>>> + case AFSR1_EL1: write_sysreg_el1(val, afsr1); return;
>>> + case MAIR_EL1: write_sysreg_el1(val, mair); return;
>>> + case AMAIR_EL1: write_sysreg_el1(val, amair); return;
>>> + case CONTEXTIDR_EL1: write_sysreg_el1(val, contextidr); return;
>>> + case DACR32_EL2: write_sysreg(val, dacr32_el2); return;
>>> + case IFSR32_EL2: write_sysreg(val, ifsr32_el2); return;
>>> + default: BUG();
>>> + }
>>> + }
>>> +
>>> + vcpu_sys_reg(vcpu, reg) = val;
>>> +}
>>> +
>>> /*
>>> * Generic accessor for VM registers. Only called as long as HCR_TVM
>>> * is set. If the guest enables the MMU, we stop trapping the VM
>>> @@ -133,14 +182,14 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
>>> if (!p->is_aarch32 || !p->is_32bit) {
>>> val = p->regval;
>>> } else {
>>> - val = vcpu_sys_reg(vcpu, reg);
>>> + val = read_deferrable_vm_reg(vcpu, reg);
>>> if (r->reg % 2)
>>> val = (p->regval << 32) | (u64)lower_32_bits(val);
>>> else
>>> val = ((u64)upper_32_bits(val) << 32) |
>>> (u64)lower_32_bits(p->regval);
>>> }
>>> - vcpu_sys_reg(vcpu, reg) = val;
>>> + write_deferrable_vm_reg(vcpu, reg, val);
>>>
>>> kvm_toggle_cache(vcpu, was_enabled);
>>> return true;
>>>
>>
>> I'm slightly uneasy with this. It means that the rest of the KVM code
>> has to know whether a given register is deferrable or not (or face the
>> wrath of the BUG). I'd be more inclined to hide the "loaded on cpu"
>> magic in the vcpu_sys_reg() accessors.
>>
>> Thoughts?
>>
>
> Yes, this is the main reservation I also have with the series.
>
> I did start out with a giant "rewrite everything to vcpu_get_sys_reg and
> vcpu_get_sys_reg" which hides this logic, and we may want to go back to
> that.
>
> That does mean that we need a giant switch statement which knows how to
> read any deferrable EL1 (and EL0) system register from hardware, and
> still BUG/WARN if someone adds a system register but forgets to add that
> handler and test on VHE. Unless there's some fantastic auto-gen
> mechanism that can take a hash define and figure out which sysreg
> instruction to use - I couldn't think of that.
>
> I'm happy to go back to that approach, but I didn't find it that much
> nicer either.
>
> How about I send you the small handful of patches that implement the
> alternative approach and you have a look at that?
Sure, feel free to post them. I wonder if we can take a similar approach
to the hack I used for the CP15 stuff on 32bit, where read/write_sysreg
are automagically turned into the right type of accessor...
I'll have a try.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] crypto: stm32: fix modular build
From: Arnd Bergmann @ 2017-12-11 11:47 UTC (permalink / raw)
To: linux-arm-kernel
Building the stm32 crypto suport as a loadable module causes a build
failure from a simple typo:
drivers/crypto/stm32/stm32-cryp.c:1035:25: error: 'sti_dt_ids' undeclared here (not in a function); did you mean 'stm32_dt_ids'?
This renames the reference to point to the correct symbol.
Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/stm32/stm32-cryp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
index 459755940632..cf1dddbeaa2c 100644
--- a/drivers/crypto/stm32/stm32-cryp.c
+++ b/drivers/crypto/stm32/stm32-cryp.c
@@ -1032,7 +1032,7 @@ static const struct of_device_id stm32_dt_ids[] = {
{ .compatible = "st,stm32f756-cryp", },
{},
};
-MODULE_DEVICE_TABLE(of, sti_dt_ids);
+MODULE_DEVICE_TABLE(of, stm32_dt_ids);
static int stm32_cryp_probe(struct platform_device *pdev)
{
--
2.9.0
^ permalink raw reply related
* [PATCH] nvmem: meson-mx-efuse: fix reading from an offset other than 0
From: Srinivas Kandagatla @ 2017-12-11 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171112183412.12806-1-martin.blumenstingl@googlemail.com>
Hi Martin,
On 12/11/17 18:34, Martin Blumenstingl wrote:
> meson_mx_efuse_read calculates the address internal to the eFuse based
> on the offset and the word size. This works fine with any given offset.
> However, the offset is also included when writing to the output buffer.
> This means that reading 4 bytes at offset 500 tries to write beyond the
> array allocated by the nvmem core as it wants to write the 4 bytes to
> "buffer address + offset (500)".
> This issue did not show up in the previous tests since no driver uses
> any value from the eFuse yet and reading the eFuse via sysfs simply
> reads the whole eFuse, starting at offset 0.
>
> Fix this by only including the offset in the internal address
> calculation.
>
> Fixes: 8caef1fa9176 ("nvmem: add a driver for the Amlogic Meson6/Meson8/Meson8b SoCs")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
Thanks for your patience,
I will send this to Greg along with other fixes some time this week!
thanks,
srini
> drivers/nvmem/meson-mx-efuse.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c
> index a346b4923550..41d3a3c1104e 100644
> --- a/drivers/nvmem/meson-mx-efuse.c
> +++ b/drivers/nvmem/meson-mx-efuse.c
> @@ -156,8 +156,8 @@ static int meson_mx_efuse_read(void *context, unsigned int offset,
> MESON_MX_EFUSE_CNTL1_AUTO_RD_ENABLE,
> MESON_MX_EFUSE_CNTL1_AUTO_RD_ENABLE);
>
> - for (i = offset; i < offset + bytes; i += efuse->config.word_size) {
> - addr = i / efuse->config.word_size;
> + for (i = 0; i < bytes; i += efuse->config.word_size) {
> + addr = (offset + i) / efuse->config.word_size;
>
> err = meson_mx_efuse_read_addr(efuse, addr, &tmp);
> if (err)
>
^ permalink raw reply
* [PATCH v3 01/16] KVM: Take vcpu->mutex outside vcpu_load
From: Cornelia Huck @ 2017-12-11 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-2-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:23 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> As we're about to call vcpu_load() from architecture-specific
> implementations of the KVM vcpu ioctls, but yet we access data
> structures protected by the vcpu->mutex in the generic code, factor
> this logic out from vcpu_load().
>
> x86 is the only architecture which calls vcpu_load() outside of the main
> vcpu ioctl function, and these calls will no longer take the vcpu mutex
> following this patch. However, with the exception of
> kvm_arch_vcpu_postcreate (see below), the callers are either in the
> creation or destruction path of the VCPU, which means there cannot be
> any concurrent access to the data structure, because the file descriptor
> is not yet accessible, or is already gone.
>
> kvm_arch_vcpu_postcreate makes the newly created vcpu potentially
> accessible by other in-kernel threads through the kvm->vcpus array, and
> we therefore take the vcpu mutex in this case directly.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/x86/kvm/vmx.c | 4 +---
> arch/x86/kvm/x86.c | 20 +++++++-------------
> include/linux/kvm_host.h | 2 +-
> virt/kvm/kvm_main.c | 17 ++++++-----------
> 4 files changed, 15 insertions(+), 28 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v2] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform
From: SZ Lin @ 2017-12-11 11:51 UTC (permalink / raw)
To: linux-arm-kernel
Add support for Moxa UC-8410A open platform
The UC-8410A computing platform is designed
for embedded communication-centric industrial applications
The features of UC-8410A are:
* QSPI flash
* SD slot
* 3x LAN
* 8x RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with PCIe/USB signal
* 2x USB host
* TPM
* Watchdog
* RTC
* User LEDs
* Beeper
* Push button
Signed-off-by: Jimmy Chen <jimmy.chen@moxa.com>
Signed-off-by: Harry YJ Jhou <harryyj.jhou@moxa.com>
Signed-off-by: SZ Lin <sz.lin@moxa.com>
--
Changes from v1:
- Add newline between nodes
- Add push button node
- Insert newline between property list and child node
- Include file of "include/dt-bindings/gpio/gpio.h"
- Include file of "include/dt-bindings/input/input.h"
- Use polartiy defines for gpios to make it more readable
- Put 'status' at the end of property list
- Change GPIO pin number in cel_pwr and cel_reset
- Sort the labeled node alphabetically
- Drop container node of regulator and put fixed regulator directly
under root
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 ++++++++++++++++++++++++++++
2 files changed, 242 insertions(+)
create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..62ce9b27ad30 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
dtb-$(CONFIG_SOC_LS1021A) += \
+ ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
dtb-$(CONFIG_SOC_VF610) += \
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
new file mode 100644
index 000000000000..bc73b5187990
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
+ *
+ * Author: Harry YJ Jhou (???) <harryyj.jhou@moxa.com>
+ * Jimmy Chen (???) <jimmy.chen@moxa.com>
+ * SZ Lin (???) <sz.lin@moxa.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "ls1021a.dtsi"
+
+/ {
+ model = "Moxa UC-8410A";
+
+ aliases {
+ enet0_rgmii_phy = &rgmii_phy0;
+ enet1_rgmii_phy = &rgmii_phy1;
+ enet2_rgmii_phy = &rgmii_phy2;
+ };
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ cel_pwr {
+ label = "UC8410A:CEL-PWR";
+ gpios = <&gpio3 27 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ cel_reset {
+ label = "UC8410A:CEL-RESET";
+ gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ str_led {
+ label = "UC8410A:RED:PROG";
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+
+ sw_ready {
+ label = "UC8410A:GREEN:SWRDY";
+ gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ beeper {
+ label = "UC8410A:BEEP";
+ gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led0 {
+ label = "UC8410A:GREEN:PROG2";
+ gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led1 {
+ label = "UC8410A:GREEN:PROG1";
+ gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led2 {
+ label = "UC8410A:GREEN:PROG0";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal0 {
+ label = "UC8410A:GREEN:CEL2";
+ gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal1 {
+ label = "UC8410A:GREEN:CEL1";
+ gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal2 {
+ label = "UC8410A:GREEN:CEL0";
+ gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_red {
+ label = "UC8410A:RED:DIA";
+ gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_green {
+ label = "UC8410A:GREEN:DIA";
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_yellow {
+ label = "UC8410A:YELLOW:DIA";
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pushbtn-key {
+ label = "push button key";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ default-state = "on";
+ };
+ };
+};
+
+&enet0 {
+ phy-handle = <&rgmii_phy0>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet1 {
+ phy-handle = <&rgmii_phy1>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet2 {
+ phy-handle = <&rgmii_phy2>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ rtc {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ };
+
+ tpm {
+ compatible = "infineon,slb9635tt";
+ reg = <0x20>;
+ };
+};
+
+&lpuart0 {
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy at 0 {
+ compatible = "marvell,88e1118";
+ reg = <0x0>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy1: ethernet-phy at 1 {
+ compatible = "marvell,88e1118";
+ reg = <0x1>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy2: ethernet-phy at 2 {
+ compatible = "marvell,88e1118";
+ reg = <0x2>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+};
+
+&qspi {
+ bus-num = <0>;
+ fsl,spi-num-chipselects = <2>;
+ fsl,spi-flash-chipselects = <0>;
+ fsl,qspi-has-second-chip;
+ status = "okay";
+
+ flash: flash at 0 {
+ compatible = "spansion,s25fl064l", "spansion,s25fl164k";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+
+ partitions at 0 {
+ label = "U-Boot";
+ reg = <0x0 0x180000>;
+ };
+
+ partitions at 1 {
+ label = "U-Boot Env";
+ reg = <0x180000 0x680000>;
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.15.1
^ 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