* [GIT PULL] ARM: mediatek: dts64 updates for v4.18
From: Olof Johansson @ 2018-05-15 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e36e9a49-4913-25a8-16a9-31c1fbbfddc9@gmail.com>
On Mon, May 14, 2018 at 01:28:16PM +0200, Matthias Brugger wrote:
> Hi you two,
>
> Please take into account the following commit to 64-bit DTS.
>
> Thanks a lot,
> Matthias
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-dts64
>
> for you to fetch changes up to f1e0d0d8cf454202d21140aace184cc5512a9fdd:
>
> arm64: dts: mt7622: add audio related device nodes (2018-05-11 18:42:20 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [RFC PATCH 07/10] clk: rockchip: set clk-ddr to GET_RATE_NOCACHE.
From: Stephen Boyd @ 2018-05-15 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514211610.26618-8-enric.balletbo@collabora.com>
Quoting Enric Balletbo i Serra (2018-05-14 14:16:07)
> From: Derek Basehore <dbasehore@chromium.org>
>
> This adds the flag to the clk-ddr in rockchip to not use the cached
> rate for get_rate. This is to handle timeout error conditions in SMC
> for the set rate function.
We need some more information here. Why does timeout error condition in
set_rate() matter for get_rate()?
^ permalink raw reply
* [GIT PULL] ARM: mediatek: soc driver updates for v4.18
From: Olof Johansson @ 2018-05-15 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd033549-4998-e376-eb92-16111ec71a07@gmail.com>
On Mon, May 14, 2018 at 01:32:49PM +0200, Matthias Brugger wrote:
> Hi Arnd and Olof,
>
> Below the commits for mediatek soc drivers.
> Please beware that we need the regmap-ktime-fix [1] from Mark Browns static tag.
> I merged that into my branch, but I wanted to let you know, so that you don't
> hit any breakage when pulling in my branch.
Great, and thanks for mentioning it.
>
> Regards,
> Matthias
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
> tags/regmap-ktime-fix
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-soc
>
> for you to fetch changes up to 0afd32c6bb59e41b6692dec4473efaffffcad67b:
>
> Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
> v.4.17-next/soc-test (2018-05-14 12:22:03 +0200)
Merged into next/drivers. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] STi DT update for v4.18 round 1
From: Olof Johansson @ 2018-05-15 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11f8376c-860d-26cf-92f6-38737e513656@st.com>
On Mon, May 14, 2018 at 03:56:08PM +0000, Patrice CHOTARD wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this first round of STi dts update for v4.18
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git
> tags/sti-dt-for-v4.18-round1
>
> for you to fetch changes up to c5bf208a0dc4aee18e03c6ed97eada70ffa9a4d8:
>
> ARM: dts: stihxxx-b2120: Fix complain about IRQ_TYPE_NONE usage
> (2018-05-14 17:40:26 +0200)
>
> ----------------------------------------------------------------
> STi DT update for 4.18:
> - Fix complain about IRQ_TYPE_NONE_usage
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162144.GA8409@e107155-lin>
On Mon, May 14, 2018 at 05:21:44PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Note that the commit restructuring motherboard dtsi touches the file
> in ARM64 DT but that's because of the way the file gets included and
> it's not something newly introduced here.
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-updates-4.18
>
> for you to fetch changes up to b67b00eeddac0fea494d6339618ffd3da071c2e4:
>
> ARM: dts: vexpress: replace '_' with '-' in node names (2018-05-11 14:12:32 +0100)
>
> ----------------------------------------------------------------
> ARMv7 Vexpress updates/cleanups for v4.18
>
> 1. Syntactic restructuring of motherboard include file so that it can be
> included at the top of any other DTS file as it should be rather than
> existing include in the middle of the file at a specific location
>
> 2. Use of standard GPIO controller bindings for few sysreg components
> like LED, MMC Write Protect/Card Detect and Flash Write Protect
> to fix some of the new DTC warnings
>
> 3. Cleanup to replace all underscores('_') with hyphens('-') in the
> device node names
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162317.GB8409@e107155-lin>
On Mon, May 14, 2018 at 05:23:17PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Note that the tag is based on v4.17-rc3 instead of -rc1 as a fix went in
> -rc3 and conflicts with changes here. The conflicts themselves are
> trivial and hence I can based the change on -rc1 if required.
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
>
> Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-4.18
>
> for you to fetch changes up to 349b0f95e1ea718d912ca6875a40813e52a4ba39:
>
> arm64: dts: juno/rtsm: re-structure motherboard includes (2018-05-10 11:01:56 +0100)
>
> ----------------------------------------------------------------
> ARMv8 Juno/Vexpress updates/cleanups for v4.18
>
> 1. Add the missing connections to the STM output port as all endpoint
> connections must be bidirectional.
>
> 2. Replace all the custom OF graph endpoint node names with the standard
> 'endpoint'
>
> 3. Cleanup to replace all underscores('_') with hyphens('-') in the
> device node names
>
> 4. Syntactic restructuring of motherboard include file so that it can be
> included at the top of any other DTS file as it should be rather than
> existing include in the middle of the file at a specific location
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] firmware: scmi: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162607.GC8409@e107155-lin>
On Mon, May 14, 2018 at 05:26:07PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-4.18
>
> for you to fetch changes up to 632de8f542bcd44c756637da0e7d824e7129e496:
>
> firmware: arm_scmi: simplify exit path by returning on error (2018-05-10 10:52:00 +0100)
>
> ----------------------------------------------------------------
> SCMI cleanups for v4.18
>
> This contains all of the trivial review comments that were not
> addressed as the series was already queued up for v4.17 and were not
> critical to go as fixes.
>
> They generally just improve code readability, fix kernel-docs, remove
> unused/unnecessary code, follow standard function naming and simplifies
> certain exit paths.
Nice! Merged into next/drivers now.
-Olof
^ permalink raw reply
* [GIT PULL] Reset controller changes for v4.18
From: Olof Johansson @ 2018-05-15 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526374427.2303.3.camel@pengutronix.de>
On Tue, May 15, 2018 at 10:53:47AM +0200, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> The following changes since commit e6914365fd280fce303a89b8a8d4529af5a2e0f9:
>
> reset: uniphier: fix USB clock line for LD20 (2018-04-27 11:51:12 +0200)
>
> are available in the Git repository at:
>
> git://git.pengutronix.de/pza/linux.git tags/reset-for-4.18
>
> for you to fetch changes up to d7bab65b1f57cdf2d81fc469cea6b2160a50e917:
>
> reset: uniphier: add LD11/LD20 stream demux system reset control (2018-04-27 11:59:05 +0200)
>
> ----------------------------------------------------------------
> Reset controller changes for v4.18
>
> This adds PCIe, SATA, and HSC reset control support on various Uniphier
> SoCs. PCIe reset control is added for Pro5, LD20, and PXs3 SoCs, SATA
> reset control support is added on Pro4 and PXs3 SoCs. The previously
> added PXs2 SATA reset control identifier is changed to the same value
> for consistency. HSC (MPEG2 transport stream I/O and demux system) reset
> controls are added for LD11 and LD20 SoCs.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] DaVinci fixes for v4.17 (part 2)
From: Olof Johansson @ 2018-05-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcf8613b-31df-733b-3443-c1a6176cbdd1@ti.com>
On Tue, May 15, 2018 at 02:52:14PM +0530, Sekhar Nori wrote:
> The following changes since commit 9411ac07cd764be34bbd7ff09125a6b7b9175d4c:
>
> ARM: davinci: fix GPIO lookup for I2C (2018-05-02 14:55:06 +0530)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.17-part-2
>
> for you to fetch changes up to bb7298a7e87cf3430eb62be8746e5d7a07ca9d7c:
>
> ARM: davinci: board-dm646x-evm: set VPIF capture card name (2018-05-15 14:31:12 +0530)
>
> ----------------------------------------------------------------
> Second set of fixes for TI DaVinci.
>
> They are needed for DM6467 EVM to work. The first patch fixes an
> issue with timer interrupt and the second two are needed for video
> driver to probe successfully.
Merged, thanks.
Was DM6467 ever working, so is this a regression?
-Olof
^ permalink raw reply
* [GIT PULL 1/4] Rockchip driver updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2000491.bLgWuj0xar@phil>
On Tue, May 15, 2018 at 12:38:09PM +0200, Heiko Stuebner wrote:
> Hi Arnd, Kevin Olof,
>
> please find below and in the replies the main pull requests for Rockchip
> stuff for 4.18. Depending on timing there may or may not be a second
> round but so far I don't have anything big on the radar.
>
> The signed tags should explain the individual contents, so please pull.
>
>
> Thanks
> Heiko
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-drivers-1
>
> for you to fetch changes up to 9e59c5f66c624b43c766a9fe3b2430e0e976bf0e:
>
> soc: rockchip: power-domain: Fix wrong value when power up pd with writemask (2018-05-14 11:53:26 +0200)
>
> ----------------------------------------------------------------
> Fix for an issue introduced in 2016 where some powerdomains could only
> be turned off but not on again.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/4] Rockchip dts32 updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2461510.NP0ZiRnFEz@phil>
On Tue, May 15, 2018 at 12:38:49PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts32-1
>
> for you to fetch changes up to 08624814cbec12b1ce877bf80f6990ad2b9cdcd7:
>
> ARM: dts: rockchip: default serial for rk3288 Tinker Board (2018-04-20 14:55:07 +0200)
>
> ----------------------------------------------------------------
> Fixed pin numbers for uart4 on rk3288, iommu clocks and small changes
> over multiple boards like default serial setting for rk3288-tinker,
> output selection for the dp83867 on the phycore-som and the newly
> added pwm-backlight delay properties for veyron boards.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 3/4] Rockchip dts64 updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20114925.REm1YfjZS7@phil>
On Tue, May 15, 2018 at 12:39:26PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts64-1
>
> for you to fetch changes up to 17bd0737948aa841b76278a601217b914aa5f18e:
>
> arm64: dts: rockchip: enable hdmi on rk3399-puma-haikou (2018-05-03 14:38:20 +0200)
>
> ----------------------------------------------------------------
> All iommus got their clocks added and rk3399 got support for its
> usb3-phy otg-port and better ajustment for the cpll child clocks.
> On the board side, all rk3399 got their typec phys enabled - which
> is needed for better usb support, the sapphire board got some more
> properties moved to the excavator baseboard where they really belong,
> kevin got a fix to use a real devicetree compatible and puma-haikou
> got its hdmi port enabled.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 4/4] Rockchip arm64 defconfig updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2676342.8y6AX4oR9f@phil>
On Tue, May 15, 2018 at 12:40:05PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-defconfig64-1
>
> for you to fetch changes up to 214f2c319a140f8a0121f362ad8e73ea1576d5ad:
>
> arm64: defconfig: enable rockchip efuse (2018-05-09 16:33:09 +0200)
>
> ----------------------------------------------------------------
> Enablement of Rockchip-specific efuse, io-domain and typec drivers
> as well as general cros-ec, hid, touchscreen bluetooth and wifi-drivers
> on 64bit arm platforms.
>
> ----------------------------------------------------------------
> Enric Balletbo i Serra (3):
> arm64: defconfig: Enable typec-phy and extcon-usbc-cros-ec for rk3399
> arm64: defconfig: Enable Rockchip io-domain driver
> arm64: defconfig: Enable ChromeOS EC drivers for supported Chromebooks.
>
> Ezequiel Garcia (4):
> arm64: defconfig: Enable HID over I2C drivers
> arm64: defconfig: Enable Atmel Maxtouch driver
> arm64: defconfig: Enable Marvell WiFi-Ex PCIe driver
> arm64: defconfig: Enable bluetooth USB support
>
> Heiko Stuebner (1):
> arm64: defconfig: enable rockchip efuse
Merged. Not sure if it's useful to split defconfig updates quite this granular,
might make sense to just do slightly more consolidated patches.
Anyway, no harm, just a bit verbose.
-Olof
^ permalink raw reply
* [PATCH v12 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value.
4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this
notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver
to handle this notification.
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
5. Update the patches commit message and document description
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
Dongjiu Geng (4):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
ACPI / APEI: Add SEI notification type support for ARMv8
arm64: handle NOTIFY_SEI notification by the APEI driver
Documentation/virtual/kvm/api.txt | 42 ++++++++++++++++++++++++++--
arch/arm/include/asm/kvm_host.h | 6 ++++
arch/arm/kvm/guest.c | 12 ++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 ++++
arch/arm64/include/asm/kvm_host.h | 7 +++++
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++
arch/arm64/kernel/traps.c | 4 +++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++-
arch/arm64/kvm/reset.c | 4 +++
arch/arm64/mm/fault.c | 10 +++++++
drivers/acpi/apei/Kconfig | 15 ++++++++++
drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 21 ++++++++++++++
17 files changed, 234 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v12 1/4] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Change from V11:
1. Change the commit message
2. Update the Documentation/virtual/kvm/api.tx
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fc3ae95..66494a5 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4415,3 +4415,14 @@ Parameters: none
This capability indicates if the flic device will be able to get/set the
AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
to discover this without having to create a flic device.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8fb90a0..3587b33 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_AIS_MIGRATION 150
#define KVM_CAP_PPC_GET_CPU_CHAR 151
#define KVM_CAP_S390_BPB 152
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 153
#ifdef KVM_CAP_IRQ_ROUTING
--
1.9.1
^ permalink raw reply related
* [PATCH v12 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++++-
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
10 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 66494a5..36a9dc3 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -819,11 +819,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -865,15 +867,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -894,6 +913,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index ef54013..d81621e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -211,6 +211,12 @@ struct kvm_vcpu_stat {
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 1e0784e..39f895d 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 413dc82..3294885 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr)
vcpu->arch.hcr_el2 = hcr;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a73f63a..1125540 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -326,6 +326,11 @@ struct kvm_vcpu_stat {
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 9abbf30..d815b67 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 5c7f657..f9b7e8f 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -277,6 +277,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
+ (!!vcpu_get_vsesr(vcpu));
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 60666a0..aa0358a 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE);
}
@@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
pend_guest_serror(vcpu, ESR_ELx_ISV);
}
+
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
+{
+ pend_guest_serror(vcpu, syndrome);
+}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 7e3941f..e466f5d 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
return -EFAULT;
return kvm_arm_vcpu_has_attr(vcpu, &attr);
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ memset(&events, 0, sizeof(events));
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp,
+ sizeof(struct kvm_vcpu_events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v12 3/4] ACPI / APEI: Add SEI notification type support for ARMv8
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Note:
Firmware will follow the SError mask rule, if the SError is masked,
the firmware will not deliver NOTIFY_SEI notification.
---
drivers/acpi/apei/Kconfig | 15 ++++++++++++++
drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
3 files changed, 69 insertions(+)
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 52ae543..ff4afc3 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -55,6 +55,21 @@ config ACPI_APEI_SEA
option allows the OS to look for such hardware error record, and
take appropriate action.
+config ACPI_APEI_SEI
+ bool "APEI SError(System Error) Interrupt logging/recovering support"
+ depends on ARM64 && ACPI_APEI_GHES
+ default y
+ help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a hardware error record for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..33f77ae 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { }
static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+
+/*
+ * Return 0 only if one of the SEI error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sei(void)
+{
+ struct ghes *ghes;
+ int ret = -ENOENT;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, &ghes_sei, list) {
+ if (!ghes_proc(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+ return ret;
+}
+
+static void ghes_sei_add(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_add_rcu(&ghes->list, &ghes_sei);
+ mutex_unlock(&ghes_list_mutex);
+}
+
+static void ghes_sei_remove(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_del_rcu(&ghes->list);
+ mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEI */
+static inline void ghes_sei_add(struct ghes *ghes) { }
+static inline void ghes_sei_remove(struct ghes *ghes) { }
+#endif /* CONFIG_ACPI_APEI_SEI */
+
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
* printk is not safe in NMI context. So in NMI handler, we allocate
@@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
@@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_add(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_remove(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c8..9ba59e2 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
section = acpi_hest_get_next(section))
int ghes_notify_sea(void);
+int ghes_notify_sei(void);
#endif /* GHES_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v12 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
Add a helper to handle the NOTIFY_SEI notification, when kernel
gets the NOTIFY_SEI notification, call this helper and let APEI
driver to handle this notification.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/kernel/traps.c | 4 ++++
arch/arm64/mm/fault.c | 10 ++++++++++
3 files changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 07aa8e3..9ee13ad 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int,
})
int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index bbb0fde..d888eb2 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr)
{
u32 aet = arm64_ras_serror_get_severity(esr);
+ /* The APEI driver may handle this RAS error. */
+ if (!handle_guest_sei())
+ return false;
+
switch (aet) {
case ESR_ELx_AET_CE: /* corrected error */
case ESR_ELx_AET_UEO: /* restartable, not yet consumed */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c..8f29bd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
return ret;
}
+int handle_guest_sei(void)
+{
+ int ret = -ENOENT;
+
+ if (IS_ENABLED(CONFIG_ACPI_APEI_SEI))
+ ret = ghes_notify_sei();
+
+ return ret;
+}
+
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
--
1.9.1
^ permalink raw reply related
* [patch v21 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Andy Shevchenko @ 2018-05-15 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526394095-5069-3-git-send-email-oleksandrs@mellanox.com>
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on Mellanox system with BMC equipped with
> Aspeed 2520 SoC for programming CPLD devices.
> +#define ASPEED_JTAG_DATA 0x00
> +#define ASPEED_JTAG_INST 0x04
> +#define ASPEED_JTAG_CTRL 0x08
> +#define ASPEED_JTAG_ISR 0x0C
> +#define ASPEED_JTAG_SW 0x10
> +#define ASPEED_JTAG_TCK 0x14
> +#define ASPEED_JTAG_EC 0x18
> +
> +#define ASPEED_JTAG_DATA_MSB 0x01
> +#define ASPEED_JTAG_DATA_CHUNK_SIZE 0x20
> +#define ASPEED_JTAG_IOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\
> + ASPEED_JTAG_CTL_ENG_OUT_EN |\
> + ASPEED_JTAG_CTL_INST_LEN(len))
Better to read
#define MY_COOL_CONST_OR_MACRO(xxx) \
...
> +#define ASPEED_JTAG_DOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\
> + ASPEED_JTAG_CTL_ENG_OUT_EN |\
> + ASPEED_JTAG_CTL_DATA_LEN(len))
Ditto.
> +static char *end_status_str[] = {"idle", "ir pause", "drpause"};
> +static int aspeed_jtag_freq_set(struct jtag *jtag, u32 freq)
> +{
> + struct aspeed_jtag *aspeed_jtag = jtag_priv(jtag);
> + unsigned long apb_frq;
> + u32 tck_val;
> + u16 div;
> +
> + apb_frq = clk_get_rate(aspeed_jtag->pclk);
> + div = (apb_frq % freq == 0) ? (apb_frq / freq) - 1 : (apb_frq / freq);
Isn't it the same as
div = (apb_frq - 1) / freq;
?
> + tck_val = aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_TCK);
> + aspeed_jtag_write(aspeed_jtag,
> + (tck_val & ASPEED_JTAG_TCK_DIVISOR_MASK) | div,
> + ASPEED_JTAG_TCK);
> + return 0;
> +}
> +static void aspeed_jtag_sw_delay(struct aspeed_jtag *aspeed_jtag, int cnt)
> +{
> + int i;
> +
> + for (i = 0; i < cnt; i++)
> + aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_SW);
Isn't it readsl() (or how it's called, I don't remember).
> +}
> +static void aspeed_jtag_wait_instruction_pause(struct aspeed_jtag *aspeed_jtag)
> +{
> + wait_event_interruptible(aspeed_jtag->jtag_wq, aspeed_jtag->flag &
> + ASPEED_JTAG_ISR_INST_PAUSE);
In such cases I prefer to see a new line with a parameter in full.
Check all places.
> + aspeed_jtag->flag &= ~ASPEED_JTAG_ISR_INST_PAUSE;
> +}
> +static void aspeed_jtag_sm_cycle(struct aspeed_jtag *aspeed_jtag, const u8 *tms,
> + int len)
> +{
> + int i;
> +
> + for (i = 0; i < len; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, tms[i], 0);
> +}
> +
> +static void aspeed_jtag_run_test_idle_sw(struct aspeed_jtag *aspeed_jtag,
> + struct jtag_run_test_idle *runtest)
> +{
> + static const u8 sm_pause_irpause[] = {1, 1, 1, 1, 0, 1, 0};
> + static const u8 sm_pause_drpause[] = {1, 1, 1, 0, 1, 0};
> + static const u8 sm_idle_irpause[] = {1, 1, 0, 1, 0};
> + static const u8 sm_idle_drpause[] = {1, 0, 1, 0};
> + static const u8 sm_pause_idle[] = {1, 1, 0};
> + int i;
> +
> + /* SW mode from idle/pause-> to pause/idle */
> + if (runtest->reset) {
> + for (i = 0; i < ASPEED_JTAG_RESET_CNTR; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, 1, 0);
> + }
I would rather split this big switch to a few helper functions per
each status of surrounding switch.
> +
> + /* Stay on IDLE for at least TCK cycle */
> + for (i = 0; i < runtest->tck; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, 0, 0);
> +}
> +/**
> + * aspeed_jtag_run_test_idle:
> + * JTAG reset: generates at least 9 TMS high and 1 TMS low to force
> + * devices into Run-Test/Idle State.
> + */
It's rather broken kernel doc.
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_CTL_ENG_EN |
> + ASPEED_JTAG_CTL_ENG_OUT_EN |
> + ASPEED_JTAG_CTL_FORCE_TMS, ASPEED_JTAG_CTRL);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_EC_GO_IDLE,
> + ASPEED_JTAG_EC);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
Here you have permutations of flag some of which are repeatetive in
the code. Perhaps make additional definitions instead.
Check other similar places.
> + char tdo;
Indentation.
> + if (xfer->direction == JTAG_READ_XFER)
> + tdi = UINT_MAX;
> + else
> + tdi = data[index];
> + if (xfer->direction == JTAG_READ_XFER)
> + tdi = UINT_MAX;
> + else
> + tdi = data[index];
Take your time to think how the above duplication can be avoided.
> + }
> + }
> +
> + tdo = aspeed_jtag_tck_cycle(aspeed_jtag, 1, tdi & ASPEED_JTAG_DATA_MSB);
> + data[index] |= tdo << (shift_bits % ASPEED_JTAG_DATA_CHUNK_SIZE);
> +}
> + if (endstate != JTAG_STATE_IDLE) {
Why not to use positive check?
> + int i;
> +
> + for (i = 0; i <= xfer->length / BITS_PER_BYTE; i++) {
> + pos += snprintf(&dbg_str[pos], sizeof(dbg_str) - pos,
> + "0x%02x ", xfer_data[i]);
> + }
Oh, NO! Consider reading printk-formats (for %*ph) and other
documentation about available APIs.
> + if (!(aspeed_jtag->mode & JTAG_XFER_HW_MODE)) {
> + /* SW mode */
This is rather too complex to be in one function.
> + } else {
> + /* hw mode */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_SW);
> + aspeed_jtag_xfer_hw(aspeed_jtag, xfer, data);
For symmetry it might be another function.
> + }
> + dev_dbg(aspeed_jtag->dev, "status %x\n", status);
Perhaps someone should become familiar with tracepoints?
> + dev_err(aspeed_jtag->dev, "irq status:%x\n",
> + status);
Huh, really?! SPAM.
(I would drop it completely, though you may use ratelimited variant)
> + ret = IRQ_NONE;
> + }
> + return ret;
> +}
> + clk_prepare_enable(aspeed_jtag->pclk);
This might fail.
> + dev_dbg(&pdev->dev, "IRQ %d.\n", aspeed_jtag->irq);
Noise even for debug.
> + err = jtag_register(jtag);
Perhaps we might have devm_ variant of this. Check how SPI framework
deal with a such.
> +static int aspeed_jtag_remove(struct platform_device *pdev)
> +{
> + struct jtag *jtag;
> +
> + jtag = platform_get_drvdata(pdev);
Usually we put this on one line
> + aspeed_jtag_deinit(pdev, jtag_priv(jtag));
> + jtag_unregister(jtag);
> + jtag_free(jtag);
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 05/61] clk: samsung: simplify getting .drvdata
From: Stephen Boyd @ 2018-05-15 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93ee0d94-81aa-db81-2bff-87f5f91bc9d3@samsung.com>
Quoting Sylwester Nawrocki (2018-05-15 02:32:12)
> On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
> >
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> It seems to be the only clk/samsung patch in the v4.18 queue, please
> feel free to apply it directly.
Ok. I'll pick it up.
^ permalink raw reply
* [PATCH 05/61] clk: samsung: simplify getting .drvdata
From: Stephen Boyd @ 2018-05-15 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180419140641.27926-6-wsa+renesas@sang-engineering.com>
Quoting Wolfram Sang (2018-04-19 07:05:35)
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH RESEND] clk: uniphier: add LD11/LD20 stream demux system clock
From: Stephen Boyd @ 2018-05-15 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515021416.31760-1-suzuki.katsuhiro@socionext.com>
Quoting Katsuhiro Suzuki (2018-05-14 19:14:16)
> Add clock for MPEG2 transport stream I/O and demux system (HSC) on
> UniPhier LD11/LD20 SoCs.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
^ permalink raw reply
* [patch v21 1/4] drivers: jtag: Add JTAG core driver
From: Andy Shevchenko @ 2018-05-15 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526394095-5069-2-git-send-email-oleksandrs@mellanox.com>
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices which equipped with JTAG interface
> using standard transactions.
>
> Driver exposes set of IOCTL to user space for:
> - XFER:
> - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
> - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
> - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> number of clocks).
> - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.
>
> Driver core provides set of internal APIs for allocation and
> registration:
> - jtag_register;
> - jtag_unregister;
> - jtag_alloc;
> - jtag_free;
>
> Platform driver on registration with jtag-core creates the next
> entry in dev folder:
> /dev/jtagX
> 0xB0 all RATIO devices in development:
> <mailto:vgo@ratio.de>
> 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
> +0xB2 00-0f linux/jtag.h JTAG driver
> + <mailto:oleksandrs@mellanox.com>
Consider to preserve style (upper vs. lower).
> + This provides basic core functionality support for JTAG class devices.
> + Hardware that is equipped with a JTAG microcontroller can be
> + supported by using this driver's interfaces.
> + This driver exposes a set of IOCTLs to the user space for
> + the following commands:
> + SDR: (Scan Data Register) Performs an IEEE 1149.1 Data Register scan
> + SIR: (Scan Instruction Register) Performs an IEEE 1149.1 Instruction
> + Register scan.
> + RUNTEST: Forces the IEEE 1149.1 bus to a run state for a specified
> + number of clocks or a specified time period.
Something feels wrong with formatting here.
> +#define MAX_JTAG_NAME_LEN (sizeof("jtag") + 5)
Interesting definition. Why not to set to 10 explicitly? And why 10?
(16 sounds better)
> +struct jtag {
> + struct miscdevice miscdev;
> + struct device *dev;
Doesn't miscdev parent contain exactly this one?
> + const struct jtag_ops *ops;
> + int id;
> + bool opened;
> + struct mutex open_lock;
> + unsigned long priv[0];
> +};
> + err = copy_to_user(u64_to_user_ptr(xfer.tdio),
> + (void *)(xfer_data), data_size);
Redundant parens in one case. Check the rest similar places.
> +static int jtag_open(struct inode *inode, struct file *file)
> +{
> + struct jtag *jtag = container_of(file->private_data, struct jtag,
> + miscdev);
I would don't care about length and put it on one line.
> + if (jtag->opened) {
> + jtag->opened = true;
> + jtag->opened = false;
Can it be opened non exclusively several times? If so, this needs to
be a ref counter instead.
> + if (!ops->idle || !ops->mode_set || !ops->status_get || !ops->xfer)
> + return NULL;
Are all of them mandatory?
> +int jtag_register(struct jtag *jtag)
Perhaps devm_ variant.
> +#define jtag_u64_to_ptr(arg) ((void *)(uintptr_t)arg)
Where is this used or supposed to be used?
> +#define JTAG_MAX_XFER_DATA_LEN 65535
Is this limitation from some spec?
Otherwise why not to allow 64K?
> +/**
> + * struct jtag_ops - callbacks for jtag control functions:
> + *
> + * @freq_get: get frequency function. Filled by device driver
> + * @freq_set: set frequency function. Filled by device driver
> + * @status_get: set status function. Filled by device driver
> + * @idle: set JTAG to idle state function. Filled by device driver
> + * @xfer: send JTAG xfer function. Filled by device driver
> + */
Perhaps you need to describe which of them are _really_ mandatory and
which are optional.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 0/3] fix free pmd/pte page handlings on x86
From: Toshi Kani @ 2018-05-15 21:39 UTC (permalink / raw)
To: linux-arm-kernel
This series fixes two issues in the x86 ioremap free page handlings
for pud/pmd mappings.
Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables
the free page handling on x86-PAE.
Patch 02-03 fixes a possible issue with speculation which can cause
stale page-directory cache.
- Patch 02 is from Chintan's v9 01/04 patch [1], which adds a new arg
'addr'. This avoids merge conflicts with his series.
- Patch 03 adds a TLB purge (INVLPG) to purge page-structure caches
that may be cached by speculation. See the patch descriptions for
more detal.
[1] https://patchwork.kernel.org/patch/10371015/
v2:
- Reordered patch-set, so that patch 01 can be applied independently.
- Added a NULL pointer check for the page alloc in patch 03.
---
Toshi Kani (2):
1/3 x86/mm: disable ioremap free page handling on x86-PAE
3/3 x86/mm: add TLB purge to free pmd/pte page interfaces
Chintan Pandya (1):
2/3 ioremap: Update pgtable free interfaces with addr
---
arch/arm64/mm/mmu.c | 4 +--
arch/x86/mm/pgtable.c | 59 +++++++++++++++++++++++++++++++++++++------
include/asm-generic/pgtable.h | 8 +++---
lib/ioremap.c | 4 +--
4 files changed, 59 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH v2 1/3] x86/mm: disable ioremap free page handling on x86-PAE
From: Toshi Kani @ 2018-05-15 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515213931.23885-1-toshi.kani@hpe.com>
ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd
tables are not shared among processes on x86-PAE. Therefore, any
update to sync'd pmd entries need re-syncing. Freeing a pte page
also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().
Disable free page handling on x86-PAE. pud_free_pmd_page() and
pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
This assures that ioremap() does not update sync'd pmd entries at the
cost of falling back to pte mappings.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/x86/mm/pgtable.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13c50e4..08cdd7c13619 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -715,6 +715,7 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+#ifdef CONFIG_X86_64
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
@@ -762,4 +763,22 @@ int pmd_free_pte_page(pmd_t *pmd)
return 1;
}
+
+#else /* !CONFIG_X86_64 */
+
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
+{
+ return pud_none(*pud);
+}
+
+/*
+ * Disable free page handling on x86-PAE. This assures that ioremap()
+ * does not update sync'd pmd entries. See vmalloc_sync_one().
+ */
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
+{
+ return pmd_none(*pmd);
+}
+
+#endif /* CONFIG_X86_64 */
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
^ 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