* [PATCH v7 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: vijay.kilari at gmail.com @ 2016-09-23 15:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
This patchset adds API for saving and restoring
of VGICv3 registers to support live migration with new vgic feature.
This API definition is as per version of VGICv3 specification
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
The patch 3 & 4 are picked from the Pavel's previous implementation.
http://www.spinics.net/lists/kvm/msg122040.html
v6 => v7:
- Rename all patches heading from vgic-new to vgic
- Moved caching of priority and ID bits from vgic global struct
to vgic_cpu struct.
v5 => v6:
- Collated all register definitions to single patch (4)
- Introduce macro to convert userspace MPIDR format to MPIDR reg format
- Check on ICC_CTLR_EL1.CBPR value is made while accessing ICC_BPR1_EL1
- Cached ich_vtr_el2 and guests priority and ID bits
- Check on number of priority and ID bits when ICC_CTRL_EL1 write is made
- Check is made on SRE bit for ICC_SRE_EL1 write
v4 => v5:
- ICC_CTLR_EL1 access is updated to reflect HW values
- Updated ICC reg access mask and shift macros
- Introduced patch 4 for VMCR changes
- Other minor fixes.
v3 => v4:
- Rebased to latest code base
- Moved vgic_uaccess() from vgic-mmio-v2.c to vgic-mmio.c
- Dropped macro REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED_UACCESS
- Dropped LE conversion for userspace access
- Introduced vgic_uaccess_write_pending() for ISPENDR write
- Change macro KVM_DEV_ARM_VGIC_V3_CPUID_MASK to KVM_DEV_ARM_VGIC_V3_MIDR_MASK
- Refactored some code as common code.
- Changed handing of ICC_* registers
- Allowed ICC_SRE_EL1 read by userspace
- Fixed KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_* macros
v2 => v3:
- Implemented separate API for ISPENDR and ICPENDR to
read soft_pending instead of pending for level triggerred interrupts
- Implemented ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO to access line level
- Rebased on top of Christoffer's patch set
http://www.spinics.net/lists/kvm/msg136840.html
NOTE: GICD_STATUSR and GICR_STATUSR are implemented as RAZ/WI.
v1 => v2:
- The init sequence change patch is no more required.
Fixed in patch 2 by using static vgic_io_dev regions structure instead
of using dynamic allocation pointer.
- Updated commit message of patch 4.
- Dropped usage of union to manage 32-bit and 64-bit access in patch 1.
Used local variable for 32-bit access.
- Updated macro __ARM64_SYS_REG and ARM64_SYS_REG in
arch/arm64/include/uapi/asm/kvm.h as per qemu requirements.
Vijaya Kumar K (7):
arm/arm64: vgic: Implement support for userspace access
arm/arm64: vgic: Add distributor and redistributor access
arm/arm64: vgic: Introduce find_reg_by_id()
irqchip/gic-v3: Add missing system register definitions
arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
arm/arm64: vgic: Implement VGICv3 CPU interface access
arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
arch/arm64/include/uapi/asm/kvm.h | 13 ++
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/sys_regs.c | 22 ++-
arch/arm64/kvm/sys_regs.h | 4 +
include/kvm/arm_vgic.h | 9 +
include/linux/irqchip/arm-gic-v3.h | 45 ++++-
virt/kvm/arm/vgic/vgic-kvm-device.c | 224 +++++++++++++++++++++++--
virt/kvm/arm/vgic/vgic-mmio-v2.c | 57 +------
virt/kvm/arm/vgic/vgic-mmio-v3.c | 200 ++++++++++++++++++++--
virt/kvm/arm/vgic/vgic-mmio.c | 149 ++++++++++++++++-
virt/kvm/arm/vgic/vgic-mmio.h | 28 ++++
virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
virt/kvm/arm/vgic/vgic-v3.c | 18 +-
virt/kvm/arm/vgic/vgic.h | 45 +++++
14 files changed, 1035 insertions(+), 104 deletions(-)
create mode 100644 virt/kvm/arm/vgic/vgic-sys-reg-v3.c
--
1.9.1
^ permalink raw reply
* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Rob Herring @ 2016-09-23 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473960166-30155-2-git-send-email-okaya@codeaurora.org>
On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> index fd5618b..47bfb5a 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
> the channel nodes appear on their own, not under a management node.
>
> Required properties:
> -- compatible: must contain "qcom,hidma-1.0"
> +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
> +for MSI capable HW.
Do you have an SoC part number yet? If so, please use that instead.
> - reg: Addresses for the transfer and event channel
> - interrupts: Should contain the event interrupt
> - desc-count: Number of asynchronous requests this channel can handle
> - iommus: required a iommu node
>
> +Optional properties for MSI:
> +- msi-parent: pointer to the MSI controller object with the DeviceID in use.
> +
> +Example:
> + msi_parent: <&msi0 0x80024>
> +
> +msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
> +is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
> +instance 1.
> +
> Example:
>
> Hypervisor OS configuration:
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 07/11] dt-bindings: Add DMA bindings for STM32 USART
From: Rob Herring @ 2016-09-23 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473957763-30629-8-git-send-email-alexandre.torgue@st.com>
On Thu, Sep 15, 2016 at 06:42:39PM +0200, Alexandre TORGUE wrote:
> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Squash this with the other binding patch. You are describing the h/w
block, do so completely.
>
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> index 75b1400..85ec5f2 100644
> --- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> @@ -12,6 +12,8 @@ stm32(f4) or stm32f7.
> Optional properties:
> - pinctrl: The reference on the pins configuration
> - st,hw-flow-ctrl: bool flag to enable hardware flow control.
> +- dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt
> +- dma-names: "rx" and/or "tx"
>
> Examples:
> usart4: serial at 40004c00 {
> @@ -32,3 +34,13 @@ usart2: serial at 40004400 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>;
> };
> +
> +usart1: serial at 40011000 {
> + compatible = "st,stm32-usart", "st,stm32-uart";
> + reg = <0x40011000 0x400>;
> + interrupts = <37>;
> + clocks = <&rcc 0 164>;
> + dmas = <&dma2 2 4 0x414 0x0>,
> + <&dma2 7 4 0x414 0x0>;
> + dma-names = "rx", "tx";
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Rob Herring @ 2016-09-23 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473957763-30629-3-git-send-email-alexandre.torgue@st.com>
On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
> This adds documentation of device tree bindings for the
> STM32 USART
Please make your subject prefixes consistent and drop "DOCUMENTATION".
>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> new file mode 100644
> index 0000000..75b1400
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> @@ -0,0 +1,34 @@
> +* STMicroelectronics STM32 USART
> +
> +Required properties:
> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
> +the device supports synchronous mode and is compatible with
> +stm32(f4) or stm32f7.
Why not put f4 in the compatible string. stm32 is too generic.
What determines sync mode or not? If it is IP configuration fixed in the
design, then this is fine. If it is user choice or board dependent, then
use a separate property.
> +- reg: The address and length of the peripheral registers space
> +- interrupts: The interrupt line of the USART instance
> +- clocks: The input clock of the USART instance
> +
> +Optional properties:
> +- pinctrl: The reference on the pins configuration
> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
> +
> +Examples:
> +usart4: serial at 40004c00 {
> + compatible = "st,stm32-uart";
> + reg = <0x40004c00 0x400>;
> + interrupts = <52>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart4>;
> +};
> +
> +usart2: serial at 40004400 {
> + compatible = "st,stm32-usart", "st,stm32-uart";
What are valid combinations? usart is sync only, not sync and async?
> + reg = <0x40004400 0x400>;
> + interrupts = <38>;
> + clocks = <&clk_pclk1>;
> + st,hw-flow-ctrl;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>;
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Santosh Shilimkar @ 2016-09-23 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923142634.zkaqxmiif22kws2e@atomide.com>
On 9/23/2016 7:26 AM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
>> On 09/22/16 21:07, Tony Lindgren wrote:
[...]
>> On which linux-next version you are seeing this?
>
> This was with next-20160922. But testing it again this is just another
> regression caused by "softirq: fix tasklet_kill() and its users", so adding
> Santosh to Cc.
>
> So no need to revert $subject patch.
>
So your driver also looks like fiddling with tasklet core structures if
you got impacted because of the core change. After the merge window
am going to take stab at bad users of tasklet but below is
quick snap shot conversation I had with Thomas and Andrew...
------------------------------------------------------------------
B1;2802;0cOn Wed, 21 Sep 2016, Santosh Shilimkar wrote:
> I requested you to include this patch but now am not sure anymore.
> Looks like there are almost 30 more users which are directly
> tweaking 'tasklet_struct' fields and calling other APIs. Hunting them
> and fixing them probably would be an exercise and also those changes
> needs those changed drivers to be tested.
>
> What do you suggest ? At least this patch needs to be dropped as of now
> till we can have complete coverage for those bad users.
Yes, it needs to be dropped. Stephen, can you please revert it from next?
How to fix this: The only way is to review all tasklet usage sites for
creative abuse and then fix them one by one. This needs to be done anyway
because those are ticking timebombs even without changes in the core
code. I looked at one of the offenders and it's broken today, it's just
protected by the extremly low probablity to hit the wreckage case.
What you can do to coerce the developers/maintainers of offending code into
looking at the mess they created/merged is to implement accessors for the
tasklet struct fields and replace the open coded fiddling with them.
Once that is done, rename the struct fields to something which is absurd
enough to type. But don't worry, you will find people doing that. I
catched a few brainwrecks who actually used:
irqdesc->core_internal_state__do_not_mess_with_it
in their code.
Now after having everything converted to accessors, you can add sanity
checks into the accessors and emit WARN_ONCE() when they are used in the
wrong context. That'll make them look and explain why they think that
fiddling in the internals is a good idea.
Thanks,
tglx
------------------------------------------------------------------
^ permalink raw reply
* [PATCH 3/3] selftests: arm64: add test for inexact watchpoint address handling
From: Pavel Labath @ 2016-09-23 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474643941-109020-1-git-send-email-labath@google.com>
This adds a test which triggers hardware watchpoints by memory accesses
of different sizes. Memory accesses of large blocks of memory were
confusing the kernel as in these cases, the address reported by the
hardware did not exactly match the address we were watching.
This is a follow-up to: "arm64: hw_breakpoint: Handle inexact watchpoint
addresses".
Signed-off-by: Pavel Labath <labath@google.com>
---
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test-arm.c | 217 +++++++++++++++++++++
2 files changed, 221 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test-arm.c
diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile
index 74e533f..458a31a 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -5,6 +5,9 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
ifeq ($(ARCH),x86)
TEST_PROGS := breakpoint_test
endif
+ifeq ($(ARCH),arm64)
+TEST_PROGS := breakpoint_test-arm
+endif
TEST_PROGS += step_after_suspend_test
@@ -13,4 +16,4 @@ all: $(TEST_PROGS)
include ../lib.mk
clean:
- rm -fr breakpoint_test step_after_suspend_test
+ rm -fr breakpoint_test breakpoint_test-arm step_after_suspend_test
diff --git a/tools/testing/selftests/breakpoints/breakpoint_test-arm.c b/tools/testing/selftests/breakpoints/breakpoint_test-arm.c
new file mode 100644
index 0000000..3ed46b7
--- /dev/null
+++ b/tools/testing/selftests/breakpoints/breakpoint_test-arm.c
@@ -0,0 +1,217 @@
+/*
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define _GNU_SOURCE
+
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/ptrace.h>
+#include <sys/uio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <elf.h>
+#include <signal.h>
+
+#include "../kselftest.h"
+
+enum Test {
+ TEST_WRITE_1, TEST_WRITE_2, TEST_WRITE_4, TEST_WRITE_8,
+ TEST_WRITE_16, TEST_WRITE_32, TEST_MAX
+};
+
+struct Data {
+ union {
+ uint8_t u8[32];
+ uint16_t u16[16];
+ uint32_t u32[8];
+ uint64_t u64[4];
+ };
+};
+volatile struct Data var __aligned(32);
+
+
+void child(enum Test test)
+{
+ if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) != 0) {
+ perror("ptrace(PTRACE_TRACEME) failed");
+ _exit(1);
+ }
+
+ if (raise(SIGSTOP) != 0) {
+ perror("raise(SIGSTOP) failed");
+ _exit(1);
+ }
+
+ switch (test) {
+ case TEST_WRITE_1:
+ var.u8[31] = 47;
+ break;
+ case TEST_WRITE_2:
+ var.u16[15] = 47;
+ break;
+ case TEST_WRITE_4:
+ var.u32[7] = 47;
+ break;
+ case TEST_WRITE_8:
+ var.u64[3] = 47;
+ break;
+ case TEST_WRITE_16:
+ __asm__ volatile ("stp x29, x30, %0" : "=m" (var.u64[2]));
+ break;
+ case TEST_WRITE_32:
+ __asm__ volatile ("stp q29, q30, %0" : "=m" (var));
+ break;
+ }
+
+ _exit(0);
+}
+
+static bool set_watchpoint(pid_t pid, const volatile void *address,
+ size_t size)
+{
+ const unsigned int byte_mask = (1 << size) - 1;
+ const unsigned int type = 2; /* Write */
+ const unsigned int enable = 1;
+ const unsigned int control = byte_mask << 5 | type << 3 | enable;
+ struct user_hwdebug_state dreg_state;
+ struct iovec iov;
+
+ memset(&dreg_state, 0, sizeof(dreg_state));
+ dreg_state.dbg_regs[0].addr = (uintptr_t)address;
+ dreg_state.dbg_regs[0].ctrl = control;
+ iov.iov_base = &dreg_state;
+ iov.iov_len = offsetof(struct user_hwdebug_state, dbg_regs) +
+ sizeof(dreg_state.dbg_regs[0]);
+ if (ptrace(PTRACE_SETREGSET, pid, NT_ARM_HW_WATCH, &iov) == 0)
+ return true;
+
+ if (errno == EIO) {
+ printf("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) "
+ "not supported on this hardware\n");
+ ksft_exit_skip();
+ }
+ perror("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) failed");
+ return false;
+}
+
+
+bool run_test(enum Test test)
+{
+ int status;
+ siginfo_t siginfo;
+ pid_t pid = fork();
+ pid_t wpid;
+
+ if (pid < 0) {
+ perror("fork() failed");
+ return false;
+ }
+ if (pid == 0)
+ child(test);
+
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGSTOP) {
+ printf("child did not stop with SIGSTOP\n");
+ return false;
+ }
+
+ if (!set_watchpoint(pid, &var.u64[3], 8))
+ return false;
+
+ if (ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) {
+ perror("ptrace(PTRACE_SINGLESTEP) failed");
+ return false;
+ }
+
+ alarm(3);
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ alarm(0);
+ if (WIFEXITED(status)) {
+ printf("child did not single-step\n");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGTRAP) {
+ printf("child did not stop with SIGTRAP\n");
+ return false;
+ }
+ if (ptrace(PTRACE_GETSIGINFO, pid, NULL, &siginfo) != 0) {
+ perror("ptrace(PTRACE_GETSIGINFO)");
+ return false;
+ }
+ if (siginfo.si_code != TRAP_HWBKPT) {
+ printf("Unexpected si_code %d\n", siginfo.si_code);
+ return false;
+ }
+
+ kill(pid, SIGKILL);
+ wpid = waitpid(pid, &status, 0);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ return true;
+}
+
+void sigalrm(int sig)
+{
+}
+
+int main(int argc, char **argv)
+{
+ int opt;
+ bool succeeded = true;
+ enum Test test;
+ struct sigaction act;
+
+ act.sa_handler = sigalrm;
+ sigemptyset(&act.sa_mask);
+ act.sa_flags = 0;
+ sigaction(SIGALRM, &act, NULL);
+ for (test = 0; test < TEST_MAX; ++test) {
+ printf("Test %d ", test);
+ if (run_test(test)) {
+ printf("[OK]\n");
+ ksft_inc_pass_cnt();
+ } else {
+ printf("[FAILED]\n");
+ ksft_inc_fail_cnt();
+ succeeded = false;
+ }
+ }
+
+ ksft_print_cnts();
+ if (succeeded)
+ ksft_exit_pass();
+ else
+ ksft_exit_fail();
+}
+
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pavel Labath @ 2016-09-23 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474643941-109020-1-git-send-email-labath@google.com>
Arm64 hardware does not always report a watchpoint hit address that
matches one of the watchpoints set. It can also report an address
"near" the watchpoint if a single instruction access both watched and
unwatched addresses. There is no straight-forward way, short of
disassembling the offending instruction, to map that address back to
the watchpoint.
Previously, when the hardware reported a watchpoint hit on an address
that did not match our watchpoint (this happens in case of instructions
which access large chunks of memory such as "stp") the process would
enter a loop where we would be continually resuming it (because we did
not recognise that watchpoint hit) and it would keep hitting the
watchpoint again and again. The tracing process would never get
notified of the watchpoint hit.
This commit fixes the problem by looking at the watchpoints near the
address reported by the hardware. If the address does not exactly match
one of the watchpoints we have set, it attributes the hit to the
nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
think we can do much more, given the hardware limitations.
Signed-off-by: Pavel Labath <labath@google.com>
---
arch/arm64/kernel/hw_breakpoint.c | 98 +++++++++++++++++++++++++--------------
1 file changed, 64 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 14562ae..3ce27ea 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -664,49 +664,63 @@ unlock:
}
NOKPROBE_SYMBOL(breakpoint_handler);
+/*
+ * Arm64 hardware does not always report a watchpoint hit address that matches
+ * one of the watchpoints set. It can also report an address "near" the
+ * watchpoint if a single instruction access both watched and unwatched
+ * addresses. There is no straight-forward way, short of disassembling the
+ * offending instruction, to map that address back to the watchpoint. This
+ * function computes the distance of the memory access from the watchpoint as a
+ * heuristic for the likelyhood that a given access triggered the watchpoint.
+ *
+ * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
+ * exception" of ARMv8 Architecture Reference Manual for details.
+ *
+ * The function returns the distance of the address from the bytes watched by
+ * the watchpoint. In case of an exact match, it returns 0.
+ */
+static u64 get_distance_from_watchpoint(unsigned long addr, int i,
+ struct arch_hw_breakpoint *info)
+{
+ u64 wp_low, wp_high;
+ int first_bit;
+
+ first_bit = ffs(info->ctrl.len);
+ if (first_bit == 0)
+ return -1;
+
+ wp_low = info->address + first_bit - 1;
+ wp_high = info->address + fls(info->ctrl.len) - 1;
+ if (addr < wp_low)
+ return wp_low - addr;
+ else if (addr > wp_high)
+ return addr - wp_high;
+ else
+ return 0;
+
+}
+
static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
- int i, step = 0, *kernel_step, access;
- u32 ctrl_reg;
- u64 val, alignment_mask;
+ int i, step = 0, *kernel_step, access, closest_match = 0;
+ u64 min_dist = -1, dist;
struct perf_event *wp, **slots;
struct debug_info *debug_info;
struct arch_hw_breakpoint *info;
- struct arch_hw_breakpoint_ctrl ctrl;
slots = this_cpu_ptr(wp_on_reg);
debug_info = ¤t->thread.debug;
+ /*
+ * Find all watchpoints that match the reported address. If no exact
+ * match is found. Attribute the hit to the closest watchpoint.
+ */
+ rcu_read_lock();
for (i = 0; i < core_num_wrps; ++i) {
- rcu_read_lock();
-
wp = slots[i];
-
if (wp == NULL)
- goto unlock;
-
- info = counter_arch_bp(wp);
- /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
- if (is_compat_task()) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
- } else {
- alignment_mask = 0x7;
- }
-
- /* Check if the watchpoint value matches. */
- val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- if (val != (addr & ~alignment_mask))
- goto unlock;
-
- /* Possible match, check the byte address select to confirm. */
- ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
- decode_ctrl_reg(ctrl_reg, &ctrl);
- if (!((1 << (addr & alignment_mask)) & ctrl.len))
- goto unlock;
+ continue;
/*
* Check that the access type matches.
@@ -715,7 +729,18 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
access = (esr & AARCH64_ESR_ACCESS_MASK) ? HW_BREAKPOINT_W :
HW_BREAKPOINT_R;
if (!(access & hw_breakpoint_type(wp)))
- goto unlock;
+ continue;
+
+ info = counter_arch_bp(wp);
+
+ dist = get_distance_from_watchpoint(addr, i, info);
+ if (dist < min_dist) {
+ min_dist = dist;
+ closest_match = i;
+ }
+ /* Is this an exact match? */
+ if (dist != 0)
+ continue;
info->trigger = addr;
perf_bp_event(wp, regs);
@@ -723,10 +748,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
/* Do we need to handle the stepping? */
if (is_default_overflow_handler(wp))
step = 1;
-
-unlock:
- rcu_read_unlock();
}
+ if (min_dist > 0 && min_dist != -1) {
+ /* No exact match found. */
+ wp = slots[closest_match];
+ info = counter_arch_bp(wp);
+ info->trigger = addr;
+ perf_bp_event(wp, regs);
+ }
+ rcu_read_unlock();
if (!step)
return 0;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/3] arm64: hw_breakpoint: Add get_hwbkt_alignment_mask
From: Pavel Labath @ 2016-09-23 15:18 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds a utility function for computing the alignment mask of a
hardware breakpoint and fixes arch_validate_hwbkpt_settings to use that
instead.
Signed-off-by: Pavel Labath <labath@google.com>
---
arch/arm64/kernel/hw_breakpoint.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 26a6bf7..14562ae 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -473,6 +473,16 @@ static int arch_build_bp_info(struct perf_event *bp)
return 0;
}
+static unsigned int get_hwbkpt_alignment_mask(struct perf_event *bp)
+{
+ const struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ if (is_compat_bp(bp))
+ return info->ctrl.len == ARM_BREAKPOINT_LEN_8 ? 0x7 : 0x3;
+ else
+ return info->ctrl.type == ARM_BREAKPOINT_EXECUTE ? 0x3 : 0x7;
+}
+
/*
* Validate the arch-specific HW Breakpoint register settings.
*/
@@ -496,11 +506,8 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
* AArch32 tasks expect some simple alignment fixups, so emulate
* that here.
*/
+ alignment_mask = get_hwbkpt_alignment_mask(bp);
if (is_compat_bp(bp)) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
offset = info->address & alignment_mask;
switch (offset) {
case 0:
@@ -521,10 +528,6 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
info->address &= ~alignment_mask;
info->ctrl.len <<= offset;
} else {
- if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE)
- alignment_mask = 0x3;
- else
- alignment_mask = 0x7;
if (info->address & alignment_mask)
return -EINVAL;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2017806.nj5EEu7nrO@wuerfel>
On 23/09/16 15:44, Arnd Bergmann wrote:
> On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
>> On 23/09/16 15:01, Stuart Yoder wrote:
>> Otherwise you can
>> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
>> need to trap and translate subsequent SMC calls for e.g. PSCI).
>>
>>> If there is such a requirement, it's something begging for standardization.
>>> Doesn't make sense for multiple divergent approaches for switching from
>>> aarch64/EL2 to aarch32/EL2.
>>
>> Perhaps - I did briefly look into how hard it would be to write a proper
>> SMC service handler to do this (since ATF does have a framework for such
>> things), but concluded it would be more than 10 minutes' work and just
>> cheated instead. It's certainly something which could be raised with the
>> firmware folks.
>
> If we end up allowing all arm64 platforms to be enabled in arch/arm,
> we could perhaps create a generic implementation that does both of
> those things, i.e.
>
> - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
> that implements the arm64 boot protocol.
> - When that starts up, try to use the new PSCI call to jump into
> the arm32 kernel
> - If PSCI failed and we are running in EL2, implement the shim
> and start the arm32 kernel in EL1 mode
Really, though, the firmware call thing is an incredibly niche use-case.
Beyond development, the only real benefit of starting an AArch32 kernel
in Hyp is that you can run AArch32 KVM guests, which you can do equally
well (if not better) under an AArch64 kernel.
The standalone EL2 shim probably has legs, though, if the one currently
found in arch/arm64 is too heavyweight ;) My first version was
essentially that, albeit implemented by a load of .inst directives in
head.S.
Robin.
>
> Arnd
>
^ permalink raw reply
* [PATCH 19/19] reset: sti: softreset: Remove obsolete platforms from dt binding doc.
From: Rob Herring @ 2016-09-23 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-20-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:57PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti dt softreset bindings and
> removes references to these obsolete platforms.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <p.zabel@pengutronix.de>
> ---
> Documentation/devicetree/bindings/reset/st,sti-softreset.txt | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 18/19] stmmac: dwmac-sti: Remove obsolete STi platforms
From: Rob Herring @ 2016-09-23 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-19-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:56PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> dwmac-sti driver and dt binding doc, as support for these
> platforms is being removed from the kernel. It also removes
> STiD127 related code, which has never actually been supported
> upstream.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <peppe.cavallaro@st.com>
> Cc: <alexandre.torgue@st.com>
> Cc: <netdev@vger.kernel.org>
> ---
> .../devicetree/bindings/net/sti-dwmac.txt | 3 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 37 ----------------------
> 2 files changed, 1 insertion(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 12/19] reset: sti: Remove obsolete platforms from dt binding doc.
From: Rob Herring @ 2016-09-23 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-13-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:50PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel.
> This patch updates the sti dt powerdown bindings and
> removes references to these obsolete platforms.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <p.zabel@pengutronix.de>
> Cc: <robh+dt@kernel.org>
> ---
> Documentation/devicetree/bindings/reset/st,sti-powerdown.txt | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> index 1cfd21d..9252713 100644
> --- a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> +++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> @@ -16,15 +16,14 @@ Please refer to reset.txt in this directory for common reset
> controller binding usage.
>
> Required properties:
> -- compatible: Should be "st,<chip>-powerdown"
> - ex: "st,stih415-powerdown", "st,stih416-powerdown"
> +- compatible: Should be "st,stih407-powerdown"
> - #reset-cells: 1, see below
>
> example:
>
> powerdown: powerdown-controller {
> + compatible = "st,stih407-powerdown";
> #reset-cells = <1>;
> - compatible = "st,stih415-powerdown";
> };
>
>
> @@ -37,11 +36,10 @@ index specifying which channel to use, as described in reset.txt
>
> example:
>
> - usb1: usb at fe200000 {
> - resets = <&powerdown STIH41X_USB1_POWERDOWN>;
> + st_dwc3: dwc3 at 8f94000 {
usb@ was correct here. With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 10/19] watchdog: bindings: Remove obsolete platforms from dt doc.
From: Rob Herring @ 2016-09-23 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-11-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:48PM +0100, Peter Griffin wrote:
> STiH415/6 SoC support is being removed from the kernel
> so update the dt bding document to reflect this.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <wim@iguana.be>
> Cc: <linux@roeck-us.net>
> Cc: <robh+dt@kernel.org>
> Cc: <linux-watchdog@vger.kernel.org>
> ---
> Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 08/19] thermal: sti: Remove obsolete platforms from the DT doc.
From: Rob Herring @ 2016-09-23 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-9-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:46PM +0100, Peter Griffin wrote:
> STiH415/6 SoC's are being removed from the kernel. This
> patch removes the compatibles from the dt doc and also
> updates the example to a supported platform.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <rui.zhang@intel.com>
> Cc: <edubezval@gmail.com>
> Cc: <robh+dt@kernel.org>
> ---
> .../devicetree/bindings/thermal/st-thermal.txt | 28 +++++++---------------
> 1 file changed, 9 insertions(+), 19 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 07/19] ahci: st: Remove STiH416 dt example
From: Rob Herring @ 2016-09-23 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-8-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:45PM +0100, Peter Griffin wrote:
> This platform is being removed from the kernel so remove
> the dt example.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <tj@kernel.org>
> Cc: <robh+dt@kernel.org>
> Cc: <linux-ide@vger.kernel.org>
> ---
> Documentation/devicetree/bindings/ata/ahci-st.txt | 15 ---------------
> 1 file changed, 15 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 02/19] phy: stih41x-usb: Remove usb phy driver and dt binding documentation.
From: Rob Herring @ 2016-09-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-3-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:40PM +0100, Peter Griffin wrote:
> This phy is only used on STiH415/6 based silicon, and support for
> these SoC's is being removed from the kernel.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <kishon@ti.com>
> ---
> .../devicetree/bindings/phy/phy-stih41x-usb.txt | 24 ---
Acked-by: Rob Herring <robh@kernel.org>
> drivers/phy/Kconfig | 8 -
> drivers/phy/Makefile | 1 -
> drivers/phy/phy-stih41x-usb.c | 188 ---------------------
> 4 files changed, 221 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/phy-stih41x-usb.txt
> delete mode 100644 drivers/phy/phy-stih41x-usb.c
^ permalink raw reply
* [PATCH 01/19] phy: phy-miphy365x: Remove miphy365 driver and dt binding documentation.
From: Rob Herring @ 2016-09-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-2-git-send-email-peter.griffin@linaro.org>
On Wed, Sep 14, 2016 at 02:27:39PM +0100, Peter Griffin wrote:
> This phy is only used on STiH415/6 based silicon, and support for
> these SoC's is being removed from the kernel.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Cc: <kishon@ti.com>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 77 ---
Acked-by: Rob Herring <robh@kernel.org>
> drivers/phy/Kconfig | 10 -
> drivers/phy/Makefile | 1 -
> drivers/phy/phy-miphy365x.c | 625 ---------------------
> 4 files changed, 713 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> delete mode 100644 drivers/phy/phy-miphy365x.c
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Greg Kroah-Hartman @ 2016-09-23 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <331f5819-1f65-980d-486d-732342877f2c@atmel.com>
On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
> Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
> > Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
> >> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
> >> atmel_usba_udc fails with:
> >>
> >> ------------[ cut here ]------------
> >> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
> >> ecm_do_notify+0x188/0x1a0
> >> Modules linked in:
> >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
> >> Hardware name: Atmel SAMA5
> >> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
> >> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
> >> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
> >> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
> >> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
> >> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
> >> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
> >> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
> >> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
> >> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
> >> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
> >> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
> >> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
> >> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
> >> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
> >> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
> >> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
> >> ---[ end trace e7cf9dcebf4815a6 ]---
> >>
> >> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
> >> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> >> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >
> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >
> > Felipe, Greg,
> > It is clearly a regression and material for 4.8-fixes. But I do know
> > that we are very late in the process :-(
> > Please do what you can to make it progress before 4.8-final but I'm
> > truly aware of the challenge.
>
> Any chance that we can have it (aka ping)?
It's Felipe's area, not mine :)
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Sudeep Holla @ 2016-09-23 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923150004.GV8917@e106497-lin.cambridge.arm.com>
On 23/09/16 16:00, Liviu Dudau wrote:
> On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
>> Current vexpress smp init code detects whether to override the
>> default smp ops with MCPM smp ops by matching the "cci-400"
>> compatible string, in that MCPM requires control over CCI ports
>> to manage low-power states entry/exit.
>>
>> The "cci-400" compatible string check is a necessary but not
>> sufficient condition for MCPM to work, because the cci-400
>> can be made visible to the kernel, but firmware can nonetheless
>> disable non-secure CCI ports control, while still allowing PMU
>> access; if booted in non-secure world, the kernel would still
>> blindly override smp operations with MCPM operations, resulting
>> in kernel faults when the CCI ports programming interface is
>> accessed from non-secure world.
>>
>> This means that the "cci-400" compatible string check would
>> result in a false positive in systems that eg boot in HYP mode,
>> where CCI ports non-secure access is explicitly not allowed,
>> and it is reported in the respective device tree nodes with
>> CCI ports marked as disabled.
>
> I remember seeing a patch from Marc this week exactly on this
> subject, but I can't find it again today. However, I remember that
> his patch was explicitly testing for the HYP presence.
>
>>
>> Refactor the smp operations initialization to make sure that
>> the kernel is actually allowed to take control over CCI ports
>> (by enabling MCPM smp operations) before overriding default
>> vexpress smp operations.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
>> index 8b8d072..6cfd782 100644
>> --- a/arch/arm/mach-vexpress/platsmp.c
>> +++ b/arch/arm/mach-vexpress/platsmp.c
>> @@ -26,17 +26,34 @@
>> bool __init vexpress_smp_init_ops(void)
>> {
>> #ifdef CONFIG_MCPM
>> + int cpu;
>> + struct device_node *cpu_node, *cci_node;
>> +
>> /*
>> - * The best way to detect a multi-cluster configuration at the moment
>> - * is to look for the presence of a CCI in the system.
>> + * The best way to detect a multi-cluster configuration
>> + * is to detect if the kernel can take over CCI ports
>> + * control. Loop over possible CPUs and check if CCI
>> + * port control is available.
>> * Override the default vexpress_smp_ops if so.
>> */
>> - struct device_node *node;
>> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> - if (node && of_device_is_available(node)) {
>> - mcpm_smp_set_ops();
>> - return true;
>> + for_each_possible_cpu(cpu) {
>> + bool available;
>> +
>> + cpu_node = of_get_cpu_node(cpu, NULL);
>> + if (WARN(!cpu_node, "Missing cpu device node!"))
>> + return false;
>> +
>> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
>> + available = cci_node && of_device_is_available(cci_node);
>
> of_device_is_available() only checks the DT node for status = "enabled";
>
> Does the HYP modify the DT to disable the cci-control-port? If not, then I guess
> this patch is not enough?
>
Correct, I will send out the u-boot patch to disable the cci ports soon.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 0/2] i2c: meson: add gxbb compatible string
From: Rob Herring @ 2016-09-23 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915194146.GB7863@katana>
On Thu, Sep 15, 2016 at 2:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Wed, Sep 14, 2016 at 11:49:15AM +0200, Jerome Brunet wrote:
>> This patchset adds a specific compatible string in the Meson I2C driver
>> for the Amlogic Meson gxbb SoC.
>>
>> Other patch series (pinctrl and device tree) are being sent to complete
>> the i2c support on meson gxbb
>>
>> Neil Armstrong (2):
>> i2c: meson: add gxbb compatible string
>> dt-bindings: i2c-meson: add gxbb compatible string
>
> Squashed both patches and applied to for-next, thanks!
Please don't squash. We ask people to split DT bindings for a reason
being reviews and bindings may not go thru subsystem maintainers in
the future. It also makes it harder to find things in the archives or
patchwork (as does maintainer fixups of subject lines).
Rob
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Liviu Dudau @ 2016-09-23 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> Current vexpress smp init code detects whether to override the
> default smp ops with MCPM smp ops by matching the "cci-400"
> compatible string, in that MCPM requires control over CCI ports
> to manage low-power states entry/exit.
>
> The "cci-400" compatible string check is a necessary but not
> sufficient condition for MCPM to work, because the cci-400
> can be made visible to the kernel, but firmware can nonetheless
> disable non-secure CCI ports control, while still allowing PMU
> access; if booted in non-secure world, the kernel would still
> blindly override smp operations with MCPM operations, resulting
> in kernel faults when the CCI ports programming interface is
> accessed from non-secure world.
>
> This means that the "cci-400" compatible string check would
> result in a false positive in systems that eg boot in HYP mode,
> where CCI ports non-secure access is explicitly not allowed,
> and it is reported in the respective device tree nodes with
> CCI ports marked as disabled.
I remember seeing a patch from Marc this week exactly on this
subject, but I can't find it again today. However, I remember that
his patch was explicitly testing for the HYP presence.
>
> Refactor the smp operations initialization to make sure that
> the kernel is actually allowed to take control over CCI ports
> (by enabling MCPM smp operations) before overriding default
> vexpress smp operations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index 8b8d072..6cfd782 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -26,17 +26,34 @@
> bool __init vexpress_smp_init_ops(void)
> {
> #ifdef CONFIG_MCPM
> + int cpu;
> + struct device_node *cpu_node, *cci_node;
> +
> /*
> - * The best way to detect a multi-cluster configuration at the moment
> - * is to look for the presence of a CCI in the system.
> + * The best way to detect a multi-cluster configuration
> + * is to detect if the kernel can take over CCI ports
> + * control. Loop over possible CPUs and check if CCI
> + * port control is available.
> * Override the default vexpress_smp_ops if so.
> */
> - struct device_node *node;
> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> - if (node && of_device_is_available(node)) {
> - mcpm_smp_set_ops();
> - return true;
> + for_each_possible_cpu(cpu) {
> + bool available;
> +
> + cpu_node = of_get_cpu_node(cpu, NULL);
> + if (WARN(!cpu_node, "Missing cpu device node!"))
> + return false;
> +
> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> + available = cci_node && of_device_is_available(cci_node);
of_device_is_available() only checks the DT node for status = "enabled";
Does the HYP modify the DT to disable the cci-control-port? If not, then I guess
this patch is not enough?
Best regards,
Liviu
> + of_node_put(cci_node);
> + of_node_put(cpu_node);
> +
> + if (!available)
> + return false;
> }
> +
> + mcpm_smp_set_ops();
> + return true;
> #endif
> return false;
> }
> --
> 2.10.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-09-23 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10705430.q2aqv5uYO3@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 23 September 2016 14:43
> To: Gabriele Paoloni
> Cc: zhichang.yuan; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; lorenzo.pieralisi at arm.com; minyard at acm.org;
> linux-pci at vger.kernel.org; gregkh at linuxfoundation.org; John Garry;
> will.deacon at arm.com; linux-kernel at vger.kernel.org; Yuanzhichang;
> Linuxarm; xuwei (O); linux-serial at vger.kernel.org;
> benh at kernel.crashing.org; zourongrong at gmail.com; liviu.dudau at arm.com;
> kantyzc at 163.com
> Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, September 23, 2016 10:23:30 AM CEST Gabriele Paoloni wrote:
> > Hi Arnd
> >
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: 23 September 2016 10:52
> > > To: zhichang.yuan
> > > Cc: Gabriele Paoloni; linux-arm-kernel at lists.infradead.org;
> > > devicetree at vger.kernel.org; lorenzo.pieralisi at arm.com;
> minyard at acm.org;
> > > linux-pci at vger.kernel.org; gregkh at linuxfoundation.org; John Garry;
> > > will.deacon at arm.com; linux-kernel at vger.kernel.org; Yuanzhichang;
> > > Linuxarm; xuwei (O); linux-serial at vger.kernel.org;
> > > benh at kernel.crashing.org; zourongrong at gmail.com;
> liviu.dudau at arm.com;
> > > kantyzc at 163.com
> > > Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> > > Hip06
> > >
> > > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote:
> > > > For this patch sketch, I have a question.
> > > > Do we call pci_address_to_pio in arch_of_address_to_pio to get
> the
> > > > corresponding logical IO port
> > > > for LPC??
> > >
> > >
> > > No, of course not, that would be silly:
> > >
> > > The argument to pci_address_to_pio() is a phys_addr_t, and we we
> don't
> > > have one because there is no address associated with your PIO, that
> > > is the entire point of your driver!
> > >
> > > Also, we already know the mapping because this is what the inb/outb
> > > workaround is looking at, so there is absolutely no reason to call
> it
> > > either.
> >
> > Ok assume that we do not call pci_address_to_pio() for the ISA bus...
> > The LPC driver will register its phys address range in io_range_list,
> > then the IPMI driver probe will retrieve its physical address calling
> > of_address_to_resource and will use the indirect io to access this
> > address.
> >
> > From the perspective of the indirect IO function the input parameter
> > is an unsigned long addr that (now) can be either:
> > 1) an IO token coming from a legacy pci device
> > 2) a phys address that lives on the LPC bus
> >
> > These are conceptually two separate address spaces (and actually they
> > both start from 0).
>
> Why? Any IORESOURCE_IO address always refers to the logical I/O port
> range in Linux, not the physical address that is used on a bus.
If I read the code correctly when you get an I/O token you just add it
to PCI_IOBASE.
This is enough since pci_remap_iospace set the virtual address to
PCI_IOBASE + the I/O token offset; so we can read/write to
vaddr = PCI_IOBASE + token as pci_remap_iospace has mapped it correctly
to the respective PCI cpu address (that is set in the I/O range property
of the host controller)
In the patchset accessors LPC operates directly on the cpu addresses
and the input parameter of the accessors can be either an IO token or
a cpu address
+static inline void outb(u8 value, unsigned long addr)
+{
+#ifdef CONFIG_ARM64_INDIRECT_PIO
+ if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
+ addr <= arm64_extio_ops->end)
Here below we operate on cpu address
+ extio_outb(value, addr);
+ else
+#endif
In the case below we have an I/O token added to PCI_IOBASE
to calculate the virtual address
+ writeb(value, PCI_IOBASE + addr);
+}
My point is that if do not call pci_address_to_pio() in
__of_address_to_resource for the ISA LPC exception then the accessors
are called either by passing an IO token or a cpu address...and from
the accessors perspective we do not know...
Thanks
Gab
>
> > If the input parameter can live on different address spaces that are
> > overlapped, even if I save the used LPC range in arm64_extio_ops-
> >start/end
> > there is no way for the indirect IO to tell if the input parameter is
> > an I/O token or a phys address that belongs to LPC...
>
> The start address is the offset: if you get an address between 'start'
> and 'end', you subtract the 'start' from it, and use that to call
> the registered driver function. That works because we can safely
> assume that the bus address range that the LPC driver registers starts
> zero.
>
> Arnd
^ permalink raw reply
* [PATCH] arm64: fix dump_backtrace with NULL tsk
From: Mark Rutland @ 2016-09-23 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In some places, dump_backtrace() is called with a NULL tsk parameter,
e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
core code. The expectation is that this is treated as if current were
passed instead of NULL.
Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't
take this into account, and compares tsk against current *before* we
check if tsk is NULL.
Due to this, we won't initialise irq_stack_ptr, and when we try to dump
the exception regs we may call dump_mem() for memory immediately above
the IRQ stack range, rather than for the relevant range on the task
stack.
This will result in misleading, though should not be otherwise
problematic. The initial percpu areas (including the IRQ stacks) are
allocated in the linear map, and dump_mem uses __get_user(), so we
shouldn't access anything with side-effects, and will handle holes
safely.
This patch fixes the issue by handling the NULL tsk case before we do
anything else with tsk.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust")
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yang Shi <yang.shi@linaro.org>
---
arch/arm64/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index e04f838..df06750 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -142,6 +142,11 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
unsigned long irq_stack_ptr;
int skip;
+ pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+
+ if (!tsk)
+ tsk = current;
+
/*
* Switching between stacks is valid when tracing current and in
* non-preemptible context.
@@ -151,11 +156,6 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
else
irq_stack_ptr = 0;
- pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
-
- if (!tsk)
- tsk = current;
-
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_stack_pointer;
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 08/11] pci: controller: dra7xx: Add EP mode support
From: Rob Herring @ 2016-09-23 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473829927-20466-9-git-send-email-kishon@ti.com>
On Wed, Sep 14, 2016 at 10:42:04AM +0530, Kishon Vijay Abraham I wrote:
> The PCIe controller integrated in dra7xx SoCs is capable of operating
> in endpoint mode. Add support for dra7xx SoCs to operate in endpoint
> mode.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 30 ++-
> drivers/pci/controller/Kconfig | 21 +++
> drivers/pci/controller/pci-dra7xx.c | 211 +++++++++++++++++++---
> 3 files changed, 225 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 60e2516..b0e76f6 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -1,17 +1,22 @@
> TI PCI Controllers
>
> PCIe Designware Controller
> - - compatible: Should be "ti,dra7-pcie""
> - - reg : Two register ranges as listed in the reg-names property
> - - reg-names : The first entry must be "ti-conf" for the TI specific registers
> - The second entry must be "rc-dbics" for the designware pcie
> - registers
> - The third entry must be "config" for the PCIe configuration space
> + - compatible: Should be "ti,dra7-pcie" for RC
> + Should be "ti,dra7-pcie-ep" for EP
> - phys : list of PHY specifiers (used by generic PHY framework)
> - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
> number of PHYs as specified in *phys* property.
> - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
> where <X> is the instance number of the pcie from the HW spec.
> + - num-lanes as specified in ../designware-pcie.txt
> +
> +HOST MODE
> +=========
> + - reg : Two register ranges as listed in the reg-names property
> + - reg-names : The first entry must be "ti-conf" for the TI specific registers
> + The second entry must be "rc-dbics" for the designware pcie
> + registers
> + The third entry must be "config" for the PCIe configuration space
> - interrupts : Two interrupt entries must be specified. The first one is for
> main interrupt line and the second for MSI interrupt line.
> - #address-cells,
> @@ -19,13 +24,24 @@ PCIe Designware Controller
> #interrupt-cells,
> device_type,
> ranges,
> - num-lanes,
> interrupt-map-mask,
> interrupt-map : as specified in ../designware-pcie.txt
>
> Optional Property:
> - gpios : Should be added if a gpio line is required to drive PERST# line
Don't you need gpios as the input side of GPIO outputs in RC mode? Or
for EP mode they are all handled by h/w?
>
> +DEVICE MODE
> +===========
> + - reg : Two register ranges as listed in the reg-names property
> + - reg-names : "ti-conf" for the TI specific registers
> + "ep_dbics" for the standard configuration registers as
> + they are locally accessed within the DIF CS space
> + "ep_dbics2" for the standard configuration registers as
> + they are locally accessed within the DIF CS2 space
> + - interrupts : one interrupt entries must be specified for main interrupt.
> + - num-ib-windows : number of inbound address translation windows
> + - num-ob-windows : number of outbound address translation windows
> +
> Example:
> axi {
> compatible = "simple-bus";
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 8574828..4d70981 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -23,6 +23,27 @@ config PCI_DRA7XX_HOST
> Enables support for the PCIe controller in the DRA7xx SoC to work in
> host mode.
>
> +config PCI_DRA7XX_EP
> + bool "Endpoint Only Mode"
> + depends on PCI_ENDPOINT
> + select PCIE_DW_EP
> + help
> + Enables support for the PCIe controller in the DRA7xx SoC to work in
> + endpoint mode.
> +
> +config PCI_DRA7XX_HOST_EP
I'd make these 2 options just RC and EP depending on PCI_DRA7XX_HOST
with RC option being default yes.
> + bool "Both Host and Endpoint Mode"
> + depends on PCI_MSI_IRQ_DOMAIN
> + depends on PCI
> + depends on PCI_ENDPOINT
> + select PCIE_DW_HOST
> + select PCIE_DW_EP
> + help
> + Enables support for the PCIe controller in the DRA7xx SoC to work in
> + both endpoint mode and host mode. If the board has 2 PCIe ports and
> + one of them has to work in host mode and the other has to work in
> + EP mode then this option has to be enabled.
> +
> endchoice
>
> endif
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15d69a29-6997-6af8-f121-ff253388626c@arm.com>
On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> On 23/09/16 15:01, Stuart Yoder wrote:
> Otherwise you can
> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> need to trap and translate subsequent SMC calls for e.g. PSCI).
>
> > If there is such a requirement, it's something begging for standardization.
> > Doesn't make sense for multiple divergent approaches for switching from
> > aarch64/EL2 to aarch32/EL2.
>
> Perhaps - I did briefly look into how hard it would be to write a proper
> SMC service handler to do this (since ATF does have a framework for such
> things), but concluded it would be more than 10 minutes' work and just
> cheated instead. It's certainly something which could be raised with the
> firmware folks.
If we end up allowing all arm64 platforms to be enabled in arch/arm,
we could perhaps create a generic implementation that does both of
those things, i.e.
- Take the arm32 kernel Image or zImage file, wrap it inside of a binary
that implements the arm64 boot protocol.
- When that starts up, try to use the new PSCI call to jump into
the arm32 kernel
- If PSCI failed and we are running in EL2, implement the shim
and start the arm32 kernel in EL1 mode
Arnd
^ permalink raw reply
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