[PATCH 1/1] drivers: dma-contiguous: Ensure cma reserve region never cross the low/high mem boundary
If the cma reserve region goes through the device-tree method,
also need ensure the cma reserved region not cross the low/high
mem boundary. This patch did the similar fix as commit:16195dd
("mm: cma: Ensure that reservations never cross the low/high mem boundary")
Signed-off-by: Jason Liu
Cc: Marek Szyprowski
Cc: Joonsoo Kim
Cc: Greg Kroah-Hartman
---
drivers/base/dma-contiguous.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1..2bc093c 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -244,6 +244,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
phys_addr_t mask = align - 1;
+ phys_addr_t highmem_start;
unsigned long node = rmem->fdt_node;
struct cma *cma;
int err;
@@ -256,6 +257,32 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
pr_err("Reserved memory: incorrect alignment of CMA region\n");
return -EINVAL;
}
+#ifdef CONFIG_X86
+ /*
+* high_memory isn't direct mapped memory so retrieving its physical
+* address isn't appropriate. But it would be useful to check the
+* physical address of the highmem boundary so it's justfiable to get
+* the physical address from it. On x86 there is a validation check for
+* this case, so the following workaround is needed to avoid it.
+*/
+ highmem_start = __pa_nodebug(high_memory);
+#else
+ highmem_start = __pa(high_memory);
+#endif
+
+ /*
+* All pages in the reserved area must come from the same zone.
+* If the reserved region crosses the low/high memory boundary,
+* try to fix it up and then fall back to allocate from the low mem
+*/
+ if (rmem->base < highmem_start &&
+ (rmem->base + rmem->size) > highmem_start) {
+ memblock_free(rmem->base, rmem->size);
+ rmem->base = memblock_alloc_range(rmem->size, align, 0,
+ highmem_start, MEMBLOCK_NONE);
+ if (!rmem->base)
+ return -ENOMEM;
+ }
err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
if (err) {
--
1.9.1
Re: [PATCH resend v4] i2c: hibvt: add Hisilicon BVT I2C controller driver
Hi Wolfram,
On 2016/10/21 16:17, Pan Wen wrote:
> add Hisilicon BVT I2C controller driver support.
>
> Signed-off-by: Pan Wen
> Acked-by: Rob Herring
> ---
> change log
> v4:
> Modify the default frequency to 100KHz.
> v3:
> Add a SoC specific compatible string.
> v2:
> 1)Fixed a compile error.
> 2)Dropped the clock-names property.
> .../devicetree/bindings/i2c/i2c-hibvt.txt | 24 +
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile| 1 +
> drivers/i2c/busses/i2c-hibvt.c | 737
> +
> 4 files changed, 772 insertions(+)
Could you give us some comments on this patch?
If there are some issues about it, please let us know.
Thank you very much!
Best Regards,
Jiancheng
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
> create mode 100644 drivers/i2c/busses/i2c-hibvt.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
> b/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
> new file mode 100644
> index 000..db3d2e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-hibvt.txt
> @@ -0,0 +1,24 @@
> +Hisilicon BVT I2C master controller
> +
> +Required properties:
> +- compatible: should be "hisilicon,hibvt-i2c" and one of the following:
> + "hisilicon,hi3516cv300-i2c"
> +- reg: physical base address of the controller and length of memory mapped.
> + region.
> +- interrupts: interrupt number to the cpu.
> +- clocks: phandles to input clocks.
> +
> +Optional properties:
> +- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to
> 10.
> +
> +Other properties:
> +see Documentation/devicetree/bindings/i2c/i2c.txt.
> +
> +Examples:
> +i2c_bus0: i2c@1211 {
> + compatible = "hisilicon,hi3516cv300-i2c", "hisilicon,hibvt-i2c";
> + reg = <0x1211 0x100>;
> + interrupts = <20>;
> + clocks = <&crg_ctrl HI3516CV300_APB_CLK>;
> + clock-frequency = <10>;
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 5c3993b..fc1b679 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -555,6 +555,16 @@ config I2C_GPIO
> This is a very simple bitbanging I2C driver utilizing the
> arch-neutral GPIO API to control the SCL and SDA lines.
>
> +config I2C_HIBVT
> + tristate "Hisilicon BVT I2C Controller"
> + depends on ARCH_HISI
> + help
> + Say Y here to include support for Hisilicon BVT I2C controller in the
> + Hisilicon BVT SoCs.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-hibvt.
> +
> config I2C_HIGHLANDER
> tristate "Highlander FPGA SMBus interface"
> depends on SH_HIGHLANDER
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 37f2819..42ef2e0 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_I2C_EG20T) += i2c-eg20t.o
> obj-$(CONFIG_I2C_EMEV2) += i2c-emev2.o
> obj-$(CONFIG_I2C_EXYNOS5)+= i2c-exynos5.o
> obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
> +obj-$(CONFIG_I2C_HIBVT) += i2c-hibvt.o
> obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
> obj-$(CONFIG_I2C_HIX5HD2)+= i2c-hix5hd2.o
> obj-$(CONFIG_I2C_IBM_IIC)+= i2c-ibm_iic.o
> diff --git a/drivers/i2c/busses/i2c-hibvt.c b/drivers/i2c/busses/i2c-hibvt.c
> new file mode 100644
> index 000..e8af63e
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-hibvt.c
> @@ -0,0 +1,737 @@
> +/*
> + * Hisilicon BVT I2C Controller Driver
> + *
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * Authors: wen...@hisilicon.com
> + *
> + * 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; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
[PATCH v2] mtd: nand: nandsim: fix error check
debugfs_create_dir() and debugfs_create_file() returns NULL on error or
a pointer on success. They do not return the error value with ERR_PTR.
So we should not check the return with IS_ERR_OR_NULL, instead we
should just check for NULL.
Signed-off-by: Sudip Mukherjee
---
v2: nuked err
drivers/mtd/nand/nandsim.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c
index c76287a..c847426 100644
--- a/drivers/mtd/nand/nandsim.c
+++ b/drivers/mtd/nand/nandsim.c
@@ -525,24 +525,20 @@ static int nandsim_debugfs_create(struct nandsim *dev)
{
struct nandsim_debug_info *dbg = &dev->dbg;
struct dentry *dent;
- int err;
if (!IS_ENABLED(CONFIG_DEBUG_FS))
return 0;
dent = debugfs_create_dir("nandsim", NULL);
- if (IS_ERR_OR_NULL(dent)) {
- int err = dent ? -ENODEV : PTR_ERR(dent);
-
- NS_ERR("cannot create \"nandsim\" debugfs directory, err %d\n",
- err);
- return err;
+ if (!dent) {
+ NS_ERR("cannot create \"nandsim\" debugfs directory\n");
+ return -ENODEV;
}
dbg->dfs_root = dent;
dent = debugfs_create_file("wear_report", S_IRUSR,
dbg->dfs_root, dev, &dfs_fops);
- if (IS_ERR_OR_NULL(dent))
+ if (!dent)
goto out_remove;
dbg->dfs_wear_report = dent;
@@ -550,8 +546,7 @@ static int nandsim_debugfs_create(struct nandsim *dev)
out_remove:
debugfs_remove_recursive(dbg->dfs_root);
- err = dent ? PTR_ERR(dent) : -ENODEV;
- return err;
+ return -ENODEV;
}
/**
--
1.9.1
Re: [PATCH v2] perf/core: do not set cpuctx->cgrp for unscheduled cgroups
Hi all, Ping on this patch. Is there any outstanding problem with it? Hopefully can make it to 4.9 Thanks, David
Re: [PATCH] vt: fix Scroll Lock LED trigger name
Hello,
Greg Kroah-Hartman, on Wed 16 Nov 2016 08:24:42 +0100, wrote:
> > static struct kbd_led_trigger kbd_led_triggers[] = {
> > - KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
> > + KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"),
> > KBD_LED_TRIGGER(VC_NUMLOCK, "kbd-numlock"),
> > KBD_LED_TRIGGER(VC_CAPSLOCK, "kbd-capslock"),
> > KBD_LED_TRIGGER(VC_KANALOCK, "kbd-kanalock"),
>
> So, how far back should this change be backported to?
This was introduced in Linux 4.2.
Samuel
[PATCH -tip v3 0/9] ftrace: selftests: Add full glob matching and update ftracetest
Hi, Here is the 3rd version of the series of patches to add full glob matching support in ftrace, and update ftracetest to fix bugs and add test for the glob matching and hexadecimal types. Previous version is here: https://lkml.org/lkml/2016/10/30/16 I've fix some bugs related to ftrace kconfig selection on ftracetest, and add --quiet option in this version. Here is the short description, 3/9 - 5/9 are newly added. [1/9] Add full glob matching support on ftrace's function filter and event filter expression. [2/9] Initialize ftrace before running each testcase. (updated in v2 for checking supported features) [3/9] Add --quiet option to suppress error logs [4/9] Fix snapshot trigger test to be unsupported if the kernel has no snapshot feature. [5/9] Fix hist trigger-mod test to run correctly without syscall trace. [6/9] Hide logs direcotry from git. [7/9] Introduce temporary directory for test cases, which is used for storing temporary test data. [8/9] Add a testcase for function-name glob matching [9/9] Add a testcase for types of event arguments Thanks, --- Masami Hiramatsu (9): ftrace: Support full glob matching selftests: ftrace: Initialize ftrace before each test selftests: ftrace: Add --quiet option not to show error logs on screen selftests: ftrace: Check whether snapshot trigger is supported correctly selftests: ftrace: Fix trigger-mod to run without syscall trace selftests: ftrace: Hide ftracetest logs from git selftests: ftrace: Introduce TMPDIR for temporary files selftests: ftrace: Add a testcase for function filter glob match selftests: ftrace: Add a testcase for types of kprobe event Documentation/trace/events.txt |9 +--- Documentation/trace/ftrace.txt |9 +--- kernel/trace/Kconfig |2 + kernel/trace/ftrace.c |4 ++ kernel/trace/trace.c |2 - kernel/trace/trace.h |2 + kernel/trace/trace_events_filter.c | 17 +++ tools/testing/selftests/ftrace/.gitignore |1 tools/testing/selftests/ftrace/ftracetest | 12 - .../ftrace/test.d/ftrace/func-filter-glob.tc | 49 tools/testing/selftests/ftrace/test.d/functions| 28 +++ .../ftrace/test.d/kprobe/kprobe_args_type.tc | 37 +++ .../ftrace/test.d/trigger/trigger-hist-mod.tc |2 - .../ftrace/test.d/trigger/trigger-snapshot.tc |5 ++ 14 files changed, 162 insertions(+), 17 deletions(-) create mode 100644 tools/testing/selftests/ftrace/.gitignore create mode 100644 tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc -- Masami Hiramatsu (Linaro Ltd.)
[PATCH -tip v3 1/9] ftrace: Support full glob matching
Use glob_match() to support flexible glob wildcards (*,?)
and character classes ([) for ftrace.
Since the full glob matching is slower than the current
partial matching routines(*pat, pat*, *pat*), this leaves
those routines and just add MATCH_GLOB for complex glob
expression.
e.g.
[root@localhost tracing]# echo 'sched*group' > set_ftrace_filter
[root@localhost tracing]# cat set_ftrace_filter
sched_free_group
sched_change_group
sched_create_group
sched_online_group
sched_destroy_group
sched_offline_group
[root@localhost tracing]# echo '[Ss]y[Ss]_*' > set_ftrace_filter
[root@localhost tracing]# head set_ftrace_filter
sys_arch_prctl
sys_rt_sigreturn
sys_ioperm
SyS_iopl
sys_modify_ldt
SyS_mmap
SyS_set_thread_area
SyS_get_thread_area
SyS_set_tid_address
sys_fork
Signed-off-by: Masami Hiramatsu
---
Documentation/trace/events.txt |9 +++--
Documentation/trace/ftrace.txt |9 +++--
kernel/trace/Kconfig |2 ++
kernel/trace/ftrace.c |4
kernel/trace/trace.c |2 +-
kernel/trace/trace.h |2 ++
kernel/trace/trace_events_filter.c | 17 -
7 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 08d74d7..2cc08d4 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -189,16 +189,13 @@ And for string fields they are:
==, !=, ~
-The glob (~) only accepts a wild card character (*) at the start and or
-end of the string. For example:
+The glob (~) accepts a wild card character (*,?) and character classes
+([). For example:
prev_comm ~ "*sh"
prev_comm ~ "sh*"
prev_comm ~ "*sh*"
-
-But does not allow for it to be within the string:
-
- prev_comm ~ "ba*sh" <-- is invalid
+ prev_comm ~ "ba*sh"
5.2 Setting filters
---
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 185c39f..1bc66c1 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2218,16 +2218,13 @@ hrtimer_interrupt
sys_nanosleep
-Perhaps this is not enough. The filters also allow simple wild
-cards. Only the following are currently available
+Perhaps this is not enough. The filters also allow glob(7) matching.
* - will match functions that begin with
* - will match functions that end with
** - will match functions that have in it
-
-These are the only wild cards which are supported.
-
- * will not work.
+ * - will match functions that begin with
+ and end with
Note: It is better to use quotes to enclose the wild cards,
otherwise the shell may expand the parameters into names
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 2a96b06..d503800 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -70,6 +70,7 @@ config FTRACE_NMI_ENTER
config EVENT_TRACING
select CONTEXT_SWITCH_TRACER
+select GLOB
bool
config CONTEXT_SWITCH_TRACER
@@ -133,6 +134,7 @@ config FUNCTION_TRACER
select KALLSYMS
select GENERIC_TRACER
select CONTEXT_SWITCH_TRACER
+select GLOB
help
Enable the kernel to trace every kernel function. This is done
by using a compiler feature to insert a small, 5-byte No-Operation
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2050a765..7d97c45 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3499,6 +3499,10 @@ static int ftrace_match(char *str, struct ftrace_glob *g)
memcmp(str + slen - g->len, g->search, g->len) == 0)
matched = 1;
break;
+ case MATCH_GLOB:
+ if (glob_match(g->search, str))
+ matched = 1;
+ break;
}
return matched;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8696ce6..d904516d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4065,7 +4065,7 @@ static const char readme_msg[] =
"\n available_filter_functions - list of functions that can be
filtered on\n"
" set_ftrace_filter\t- echo function name in here to only trace
these\n"
"\t\t\t functions\n"
- "\t accepts: func_full_name, *func_end, func_begin*,
*func_middle*\n"
+ "\t accepts: func_full_name or glob-matching-pattern\n"
"\t modules: Can select a group via module\n"
"\t Format: :mod:\n"
"\t example: echo :mod:ext3 > set_ftrace_filter\n"
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index fd24b1f..4b79189 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FTRACE_SYSCALLS
#include /* For NR_SYSCALLS */
@@ -1257,6 +1258,7 @@ enum regex_type {
MATCH_FRONT_ONLY,
MATCH_MIDDLE_ONLY,
[PATCH -tip v3 2/9] selftests: ftrace: Initialize ftrace before each test
Reset ftrace to initial state before running each test.
This fixes some test cases to enable tracing before starting
trace test. This can avoid false-positive failure when
previous testcase fails while disabling tracing.
Signed-off-by: Masami Hiramatsu
Suggested-by: Steven Rostedt
---
Changes in v3:
- Fix to avoid initializing error by checking all optional features
---
tools/testing/selftests/ftrace/ftracetest |2 +-
tools/testing/selftests/ftrace/test.d/functions | 28 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index 4c6a0bf..a03d366 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -228,7 +228,7 @@ trap 'SIG_RESULT=$XFAIL' $SIG_XFAIL
__run_test() { # testfile
# setup PID and PPID, $$ is not updated.
- (cd $TRACING_DIR; read PID _ < /proc/self/stat ; set -e; set -x; . $1)
+ (cd $TRACING_DIR; read PID _ < /proc/self/stat; set -e; set -x;
initialize_ftrace; . $1)
[ $? -ne 0 ] && kill -s $SIG_FAIL $SIG_PID
}
diff --git a/tools/testing/selftests/ftrace/test.d/functions
b/tools/testing/selftests/ftrace/test.d/functions
index c37262f..91de1a8 100644
--- a/tools/testing/selftests/ftrace/test.d/functions
+++ b/tools/testing/selftests/ftrace/test.d/functions
@@ -23,3 +23,31 @@ reset_trigger() { # reset all current setting triggers
done
}
+reset_events_filter() { # reset all current setting filters
+grep -v ^none events/*/*/filter |
+while read line; do
+ echo 0 > `echo $line | cut -f1 -d:`
+done
+}
+
+disable_events() {
+echo 0 > events/enable
+}
+
+initialize_ftrace() { # Reset ftrace to initial-state
+# As the initial state, ftrace will be set to nop tracer,
+# no events, no triggers, no filters, no function filters,
+# no probes, and tracing on.
+disable_tracing
+reset_tracer
+reset_trigger
+reset_events_filter
+disable_events
+echo > set_event_pid # event tracer is always on
+[ -f set_ftrace_filter ] && echo | tee set_ftrace_*
+[ -f set_graph_function ] && echo | tee set_graph_*
+[ -f stack_trace_filter ] && echo > stack_trace_filter
+[ -f kprobe_events ] && echo > kprobe_events
+[ -f uprobe_events ] && echo > uprobe_events
+enable_tracing
+}
[PATCH -tip v3 3/9] selftests: ftrace: Add --quiet option not to show error logs on screen
Since the verbose error logs scrolls out previous test results
--quiet option suppress to show such message.
e.g.
# ./ftracetest -q
=== Ftrace unit tests ===
[1] Basic trace file check [PASS]
[2] Basic test for tracers [PASS]
[3] Basic trace clock test [PASS]
[4] Basic event tracing check [PASS]
[5] event tracing - enable/disable with event level files [PASS]
[6] event tracing - restricts events based on pid [PASS]
[7] event tracing - enable/disable with subsystem level files [PASS]
[8] event tracing - enable/disable with top level files [PASS]
[9] ftrace - function graph filters with stack tracer [UNSUPPORTED]
[10] ftrace - function graph filters[UNSUPPORTED]
[11] ftrace - function profiler with function tracing [UNSUPPORTED]
[12] Test creation and deletion of trace instances while setting an event
[PASS]
[13] Test creation and deletion of trace instances [PASS]
[14] Kprobe dynamic event - adding and removing [UNSUPPORTED]
[15] Kprobe dynamic event - busy event check[UNSUPPORTED]
[16] Kprobe dynamic event with arguments[UNSUPPORTED]
[17] Kprobe dynamic event with function tracer [UNSUPPORTED]
[18] Kretprobe dynamic event with arguments [UNSUPPORTED]
[19] event trigger - test event enable/disable trigger [PASS]
[20] event trigger - test trigger filter[PASS]
[21] event trigger - test histogram modifiers [UNSUPPORTED]
[22] event trigger - test histogram trigger [UNSUPPORTED]
[23] event trigger - test multiple histogram triggers [UNSUPPORTED]
[24] event trigger - test snapshot-trigger [FAIL]
[25] event trigger - test stacktrace-trigger[PASS]
[26] event trigger - test traceon/off trigger [PASS]
# of passed: 14
# of failed: 1
# of unresolved: 0
# of untested: 0
# of unsupported: 11
# of xfailed: 0
# of undefined(test bug): 0
Signed-off-by: Masami Hiramatsu
---
tools/testing/selftests/ftrace/ftracetest |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index a03d366..d08235f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -14,6 +14,7 @@ echo " Options:"
echo " -h|--help Show help message"
echo " -k|--keep Keep passed test logs"
echo " -v|--verbose Show all stdout messages in testcases"
+echo " -q|--quiet Do not show error log on stdout"
echo " -d|--debug Debug mode (trace all shell commands)"
exit $1
}
@@ -58,6 +59,10 @@ parse_opts() { # opts
VERBOSE=1
shift 1
;;
+--quiet|-q)
+ BE_QUIET=1
+ shift 1
+;;
--debug|-d)
DEBUG=1
shift 1
@@ -101,6 +106,7 @@ LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
KEEP_LOG=0
DEBUG=0
VERBOSE=0
+BE_QUIET=0
# Parse command-line options
parse_opts $*
@@ -249,7 +255,7 @@ run_test() { # testfile
# Remove test log if the test was done as it was expected.
[ $KEEP_LOG -eq 0 ] && rm $testlog
else
-catlog $testlog
+[ $BE_QUIET -eq 0 ] && catlog $testlog
TOTAL_RESULT=1
fi
}
[PATCH -tip v3 5/9] selftests: ftrace: Fix trigger-mod to run without syscall trace
Since histogram trigger id.syscall depends on CONFIG_FTRACE_SYSCALLS, a testcase in trigger-modifier test fails if that config is disabled. Fix this bug by using flexible pattern to check the histogram output. Signed-off-by: Masami Hiramatsu --- .../ftrace/test.d/trigger/trigger-hist-mod.tc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/ftrace/test.d/trigger/trigger-hist-mod.tc b/tools/testing/selftests/ftrace/test.d/trigger/trigger-hist-mod.tc index 0bf5085..400e98b 100644 --- a/tools/testing/selftests/ftrace/test.d/trigger/trigger-hist-mod.tc +++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-hist-mod.tc @@ -56,7 +56,7 @@ echo "Test histogram with syscall modifier" echo 'hist:keys=id.syscall' > events/raw_syscalls/sys_exit/trigger for i in `seq 1 10` ; do ( echo "forked" > /dev/null); done -grep "id: sys_" events/raw_syscalls/sys_exit/hist > /dev/null || \ +grep "id: \(unknown_\|sys_\)" events/raw_syscalls/sys_exit/hist > /dev/null || \ fail "syscall modifier on raw_syscalls/sys_exit did not work"
[PATCH -tip v3 8/9] selftests: ftrace: Add a testcase for function filter glob match
Add function filter glob matching test case.
This checks whether the kernel supports glob matching
(front match, end match, middle match, side match,
character class and '?').
Here is the test result.
-
./ftracetest test.d/ftrace/func-filter-glob.tc
=== Ftrace unit tests ===
[1] ftrace - function glob filters[PASS]
# of passed: 1
# of failed: 0
# of unresolved: 0
# of untested: 0
# of unsupported: 0
# of xfailed: 0
# of undefined(test bug): 0
-
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/ftrace/func-filter-glob.tc | 49
1 file changed, 49 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
new file mode 100644
index 000..9dcd0ca
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -0,0 +1,49 @@
+#!/bin/sh
+# description: ftrace - function glob filters
+
+# Make sure that function glob matching filter works.
+
+if ! grep -q function available_tracers; then
+echo "no function tracer configured"
+exit_unsupported
+fi
+
+disable_tracing
+clear_trace
+
+# filter by ?, schedule is always good
+if ! echo "sch?dule" > set_ftrace_filter; then
+# test for powerpc 64
+if ! echo ".sch?dule" > set_ftrace_filter; then
+ fail "can not enable schedule filter"
+fi
+cat set_ftrace_filter | grep '^.schedule$'
+else
+cat set_ftrace_filter | grep '^schedule$'
+fi
+
+ftrace_filter_check() { # glob grep
+ echo "$1" > set_ftrace_filter
+ cut -f1 -d" " set_ftrace_filter > $TMPDIR/actual
+ cut -f1 -d" " available_filter_functions | grep "$2" > $TMPDIR/expected
+ DIFF=`diff $TMPDIR/actual $TMPDIR/expected`
+ test -z "$DIFF"
+}
+
+# filter by *, front match
+ftrace_filter_check '*schedule' '^.*schedule$'
+
+# filter by *, middle match
+ftrace_filter_check '*schedule*' '^.*schedule.*$'
+
+# filter by *, end match
+ftrace_filter_check 'schedule*' '^schedule.*$'
+
+# filter by *, both side match
+ftrace_filter_check 'sch*ule' '^sch.*ule$'
+
+# filter by char class.
+ftrace_filter_check '[Ss]y[Ss]_*' '^[Ss]y[Ss]_.*$'
+
+echo > set_ftrace_filter
+enable_tracing
[PATCH -tip v3 4/9] selftests: ftrace: Check whether snapshot trigger is supported correctly
If "snapshot" special file doesn't exist, that kernel does not support snapshot and snapshot trigger too. In that case snapshot trigger test results to unsupported instead of fail. Signed-off-by: Masami Hiramatsu --- .../ftrace/test.d/trigger/trigger-snapshot.tc |5 + 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc index f84b80d..ed94f0c 100644 --- a/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc +++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc @@ -23,6 +23,11 @@ if [ ! -f events/sched/sched_process_fork/trigger ]; then exit_unsupported fi +if [ ! -f snapshot ]; then +echo "snapshot is not supported" +exit_unsupported +fi + reset_tracer do_reset
[PATCH -tip v3 6/9] selftests: ftrace: Hide ftracetest logs from git
Hide ftracetest result log directory from git. Signed-off-by: Masami Hiramatsu --- tools/testing/selftests/ftrace/.gitignore |1 + 1 file changed, 1 insertion(+) create mode 100644 tools/testing/selftests/ftrace/.gitignore diff --git a/tools/testing/selftests/ftrace/.gitignore b/tools/testing/selftests/ftrace/.gitignore new file mode 100644 index 000..98d8a5a --- /dev/null +++ b/tools/testing/selftests/ftrace/.gitignore @@ -0,0 +1 @@ +logs
Re: [PATCH] printk, locking/atomics, kref: Introduce new %pAr and %pAk format string options for atomic_t and 'struct kref'
* Linus Torvalds wrote:
> On Tue, Nov 15, 2016 at 12:37 AM, Ingo Molnar wrote:
> > +atomic variables such atomic_t or struct kref:
> > +
> > + %pAratomic_t count
> > + %pAkstruct kref count
>
> Not a huge fan. That "r" makes sense to you ("raw" atomic), but it
> makes no sense to a user. An atomic isn't "raw" to anybody else. It's
> just an atomic.
So in the latestest patch this has evolved to:
%pAa - print the 'atomic_t'count in decimal
%pAk - print the 'struct kref' count in decimal
%pAr - print the 'refcount_t' count in decimal
... are you still hating it?
> Also, we have 'atomic64_t", which this doesn't cover at all.
We could use a somewhat logical letter for atomic64_t too:
%pAA - print the 'atomic64_t' count in decimal
... as 'A' is the bigger version of 'a', just like atomic64_t is the bigger
version of atomic_t! ;-)
> I'd suggest just %pA, %pA64, %pAkref or something. Which leaves us the
> choice to add more atomic versions later without having to make up
> random one-letter things that make no sense.
It's a bit more work, but we could do that too, if you still don't like the
above
single letter abbreviations.
Thanks,
Ingo
[PATCH -tip v3 7/9] selftests: ftrace: Introduce TMPDIR for temporary files
Introduce TMPDIR variable which is removed after each test
is done, so that the test script can put their temporary
files in that.
Signed-off-by: Masami Hiramatsu
---
tools/testing/selftests/ftrace/ftracetest |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index d08235f..685376b4 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -242,6 +242,7 @@ __run_test() { # testfile
run_test() { # testfile
local testname=`basename $1`
local testlog=`mktemp $LOG_DIR/${testname}-log.XX`
+ export TMPDIR=`mktemp -d /tmp/ftracetest-dir.XX`
testcase $1
echo "execute: "$1 > $testlog
SIG_RESULT=0
@@ -258,6 +259,7 @@ run_test() { # testfile
[ $BE_QUIET -eq 0 ] && catlog $testlog
TOTAL_RESULT=1
fi
+ rm -rf $TMPDIR
}
# load in the helper functions
Re: [PATCH] vt: fix Scroll Lock LED trigger name
On Wed, Nov 16, 2016 at 09:10:04AM +0100, Samuel Thibault wrote:
> Hello,
>
> Greg Kroah-Hartman, on Wed 16 Nov 2016 08:24:42 +0100, wrote:
> > > static struct kbd_led_trigger kbd_led_triggers[] = {
> > > - KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
> > > + KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"),
> > > KBD_LED_TRIGGER(VC_NUMLOCK, "kbd-numlock"),
> > > KBD_LED_TRIGGER(VC_CAPSLOCK, "kbd-capslock"),
> > > KBD_LED_TRIGGER(VC_KANALOCK, "kbd-kanalock"),
> >
> > So, how far back should this change be backported to?
>
> This was introduced in Linux 4.2.
Great, thanks for letting me know.
greg k-h
[PATCH -tip v3 9/9] selftests: ftrace: Add a testcase for types of kprobe event
Add a testcase for types of kprobe event. This checks
kprobe event can accept and correctly expressed the
arguments typed as s32, u32, x32 and bitfield.
Here is the test result.
-
# ./ftracetest test.d/kprobe/kprobe_args_type.tc
=== Ftrace unit tests ===
[1] Kprobes event arguments with types[PASS]
# of passed: 1
# of failed: 0
# of unresolved: 0
# of untested: 0
# of unsupported: 0
# of xfailed: 0
# of undefined(test bug): 0
-
Signed-off-by: Masami Hiramatsu
---
.../ftrace/test.d/kprobe/kprobe_args_type.tc | 37
1 file changed, 37 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
new file mode 100644
index 000..0a78705
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
@@ -0,0 +1,37 @@
+#!/bin/sh
+# description: Kprobes event arguments with types
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+grep "x8/16/32/64" README > /dev/null || exit_unsupported # version issue
+
+echo 0 > events/enable
+echo > kprobe_events
+enable_tracing
+
+echo 'p:testprobe _do_fork $stack0:s32 $stack0:u32 $stack0:x32
$stack0:b8@4/32' > kprobe_events
+grep testprobe kprobe_events
+test -d events/kprobes/testprobe
+
+echo 1 > events/kprobes/testprobe/enable
+( echo "forked")
+echo 0 > events/kprobes/testprobe/enable
+ARGS=`tail -n 1 trace | sed -e 's/.* arg1=\(.*\) arg2=\(.*\) arg3=\(.*\)
arg4=\(.*\)/\1 \2 \3 \4/'`
+
+check_types() {
+ X1=`printf "%x" $1 | tail -c 8`
+ X2=`printf "%x" $2`
+ X3=`printf "%x" $3`
+ test $X1 = $X2
+ test $X2 = $X3
+ test 0x$X3 = $3
+
+ B4=`printf "%x" $4`
+ B3=`echo -n $X3 | tail -c 3 | head -c 2`
+ test $B3 = $B4
+}
+check_types $ARGS
+
+echo "-:testprobe" >> kprobe_events
+clear_trace
+test -d events/kprobes/testprobe && exit 1 || exit 0
Re: [linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
Hi,
On 11/15/2016 08:29 AM, Chen-Yu Tsai wrote:
Hi,
On Wed, Nov 2, 2016 at 9:33 AM, Chen-Yu Tsai wrote:
On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring wrote:
On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
Some dumb VGA DACs are active components which require external power.
Add support for specifying a regulator as its power supply.
Signed-off-by: Chen-Yu Tsai
---
.../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
For the binding,
Acked-by: Rob Herring
Any comments on this patch from the DRM people?
A comment below.
ChenYu
One code comment below...
drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..164cbb15f04c 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in
Documentation/devicetree/bindings/graph.txt.
- Video port 0 for RGB input
- Video port 1 for VGA output
+Optional properties:
+- vdd-supply: Power supply for DAC
Example
---
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..59781e031220 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connectorconnector;
struct i2c_adapter *ddc;
+ struct regulator*vdd;
};
static inline struct dumb_vga *
@@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
}
+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+ int ret;
+
+ if (!IS_ERR(vga->vdd)) {
if (IS_ERR())
return;
...will save some intentation.
I thought about that, though if someone were to add more stuff to
this, such as an enable GPIO, they might have to rework it. A standalone
block of code would be easier to work with. I'm OK either way though.
ChenYu
+ ret = regulator_enable(vga->vdd);
+
+ if (ret) {
+ DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
+ return;
+ }
+ }
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (!IS_ERR(vga->vdd))
+ regulator_disable(vga->vdd);
+}
+
static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+ .enable = dumb_vga_enable,
+ .disable= dumb_vga_disable,
};
static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+ vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
+ if (IS_ERR(vga->vdd)) {
+ ret = PTR_ERR(vga->vdd);
+ if (ret == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
A cleaner way would be to set vga->vdd to NULL here, and do:
int ret = 0;
if (vga->vdd)
ret = regulator_enable(vga->vdd);
if (ret) {
...
return;
}
/* if a gpio is added later */
if (vga->gpio)
ret = gpiod_set_value_cansleep(vga->gpio, 1);
if (ret) {
...
return;
}
...
We don't really care what error code is contained in vga->vdd once we have
identified whether we got a regulator or not.
The same thing can be done for ddc too, but that can done left for later.
If you're okay with the suggestion, can you re-spin a patch?
Thanks,
Archit
+ }
+
vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {
--
2.9.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Tue, Nov 15, 2016 at 12:53:35PM -0800, Kees Cook wrote:
> On Tue, Nov 15, 2016 at 12:03 AM, Peter Zijlstra wrote:
> > On Tue, Nov 15, 2016 at 08:33:22AM +0100, Greg KH wrote:
> >> On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote:
> >
> >> > --- a/drivers/block/drbd/drbd_req.c
> >> > +++ b/drivers/block/drbd/drbd_req.c
> >> > @@ -520,7 +520,7 @@ static void mod_rq_state(struct drbd_req
> >> > /* Completion does it's own kref_put. If we are going to
> >> > * kref_sub below, we need req to be still around then. */
> >> > int at_least = k_put + !!c_put;
> >> > - int refcount = atomic_read(&req->kref.refcount);
> >> > + int refcount = kref_read(&req->kref);
> >> > if (refcount < at_least)
> >> > drbd_err(device,
> >> > "mod_rq_state: Logic BUG: %x -> %x: refcount
> >> > = %d, should be >= %d\n",
> >>
> >> As proof of "things you should never do", here is one such example.
> >>
> >> ugh.
> >>
> >>
> >> > --- a/drivers/block/virtio_blk.c
> >> > +++ b/drivers/block/virtio_blk.c
> >> > @@ -767,7 +767,7 @@ static void virtblk_remove(struct virtio
> >> > /* Stop all the virtqueues. */
> >> > vdev->config->reset(vdev);
> >> >
> >> > - refc = atomic_read(&disk_to_dev(vblk->disk)->kobj.kref.refcount);
> >> > + refc = kref_read(&disk_to_dev(vblk->disk)->kobj.kref);
> >> > put_disk(vblk->disk);
> >> > vdev->config->del_vqs(vdev);
> >> > kfree(vblk->vqs);
> >>
> >> And this too, ugh, that's a huge abuse and is probably totally wrong...
> >>
> >> thanks again for digging through this crap. I wonder if we need to name
> >> the kref reference variable "do_not_touch_this_ever" or some such thing
> >> to catch all of the people who try to be "too smart".
> >
> > There's unimaginable bong hits involved in this stuff, in the end I
> > resorted to brute force and scripts to convert all this.
>
> What should we do about things like this (bpf_prog_put() and callbacks
> from kernel/bpf/syscall.c):
>
>
> static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> {
> struct user_struct *user = prog->aux->user;
>
> atomic_long_sub(prog->pages, &user->locked_vm);
Oh that's scary. Let's just make one reference count rely on another
one and not check things...
> free_uid(user);
> }
>
> static void __bpf_prog_put_rcu(struct rcu_head *rcu)
> {
> struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux,
> rcu);
>
> free_used_maps(aux);
> bpf_prog_uncharge_memlock(aux->prog);
> bpf_prog_free(aux->prog);
> }
>
> void bpf_prog_put(struct bpf_prog *prog)
> {
> if (atomic_dec_and_test(&prog->aux->refcnt))
> call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
> }
>
>
> Not only do we want to protect prog->aux->refcnt, but I think we want
> to protect user->locked_vm too ... I don't think it's sane for
> user->locked_vm to be a stats_t ?
I don't think this is sane code...
greg k-h
RE: [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
>From: Rob Herring [mailto:r...@kernel.org]
>On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
>> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
>> Describes the qoriq usb 2.0 phy driver binding, currently used for
>> LS1043A platform.
>>
>> Signed-off-by: Sriram Dash
>> ---
>> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36
>> drivers/phy/Kconfig| 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qoriq-usb3.c | 202
>> +
>> 4 files changed, 247 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> new file mode 100644
>> index 000..d934c80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> @@ -0,0 +1,36 @@
>> +Driver for Freescale USB 3.0 PHY
>> +
>> +Required properties:
>> +
>> +- compatible : fsl,qoriq-usb3-phy
>> +- reg : register mappings for Parameter Configuration Register
>> +and Phy base offset.
>> +- reg-names : "param_ctrl" and "phy_base"
>> +- phy_type :For multi port host USB controllers, should be one of
>> +"ulpi", or "serial". For dual role USB controllers,
>> +should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Hi Rob,
>
>Do any of these really apply to a USB3 PHY?
>
The concerned USB3 phy used is UTMI. I agree to your point somewhat that
all the types are not required now. Anyway, shall I make it an optional
property, with the mention of only UTMI and ULPI?
>Rob
>
>> +
>> +Example:
>> +usbphy0: usb3-phy@084F {
>
>usb-phy@...
>
Ok. Will change in the next rev for Documentation and dts (patch 2/2)
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
>> +
>> +usbphy1: usb3-phy@0850 {
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x0850 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
>> +
>> +usbphy2: usb3-phy@0851 {
>> +compatible = "fsl,qoriq-usb3-phy";
>> +reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x0851 0x0
>> 0x5000>;
>> +reg-names = "param_ctrl", "phy_base";
>> +#phy-cells = <0>;
>> +phy_type = "utmi";
>> +};
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
* Kees Cook wrote: > On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra wrote: > > > > > > On 15 November 2016 19:06:28 CET, Kees Cook wrote: > > > >>I'll want to modify this in the future; I have a config already doing > >>"Bug on data structure corruption" that makes the warn/bug choice. > >>It'll need some massaging to fit into the new refcount_t checks, but > >>it should be okay -- there needs to be a way to complete the > >>saturation, etc, but still kill the offending process group. > > > > Ideally we'd create a new WARN like construct that continues in kernel > > space > > and terminates the process on return to user. That way there would be > > minimal > > kernel state corruption. Yeah, so the problem is that sometimes you are p0wned the moment you return to a corrupted stack, and some of these checks only detect corruption after the fact. > Right, though I'd like to be conservative about the kernel execution > continuing... I'll experiment with it. So what I'd love to see is to have a kernel option that re-introduces some historic root (and other) holes that can be exploited deterministically - obviously default disabled. I'd restrict this to reasonably 'deterministic' holes, and the exploits themselves could be somewhere in tools/. (Obviously only where the maintainers agree to host the code.) They wouldn't give a root shell, they'd only test whether they reached uid0 (or some other elevated privilege). The advantages of such a suite would be: - Uptodate tests on modern kernels: It would allow the (controlled) testing of live kernel exploits even on the latest kernel - and would allow the testing of various defensive measures. - It would also make sure that defensive measures _remain_ effective against similar categories of bugs. We've had defensive measure regressions in the past, which was only discovered when the next exploit came out ... - Testing of new defensive measures: It would help convert this whole probabilistic and emotion driven "kernel protection" business into something somewhat more rational. For example new protection mechanisms should have a demonstrated ability to turn an existing exploit test into something less dangerous. - Education: It would teach kernel developers the various patterns of holes, right in the code. Maybe being more directly exposed to what can get you p0wned is both a stronger education force plus it could give people ideas about how to protect better. - I also think that collecting the various problems into a single place will give us new insights into patterns, bug counts and various exploit techniques. The disadvantages would be: - Maintenance: do we want to add extra (compiled out by default) code to the kernel whose only purpose is to demonstrate certain types of bugs? - Exposing exploits: Do we want to host a powerful collection of almost-exploits in tools/ ? I don't think we have a choice but to face the problem directly - but others might disagree. I think most of the negatives could be kept small by starting small, allowing maintainers to explicitly opt-in, and observing the effects as we go. But YMMV. Thanks, Ingo
[tip:timers/core] Kconfig: Introduce the "imply" keyword
Commit-ID: 237e3ad0f195d8fd34f1299e45f04793832a16fc
Gitweb: http://git.kernel.org/tip/237e3ad0f195d8fd34f1299e45f04793832a16fc
Author: Nicolas Pitre
AuthorDate: Fri, 11 Nov 2016 00:10:05 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:26:33 +0100
Kconfig: Introduce the "imply" keyword
The "imply" keyword is a weak version of "select" where the target
config symbol can still be turned off, avoiding those pitfalls that come
with the "select" keyword.
This is useful e.g. with multiple drivers that want to indicate their
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.
Currently, the same effect can almost be achieved with:
config DRIVER_A
tristate
config DRIVER_B
tristate
config DRIVER_C
tristate
config DRIVER_D
tristate
[...]
config SUBSYSTEM_X
tristate
default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...]
This is unwieldy to maintain especially with a large number of drivers.
Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X
to y or n, excluding m, when some drivers are built-in. The "select"
keyword allows for excluding m, but it excludes n as well. Hence
this "imply" keyword. The above becomes:
config DRIVER_A
tristate
imply SUBSYSTEM_X
config DRIVER_B
tristate
imply SUBSYSTEM_X
[...]
config SUBSYSTEM_X
tristate
This is much cleaner, and way more flexible than "select". SUBSYSTEM_X
can still be configured out, and it can be set as a module when none of
the drivers are configured in or all of them are modular.
Signed-off-by: Nicolas Pitre
Acked-by: Richard Cochran
Acked-by: Thomas Gleixner
Acked-by: John Stultz
Reviewed-by: Josh Triplett
Cc: Paul Bolle
Cc: linux-kbu...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Michal Marek
Cc: Edward Cree
Link:
http://lkml.kernel.org/r/1478841010-28605-2-git-send-email-nicolas.pi...@linaro.org
Signed-off-by: Thomas Gleixner
---
Documentation/kbuild/kconfig-language.txt | 29
scripts/kconfig/expr.h| 2 ++
scripts/kconfig/menu.c| 55 ++-
scripts/kconfig/symbol.c | 24 +-
scripts/kconfig/zconf.gperf | 1 +
scripts/kconfig/zconf.y | 16 +++--
6 files changed, 108 insertions(+), 19 deletions(-)
diff --git a/Documentation/kbuild/kconfig-language.txt
b/Documentation/kbuild/kconfig-language.txt
index 069fcb3..262722d 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -113,6 +113,34 @@ applicable everywhere (see syntax).
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
+- weak reverse dependencies: "imply" ["if" ]
+ This is similar to "select" as it enforces a lower limit on another
+ symbol except that the "implied" symbol's value may still be set to n
+ from a direct dependency or with a visible prompt.
+
+ Given the following example:
+
+ config FOO
+ tristate
+ imply BAZ
+
+ config BAZ
+ tristate
+ depends on BAR
+
+ The following values are possible:
+
+ FOO BAR BAZ's default choice for BAZ
+ --- --- - --
+ n y n N/m/y
+ m y m M/y/n
+ y y y Y/n
+ y n * N
+
+ This is useful e.g. with multiple drivers that want to indicate their
+ ability to hook into a secondary subsystem while allowing the user to
+ configure that subsystem out without also having to unset these drivers.
+
- limiting menu display: "visible if"
This attribute is only applicable to menu blocks, if the condition is
false, the menu block is not displayed to the user (the symbols
@@ -481,6 +509,7 @@ historical issues resolved through these different
solutions.
b) Match dependency semantics:
b1) Swap all "select FOO" to "depends on FOO" or,
b2) Swap all "depends on FOO" to "select FOO"
+ c) Consider the use of "imply" instead of "select"
The resolution to a) can be tested with the sample Kconfig file
Documentation/kbuild/Kconfig.recursion-issue-01 through the removal
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 973b6f7..a73f762 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -85,6 +85,7 @@ struct symbol {
struct property *prop;
struct expr_value dir_dep;
struct expr_value rev_dep;
+ struct expr_value implied;
};
#define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym
= symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER)
@@ -
[PATCH] ARM: zynq: Fix pmu register description coding style
Drop the space before/after '<' and '>'; and
separate the entries to be a bit more readable.
Reported-by: Julia Cartwright
Signed-off-by: Michal Simek
---
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 402b5bbe3b5b..f3ac9bfe580e 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -46,7 +46,8 @@
compatible = "arm,cortex-a9-pmu";
interrupts = <0 5 4>, <0 6 4>;
interrupt-parent = <&intc>;
- reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
+ reg = <0xf8891000 0x1000>,
+ <0xf8893000 0x1000>;
};
regulator_vccpint: fixedregulator {
--
1.9.1
[tip:timers/core] timer: Move sys_alarm from timer.c to itimer.c
Commit-ID: 74ba181e61c6accf9066d6980f44588de2f854f6
Gitweb: http://git.kernel.org/tip/74ba181e61c6accf9066d6980f44588de2f854f6
Author: Nicolas Pitre
AuthorDate: Fri, 11 Nov 2016 00:10:08 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:26:34 +0100
timer: Move sys_alarm from timer.c to itimer.c
Move the only user of alarm_setitimer to itimer.c where it is defined.
This allows for making alarm_setitimer static, and dropping it from the
build when __ARCH_WANT_SYS_ALARM is not defined.
Signed-off-by: Nicolas Pitre
Acked-by: John Stultz
Cc: Paul Bolle
Cc: linux-kbu...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Richard Cochran
Cc: Josh Triplett
Cc: Michal Marek
Cc: Edward Cree
Link:
http://lkml.kernel.org/r/1478841010-28605-5-git-send-email-nicolas.pi...@linaro.org
Signed-off-by: Thomas Gleixner
---
include/linux/time.h | 2 --
kernel/time/itimer.c | 15 ++-
kernel/time/timer.c | 13 -
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index 4cea09d..23f0f5c 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -172,8 +172,6 @@ extern int do_setitimer(int which, struct itimerval *value,
struct itimerval *ovalue);
extern int do_getitimer(int which, struct itimerval *value);
-extern unsigned int alarm_setitimer(unsigned int seconds);
-
extern long do_utimes(int dfd, const char __user *filename, struct timespec
*times, int flags);
struct tms;
diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c
index 1d5c720..2b9f45b 100644
--- a/kernel/time/itimer.c
+++ b/kernel/time/itimer.c
@@ -238,6 +238,8 @@ again:
return 0;
}
+#ifdef __ARCH_WANT_SYS_ALARM
+
/**
* alarm_setitimer - set alarm in seconds
*
@@ -250,7 +252,7 @@ again:
* On 32 bit machines the seconds value is limited to (INT_MAX/2) to avoid
* negative timeval settings which would cause immediate expiry.
*/
-unsigned int alarm_setitimer(unsigned int seconds)
+static unsigned int alarm_setitimer(unsigned int seconds)
{
struct itimerval it_new, it_old;
@@ -275,6 +277,17 @@ unsigned int alarm_setitimer(unsigned int seconds)
return it_old.it_value.tv_sec;
}
+/*
+ * For backwards compatibility? This can be done in libc so Alpha
+ * and all newer ports shouldn't need it.
+ */
+SYSCALL_DEFINE1(alarm, unsigned int, seconds)
+{
+ return alarm_setitimer(seconds);
+}
+
+#endif
+
SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
struct itimerval __user *, ovalue)
{
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 88aab86..42d27aa 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1662,19 +1662,6 @@ void run_local_timers(void)
raise_softirq(TIMER_SOFTIRQ);
}
-#ifdef __ARCH_WANT_SYS_ALARM
-
-/*
- * For backwards compatibility? This can be done in libc so Alpha
- * and all newer ports shouldn't need it.
- */
-SYSCALL_DEFINE1(alarm, unsigned int, seconds)
-{
- return alarm_setitimer(seconds);
-}
-
-#endif
-
static void process_timeout(unsigned long __data)
{
wake_up_process((struct task_struct *)__data);
[tip:timers/core] Kconfig: Regenerate *.c_shipped files after previous changes
Commit-ID: 32ce5ac867bf4ba8350a751216d087f574a38133
Gitweb: http://git.kernel.org/tip/32ce5ac867bf4ba8350a751216d087f574a38133
Author: Nicolas Pitre
AuthorDate: Fri, 11 Nov 2016 00:10:06 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:26:33 +0100
Kconfig: Regenerate *.c_shipped files after previous changes
Signed-off-by: Nicolas Pitre
Cc: Paul Bolle
Cc: linux-kbu...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Richard Cochran
Cc: Josh Triplett
Cc: Michal Marek
Cc: John Stultz
Cc: Edward Cree
Link:
http://lkml.kernel.org/r/1478841010-28605-3-git-send-email-nicolas.pi...@linaro.org
Signed-off-by: Thomas Gleixner
---
scripts/kconfig/zconf.hash.c_shipped | 30 +-
scripts/kconfig/zconf.tab.c_shipped | 1581 --
2 files changed, 753 insertions(+), 858 deletions(-)
diff --git a/scripts/kconfig/zconf.hash.c_shipped
b/scripts/kconfig/zconf.hash.c_shipped
index 360a62d..d51b15d 100644
--- a/scripts/kconfig/zconf.hash.c_shipped
+++ b/scripts/kconfig/zconf.hash.c_shipped
@@ -55,10 +55,10 @@ kconf_id_hash (register const char *str, register unsigned
int len)
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
- 73, 73, 73, 73, 73, 73, 73, 5, 25, 25,
+ 73, 73, 73, 73, 73, 73, 73, 10, 25, 25,
0, 0, 0, 5, 0, 0, 73, 73, 5, 0,
10, 5, 45, 73, 20, 20, 0, 15, 15, 73,
- 20, 5, 73, 73, 73, 73, 73, 73, 73, 73,
+ 20, 0, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
@@ -120,6 +120,7 @@ struct kconf_id_strings_t
char kconf_id_strings_str43[sizeof("hex")];
char kconf_id_strings_str46[sizeof("config")];
char kconf_id_strings_str47[sizeof("boolean")];
+char kconf_id_strings_str50[sizeof("imply")];
char kconf_id_strings_str51[sizeof("string")];
char kconf_id_strings_str54[sizeof("help")];
char kconf_id_strings_str56[sizeof("prompt")];
@@ -157,6 +158,7 @@ static const struct kconf_id_strings_t
kconf_id_strings_contents =
"hex",
"config",
"boolean",
+"imply",
"string",
"help",
"prompt",
@@ -174,7 +176,7 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
{
enum
{
- TOTAL_KEYWORDS = 34,
+ TOTAL_KEYWORDS = 35,
MIN_WORD_LENGTH = 2,
MAX_WORD_LENGTH = 14,
MIN_HASH_VALUE = 2,
@@ -205,15 +207,15 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str12,
T_DEFAULT, TF_COMMAND, S_TRISTATE},
#line 36 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str13,
T_DEFAULT, TF_COMMAND, S_BOOLEAN},
-#line 46 "scripts/kconfig/zconf.gperf"
+#line 47 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str14,
T_OPT_DEFCONFIG_LIST,TF_OPTION},
{-1}, {-1},
-#line 44 "scripts/kconfig/zconf.gperf"
+#line 45 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str17,
T_ON, TF_PARAM},
#line 29 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str18,
T_OPTIONAL, TF_COMMAND},
{-1}, {-1},
-#line 43 "scripts/kconfig/zconf.gperf"
+#line 44 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str21,
T_OPTION, TF_COMMAND},
#line 17 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str22,
T_ENDMENU, TF_COMMAND},
@@ -223,9 +225,9 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
#line 23 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str25,
T_MENUCONFIG, TF_COMMAND},
{-1},
-#line 45 "scripts/kconfig/zconf.gperf"
+#line 46 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str27,
T_OPT_MODULES, TF_OPTION},
-#line 48 "scripts/kconfig/zconf.gperf"
+#line 49 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str28,
T_OPT_ALLNOCONFIG_Y,TF_OPTION},
#line 16 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str29,
T_MENU, TF_COMMAND},
@@ -234,10 +236,10 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str31,
T_SELECT, TF_COMMAND},
#line 21 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str32,
T_COMMENT, TF_COM
[tip:timers/core] ptp_clock: Allow for it to be optional
Commit-ID: d1cbfd771ce8297fa11e89f315392de6056a2181 Gitweb: http://git.kernel.org/tip/d1cbfd771ce8297fa11e89f315392de6056a2181 Author: Nicolas Pitre AuthorDate: Fri, 11 Nov 2016 00:10:07 -0500 Committer: Thomas Gleixner CommitDate: Wed, 16 Nov 2016 09:26:34 +0100 ptp_clock: Allow for it to be optional In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to accept NULL from ptp_clock_register() in that case. And to make it possible for PTP to be configured out, the select statement in those driver's Kconfig menu entries is converted to the new "imply" statement. This way the PTP subsystem may have Kconfig dependencies of its own, such as POSIX_TIMERS, without having to make those ethernet drivers unavailable if POSIX timers are cconfigured out. And when support for POSIX timers is selected again then the default config option for PTP clock support will automatically be adjusted accordingly. The pch_gbe driver is a bit special as it relies on extra code in drivers/ptp/ptp_pch.c. Therefore we let the make process descend into drivers/ptp/ even if PTP_1588_CLOCK is unselected. Signed-off-by: Nicolas Pitre Acked-by: Richard Cochran Acked-by: Edward Cree Acked-by: Thomas Gleixner Acked-by: John Stultz Reviewed-by: Josh Triplett Cc: Paul Bolle Cc: linux-kbu...@vger.kernel.org Cc: net...@vger.kernel.org Cc: Michal Marek Link: http://lkml.kernel.org/r/1478841010-28605-4-git-send-email-nicolas.pi...@linaro.org Signed-off-by: Thomas Gleixner --- drivers/Makefile| 2 +- drivers/net/ethernet/adi/Kconfig| 2 +- drivers/net/ethernet/amd/Kconfig| 2 +- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 6 ++- drivers/net/ethernet/broadcom/Kconfig | 4 +- drivers/net/ethernet/cavium/Kconfig | 2 +- drivers/net/ethernet/freescale/Kconfig | 2 +- drivers/net/ethernet/intel/Kconfig | 10 ++-- drivers/net/ethernet/mellanox/mlx4/Kconfig | 2 +- drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +- drivers/net/ethernet/renesas/Kconfig| 2 +- drivers/net/ethernet/samsung/Kconfig| 2 +- drivers/net/ethernet/sfc/Kconfig| 2 +- drivers/net/ethernet/stmicro/stmmac/Kconfig | 2 +- drivers/net/ethernet/ti/Kconfig | 2 +- drivers/net/ethernet/tile/Kconfig | 2 +- drivers/ptp/Kconfig | 8 +-- include/linux/ptp_clock_kernel.h| 65 - 18 files changed, 69 insertions(+), 50 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index 194d20b..060026a 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -107,7 +107,7 @@ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_RTC_LIB) += rtc/ obj-y += i2c/ media/ obj-$(CONFIG_PPS) += pps/ -obj-$(CONFIG_PTP_1588_CLOCK) += ptp/ +obj-y += ptp/ obj-$(CONFIG_W1) += w1/ obj-y += power/ obj-$(CONFIG_HWMON)+= hwmon/ diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig index 6b94ba6..98cc8f5 100644 --- a/drivers/net/ethernet/adi/Kconfig +++ b/drivers/net/ethernet/adi/Kconfig @@ -58,7 +58,7 @@ config BFIN_RX_DESC_NUM config BFIN_MAC_USE_HWSTAMP bool "Use IEEE 1588 hwstamp" depends on BFIN_MAC && BF518 - select PTP_1588_CLOCK + imply PTP_1588_CLOCK default y ---help--- To support the IEEE 1588 Precision Time Protocol (PTP), select y here diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig index 0038709..713ea7a 100644 --- a/drivers/net/ethernet/amd/Kconfig +++ b/drivers/net/ethernet/amd/Kconfig @@ -177,7 +177,7 @@ config AMD_XGBE depends on ARM64 || COMPILE_TEST select BITREVERSE select CRC32 - select PTP_1588_CLOCK + imply PTP_1588_CLOCK ---help--- This driver supports the AMD 10GbE Ethernet device found on an AMD SoC. diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c index 9de0788..e10e569 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c @@ -773,7 +773,8 @@ static int xgbe_probe(struct platform_device *pdev) goto err_wq; } - xgbe_ptp_register(pdata); + if (IS_REACHABLE(CONFIG_PTP_1588_CLOCK)) + xgbe_ptp_register(pdata); xgbe_debugfs_init(pdata); @@ -812,7 +813,8 @@ static int xgbe_remove(struct platform_device *pdev) xgbe_debugfs_exit(pdata); - xgbe_ptp_unregister(pdata); + if (I
[tip:timers/core] posix_cpu_timers: Move the add_device_randomness() call to a proper place
Commit-ID: 53d3eaa31508222e445b489f3c3ac4c63542a4ef
Gitweb: http://git.kernel.org/tip/53d3eaa31508222e445b489f3c3ac4c63542a4ef
Author: Nicolas Pitre
AuthorDate: Fri, 11 Nov 2016 00:10:09 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:26:34 +0100
posix_cpu_timers: Move the add_device_randomness() call to a proper place
There is no logical relation between add_device_randomness() and
posix_cpu_timers_exit(). Let's move the former to where the later
is called. This way, when posix-cpu-timers.c is compiled out, there
is no need to worry about not losing a call to add_device_randomness().
Signed-off-by: Nicolas Pitre
Acked-by: John Stultz
Cc: Paul Bolle
Cc: linux-kbu...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Richard Cochran
Cc: Josh Triplett
Cc: Michal Marek
Cc: Edward Cree
Link:
http://lkml.kernel.org/r/1478841010-28605-6-git-send-email-nicolas.pi...@linaro.org
Signed-off-by: Thomas Gleixner
---
kernel/exit.c | 4
kernel/time/posix-cpu-timers.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 9d68c45..d16bcdd 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,6 +117,9 @@ static void __exit_signal(struct task_struct *tsk)
sig->curr_target = next_thread(tsk);
}
+ add_device_randomness((const void*) &tsk->se.sum_exec_runtime,
+ sizeof(unsigned long long));
+
/*
* Accumulate here the counters for all threads as they die. We could
* skip the group leader because it is the last user of signal_struct,
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 39008d7..e582f20 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
@@ -447,10 +446,7 @@ static void cleanup_timers(struct list_head *head)
*/
void posix_cpu_timers_exit(struct task_struct *tsk)
{
- add_device_randomness((const void*) &tsk->se.sum_exec_runtime,
- sizeof(unsigned long long));
cleanup_timers(tsk->cpu_timers);
-
}
void posix_cpu_timers_exit_group(struct task_struct *tsk)
{
[tip:timers/core] posix-timers: Make them configurable
Commit-ID: baa73d9e478ff32d62f3f9422822b59dd9a95a21
Gitweb: http://git.kernel.org/tip/baa73d9e478ff32d62f3f9422822b59dd9a95a21
Author: Nicolas Pitre
AuthorDate: Fri, 11 Nov 2016 00:10:10 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:26:35 +0100
posix-timers: Make them configurable
Some embedded systems have no use for them. This removes about
25KB from the kernel binary size when configured out.
Corresponding syscalls are routed to a stub logging the attempt to
use those syscalls which should be enough of a clue if they were
disabled without proper consideration. They are: timer_create,
timer_gettime: timer_getoverrun, timer_settime, timer_delete,
clock_adjtime, setitimer, getitimer, alarm.
The clock_settime, clock_gettime, clock_getres and clock_nanosleep
syscalls are replaced by simple wrappers compatible with CLOCK_REALTIME,
CLOCK_MONOTONIC and CLOCK_BOOTTIME only which should cover the vast
majority of use cases with very little code.
Signed-off-by: Nicolas Pitre
Acked-by: Richard Cochran
Acked-by: Thomas Gleixner
Acked-by: John Stultz
Reviewed-by: Josh Triplett
Cc: Paul Bolle
Cc: linux-kbu...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Michal Marek
Cc: Edward Cree
Link:
http://lkml.kernel.org/r/1478841010-28605-7-git-send-email-nicolas.pi...@linaro.org
Signed-off-by: Thomas Gleixner
---
arch/alpha/kernel/osf_sys.c | 8 +++
drivers/char/Kconfig| 1 +
drivers/ptp/Kconfig | 2 +-
fs/exec.c | 2 +
init/Kconfig| 17 ++
kernel/compat.c | 8 +++
kernel/exit.c | 11 +++-
kernel/fork.c | 2 +
kernel/signal.c | 6 +++
kernel/sys.c| 3 +-
kernel/time/Makefile| 10 +++-
kernel/time/alarmtimer.c| 6 ++-
kernel/time/posix-stubs.c | 123
kernel/time/timer.c | 3 +-
security/selinux/hooks.c| 11 ++--
15 files changed, 200 insertions(+), 13 deletions(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index ffb93f49..56e427c 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1029,11 +1029,16 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32
__user *, tv,
return do_sys_settimeofday(tv ? &kts : NULL, tz ? &ktz : NULL);
}
+asmlinkage long sys_ni_posix_timers(void);
+
SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it)
{
struct itimerval kit;
int error;
+ if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+ return sys_ni_posix_timers();
+
error = do_getitimer(which, &kit);
if (!error && put_it32(it, &kit))
error = -EFAULT;
@@ -1047,6 +1052,9 @@ SYSCALL_DEFINE3(osf_setitimer, int, which, struct
itimerval32 __user *, in,
struct itimerval kin, kout;
int error;
+ if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
+ return sys_ni_posix_timers();
+
if (in) {
if (get_it32(&kin, in))
return -EFAULT;
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index dcc0973..45ba878 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -542,6 +542,7 @@ config HANGCHECK_TIMER
config MMTIMER
tristate "MMTIMER Memory mapped RTC for SGI Altix"
depends on IA64_GENERIC || IA64_SGI_SN2
+ depends on POSIX_TIMERS
default y
help
The mmtimer device allows direct userspace access to the
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 0f7492f..bdce332 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -6,7 +6,7 @@ menu "PTP clock support"
config PTP_1588_CLOCK
tristate "PTP clock support"
- depends on NET
+ depends on NET && POSIX_TIMERS
select PPS
select NET_PTP_CLASSIFY
help
diff --git a/fs/exec.c b/fs/exec.c
index 4e497b9..923c57d 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1169,8 +1169,10 @@ no_thread_group:
/* we have changed execution domain */
tsk->exit_signal = SIGCHLD;
+#ifdef CONFIG_POSIX_TIMERS
exit_itimers(sig);
flush_itimer_signals();
+#endif
if (atomic_read(&oldsighand->count) != 1) {
struct sighand_struct *newsighand;
diff --git a/init/Kconfig b/init/Kconfig
index 34407f1..456e0b8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1445,6 +1445,23 @@ config SYSCTL_SYSCALL
If unsure say N here.
+config POSIX_TIMERS
+ bool "Posix Clocks & timers" if EXPERT
+ default y
+ help
+ This includes native support for POSIX timers to the kernel.
+ Some embedded systems have no use for them and therefore they
+ can be configured out to reduce the size of the kernel image.
+
+ When this option is disabled, the following syscalls won't be
+ available: timer_create, timer_gettime: timer_getoverrun,
+ ti
Re: [PATCH v2] staging: slicoss: fix different address space warnings
On Wed, Nov 16, 2016 at 8:05 AM, Greg KH wrote:
> On Wed, Nov 16, 2016 at 05:07:37AM +0100, Sergio Paracuellos wrote:
>> This patch fix the following sparse warnings in slicoss driver:
>> warning: incorrect type in assignment (different address spaces)
>>
>> Changes in v2:
>> * Remove IOMEM_GET_FIELDADDR macro
>> * Add ioread64 and iowrite64 defines
>>
>> Signed-off-by: Sergio Paracuellos
>> ---
>> drivers/staging/slicoss/slicoss.c | 111
>> ++
>> 1 file changed, 76 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/staging/slicoss/slicoss.c
>> b/drivers/staging/slicoss/slicoss.c
>> index d2929b9..d68a463 100644
>> --- a/drivers/staging/slicoss/slicoss.c
>> +++ b/drivers/staging/slicoss/slicoss.c
>> @@ -128,6 +128,35 @@
>>
>> MODULE_DEVICE_TABLE(pci, slic_pci_tbl);
>>
>> +#ifndef ioread64
>> +#ifdef readq
>> +#define ioread64 readq
>> +#else
>> +#define ioread64 _ioread64
>> +static inline u64 _ioread64(void __iomem *mmio)
>> +{
>> + u64 low, high;
>> +
>> + low = ioread32(mmio);
>> + high = ioread32(mmio + sizeof(u32));
>> + return low | (high << 32);
>> +}
>> +#endif
>> +#endif
>
> eek, no! Don't write common kernel functions in a driver just because
> some configuration option was incorrect. That implies that you really
> can't do that type of read/write for that platform, so maybe you
> shouldn't be doing it!
>
> Split this up into one patch that does the 32bit stuff, then worry
> about the 64bit stuff in a separate patch please.
>
> thanks,
>
> greg k-h
thank you for your clarification, Greg.
I'll send a v3 patchset with the two patches.
Cheers,
Sergio Paracuellos
Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs
On Tue, Nov 15, 2016 at 03:52:46PM +, Salil Mehta wrote:
> > -Original Message-
> > From: Leon Romanovsky [mailto:l...@kernel.org]
> > Sent: Wednesday, November 09, 2016 7:22 AM
> > To: Salil Mehta
> > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun;
> > mehta.salil@gmail.com; linux-r...@vger.kernel.org;
> > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm;
> > Zhangping (ZP)
> > Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of
> > allocating memory using APIs
> >
> > On Fri, Nov 04, 2016 at 04:36:25PM +, Salil Mehta wrote:
> > > From: "Wei Hu (Xavier)"
> > >
> > > This patch modified the logic of allocating memory using APIs in
> > > hns RoCE driver. We used kcalloc instead of kmalloc_array and
> > > bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> > > memory.
> > >
> > > Signed-off-by: Wei Hu (Xavier)
> > > Signed-off-by: Ping Zhang
> > > Signed-off-by: Salil Mehta
> > > ---
> > > drivers/infiniband/hw/hns/hns_roce_mr.c | 15 ---
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > index fb87883..d3dfb5f 100644
> > > --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct
> > hns_roce_buddy *buddy, int max_order)
> > >
> > > for (i = 0; i <= buddy->max_order; ++i) {
> > > s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> > > - buddy->bits[i] = kmalloc_array(s, sizeof(long),
> > GFP_KERNEL);
> > > - if (!buddy->bits[i])
> > > - goto err_out_free;
> > > -
> > > - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> > > + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> > > + if (!buddy->bits[i]) {
> > > + buddy->bits[i] = vzalloc(s * sizeof(long));
> >
> > I wonder, why don't you use directly vzalloc instead of kcalloc
> > fallback?
> As we know we will have physical contiguous pages if the kcalloc
> call succeeds. This will give us a chance to have better performance
> over the allocations which are just virtually contiguous through the
> function vzalloc(). Therefore, later has only been used as a fallback
> when our memory request cannot be entertained through kcalloc.
>
> Are you suggesting that there will not be much performance penalty
> if we use just vzalloc ?
Not exactly,
I asked it, because we have similar code in our drivers and this
construction looks strange to me.
1. If performance is critical, we will use kmalloc.
2. If performance is not critical, we will use vmalloc.
But in this case, such construction shows me that we can live with
vmalloc performance and kmalloc allocation are not really needed.
In your specific case, I'm not sure that kcalloc will ever fail.
Thanks
>
> >
> > > + if (!buddy->bits[i])
> > > + goto err_out_free;
> > > + }
> > > }
signature.asc
Description: PGP signature
[tip:perf/urgent] perf/core: Do not set cpuctx->cgrp for unscheduled cgroups
Commit-ID: 864c2357ca898c6171fe5284f5ecc795c8ce27a8
Gitweb: http://git.kernel.org/tip/864c2357ca898c6171fe5284f5ecc795c8ce27a8
Author: David Carrillo-Cisneros
AuthorDate: Tue, 1 Nov 2016 11:52:58 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 Nov 2016 14:18:22 +0100
perf/core: Do not set cpuctx->cgrp for unscheduled cgroups
Commit:
db4a835601b7 ("perf/core: Set cgroup in CPU contexts for new cgroup events")
failed to verify that event->cgrp is actually the scheduled cgroup
in a CPU before setting cpuctx->cgrp. This patch fixes that.
Now that there is a different path for scheduled and unscheduled
cgroup, add a warning to catch when cpuctx->cgrp is still set after
the last cgroup event has been unsheduled.
To verify the bug:
# Create 2 cgroups.
mkdir /dev/cgroups/devices/g1
mkdir /dev/cgroups/devices/g2
# launch a task, bind it to a cpu and move it to g1
CPU=2
while :; do : ; done &
P=$!
taskset -pc $CPU $P
echo $P > /dev/cgroups/devices/g1/tasks
# monitor g2 (it runs no tasks) and observe output
perf stat -e cycles -I 1000 -C $CPU -G g2
# time counts unit events
1.91408 7,579,527 cyclesg2
2.000350111cyclesg2
3.000589181cyclesg2
4.000771428cyclesg2
# note first line that displays that a task run in g2, despite
# g2 having no tasks. This is because cpuctx->cgrp was wrongly
# set when context of new event was installed.
# After applying the fix we obtain the right output:
perf stat -e cycles -I 1000 -C $CPU -G g2
# time counts unit events
1.000119615cyclesg2
2.000389430cyclesg2
3.000590962cyclesg2
Signed-off-by: David Carrillo-Cisneros
Signed-off-by: Peter Zijlstra (Intel)
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Linus Torvalds
Cc: Nilay Vaish
Cc: Paul Turner
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vegard Nossum
Link:
http://lkml.kernel.org/r/1478026378-86083-1-git-send-email-davi...@google.com
Signed-off-by: Ingo Molnar
---
kernel/events/core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0e29213..ff230bb 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -902,6 +902,17 @@ list_update_cgroup_event(struct perf_event *event,
* this will always be called from the right CPU.
*/
cpuctx = __get_cpu_context(ctx);
+
+ /* Only set/clear cpuctx->cgrp if current task uses event->cgrp. */
+ if (perf_cgroup_from_task(current, ctx) != event->cgrp) {
+ /*
+* We are removing the last cpu event in this context.
+* If that event is not active in this cpu, cpuctx->cgrp
+* should've been cleared by perf_cgroup_switch.
+*/
+ WARN_ON_ONCE(!add && cpuctx->cgrp);
+ return;
+ }
cpuctx->cgrp = add ? event->cgrp : NULL;
}
[tip:smp/hotplug] x86/mcheck: Move threshold_create_device()
Commit-ID: 0943637293a05aa3d8fb47bc30c7c0104480829a
Gitweb: http://git.kernel.org/tip/0943637293a05aa3d8fb47bc30c7c0104480829a
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 10 Nov 2016 18:44:41 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:34:16 +0100
x86/mcheck: Move threshold_create_device()
Move the threshold_create_device() so it can use
threshold_remove_device() without a forward declaration.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Borislav Petkov
Cc: Tony Luck
Cc: r...@linutronix.de
Cc: linux-e...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161110174447.11848-2-bige...@linutronix.de
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 50 ++--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 9b54034..75a3e3e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -1010,31 +1010,6 @@ static int threshold_create_bank(unsigned int cpu,
unsigned int bank)
return err;
}
-/* create dir/files for all valid threshold banks */
-static int threshold_create_device(unsigned int cpu)
-{
- unsigned int bank;
- struct threshold_bank **bp;
- int err = 0;
-
- bp = kzalloc(sizeof(struct threshold_bank *) * mca_cfg.banks,
-GFP_KERNEL);
- if (!bp)
- return -ENOMEM;
-
- per_cpu(threshold_banks, cpu) = bp;
-
- for (bank = 0; bank < mca_cfg.banks; ++bank) {
- if (!(per_cpu(bank_map, cpu) & (1 << bank)))
- continue;
- err = threshold_create_bank(cpu, bank);
- if (err)
- return err;
- }
-
- return err;
-}
-
static void deallocate_threshold_block(unsigned int cpu,
unsigned int bank)
{
@@ -1114,6 +1089,31 @@ static void threshold_remove_device(unsigned int cpu)
kfree(per_cpu(threshold_banks, cpu));
}
+/* create dir/files for all valid threshold banks */
+static int threshold_create_device(unsigned int cpu)
+{
+ unsigned int bank;
+ struct threshold_bank **bp;
+ int err = 0;
+
+ bp = kzalloc(sizeof(struct threshold_bank *) * mca_cfg.banks,
+GFP_KERNEL);
+ if (!bp)
+ return -ENOMEM;
+
+ per_cpu(threshold_banks, cpu) = bp;
+
+ for (bank = 0; bank < mca_cfg.banks; ++bank) {
+ if (!(per_cpu(bank_map, cpu) & (1 << bank)))
+ continue;
+ err = threshold_create_bank(cpu, bank);
+ if (err)
+ return err;
+ }
+
+ return err;
+}
+
/* get notified when a cpu comes on/off */
static void
amd_64_threshold_cpu_callback(unsigned long action, unsigned int cpu)
[tip:smp/hotplug] x86/mcheck: Explicit cleanup on failure in mce_amd
Commit-ID: ec553abb318d75b1eafd275c71125569fa13b33b Gitweb: http://git.kernel.org/tip/ec553abb318d75b1eafd275c71125569fa13b33b Author: Sebastian Andrzej Siewior AuthorDate: Thu, 10 Nov 2016 18:44:42 +0100 Committer: Thomas Gleixner CommitDate: Wed, 16 Nov 2016 09:34:17 +0100 x86/mcheck: Explicit cleanup on failure in mce_amd If the ONLINE callback fails, the driver does not any clean up right away instead it waits to get to the DEAD stage to do it. Yes, it waits. Since we don't pass the error code back to the caller, no one knows. Do the clean up right away so it does not look like a leak. Signed-off-by: Sebastian Andrzej Siewior Acked-by: Borislav Petkov Cc: Tony Luck Cc: r...@linutronix.de Cc: linux-e...@vger.kernel.org Link: http://lkml.kernel.org/r/20161110174447.11848-3-bige...@linutronix.de Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/mcheck/mce_amd.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 75a3e3e..55cd018 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -1087,6 +1087,7 @@ static void threshold_remove_device(unsigned int cpu) threshold_remove_bank(cpu, bank); } kfree(per_cpu(threshold_banks, cpu)); + per_cpu(threshold_banks, cpu) = NULL; } /* create dir/files for all valid threshold banks */ @@ -1108,9 +1109,11 @@ static int threshold_create_device(unsigned int cpu) continue; err = threshold_create_bank(cpu, bank); if (err) - return err; + goto err; } - + return err; +err: + threshold_remove_device(cpu); return err; }
[tip:smp/hotplug] x86/mcheck: Be prepared for a rollback back to the ONLINE state
Commit-ID: 7f34b935e8bf2f5304fce273a8fa98c63886d686 Gitweb: http://git.kernel.org/tip/7f34b935e8bf2f5304fce273a8fa98c63886d686 Author: Sebastian Andrzej Siewior AuthorDate: Thu, 10 Nov 2016 18:44:43 +0100 Committer: Thomas Gleixner CommitDate: Wed, 16 Nov 2016 09:34:17 +0100 x86/mcheck: Be prepared for a rollback back to the ONLINE state If we try a CPU down and fail in the middle then we roll back to the online state. This means we would perform CPU_ONLINE / mce_device_create() without invoking CPU_DEAD / mce_device_remove() for the cleanup of what was allocated in CPU_ONLINE. Be prepared for this and don't allocate the struct if we have it already. Signed-off-by: Sebastian Andrzej Siewior Acked-by: Borislav Petkov Cc: Tony Luck Cc: r...@linutronix.de Cc: linux-e...@vger.kernel.org Link: http://lkml.kernel.org/r/20161110174447.11848-4-bige...@linutronix.de Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/mcheck/mce.c | 4 arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 2 files changed, 8 insertions(+) diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index a7fdf45..e9ffd6d 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -2409,6 +2409,10 @@ static int mce_device_create(unsigned int cpu) if (!mce_available(&boot_cpu_data)) return -EIO; + dev = per_cpu(mce_device, cpu); + if (dev) + return 0; + dev = kzalloc(sizeof *dev, GFP_KERNEL); if (!dev) return -ENOMEM; diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c index 55cd018..e93580c 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c @@ -1097,6 +1097,10 @@ static int threshold_create_device(unsigned int cpu) struct threshold_bank **bp; int err = 0; + bp = per_cpu(threshold_banks, cpu); + if (bp) + return 0; + bp = kzalloc(sizeof(struct threshold_bank *) * mca_cfg.banks, GFP_KERNEL); if (!bp)
[tip:smp/hotplug] x86/mcheck: Split threshold_cpu_callback into two callbacks
Commit-ID: 4d7b02d58c4000597d08930193d7aed81fba6b7c
Gitweb: http://git.kernel.org/tip/4d7b02d58c4000597d08930193d7aed81fba6b7c
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 10 Nov 2016 18:44:44 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:34:17 +0100
x86/mcheck: Split threshold_cpu_callback into two callbacks
The threshold_cpu_callback callbacks looks like one of the notifier and
its arguments are almost the same. Split this out and have one ONLINE
and one DEAD callback. This will come handy later once the main code
gets changed to use the callback mechanism.
Also, handle threshold_cpu_callback_online() return value so we don't
continue if the function fails.
Boris Petkov removed the callback pointer and replaced it with proper
functions.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Borislav Petkov
Cc: Tony Luck
Cc: r...@linutronix.de
Cc: linux-e...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161110174447.11848-5-bige...@linutronix.de
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mce.h | 7 +--
arch/x86/kernel/cpu/mcheck/mce.c | 14 +++--
arch/x86/kernel/cpu/mcheck/mce_amd.c | 38 ++--
3 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 9bd7ff5..caafad4 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -293,9 +293,7 @@ void do_machine_check(struct pt_regs *, long);
/*
* Threshold handler
*/
-
extern void (*mce_threshold_vector)(void);
-extern void (*threshold_cpu_callback)(unsigned long action, unsigned int cpu);
/* Deferred error interrupt handler */
extern void (*deferred_error_int_vector)(void);
@@ -377,7 +375,12 @@ struct smca_bank_info {
};
extern struct smca_bank_info smca_banks[MAX_NR_BANKS];
+extern int mce_threshold_create_device(unsigned int cpu);
+extern int mce_threshold_remove_device(unsigned int cpu);
+#else
+static inline int mce_threshold_create_device(unsigned int cpu) { return 0; };
+static inline int mce_threshold_remove_device(unsigned int cpu) { return 0; };
#endif
#endif /* _ASM_X86_MCE_H */
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index e9ffd6d..052b5e0 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2255,8 +2255,6 @@ static struct bus_type mce_subsys = {
DEFINE_PER_CPU(struct device *, mce_device);
-void (*threshold_cpu_callback)(unsigned long action, unsigned int cpu);
-
static inline struct mce_bank *attr_to_bank(struct device_attribute *attr)
{
return container_of(attr, struct mce_bank, attr);
@@ -2512,13 +2510,17 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned
long action, void *hcpu)
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
+
mce_device_create(cpu);
- if (threshold_cpu_callback)
- threshold_cpu_callback(action, cpu);
+
+ if (mce_threshold_create_device(cpu)) {
+ mce_device_remove(cpu);
+ return NOTIFY_BAD;
+ }
+
break;
case CPU_DEAD:
- if (threshold_cpu_callback)
- threshold_cpu_callback(action, cpu);
+ mce_threshold_remove_device(cpu);
mce_device_remove(cpu);
mce_intel_hcpu_update(cpu);
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index e93580c..c33a3ee 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -55,6 +55,8 @@
/* Threshold LVT offset is at MSR0xC410[15:12] */
#define SMCA_THR_LVT_OFF 0xF000
+static bool thresholding_en;
+
static const char * const th_names[] = {
"load_store",
"insn_fetch",
@@ -1077,10 +1079,13 @@ free_out:
per_cpu(threshold_banks, cpu)[bank] = NULL;
}
-static void threshold_remove_device(unsigned int cpu)
+int mce_threshold_remove_device(unsigned int cpu)
{
unsigned int bank;
+ if (!thresholding_en)
+ return 0;
+
for (bank = 0; bank < mca_cfg.banks; ++bank) {
if (!(per_cpu(bank_map, cpu) & (1 << bank)))
continue;
@@ -1088,15 +1093,19 @@ static void threshold_remove_device(unsigned int cpu)
}
kfree(per_cpu(threshold_banks, cpu));
per_cpu(threshold_banks, cpu) = NULL;
+ return 0;
}
/* create dir/files for all valid threshold banks */
-static int threshold_create_device(unsigned int cpu)
+int mce_threshold_create_device(unsigned int cpu)
{
unsigned int bank;
struct threshold_bank **bp;
int err = 0;
+ if (!thresholding_en)
+ return 0;
+
bp = per_cpu(threshold_banks, cpu);
if (bp)
return 0;
@@ -1117,40 +1126,23 @@ static int threshol
[tip:smp/hotplug] x86/mcheck: Reorganize the hotplug callbacks
Commit-ID: 39f152ffbfedb42b57b6e0c896eeae51dbe83b7a
Gitweb: http://git.kernel.org/tip/39f152ffbfedb42b57b6e0c896eeae51dbe83b7a
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 10 Nov 2016 18:44:45 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:34:18 +0100
x86/mcheck: Reorganize the hotplug callbacks
Initially I wanted to remove mcheck_cpu_init() from identify_cpu() and let it
become an independent early hotplug callback. The main problem here was that
the init on the boot CPU may happen too late
(device_initcall_sync(mcheck_init_device)) and nobody wanted to risk receiving
and MCE event at boot time leading to a shutdown (if the MCE feature is not yet
enabled).
Here is attempt two: the timming stays as-is but the ordering of the functions
is changed:
- mcheck_cpu_init() (which is run from identify_cpu()) will setup the timer
struct but won't fire the timer. This is moved to CPU_ONLINE since its
cleanup part is in CPU_DOWN_PREPARE. So if it is okay to stop the timer early
in the shutdown phase, it should be okay to start it late in the bring up
phase.
- CPU_DOWN_PREPARE disables the MCE feature flags for !INTEL CPUs in
mce_disable_cpu(). If a failure occures it would be re-enabled on all vendor
CPUs (including Intel where it was not disabled during shutdown). To keep this
working I am moving it to CPU_ONLINE. smp_call_function_single() is dropped
beause the notifier runs nowdays on the target CPU.
- CPU_ONLINE is invoking mce_device_create() + mce_threshold_create_device()
but its cleanup part is in CPU_DEAD (mce_threshold_remove_device() and
mce_device_remove()). In order to keep this symmetrical I am moving the clean
up from CPU_DEAD to CPU_DOWN_PREPARE.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Borislav Petkov
Cc: Tony Luck
Cc: r...@linutronix.de
Cc: linux-e...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161110174447.11848-6-bige...@linutronix.de
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/mcheck/mce.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 052b5e0..a524faa 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1745,6 +1745,14 @@ static void mce_start_timer(unsigned int cpu, struct
timer_list *t)
add_timer_on(t, cpu);
}
+static void __mcheck_cpu_setup_timer(void)
+{
+ struct timer_list *t = this_cpu_ptr(&mce_timer);
+ unsigned int cpu = smp_processor_id();
+
+ setup_pinned_timer(t, mce_timer_fn, cpu);
+}
+
static void __mcheck_cpu_init_timer(void)
{
struct timer_list *t = this_cpu_ptr(&mce_timer);
@@ -1796,7 +1804,7 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)
__mcheck_cpu_init_generic();
__mcheck_cpu_init_vendor(c);
__mcheck_cpu_init_clear_banks();
- __mcheck_cpu_init_timer();
+ __mcheck_cpu_setup_timer();
}
/*
@@ -2470,28 +2478,25 @@ static void mce_device_remove(unsigned int cpu)
}
/* Make sure there are no machine checks on offlined CPUs. */
-static void mce_disable_cpu(void *h)
+static void mce_disable_cpu(void)
{
- unsigned long action = *(unsigned long *)h;
-
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
- if (!(action & CPU_TASKS_FROZEN))
+ if (!cpuhp_tasks_frozen)
cmci_clear();
vendor_disable_error_reporting();
}
-static void mce_reenable_cpu(void *h)
+static void mce_reenable_cpu(void)
{
- unsigned long action = *(unsigned long *)h;
int i;
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
- if (!(action & CPU_TASKS_FROZEN))
+ if (!cpuhp_tasks_frozen)
cmci_reenable();
for (i = 0; i < mca_cfg.banks; i++) {
struct mce_bank *b = &mce_banks[i];
@@ -2510,6 +2515,7 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned
long action, void *hcpu)
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
mce_device_create(cpu);
@@ -2517,11 +2523,10 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned
long action, void *hcpu)
mce_device_remove(cpu);
return NOTIFY_BAD;
}
-
+ mce_reenable_cpu();
+ mce_start_timer(cpu, t);
break;
case CPU_DEAD:
- mce_threshold_remove_device(cpu);
- mce_device_remove(cpu);
mce_intel_hcpu_update(cpu);
/* intentionally ignoring frozen here */
@@ -2529,12 +2534,11 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned
long action, void *hcpu)
cmci_rediscover();
break;
case CPU_DOWN_PREPARE:
- smp_call_function_single(cpu, mce_disable_cpu, &action, 1);
[tip:smp/hotplug] x86/mcheck: Move CPU_ONLINE and CPU_DOWN_PREPARE to hotplug state machine
Commit-ID: 8c0eeac819c85e4c1143f7a874d87b4594739208
Gitweb: http://git.kernel.org/tip/8c0eeac819c85e4c1143f7a874d87b4594739208
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 10 Nov 2016 18:44:46 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:34:18 +0100
x86/mcheck: Move CPU_ONLINE and CPU_DOWN_PREPARE to hotplug state machine
The CPU_ONLINE and CPU_DOWN_PREPARE look fully symmetrical and could be move
to the hotplug state machine.
On a failure during registration we have the tear down callback invoked
(mce_cpu_pre_down()) so there should be no timer around and so no need to need
keep notifier installed (this was the reason according to the comment why the
notifier was registered despite of errors).
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Borislav Petkov
Cc: Tony Luck
Cc: r...@linutronix.de
Cc: linux-e...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161110174447.11848-7-bige...@linutronix.de
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/mcheck/mce.c | 78 +++-
1 file changed, 36 insertions(+), 42 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index a524faa..78955f5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2511,21 +2511,8 @@ static int
mce_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
- struct timer_list *t = &per_cpu(mce_timer, cpu);
switch (action & ~CPU_TASKS_FROZEN) {
- case CPU_ONLINE:
- case CPU_DOWN_FAILED:
-
- mce_device_create(cpu);
-
- if (mce_threshold_create_device(cpu)) {
- mce_device_remove(cpu);
- return NOTIFY_BAD;
- }
- mce_reenable_cpu();
- mce_start_timer(cpu, t);
- break;
case CPU_DEAD:
mce_intel_hcpu_update(cpu);
@@ -2534,17 +2521,41 @@ mce_cpu_callback(struct notifier_block *nfb, unsigned
long action, void *hcpu)
cmci_rediscover();
break;
case CPU_DOWN_PREPARE:
- mce_disable_cpu();
- del_timer_sync(t);
- mce_threshold_remove_device(cpu);
- mce_device_remove(cpu);
break;
}
return NOTIFY_OK;
}
+static int mce_cpu_online(unsigned int cpu)
+{
+ struct timer_list *t = &per_cpu(mce_timer, cpu);
+ int ret;
+
+ mce_device_create(cpu);
+
+ ret = mce_threshold_create_device(cpu);
+ if (ret) {
+ mce_device_remove(cpu);
+ return ret;
+ }
+ mce_reenable_cpu();
+ mce_start_timer(cpu, t);
+ return 0;
+}
+
+static int mce_cpu_pre_down(unsigned int cpu)
+{
+ struct timer_list *t = &per_cpu(mce_timer, cpu);
+
+ mce_disable_cpu();
+ del_timer_sync(t);
+ mce_threshold_remove_device(cpu);
+ mce_device_remove(cpu);
+ return 0;
+}
+
static struct notifier_block mce_cpu_notifier = {
.notifier_call = mce_cpu_callback,
};
@@ -2569,8 +2580,8 @@ static __init void mce_init_banks(void)
static __init int mcheck_init_device(void)
{
+ enum cpuhp_state hp_online;
int err;
- int i = 0;
if (!mce_available(&boot_cpu_data)) {
err = -EIO;
@@ -2588,21 +2599,13 @@ static __init int mcheck_init_device(void)
if (err)
goto err_out_mem;
- cpu_notifier_register_begin();
- for_each_online_cpu(i) {
- err = mce_device_create(i);
- if (err) {
- /*
-* Register notifier anyway (and do not unreg it) so
-* that we don't leave undeleted timers, see notifier
-* callback above.
-*/
- __register_hotcpu_notifier(&mce_cpu_notifier);
- cpu_notifier_register_done();
- goto err_device_create;
- }
- }
+ err = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/mce:online",
+ mce_cpu_online, mce_cpu_pre_down);
+ if (err < 0)
+ goto err_out_mem;
+ hp_online = err;
+ cpu_notifier_register_begin();
__register_hotcpu_notifier(&mce_cpu_notifier);
cpu_notifier_register_done();
@@ -2617,16 +2620,7 @@ static __init int mcheck_init_device(void)
err_register:
unregister_syscore_ops(&mce_syscore_ops);
-
-err_device_create:
- /*
-* We didn't keep track of which devices were created above, but
-* even if we had, the set of online cpus might have changed.
-* Play safe and remove for every possible cpu, since
-* mce_device_remove() will do the right thing.
-*/
- for_each_possible_cpu(i)
-
[tip:smp/hotplug] x86/mcheck: Move CPU_DEAD to hotplug state machine
Commit-ID: 0e285d36bd2bfee0b95433ccc9065c878164f5b2
Gitweb: http://git.kernel.org/tip/0e285d36bd2bfee0b95433ccc9065c878164f5b2
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 10 Nov 2016 18:44:47 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:34:18 +0100
x86/mcheck: Move CPU_DEAD to hotplug state machine
This moves the last piece of the old hotplug notifier code in MCE to the
new hotplug state machine.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Borislav Petkov
Cc: Tony Luck
Cc: r...@linutronix.de
Cc: linux-e...@vger.kernel.org
Link: http://lkml.kernel.org/r/20161110174447.11848-8-bige...@linutronix.de
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/mcheck/mce.c | 42 ++--
include/linux/cpuhotplug.h | 1 +
2 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 78955f5..b888e2f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2506,26 +2506,14 @@ static void mce_reenable_cpu(void)
}
}
-/* Get notified when a cpu comes on/off. Be hotplug friendly. */
-static int
-mce_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
+static int mce_cpu_dead(unsigned int cpu)
{
- unsigned int cpu = (unsigned long)hcpu;
+ mce_intel_hcpu_update(cpu);
- switch (action & ~CPU_TASKS_FROZEN) {
- case CPU_DEAD:
- mce_intel_hcpu_update(cpu);
-
- /* intentionally ignoring frozen here */
- if (!(action & CPU_TASKS_FROZEN))
- cmci_rediscover();
- break;
- case CPU_DOWN_PREPARE:
-
- break;
- }
-
- return NOTIFY_OK;
+ /* intentionally ignoring frozen here */
+ if (!cpuhp_tasks_frozen)
+ cmci_rediscover();
+ return 0;
}
static int mce_cpu_online(unsigned int cpu)
@@ -2556,10 +2544,6 @@ static int mce_cpu_pre_down(unsigned int cpu)
return 0;
}
-static struct notifier_block mce_cpu_notifier = {
- .notifier_call = mce_cpu_callback,
-};
-
static __init void mce_init_banks(void)
{
int i;
@@ -2599,16 +2583,17 @@ static __init int mcheck_init_device(void)
if (err)
goto err_out_mem;
+ err = cpuhp_setup_state(CPUHP_X86_MCE_DEAD, "x86/mce:dead", NULL,
+ mce_cpu_dead);
+ if (err)
+ goto err_out_mem;
+
err = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/mce:online",
mce_cpu_online, mce_cpu_pre_down);
if (err < 0)
- goto err_out_mem;
+ goto err_out_online;
hp_online = err;
- cpu_notifier_register_begin();
- __register_hotcpu_notifier(&mce_cpu_notifier);
- cpu_notifier_register_done();
-
register_syscore_ops(&mce_syscore_ops);
/* register character device /dev/mcelog */
@@ -2622,6 +2607,9 @@ err_register:
unregister_syscore_ops(&mce_syscore_ops);
cpuhp_remove_state(hp_online);
+err_out_online:
+ cpuhp_remove_state(CPUHP_X86_MCE_DEAD);
+
err_out_mem:
free_cpumask_var(mce_device_initialized);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 3410d83..79b96f6 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -16,6 +16,7 @@ enum cpuhp_state {
CPUHP_PERF_SUPERH,
CPUHP_X86_HPET_DEAD,
CPUHP_X86_APB_DEAD,
+ CPUHP_X86_MCE_DEAD,
CPUHP_VIRT_NET_DEAD,
CPUHP_SLUB_DEAD,
CPUHP_MM_WRITEBACK_DEAD,
Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic
Hi Boris,
I found a bug during my review. Please see below.
On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
wrote:
> BBT support is currently tightly tied to raw NAND, though this is the kind
> of code we could share across all NAND based devices, no matter what
> physical interface is to communicate with the NAND chip.
>
> Make BBT code interface agnostic by replacing all occurrence of
> struct nand_chip by struct nand_device, and move functions that are
> specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/nand/raw/nand_base.c | 78 -
> drivers/mtd/nand/raw/nand_bbt.c | 609
> ++-
> include/linux/mtd/nand.h | 8 +
> include/linux/mtd/rawnand.h | 4 -
> 4 files changed, 361 insertions(+), 338 deletions(-)
>
[...]
> /**
> * write_bbt - [GENERIC] (Re)write the bad block table
> - * @mtd: MTD device structure
> + * @this: NAND device
> * @buf: temporary buffer
> * @td: descriptor for the bad block table
> * @md: descriptor for the bad block table mirror
> @@ -708,11 +707,11 @@ static void mark_bbt_block_bad(struct nand_chip *this,
> *
> * (Re)write the bad block table.
> */
> -static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> +static int write_bbt(struct nand_device *this, uint8_t *buf,
> struct nand_bbt_descr *td, struct nand_bbt_descr *md,
> int chipsel)
> {
> - struct nand_chip *this = mtd_to_nandc(mtd);
> + struct mtd_info *mtd = nand_to_mtd(this);
> struct erase_info einfo;
> int i, res, chip = 0;
> int bits, page, offs, numblocks, sft, sftmsk;
> @@ -723,7 +722,7 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> loff_t to;
> struct mtd_oob_ops ops;
>
> - ops.ooblen = mtd->oobsize;
> + ops.ooblen = nand_per_page_oobsize(this);
> ops.ooboffs = 0;
> ops.datbuf = NULL;
> ops.mode = MTD_OPS_PLACE_OOB;
> @@ -732,16 +731,16 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> rcode = 0xff;
> /* Write bad block table per chip rather than per device? */
> if (td->options & NAND_BBT_PERCHIP) {
> - numblocks = (int)(this->chipsize >> this->bbt_erase_shift);
> + numblocks = nand_eraseblocks_per_die(this);
> /* Full device write or specific chip? */
> if (chipsel == -1) {
> - nrchips = this->numchips;
> + nrchips = nand_ndies(this);
> } else {
> nrchips = chipsel + 1;
> chip = chipsel;
> }
> } else {
> - numblocks = (int)(mtd->size >> this->bbt_erase_shift);
> + numblocks = nand_neraseblocks(this);
> nrchips = 1;
> }
>
> @@ -760,7 +759,7 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> * get_bbt_block() returns a block number, shift the value to
> * get a page number.
> */
> - page = block << (this->bbt_erase_shift - this->page_shift);
> + nand_eraseblock_to_page(this, block);
Should be page = nand_eraseblock_to_page(this, block);
I will continue to review and test your patch. Hope give you feedback this week.
Thanks,
Peter Pan
Re: [PATCH] perf/x86/uncore: remove event_list for snb client uncore IMC
* kan.li...@intel.com wrote:
> From: Kan Liang
>
> A BUG was found by perf_fuzzer after enabled KASAN.
> [ 205.748005] BUG: KASAN: slab-out-of-bounds in
> snb_uncore_imc_event_del+0x6c/0xa0 at addr 8800caa43768
> Reported-by: Vince Weaver
> Tested-by: Vince Weaver
> Signed-off-by: Kan Liang
> ---
> arch/x86/events/intel/uncore_snb.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/x86/events/intel/uncore_snb.c
> b/arch/x86/events/intel/uncore_snb.c
> index 81195cc..a3dcc12 100644
> --- a/arch/x86/events/intel/uncore_snb.c
> +++ b/arch/x86/events/intel/uncore_snb.c
> @@ -490,24 +490,12 @@ static int snb_uncore_imc_event_add(struct perf_event
> *event, int flags)
>
> snb_uncore_imc_event_start(event, 0);
>
> - box->n_events++;
> -
> return 0;
> }
>
> static void snb_uncore_imc_event_del(struct perf_event *event, int flags)
> {
> - struct intel_uncore_box *box = uncore_event_to_box(event);
> - int i;
> -
> snb_uncore_imc_event_stop(event, PERF_EF_UPDATE);
> -
> - for (i = 0; i < box->n_events; i++) {
> - if (event == box->event_list[i]) {
> - --box->n_events;
> - break;
> - }
> - }
I'll apply this fix - but could we please also make sure box->event_list[]
_always_ get initialized to a sane state?
If it had a proper zero initial value in box->n_events the bug would not have
triggered. So struct intel_uncore_box initialization appears to be sloppy,
and that should be looked at as well...
Thanks,
Ingo
Re: [PATCH v2 6/7] mtd: nand: raw: make BBT code more generic
On Wed, 16 Nov 2016 16:43:58 +0800
Peter Pan wrote:
> Hi Boris,
>
> I found a bug during my review. Please see below.
>
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
> wrote:
> > BBT support is currently tightly tied to raw NAND, though this is the kind
> > of code we could share across all NAND based devices, no matter what
> > physical interface is to communicate with the NAND chip.
> >
> > Make BBT code interface agnostic by replacing all occurrence of
> > struct nand_chip by struct nand_device, and move functions that are
> > specific to raw NANDs to drivers/mtd/nand/rawnand/nand_base.c.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/mtd/nand/raw/nand_base.c | 78 -
> > drivers/mtd/nand/raw/nand_bbt.c | 609
> > ++-
> > include/linux/mtd/nand.h | 8 +
> > include/linux/mtd/rawnand.h | 4 -
> > 4 files changed, 361 insertions(+), 338 deletions(-)
> >
> [...]
> > /**
> > * write_bbt - [GENERIC] (Re)write the bad block table
> > - * @mtd: MTD device structure
> > + * @this: NAND device
> > * @buf: temporary buffer
> > * @td: descriptor for the bad block table
> > * @md: descriptor for the bad block table mirror
> > @@ -708,11 +707,11 @@ static void mark_bbt_block_bad(struct nand_chip *this,
> > *
> > * (Re)write the bad block table.
> > */
> > -static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> > +static int write_bbt(struct nand_device *this, uint8_t *buf,
> > struct nand_bbt_descr *td, struct nand_bbt_descr *md,
> > int chipsel)
> > {
> > - struct nand_chip *this = mtd_to_nandc(mtd);
> > + struct mtd_info *mtd = nand_to_mtd(this);
> > struct erase_info einfo;
> > int i, res, chip = 0;
> > int bits, page, offs, numblocks, sft, sftmsk;
> > @@ -723,7 +722,7 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> > loff_t to;
> > struct mtd_oob_ops ops;
> >
> > - ops.ooblen = mtd->oobsize;
> > + ops.ooblen = nand_per_page_oobsize(this);
> > ops.ooboffs = 0;
> > ops.datbuf = NULL;
> > ops.mode = MTD_OPS_PLACE_OOB;
> > @@ -732,16 +731,16 @@ static int write_bbt(struct mtd_info *mtd, uint8_t
> > *buf,
> > rcode = 0xff;
> > /* Write bad block table per chip rather than per device? */
> > if (td->options & NAND_BBT_PERCHIP) {
> > - numblocks = (int)(this->chipsize >> this->bbt_erase_shift);
> > + numblocks = nand_eraseblocks_per_die(this);
> > /* Full device write or specific chip? */
> > if (chipsel == -1) {
> > - nrchips = this->numchips;
> > + nrchips = nand_ndies(this);
> > } else {
> > nrchips = chipsel + 1;
> > chip = chipsel;
> > }
> > } else {
> > - numblocks = (int)(mtd->size >> this->bbt_erase_shift);
> > + numblocks = nand_neraseblocks(this);
> > nrchips = 1;
> > }
> >
> > @@ -760,7 +759,7 @@ static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
> > * get_bbt_block() returns a block number, shift the value
> > to
> > * get a page number.
> > */
> > - page = block << (this->bbt_erase_shift - this->page_shift);
> > + nand_eraseblock_to_page(this, block);
>
> Should be page = nand_eraseblock_to_page(this, block);
>
> I will continue to review and test your patch. Hope give you feedback this
> week.
Cool. Thanks a lot!
>
> Thanks,
> Peter Pan
RE: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Monday, November 14, 2016 11:12 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Ulf Hansson; Adrian Hunter; yangbo lu;
> Michael Walle
> Subject: [PATCH v3] mmc: sdhci-of-esdhc: fixup PRESENT_STATE read
>
> Since commit 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy
> cards in __mmc_switch()") the ESDHC driver is broken:
> mmc0: Card stuck in programming state! __mmc_switch
> mmc0: error -110 whilst initialising MMC card
>
> Since this commit __mmc_switch() uses ->card_busy(), which is
> sdhci_card_busy() for the esdhc driver. sdhci_card_busy() uses the
> PRESENT_STATE register, specifically the DAT0 signal level bit. But the
> ESDHC uses a non-conformant PRESENT_STATE register, thus a read fixup is
> required to make the driver work again.
>
> Signed-off-by: Michael Walle
> Fixes: 87a18a6a5652 ("mmc: mmc: Use ->card_busy() to detect busy cards in
> __mmc_switch()")
> ---
> v3:
> - explain the bits in the comments
> - use bits[19:0] from the original value, all other will be taken from
> the
>fixup value.
>
> v2:
> - use lower bits of the original value (that was actually a typo)
> - add fixes tag
> - fix typo
>
> drivers/mmc/host/sdhci-of-esdhc.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index fb71c86..74cf3b1 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -66,6 +66,19 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
> return ret;
> }
> }
> + /*
> + * The DAT[3:0] line signal levels and the CMD line signal level
> are
> + * not compatible with standard SDHC register. The line signal
> levels
> + * DAT[7:0] are at bits 31:24 and the line signal level is at bit
> 23.
> + * All other bits are the same as in the standard SDHC register.
> + */
> + if (spec_reg == SDHCI_PRESENT_STATE) {
> + ret = value & 0x000f;
> + ret |= (value >> 4) & SDHCI_DATA_LVL_MASK;
> + ret |= (value << 1) & 0x0100;
> + return ret;
> + }
> +
[Lu Yangbo-B47093] This is the proper fix.
Acked-by: Yangbo Lu
> ret = value;
> return ret;
> }
> --
> 2.1.4
[PATCH] remoteproc: adsp-pil: fix recursive dependency
The newly added driver tries to 'select' a symbol that it has an implicit dependency on, which confuses Kconfig: subsection "Kconfig recursive dependency limitations" drivers/remoteproc/Kconfig:3: symbol REMOTEPROC is selected by QCOM_ADSP_PIL As REMOTEPROC is itself user-visible, we clearly should not select it from a driver, removing the line fixes the problem. Signed-off-by: Arnd Bergmann --- drivers/remoteproc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 9c41128750ca..5a0019ce7555 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -81,10 +81,10 @@ config DA8XX_REMOTEPROC config QCOM_ADSP_PIL tristate "Qualcomm ADSP Peripheral Image Loader" depends on OF && ARCH_QCOM + depends on REMOTEPROC depends on QCOM_SMEM select MFD_SYSCON select QCOM_MDT_LOADER - select REMOTEPROC help Say y here to support the TrustZone based Peripherial Image Loader for the Qualcomm ADSP remote processors. -- 2.9.0
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > So what I'd love to see is to have a kernel option that re-introduces some > historic root (and other) holes that can be exploited deterministically - > obviously default disabled. Ick, I don't want to have to support nasty #ifdefs for "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+ years, do you? > I'd restrict this to reasonably 'deterministic' holes, and the exploits > themselves > could be somewhere in tools/. (Obviously only where the maintainers agree to > host > the code.) They wouldn't give a root shell, they'd only test whether they > reached > uid0 (or some other elevated privilege). Having exploits in tools/ would be good, I would like to see that, as then we can ensure that we don't ever introduce old problems that we have fixed again in the future. That I have no objection to. thanks, greg k-h
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Mon, 2016-11-14 at 06:34 -0800, Guenter Roeck wrote:
> >>> +int typec_connect(struct typec_port *port, struct
> typec_connection *con)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + if (!con->partner && !con->cable)
> >>> + return -EINVAL;
> >>> +
> >>> + port->connected = 1;
> >>> + port->data_role = con->data_role;
> >>> + port->pwr_role = con->pwr_role;
> >>> + port->vconn_role = con->vconn_role;
> >>> + port->pwr_opmode = con->pwr_opmode;
> >>> +
> >>> + kobject_uevent(&port->dev.kobj, KOBJ_CHANGE);
> >>
> >> This worries me. Who is listening for it? What will you do with
> it?
> >> Shouldn't you just poll on an attribute file instead?
> >
> > Oliver! Did you need this or can we remove it?
> >
>
> I'll also have to make sure that the Android folks don't use it.
How then do we notify user space? poll()? Yet another demon.
I do not specifically need this, but I note that uevents are the
general tool we use to notify user space of that kind of events.
Regards
Oliver
Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
Hi Martyo< Does this confict with your patcho< If noto< I hope this could be merged first. Besides could you tell me the link to your related patch? Thanks, Pan On 2016/10/17 21:48, Arnd Bergmann wrote: > On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote: >> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5. >> >> Signed-off-by: Pan Wen >> > > Looks ok. I've added Marty Plummer to Cc, he was recently proposing > patches for Hi3520, which I think is closely related to this one. > Please try to work together so the patches don't conflict. It should > be fairly straightforward since you are basically doing the same > change here. > > Arnd > > . >
[PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped
We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
under kdump, it can be steadily reproduced on several different machines,
the dmesg log is like:
HP HPSA Driver (v 3.4.16-0)
hpsa :02:00.0: using doorbell to reset controller
hpsa :02:00.0: board ready after hard reset.
hpsa :02:00.0: Waiting for controller to respond to no-op
DMAR: Setting identity map for device :02:00.0 [0xe8000 - 0xe8fff]
DMAR: Setting identity map for device :02:00.0 [0xf4000 - 0xf4fff]
DMAR: Setting identity map for device :02:00.0 [0xbdf6e000 - 0xbdf6efff]
DMAR: Setting identity map for device :02:00.0 [0xbdf6f000 - 0xbdf7efff]
DMAR: Setting identity map for device :02:00.0 [0xbdf7f000 - 0xbdf82fff]
DMAR: Setting identity map for device :02:00.0 [0xbdf83000 - 0xbdf84fff]
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read] Request device [02:00.0] fault addr f000 [fault reason 06]
PTE Read access is not set
hpsa :02:00.0: controller message 03:00 timed out
hpsa :02:00.0: no-op failed; re-trying
After some debugging, we found that the corresponding pte entry value
is correct, and the value of the iommu caching mode is 0, the fault is
probably due to the old iotlb cache of the in-flight DMA.
Thus need to flush the old iotlb after context mapping is setup for the
device, where the device is supposed to finish reset at its driver probe
stage and no in-flight DMA exists hereafter.
With this patch, all our problematic machines can survive the kdump tests.
CC: Myron Stowe
CC: Don Brace
CC: Baoquan He
CC: Dave Young
Tested-by: Joseph Szczypek
Signed-off-by: Xunlei Pang
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3965e73..eb79288 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2067,9 +2067,16 @@ static int domain_context_mapping_one(struct dmar_domain
*domain,
* It's a non-present to present mapping. If hardware doesn't cache
* non-present entry we only need to flush the write-buffer. If the
* _does_ cache non-present entries, then it does so in the special
-* domain #0, which we have to flush:
+* domain #0, which we have to flush.
+*
+* For kdump cases, present entries may be cached due to the in-flight
+* DMA and copied old pgtable, but there is no unmapping behaviour for
+* them, so we need an explicit iotlb flush for the newly-mapped device.
+* For kdump, at this point, the device is supposed to finish reset at
+* the driver probe stage, no in-flight DMA will exist, thus we do not
+* need to worry about that anymore hereafter.
*/
- if (cap_caching_mode(iommu->cap)) {
+ if (is_kdump_kernel() || cap_caching_mode(iommu->cap)) {
iommu->flush.flush_context(iommu, 0,
(((u16)bus) << 8) | devfn,
DMA_CCMD_MASK_NOBIT,
--
1.8.3.1
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
* Greg KH wrote: > On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > > So what I'd love to see is to have a kernel option that re-introduces some > > historic root (and other) holes that can be exploited deterministically - > > obviously default disabled. > > Ick, I don't want to have to support nasty #ifdefs for > "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+ > years, do you? I'd write it in C, not CPP, so it would be an 'if', but yeah, it would be extra code otherwise. So I'd restrict this strictly to cases: - Where the maintainer absolutely agrees to carry it. - Where it's still easy to do technically - for example a single unobtrusive 'if' condition or so, in cases where the current upstream code still has a similar structure conductive to the re-introducion of the bug. Such testcases can be dropped the moment they interfere with active development. - Plus an additional approach could be that some of the typical holes can be reproduced in completely separate code that is not seen by anyone who doesn't want to see it. I doubt many bugs have 20 years life times in face of frequent code reorganization - and if code is static for 20 years then there won't be much extra maintenance overhead, right? > > I'd restrict this to reasonably 'deterministic' holes, and the exploits > > themselves > > could be somewhere in tools/. (Obviously only where the maintainers agree > > to host > > the code.) They wouldn't give a root shell, they'd only test whether they > > reached > > uid0 (or some other elevated privilege). > > Having exploits in tools/ would be good, I would like to see that, as > then we can ensure that we don't ever introduce old problems that we > have fixed again in the future. That I have no objection to. Heh, I actually guessed that this would be the more contentious part of my suggestion - go figure! ;-) Thanks, Ingo
[PATCH] net: ethernet: faraday: To support device tree usage.
To support device tree usage for ftmac100.
Signed-off-by: Greentime Hu
---
drivers/net/ethernet/faraday/ftmac100.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c
b/drivers/net/ethernet/faraday/ftmac100.c
index dce5f7b..81dd9e1 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id mac_of_ids[] = {
+ { .compatible = "andestech,atmac100" },
+ { }
+};
+
static struct platform_driver ftmac100_driver = {
.probe = ftmac100_probe,
.remove = __exit_p(ftmac100_remove),
.driver = {
.name = DRV_NAME,
+ .of_match_table = mac_of_ids
},
};
@@ -1200,3 +1206,4 @@ static void __exit ftmac100_exit(void)
MODULE_AUTHOR("Po-Yu Chuang ");
MODULE_DESCRIPTION("FTMAC100 driver");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, mac_of_ids);
--
1.7.9.5
[PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver
From: Ong Hean Loong
This patch enables the display port IP driver for
Intel Arria 10 SOCFPGA Golden Hardware
Reference Design (GHRD).
The driver requires enabling the options such as
Coheherent Memory Allocation,
Intel FPGA Frame Buffer, Frame Buffer Conasole
Signed-off-by: Ong Hean Loong
---
.../devicetree/bindings/video/intelfpgavipfb.txt | 22 ++
MAINTAINERS|6 +
drivers/video/fbdev/Kconfig| 15 +
drivers/video/fbdev/Makefile |1 +
drivers/video/fbdev/intelfpgavipfb.c | 302
5 files changed, 346 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/intelfpgavipfb.txt
create mode 100644 drivers/video/fbdev/intelfpgavipfb.c
diff --git a/Documentation/devicetree/bindings/video/intelfpgavipfb.txt
b/Documentation/devicetree/bindings/video/intelfpgavipfb.txt
new file mode 100644
index 000..8928c99
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/intelfpgavipfb.txt
@@ -0,0 +1,22 @@
+Intel FPGA Video and Image Processing(VIP) Frame Buffer bindings
+
+Required properties:
+- compatible: "intel,vip-frame-buffer2"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- max-width: The width of the framebuffer in pixels.
+- max-height: The height of the framebuffer in pixels.
+- bits-per-color: only "8" is currently supported
+- mem-word-width = the bus width of the avalon master port on the frame reader
+
+Example:
+
+alt_vip_vfr_0: vip@0xff26 {
+ compatible = "intel,vip-frame-buffer2";
+ reg = <0xff26 0x0080>;
+ max-width = <1024>;
+ max-height = <768>;
+ bits-per-color = <8>;
+ mem-word-width = <128>;
+};
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 4012c2f..bfc2687 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6314,6 +6314,12 @@ L: linux-fb...@vger.kernel.org
S: Maintained
F: drivers/video/fbdev/i810/
+INTEL FPGA FRAMEBUFFER DRIVER
+M: Ong, Hean Loong
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/intvipfb.c
+
INTEL MENLOW THERMAL DRIVER
M: Sujith Thomas
L: platform-driver-...@vger.kernel.org
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5d3b0db..5c9d674 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -228,6 +228,21 @@ config FB_TILEBLITTING
comment "Frame buffer hardware drivers"
depends on FB
+config FB_INTEL_FPGA_VIP
+ tristate "Intel FPGA VIP framebuffer support"
+ depends on FB
+ select CMA
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FRAMEBUFFER_CONSOLE
+ select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
+ ---help---
+ The FB_INTEL_FPGA_VIP driver supports the formerly Altera Video and
Image Processing(VIP)
+ Frame Buffer II. Requires CONFIG_CMA and Frame Buffer Console to
+ be enabled as well. The driver currently only supports ARRIA 10 board
from the Intel
+ FPGA Reference Design board family.
+
config FB_GRVGA
tristate "Aeroflex Gaisler framebuffer support"
depends on FB && SPARC
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index ee8c814..6c30549 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_FB_MACMODES) += macmodes.o
obj-$(CONFIG_FB_WMT_GE_ROPS) += wmt_ge_rops.o
# Hardware specific drivers go first
+obj-$(CONFIG_FB_INTEL_FPGA_VIP) += intelfpgavipfb.o
obj-$(CONFIG_FB_AMIGA)+= amifb.o c2p_planar.o
obj-$(CONFIG_FB_ARC) += arcfb.o
obj-$(CONFIG_FB_CLPS711X)+= clps711x-fb.o
diff --git a/drivers/video/fbdev/intelfpgavipfb.c
b/drivers/video/fbdev/intelfpgavipfb.c
new file mode 100644
index 000..9f5ca26
--- /dev/null
+++ b/drivers/video/fbdev/intelfpgavipfb.c
@@ -0,0 +1,302 @@
+/*
+ * Copyright (C) 2016 Intel Corporation. All rights reserved
+ *
+ * intelfpgavipfb.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This is based on a driver made by Thomas Chou and
+ * Winteler Goossens This driver supports the
+ * Intel VIP Frame Buffer II component. More info on the hardware can be
+ * found in the Intel Video and Image Processing Suite User Guide at
+ * http://www.intelera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A P
Re: [PATCH v12 3/3] drm/fence: add out-fences support
On Tue, Nov 15, 2016 at 10:06:41PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Support DRM out-fences by creating a sync_file with a fence for each CRTC
> that sets the OUT_FENCE_PTR property.
>
> We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> the sync_file fd back to userspace.
>
> The sync_file and fd are allocated/created before commit, but the
> fd_install operation only happens after we know that commit succeed.
>
> v2: Comment by Rob Clark:
> - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
> Comment by Daniel Vetter:
> - Add clean up code for out_fences
>
> v3: Comments by Daniel Vetter:
> - create DRM_MODE_ATOMIC_EVENT_MASK
> - userspace should fill out_fences_ptr with the crtc_ids for which
> it wants fences back.
>
> v4: Create OUT_FENCE_PTR properties and remove old approach.
>
> v5: Comments by Brian Starkey:
> - Remove extra fence_get() in atomic_ioctl()
> - Check ret before iterating on the crtc_state
> - check ret before fd_install
> - set fence_state to NULL at the beginning
> - check fence_state->out_fence_ptr before put_user()
> - change order of fput() and put_unused_fd() on failure
>
> - Add access_ok() check to the out_fence_ptr received
> - Rebase after fence -> dma_fence rename
> - Store out_fence_ptr in the drm_atomic_state
> - Split crtc_setup_out_fence()
> - return -1 as out_fence with TEST_ONLY flag
>
> v6: Comments by Daniel Vetter
> - Add prepare/unprepare_crtc_signaling()
> - move struct drm_out_fence_state to drm_atomic.c
> - mark get_crtc_fence() as static
>
> Comments by Brian Starkey
> - proper set fence_ptr fence_state array
> - isolate fence_idx increment
>
> - improve error handling
>
> v7: Comments by Daniel Vetter
> - remove prefix from internal functions
> - make out_fence_ptr an s64 pointer
> - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
> - fix doc issues
> - filter out OUT_FENCE_PTR == NULL and do not fail in this case
> - add complete_crtc_signalling()
> - krealloc fence_state on demand
>
> Comment by Brian Starkey
> - remove unused crtc_state arg from get_out_fence()
>
> v8: Comment by Brian Starkey
> - cancel events before check for !fence_state
> - convert a few lefovers u64 types for out_fence_ptr
> - fix memleak by assign fence_state earlier after realloc
> - proper accout num_fences in case of error
>
> v9: Comment by Brian Starkey
> - memset last position of fence_state after krealloc
> Comments by Sean Paul
> - pass install_fds in complete_crtc_signaling() instead of ret
>
> - put_user(-1, fence_ptr) when decoding props
>
> v10: Comment by Brian Starkey
> - remove unneeded num_fences increment on error path
> - kfree fence_state after installing fences fd
>
> v11: rebase against latest drm-misc
>
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Brian Starkey
> Tested-by: Robert Foss
> ---
> drivers/gpu/drm/drm_atomic.c | 241
> +++
> drivers/gpu/drm/drm_crtc.c | 8 ++
> include/drm/drm_atomic.h | 1 +
> include/drm/drm_crtc.h | 6 ++
> 4 files changed, 211 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3ad780a..d4a92a9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
> +static void set_out_fence_for_crtc(struct drm_atomic_state *state,
> +struct drm_crtc *crtc, s64 __user *fence_ptr)
> +{
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
> +}
> +
> +static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
> +struct drm_crtc *crtc)
> +{
> + s64 __user *fence_ptr;
> +
> + fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
> + state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
> +
> + return fence_ptr;
> +}
> +
> /**
> * drm_atomic_set_mode_for_crtc - set mode for CRTC
> * @state: the CRTC whose incoming state to update
> @@ -494,6 +511,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == config->prop_out_fence_ptr) {
> + s64 __user *fence_ptr = u64_to_user_ptr(val);
> +
> + if (!fence_ptr)
> + return 0;
> +
> + if (put_user(-1, fence_ptr))
> + return -EFAULT;
> +
> + set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> } else
Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped
Ccing David
On 2016/11/16 at 17:02, Xunlei Pang wrote:
> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
> under kdump, it can be steadily reproduced on several different machines,
> the dmesg log is like:
> HP HPSA Driver (v 3.4.16-0)
> hpsa :02:00.0: using doorbell to reset controller
> hpsa :02:00.0: board ready after hard reset.
> hpsa :02:00.0: Waiting for controller to respond to no-op
> DMAR: Setting identity map for device :02:00.0 [0xe8000 - 0xe8fff]
> DMAR: Setting identity map for device :02:00.0 [0xf4000 - 0xf4fff]
> DMAR: Setting identity map for device :02:00.0 [0xbdf6e000 - 0xbdf6efff]
> DMAR: Setting identity map for device :02:00.0 [0xbdf6f000 - 0xbdf7efff]
> DMAR: Setting identity map for device :02:00.0 [0xbdf7f000 - 0xbdf82fff]
> DMAR: Setting identity map for device :02:00.0 [0xbdf83000 - 0xbdf84fff]
> DMAR: DRHD: handling fault status reg 2
> DMAR: [DMA Read] Request device [02:00.0] fault addr f000 [fault reason
> 06] PTE Read access is not set
> hpsa :02:00.0: controller message 03:00 timed out
> hpsa :02:00.0: no-op failed; re-trying
>
> After some debugging, we found that the corresponding pte entry value
> is correct, and the value of the iommu caching mode is 0, the fault is
> probably due to the old iotlb cache of the in-flight DMA.
>
> Thus need to flush the old iotlb after context mapping is setup for the
> device, where the device is supposed to finish reset at its driver probe
> stage and no in-flight DMA exists hereafter.
>
> With this patch, all our problematic machines can survive the kdump tests.
>
> CC: Myron Stowe
> CC: Don Brace
> CC: Baoquan He
> CC: Dave Young
> Tested-by: Joseph Szczypek
> Signed-off-by: Xunlei Pang
> ---
> drivers/iommu/intel-iommu.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3965e73..eb79288 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -2067,9 +2067,16 @@ static int domain_context_mapping_one(struct
> dmar_domain *domain,
>* It's a non-present to present mapping. If hardware doesn't cache
>* non-present entry we only need to flush the write-buffer. If the
>* _does_ cache non-present entries, then it does so in the special
> - * domain #0, which we have to flush:
> + * domain #0, which we have to flush.
> + *
> + * For kdump cases, present entries may be cached due to the in-flight
> + * DMA and copied old pgtable, but there is no unmapping behaviour for
> + * them, so we need an explicit iotlb flush for the newly-mapped device.
> + * For kdump, at this point, the device is supposed to finish reset at
> + * the driver probe stage, no in-flight DMA will exist, thus we do not
> + * need to worry about that anymore hereafter.
>*/
> - if (cap_caching_mode(iommu->cap)) {
> + if (is_kdump_kernel() || cap_caching_mode(iommu->cap)) {
> iommu->flush.flush_context(iommu, 0,
> (((u16)bus) << 8) | devfn,
> DMA_CCMD_MASK_NOBIT,
[PATCH] gpio: max77620: add compatible string to device id list
From: Venkat Reddy Talla
Adding max20024 compatible string to the device id list
to support both max77620 and max20024 devices.
Signed-off-by: Venkat Reddy Talla
---
drivers/gpio/gpio-max77620.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-max77620.c b/drivers/gpio/gpio-max77620.c
index b46b436..7bb2f11 100644
--- a/drivers/gpio/gpio-max77620.c
+++ b/drivers/gpio/gpio-max77620.c
@@ -296,6 +296,7 @@ static int max77620_gpio_probe(struct platform_device *pdev)
static const struct platform_device_id max77620_gpio_devtype[] = {
{ .name = "max77620-gpio", },
+ { .name = "max20024-gpio", },
{},
};
MODULE_DEVICE_TABLE(platform, max77620_gpio_devtype);
--
2.1.4
Re: [PATCH] mfd: core: fix device reference leak in mfd_clone_cell
On Mon, Nov 14, 2016 at 06:25:01PM +, Lee Jones wrote:
> On Tue, 01 Nov 2016, Johan Hovold wrote:
>
> > Make sure to drop the reference taken by bus_find_device_by_name()
> > before returning from mfd_clone_cell().
> >
> > Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
> > Signed-off-by: Johan Hovold
> > ---
> > drivers/mfd/mfd-core.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> Applied, thanks.
I do not see this one in linux-next (or your tree). Did you forget to
push?
Thanks,
Johan
Re: [PATCH v7 0/6] perf annotate: Cross arch support + few fixes
On 2016/09/21 09:17PM, Ravi Bangoria wrote: > Currently Perf annotate support code navigation (branches and calls) > only when run on the same architecture where perf.data was recorded. > But, for example, record on powerpc server and annotate on client's > x86 desktop is not supported. > > This patchset adds supports for that. > > Example: > > Record on powerpc: > $ ./perf record -a > > Report -> Annotate on x86: > $ ./perf report -i perf.data.powerpc --vmlinux vmlinux.powerpc Hi Arnaldo, Can you please take this in for v4.10? We'd very much like to use this for better code annotation and browsing. FWIW, I have tested this on powerpc. Tested-by: Naveen N. Rao Thanks, Naveen
Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
On Tuesday 15 November 2016 04:30 PM, Bartosz Golaszewski wrote: > Add the nodes for the MSTPRI configuration and DDR2/mDDR memory > controller drivers to da850.dtsi. > > Signed-off-by: Bartosz Golaszewski Applied to v4.10/dt Thanks, Sekhar
Re: [PATCH 1/2] ovl: use kernel facility for copying attributes
On Tue, Nov 15, 2016 at 5:54 PM, Quorum Laval wrote: > Replace ovl_copyattr() by fsstack_copy_attr_all() and drop the definition of > the former. This isn't trivially correct, fsstack_copy_attr_all() copies more than ovl_copyattr(). We need a better explanation for why it is correct to copy all the other attributes as well. Thanks, Miklos
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Wed, Nov 16, 2016 at 10:07:37AM +0100, Ingo Molnar wrote: > > * Greg KH wrote: > > > On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > > > So what I'd love to see is to have a kernel option that re-introduces > > > some > > > historic root (and other) holes that can be exploited deterministically - > > > obviously default disabled. > > > > Ick, I don't want to have to support nasty #ifdefs for > > "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+ > > years, do you? > > I'd write it in C, not CPP, so it would be an 'if', but yeah, it would be > extra > code otherwise. > > So I'd restrict this strictly to cases: > > - Where the maintainer absolutely agrees to carry it. > > - Where it's still easy to do technically - for example a single unobtrusive >'if' condition or so, in cases where the current upstream code still has a >similar structure conductive to the re-introducion of the bug. Such > testcases >can be dropped the moment they interfere with active development. > > - Plus an additional approach could be that some of the typical holes can be >reproduced in completely separate code that is not seen by anyone who > doesn't >want to see it. Ok, but in looking at a number of "security" fixes over the past year or so, I don't think that many of them would really work well for this. Just look at all of the "don't reference a NULL pointer" bugs for an example of that. > I doubt many bugs have 20 years life times in face of frequent code > reorganization > - and if code is static for 20 years then there won't be much extra > maintenance > overhead, right? Hah, you obviously are not in charge of maintaining the tty layer :) Anyway, if you want to try this for the next type of security "issue" in your area of the kernel, be my guest, but I think it's going to be a lot harder than you think. thanks, greg k-h
Re: [PATCH 2/2] ovl: use kernel facility for updating access time
On Tue, Nov 15, 2016 at 5:54 PM, Quorum Laval wrote: > Use fsstack_copy_attr_atime() instead of direct assignement. This one's correct, but what's the point? Thanks, Miklos
[tip:ras/core] x86/mce/AMD: Reset Threshold Limit after logging error
Commit-ID: 18807ddb7f88d4ac3797302bafb18143d573e66f
Gitweb: http://git.kernel.org/tip/18807ddb7f88d4ac3797302bafb18143d573e66f
Author: Yazen Ghannam
AuthorDate: Tue, 15 Nov 2016 15:13:53 -0600
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 09:57:11 +0100
x86/mce/AMD: Reset Threshold Limit after logging error
The error count field in MCA_MISC does not get reset by hardware when the
threshold has been reached. Software is expected to reset it. Currently,
the threshold limit only gets reset during init or when a user writes to
sysfs.
If the user is not monitoring threshold interrupts and resetting
the limit then the user will only see 1 interrupt when the limit is first
hit. So if, for example, the limit is set to 10 then only 1 interrupt will
be recorded after 10 errors even if 100 errors have occurred. The user may
then assume that only 10 errors have occurred.
Signed-off-by: Yazen Ghannam
Cc: Aravind Gopalakrishnan
Cc: linux-edac
Cc: x86-ml
Link:
http://lkml.kernel.org/r/1479244433-69267-1-git-send-email-yazen.ghan...@amd.com
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index e68a305..5b33702 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -665,6 +665,7 @@ static void amd_threshold_interrupt(void)
{
u32 low = 0, high = 0, address = 0;
unsigned int bank, block, cpu = smp_processor_id();
+ struct thresh_restart tr;
/* assume first bank caused it */
for (bank = 0; bank < mca_cfg.banks; ++bank) {
@@ -701,6 +702,11 @@ static void amd_threshold_interrupt(void)
log:
__log_error(bank, false, true, ((u64)high << 32) | low);
+
+ /* Reset threshold block after logging error. */
+ memset(&tr, 0, sizeof(tr));
+ tr.b = &per_cpu(threshold_banks, cpu)[bank]->blocks[block];
+ threshold_restart_bank(&tr);
}
/*
Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support
Hi,
John Youn writes:
> On 11/14/2016 3:00 PM, John Youn wrote:
>> On 11/11/2016 3:12 PM, Christian Lamparter wrote:
>>> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
On 11/11/2016 2:05 PM, Christian Lamparter wrote:
> On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
>> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
>>> This patch adds support for the "amcc,usb-otg" device
>>> which is found in the PowerPC Canyonlands' dts.
>>>
>>> The device definition was added by:
>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
>>> board")'
>>> but without any driver support as the dwc2 driver wasn't
>>> available at that time.
>>>
>>> Note: The system can't use the generic "snps,dwc2" compatible
>>> because of the special ahbcfg configuration. The default
>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>> when the USB and SATA is used concurrently.
>>
>> I don't want to add any more of these param structures to the driver
>> unless really necessary. We're trying to remove usage of them in favor
>> of using auto-detected defaults and device properties to override
>> them.
> Ok, thanks. I think that would work. I've attached an updated patch.
> Can it be applied/queued now? Or do you want me to resent it later?
>
>> The AHB Burst is actually one of the ones we were going to do next
>> because our platform also doesn't work well with INCR4. In fact I'm
>> thinking of making the default INCR.
> Is that actually possible to change the default still? This would
> require to re-evaluate all existing archs/platforms that use
> "snps,dwc2" for INCR16 compatibility.
INCR, not INCR16, but you're right, so we may not change it even
though though INCR is usually the right choice over INCR4.
>>> What about making a device-tree property?
>>
>> Yes, that's what I meant. I'll send a change for this shortly.
>>
>>>
>>> Recommended properties:
>>> - g-ahb-bursts : specifies the ahb bursts length, should be one of
>>>"single", "INCRx", "INCR4", "INCR8", or "INCR16". If not specified
>>>the safer but inefficient "INCR4" is used. The optimal setting is
>>>"INCRx".
>>>
>>> Would this work? If so, I can make a patch over the weekend.
Anyways, with the binding, can't you just set the compatible string to
snps,dwc2?
>>>
>>> Ah, let me explain. I had a discussion with Mark Rutland and Rob Herring
>>> a while back about device-tree bindings.
>>>
>>> They made it very clear to me, that they don't want any generic "catch all
>>> compatible" strings:
>>>
>>> "Bindings should be for hardware (either specific device models, or for
>>> classes), and not for Linux drivers. The latter is subject to arbitrary
>>> changes while the former is not, as old hardware continues to exist and
>>> does not change while drivers get completely reworked." [0]
>>>
>>> Furthermore, this is an existing binding in kernel's canyonlands.dts [1]
>>> and this binding can't be easily changed. Rob Herring explained this in
>>> the context of the "basic-mmio-gpio" patch [2] when I was editing the dts
>>> to make them work with the changes I made:
>>>
>>> "You can't remove the old drivers as they are needed to work with
>>> old dtbs, so there is no gain.
>>>
>>> You would need to match on existing compatibles such as
>>> moxa,moxart-gpio and provide a match data struct that has all the info
>>> you are adding here (e.g. data register offset). Then additionally you
>>> could add "basic-mmio-gpio" (I would drop "basic" part) and the
>>> additional data associated with it. But it has to be new properties,
>>> not changing properties. Changing the reg values doesn't work."
>>>
>>> So, for this to work with the existing canyonlands.dts, I need to have
>>> the "amcc,dwc-otg" compatible string.
>>
>> Ok, if that's the case. But still a bit confused as to what driver was
>> working with it before since the binding was not defined for dwc2.
>>
>>>
>>> Of course, it would be great to hear from Rob Herring and/or Mark Rutland
>>> about this case.
>>>
>>> Regards,
>>> Christian
>>>
>>> [0]
>>> [2]
>>>
>>>
>
> From what I can tell based would be:
> bcm11351, bcm21664, bcm23550, exynos3250, stm32f429, rk3xxx,
> stratix10, meson-gxbb, rt3050 and some Altera FPGAs.
>
>> If that's all you need then a devicetree binding should be enough
>> right?
> Yes. The device is working fine so far.
>
> Regards,
> Christian
>
> ---
> From 70dd4be016b89655a56bc8260f04683b50f07644 Mon Sep 17 00:00:00 2001
> From: Christian Lamparter
> Date: Sun, 6 Nov 2016 00:39:24 +0100
> Subject: [PATCH] usb: dwc2: add a
Re: [Patch v7 3/7] irqchip: xilinx: restructure and use jump label api
On 15.11.2016 17:03, Zubair Lutfullah Kakakhel wrote:
> Hi,
>
> On 11/15/2016 12:49 PM, Michal Simek wrote:
>> On 14.11.2016 13:13, Zubair Lutfullah Kakakhel wrote:
>>> Add a global structure to house various variables.
>>> And cleanup read/write handling by using jump label api.
>>>
>>> Signed-off-by: Zubair Lutfullah Kakakhel
>>>
>
> ...
>
>>> @@ -138,59 +136,75 @@ static const struct irq_domain_ops
>>> xintc_irq_domain_ops = {
>>> static int __init xilinx_intc_of_init(struct device_node *intc,
>>> struct device_node *parent)
>>> {
>>> -u32 nr_irq, intr_mask;
>>> +u32 nr_irq;
>>> int ret;
>>> +struct xintc_irq_chip *irqc;
>>>
>>> -intc_baseaddr = of_iomap(intc, 0);
>>> -BUG_ON(!intc_baseaddr);
>>> +if (xintc_irqc) {
>>> +pr_err("irq-xilinx: Multiple instances aren't supported\n");
>>> +return -EINVAL;
>>> +}
>>
>> I don't agree with this.
>> Pretty long time ago we were added support for multiple instances in
>> xilinx private tree.
>> You can look here.
>>
>> https://github.com/Xilinx/linux-xlnx/blob/master/drivers/irqchip/irq-xilinx-intc.c
>>
>>
>> Not sure if this the latest way how to do it but as you can see
>> we were setting up
>> irq_set_handler_data(irq, intc);
>>
>> and then when you need that structure we were calling
>> struct intc *local_intc = irq_data_get_irq_chip_data(d);
>>
>> And that should be it to support multiple instance of this driver.
>>
>> Based on 5/7 you are describing your interrupt subsystem like this.
>>
>> Peripherals --> xilinx_intcontroller -> mips_cpu_int controller
>> If mips_cpu_int has more than one input you can connect more xilinx intc
>> controllers.
>> If not you still have an option to connect
>> xilinx_intcontroller(up to 32 peripherals) -> xilinx_intcontroller(one
>> intc + up to 31 peripherals) -> mips_cpu_int controller
>
> That configuration in FPGA is technically possible. Although not
> done/needed in the
> way we use the Xilinx Interrupt Controller IP block in MIPSfpga.
>
> This series takes the drivers out of arch code and makes it accessible.
> Any further development on the driver would be common to all architectures.
> Support for multiple instances would be a 'new feature'.
>
> I say this as this series keeps growing and mutating in terms of its scope
> and work.
fair enough - it can be added in separate patch.
>
> Would it be possible to ack this so that the restructure out of arch code
> can move forward?
I have tested the whole series on Microblaze and I can't see any problem
in running it there.
That's why
Tested-by; Michal Simek
If everything is right needs to be checked by irqchip experts.
Thanks,
Michal
[PATCH v4] tools/power/acpi: Remove direct kernel source include reference
ACPICA tools trickily uses integer types, and trickily includes kernel
include directory directly, which breaks tools build for some cross
compilers.
This patch improves ACPICA tools build to make it a bit more robust in such
situation by splitting include/acpi into a separate output directory.
This patch also contains OUTPUT/srctree cleanups in order to make above fix
working for various build environments.
Fixes: e323c02dee59 ("ACPICA: MSVC9: Fix inclusion order issue")
Reported-and-tested-by: Yisheng Xie
Reported-by: Andy Shevchenko
Signed-off-by: Lv Zheng
Cc: Andy Shevchenko
---
include/acpi/platform/aclinux.h | 3 +++
tools/power/acpi/Makefile.config | 23 +-
tools/power/acpi/Makefile.rules | 40 +---
tools/power/acpi/tools/acpidbg/Makefile | 4 +---
tools/power/acpi/tools/acpidbg/acpidbg.c | 8 ++-
tools/power/acpi/tools/acpidump/Makefile | 12 +-
6 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index a5d98d1..e861a24 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -191,6 +191,9 @@
#ifndef __init
#define __init
#endif
+#ifndef __iomem
+#define __iomem
+#endif
/* Host-dependent types and defines for user-space ACPICA */
diff --git a/tools/power/acpi/Makefile.config b/tools/power/acpi/Makefile.config
index a538ff4..a1883bb 100644
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -8,18 +8,19 @@
# as published by the Free Software Foundation; version 2
# of the License.
-include ../../../../scripts/Makefile.include
-
-OUTPUT=./
-ifeq ("$(origin O)", "command line")
- OUTPUT := $(O)/
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+#$(info Determined 'srctree' to be $(srctree))
endif
-ifneq ($(OUTPUT),)
-# check that the output directory actually exists
-OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
-$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
+include $(srctree)/../../scripts/Makefile.include
+
+OUTPUT=$(srctree)/
+ifeq ("$(origin O)", "command line")
+ OUTPUT := $(O)/power/acpi/
endif
+#$(info Determined 'OUTPUT' to be $(OUTPUT))
# --- CONFIGURATION BEGIN ---
@@ -70,8 +71,8 @@ WARNINGS := -Wall
WARNINGS += $(call cc-supports,-Wstrict-prototypes)
WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
-KERNEL_INCLUDE := ../../../include
-ACPICA_INCLUDE := ../../../drivers/acpi/acpica
+KERNEL_INCLUDE := $(OUTPUT)include
+ACPICA_INCLUDE := $(srctree)/../../../drivers/acpi/acpica
CFLAGS += -D_LINUX -I$(KERNEL_INCLUDE) -I$(ACPICA_INCLUDE)
CFLAGS += $(WARNINGS)
diff --git a/tools/power/acpi/Makefile.rules b/tools/power/acpi/Makefile.rules
index ec87a9e..3737383 100644
--- a/tools/power/acpi/Makefile.rules
+++ b/tools/power/acpi/Makefile.rules
@@ -8,28 +8,42 @@
# as published by the Free Software Foundation; version 2
# of the License.
-$(OUTPUT)$(TOOL): $(TOOL_OBJS) FORCE
- $(ECHO) " LD " $@
- $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(TOOL_OBJS) -L$(OUTPUT) -o $@
+objdir := $(OUTPUT)tools/$(TOOL)/
+toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
+$(OUTPUT)$(TOOL): $(toolobjs) FORCE
+ $(ECHO) " LD " $(subst $(OUTPUT),,$@)
+ $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
+ $(ECHO) " STRIP " $(subst $(OUTPUT),,$@)
$(QUIET) $(STRIPCMD) $@
-$(OUTPUT)%.o: %.c
- $(ECHO) " CC " $@
+$(KERNEL_INCLUDE):
+ $(ECHO) " MKDIR " $(subst $(OUTPUT),,$@)
+ $(QUIET) mkdir -p $(KERNEL_INCLUDE)
+ $(ECHO) " CP " $(subst $(OUTPUT),,$@)
+ $(QUIET) cp -rf $(srctree)/../../../include/acpi $(KERNEL_INCLUDE)/
+
+$(objdir)%.o: %.c $(KERNEL_INCLUDE)
+ $(ECHO) " CC " $(subst $(OUTPUT),,$@)
$(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
all: $(OUTPUT)$(TOOL)
clean:
- -find $(OUTPUT) \( -not -type d \) \
- -and \( -name '*~' -o -name '*.[oas]' \) \
- -type f -print \
-| xargs rm -f
- -rm -f $(OUTPUT)$(TOOL)
+ $(ECHO) " RMOBJ " $(subst $(OUTPUT),,$(objdir))
+ $(QUIET) find $(objdir) \( -not -type d \)\
+-and \( -name '*~' -o -name '*.[oas]' \)\
+-type f -print | xargs rm -f
+ $(ECHO) " RM " $(TOOL)
+ $(QUIET) rm -f $(OUTPUT)$(TOOL)
+ $(ECHO) " RMINC " $(subst $(OUTPUT),,$(KERNEL_INCLUDE))
+ $(QUIET) rm -rf $(KERNEL_INCLUDE)
install-tools:
- $(INSTALL) -d $(DESTDIR)${sbindir}
- $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)${sbindir}
+ $(ECHO) " INST" $(TOOL)
+ $(QUIET) $(INSTALL) -d $(DESTDIR)$(sbindir)
+ $(QUIET) $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)$(sbindir)
uninstall-tools:
- - rm -f $(DESTDIR)${sbindir}/$(TOOL)
+ $(ECHO) " UNINST " $(TOOL)
+ $(QUIET) rm -
Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm
On Thu, Nov 10, 2016 at 12:56:14AM +0100, Rafael J. Wysocki wrote: > The idea, roughly, is that if there is a single on/off switch acting > on multiple devices, you can (a) set up a PM domain tracking all of > those device's runtime PM invocations and (b) maintaining a reference > counter of devices still not suspended. This way it would only turn > the switch off when all of the devices in question had been suspended. > Analogously, it would turn the switch on before resuming the first > device in the domain. Of course, that code isn't available as a > library, you would need to implement it (or use genpd, but chances are > it is too heavy weight for the job). My understanding is that the hierarchy of struct generic_pm_domain is created by the platform on boot. For an embedded platform, this is encoded in the device tree, but what about ACPI which doesn't know anything about struct generic_pm_domain? I would have to lump devices into generic_pm_domains after the fact, after the platform has scanned the buses, but this seems to be forbidden according to this slide deck, which calls that a "layering violation": https://events.linuxfoundation.org/images/stories/pdf/lcjp2012_wysocki.pdf (Quote: "Adding and Removing Devices [...] Supposed to be called by the platform (calling one of them from a device driver is a layering violation).") So it seems that using struct generic_pm_domain is never an option on ACPI, is that correct? Thanks, Lukas
Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
Hi Pan, On 2016/11/16 8:56, wenpan wrote: > Hi Marty， > Does this confict with your patch？ If not，I hope this could be merged first. > Besides could you tell me the link to your related patch? This is the link: https://patchwork.kernel.org/patch/9334743/ BR, Wei > > Thanks, > Pan > > On 2016/10/17 21:48, Arnd Bergmann wrote: >> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote: >>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5. >>> >>> Signed-off-by: Pan Wen >>> >> >> Looks ok. I've added Marty Plummer to Cc, he was recently proposing >> patches for Hi3520, which I think is closely related to this one. >> Please try to work together so the patches don't conflict. It should >> be fairly straightforward since you are basically doing the same >> change here. >> >> Arnd >> >> . >> > > > . >
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > Hi, > > At present I am using the uevent in the userspace to infer > the Presence of a port on the remote end through the > appearance of usbc*-partner. > > Userspace uses this info to decide on when to show a USB > notification on the screen and what should be the options > provided in the dialog. > > I was assuming that this is not something that would be dropped. > > Coding using events was relatively easier to program from userspace .. > > Is it possible to use POLL for identifying the appearance of port partner ? > I did not notice sysfs_notify call in typec_connect/typec_disconnect. > > It would also be nice to have uevent notifications when the contents > of current_data_role or current_power_role changes. > > Is that too costly to have ? Greg, could you give your opinion. In this case we do have attribute files that the user space can poll. Data role is the USB data role, so host or device, and it can change for example if the partner executes a swap. The same can happen with the power role. Thanks, -- heikki
Re: [RFC][PATCH 2/2] fsnotify: handle permission events without holding fsnotify_mark_srcu[0]
On Mon 14-11-16 17:09:47, Amir Goldstein wrote: > On Mon, Nov 14, 2016 at 3:20 PM, Jan Kara wrote: > > On Mon 14-11-16 13:48:27, Amir Goldstein wrote: > >> Handling fanotify events does not entail dereferencing fsnotify_mark > >> beyond the point of fanotify_should_send_event(). > >> > >> For the case of permission events, which may block indefinitely, > >> return -EAGAIN and then fsnotify() will call handle_event() again > >> without a reference to the mark. > >> > >> Without a reference to the mark, there is no need to call > >> handle_event() under fsnotify_mark_srcu[0] read side lock, > >> so we drop fsnotify_mark_srcu[0] while handling the event > >> and grab it back before continuing to the next mark. > >> > >> After this change, a blocking permission event will no longer > >> block closing of any file descriptors of 0 priority groups, > >> i.e: inotify and fanotify groups of class FAN_CLASS_NOTIF. > >> > >> Reported-by: Miklos Szeredi > >> Signed-off-by: Amir Goldstein > > > > Well, this has a similar problem as my attempt to fix the issue. The > > current mark can get removed from the mark list while waiting for userspace > > response. ->next pointer is still valid at that moment but ->next->pprev > > already points to mark preceding us (that's how rcu lists work). When > > ->next mark then gets removed from the list and destroyed (it may be > > protected by the second srcu), our ->next pointer points to freed memory. > > Oh! I missed the fact that the SRCU does not protect mark->obj_list. > Can resurrecting mark->free_list buy us anything? > Perhaps keep the marks on obj_list without FLAG_ATTACHED > and then remove marks from both free_list and obj_list post > srcu_synchronize()? > I think that removing mark->obj_list was optimization of good faith > and not because it really hurts the system's memory usage that much? You have to be really careful here. Minimally you'd need then another srcu_synchronize() call after removing mark from the list and before freeing the mark so that you are sure no process iterating the list can have a reference to a mark being freed but even then it needs careful checking whether it would work. The joy of lockless algorithms... > > I have some ideas how to fix up issues with my refcounting approach - > > refcount would pin marks not only in memory but also in lists but I have > > yet to see whether that works out sensibly (it would mean that dropping > > mark reference would then need to take group->mark_mutex and that may cause > > lock ordering issues). > > It sounds like a chicken and egg problem, but I suppose you don't mean > the actual mark refcount, but a secondary "pinned refcount"? No, I mean the original refcount. I have patches that already postpone part of the mark cleanup to happen only once the refcount drops to 0. > Anyway, if you have something ready, my test setup is already in place.. Thanks for an offer. I don't have anything yet, hopefully later today or tomorrow. Honza -- Jan Kara SUSE Labs, CR
[PATCH] drm/sun4i: Only count TCON endpoints as valid outputs
The sun4i DRM driver counts the number of endpoints it found and
registers the whole DRM pipeline if any endpoints are found.
However, if the TCON and its child endpoints (LCD panels, TV encoder,
HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
don't have any usable CRTCs, and the display pipeline is incomplete
and useless. The whole DRM display pipeline should only be registered
and enabled if there are proper outputs available.
The debug message "Queued %d outputs on pipeline %d\n" is also telling.
This patch makes the driver only count enabled TCON endpoints. If
none are found, the DRM pipeline is not used. This avoids screwing
up the simple framebuffer provided by the bootloader in cases where
we aren't able to support the display with the DRM subsystem, due
to lack of panel or bridge drivers, or just lack of progress.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai
---
Hi Maxime,
This avoids DRM screwing up simplefb on my SinA31s, which does not
have the display pipeline enabled in its dts file. But the display
engine and backend are already enabled in the dtsi.
I think this is a better and proper (for the driver) fix. The
alternative would be to disable the display-engine node in the dts
by default. Last time I asked you wanted to have them enabled by
default?
It may also be possible to push the check further down, and check
against panel and encoder endpoints, but I think that complicates
things. The TCON is a necessary part of the output.
ChenYu
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index c3b21865443e..3603f34901b6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -243,9 +243,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
DRM_DEBUG_DRIVER("Adding component %s\n",
of_node_full_name(node));
component_match_add(dev, match, compare_of, node);
- count++;
}
+ /* Only count the tcon as an output */
+ if (sun4i_drv_node_is_tcon(node))
+ count++;
+
/* Inputs are listed first, then outputs */
port = of_graph_get_port_by_id(node, 1);
if (!port) {
--
2.10.2
[PATCH] drm/sun4i: tcon: Initialize regmap after enabling bus clocks
If we attempt to read/write the TCON registers before the bus clock
is enabled, those accesses get ignored.
In practice this almost never occurs because U-boot had already enabled
the bus clock as part of its firmware provided framebuffer (simplefb).
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai
---
I was looking around the DRM driver and noticed this sequence was off.
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c6afb2448655..8c2db65ea229 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -506,16 +506,16 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return ret;
}
- ret = sun4i_tcon_init_regmap(dev, tcon);
+ ret = sun4i_tcon_init_clocks(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON regmap\n");
+ dev_err(dev, "Couldn't init our TCON clocks\n");
goto err_assert_reset;
}
- ret = sun4i_tcon_init_clocks(dev, tcon);
+ ret = sun4i_tcon_init_regmap(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON clocks\n");
- goto err_assert_reset;
+ dev_err(dev, "Couldn't init our TCON regmap\n");
+ goto err_free_clocks;
}
ret = sun4i_tcon_init_irq(dev, tcon);
--
2.10.2
[PATCH v2] iio: magnetometer: separate the values of attributes based on their usage type for HID compass sensor
There are 2 usage types (Magnetic Flux and Heading data field) for HID
compass sensor, thus the values of offset, scale, and sensitivity should
be separated according to their respective usage type. The changes made
are as below:
1. Hysteresis: A struct hid_sensor_common rot_attributes is created in
struct magn_3d_state to contain the sensitivity for IIO_ROT.
2. Scale: scale_pre_decml and scale_post_decml are separated for IIO_MAGN
and IIO_ROT.
3. Offset: Same as scale, value_offset is separated for IIO_MAGN and
IIO_ROT.
For sensitivity, HID_USAGE_SENSOR_ORIENT_MAGN_FLUX and
HID_USAGE_SENSOR_ORIENT_MAGN_HEADING are used for sensivitity fields based
on the HID Sensor Usages specifications. Hence, these changes are added on
the sensitivity field.
Signed-off-by: Ooi, Joyce
---
changelog v2:
* rename struct hid_sensor_common common_attributes to struct
hid_sensor_common magn_flux_attributes.
* create a common_attributes struct which stores scale_pre_decml,
scale_post_decml, scale_precision, and value_offset.
* create struct hid_sensor_common magn_flux_attributes and rot_attributes
for IIO_MAGN and IIO_ROT respectively.
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 147 --
1 file changed, 112 insertions(+), 35 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index d8a0c8d..0e791b0 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -42,9 +42,17 @@ enum magn_3d_channel {
MAGN_3D_CHANNEL_MAX,
};
+struct common_attributes {
+ int scale_pre_decml;
+ int scale_post_decml;
+ int scale_precision;
+ int value_offset;
+};
+
struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
- struct hid_sensor_common common_attributes;
+ struct hid_sensor_common magn_flux_attributes;
+ struct hid_sensor_common rot_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
/* dynamically sized array to hold sensor values */
@@ -52,10 +60,8 @@ struct magn_3d_state {
/* array of pointers to sensor value */
u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
- int scale_pre_decml;
- int scale_post_decml;
- int scale_precision;
- int value_offset;
+ struct common_attributes magn_flux_attr;
+ struct common_attributes rot_attr;
};
static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
@@ -162,41 +168,74 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
*val2 = 0;
switch (mask) {
case 0:
- hid_sensor_power_state(&magn_state->common_attributes, true);
+ hid_sensor_power_state(&magn_state->magn_flux_attributes, true);
report_id =
magn_state->magn[chan->address].report_id;
address = magn_3d_addresses[chan->address];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
- magn_state->common_attributes.hsdev,
+ magn_state->magn_flux_attributes.hsdev,
HID_USAGE_SENSOR_COMPASS_3D, address,
report_id,
SENSOR_HUB_SYNC);
else {
*val = 0;
- hid_sensor_power_state(&magn_state->common_attributes,
- false);
+ hid_sensor_power_state(
+ &magn_state->magn_flux_attributes,
+ false);
return -EINVAL;
}
- hid_sensor_power_state(&magn_state->common_attributes, false);
+ hid_sensor_power_state(&magn_state->magn_flux_attributes,
+ false);
ret_type = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
- *val = magn_state->scale_pre_decml;
- *val2 = magn_state->scale_post_decml;
- ret_type = magn_state->scale_precision;
+ switch (chan->type) {
+ case IIO_MAGN:
+ *val = magn_state->magn_flux_attr.scale_pre_decml;
+ *val2 = magn_state->magn_flux_attr.scale_post_decml;
+ ret_type = magn_state->magn_flux_attr.scale_precision;
+ break;
+ case IIO_ROT:
+ *val = magn_state->rot_attr.scale_pre_decml;
+ *val2 = magn_state->rot_attr.scale_post_decml;
+ ret_type = magn_state->rot_attr.scale_precision;
+ break;
+ default:
+ ret_type = -EINVAL;
+ }
break;
case IIO_CHAN_INFO_OFFSE
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, 2016-11-16 at 11:30 +0200, Heikki Krogerus wrote: > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > Is that too costly to have ? > > Greg, could you give your opinion. In this case we do have attribute > files that the user space can poll. Data role is the USB data role, so > host or device, and it can change for example if the partner executes > a swap. The same can happen with the power role. IMHO the uevent is cheaper. User space cannot just poll without further infrastructure. A task needs to run to poll. A uevent can be handled through established infrastructure. Sure from a kernel level it is the heavier gun, but I think this is the wrong angle of looking at this issue. Regards Oliver
[PATCH] platform: asus-nb-wmi: Make use of dmi->ident
as other drives also do, like fujitsu, intel, hp and samsung.
Signed-off-by: Marcos Paulo de Souza
---
drivers/platform/x86/asus-nb-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 26e4cbc..c3abfc8 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -118,6 +118,7 @@ static struct quirk_entry quirk_asus_ux303ub = {
static int dmi_matched(const struct dmi_system_id *dmi)
{
+ pr_info("Identified laptop model '%s'\n", dmi->ident);
quirks = dmi->driver_data;
return 1;
}
--
2.7.4
[tip:locking/core 12/12] drivers/gpu/drm/i915/i915_gem_shrinker.c:230:2: warning: 'mutex_trylock_recursive' is deprecated
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
head: 0f5225b024d4bffd682aab008c35862e8fdc1865
commit: 0f5225b024d4bffd682aab008c35862e8fdc1865 [12/12] locking/mutex, drm:
Introduce mutex_trylock_recursive()
config: i386-randconfig-a0-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 0f5225b024d4bffd682aab008c35862e8fdc1865
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem_shrinker.c: In function
'i915_gem_shrinker_lock':
>> drivers/gpu/drm/i915/i915_gem_shrinker.c:230:2: warning:
>> 'mutex_trylock_recursive' is deprecated [-Wdeprecated-declarations]
switch (mutex_trylock_recursive(&dev->struct_mutex)) {
^~
In file included from arch/x86/include/asm/mmu.h:5:0,
from include/linux/mm_types.h:17,
from include/linux/sched.h:27,
from include/linux/oom.h:5,
from drivers/gpu/drm/i915/i915_gem_shrinker.c:25:
include/linux/mutex.h:215:1: note: declared here
mutex_trylock_recursive(struct mutex *lock)
^~~
vim +/mutex_trylock_recursive +230 drivers/gpu/drm/i915/i915_gem_shrinker.c
214 */
215 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv)
216 {
217 unsigned long freed;
218
219 freed = i915_gem_shrink(dev_priv, -1UL,
220 I915_SHRINK_BOUND |
221 I915_SHRINK_UNBOUND |
222 I915_SHRINK_ACTIVE);
223 rcu_barrier(); /* wait until our RCU delayed slab frees are
completed */
224
225 return freed;
226 }
227
228 static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
229 {
> 230 switch (mutex_trylock_recursive(&dev->struct_mutex)) {
231 case MUTEX_TRYLOCK_FAILED:
232 return false;
233
234 case MUTEX_TRYLOCK_SUCCESS:
235 *unlock = true;
236 return true;
237
238 case MUTEX_TRYLOCK_RECURSIVE:
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATHCv10 1/2] usb: USB Type-C connector class
On Wed, Nov 16, 2016 at 11:30:35AM +0200, Heikki Krogerus wrote: > On Tue, Nov 15, 2016 at 04:19:10PM -0800, Badhri Jagan Sridharan wrote: > > Hi, > > > > At present I am using the uevent in the userspace to infer > > the Presence of a port on the remote end through the > > appearance of usbc*-partner. > > > > Userspace uses this info to decide on when to show a USB > > notification on the screen and what should be the options > > provided in the dialog. > > > > I was assuming that this is not something that would be dropped. > > > > Coding using events was relatively easier to program from userspace .. > > > > Is it possible to use POLL for identifying the appearance of port partner ? > > I did not notice sysfs_notify call in typec_connect/typec_disconnect. > > > > It would also be nice to have uevent notifications when the contents > > of current_data_role or current_power_role changes. > > > > Is that too costly to have ? > > Greg, could you give your opinion. In this case we do have attribute > files that the user space can poll. Data role is the USB data role, so > host or device, and it can change for example if the partner executes > a swap. The same can happen with the power role. So the same 'struct device' switches roles and attribute files are updated that need to be re-read? If so, yes KOBJ_CHANGE is correct, if a struct device is added/removed for this, then no, it doesn't make sense. Again, document this to describe what is happening and it might be more obvious to people and so these questions would not come up :) thanks, greg k-h
[PATCH v5] pwm: add pwm driver for HiSilicon BVT SOCs
From: yuanjian
Add PWM driver for the PWM controller found on HiSilicon BVT SOCs, like
Hi3519V100, Hi3516CV300, etc.
The PWM controller is primarily in charge of controlling P-Iris lens.
Reviewed-by: Jiancheng Xue
Signed-off-by: Jian Yuan
---
Change Log:
v5:
remove the generic compatible string "hisilicon, hibvt-pwm".
v4:
Add #pwm-cells in the bindings document.
v3:
fixed issues pointed by thierry.
Add PWM compatible string for Hi3519V100.
Implement .apply() function which support atomic, instead of
.enable()/.disable()/.config().
v2:
The number of PWMs is change to be probeable based on the compatible string.
.../devicetree/bindings/pwm/pwm-hibvt.txt | 22 ++
drivers/pwm/Kconfig| 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-hibvt.c| 269 +
4 files changed, 301 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
create mode 100644 drivers/pwm/pwm-hibvt.c
diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
new file mode 100644
index 000..fe63950
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
@@ -0,0 +1,22 @@
+Hisilicon PWM controller
+
+Required properties:
+-compatible: should contain one SoC specific compatible string
+ The SoC specific strings supported including:
+ "hisilicon,hi3516cv300-pwm"
+ "hisilicon,hi3519v100-pwm"
+- reg: physical base address and length of the controller's registers.
+- clocks: phandle and clock specifier of the PWM reference clock.
+- resets: phandle and reset specifier for the PWM controller reset.
+- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
+ the cells format.
+
+Example:
+ pwm: pwm@1213 {
+
+ compatible = "hisilicon,hi3516cv300-pwm";
+ reg = <0x1213 0x1>;
+ clocks = <&crg_ctrl HI3516CV300_PWM_CLK>;
+ resets = <&crg_ctrl 0x38 0>;
+ #pwm-cells = <2>;
+ };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc..b2d7408 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -158,6 +158,15 @@ config PWM_FSL_FTM
To compile this driver as a module, choose M here: the module
will be called pwm-fsl-ftm.
+config PWM_HIBVT
+ tristate "HiSilicon BVT PWM support"
+ depends on ARCH_HISI || COMPILE_TEST
+ help
+ Generic PWM framework driver for HiSilicon BVT SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-hibvt.
+
config PWM_IMG
tristate "Imagination Technologies PWM driver"
depends on HAS_IOMEM
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc1..37ec39e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PWM_CLPS711X)+= pwm-clps711x.o
obj-$(CONFIG_PWM_CRC) += pwm-crc.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
+obj-$(CONFIG_PWM_HIBVT)+= pwm-hibvt.o
obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
new file mode 100644
index 000..feadb3d
--- /dev/null
+++ b/drivers/pwm/pwm-hibvt.c
@@ -0,0 +1,269 @@
+/*
+ * PWM Controller Driver for HiSilicon BVT SoCs
+ *
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
Hi Joerg,
On Mon, Nov 14, 2016 at 06:25:16PM +, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce new dependencies on
> >> them. Besides, as it stands, this patch literally implements "tell the
> >> iommu-core which hardware-iommus exist in the system and a seperate
> >> iommu_ops ptr for each of them" straight off.
> >
> > Not sure which code you are looking at, but as I see it we have only
> > per-device iommu-ops now (with this patch). That is different from
> > having core-visible hardware-iommu instances where devices could link
> > to.
>
> The per-device IOMMU ops are already there since 57f98d2f61e1. This
> patch generalises the other end, moving the "registering an IOMMU
> instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
> OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
> iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
> such if that makes the design intent clearer.
I can easily make the changes Robin suggests above, I need to know
what to do with this patch it is the last blocking point for this
series and time is running out I can revert to using dev->bus to
retrieve iommu_ops (even though I do not think it makes sense given
what Robin outlines below) but I need to know please, we can't gate
an entire series for this patch that is just syntactic sugar.
Thanks !
Lorenzo
> If you'd also prefer to replace iommu_fwspec::ops with an opaque
> iommu_fwspec::iommu_instance pointer so that things are a bit more
> centralised (and users are forced to go through the API rather then call
> ops directly), I'd have no major objection either. My main point is that
> we've been deliberately putting the relevant building blocks in place -
> the of_iommu_{get,set}_ops stuff was designed from the start to
> accommodate per-instance ops, via the ops pointer *being* the instance
> token; the iommu_fwspec stuff is deliberately intended to provide
> per-device ops on top of that. The raw functionality is either there in
> iommu.c already, or moving there in patches already written, so if it
> doesn't look right all we need to focus on is making it look right.
>
> > Also the rest of iommu-core code still makes use of the per-bus ops. The
> > per-device ops are only used for the of_xlate fn-ptr.
>
> Hence my aforementioned patches intended for 4.10, directly following on
> from introducing iommu_fwspec in 4.9:
>
> http://www.mail-archive.com/iommu@lists.linux-foundation.org/msg14576.html
>
> ...the purpose being to provide a smooth transition from per-bus ops to
> per-device, per-instance ops. Apply those and we're 90% of the way there
> for OF-based IOMMU drivers (not that any of those actually need
> per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
> ago, but it didn't seem worth the bother). Lorenzo's series broadens the
> scope to ACPI-based systems and moves the generically-useful parts into
> the core where we can easily build on them further if necessary. The
> major remaining work is to convert external callers of the current
> bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
> to device-based alternatives.
>
> Robin.
Re: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
On 11/15/2016 06:39 AM, Sriram Dash wrote:
>> From: Scott Wood
>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> new file mode 100644
>>> index 000..d934c80
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> @@ -0,0 +1,36 @@
>>> +Driver for Freescale USB 3.0 PHY
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : fsl,qoriq-usb3-phy
>>
>
> Hi Scott,
>
>> This is a very vague compatible. Are there versioning registers within this
>> register
>> block?
>>
>
> There are versioning registers for the phy (1.0 and 1.1). But the current
> erratum
> A008751 does not require the mentioning of the version numbers. Was planning
> to take care of the versioning when there is code diversity on the basis of
> the
> version number.
That is not how device tree bindings work. The describe the hardware,
not the driver.
That said, is the block version sufficient to tell whether a given chip
has this erratum? If so, you don't need a special property for the
erratum. If not, what is different about the PHY that is not described
by the versioning?
In any case, it would be nice to mention the version register and its
offset in the binding, just so that it becomes part of the definition of
this compatible string, and if we come out with some QorIQ chip with a
USB3 PHY that is totally different and doesn't have that version
register, it'll be clear that it needs a different compatible.
>>> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
>>> +offset) {
>>> + return __raw_readl(addr + offset);
>>> +}
>>> +
>>> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
>>> + u32 data)
>>> +{
>>> + __raw_writel(data, addr + offset);
>>> +}
>>
>> Why raw? Besides missing barriers, this will cause the accesses to be
>> native-endian
>> which is not correct.
>>
>
> The only reason for __raw_writel is to make the code faster.
Does that really matter here?
> However, shall I use writel(with both barriers and byte swap) instead
Yes, if the registers are little-endian on all chips.
> and then make appropriate changes in the value 32'h27672B2A?
Not sure what you mean here.
> In my knowledge, there are more than 5 errata in pipeline,
Then please get all of these errata described in the device tree ASAP
(unless their presence can be reliably inferred from the block version,
as discussed above).
> However, in future, if any other erratum comes up, and it has to be applied
> at any point other than during init, then the variable has to be added in
> qoriq_usb3_phy struct and the property has to be read separately.
Or if the erratum is detected by some means other than a device tree
property...
-Scott
Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
On Tue, 2016-11-15 at 09:03 -0800, Florian Fainelli wrote: > On 11/15/2016 08:30 AM, Andrew Lunn wrote: > > > > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote: > > > > > > On some platforms, energy efficient ethernet with rtl8211 devices > > > is > > > causing issue, like throughput drop or broken link. > > > > > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the > > > issue root > > > cause is not fully understood yet, disabling EEE advertisement > > > prevent auto > > > negotiation from enabling EEE. > > > > > > This patch provides options to disable 1000T and 100TX EEE > > > advertisement > > > individually for the realtek phys supporting this feature. > > > > Looking at the code, i don't see anything specific to RealTek > > here. This all seems generic. So should it be in phy.c and made a > > generic OF property which can be applied to any PHY which supports > > EEE. > > Agreed. Good point, Thanks for pointing this out. > Just to be sure, Jerome, you did verify that with EEE no longer > advertised, ethtool --set-eee fails, right? The point is that you may > be > able to disable EEE on boot, but if there is a way to re-enable it > later > on, we would want to disable that too. I was focused on getting the issue out of way I did not think that someone could try something like this :) I just tried and it is possible to re-enable eee, though it is not simplest thing to do: using ethtool enable eee advertisement, enable eee, restart the autonegotiation without bringing the interface down (otherwise the phy config kicks and disable eee again). I reckon this is not good and I need to address this. There two kind of PHYs supporting eee, the one advertising eee by default (like realtek) and the one not advertising it (like micrel). If the property is going to be generic, I see two options and I'd like your view on this: 1) The DT provided value could be seen as "preferred" (or boot setting), which can be cleanly changed with ethtool later on. In this case, I guess I need to provide a way to force eee advertisement as well to be consistent. 2) The DT provided value could forbid the advertisement of eee. In this case I need to return an error if ethtool tries to re-enable it. Phy with eee advertisement off by default (and not forbidden) would still need to activate it manually with ethtool after boot. I don't see why someone would absolutely want eee activated at boot time so I guess this is OK. Do you have a preference ? Thanks for this quick feedback ! Cheers Jerome
Re: [PATCH] mxs-auart: count FIFO overrun errors
On Tue, Nov 15, 2016 at 12:05:29PM +0100, Wolfgang Ocker wrote: > The mxs-auart driver does not count FIFO overrun errors. These errors never > appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is > masked by read_status_mask in the rx interrupt function, but the > AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the > counting of overrun errors. > > Signed-off-by: Wolfgang Ocker > --- > drivers/tty/serial/mxs-auart.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c > index 770454e0dfa3..8c1c9112b3fd 100644 > --- a/drivers/tty/serial/mxs-auart.c > +++ b/drivers/tty/serial/mxs-auart.c > @@ -1016,7 +1016,7 @@ static void mxs_auart_settermios(struct uart_port *u, > ctrl |= AUART_LINECTRL_EPS; > } > > - u->read_status_mask = 0; > + u->read_status_mask = AUART_STAT_OERR; > > if (termios->c_iflag & INPCK) > u->read_status_mask |= AUART_STAT_PERR; > -- > 2.10.0 This patch is corrupted and can not be applied, what did you do here? Please fix up and resend. thanks, greg k-h
Re: [PATCH] mfd: core: fix device reference leak in mfd_clone_cell
On Wed, 16 Nov 2016, Johan Hovold wrote:
> On Mon, Nov 14, 2016 at 06:25:01PM +, Lee Jones wrote:
> > On Tue, 01 Nov 2016, Johan Hovold wrote:
> >
> > > Make sure to drop the reference taken by bus_find_device_by_name()
> > > before returning from mfd_clone_cell().
> > >
> > > Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
> > > Signed-off-by: Johan Hovold
> > > ---
> > > drivers/mfd/mfd-core.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > Applied, thanks.
>
> I do not see this one in linux-next (or your tree). Did you forget to
> push?
Since I tend to flit between maintaining and real-work, I tend to bulk
push once I have a bunch of fixes/updates. Your fix should appear in
-next tomorrow. The plan is to have it in upstream by next week.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 02/11] hisi_sas: alloc queue id of slot according to device id
On 16/11/2016 01:41, Zhangfei Gao wrote: On Mon, Nov 7, 2016 at 8:48 PM, John Garry wrote: From: Xiang Chen Currently slots are allocated from queues in a round-robin fashion. This causes a problem for internal commands in device mode. For this mode, we should ensure that the internal abort command is the last command seen in the host for that device. We can only ensure this when we place the internal abort command after the preceding commands for device that in the same queue, as there is no order in which the host will select a queue to execute the next command. Is there performance penalty, since only one queue is supported for a device. Hi Zhangfei, From testing I have not seen any noteable performance change. However, please note the comment on mq, below. Cheers, John This queue restriction makes supporting scsi mq more tricky in the future, but should not be a blocker. Note: Even though v1 hw does not support internal abort, the allocation method is chosen to be the same for consistency. Signed-off-by: Xiang Chen Signed-off-by: John Garry Reviewed-by: Zhangfei Gao -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html .
[PATCH net-next v6] cadence: Add LSO support.
New Cadence GEM hardware support Large Segment Offload (LSO):
TCP segmentation offload (TSO) as well as UDP fragmentation
offload (UFO). Support for those features was added to the driver.
---
Changed in v2:
macb_lso_check_compatibility() changed to macb_features_check()
(with little modifications) and bind to .ndo_features_check.
(after Eric Dumazet suggestion)
---
Changed in v3:
Respin to net-next.
---
Changed in v4:
(struct iphdr*)skb_network_header(skb) changed to ip_hdr(skb)
---
Changed in v5:
Changes after Florian Fainelli comments
---
Changes in v6:
UDP checksum zeroing removed. There is no need to zeroing
UDP checksum during UFO operation.
Signed-off-by: Rafal Ozieblo
---
drivers/net/ethernet/cadence/macb.c | 138
drivers/net/ethernet/cadence/macb.h | 14
2 files changed, 140 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index e1847ce..654b5bf 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -32,7 +32,9 @@
#include
#include
#include
-
+#include
+#include
+#include
#include "macb.h"
#define MACB_RX_BUFFER_SIZE128
@@ -60,10 +62,13 @@
| MACB_BIT(TXERR))
#define MACB_TX_INT_FLAGS (MACB_TX_ERR_FLAGS | MACB_BIT(TCOMP))
-#define MACB_MAX_TX_LEN((unsigned int)((1 <<
MACB_TX_FRMLEN_SIZE) - 1))
-#define GEM_MAX_TX_LEN ((unsigned int)((1 << GEM_TX_FRMLEN_SIZE) - 1))
+/* Max length of transmit frame must be a multiple of 8 bytes */
+#define MACB_TX_LEN_ALIGN 8
+#define MACB_MAX_TX_LEN((unsigned int)((1 <<
MACB_TX_FRMLEN_SIZE) - 1) & ~((unsigned int)(MACB_TX_LEN_ALIGN - 1)))
+#define GEM_MAX_TX_LEN ((unsigned int)((1 << GEM_TX_FRMLEN_SIZE) - 1)
& ~((unsigned int)(MACB_TX_LEN_ALIGN - 1)))
#define GEM_MTU_MIN_SIZE ETH_MIN_MTU
+#define MACB_NETIF_LSO (NETIF_F_TSO | NETIF_F_UFO)
#define MACB_WOL_HAS_MAGIC_PACKET (0x1 << 0)
#define MACB_WOL_ENABLED (0x1 << 1)
@@ -1223,7 +1228,8 @@ static void macb_poll_controller(struct net_device *dev)
static unsigned int macb_tx_map(struct macb *bp,
struct macb_queue *queue,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ unsigned int hdrlen)
{
dma_addr_t mapping;
unsigned int len, entry, i, tx_head = queue->tx_head;
@@ -1231,14 +1237,27 @@ static unsigned int macb_tx_map(struct macb *bp,
struct macb_dma_desc *desc;
unsigned int offset, size, count = 0;
unsigned int f, nr_frags = skb_shinfo(skb)->nr_frags;
- unsigned int eof = 1;
- u32 ctrl;
+ unsigned int eof = 1, mss_mfs = 0;
+ u32 ctrl, lso_ctrl = 0, seq_ctrl = 0;
+
+ /* LSO */
+ if (skb_shinfo(skb)->gso_size != 0) {
+ if (ip_hdr(skb)->protocol == IPPROTO_UDP)
+ /* UDP - UFO */
+ lso_ctrl = MACB_LSO_UFO_ENABLE;
+ else
+ /* TCP - TSO */
+ lso_ctrl = MACB_LSO_TSO_ENABLE;
+ }
/* First, map non-paged data */
len = skb_headlen(skb);
+
+ /* first buffer length */
+ size = hdrlen;
+
offset = 0;
while (len) {
- size = min(len, bp->max_tx_length);
entry = macb_tx_ring_wrap(bp, tx_head);
tx_skb = &queue->tx_skb[entry];
@@ -1258,6 +1277,8 @@ static unsigned int macb_tx_map(struct macb *bp,
offset += size;
count++;
tx_head++;
+
+ size = min(len, bp->max_tx_length);
}
/* Then, map paged data from fragments */
@@ -1311,6 +1332,21 @@ static unsigned int macb_tx_map(struct macb *bp,
desc = &queue->tx_ring[entry];
desc->ctrl = ctrl;
+ if (lso_ctrl) {
+ if (lso_ctrl == MACB_LSO_UFO_ENABLE)
+ /* include header and FCS in value given to h/w */
+ mss_mfs = skb_shinfo(skb)->gso_size +
+ skb_transport_offset(skb) +
+ ETH_FCS_LEN;
+ else /* TSO */ {
+ mss_mfs = skb_shinfo(skb)->gso_size;
+ /* TCP Sequence Number Source Select
+* can be set only for TSO
+*/
+ seq_ctrl = 0;
+ }
+ }
+
do {
i--;
entry = macb_tx_ring_wrap(bp, i);
@@ -1325,6 +1361,16 @@ static unsigned int macb_tx_map(struct macb *bp,
if (unlikely(entry == (bp->tx_ring_size - 1)))
ctrl |= MACB_BIT(TX_WRAP);
+ /* First descriptor is header descriptor */
+ if (i == queue->tx_h
Re: [PATCH] edac: mpc85xx: implement "remove" for mpc85xx_pci_err_driver
On Wed, Nov 16, 2016 at 02:26:14PM +0800, yanjiang@windriver.com wrote: > From: Yanjiang Jin > > Tested on a T4240QDS board. > > If we execute the below steps without this patch: > > 1. modprobe mpc85xx_edac [The first insmod, everything is well.] > 2. modprobe -r mpc85xx_edac > 3. modprobe mpc85xx_edac [insmod again, error happens.] > > We would get the below error: Looks ok to me, I'd let the people who are more knowledgeable of mpc85xx_edac chime in here... > BUG: recent printk recursion! > Oops: Kernel access of bad area, sig: 11 [#48] > PREEMPT SMP NR_CPUS=24 CoreNet Generic > Modules linked in: mpc85xx_edac edac_core softdog [last unloaded: > mpc85xx_edac] > CPU: 5 PID: 14773 Comm: modprobe Tainted: G D C 4.8.3-rt2 > task: c005cdc40d40 task.stack: c005c8814000 > NIP: c05c5b60 LR: c05c895c CTR: c05c8940 > REGS: c005c8816e20 TRAP: 0300 Tainted: G D C > (4.8.3-rt2-WR9.0.0.0_preempt-rt) > MSR: 80029000 CR: 28222828 XER: 2000 > DEAR: 805392d8 ESR: 0100 SOFTE: 0 > GPR00: c05c8844 c005c88170a0 c11db400 c1220496 > GPR04: c1220838 c1220838 04ff000a 805392d8 > GPR08: c05cb400 c05c8940 fffe 804c9108 > GPR12: c0bdad80 c0003fff7300 fff1 c0d1c7f0 > GPR16: 0001 003f c005c8817c20 c0bed4e0 > GPR20: c11fdaa0 0002 804ccafe > GPR24: c005c8817390 0025 c1220458 0020 > GPR28: 03e0 c1220838 804ccafe c1220496 > NIP [c05c5b60] .string+0x20/0xa0 > LR [c05c895c] .vsnprintf+0x1ac/0x490 > Call Trace: > [c005c88170a0] [c05c8844] .vsnprintf+0x94/0x490 (unreliable) > [c005c8817170] [c05c8c58] .vscnprintf+0x18/0x70 > [c005c88171f0] [c00d5920] .vprintk_emit+0x120/0x600 > [c005c88172c0] [c0bdae44] .printk+0xc4/0xe0 > [c005c8817340] [804c6f5c] .edac_pci_add_device+0x2fc/0x350 > [edac_core] > [c005c88173e0] [80759d64] .mpc85xx_pci_err_probe+0x344/0x550 > [mpc85xx_edac] > [c005c88174c0] [c06952b4] .platform_drv_probe+0x84/0x120 > [c005c8817550] [c0692294] .driver_probe_device+0x2f4/0x3d0 > [c005c88175f0] [c069248c] .__driver_attach+0x11c/0x120 > [c005c8817680] [c068f034] .bus_for_each_dev+0x94/0x100 > [c005c8817720] [c0691624] .driver_attach+0x34/0x50 > [c005c88177a0] [c0690e88] .bus_add_driver+0x1b8/0x310 > [c005c8817840] [c0693404] .driver_register+0x94/0x170 > [c005c88178c0] [c06954b0] .__platform_register_drivers+0xa0/0x150 > [c005c8817980] [8075b51c] .mpc85xx_mc_init+0x60/0xd0 > [mpc85xx_edac] > [c005c8817a00] [c0001a68] .do_one_initcall+0x68/0x1e0 > [c005c8817ae0] [c0bdb2e8] .do_init_module+0x88/0x24c > [c005c8817b80] [c011961c] .load_module+0x1e3c/0x2840 > [c005c8817d20] [c011a320] .SyS_finit_module+0x100/0x130 > [c005c8817e30] [c698] system_call+0x38/0xe8 > Instruction dump: > 4ba71abd 6000 7214 4b20 2ba50fff 7ca72b78 7cca0734 7c852378 > 40dd0030 2faa 394a 41de0014 <8907> 38e70001 2fa8 40fe002c > ---[ end trace 0031 ]--- ... but please send a v2 without all those hex addresses and offsets as they're completely meaningless outside of your kernel. I.e., something like: Call Trace: .vsnprintf .vscnprintf .vprintk_emit .printk ... is much more readable. The registers above are not really useful too. I think you should leave only the gist of the oops so that it is recognizable by others. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] mfd: core: fix device reference leak in mfd_clone_cell
On Wed, Nov 16, 2016 at 09:59:44AM +, Lee Jones wrote:
> On Wed, 16 Nov 2016, Johan Hovold wrote:
>
> > On Mon, Nov 14, 2016 at 06:25:01PM +, Lee Jones wrote:
> > > On Tue, 01 Nov 2016, Johan Hovold wrote:
> > >
> > > > Make sure to drop the reference taken by bus_find_device_by_name()
> > > > before returning from mfd_clone_cell().
> > > >
> > > > Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
> > > > Signed-off-by: Johan Hovold
> > > > ---
> > > > drivers/mfd/mfd-core.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > >
> > > Applied, thanks.
> >
> > I do not see this one in linux-next (or your tree). Did you forget to
> > push?
>
> Since I tend to flit between maintaining and real-work, I tend to bulk
> push once I have a bunch of fixes/updates. Your fix should appear in
> -next tomorrow. The plan is to have it in upstream by next week.
Sounds good, thanks for the explanation.
Johan
[PATCH] block: deal with stale req count of plug list
In both legacy and mq path, req count of plug list is computed
before allocating request, so the number can be stale when falling
back to slept allocation, also the new introduced wbt can sleep
too.
This patch deals with the case by checking if plug list becomes
empty, and fixes the KASAN report of 'BUG: KASAN: stack-out-of-bounds'
which is introduced by Shaohua's patches of dispatching big request.
Fixes: 600271d92(blk-mq: immediately dispatch big size request)
Fixes: 50d24c34403c6(block: immediately dispatch big size request)
Cc: Shaohua Li
Signed-off-by: Ming Lei
---
block/blk-core.c | 5 -
block/blk-mq.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index eea246567884..473dd698effd 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1753,8 +1753,11 @@ static blk_qc_t blk_queue_bio(struct request_queue *q,
struct bio *bio)
/*
* If this is the first request added after a plug, fire
* of a plug trace.
+*
+* @request_count may become stale because of schedule
+* out, so check plug list again.
*/
- if (!request_count)
+ if (!request_count || list_empty(&plug->list))
trace_block_plug(q);
else {
struct request *last = list_entry_rq(plug->list.prev);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index ae8df5ec20d3..f39e69c732cc 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1497,6 +1497,13 @@ static blk_qc_t blk_sq_make_request(struct request_queue
*q, struct bio *bio)
struct request *last = NULL;
blk_mq_bio_to_request(rq, bio);
+
+ /*
+* @request_count may become stale because of schedule
+* out, so check the list again.
+*/
+ if (list_empty(&plug->mq_list))
+ request_count = 0;
if (!request_count)
trace_block_plug(q);
else
--
2.7.4
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Tue, Nov 15, 2016 at 12:53:35PM -0800, Kees Cook wrote:
>
> What should we do about things like this (bpf_prog_put() and callbacks
> from kernel/bpf/syscall.c):
>
>
> static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> {
> struct user_struct *user = prog->aux->user;
>
> atomic_long_sub(prog->pages, &user->locked_vm);
> free_uid(user);
> }
>
> static void __bpf_prog_put_rcu(struct rcu_head *rcu)
> {
> struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux,
> rcu);
>
> free_used_maps(aux);
> bpf_prog_uncharge_memlock(aux->prog);
> bpf_prog_free(aux->prog);
> }
>
> void bpf_prog_put(struct bpf_prog *prog)
> {
> if (atomic_dec_and_test(&prog->aux->refcnt))
> call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
> }
>
>
> Not only do we want to protect prog->aux->refcnt, but I think we want
> to protect user->locked_vm too ... I don't think it's sane for
> user->locked_vm to be a stats_t ?
Why would you want to mess with locked_vm? You seem of the opinion that
everything atomic_t is broken, this isn't the case.
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Wed, Nov 16, 2016 at 09:21:51AM +0100, Greg KH wrote:
> > What should we do about things like this (bpf_prog_put() and callbacks
> > from kernel/bpf/syscall.c):
> >
> >
> > static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> > {
> > struct user_struct *user = prog->aux->user;
> >
> > atomic_long_sub(prog->pages, &user->locked_vm);
>
> Oh that's scary. Let's just make one reference count rely on another
> one and not check things...
Its not a reference count, its a resource limit thingy. Also, isn't
stacking, or in general building an object graph, the entire point of
reference counts?
> > free_uid(user);
> > }
> >
> > static void __bpf_prog_put_rcu(struct rcu_head *rcu)
> > {
> > struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux,
> > rcu);
> >
> > free_used_maps(aux);
> > bpf_prog_uncharge_memlock(aux->prog);
> > bpf_prog_free(aux->prog);
> > }
> >
> > void bpf_prog_put(struct bpf_prog *prog)
> > {
> > if (atomic_dec_and_test(&prog->aux->refcnt))
> > call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
> > }
> >
> >
> > Not only do we want to protect prog->aux->refcnt, but I think we want
> > to protect user->locked_vm too ... I don't think it's sane for
> > user->locked_vm to be a stats_t ?
>
> I don't think this is sane code...
I once again fail to see any problems. That code is fine.
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On 11/16/2016 09:21 AM, Greg KH wrote:
On Tue, Nov 15, 2016 at 12:53:35PM -0800, Kees Cook wrote:
On Tue, Nov 15, 2016 at 12:03 AM, Peter Zijlstra wrote:
On Tue, Nov 15, 2016 at 08:33:22AM +0100, Greg KH wrote:
On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote:
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -520,7 +520,7 @@ static void mod_rq_state(struct drbd_req
/* Completion does it's own kref_put. If we are going to
* kref_sub below, we need req to be still around then. */
int at_least = k_put + !!c_put;
- int refcount = atomic_read(&req->kref.refcount);
+ int refcount = kref_read(&req->kref);
if (refcount < at_least)
drbd_err(device,
"mod_rq_state: Logic BUG: %x -> %x: refcount = %d, should
be >= %d\n",
As proof of "things you should never do", here is one such example.
ugh.
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -767,7 +767,7 @@ static void virtblk_remove(struct virtio
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
- refc = atomic_read(&disk_to_dev(vblk->disk)->kobj.kref.refcount);
+ refc = kref_read(&disk_to_dev(vblk->disk)->kobj.kref);
put_disk(vblk->disk);
vdev->config->del_vqs(vdev);
kfree(vblk->vqs);
And this too, ugh, that's a huge abuse and is probably totally wrong...
thanks again for digging through this crap. I wonder if we need to name
the kref reference variable "do_not_touch_this_ever" or some such thing
to catch all of the people who try to be "too smart".
There's unimaginable bong hits involved in this stuff, in the end I
resorted to brute force and scripts to convert all this.
What should we do about things like this (bpf_prog_put() and callbacks
from kernel/bpf/syscall.c):
Just reading up on this series. Your question refers to converting bpf
prog and map ref counts to Peter's refcount_t eventually, right?
static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
{
struct user_struct *user = prog->aux->user;
atomic_long_sub(prog->pages, &user->locked_vm);
Oh that's scary. Let's just make one reference count rely on another
one and not check things...
Sorry, could you elaborate what you mean by 'check things', you mean for
wrap around? IIUC, back then accounting was roughly similar modeled after
perf event's one, and in this case accounts for pages used by progs and
maps during their life-time. Are you suggesting that this approach is
inherently broken?
free_uid(user);
}
static void __bpf_prog_put_rcu(struct rcu_head *rcu)
{
struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
free_used_maps(aux);
bpf_prog_uncharge_memlock(aux->prog);
bpf_prog_free(aux->prog);
}
void bpf_prog_put(struct bpf_prog *prog)
{
if (atomic_dec_and_test(&prog->aux->refcnt))
call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
}
Not only do we want to protect prog->aux->refcnt, but I think we want
to protect user->locked_vm too ... I don't think it's sane for
user->locked_vm to be a stats_t ?
I don't think this is sane code...
greg k-h
[tip:locking/core 12/12] drivers/gpu/drm/msm/msm_gem_shrinker.c:23:2: warning: 'mutex_trylock_recursive' is deprecated
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
head: 0f5225b024d4bffd682aab008c35862e8fdc1865
commit: 0f5225b024d4bffd682aab008c35862e8fdc1865 [12/12] locking/mutex, drm:
Introduce mutex_trylock_recursive()
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0f5225b024d4bffd682aab008c35862e8fdc1865
# save the attached .config to linux build tree
make.cross ARCH=arm64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'msm_gem_shrinker_lock':
>> drivers/gpu/drm/msm/msm_gem_shrinker.c:23:2: warning:
>> 'mutex_trylock_recursive' is deprecated [-Wdeprecated-declarations]
switch (mutex_trylock_recursive(&dev->struct_mutex)) {
^~
In file included from include/linux/notifier.h:13:0,
from include/linux/clk.h:17,
from drivers/gpu/drm/msm/msm_drv.h:22,
from drivers/gpu/drm/msm/msm_gem_shrinker.c:18:
include/linux/mutex.h:215:1: note: declared here
mutex_trylock_recursive(struct mutex *lock)
^~~
vim +/mutex_trylock_recursive +23 drivers/gpu/drm/msm/msm_gem_shrinker.c
7 * the Free Software Foundation.
8 *
9 * This program is distributed in the hope that it will be useful, but
WITHOUT
10 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
11 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
12 * more details.
13 *
14 * You should have received a copy of the GNU General Public License
along with
15 * this program. If not, see
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > > * Kees Cook wrote: > > > On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra > > wrote: > > > > > > > > > On 15 November 2016 19:06:28 CET, Kees Cook wrote: > > > > > >>I'll want to modify this in the future; I have a config already doing > > >>"Bug on data structure corruption" that makes the warn/bug choice. > > >>It'll need some massaging to fit into the new refcount_t checks, but > > >>it should be okay -- there needs to be a way to complete the > > >>saturation, etc, but still kill the offending process group. > > > > > > Ideally we'd create a new WARN like construct that continues in kernel > > > space > > > and terminates the process on return to user. That way there would be > > > minimal > > > kernel state corruption. > > Yeah, so the problem is that sometimes you are p0wned the moment you return > to a > corrupted stack, and some of these checks only detect corruption after the > fact. So the case here is about refcounts, with the saturation semantics we avoid the use-after-free case which is all this is about. So actually continuation of execution is harmless vs the attack vector in question. Corrupting the stack is another attack vector, one that refcount overflow is entirely unrelated to and not one I think we should consider here. The problem with BUG and insta killing the task is that refcounts are typically done under locks, if you kill the task before the unlock, you've wrecked kernel state in unrecoverable ways.
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Wed, Nov 16, 2016 at 11:10:42AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 16, 2016 at 09:21:51AM +0100, Greg KH wrote:
> > > What should we do about things like this (bpf_prog_put() and callbacks
> > > from kernel/bpf/syscall.c):
> > >
> > >
> > > static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> > > {
> > > struct user_struct *user = prog->aux->user;
> > >
> > > atomic_long_sub(prog->pages, &user->locked_vm);
> >
> > Oh that's scary. Let's just make one reference count rely on another
> > one and not check things...
>
> Its not a reference count, its a resource limit thingy. Also, isn't
> stacking, or in general building an object graph, the entire point of
> reference counts?
Ah, that wasn't obvious, but yes, you are correct here, sorry for the
noise.
greg k-h
Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Wed, Nov 16, 2016 at 11:11:43AM +0100, Daniel Borkmann wrote:
> On 11/16/2016 09:21 AM, Greg KH wrote:
> > On Tue, Nov 15, 2016 at 12:53:35PM -0800, Kees Cook wrote:
> > > On Tue, Nov 15, 2016 at 12:03 AM, Peter Zijlstra
> > > wrote:
> > > > On Tue, Nov 15, 2016 at 08:33:22AM +0100, Greg KH wrote:
> > > > > On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote:
> > > >
> > > > > > --- a/drivers/block/drbd/drbd_req.c
> > > > > > +++ b/drivers/block/drbd/drbd_req.c
> > > > > > @@ -520,7 +520,7 @@ static void mod_rq_state(struct drbd_req
> > > > > > /* Completion does it's own kref_put. If we are going
> > > > > > to
> > > > > > * kref_sub below, we need req to be still around
> > > > > > then. */
> > > > > > int at_least = k_put + !!c_put;
> > > > > > - int refcount = atomic_read(&req->kref.refcount);
> > > > > > + int refcount = kref_read(&req->kref);
> > > > > > if (refcount < at_least)
> > > > > > drbd_err(device,
> > > > > > "mod_rq_state: Logic BUG: %x -> %x:
> > > > > > refcount = %d, should be >= %d\n",
> > > > >
> > > > > As proof of "things you should never do", here is one such example.
> > > > >
> > > > > ugh.
> > > > >
> > > > > > --- a/drivers/block/virtio_blk.c
> > > > > > +++ b/drivers/block/virtio_blk.c
> > > > > > @@ -767,7 +767,7 @@ static void virtblk_remove(struct virtio
> > > > > > /* Stop all the virtqueues. */
> > > > > > vdev->config->reset(vdev);
> > > > > >
> > > > > > - refc =
> > > > > > atomic_read(&disk_to_dev(vblk->disk)->kobj.kref.refcount);
> > > > > > + refc = kref_read(&disk_to_dev(vblk->disk)->kobj.kref);
> > > > > > put_disk(vblk->disk);
> > > > > > vdev->config->del_vqs(vdev);
> > > > > > kfree(vblk->vqs);
> > > > >
> > > > > And this too, ugh, that's a huge abuse and is probably totally
> > > > > wrong...
> > > > >
> > > > > thanks again for digging through this crap. I wonder if we need to
> > > > > name
> > > > > the kref reference variable "do_not_touch_this_ever" or some such
> > > > > thing
> > > > > to catch all of the people who try to be "too smart".
> > > >
> > > > There's unimaginable bong hits involved in this stuff, in the end I
> > > > resorted to brute force and scripts to convert all this.
> > >
> > > What should we do about things like this (bpf_prog_put() and callbacks
> > > from kernel/bpf/syscall.c):
>
> Just reading up on this series. Your question refers to converting bpf
> prog and map ref counts to Peter's refcount_t eventually, right?
>
> > > static void bpf_prog_uncharge_memlock(struct bpf_prog *prog)
> > > {
> > > struct user_struct *user = prog->aux->user;
> > >
> > > atomic_long_sub(prog->pages, &user->locked_vm);
> >
> > Oh that's scary. Let's just make one reference count rely on another
> > one and not check things...
>
> Sorry, could you elaborate what you mean by 'check things', you mean for
> wrap around? IIUC, back then accounting was roughly similar modeled after
> perf event's one, and in this case accounts for pages used by progs and
> maps during their life-time. Are you suggesting that this approach is
> inherently broken?
No, it is correct, I responded too quickly before my morning coffee had
kicked in, my apologies.
greg k-h
Re: [PATCH v6 0/3] x86/kvm: Support AVX512_4VNNIW and AVX512_4FMAPS for KVM guest
On Fri, 11 Nov 2016, He Chen wrote: > This patch series is going to add two new AVX512 features to KVM guest. > Since these two features are defined as scattered features in kernel, > some extra modification in kernel is included. I merged the first two patches into git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpufeatures Paolo, feel free to pull that branch up to commit 47bdf3378d62 into kvm so you can apply the KVM patch on top. Thanks, tglx
[tip:x86/cpufeature] x86/cpuid: Cleanup cpuid_regs definitions
Commit-ID: 47f10a36003eaf493125a5e6687dd1ff775bfd8c
Gitweb: http://git.kernel.org/tip/47f10a36003eaf493125a5e6687dd1ff775bfd8c
Author: He Chen
AuthorDate: Fri, 11 Nov 2016 17:25:34 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 11:13:09 +0100
x86/cpuid: Cleanup cpuid_regs definitions
cpuid_regs is defined multiple times as structure and enum. Rename the enum
and move all of it to processor.h so we don't end up with more instances.
Rename the misnomed register enumeration from CR_* to the obvious CPUID_*.
[ tglx: Rewrote changelog ]
Signed-off-by: He Chen
Reviewed-by: Borislav Petkov
Cc: Luwei Kang
Cc: k...@vger.kernel.org
Cc: Radim Krčmář
Cc: Piotr Luc
Cc: Paolo Bonzini
Link:
http://lkml.kernel.org/r/1478856336-9388-2-git-send-email-he.c...@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/events/intel/pt.c | 45 +---
arch/x86/include/asm/processor.h | 11 ++
arch/x86/kernel/cpu/scattered.c | 28 ++---
arch/x86/kernel/cpuid.c | 4
4 files changed, 41 insertions(+), 47 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index c5047b8..1c1b9fe 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -36,13 +36,6 @@ static DEFINE_PER_CPU(struct pt, pt_ctx);
static struct pt_pmu pt_pmu;
-enum cpuid_regs {
- CR_EAX = 0,
- CR_ECX,
- CR_EDX,
- CR_EBX
-};
-
/*
* Capabilities of Intel PT hardware, such as number of address bits or
* supported output schemes, are cached and exported to userspace as "caps"
@@ -64,21 +57,21 @@ static struct pt_cap_desc {
u8 reg;
u32 mask;
} pt_caps[] = {
- PT_CAP(max_subleaf, 0, CR_EAX, 0x),
- PT_CAP(cr3_filtering, 0, CR_EBX, BIT(0)),
- PT_CAP(psb_cyc, 0, CR_EBX, BIT(1)),
- PT_CAP(ip_filtering,0, CR_EBX, BIT(2)),
- PT_CAP(mtc, 0, CR_EBX, BIT(3)),
- PT_CAP(ptwrite, 0, CR_EBX, BIT(4)),
- PT_CAP(power_event_trace, 0, CR_EBX, BIT(5)),
- PT_CAP(topa_output, 0, CR_ECX, BIT(0)),
- PT_CAP(topa_multiple_entries, 0, CR_ECX, BIT(1)),
- PT_CAP(single_range_output, 0, CR_ECX, BIT(2)),
- PT_CAP(payloads_lip,0, CR_ECX, BIT(31)),
- PT_CAP(num_address_ranges, 1, CR_EAX, 0x3),
- PT_CAP(mtc_periods, 1, CR_EAX, 0x),
- PT_CAP(cycle_thresholds,1, CR_EBX, 0x),
- PT_CAP(psb_periods, 1, CR_EBX, 0x),
+ PT_CAP(max_subleaf, 0, CPUID_EAX, 0x),
+ PT_CAP(cr3_filtering, 0, CPUID_EBX, BIT(0)),
+ PT_CAP(psb_cyc, 0, CPUID_EBX, BIT(1)),
+ PT_CAP(ip_filtering,0, CPUID_EBX, BIT(2)),
+ PT_CAP(mtc, 0, CPUID_EBX, BIT(3)),
+ PT_CAP(ptwrite, 0, CPUID_EBX, BIT(4)),
+ PT_CAP(power_event_trace, 0, CPUID_EBX, BIT(5)),
+ PT_CAP(topa_output, 0, CPUID_ECX, BIT(0)),
+ PT_CAP(topa_multiple_entries, 0, CPUID_ECX, BIT(1)),
+ PT_CAP(single_range_output, 0, CPUID_ECX, BIT(2)),
+ PT_CAP(payloads_lip,0, CPUID_ECX, BIT(31)),
+ PT_CAP(num_address_ranges, 1, CPUID_EAX, 0x3),
+ PT_CAP(mtc_periods, 1, CPUID_EAX, 0x),
+ PT_CAP(cycle_thresholds,1, CPUID_EBX, 0x),
+ PT_CAP(psb_periods, 1, CPUID_EBX, 0x),
};
static u32 pt_cap_get(enum pt_capabilities cap)
@@ -213,10 +206,10 @@ static int __init pt_pmu_hw_init(void)
for (i = 0; i < PT_CPUID_LEAVES; i++) {
cpuid_count(20, i,
- &pt_pmu.caps[CR_EAX + i*PT_CPUID_REGS_NUM],
- &pt_pmu.caps[CR_EBX + i*PT_CPUID_REGS_NUM],
- &pt_pmu.caps[CR_ECX + i*PT_CPUID_REGS_NUM],
- &pt_pmu.caps[CR_EDX + i*PT_CPUID_REGS_NUM]);
+ &pt_pmu.caps[CPUID_EAX + i*PT_CPUID_REGS_NUM],
+ &pt_pmu.caps[CPUID_EBX + i*PT_CPUID_REGS_NUM],
+ &pt_pmu.caps[CPUID_ECX + i*PT_CPUID_REGS_NUM],
+ &pt_pmu.caps[CPUID_EDX + i*PT_CPUID_REGS_NUM]);
}
ret = -ENOMEM;
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 984a7bf..8f6ac5b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -137,6 +137,17 @@ struct cpuinfo_x86 {
u32 microcode;
};
+struct cpuid_regs {
+ u32 eax, ebx, ecx, edx;
+};
+
+enum cpuid_regs_idx {
+ CPUID_EAX = 0,
+ CPUID_EBX,
+ CPUID_ECX,
+ CPUID_EDX,
+};
+
#define X86_VENDOR_INTEL 0
#define X86_VENDOR_CYRIX 1
#define X86_VENDOR_AMD
[tip:x86/cpufeature] x86/cpuid: Provide get_scattered_cpuid_leaf()
Commit-ID: 47bdf3378d62a627cfb8a54e1180c08d67078b61
Gitweb: http://git.kernel.org/tip/47bdf3378d62a627cfb8a54e1180c08d67078b61
Author: He Chen
AuthorDate: Fri, 11 Nov 2016 17:25:35 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 16 Nov 2016 11:13:09 +0100
x86/cpuid: Provide get_scattered_cpuid_leaf()
Sparse populated CPUID leafs are collected in a software provided leaf to
avoid bloat of the x86_capability array, but there is no way to rebuild the
real leafs (e.g. for KVM CPUID enumeration) other than rereading the CPUID
leaf from the CPU. While this is possible it is problematic as it does not
take software disabled features into account. If a feature is disabled on
the host it should not be exposed to a guest either.
Add get_scattered_cpuid_leaf() which rebuilds the leaf from the scattered
cpuid table information and the active CPU features.
[ tglx: Rewrote changelog ]
Signed-off-by: He Chen
Reviewed-by: Borislav Petkov
Cc: Luwei Kang
Cc: k...@vger.kernel.org
Cc: Radim Krčmář
Cc: Piotr Luc
Cc: Borislav Petkov
Cc: Paolo Bonzini
Link:
http://lkml.kernel.org/r/1478856336-9388-3-git-send-email-he.c...@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h | 3 +++
arch/x86/kernel/cpu/scattered.c | 49 ++--
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 8f6ac5b..e7f8c62 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -189,6 +189,9 @@ extern void identify_secondary_cpu(struct cpuinfo_x86 *);
extern void print_cpu_info(struct cpuinfo_x86 *);
void print_cpu_msr(struct cpuinfo_x86 *);
extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
+extern u32 get_scattered_cpuid_leaf(unsigned int level,
+ unsigned int sub_leaf,
+ enum cpuid_regs_idx reg);
extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index dbb470e..d1316f9 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -17,24 +17,25 @@ struct cpuid_bit {
u32 sub_leaf;
};
+/* Please keep the leaf sorted by cpuid_bit.level for faster search. */
+static const struct cpuid_bit cpuid_bits[] = {
+ { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x0006, 0 },
+ { X86_FEATURE_EPB, CPUID_ECX, 3, 0x0006, 0 },
+ { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
+ { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX, 2, 0x0007, 0 },
+ { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX, 3, 0x0007, 0 },
+ { X86_FEATURE_HW_PSTATE,CPUID_EDX, 7, 0x8007, 0 },
+ { X86_FEATURE_CPB, CPUID_EDX, 9, 0x8007, 0 },
+ { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
+ { 0, 0, 0, 0, 0 }
+};
+
void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
{
u32 max_level;
u32 regs[4];
const struct cpuid_bit *cb;
- static const struct cpuid_bit cpuid_bits[] = {
- { X86_FEATURE_INTEL_PT, CPUID_EBX, 25, 0x0007, 0 },
- { X86_FEATURE_AVX512_4VNNIW,CPUID_EDX, 2, 0x0007, 0 },
- { X86_FEATURE_AVX512_4FMAPS,CPUID_EDX, 3, 0x0007, 0 },
- { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x0006, 0 },
- { X86_FEATURE_EPB, CPUID_ECX, 3, 0x0006, 0 },
- { X86_FEATURE_HW_PSTATE,CPUID_EDX, 7, 0x8007, 0 },
- { X86_FEATURE_CPB, CPUID_EDX, 9, 0x8007, 0 },
- { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
- { 0, 0, 0, 0, 0 }
- };
-
for (cb = cpuid_bits; cb->feature; cb++) {
/* Verify that the level is valid */
@@ -51,3 +52,27 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
set_cpu_cap(c, cb->feature);
}
}
+
+u32 get_scattered_cpuid_leaf(unsigned int level, unsigned int sub_leaf,
+enum cpuid_regs_idx reg)
+{
+ const struct cpuid_bit *cb;
+ u32 cpuid_val = 0;
+
+ for (cb = cpuid_bits; cb->feature; cb++) {
+
+ if (level > cb->level)
+ continue;
+
+ if (level < cb->level)
+ break;
+
+ if (reg == cb->reg && sub_leaf == cb->sub_leaf) {
+ if (cpu_has(&boot_cpu_data, cb->feature))
+ cpuid_val |= BIT(cb->bit);
+ }
+ }
+
+ return cpuid_val;
+}
+EXPORT_SYMBOL_GPL(get_scattered_cpuid_leaf);
Re: [PATCH v7 06/11] x86, paravirt: Add interface to support kvm/xen vcpu preempted check
On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
> Hi, Peter.
> I think we can avoid a function call in a simpler way. How about below
>
> static inline bool vcpu_is_preempted(int cpu)
> {
> /* only set in pv case*/
> if (pv_lock_ops.vcpu_is_preempted)
> return pv_lock_ops.vcpu_is_preempted(cpu);
> return false;
> }
That is still more expensive. It needs to do an actual load and makes it
hard to predict the branch, you'd have to actually wait for the load to
complete etc.
Also, it generates more code.
Paravirt muck should strive to be as cheap as possible when ran on
native hardware.
Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function
On Mon, Nov 14, 2016 at 3:34 PM, Kai-Heng Feng wrote: > On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman > wrote: >> On 10.11.2016 13:22, Oliver Neukum wrote: >>> >>> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: > > On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: >> >> Oliver Neukum writes: >> >>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: >>> These problems could very well be caused by running at SuperSpeed (USB-3) instead of high speed (USB-2). > > > Yes, it's running at SuperSpeed, on a Kabylake laptop. > > It does not have this issue on a Broadwell laptop, also running at > SuperSpeed. Then I must join Oliver, being very surprised by where in the stack you attempt to fix the issue. What you write above indicates a problem in pci bridge or usb host controller, doesn't it? > > Yes, I was totally wrong about that. > >>> >>> >>> Indeed. And this means we need an XHCI specialist. >>> Mathias, we have a failure specific to one implementation of XHCI. >>> >> >> >> Could be related to resume singnalling time. >> Does the xhci fix for it in 4.9-rc3 help? >> >> commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 >> xhci: use default USB_RESUME_TIMEOUT when resuming ports. >> >> It doesn't directly explain why it would work on Broadwell but not Kabylake, >> but it resolved very similar cases. >> >> If not, then adding dynamic debug for xhci could show something. > > I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7, > on for-usb-next branch. > > Now the cdc_mbim still probe failed at the first time, but somehow it > re-probed again with a success. > > I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the > behavior is the same, first time probed failed, second time probed > success. > > The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled. I filed a bug report on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187861 > >> >> -Mathias >>
Re: [PATCH] staging: slicoss: fix different address space warnings
This can't be right... ->shmem_data is set in slic_init_adapter() and it's not iomem. regards, dan carpenter
Re: [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
On 11/15/2016 11:46 AM, Sekhar Nori wrote:
> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>> This adds the device tree node for the usb otg
>> controller present in the da850 family of SoC's.
>> This also enables the otg usb controller for the lcdk board.
>>
>> Signed-off-by: Alexandre Bailon
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 8
>> arch/arm/boot/dts/da850.dtsi | 15 +++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts
>> index 7b8ab21..9f5040c 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -158,6 +158,14 @@
>> rx-num-evt = <32>;
>> };
>>
>> +&usb_phy {
>> +status = "okay";
>> +};
>
> As mentioned by David already, this node needs to be removed. Please
I have missed it. But why should I remove it?
Without it, usb otg won't work.
> rebase this on top of latest linux-davinci/master when ready for merging
> (driver changes accepted).
>
>> +
>> +&usb0 {
>> +status = "okay";
>> +};
>> +
>> &aemif {
>> pinctrl-names = "default";
>> pinctrl-0 = <&nand_pins>;
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..322a31a 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -372,6 +372,21 @@
>> >;
>> status = "disabled";
>> };
>> +usb_phy: usb-phy {
>> +compatible = "ti,da830-usb-phy";
>> +#phy-cells = <1>;
>> +status = "disabled";
>> +};
>> +usb0: usb@20 {
>> +compatible = "ti,da830-musb";
>> +reg = <0x20 0x1>;
>> +interrupts = <58>;
>> +interrupt-names = "mc";
>> +dr_mode = "otg";
>> +phys = <&usb_phy 0>;
>> +phy-names = "usb-phy";
>> +status = "disabled";
>> +};
>
> Can you separate out the soc specific changes from board changes? Please
> place the usb0 node above the mdio node. I am trying to get to a rough
> ordering based on reg property.
I will do.
>
> Thanks,
> Sekhar
>
Thanks,
Alexandre
[PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc
---
Changes since v1:
* Added comment detailing applicability to different RGMII interfaces.
drivers/net/phy/vitesse.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..24b4a09 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW(1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,34 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+/* This adds a skew for both TX and RX clocks, so the skew should only be
+ * applied to "rgmii-id" interfaces. It may not work as expected
+ * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +307,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask= 0x0000,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init= &genphy_config_init,
+ .config_init= &vsc8601_config_init,
.config_aneg= &genphy_config_aneg,
.read_status= &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
