summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorSean Wang <sean.wang@mediatek.com>2018-01-05 16:14:06 +0800
committerStephen Boyd <sboyd@codeaurora.org>2018-01-10 13:41:15 -0800
commitbc27360b3c7aedfc385f7fc0527a42918bdeba51 (patch)
treef28f2a392dd7f9ff425b3e9de009baa92fbd3421 /tools/perf/scripts/python
parent5589818b2fab09c4b7250865a6163c3e2f81a9d6 (diff)
downloadkernel-bc27360b3c7aedfc385f7fc0527a42918bdeba51.tar.gz
clk: mediatek: adjust dependency of reset.c to avoid unexpectedly being built
Changes from v1->v2: Add 'select RESET_CONTROLLER' under COMMON_CLK_MEDIATEK and enable reset.c to be built when COMMON_CLK_MEDIATEK is selected. That should be quite reasonable because the reset controller is tightly embedded inside and exported from these clock subsystems. At least it can be found on infracfg and pericfg subsystem that both are really fundamental block lots of devices must depend on. commit 74cb0d6dde8 ("clk: mediatek: fixup test-building of MediaTek clock drivers") can let the build system looking into the directory where the clock drivers resides and then allow test-building the drivers. But the change also gives rise to certain incorrect behavior which is reset.c being built even not depending on either COMPILE_TEST or ARCH_MEDIATEK alternative dependency. To get rid of reset.c being built unexpectedly on the other platforms, it would be a good change that the file should be built depending on its own specific configuration rather than just on generic RESET_CONTROLLER one. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
om __do_user_fault signal/arm: Remove tsk parameter from ptrace_break signal/nds32: Remove tsk parameter from send_sigtrap signal/riscv: Remove tsk parameter from do_trap signal/sh: Remove tsk parameter from force_sig_info_fault signal/um: Remove task parameter from send_sigtrap signal/x86: Remove task parameter from send_sigtrap signal: Remove task parameter from force_sig_mceerr signal: Remove task parameter from force_sig signal: Remove task parameter from force_sigsegv ... 2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 286Thomas Gleixner Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation version 2 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 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 97 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.025053186@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-05-29signal/riscv: Remove tsk parameter from do_trapEric W. Biederman The do_trap function is always called with tsk == current. Make that obvious by removing the tsk parameter. This also makes it clear that do_trap calls force_sig_fault on the current task. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> 2019-05-16riscv: Add the support for c.ebreak check in is_valid_bugaddr()Vincent Chen The macro __BUG_INSN currently is defined as the "ebreak" opcode. The is_valid_bugaddr() function compares the instruction pointed to by $sepc with macro __BUG_INSN to check whether the current trap exception is caused by an "ebreak" instruction. However, this check flow is possibly erroneous because if C extension is supported, the expected trap instruction "ebreak" is possibly translated to "c.ebreak" by the assembler. Therefore, it requires a mechanism to distinguish the length of the instruction in $spec and compare it to the correct trap instruction. Signed-off-by: Vincent Chen <vincentc@andestech.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> 2019-05-16riscv: support trap-based WARN()Vincent Chen The WARN() related function will trigger a debug exception. This can help developers to analyze the cause of WARN() because if the debugger is connected, the control flow will be transferred to debugging environment. Signed-off-by: Vincent Chen <vincentc@andestech.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>