[tip:smp/hotplug] x86/vdso: Convert to hotplug state machine

[tip-bot for Sebastian Andrzej Siewior]

Commit-ID:  07d36c9e84002678d75b97d2361eb6302a718359
Gitweb: http://git.kernel.org/tip/07d36c9e84002678d75b97d2361eb6302a718359
Author: Sebastian Andrzej Siewior 
AuthorDate: Wed, 13 Jul 2016 17:16:03 +
Committer:  Ingo Molnar 
CommitDate: Thu, 14 Jul 2016 09:34:27 +0200

x86/vdso: Convert to hotplug state machine

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Anna-Maria Gleixner 
Acked-by: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: r...@linutronix.de
Link: http://lkml.kernel.org/r/20160713153332.987560...@linutronix.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/vdso/vma.c  | 20 
 include/linux/cpuhotplug.h |  1 +
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index ab220ac..25b0368 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -294,15 +294,9 @@ static void vgetcpu_cpu_init(void *arg)
write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, &d, 
DESCTYPE_S);
 }
 
-static int
-vgetcpu_cpu_notifier(struct notifier_block *n, unsigned long action, void *arg)
+static int vgetcpu_online(unsigned int cpu)
 {
-   long cpu = (long)arg;
-
-   if (action == CPU_ONLINE || action == CPU_ONLINE_FROZEN)
-   smp_call_function_single(cpu, vgetcpu_cpu_init, NULL, 1);
-
-   return NOTIFY_DONE;
+   return smp_call_function_single(cpu, vgetcpu_cpu_init, NULL, 1);
 }
 
 static int __init init_vdso(void)
@@ -313,15 +307,9 @@ static int __init init_vdso(void)
init_vdso_image(&vdso_image_x32);
 #endif
 
-   cpu_notifier_register_begin();
-
-   on_each_cpu(vgetcpu_cpu_init, NULL, 1);
/* notifier priority > KVM */
-   __hotcpu_notifier(vgetcpu_cpu_notifier, 30);
-
-   cpu_notifier_register_done();
-
-   return 0;
+   return cpuhp_setup_state(CPUHP_AP_X86_VDSO_VMA_ONLINE,
+"AP_X86_VDSO_VMA_ONLINE", vgetcpu_online, 
NULL);
 }
 subsys_initcall(init_vdso);
 #endif /* CONFIG_X86_64 */
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 386374d..fe05640 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -14,6 +14,7 @@ enum cpuhp_state {
CPUHP_TEARDOWN_CPU,
CPUHP_AP_ONLINE_IDLE,
CPUHP_AP_SMPBOOT_THREADS,
+   CPUHP_AP_X86_VDSO_VMA_ONLINE,
CPUHP_AP_NOTIFY_ONLINE,
CPUHP_AP_ONLINE_DYN,
CPUHP_AP_ONLINE_DYN_END = CPUHP_AP_ONLINE_DYN + 30,

[tip:smp/hotplug] irqchip/gic: Convert to hotplug state machine

[tip-bot for Richard Cochran]

Commit-ID:  93131f7a9b5c261f9995b4a6cbd7dbbec1351d2f
Gitweb: http://git.kernel.org/tip/93131f7a9b5c261f9995b4a6cbd7dbbec1351d2f
Author: Richard Cochran 
AuthorDate: Wed, 13 Jul 2016 17:16:04 +
Committer:  Ingo Molnar 
CommitDate: Thu, 14 Jul 2016 09:34:28 +0200

irqchip/gic: Convert to hotplug state machine

More or less straightforward, although this driver sports some very
interesting SMP setup code. Regarding the callback ordering, this
deleted comment is interesting:

   ... the GIC needs to be up before the ARM generic timers.

That comment is half baken as the same requirement is true for perf.

Signed-off-by: Richard Cochran 
Signed-off-by: Anna-Maria Gleixner 
Reviewed-by: Sebastian Andrzej Siewior 
Acked-by: Jason Cooper 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: r...@linutronix.de
Link: http://lkml.kernel.org/r/2016071315.069777...@linutronix.de
Signed-off-by: Ingo Molnar 
---
 drivers/irqchip/irq-gic.c  | 23 ++-
 include/linux/cpuhotplug.h |  1 +
 2 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index fbc4ae2..606f114 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -984,25 +984,12 @@ static int gic_irq_domain_translate(struct irq_domain *d,
return -EINVAL;
 }
 
-#ifdef CONFIG_SMP
-static int gic_secondary_init(struct notifier_block *nfb, unsigned long action,
- void *hcpu)
+static int gic_starting_cpu(unsigned int cpu)
 {
-   if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
-   gic_cpu_init(&gic_data[0]);
-   return NOTIFY_OK;
+   gic_cpu_init(&gic_data[0]);
+   return 0;
 }
 
-/*
- * Notifier for enabling the GIC CPU interface. Set an arbitrarily high
- * priority because the GIC needs to be up before the ARM generic timers.
- */
-static struct notifier_block gic_cpu_notifier = {
-   .notifier_call = gic_secondary_init,
-   .priority = 100,
-};
-#endif
-
 static int gic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
 {
@@ -1148,8 +1135,10 @@ static int __init __gic_init_bases(struct gic_chip_data 
*gic, int irq_start,
gic_cpu_map[i] = 0xff;
 #ifdef CONFIG_SMP
set_smp_cross_call(gic_raise_softirq);
-   register_cpu_notifier(&gic_cpu_notifier);
 #endif
+   cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
+ "AP_IRQ_GIC_STARTING",
+ gic_starting_cpu, NULL);
set_handle_irq(gic_handle_irq);
if (static_key_true(&supports_deactivate))
pr_info("GIC: Using split EOI/Deactivate mode\n");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index fe05640..edc8adf 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -9,6 +9,7 @@ enum cpuhp_state {
CPUHP_AP_IDLE_DEAD,
CPUHP_AP_OFFLINE,
CPUHP_AP_SCHED_STARTING,
+   CPUHP_AP_IRQ_GIC_STARTING,
CPUHP_AP_NOTIFY_STARTING,
CPUHP_AP_ONLINE,
CPUHP_TEARDOWN_CPU,

[PATCH v7] wlcore: spi: add wl18xx support

[Eyal Reizer]

From: Eyal Reizer 

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
Acked-by: Rob Herring 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
v6->v7: Mail format issues
 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 123 ++---
 2 files changed, 137 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
 &spi1 {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <&gpio3>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <&vwlan_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+&spi0 {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <&gpio0>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <&vwlan_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
 

[tip:smp/hotplug] cpu/hotplug: Handle early registration gracefully

[tip-bot for Thomas Gleixner]

Commit-ID:  6a4e24518c8a10f78f44da219835239cb5aca90d
Gitweb: http://git.kernel.org/tip/6a4e24518c8a10f78f44da219835239cb5aca90d
Author: Thomas Gleixner 
AuthorDate: Wed, 13 Jul 2016 17:16:03 +
Committer:  Ingo Molnar 
CommitDate: Thu, 14 Jul 2016 09:34:25 +0200

cpu/hotplug: Handle early registration gracefully

We switched the hotplug machinery to smpboot threads. Early registration of
hotplug callbacks, i.e. from do_pre_smp_initcalls(), happens before the
threads are initialized. Instead of moving the thread init, we simply handle
it in the hotplug code itself and invoke the function directly.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Anna-Maria Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: r...@linutronix.de
Link: http://lkml.kernel.org/r/20160713153332.896450...@linutronix.de
Signed-off-by: Ingo Molnar 
---
 kernel/cpu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 7b61887..fe71ce4 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -517,6 +517,13 @@ static int cpuhp_invoke_ap_callback(int cpu, enum 
cpuhp_state state,
if (!cpu_online(cpu))
return 0;
 
+   /*
+* If we are up and running, use the hotplug thread. For early calls
+* we invoke the thread function directly.
+*/
+   if (!st->thread)
+   return cpuhp_invoke_callback(cpu, state, cb);
+
st->cb_state = state;
st->cb = cb;
/*

[tip:perf/core] perf tests: Add is_printable_array test

[tip-bot for Jiri Olsa]

Commit-ID:  988dd774dcbd9151c2a643fc7284c5c3c4d0adb7
Gitweb: http://git.kernel.org/tip/988dd774dcbd9151c2a643fc7284c5c3c4d0adb7
Author: Jiri Olsa 
AuthorDate: Sat, 16 Jul 2016 18:11:20 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:50:35 -0300

perf tests: Add is_printable_array test

Add automated test for is_printable_array function.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Jiri Pirko 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: 
http://lkml.kernel.org/r/1468685480-18951-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/Build|  1 +
 tools/perf/tests/builtin-test.c   |  4 
 tools/perf/tests/is_printable_array.c | 36 +++
 tools/perf/tests/tests.h  |  1 +
 4 files changed, 42 insertions(+)

diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 4158422..cb20ae1 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -40,6 +40,7 @@ perf-y += event_update.o
 perf-y += event-times.o
 perf-y += backward-ring-buffer.o
 perf-y += sdt.o
+perf-y += is_printable_array.o
 
 $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build
$(call rule_mkdir)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 4dd2d05..10eb306 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -222,6 +222,10 @@ static struct test generic_tests[] = {
.func = test__sdt_event,
},
{
+   .desc = "Test is_printable_array function",
+   .func = test__is_printable_array,
+   },
+   {
.func = NULL,
},
 };
diff --git a/tools/perf/tests/is_printable_array.c 
b/tools/perf/tests/is_printable_array.c
new file mode 100644
index 000..42e1339
--- /dev/null
+++ b/tools/perf/tests/is_printable_array.c
@@ -0,0 +1,36 @@
+#include 
+#include "tests.h"
+#include "debug.h"
+#include "util.h"
+
+int test__is_printable_array(int subtest __maybe_unused)
+{
+   char buf1[] = { 'k', 'r', 4, 'v', 'a', 0 };
+   char buf2[] = { 'k', 'r', 'a', 'v', 4, 0 };
+   struct {
+   char*buf;
+   unsigned int len;
+   int  ret;
+   } t[] = {
+   { (char *) "krava", sizeof("krava"),1 },
+   { (char *) "krava", sizeof("krava") - 1,0 },
+   { (char *) "",  sizeof(""), 1 },
+   { (char *) "",  0,  0 },
+   { NULL, 0,  0 },
+   { buf1, sizeof(buf1),   0 },
+   { buf2, sizeof(buf2),   0 },
+   };
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(t); i++) {
+   int ret;
+
+   ret = is_printable_array((char *) t[i].buf, t[i].len);
+   if (ret != t[i].ret) {
+   pr_err("failed: test %u\n", i);
+   return TEST_FAIL;
+   }
+   }
+
+   return TEST_OK;
+}
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index a0288f8..9bfc0e0 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -89,6 +89,7 @@ int test__event_times(int subtest);
 int test__backward_ring_buffer(int subtest);
 int test__cpu_map_print(int subtest);
 int test__sdt_event(int subtest);
+int test__is_printable_array(int subtest);
 
 #if defined(__arm__) || defined(__aarch64__)
 #ifdef HAVE_DWARF_UNWIND_SUPPORT

Re: [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon

[Quentin Schulz]

On 18/07/2016 14:24, Jonathan Cameron wrote:
> On 15/07/16 10:59, Quentin Schulz wrote:
>> Currently, iio_hwmon only exposes values of the IIO channels it can read
>> but no label by channel is exposed.
>>
>> This adds exposition of sysfs files containing label for IIO channels it
>> can read based on extended_name field of the iio_chan_spec of the channel.
>> If the extended_name field is empty, the sysfs file is not created by
>> iio_hwmon.
> Hmm. This is not the intent of extended name at all.  That exists to add
> a small amount of information to an constructed IIO channel name.
> Typically it's used to indicate physically wired stuff like:
> 
> in_voltage0_vdd_raw for cases where that channel of the ADC is hard wired
> to the vdd.  In this particular case the use might actually work as the
> vdd makes it clear it's a voltage - in general that's not the case.
> 
> Use of extended_name at all in IIO is only done after extensive review.
> It adds nasty custom ABI to a device, so the gain has to be considerable
> to use it.
> 
> When I read your original suggestion of adding labels, I was expecting the
> use of datasheet_name.  That has the advantage of being well defined by
> the datasheet (if not it should not be provided) + not being used in
> the construction of the IIO channel related attributes.  However, that
> may still not correspond well to the expected labelling in hwmon.

Good to know for extend_name use cases. While doing further testing, I
noticed the extend_name is also appended to the sysfs filename.. which
is definitely not what we want.

I've checked for datasheet_name and it is only used to be compared to
adc_channel_label from iio_map structure. Same for adc_channel_label
(which has to be the same as datasheet_name of the iio_chan_spec it is
linked to). So I could use this instead of extend_name to put a label on
a channel.
However, I thought of it to be more a way to identify the hardware in
the datasheet more than giving users a hint on what it is. That's what
"git grep adc_channel_label" told me. It's definitely better to use
datasheet_name over extend_name for channel labeling but I don't know if
it's really the good variable to use for labeling? In my understanding
of datasheet_name, in my case it would be more "temp_gpadc" than "SoC
temperature", that's what I mean.

> Thinking more on this, the label is going to often be a function of how
> the board is wired up...  Perhaps it should be a characteristic of the
> channel_map (hence from DT or similar) rather than part of the IIO driver
> itself?

Hmm.. I would not put a property in the DT only for labeling.

[...]

[tip:perf/core] perf tools: Make is_printable_array global

[tip-bot for Jiri Olsa]

Commit-ID:  accaed2659530b4047678070cb23fd1d9a1c1a59
Gitweb: http://git.kernel.org/tip/accaed2659530b4047678070cb23fd1d9a1c1a59
Author: Jiri Olsa 
AuthorDate: Sat, 16 Jul 2016 18:11:19 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:49:47 -0300

perf tools: Make is_printable_array global

It's used from 2 objects in perf, so it's better to keep just one copy.

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Jiri Pirko 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: 
http://lkml.kernel.org/r/1468685480-18951-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/python.c   | 12 
 tools/perf/util/scripting-engines/trace-event-python.c | 16 
 tools/perf/util/util.c | 16 
 tools/perf/util/util.h |  1 +
 4 files changed, 17 insertions(+), 28 deletions(-)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index d32f970..a5fbc01 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -295,18 +295,6 @@ static bool is_tracepoint(struct pyrf_event *pevent)
return pevent->evsel->attr.type == PERF_TYPE_TRACEPOINT;
 }
 
-static int is_printable_array(char *p, unsigned int len)
-{
-   unsigned int i;
-
-   for (i = 0; i < len; i++) {
-   if (!isprint(p[i]) && !isspace(p[i]))
-   return 0;
-   }
-
-   return 1;
-}
-
 static PyObject*
 tracepoint_field(struct pyrf_event *pe, struct format_field *field)
 {
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 7bd6da8..e0203b9 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -386,22 +386,6 @@ exit:
return pylist;
 }
 
-static int is_printable_array(char *p, unsigned int len)
-{
-   unsigned int i;
-
-   if (!p || !len || p[len - 1] != 0)
-   return 0;
-
-   len--;
-
-   for (i = 0; i < len; i++) {
-   if (!isprint(p[i]) && !isspace(p[i]))
-   return 0;
-   }
-   return 1;
-}
-
 static void python_process_tracepoint(struct perf_sample *sample,
  struct perf_evsel *evsel,
  struct addr_location *al)
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 5f44a21..cee559d 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -746,3 +746,19 @@ void print_binary(unsigned char *data, size_t len,
}
printer(BINARY_PRINT_DATA_END, -1, extra);
 }
+
+int is_printable_array(char *p, unsigned int len)
+{
+   unsigned int i;
+
+   if (!p || !len || p[len - 1] != 0)
+   return 0;
+
+   len--;
+
+   for (i = 0; i < len; i++) {
+   if (!isprint(p[i]) && !isspace(p[i]))
+   return 0;
+   }
+   return 1;
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 843cbba..e5f5547 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -364,4 +364,5 @@ void print_binary(unsigned char *data, size_t len,
 extern int sched_getcpu(void);
 #endif
 
+int is_printable_array(char *p, unsigned int len);
 #endif /* GIT_COMPAT_UTIL_H */

Re: [PATCH v3 09/17] mm, compaction: make whole_zone flag ignore cached scanner positions

[Vlastimil Babka]

On 07/19/2016 08:44 AM, Joonsoo Kim wrote:

On Mon, Jul 18, 2016 at 11:12:51AM +0200, Vlastimil Babka wrote:

On 07/06/2016 07:09 AM, Joonsoo Kim wrote:

On Fri, Jun 24, 2016 at 11:54:29AM +0200, Vlastimil Babka wrote:

A recent patch has added whole_zone flag that compaction sets when scanning
starts from the zone boundary, in order to report that zone has been fully
scanned in one attempt. For allocations that want to try really hard or cannot
fail, we will want to introduce a mode where scanning whole zone is guaranteed
regardless of the cached positions.

This patch reuses the whole_zone flag in a way that if it's already passed true
to compaction, the cached scanner positions are ignored. Employing this flag


Okay. But, please don't reset cached scanner position even if whole_zone
flag is set. Just set cc->migrate_pfn and free_pfn, appropriately. With


Won't that result in confusion on cached position updates during
compaction where it checks the previous cached position? I wonder
what kinds of corner cases it can bring...


whole_zone would come along with ignore_skip_hint so I think that
there is no problem on cached position updating.


Right, that's true.




your following patches, whole_zone could be set without any compaction
try


I don't understand what you mean here? Even after whole series,
whole_zone is only checked, and positions thus reset, after passing
the compaction_suitable() call from compact_zone(). So at that point
we can say that compaction is being actually tried and it's not a
drive-by reset?


My point is that we should not initialize zone's cached pfn in case of
the whole_zone because what compaction with COMPACT_PRIO_SYNC_FULL
want is just to scan whole range. zone's cached pfn exists for
efficiency and there is no reason to initialize it by compaction with
COMPACT_PRIO_SYNC_FULL. If there are some parallel compaction users,
they could be benefit from un-initialized zone's cached pfn so I'd
like to leave them.


I doubt they will benefit much, but OK, I'll update the patch.


Thanks.

[tip:perf/core] perf script python: Fix string vs byte array resolving

[tip-bot for Jiri Olsa]

Commit-ID:  249de6e074580988d3ee4902236803098e2cda4c
Gitweb: http://git.kernel.org/tip/249de6e074580988d3ee4902236803098e2cda4c
Author: Jiri Olsa 
AuthorDate: Sat, 16 Jul 2016 18:11:18 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:48:04 -0300

perf script python: Fix string vs byte array resolving

Jirka reported that python code returns all arrays as strings.  This
makes impossible to get all items for byte array tracepoint field
containing 0x00 value item.

Fixing this by scanning full length of the array and returning it as
PyByteArray object in case non printable byte is found.

Signed-off-by: Jiri Olsa 
Reported-and-Tested-by: Jiri Pirko 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Link: 
http://lkml.kernel.org/r/1468685480-18951-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../util/scripting-engines/trace-event-python.c| 39 ++
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 6ac6b7a..7bd6da8 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -386,6 +386,21 @@ exit:
return pylist;
 }
 
+static int is_printable_array(char *p, unsigned int len)
+{
+   unsigned int i;
+
+   if (!p || !len || p[len - 1] != 0)
+   return 0;
+
+   len--;
+
+   for (i = 0; i < len; i++) {
+   if (!isprint(p[i]) && !isspace(p[i]))
+   return 0;
+   }
+   return 1;
+}
 
 static void python_process_tracepoint(struct perf_sample *sample,
  struct perf_evsel *evsel,
@@ -457,14 +472,26 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
pydict_set_item_string_decref(dict, "common_callchain", 
callchain);
}
for (field = event->format.fields; field; field = field->next) {
-   if (field->flags & FIELD_IS_STRING) {
-   int offset;
+   unsigned int offset, len;
+   unsigned long long val;
+
+   if (field->flags & FIELD_IS_ARRAY) {
+   offset = field->offset;
+   len= field->size;
if (field->flags & FIELD_IS_DYNAMIC) {
-   offset = *(int *)(data + field->offset);
+   val = 
pevent_read_number(scripting_context->pevent,
+data + offset, 
len);
+   offset  = val;
+   len = offset >> 16;
offset &= 0x;
-   } else
-   offset = field->offset;
-   obj = PyString_FromString((char *)data + offset);
+   }
+   if (field->flags & FIELD_IS_STRING &&
+   is_printable_array(data + offset, len)) {
+   obj = PyString_FromString((char *) data + 
offset);
+   } else {
+   obj = PyByteArray_FromStringAndSize((const char 
*) data + offset, len);
+   field->flags &= ~FIELD_IS_STRING;
+   }
} else { /* FIELD_IS_NUMERIC */
obj = get_field_numeric_entry(event, field, data);
}

[tip:perf/core] perf stat: Balance opening and reading events

[tip-bot for Mark Rutland]

Commit-ID:  00e727bb389359c81101b03d34fec8cc7be5168d
Gitweb: http://git.kernel.org/tip/00e727bb389359c81101b03d34fec8cc7be5168d
Author: Mark Rutland 
AuthorDate: Fri, 15 Jul 2016 11:08:10 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:41:14 -0300

perf stat: Balance opening and reading events

In create_perf_stat_counter, when a target CPU has not been provided, we
call __perf_evsel__open with empty_cpu_map, and open a single FD per
thread. However, in read_counter we assume that we opened events for the
product of threads and CPUs described in the evsel's cpu_map.

Thus, if an evsel has a cpu_map with more than one entry, we will
attempt to access FDs that we didn't open. This could result in a number
of problems (e.g. blocking while reading from STDIN if the fd memory
happened to be initialised to zero).

This is problematic for systems were a logical CPU PMU covers some
arbitrary subset of CPUs. The cpu_map of any evsel for that PMU will be
initialised based on the cpumask exposed through sysfs, even if the user
requests per-thread events.

Signed-off-by: Mark Rutland 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: He Kuang 
Cc: Kan Liang 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1468577293-19667-2-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8c5a3bf..0c16d20 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -290,8 +290,12 @@ perf_evsel__write_stat_event(struct perf_evsel *counter, 
u32 cpu, u32 thread,
 static int read_counter(struct perf_evsel *counter)
 {
int nthreads = thread_map__nr(evsel_list->threads);
-   int ncpus = perf_evsel__nr_cpus(counter);
-   int cpu, thread;
+   int ncpus, cpu, thread;
+
+   if (target__has_cpu(&target))
+   ncpus = perf_evsel__nr_cpus(counter);
+   else
+   ncpus = 1;
 
if (!counter->supported)
return -ENOENT;

[tip:perf/core] perf probe: Warn unmatched function filter correctly

[tip-bot for Masami Hiramatsu]

Commit-ID:  e70493429bb1acaad829caae01c61dd7056fe671
Gitweb: http://git.kernel.org/tip/e70493429bb1acaad829caae01c61dd7056fe671
Author: Masami Hiramatsu 
AuthorDate: Tue, 19 Jul 2016 01:12:41 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:46:34 -0300

perf probe: Warn unmatched function filter correctly

Warn unmatched function filter correctly instead of warning
"symbol-loading error", since that can be a filter issue.

>From the technical point of view, this adds a filter chech in map__load
and if there is a filter, it returns -2 (filter-out), instead of -1
(error), and perf-probe checks it and change message.

E.g. without this fix:

  # perf probe -F rt_sp*
  no symbols found in [kernel.kallsyms], maybe install a debug package?
  Failed to load symbols in kernel

With this fix:

  # perf probe -F rt_sp*
  no symbols passed the given filter.
  Failed to find symbols matched to "rt_sp*"
Error: Failed to show functions.

Reported-and-Tested-by: Arnaldo Carvalho de Melo 
Signed-off-by: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/146885835596.16106.2293540792775552481.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/map.c |  3 +++
 tools/perf/util/probe-event.c | 12 ++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b39b12a..728129a 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -312,6 +312,9 @@ int map__load(struct map *map, symbol_filter_t filter)
pr_warning("%.*s was updated (is prelink enabled?). "
"Restart the long running apps that use it!\n",
   (int)real_len, name);
+   } else if (filter) {
+   pr_warning("no symbols passed the given filter.\n");
+   return -2;  /* Empty but maybe by the filter */
} else {
pr_warning("no symbols found in %s, maybe install "
   "a debug package?\n", name);
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index d4f8835..953dc1a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -3312,8 +3312,16 @@ int show_available_funcs(const char *target, struct 
strfilter *_filter,
 
/* Load symbols with given filter */
available_func_filter = _filter;
-   if (map__load(map, filter_available_functions)) {
-   pr_err("Failed to load symbols in %s\n", (target) ? : "kernel");
+   ret = map__load(map, filter_available_functions);
+   if (ret) {
+   if (ret == -2) {
+   char *str = strfilter__string(_filter);
+   pr_err("Failed to find symbols matched to \"%s\"\n",
+  str);
+   free(str);
+   } else
+   pr_err("Failed to load symbols in %s\n",
+  (target) ? : "kernel");
goto end;
}
if (!dso__sorted_by_name(map->dso, map->type))

[tip:perf/core] perf cpu_map: Add more helpers

[tip-bot for Mark Rutland]

Commit-ID:  9a6c582d57a0fc37fa4e13a69d9129fb3d98a401
Gitweb: http://git.kernel.org/tip/9a6c582d57a0fc37fa4e13a69d9129fb3d98a401
Author: Mark Rutland 
AuthorDate: Fri, 15 Jul 2016 11:08:11 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 19:42:47 -0300

perf cpu_map: Add more helpers

In some cases it's necessry to figure out the map-local index of a given
Linux logical CPU ID. Add a new helper, cpu_map__idx, to acquire this.
As the logic is largely the same as the existing cpu_map__has, this is
rewritten in terms of the new helper.

At the same time, add the inverse operation, cpu_map__cpu, which yields
the logical CPU id for a map-local index. While this can be performed
manually, wrapping this in a helper can make code more legible.

Signed-off-by: Mark Rutland 
Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: He Kuang 
Cc: Kan Liang 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1468577293-19667-3-git-send-email-mark.rutl...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cpumap.c | 14 --
 tools/perf/util/cpumap.h |  2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index 15f83ac..2c0b522 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -589,14 +589,24 @@ int cpu__setup_cpunode_map(void)
 
 bool cpu_map__has(struct cpu_map *cpus, int cpu)
 {
+   return cpu_map__idx(cpus, cpu) != -1;
+}
+
+int cpu_map__idx(struct cpu_map *cpus, int cpu)
+{
int i;
 
for (i = 0; i < cpus->nr; ++i) {
if (cpus->map[i] == cpu)
-   return true;
+   return i;
}
 
-   return false;
+   return -1;
+}
+
+int cpu_map__cpu(struct cpu_map *cpus, int idx)
+{
+   return cpus->map[idx];
 }
 
 size_t cpu_map__snprint(struct cpu_map *map, char *buf, size_t size)
diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
index 206dc55..06bd689 100644
--- a/tools/perf/util/cpumap.h
+++ b/tools/perf/util/cpumap.h
@@ -68,5 +68,7 @@ int cpu_map__build_map(struct cpu_map *cpus, struct cpu_map 
**res,
   int (*f)(struct cpu_map *map, int cpu, void *data),
   void *data);
 
+int cpu_map__cpu(struct cpu_map *cpus, int idx);
 bool cpu_map__has(struct cpu_map *cpus, int cpu);
+int cpu_map__idx(struct cpu_map *cpus, int cpu);
 #endif /* __PERF_CPUMAP_H */

Re: [PATCH v4] locking/pvqspinlock: Fix double hash race

[Wanpeng Li]

Sorry for the quick ping, but could we catch the merge window? Ingo. :)
2016-07-16 9:51 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li 
>
> When the lock holder vCPU is racing with the queue head vCPU:
>
> lock holder vCPU queue head vCPU
> ===
>
> node->locked = 1;
>  READ_ONCE(node->locked)
>...   pv_wait_head_or_lock():
>SPIN_THRESHOLD loop;
>pv_hash();
>lock->locked = _Q_SLOW_VAL;
>node->state  = vcpu_hashed;
> pv_kick_node():
>   cmpxchg(node->state,
>  vcpu_halted, vcpu_hashed);
>   lock->locked = _Q_SLOW_VAL;
>   pv_hash();
>
> With preemption at the right moment, it is possible that both the
> lock holder and queue head vCPUs can be racing to set node->state
> which can result in hash entry race. Making sure the state is never
> set to vcpu_halted will prevent this racing from happening.
>
> This patch fix it by setting vcpu_hashed after we did all hash thing.
>
> Reviewed-by: Pan Xinhui 
> Cc: Peter Zijlstra (Intel) 
> Cc: Ingo Molnar 
> Cc: Waiman Long 
> Cc: Davidlohr Bueso 
> Signed-off-by: Wanpeng Li 
> ---
> v3 -> v4:
>  * update patch subject
>  * add code comments
> v2 -> v3:
>  * fix typo in patch description
> v1 -> v2:
>  * adjust patch description
>
>  kernel/locking/qspinlock_paravirt.h | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/qspinlock_paravirt.h 
> b/kernel/locking/qspinlock_paravirt.h
> index 21ede57..ca96db4 100644
> --- a/kernel/locking/qspinlock_paravirt.h
> +++ b/kernel/locking/qspinlock_paravirt.h
> @@ -450,7 +450,28 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct 
> mcs_spinlock *node)
> goto gotlock;
> }
> }
> -   WRITE_ONCE(pn->state, vcpu_halted);
> +   /*
> +* lock holder vCPU queue head vCPU
> +*  ---
> +* node->locked = 1;
> +*  READ_ONCE(node->locked)
> +*...   pv_wait_head_or_lock():
> +*SPIN_THRESHOLD loop;
> +*pv_hash();
> +*lock->locked = _Q_SLOW_VAL;
> +*node->state  = vcpu_hashed;
> +* pv_kick_node():
> +*   cmpxchg(node->state,
> +*  vcpu_halted, vcpu_hashed);
> +*   lock->locked = _Q_SLOW_VAL;
> +*   pv_hash();
> +*
> +* With preemption at the right moment, it is possible that 
> both the
> +* lock holder and queue head vCPUs can be racing to set 
> node->state.
> +* Making sure the state is never set to vcpu_halted will 
> prevent this
> +* racing from happening.
> +*/
> +   WRITE_ONCE(pn->state, vcpu_hashed);
> qstat_inc(qstat_pv_wait_head, true);
> qstat_inc(qstat_pv_wait_again, waitcnt);
> pv_wait(&l->locked, _Q_SLOW_VAL);
> --
> 2.1.0
>



-- 
Regards,
Wanpeng Li

[tip:perf/core] tools: Copy linux/{hash,poison}.h and check for drift

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  ae3c14a028ed10552803b68276b6833295ba18cf
Gitweb: http://git.kernel.org/tip/ae3c14a028ed10552803b68276b6833295ba18cf
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 18:39:36 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 18:41:50 -0300

tools: Copy linux/{hash,poison}.h and check for drift

We were also using this directly from the kernel sources, the two last
cases, fix it.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-7o14xvacqcjc5llc7gvjj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/include/linux/hash.h   | 105 +--
 tools/include/linux/poison.h |  91 -
 tools/perf/MANIFEST  |   2 -
 tools/perf/Makefile.perf |   3 ++
 4 files changed, 195 insertions(+), 6 deletions(-)

diff --git a/tools/include/linux/hash.h b/tools/include/linux/hash.h
index d026c65..ad6fa21 100644
--- a/tools/include/linux/hash.h
+++ b/tools/include/linux/hash.h
@@ -1,5 +1,104 @@
-#include "../../../include/linux/hash.h"
+#ifndef _LINUX_HASH_H
+#define _LINUX_HASH_H
+/* Fast hashing routine for ints,  longs and pointers.
+   (C) 2002 Nadia Yvette Chambers, IBM */
 
-#ifndef _TOOLS_LINUX_HASH_H
-#define _TOOLS_LINUX_HASH_H
+#include 
+#include 
+
+/*
+ * The "GOLDEN_RATIO_PRIME" is used in ifs/btrfs/brtfs_inode.h and
+ * fs/inode.c.  It's not actually prime any more (the previous primes
+ * were actively bad for hashing), but the name remains.
+ */
+#if BITS_PER_LONG == 32
+#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_32
+#define hash_long(val, bits) hash_32(val, bits)
+#elif BITS_PER_LONG == 64
+#define hash_long(val, bits) hash_64(val, bits)
+#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_64
+#else
+#error Wordsize not 32 or 64
+#endif
+
+/*
+ * This hash multiplies the input by a large odd number and takes the
+ * high bits.  Since multiplication propagates changes to the most
+ * significant end only, it is essential that the high bits of the
+ * product be used for the hash value.
+ *
+ * Chuck Lever verified the effectiveness of this technique:
+ * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf
+ *
+ * Although a random odd number will do, it turns out that the golden
+ * ratio phi = (sqrt(5)-1)/2, or its negative, has particularly nice
+ * properties.  (See Knuth vol 3, section 6.4, exercise 9.)
+ *
+ * These are the negative, (1 - phi) = phi**2 = (3 - sqrt(5))/2,
+ * which is very slightly easier to multiply by and makes no
+ * difference to the hash distribution.
+ */
+#define GOLDEN_RATIO_32 0x61C88647
+#define GOLDEN_RATIO_64 0x61C8864680B583EBull
+
+#ifdef CONFIG_HAVE_ARCH_HASH
+/* This header may use the GOLDEN_RATIO_xx constants */
+#include 
+#endif
+
+/*
+ * The _generic versions exist only so lib/test_hash.c can compare
+ * the arch-optimized versions with the generic.
+ *
+ * Note that if you change these, any  that aren't updated
+ * to match need to have their HAVE_ARCH_* define values updated so the
+ * self-test will not false-positive.
+ */
+#ifndef HAVE_ARCH__HASH_32
+#define __hash_32 __hash_32_generic
+#endif
+static inline u32 __hash_32_generic(u32 val)
+{
+   return val * GOLDEN_RATIO_32;
+}
+
+#ifndef HAVE_ARCH_HASH_32
+#define hash_32 hash_32_generic
 #endif
+static inline u32 hash_32_generic(u32 val, unsigned int bits)
+{
+   /* High bits are more random, so use them. */
+   return __hash_32(val) >> (32 - bits);
+}
+
+#ifndef HAVE_ARCH_HASH_64
+#define hash_64 hash_64_generic
+#endif
+static __always_inline u32 hash_64_generic(u64 val, unsigned int bits)
+{
+#if BITS_PER_LONG == 64
+   /* 64x64-bit multiply is efficient on all 64-bit processors */
+   return val * GOLDEN_RATIO_64 >> (64 - bits);
+#else
+   /* Hash 64 bits using only 32x32-bit multiply. */
+   return hash_32((u32)val ^ __hash_32(val >> 32), bits);
+#endif
+}
+
+static inline u32 hash_ptr(const void *ptr, unsigned int bits)
+{
+   return hash_long((unsigned long)ptr, bits);
+}
+
+/* This really should be called fold32_ptr; it does no hashing to speak of. */
+static inline u32 hash32_ptr(const void *ptr)
+{
+   unsigned long val = (unsigned long)ptr;
+
+#if BITS_PER_LONG == 64
+   val ^= (val >> 32);
+#endif
+   return (u32)val;
+}
+
+#endif /* _LINUX_HASH_H */
diff --git a/tools/include/linux/poison.h b/tools/include/linux/poison.h
index 0c27bdf..51334ed 100644
--- a/tools/include/linux/poison.h
+++ b/tools/include/linux/poison.h
@@ -1 +1,90 @@
-#include "../../../include/linux/poison.h"
+#ifndef _LINUX_POISON_H
+#define _LINUX_POISON_H
+
+/** include/linux/list.h **/
+
+/*
+ * Architectures might want to move the poison pointer offset
+ * into some well-recognized area such as 0xdead,
+ * that is also not mappable by user-space exploits:
+ */
+#ifdef CONFIG_ILLEGAL_POINTER_VALUE
+# define POISON_POINTER_DELTA _AC(CONFIG_ILLE

Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

['Dave Young']

Hi, 
On 07/19/16 at 05:51am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi,
> 
> > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > Sent: Monday, July 18, 2016 6:02 PM
> > On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > Hi Dave,
> > >
> > > Thanks for your reply.
> > >
> > > > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > > > Sent: Wednesday, July 13, 2016 11:04 AM
> > > >
> > > > On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > > Hi Dave,
> > > > >
> > > > > Thanks for the comments.
> > > > >
> > > > > > From: Dave Young [mailto:dyo...@redhat.com]
> > > > > > Sent: Monday, July 11, 2016 5:35 PM
> > > > > >
> > > > > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> [snip] 
> > > > > > As for this patch I'm not sure it is safe to replace the
> > > > > > smp_send_stop with the kdump friendly function. I'm also not sure if
> > > > > > the kdump friendly function is safe for kdump. Will glad to hear
> > > > > > opinions from other arch experts.
> > > > >
> > > > > This stuff depends on architectures, so I speak only about
> > > > > x86 (the logic doesn't change on other architectures at this time).
> > > > >
> > > > > kdump path with crash_kexec_post_notifiers disabled:
> > > > >  panic()
> > > > >__crash_kexec()
> > > > >  crash_setup_regs()
> > > > >  crash_save_vmcoreinfo()
> > > > >  machine_crash_shutdown()
> > > > >native_machine_crash_shutdown()
> > > > >  panic_smp_send_stop() /* mostly same as original
> > > > > * kdump_nmi_shootdown_cpus()
> > > > > */
> > > > >
> > > > > kdump path with crash_kexec_post_notifiers enabled:
> > > > >  panic()
> > > > >panic_smp_send_stop()
> > > > >__crash_kexec()
> > > > >  crash_setup_regs()
> > > > >  crash_save_vmcoreinfo()
> > > > >  machine_crash_shutdown()
> > > > >native_machine_crash_shutdown()
> > > > >  panic_smp_send_stop() // do nothing
> > > > >
> > > > > The difference is that stopping other CPUs before crash_setup_regs()
> > > > > and crash_save_vmcoreinfo() or not.  Since crash_setup_regs() and
> > > > > crash_save_vmcoreinfo() just save information to some memory area,
> > > > > they wouldn't be affected by panic_smp_send_stop().  This means
> > > > > placing panic_smp_send_stop before __crash_kexec is safe.
> > > > >
> > > > > BTW, I noticed my patch breaks Xen kernel.  I'll fix it in the next
> > > > > version.
> > > >
> > > > But it does breaks stuff which depends on cpu not being disabled like 
> > > > problem 1 you mentioned in patch log.
> > >
> > > As I mentioned in the description of this patch, we should stop
> > > other CPUs ASAP to preserve current state either
> > > crash_kexec_post_notifiers is enabled or not.
> > > Then, all remaining procedures should work well
> > > after stopping other CPUs (but keep the CPU map online).
> > >
> > > Vivek also mentioned similar things:
> > > https://lkml.org/lkml/2015/7/14/433
> > 
> > The implementation in this patchset is different from suggestion in above 
> > link?
> > 
> > I think Vivek's suggestion is a good idea, to drop smp_send_stop and do 
> > below:
> > 
> > stop_cpus_save_register_state;
> > 
> > if (!crash_kexec_post_notifiers)
> > crash_kexec()
> > atomic_notifier_call_chain()
> > kmsg_dump()
> > 
> > I'm just commenting from code flow point of view, the detail implementation
> > definitely need more comments from Arch experts.
> > 
> > Any reason did not move the kdump friendly function to earlier point like
> > before previous __crash_kexec() below?
> > if (!crash_kexec_post_notifiers) {
> > printk_nmi_flush_on_panic();
> > __crash_kexec(NULL);
> > }
> 
> The reason why the implementation differs from Vivek's is to keep
> the current code flow if crash_kexec_post_notifiers is not specified.
> 
> If we apply Vivek's or your suggestion, it may always cause kdump
> to fail on MIPS OCTEON due to Problem 1.  I don't want to make things
> any worse.  I may post a patch for MIPS OCTEON, but I can't test it.
> For other architectures, I'm not sure what problems there are.
> So at first, I want to fix the case where crash_kexec_post_notifiers is
> specified on x86.  Then, if all other architectures support
> `stop other CPUs before crash_kexec', switch to your or Vivek's
> suggesting code.
> 
> Is this acceptable?

Maybe you can find someone who can test MIPS OCTEON so that they can give
some thoughts first and maybe test a fix?

[dyoung@localhost linux]$ ./scripts/get_maintainer.pl -f arch/mips/cavium-octeon
Ralf Baechle  (supporter:MIPS,commit_signer:32/35=91%)
David Daney  (commit_signer:21/35=60%,authored:8/35=23%)
Aaro Koskinen  (commit_signer:15/35=43%,authored:8/35=23%)
Janne Huttunen 
(commit_signer:7/35=20%,authored:7/35=20%)
Thomas Gleixner  (commit_signer:4/35=11%,authored:2/35=6%)
linux-m...@linux-mips.org (open list:MIPS)
linux-kernel@vger.kernel.org (open list)

Thanks
Dave

Re: linux-next: build failure after merge of the wireless-drivers-next tree

[Rafał Miłecki]

On 19 July 2016 at 08:30, Kalle Valo  wrote:
> Stephen Rothwell  writes:
>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (powerpc allyesconfig) failed like this:
>>
>> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of 
>> function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>   b47s->window = ioremap_cache(res->start, resource_size(res));
>>  ^
>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
>>   b47s->window = ioremap_cache(res->start, resource_size(res));
>>^
>>
>> Caused by commit
>>
>>   57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>>
>> I have reverted that commit for today.
>
> Thanks, kbuild bot also notified about this.
>
> Rafał, as the merge window is getting really close I would like to
> revert this for now and we can reapply it once we the problem is fully
> solved. And we can use my pending branch for build testing the patch
> with kbuild bot. What do you think?

The simplest fix sounds pretty much as simple as the revert. In the
seconds thread I was considering two fixes: switching to memremap and
adding depends on.

What about trying a simple "depends on"?

-- 
Rafał

[tip:perf/core] tools: Copy the bitops files accessed from the kernel and check for drift

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  de1e17b1d0c81be472039798698b517c8a68b516
Gitweb: http://git.kernel.org/tip/de1e17b1d0c81be472039798698b517c8a68b516
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 18:13:22 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 18:33:41 -0300

tools: Copy the bitops files accessed from the kernel and check for drift

copy some more kernel files accessed from tools/, check for drift.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-omz8xdyvvxgjiuqzwj6ec...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/include/asm-generic/bitops/__fls.h | 44 +++-
 tools/include/asm-generic/bitops/arch_hweight.h  | 26 +-
 tools/include/asm-generic/bitops/const_hweight.h | 44 +++-
 tools/include/asm-generic/bitops/fls.h   | 42 +-
 tools/include/asm-generic/bitops/fls64.h | 37 +++-
 tools/perf/MANIFEST  |  5 ---
 tools/perf/Makefile.perf | 15 
 7 files changed, 203 insertions(+), 10 deletions(-)

diff --git a/tools/include/asm-generic/bitops/__fls.h 
b/tools/include/asm-generic/bitops/__fls.h
index 494c9c6..a60a7cc 100644
--- a/tools/include/asm-generic/bitops/__fls.h
+++ b/tools/include/asm-generic/bitops/__fls.h
@@ -1 +1,43 @@
-#include "../../../../include/asm-generic/bitops/__fls.h"
+#ifndef _ASM_GENERIC_BITOPS___FLS_H_
+#define _ASM_GENERIC_BITOPS___FLS_H_
+
+#include 
+
+/**
+ * __fls - find last (most-significant) set bit in a long word
+ * @word: the word to search
+ *
+ * Undefined if no set bit exists, so code should check against 0 first.
+ */
+static __always_inline unsigned long __fls(unsigned long word)
+{
+   int num = BITS_PER_LONG - 1;
+
+#if BITS_PER_LONG == 64
+   if (!(word & (~0ul << 32))) {
+   num -= 32;
+   word <<= 32;
+   }
+#endif
+   if (!(word & (~0ul << (BITS_PER_LONG-16 {
+   num -= 16;
+   word <<= 16;
+   }
+   if (!(word & (~0ul << (BITS_PER_LONG-8 {
+   num -= 8;
+   word <<= 8;
+   }
+   if (!(word & (~0ul << (BITS_PER_LONG-4 {
+   num -= 4;
+   word <<= 4;
+   }
+   if (!(word & (~0ul << (BITS_PER_LONG-2 {
+   num -= 2;
+   word <<= 2;
+   }
+   if (!(word & (~0ul << (BITS_PER_LONG-1
+   num -= 1;
+   return num;
+}
+
+#endif /* _ASM_GENERIC_BITOPS___FLS_H_ */
diff --git a/tools/include/asm-generic/bitops/arch_hweight.h 
b/tools/include/asm-generic/bitops/arch_hweight.h
index 318bb2b..6a211f4 100644
--- a/tools/include/asm-generic/bitops/arch_hweight.h
+++ b/tools/include/asm-generic/bitops/arch_hweight.h
@@ -1 +1,25 @@
-#include "../../../../include/asm-generic/bitops/arch_hweight.h"
+#ifndef _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
+#define _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
+
+#include 
+
+static inline unsigned int __arch_hweight32(unsigned int w)
+{
+   return __sw_hweight32(w);
+}
+
+static inline unsigned int __arch_hweight16(unsigned int w)
+{
+   return __sw_hweight16(w);
+}
+
+static inline unsigned int __arch_hweight8(unsigned int w)
+{
+   return __sw_hweight8(w);
+}
+
+static inline unsigned long __arch_hweight64(__u64 w)
+{
+   return __sw_hweight64(w);
+}
+#endif /* _ASM_GENERIC_BITOPS_HWEIGHT_H_ */
diff --git a/tools/include/asm-generic/bitops/const_hweight.h 
b/tools/include/asm-generic/bitops/const_hweight.h
index 0afd644..0a7e066 100644
--- a/tools/include/asm-generic/bitops/const_hweight.h
+++ b/tools/include/asm-generic/bitops/const_hweight.h
@@ -1 +1,43 @@
-#include "../../../../include/asm-generic/bitops/const_hweight.h"
+#ifndef _ASM_GENERIC_BITOPS_CONST_HWEIGHT_H_
+#define _ASM_GENERIC_BITOPS_CONST_HWEIGHT_H_
+
+/*
+ * Compile time versions of __arch_hweightN()
+ */
+#define __const_hweight8(w)\
+   ((unsigned int) \
+((!!((w) & (1ULL << 0))) + \
+ (!!((w) & (1ULL << 1))) + \
+ (!!((w) & (1ULL << 2))) + \
+ (!!((w) & (1ULL << 3))) + \
+ (!!((w) & (1ULL << 4))) + \
+ (!!((w) & (1ULL << 5))) + \
+ (!!((w) & (1ULL << 6))) + \
+ (!!((w) & (1ULL << 7)
+
+#define __const_hweight16(w) (__const_hweight8(w)  + __const_hweight8((w)  >> 
8 ))
+#define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 
16))
+#define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 
32))
+
+/*
+ * Generic interface.
+ */
+#define hweight8(w)  (__builtin_constant_p(w) ? __const_hweight8(w)  : 
__arch_hweight8(w))
+#define hweight16(w) (__builtin_constant_p(w) ? __const_hweight16(w) : 
__arch_hweight16(w))
+#define hweight32(w) (__builtin_constant_p(w) ? __const_hweight32(w) : 
__arch_hweight32(w))
+#define hwe

[tip:perf/core] perf tools: Remove include/linux/list.h from perf's MANIFEST

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  3aa0042769313b720142c0ef8514dac389e14ebe
Gitweb: http://git.kernel.org/tip/3aa0042769313b720142c0ef8514dac389e14ebe
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 18:35:11 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 18:35:11 -0300

perf tools: Remove include/linux/list.h from perf's MANIFEST

It hasn't been used since we made tools/ self sufficiente wrt list.h.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Namhyung Kim 
Cc: Wang Nan 
Fixes: d1b39d41ebec ("tools: Make list.h self-sufficient")
Link: http://lkml.kernel.org/n/tip-w20ueqlf22kh7ctjqo0zj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/MANIFEST | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST
index eeb2fdc..3ac7f8d 100644
--- a/tools/perf/MANIFEST
+++ b/tools/perf/MANIFEST
@@ -77,7 +77,6 @@ tools/include/linux/stringify.h
 tools/include/linux/types.h
 tools/include/linux/err.h
 tools/include/linux/bitmap.h
-include/linux/list.h
 include/linux/hash.h
 tools/arch/*/include/uapi/asm/perf_regs.h
 include/linux/poison.h

[tip:perf/core] perf tools: Remove tools/perf/util/include/linux/const.h

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  e0643c4e9fdb2e77ab83ca596460e2c9c15728aa
Gitweb: http://git.kernel.org/tip/e0643c4e9fdb2e77ab83ca596460e2c9c15728aa
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 17:48:37 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 17:53:22 -0300

perf tools: Remove tools/perf/util/include/linux/const.h

Not used anymore, remove one more file referencing kernel sources, i.e.
outside of tools/

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-ykfjt3t8l0npxfwmekiww...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/MANIFEST   | 1 -
 tools/perf/util/include/linux/const.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST
index 4790f19..d059b72 100644
--- a/tools/perf/MANIFEST
+++ b/tools/perf/MANIFEST
@@ -88,4 +88,3 @@ arch/*/include/asm/unistd*.h
 arch/*/include/uapi/asm/unistd*.h
 tools/arch/*/include/uapi/asm/perf_regs.h
 include/linux/poison.h
-include/uapi/linux/const.h
diff --git a/tools/perf/util/include/linux/const.h 
b/tools/perf/util/include/linux/const.h
deleted file mode 100644
index c10a35e..000
--- a/tools/perf/util/include/linux/const.h
+++ /dev/null
@@ -1 +0,0 @@
-#include "../../../../include/uapi/linux/const.h"

[tip:perf/core] Remove: kernel unistd*h files from perf's MANIFEST, not used

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  ad430729ae00dd63f7dcadbeb638e589bc03b5a3
Gitweb: http://git.kernel.org/tip/ad430729ae00dd63f7dcadbeb638e589bc03b5a3
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 18:00:50 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 18:14:44 -0300

Remove: kernel unistd*h files from perf's MANIFEST, not used

No need to copy it to a detached tarball as they aren't used anymore

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-lopmaqi439ke10g1j9cxr...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/MANIFEST | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tools/perf/MANIFEST b/tools/perf/MANIFEST
index d059b72..e18df99 100644
--- a/tools/perf/MANIFEST
+++ b/tools/perf/MANIFEST
@@ -84,7 +84,5 @@ include/asm-generic/bitops/__fls.h
 include/asm-generic/bitops/fls.h
 include/linux/list.h
 include/linux/hash.h
-arch/*/include/asm/unistd*.h
-arch/*/include/uapi/asm/unistd*.h
 tools/arch/*/include/uapi/asm/perf_regs.h
 include/linux/poison.h

[tip:perf/core] perf tools: Add missing linux/compiler.h include to perf-sys.h

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8
Gitweb: http://git.kernel.org/tip/14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 18 Jul 2016 17:40:49 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 17:40:49 -0300

perf tools: Add missing linux/compiler.h include to perf-sys.h

It uses the likely/unlikely macros, so need to include
.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-p0xrhgbkicsii9ohmhhpr...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/perf-sys.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 5cee8a3..7ed72a4 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 

[tip:perf/core] perf jit: Remove some no-op error handling

[tip-bot for Dan Carpenter]

Commit-ID:  9fcfcdf3c7b613c0d9536f57587456411b8a4e33
Gitweb: http://git.kernel.org/tip/9fcfcdf3c7b613c0d9536f57587456411b8a4e33
Author: Dan Carpenter 
AuthorDate: Sat, 16 Jul 2016 00:08:36 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 12:20:00 -0300

perf jit: Remove some no-op error handling

The 'info.e_machine' struct member is an uint16_t so 'm' is never less
than zero.  It looks like this was maybe left over code from earlier
versions so I've just removed it.

Signed-off-by: Dan Carpenter 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: kernel-janit...@vger.kernel.org
Link: http://lkml.kernel.org/r/20160715210836.GB19522@mwanda
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/jvmti/jvmti_agent.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/tools/perf/jvmti/jvmti_agent.c b/tools/perf/jvmti/jvmti_agent.c
index 91bf333..55daeff 100644
--- a/tools/perf/jvmti/jvmti_agent.c
+++ b/tools/perf/jvmti/jvmti_agent.c
@@ -59,7 +59,6 @@ static int get_e_machine(struct jitheader *hdr)
ssize_t sret;
char id[16];
int fd, ret = -1;
-   int m = -1;
struct {
uint16_t e_type;
uint16_t e_machine;
@@ -81,11 +80,7 @@ static int get_e_machine(struct jitheader *hdr)
if (sret != sizeof(info))
goto error;
 
-   m = info.e_machine;
-   if (m < 0)
-   m = 0; /* ELF EM_NONE */
-
-   hdr->elf_mach = m;
+   hdr->elf_mach = info.e_machine;
ret = 0;
 error:
close(fd);

Re: [PATCH -v4 2/2] printk: Add kernel parameter to control writes to /dev/kmsg

[Borislav Petkov]

On Tue, Jul 19, 2016 at 08:35:07AM +0800, Dave Young wrote:
> Ok, for example below (A and B can be any program, systemd or other logging
> utility, dracut scripts...)

Are you even reading what I'm writing to you?

I asked for real-life use case and I told you the ratelimiting is done
by openers of /dev/kmsg.

> Program A:
> for (i = 0; i < 100; i++)
>   write an error message A1

Because this is a real use case, right? Write A1 100 times in a loop?!
You gotta be f*cking kidding me!

Now I'm going to ignore you know until you start reading what I'm
writing to you.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

[tip:perf/core] perf jit: Add missing curly braces

[tip-bot for Dan Carpenter]

Commit-ID:  e03141db361399619f9ee97e00d4c6fe2b472104
Gitweb: http://git.kernel.org/tip/e03141db361399619f9ee97e00d4c6fe2b472104
Author: Dan Carpenter 
AuthorDate: Sat, 16 Jul 2016 00:07:12 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 18 Jul 2016 12:20:00 -0300

perf jit: Add missing curly braces

It doesn't change the runtime behavior, but my static checker complains
that curly braces were intended.

Signed-off-by: Dan Carpenter 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: kernel-janit...@vger.kernel.org
Link: http://lkml.kernel.org/r/20160715210712.GA19522@mwanda
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/jvmti/jvmti_agent.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/jvmti_agent.c b/tools/perf/jvmti/jvmti_agent.c
index 3573f31..91bf333 100644
--- a/tools/perf/jvmti/jvmti_agent.c
+++ b/tools/perf/jvmti/jvmti_agent.c
@@ -491,10 +491,11 @@ jvmti_write_debug_info(void *agent, uint64_t code, const 
char *file,
if (sret != 1)
goto error;
}
-   if (padding_count)
+   if (padding_count) {
sret = fwrite_unlocked(pad_bytes, padding_count, 1, fp);
if (sret != 1)
goto error;
+   }
 
funlockfile(fp);
return 0;

Re: [PATCH 1/2] mem-hotplug: use GFP_HIGHUSER_MOVABLE in, alloc_migrate_target()

[Joonsoo Kim]

On Mon, Jul 18, 2016 at 04:31:11PM +0800, Xishi Qiu wrote:
> On 2016/7/18 16:05, Vlastimil Babka wrote:
> 
> > On 07/18/2016 10:00 AM, Xishi Qiu wrote:
> >> On 2016/7/18 13:51, Joonsoo Kim wrote:
> >>
> >>> On Fri, Jul 15, 2016 at 10:47:06AM +0800, Xishi Qiu wrote:
>  alloc_migrate_target() is called from migrate_pages(), and the page
>  is always from user space, so we can add __GFP_HIGHMEM directly.
> >>>
> >>> No, all migratable pages are not from user space. For example,
> >>> blockdev file cache has __GFP_MOVABLE and migratable but it has no
> >>> __GFP_HIGHMEM and __GFP_USER.
> >>>
> >>
> >> Hi Joonsoo,
> >>
> >> So the original code "gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;"
> >> is not correct?
> > 
> > It's not incorrect. GFP_USER just specifies some reclaim flags, and may 
> > perhaps restrict allocation through __GFP_HARDWALL, where the original
> > page could have been allocated without the restriction. But it doesn't put 
> > the place in an unexpected address range, as placing a non-highmem page 
> > into highmem could. __GFP_MOVABLE then just controls a heuristic for 
> > placement within a zone.
> > 
> >>> And, zram's memory isn't GFP_HIGHUSER_MOVABLE but has __GFP_MOVABLE.
> >>>
> >>
> >> Can we distinguish __GFP_MOVABLE or GFP_HIGHUSER_MOVABLE when doing
> >> mem-hotplug?
> > 
> > I don't understand the question here, can you rephrase with more detail? 
> > Thanks.
> > 
> 
> Hi Joonsoo,

Above is answered by Vlastimil. :)

> When we do memory offline, and the zone is movable zone,
> can we use "alloc_pages_node(nid, GFP_HIGHUSER_MOVABLE, 0);" to alloc a
> new page? the nid is the next node.

I don't know much about memory offline, but, AFAIK, memory offline
could happen on non-movable zone like as ZONE_NORMAL. Perhaps, you can add
"if zone of the page is movable zone then alloc with GFP_HIGHUSER_MOVABLE".

Thanks.

Re: [GIT PULL 00/15] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> From: Arnaldo Carvalho de Melo 
> 
> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Build stats:
> 
> [root@jouet 5]# perf stat dm
> alpine:3.4: Ok
> android-ndk:r12b: Ok
> centos:5: Ok
> centos:6: Ok
> centos:7: Ok
> debian:7: Ok
> debian:8: Ok
> debian:experimental: Ok
> fedora:21: Ok
> fedora:22: Ok
> fedora:23: Ok
> fedora:24: Ok
> fedora:rawhide: Ok
> mageia:5: Ok
> opensuse:13.2: Ok
> opensuse:42.1: Ok
> ubuntu:14.04.4: Ok
> ubuntu:15.10: Ok
> ubuntu:16.04: Ok
> ubuntu:16.04-x-armhf: Ok
> 
>  Performance counter stats for 'dm':
> 
>1896.227285  task-clock (msec) #0.002 CPUs utilized
>   
> 76,145  context-switches  #0.040 M/sec
>   
>  9,323  cpu-migrations#0.005 M/sec
>   
> 53,894  page-faults   #0.028 M/sec
>   
>  5,497,625,679  cycles#2.899 GHz  
>   
>  5,110,226,458  instructions  #0.93  insn per cycle   
>   
>950,036,839  branches  #  501.014 M/sec
>   
> 16,978,253  branch-misses #1.79% of all branches  
>   
> 
>  767.910393301 seconds time elapsed
> 
> [root@jouet 5]#
> 
> The following changes since commit 09211e2530ab4905ec16edecc27022d6b247419d:
> 
>   Merge tag 'perf-core-for-mingo-20160715' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2016-07-16 22:36:42 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-20160718
> 
> for you to fetch changes up to 988dd774dcbd9151c2a643fc7284c5c3c4d0adb7:
> 
>   perf tests: Add is_printable_array test (2016-07-18 19:50:35 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Properly report when a function wildcard produces no matches in 'perf probe'
>   (Masami Hiramatsu)
> 
> - Balance opening and reading events in 'perf stat', which could cause
>   it to get stuck trying to close invalid file descriptors (Mark Rutland)
> 
> Infrastructure:
> 
> - Copy more headers from the kernel, this time for headers that
>   were just including the contents of its kernel counterparts, should
>   help resolving the problems with linux-next, where some uapi related
>   patches seem to be breaking tools/object/ build.
> 
>   Some more combing will be done, but at least it is possible to build
>   perf out of tree, via a detached tarball (make help | grep perf)
>   without including kernel files in its MANIFEST (Arnaldo Carvalho de Melo)
> 
> - Fix smatch found errors that were not causing problems, but are
>   mistakes nonetheless (Dan Carpenter)
> 
> - Fix string vs byte array resolving in the python script code (Jiri Olsa)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (7):
>   perf tools: Add missing linux/compiler.h include to perf-sys.h
>   perf tools: Remove tools/perf/util/include/asm/byteorder.h
>   perf tools: Remove tools/perf/util/include/linux/const.h
>   Remove: kernel unistd*h files from perf's MANIFEST, not used
>   tools: Copy the bitops files accessed from the kernel and check for 
> drift
>   perf tools: Remove include/linux/list.h from perf's MANIFEST
>   tools: Copy linux/{hash,poison}.h and check for drift
> 
> Dan Carpenter (2):
>   perf jit: Add missing curly braces
>   perf jit: Remove some no-op error handling
> 
> Jiri Olsa (3):
>   perf script python: Fix string vs byte array resolving
>   perf tools: Make is_printable_array global
>   perf tests: Add is_printable_array test
> 
> Mark Rutland (2):
>   perf stat: Balance opening and reading events
>   perf cpu_map: Add more helpers
> 
> Masami Hiramatsu (1):
>   perf probe: Warn unmatched function filter correctly
> 
>  tools/include/asm-generic/bitops/__fls.h   |  44 -
>  tools/include/asm-generic/bitops/arch_hweight.h|  26 -
>  tools/include/asm-generic/bitops/const_hweight.h   |  44 -
>  tools/include/asm-generic/bitops/fls.h |  42 -
>  tools/include/asm-generic/bitops/fls64.h   |  37 +++-
>  tools/include/linux/hash.h   

linux-next: Tree for Jul 19

[Stephen Rothwell]

Hi all,

Changes since 20160718:

New tree: perf

The l2-mtd tree gained a build failure so I used the version from
next-20160718.

The crypto tree gained a conflict against the fsl tree.

The wireless-drivers-next tree gained a build failure for which I reverted
a commit.

The drm tree gained conflicts against the v4l-dvb tree.

The perf tree inherited a build failure from the tip tree, so I applied
the same fix patch.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 10256
 9534 files changed, 510574 insertions(+), 184291 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 239 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (47ef4ad2684d Merge tag 'for-linus-20160715' of 
git://git.infradead.org/linux-mtd)
Merging fixes/master (5edb56491d48 Linux 4.7-rc3)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as 
early as possible)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (8e6ce7ebeb34 net: cavium: liquidio: Avoid dma_unmap_single 
on uninitialized ndata)
Merging ipsec/master (8e6ce7ebeb34 net: cavium: liquidio: Avoid 
dma_unmap_single on uninitialized ndata)
Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging ipvs/master (3777ed688fba ipvs: fix bind to link-local mcast IPv6 
address in backup)
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation)
Merging sound-current/for-linus (76df52969711 ALSA: usb-audio: Fix quirks code 
is not called)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (92d21ac74a9e Linux 4.7-rc7)
Merging tty.current/tty-linus (a99cde438de0 Linux 4.7-rc6)
Merging usb.current/usb-linus (a99cde438de0 Linux 4.7-rc6)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (a99cde438de0 Linux 4.7-rc6)
Merging char-misc.current/char-misc-linus (33688abb2802 Linux 4.7-rc4)
Merging input-current/for-linus (6a5029e66404 Input: ts4800-ts - add missing 
of_node_put after calling of_parse_phandle)
Merging crypto-current/master (055ddaace035 crypto: user - re-add size check 
for CRYPTO_MSG_GETALG)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module

Re: [PATCH] arm64: dts: rockchip: add spiX aliases for rk3399

[Uwe Kleine-König]

Hello,

On Thu, Jul 14, 2016 at 06:24:33PM -0700, Brian Norris wrote:
> It's nicer to see this:
> 
> # ls -l /sys/bus/spi/devices/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi0.0 -> 
> ../../../devices/platform/ff1c.spi/spi_master/spi0/spi0.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi1.0 -> 
> ../../../devices/platform/ff1d.spi/spi_master/spi1/spi1.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi2.0 -> 
> ../../../devices/platform/ff1e.spi/spi_master/spi2/spi2.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi5.0 -> 
> ../../../devices/platform/ff20.spi/spi_master/spi5/spi5.0
> 
> than this:
> 
> # ls -l /sys/bus/spi/devices/
> total 0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi32763.0 -> 
> ../../../devices/platform/ff20.spi/spi_master/spi32763/spi32763.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi32764.0 -> 
> ../../../devices/platform/ff1e.spi/spi_master/spi32764/spi32764.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi32765.0 -> 
> ../../../devices/platform/ff1d.spi/spi_master/spi32765/spi32765.0
> lrwxrwxrwx 1 root root 0 Dec 31  1969 spi32766.0 -> 
> ../../../devices/platform/ff1c.spi/spi_master/spi32766/spi32766.0
> 
> With the latter, it's much clearer which bus devices are on.
> 
> Signed-off-by: Brian Norris 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 4c84229789ef..b04abbfd4898 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -70,6 +70,12 @@
>   serial2 = &uart2;
>   serial3 = &uart3;
>   serial4 = &uart4;
> + spi0 = &spi0;
> + spi1 = &spi1;
> + spi2 = &spi2;
> + spi3 = &spi3;
> + spi4 = &spi4;
> + spi5 = &spi5;

Note that Rob Herring (with his dt-maintainer hat on) doesn't like these
aliases.
See for example:
http://mid.gmane.org/20160705140546.GA10601@rob-hp-laptop

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

[Kristian Evensen]

On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum  wrote:
>> I had a look at some other drivers, and I think we need to be very
>> careful about making setting a random MAC too generic. For example, we
>> might be unlucky and break the possibly_iphdr()-code/assumption in
>> qmi_wwan.c. And there is probably more code/assumptions like that in
>> the network stack.
>
> In this case please use special cases for usbnet, too.
> We need a quirk.

I guess I can match on the VID/PID in usbnet, but won't it be cleaner
to add a new bind() function (in cdc_ether) which matches the two PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?

-Kristian

Re: [PATCH v3 09/17] mm, compaction: make whole_zone flag ignore cached scanner positions

[Joonsoo Kim]

On Mon, Jul 18, 2016 at 11:12:51AM +0200, Vlastimil Babka wrote:
> On 07/06/2016 07:09 AM, Joonsoo Kim wrote:
> >On Fri, Jun 24, 2016 at 11:54:29AM +0200, Vlastimil Babka wrote:
> >>A recent patch has added whole_zone flag that compaction sets when scanning
> >>starts from the zone boundary, in order to report that zone has been fully
> >>scanned in one attempt. For allocations that want to try really hard or 
> >>cannot
> >>fail, we will want to introduce a mode where scanning whole zone is 
> >>guaranteed
> >>regardless of the cached positions.
> >>
> >>This patch reuses the whole_zone flag in a way that if it's already passed 
> >>true
> >>to compaction, the cached scanner positions are ignored. Employing this flag
> >
> >Okay. But, please don't reset cached scanner position even if whole_zone
> >flag is set. Just set cc->migrate_pfn and free_pfn, appropriately. With
> 
> Won't that result in confusion on cached position updates during
> compaction where it checks the previous cached position? I wonder
> what kinds of corner cases it can bring...

whole_zone would come along with ignore_skip_hint so I think that
there is no problem on cached position updating.

> 
> >your following patches, whole_zone could be set without any compaction
> >try
> 
> I don't understand what you mean here? Even after whole series,
> whole_zone is only checked, and positions thus reset, after passing
> the compaction_suitable() call from compact_zone(). So at that point
> we can say that compaction is being actually tried and it's not a
> drive-by reset?

My point is that we should not initialize zone's cached pfn in case of
the whole_zone because what compaction with COMPACT_PRIO_SYNC_FULL
want is just to scan whole range. zone's cached pfn exists for
efficiency and there is no reason to initialize it by compaction with
COMPACT_PRIO_SYNC_FULL. If there are some parallel compaction users,
they could be benefit from un-initialized zone's cached pfn so I'd
like to leave them.

Thanks.

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

[Geert Uytterhoeven]

On Tue, Jul 19, 2016 at 6:52 AM, Greg Ungerer  wrote:
> Seeing as you have modified quite a few printk calls is it worth
> while annotating them with appropriate KERN_ERR, KERN_INFO, etc?

You mean pr_err(), pr_info(), ... ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: linux-next: build failure after merge of the wireless-drivers-next tree

[Kalle Valo]

Stephen Rothwell  writes:

> After merging the wireless-drivers-next tree, today's linux-next build
> (powerpc allyesconfig) failed like this:
>
> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of 
> function 'ioremap_cache' [-Werror=implicit-function-declaration]
>   b47s->window = ioremap_cache(res->start, resource_size(res));
>  ^
> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer 
> from integer without a cast [-Wint-conversion]
>   b47s->window = ioremap_cache(res->start, resource_size(res));
>^
>
> Caused by commit
>
>   57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>
> I have reverted that commit for today.

Thanks, kbuild bot also notified about this.

Rafał, as the merge window is getting really close I would like to
revert this for now and we can reapply it once we the problem is fully
solved. And we can use my pending branch for build testing the patch
with kbuild bot. What do you think?

-- 
Kalle Valo

[PATCH v6] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
Acked-by: Rob Herring 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select 
v2->instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip 
v3->select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 123 ++---
 2 files changed, 137 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for 
+wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
 &spi1 {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <&gpio3>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <&vwlan_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+&spi0 {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <&gpio0>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <&vwlan_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared 
+ to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for 
+ wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */  #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
   

Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

[Marek Szyprowski]

Hi Tobias


On 2016-07-18 18:43, Tobias Jakobi wrote:

Marek Szyprowski wrote:

On 2016-07-18 13:00, Tobias Jakobi wrote:

Marek Szyprowski wrote:

On 2016-07-15 15:21, Tobias Jakobi wrote:

Tobias Jakobi wrote:

Hello Marek,

I've tested the patchset on 4.7-rc7 and noticed that it breaks
reboot on
my ODROID-X2.

Going to check where exactly things break.

Sadly it's the last patch where everything comes together:
"iommu/exynos: Add proper runtime pm support"

I still have to check if forcing runpm status to 'on' makes a
difference. I suspect that the aggressive clock gating might be the
reason?

Thanks for testing. I will check this issue. Could you send me your
.config?

This is the config I'm currently using:
https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf


Do you think checking this with no_console_suspend makes sense?

no_console_suspend switch won't provide more information, but I managed
to reproduce your issue. I'm really confused how enabling runtime pm can
cause problems with usb/smsc95xx ethernet driver (that is the reason for
failed reboot). Maybe it is somehow related to the global relations
between devices and drivers and the fact that creating the runtime pm
links change the order of operations. I will check this again when
Rafael send updated patches. Here is the log I got (after waiting some
time):

thanks for looking into this! I'll try to reproduce this on my board. I
have to admit that I didn't wait too long for the hung task message to
appear.

I wonder if this has something to do with regulator code cutting some
supplies too early. Is this on a X2 or a U2/U3?


I've reproduced it on U3.


I'm not sure if we
currently model the regulator setup correctly here (IIRC then buck8 is
supplying the LAN/USB block on U2/U3).


IMHO it is not really related to regulator operations, but the sequence
of shutting down logical devices in the system. For some reasons when pm 
links

are used, something changes the order of operations in system shutdown
procedure, what causes smsc95xx to hang. I have no idea why, but I don't 
have

time to investigate it further. I will wait for the next release of Rafael's
pm links patches and then check everything again.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

[Oliver Neukum]

On Mon, 2016-07-18 at 17:04 +0200, Kristian Evensen wrote:
> On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum  wrote:
> >> Ok, sounds good. So far, I have only seen the random MAC issue with
> >> the three previously mentioned devices, but who knows how many else is
> >> out there with the same error ... I don't think it should be in the
> >> core ethernet code, at least not yet, but I agree it would make sense
> >> to move it to for example usbnet_core(). If you agree, I can prepare a
> >> patch for it.
> >
> > I don't see how it would be specific for a subsystem. If the patch
> > is correct, it belongs into the networking core.
> 
> I had a look at some other drivers, and I think we need to be very
> careful about making setting a random MAC too generic. For example, we
> might be unlucky and break the possibly_iphdr()-code/assumption in
> qmi_wwan.c. And there is probably more code/assumptions like that in
> the network stack.

In this case please use special cases for usbnet, too.
We need a quirk.

Regards
Oliver

Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support

[Peter Meerwald-Stadler]

> > comments below; nice addition
> >
> > it seems this patch clashes with the recent changes to this driver in
> > iio-testing; can you rebase on top please?
> 
> Where is iio-testing? I couldn't found it in linux.

https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/log/?h=testing

p. 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [RFCv2 3/4] perf: util: only open events on CPUs an evsel permits

[Jiri Olsa]

On Mon, Jul 18, 2016 at 07:46:04PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jul 18, 2016 at 04:32:59PM +0200, Jiri Olsa escreveu:
> > On Fri, Jul 15, 2016 at 11:08:12AM +0100, Mark Rutland wrote:
> > > In systems with heterogeneous CPU PMUs, it's possible for each evsel to
> > > cover a distinct set of CPUs, and hence the cpu_map associated with each
> > > evsel may have a distinct idx<->id mapping. Any of these may be distinct 
> > > from
> > > the evlist's cpu map.
> > > 
> > > Events can be tied to the same fd so long as they use the same per-cpu
> > > ringbuffer (i.e. so long as they are on the same CPU). To acquire the
> > > correct FDs, we must compare the Linux logical IDs rather than the evsel
> > > or evlist indices.
> > > 
> > > This path adds logic to perf_evlist__mmap_per_evsel to handle this,
> > > translating IDs as required. As PMUs may cover a subset of CPUs from the
> > > evlist, we skip the CPUs a PMU cannot handle.
> > > 
> > > Signed-off-by: Mark Rutland 
> > > Cc: Adrian Hunter 
> > > Cc: Alexander Shishkin 
> > > Cc: Arnaldo Carvalho de Melo 
> > > Cc: He Kuang 
> > > Cc: Ingo Molnar 
> > > Cc: Jiri Olsa 
> > > Cc: Peter Zijlstra 
> > > Cc: Wang Nan 
> > > Cc: linux-kernel@vger.kernel.org
> > 
> > Acked-by: Jiri Olsa 
> 
> Applied the first two, this one is not applying, please check my
> perf/core branch, what is there should soon be pushed to Ingo, so
> tip/perf/core may be ok too.

ouch, forgot to mentioned that.. 3rd one did not apply because
of the backward maps we just merged in, I changed it for my review,
but it needs repost

jirka

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

[Alexei Starovoitov]

On Mon, Jul 18, 2016 at 03:57:17AM -0700, Sargun Dhillon wrote:
> 
> 
> On Sun, 17 Jul 2016, Alexei Starovoitov wrote:
> 
> >On Sun, Jul 17, 2016 at 03:19:13AM -0700, Sargun Dhillon wrote:
> >>
> >>+static u64 bpf_copy_to_user(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> >>+{
> >>+   void *to = (void *) (long) r1;
> >>+   void *from = (void *) (long) r2;
> >>+   int  size = (int) r3;
> >>+
> >>+   /* check if we're in a user context */
> >>+   if (unlikely(in_interrupt()))
> >>+   return -EINVAL;
> >>+   if (unlikely(!current->pid))
> >>+   return -EINVAL;
> >>+
> >>+   return copy_to_user(to, from, size);
> >>+}
> >
> >thanks for the patch, unfortunately it's not that straightforward.
> >copy_to_user might fault. Try enabling CONFIG_DEBUG_ATOMIC_SLEEP and
> >you'll see the splat since bpf programs are protected by rcu.
> >Also 'current' can be null and I'm not sure what current->pid does.
> >So the writing to user memory either has to be verified to avoid
> >sleeping and faults or we need to use something like task_work_add
> >mechanism. Ideas are certainly welcome.
> >
> >
> From casual inspection, I can't find where current can be null when
> in_interrupt() is false. Although, we can check before dereferencing it.
> When not in a user context, the pid of the task struct returns 0.
> 
> As far as preventing sleep, would the following alteration do? Or do we
> actually need something more sophisticated?
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index be89c148..45878f3 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -86,14 +86,19 @@ static u64 bpf_copy_to_user(u64 r1, u64 r2, u64 r3, u64
> r4, u64 r5)
> void *to = (void *) (long) r1;
> void *from = (void *) (long) r2;
> int  size = (int) r3;
> +   struct task_struct *task = current;
> 
> /* check if we're in a user context */
> if (unlikely(in_interrupt()))
> return -EINVAL;
> -   if (unlikely(!current->pid))
> +   if (unlikely(!task || !task->pid))
> return -EINVAL;
> 
> -   return copy_to_user(to, from, size);
> +   /* Is this a user address, or a kernel address? */
> +   if (!access_ok(VERIFY_WRITE, to, size))
> +   return -EINVAL;
> +
> +   return probe_kernel_write(to, from, size);
>  }

I think it can actually work. The only concern is that comment
in access_ok() says that it may sleep whereas I couldn't find
any arch where that would be the case.
Could you please send an official patch with detailed commit log?

Re: [PATCH 1/1] iio: vcnl4000: Add IR current adjust support

[Pratik Prajapati]

On Tue, Jul 19, 2016 at 3:50 AM, Peter Meerwald-Stadler
 wrote:
>
>> Signed-off-by: Pratik Prajapati 
>
> comments below; nice addition
>
> it seems this patch clashes with the recent changes to this driver in
> iio-testing; can you rebase on top please?

Where is iio-testing? I couldn't found it in linux.

linux-next: build failure after merge of the wireless-drivers-next tree

[Stephen Rothwell]

Hi all,

After merging the wireless-drivers-next tree, today's linux-next build
(powerpc allyesconfig) failed like this:

drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of 
function 'ioremap_cache' [-Werror=implicit-function-declaration]
  b47s->window = ioremap_cache(res->start, resource_size(res));
 ^
drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer 
from integer without a cast [-Wint-conversion]
  b47s->window = ioremap_cache(res->start, resource_size(res));
   ^

Caused by commit

  57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] HID: sony: disable descriptor fixup for FutureMax Dance Mat

[Mikko Perttunen]

On 07/18/16 17:28, Benjamin Tissoires wrote:

On Jul 17 2016 or thereabouts, Mikko Perttunen wrote:

From: Mikko Perttunen 
...
 #include 
 #include 
 #include 
+#include 
+
+#include "usbhid/usbhid.h"


I spent a lot of effort 2 years ago to remove the usb dependency, I'd
prefer not adding a strong deps on it again.



I see, I'll remove it.



 #include "hid-ids.h"

@@ -51,6 +54,7 @@
 #define NAVIGATION_CONTROLLER_USB BIT(9)
 #define NAVIGATION_CONTROLLER_BT  BIT(10)
 #define SINO_LITE_CONTROLLER  BIT(11)
+#define FUTUREMAX_DANCE_MAT   BIT(12)

 #define SIXAXIS_CONTROLLER (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)
 #define MOTION_CONTROLLER (MOTION_CONTROLLER_USB | MOTION_CONTROLLER_BT)
@@ -1125,7 +1129,7 @@ static u8 *sony_report_fixup(struct hid_device *hdev, u8 
*rdesc,
 {
struct sony_sc *sc = hid_get_drvdata(hdev);

-   if (sc->quirks & SINO_LITE_CONTROLLER)
+   if (sc->quirks & (SINO_LITE_CONTROLLER | FUTUREMAX_DANCE_MAT))
return rdesc;

/*
@@ -2288,6 +2292,15 @@ static int sony_probe(struct hid_device *hdev, const 
struct hid_device_id *id)
unsigned long quirks = id->driver_data;
struct sony_sc *sc;
unsigned int connect_mask = HID_CONNECT_DEFAULT;
+   struct usb_device *usb_dev;
+
+   if (quirks & SIXAXIS_CONTROLLER_USB) {
+   usb_dev = hid_to_usb_dev(hdev);
+   if (usb_dev && usb_dev->product &&
+   !strcmp(usb_dev->product, "FutureMax Dance Mat")) {i


If they decided to reuse the same PID than one existing, and you have no
other choice but to rely on the name, you can simply have a match on
hdev->name instead of adding the USB dependency.


Ah, didn't notice this!



Also, I think it would be better to have a check on the existing report
descriptor instead of blindly fixing it. Other drivers make sure they
are fixing the correct region before overriding it, but I think using a
md5sum might be just easier (though that's not required for your patch I
think).


I agree. In fact, the mat used to work back in 3.15 when the driver did 
some rudimentary checks before overwriting the descriptor. In any case, 
it would be difficult for me to add the checks since the mat is the only 
piece of hardware I own that is handled by this driver.




Cheers,
Benjamin


 ...


Cheers, and thanks for the review! I'll post a v2 once I get the chance.

Mikko

scripts/extract-cert.c:23:25: fatal error: openssl/bio.h: No such file or directory

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   47ef4ad2684d380dd6d596140fb79395115c3950
commit: 770f2b98760ef0500183d7206724aac762433e2d modsign: Use extract-cert to 
process CONFIG_SYSTEM_TRUSTED_KEYS
date:   11 months ago
config: x86_64-randconfig-a0-07191214 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout 770f2b98760ef0500183d7206724aac762433e2d
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> scripts/extract-cert.c:23:25: fatal error: openssl/bio.h: No such file or 
>> directory
#include 
^
   compilation terminated.
   make[2]: *** [scripts/extract-cert] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [scripts] Error 2
   make[1]: Target 'modules_prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +23 scripts/extract-cert.c

1329e8cc David Woodhouse 2015-07-20   7   *  David Woodhouse 

1329e8cc David Woodhouse 2015-07-20   8   *
1329e8cc David Woodhouse 2015-07-20   9   * This program is free software; you 
can redistribute it and/or
1329e8cc David Woodhouse 2015-07-20  10   * modify it under the terms of the 
GNU General Public Licence
1329e8cc David Woodhouse 2015-07-20  11   * as published by the Free Software 
Foundation; either version
1329e8cc David Woodhouse 2015-07-20  12   * 2 of the Licence, or (at your 
option) any later version.
1329e8cc David Woodhouse 2015-07-20  13   */
1329e8cc David Woodhouse 2015-07-20  14  #define _GNU_SOURCE
1329e8cc David Woodhouse 2015-07-20  15  #include 
1329e8cc David Woodhouse 2015-07-20  16  #include 
1329e8cc David Woodhouse 2015-07-20  17  #include 
1329e8cc David Woodhouse 2015-07-20  18  #include 
1329e8cc David Woodhouse 2015-07-20  19  #include 
1329e8cc David Woodhouse 2015-07-20  20  #include 
1329e8cc David Woodhouse 2015-07-20  21  #include 
1329e8cc David Woodhouse 2015-07-20  22  #include 
1329e8cc David Woodhouse 2015-07-20 @23  #include 
1329e8cc David Woodhouse 2015-07-20  24  #include 
1329e8cc David Woodhouse 2015-07-20  25  #include 
1329e8cc David Woodhouse 2015-07-20  26  #include 
1329e8cc David Woodhouse 2015-07-20  27  #include 
1329e8cc David Woodhouse 2015-07-20  28  #include 
1329e8cc David Woodhouse 2015-07-20  29  
1329e8cc David Woodhouse 2015-07-20  30  #define PKEY_ID_PKCS7 2
1329e8cc David Woodhouse 2015-07-20  31  

:: The code at line 23 was first introduced by commit
:: 1329e8cc69b93a0b1bc6d197b30dcff628c18dbf modsign: Extract signing cert 
from CONFIG_MODULE_SIG_KEY if needed

:: TO: David Woodhouse 
:: CC: David Howells 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [mtd-next:master 30/33] drivers/mtd/spi-nor/cadence-quadspi.c:529:4: error: implicit declaration of function 'readsl'

[Stefan Roese]

On 18.07.2016 22:20, Brian Norris wrote:

On Tue, Jul 19, 2016 at 03:43:17AM +0800, kbuild test robot wrote:

tree:   git://git.infradead.org/linux-mtd-next.git master
head:   f78921b9020c510ed222a6c2402e2aa126432415
commit: 140623410536905fa6ab737b625decfde6c64a72 [30/33] mtd: spi-nor: Add 
driver for Cadence Quad SPI Flash Controller
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
 git checkout 140623410536905fa6ab737b625decfde6c64a72
 # save the attached .config to linux build tree
 make ARCH=x86_64

All errors (new ones prefixed by >>):

drivers/mtd/spi-nor/cadence-quadspi.c: In function 
'cqspi_indirect_read_execute':

drivers/mtd/spi-nor/cadence-quadspi.c:529:4: error: implicit declaration of 
function 'readsl' [-Werror=implicit-function-declaration]

readsl(ahb_base, rxbuf, DIV_ROUND_UP(bytes_to_read, 4));
^~
drivers/mtd/spi-nor/cadence-quadspi.c: In function 
'cqspi_indirect_write_execute':

drivers/mtd/spi-nor/cadence-quadspi.c:613:3: error: implicit declaration of 
function 'writesl' [-Werror=implicit-function-declaration]

   writesl(cqspi->ahb_base, txbuf, DIV_ROUND_UP(write_bytes, 4));
   ^~~
cc1: some warnings being treated as errors


Hmm, does x86 not define readsl()/writesl()? I can never tell what
accessors are supposed to be "standard" across architectures.

Either we need to drop the COMPILE_TEST or maybe make it (!X86 &&
COMPILE_TEST).


iowrite32_rep() etc should work for x86 as well.

Thanks,
Stefan

RE: Re: [V3 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Monday, July 18, 2016 6:02 PM
> On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for your reply.
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > > Sent: Wednesday, July 13, 2016 11:04 AM
> > >
> > > On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > Hi Dave,
> > > >
> > > > Thanks for the comments.
> > > >
> > > > > From: Dave Young [mailto:dyo...@redhat.com]
> > > > > Sent: Monday, July 11, 2016 5:35 PM
> > > > >
> > > > > On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
[snip] 
> > > > > As for this patch I'm not sure it is safe to replace the
> > > > > smp_send_stop with the kdump friendly function. I'm also not sure if
> > > > > the kdump friendly function is safe for kdump. Will glad to hear
> > > > > opinions from other arch experts.
> > > >
> > > > This stuff depends on architectures, so I speak only about
> > > > x86 (the logic doesn't change on other architectures at this time).
> > > >
> > > > kdump path with crash_kexec_post_notifiers disabled:
> > > >  panic()
> > > >__crash_kexec()
> > > >  crash_setup_regs()
> > > >  crash_save_vmcoreinfo()
> > > >  machine_crash_shutdown()
> > > >native_machine_crash_shutdown()
> > > >  panic_smp_send_stop() /* mostly same as original
> > > > * kdump_nmi_shootdown_cpus()
> > > > */
> > > >
> > > > kdump path with crash_kexec_post_notifiers enabled:
> > > >  panic()
> > > >panic_smp_send_stop()
> > > >__crash_kexec()
> > > >  crash_setup_regs()
> > > >  crash_save_vmcoreinfo()
> > > >  machine_crash_shutdown()
> > > >native_machine_crash_shutdown()
> > > >  panic_smp_send_stop() // do nothing
> > > >
> > > > The difference is that stopping other CPUs before crash_setup_regs()
> > > > and crash_save_vmcoreinfo() or not.  Since crash_setup_regs() and
> > > > crash_save_vmcoreinfo() just save information to some memory area,
> > > > they wouldn't be affected by panic_smp_send_stop().  This means
> > > > placing panic_smp_send_stop before __crash_kexec is safe.
> > > >
> > > > BTW, I noticed my patch breaks Xen kernel.  I'll fix it in the next
> > > > version.
> > >
> > > But it does breaks stuff which depends on cpu not being disabled like 
> > > problem 1 you mentioned in patch log.
> >
> > As I mentioned in the description of this patch, we should stop
> > other CPUs ASAP to preserve current state either
> > crash_kexec_post_notifiers is enabled or not.
> > Then, all remaining procedures should work well
> > after stopping other CPUs (but keep the CPU map online).
> >
> > Vivek also mentioned similar things:
> > https://lkml.org/lkml/2015/7/14/433
> 
> The implementation in this patchset is different from suggestion in above 
> link?
> 
> I think Vivek's suggestion is a good idea, to drop smp_send_stop and do below:
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
>   crash_kexec()
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> I'm just commenting from code flow point of view, the detail implementation
> definitely need more comments from Arch experts.
> 
> Any reason did not move the kdump friendly function to earlier point like
> before previous __crash_kexec() below?
> if (!crash_kexec_post_notifiers) {
> printk_nmi_flush_on_panic();
> __crash_kexec(NULL);
> }

The reason why the implementation differs from Vivek's is to keep
the current code flow if crash_kexec_post_notifiers is not specified.

If we apply Vivek's or your suggestion, it may always cause kdump
to fail on MIPS OCTEON due to Problem 1.  I don't want to make things
any worse.  I may post a patch for MIPS OCTEON, but I can't test it.
For other architectures, I'm not sure what problems there are.
So at first, I want to fix the case where crash_kexec_post_notifiers is
specified on x86.  Then, if all other architectures support
`stop other CPUs before crash_kexec', switch to your or Vivek's
suggesting code.

Is this acceptable?

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or directory

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   47ef4ad2684d380dd6d596140fb79395115c3950
commit: 283e8ba2dfde54f8f27d7d0f459a07de79a39d55 MODSIGN: Change from CMS to 
PKCS#7 signing if the openssl is too old
date:   10 months ago
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
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 283e8ba2dfde54f8f27d7d0f459a07de79a39d55
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or 
>> directory
   compilation terminated.
   make[2]: *** [scripts/sign-file] Error 1
   scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or 
directory
   compilation terminated.
   make[2]: *** [scripts/extract-cert] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [scripts] Error 2
   :1298:2: warning: #warning syscall userfaultfd not implemented [-Wcpp]
   :1301:2: warning: #warning syscall membarrier not implemented [-Wcpp]
   make[1]: Target 'modules_prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +23 scripts/sign-file.c

17  #include 
18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
  > 23  #include 
24  #include 
25  #include 
26  #include 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

[Jaegeuk Kim]

On Mon, Jul 18, 2016 at 08:59:52PM -0700, Christoph Hellwig wrote:
> On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote:
> > >From kernel guys working on android.
> 
> Well, until it's mainline it simply doesn't matter, so NAK to this
> patch.  Tying power behavior to plugs also sounds pretty broken, so we'd
> probably come up with something better if they bothered to actually
> submit their patches upsteam or at least explaining what they want
> to archive.

Actually, the initial patch which drops plugs is not mainlined as well.
So, at this time, I just want to revert it by this patch, since I recognized
that there might be whatever possible use-cases of plugs in another way someday.
So for now, I lost the reason to eliminate the plugs.

Moreover, since every filesystems use plugs, f2fs doesn't need to be an
exceptional case in terms of that (except hm-smr). So, let me sync f2fs
with other filesystems at this moment.

I totally agree that it'd be best to see their patches upstream, but I've
witnessed that it becomes a quite tough challenge to them.

Thanks,

[Patch-V2 1/3] cxgb4: Add Chelsio LLD support Chelsio Crypto ULD

[Yeshaswi M R Gowda]

The Chelsio crypto driver is an Upper Layer Driver (ULD), making use
of the Chelsio Lower Layer Driver (LLD - cxgb4). The LLD facilitates
the basic infrastructure services of the ULD. These services include
queue allocation, deallocation and registration with LLD. The queues
are used for sending the crypto requests to the Chelsio's hardware
and for receiving the responses from the hardware.

This patch enables the services mentioned for the Chelsio's crypto
driver.

Signed-off-by: Yeshaswi M R Gowda 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |   18 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c |   41 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c|   80 +++-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h |   10 +
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |   64 +++
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h|  437 
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h  |  131 +-
 7 files changed, 770 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index b4fceb9..4de1e39 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -346,6 +346,8 @@ struct adapter_params {
 
unsigned int max_ordird_qp;   /* Max read depth per RDMA QP */
unsigned int max_ird_adapter; /* Max read depth per adapter */
+
+   unsigned char ulp_crypto_lookaside; /* crypto lookaside support */
 };
 
 /* State needed to monitor the forward progress of SGE Ingress DMA activities
@@ -435,7 +437,7 @@ enum {
MAX_CTRL_QUEUES = NCHAN,  /* # of control Tx queues */
MAX_RDMA_QUEUES = NCHAN,  /* # of streaming RDMA Rx queues */
MAX_RDMA_CIQS = 32,/* # of  RDMA concentrator IQs */
-
+   MAX_CRYPTO_QUEUES = 32,   /* # of crypto queues */
/* # of streaming iSCSIT Rx queues */
MAX_ISCSIT_QUEUES = MAX_OFLD_QSETS,
 };
@@ -455,7 +457,8 @@ enum {
INGQ_EXTRAS = 2,/* firmware event queue and */
/*   forwarded interrupts */
MAX_INGQ = MAX_ETH_QSETS + MAX_OFLD_QSETS + MAX_RDMA_QUEUES +
-  MAX_RDMA_CIQS + MAX_ISCSIT_QUEUES + INGQ_EXTRAS,
+  MAX_RDMA_CIQS + MAX_ISCSIT_QUEUES + INGQ_EXTRAS +
+  MAX_CRYPTO_QUEUES,
 };
 
 struct adapter;
@@ -509,6 +512,10 @@ enum { /* adapter flags */
FW_OFLD_CONN   = (1 << 9),
 };
 
+enum {
+   ULP_CRYPTO_LOOKASIDE = 1 << 0,
+};
+
 struct rx_sw_desc;
 
 struct sge_fl { /* SGE free-buffer queue state */
@@ -682,10 +689,12 @@ struct sge_ctrl_txq {   /* state for an SGE 
control Tx queue */
 struct sge {
struct sge_eth_txq ethtxq[MAX_ETH_QSETS];
struct sge_ofld_txq ofldtxq[MAX_OFLD_QSETS];
+   struct sge_ofld_txq cryptotxq[MAX_CRYPTO_QUEUES];
struct sge_ctrl_txq ctrlq[MAX_CTRL_QUEUES];
 
struct sge_eth_rxq ethrxq[MAX_ETH_QSETS];
struct sge_ofld_rxq iscsirxq[MAX_OFLD_QSETS];
+   struct sge_ofld_rxq cryptorxq[MAX_CRYPTO_QUEUES];
struct sge_ofld_rxq iscsitrxq[MAX_ISCSIT_QUEUES];
struct sge_ofld_rxq rdmarxq[MAX_RDMA_QUEUES];
struct sge_ofld_rxq rdmaciq[MAX_RDMA_CIQS];
@@ -699,10 +708,12 @@ struct sge {
u16 ethtxq_rover;   /* Tx queue to clean up next */
u16 iscsiqsets;  /* # of active iSCSI queue sets */
u16 niscsitq;   /* # of available iSCST Rx queues */
+   u16 ncryptoq;   /* # of available lookaside crypto queues */
u16 rdmaqs; /* # of available RDMA Rx queues */
u16 rdmaciqs;   /* # of available RDMA concentrator IQs */
u16 iscsi_rxq[MAX_OFLD_QSETS];
u16 iscsit_rxq[MAX_ISCSIT_QUEUES];
+   u16 crypto_rxq[MAX_CRYPTO_QUEUES];
u16 rdma_rxq[MAX_RDMA_QUEUES];
u16 rdma_ciq[MAX_RDMA_CIQS];
u16 timer_val[SGE_NTIMERS];
@@ -732,6 +743,7 @@ struct sge {
 #define for_each_iscsitrxq(sge, i) for (i = 0; i < (sge)->niscsitq; i++)
 #define for_each_rdmarxq(sge, i) for (i = 0; i < (sge)->rdmaqs; i++)
 #define for_each_rdmaciq(sge, i) for (i = 0; i < (sge)->rdmaciqs; i++)
+#define for_each_cryptorxq(sge, i) for (i = 0; i < (sge)->ncryptoq; i++)
 
 struct l2t_data;
 
@@ -1441,7 +1453,7 @@ int t4_fw_bye(struct adapter *adap, unsigned int mbox);
 int t4_early_init(struct adapter *adap, unsigned int mbox);
 int t4_fw_reset(struct adapter *adap, unsigned int mbox, int reset);
 int t4_fixup_host_params(struct adapter *adap, unsigned int page_size,
- unsigned int cache_line_size);
+unsigned int cache_line_size);
 int t4_fw_initialize(struct adapter *adap, unsigned int mbox);
 int t4_query_params(struct adapter *adap, unsigned int mbox, unsigned int pf,
unsigned int vf, unsigned 

Re: [PATCH] net/sched/sch_htb: clamp xstats tokens to fit into 32-bit int

[David Miller]

From: Konstantin Khlebnikov 
Date: Sat, 16 Jul 2016 17:08:56 +0300

> In kernel HTB keeps tokens in signed 64-bit in nanoseconds. In netlink
> protocol these values are converted into pshed ticks (64ns for now) and
> truncated to 32-bit. In struct tc_htb_xstats fields "tokens" and "ctokens"
> are declared as unsigned 32-bit but they could be negative thus tool 'tc'
> prints them as signed. Big values loose higher bits and/or become negative.
> 
> This patch clamps tokens in xstat into range from INT_MIN to INT_MAX.
> In this way it's easier to understand what's going on here.
> 
> Signed-off-by: Konstantin Khlebnikov 

Applied.

[Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

[Yeshaswi M R Gowda]

The Chelsio's Crypto Hardware can perform the following operations:
SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224),
HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC,
AES-256-CBC, AES-128-XTS, AES-256-XTS

This patch implements the driver for above mentioned features. This
driver is an Upper Layer Driver which is attached to Chelsio's LLD
(cxgb4) and uses the queue allocated by the LLD for sending the crypto
requests to the Hardware and receiving the responses from it.

The crypto operations can be performed by Chelsio's hardware from the
userspace applications and/or from within the kernel space using the
kernel's crypto API.

The above mentioned crypto features have been tested using kernel's
tests mentioned in testmgr.h. They also have been tested from user
space using libkcapi and Openssl.

Signed-off-by: Yeshaswi M R Gowda 
---
 drivers/crypto/chelsio/Kconfig   |   21 +
 drivers/crypto/chelsio/Makefile  |4 +
 drivers/crypto/chelsio/chcr_algo.c   | 1509 ++
 drivers/crypto/chelsio/chcr_algo.h   |  503 
 drivers/crypto/chelsio/chcr_core.c   |  268 ++
 drivers/crypto/chelsio/chcr_core.h   |   80 ++
 drivers/crypto/chelsio/chcr_crypto.h |  204 +
 7 files changed, 2589 insertions(+)
 create mode 100644 drivers/crypto/chelsio/Kconfig
 create mode 100644 drivers/crypto/chelsio/Makefile
 create mode 100644 drivers/crypto/chelsio/chcr_algo.c
 create mode 100644 drivers/crypto/chelsio/chcr_algo.h
 create mode 100644 drivers/crypto/chelsio/chcr_core.c
 create mode 100644 drivers/crypto/chelsio/chcr_core.h
 create mode 100644 drivers/crypto/chelsio/chcr_crypto.h

diff --git a/drivers/crypto/chelsio/Kconfig b/drivers/crypto/chelsio/Kconfig
new file mode 100644
index 000..4266cb2
--- /dev/null
+++ b/drivers/crypto/chelsio/Kconfig
@@ -0,0 +1,21 @@
+config CRYPTO_DEV_CHELSIO
+   tristate "Chelsio Crypto Co-processor Driver"
+   depends on PCI && NETDEVICES && ETHERNET
+   select CRYPTO_SHA1
+   select CRYPTO_SHA256
+   select CRYPTO_SHA512
+   select NET_VENDOR_CHELSIO
+   select CHELSIO_T4
+   ---help---
+ The Chelsio Crypto Co-processor driver for T6 adapters.
+
+ For general information about Chelsio and our products, visit
+ our website at .
+
+ For customer support, please visit our customer support page at
+ .
+
+ Please send feedback to .
+
+ To compile this driver as a module, choose M here: the module
+ will be called chcr.
diff --git a/drivers/crypto/chelsio/Makefile b/drivers/crypto/chelsio/Makefile
new file mode 100644
index 000..7e4fda5
--- /dev/null
+++ b/drivers/crypto/chelsio/Makefile
@@ -0,0 +1,4 @@
+ ccflags-y := -Idrivers/net/ethernet/chelsio/cxgb4
+
+ obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chcr.o
+ chcr-objs :=  chcr_core.o chcr_algo.o
\ No newline at end of file
diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
new file mode 100644
index 000..a327b53
--- /dev/null
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -0,0 +1,1509 @@
+/*
+ * This file is part of the Chelsio T6 Crypto driver for Linux.
+ *
+ * Copyright (c) 2003-2016 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * Written and Maintained by:
+ * Manoj Malviya (manojmalv...@chelsio.com)
+ * Atul Gupta (atul.gu...@chelsio.com)
+ * Jitendra Lulla (jlu...@chelsio.com)
+ * Yeshaswi M R Gowda (yesha...@chelsio.com)
+ * Harsh Jain (ha...@chelsio.com)
+ */
+
+#defi

[Patch-V2 0/3] crypto/chcr: Add Chelsio Crypto Driver

[Yeshaswi M R Gowda]

Hi Herbert,

This patch series contains 3 patches that add support for Chelsio's
Crypto Hardware.

The patch series has been created against Herbert Xu's tree (crypto-2.6).
It includes patches for Chelsio Low Level Driver(cxgb4) and adds the new
crypto Upper Layer Driver(chcr) under a new directory drivers/crypto/chelsio.

The first of the patch series implements necessary changes in the Chelsio
LLD for queue allocation, deallocation and registration of the ULD.

The second patch implements the Chelsio crypto driver.

The third patch contains the changes to the driver/crypto/Kconfig and
drivers/crypto/Makefile to enable the Chelsio Crypto driver.

We have included all the maintainers of respective drivers. Kindly
review the changes and provide feedback on the same.

Thank you Joe Perches and Herbert Xu for your review, I have made appropriate
changes based on them.

[V1 -> V2]

1. Some residual code cleanup
2. Adds pr_fmt with chcr (KBUILD_MODNAME) added
3. Changes var name to accomodate them <80 columns in the chcr_register_alg
4. Support for printing the crypto queue stats
5. Fix compile warnings reported by kbuild bot for certain architectures
6. Dependency fix in Kconfig.
7. If the request has the MAY_BACKLOG bit set and hardware queue is full the 
request
   is queued up else -EBUSY is returned to throttle the user. The queue when 
executed
   and processed returns -EINPROGRESS in completion.

Yeshaswi M R Gowda (3):
  cxgb4: Add Chelsio LLD support Chelsio Crypto ULD
  chcr: Support for Chelsio's Crypto Hardware
  crypto: Added Chelsio Menu to the Kconfig file

 drivers/crypto/Kconfig |2 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/chelsio/Kconfig |   21 +
 drivers/crypto/chelsio/Makefile|4 +
 drivers/crypto/chelsio/chcr_algo.c | 1509 
 drivers/crypto/chelsio/chcr_algo.h |  503 +++
 drivers/crypto/chelsio/chcr_core.c |  268 
 drivers/crypto/chelsio/chcr_core.h |   80 ++
 drivers/crypto/chelsio/chcr_crypto.h   |  204 +++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |   18 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c |   41 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c|   80 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h |   10 +
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |   64 +
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h|  437 ++
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h  |  131 +-
 16 files changed, 3362 insertions(+), 11 deletions(-)
 create mode 100644 drivers/crypto/chelsio/Kconfig
 create mode 100644 drivers/crypto/chelsio/Makefile
 create mode 100644 drivers/crypto/chelsio/chcr_algo.c
 create mode 100644 drivers/crypto/chelsio/chcr_algo.h
 create mode 100644 drivers/crypto/chelsio/chcr_core.c
 create mode 100644 drivers/crypto/chelsio/chcr_core.h
 create mode 100644 drivers/crypto/chelsio/chcr_crypto.h

-- 
1.7.10.1

[Patch-V2 3/3] crypto: Added Chelsio Menu to the Kconfig file

[Yeshaswi M R Gowda]

Adds the config entry for the Chelsio Crypto Driver, Makefile changes
for the same.

Signed-off-by: Yeshaswi M R Gowda 
---
 drivers/crypto/Kconfig  |2 ++
 drivers/crypto/Makefile |1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d77ba2f..b44faf0 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -537,4 +537,6 @@ config CRYPTO_DEV_ROCKCHIP
  This driver interfaces with the hardware crypto accelerator.
  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
 
+source "drivers/crypto/chelsio/Kconfig"
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3c6432d..ad7250f 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
 obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
+obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/
-- 
1.7.10.1

Re: [PATCH v2 2/4] iio: adc: add support for Allwinner SoCs ADC

[Jonathan Cameron]

On 15/07/16 10:59, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. This patch adds the ADC driver which is
> based on the MFD for the same SoCs ADC.
> 
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree.
> 
> This driver probes on three different platform_device_id to take into
> account slight differences between Allwinner SoCs ADCs.
> 
> Signed-off-by: Quentin Schulz 

Hi Quentin,

Various bits inline.  In particular the irq handling looks flakey / racey
to me.  Definitely need some explanatory comments.

Also another note on the craziness that using extended_name to provide
the hwmon labels will cause :)

Jonathan
> ---
> 
> v2:
>  - add SUNXI_GPADC_ prefixes for defines,
>  - correct typo in Kconfig,
>  - reorder alphabetically includes, makefile,
>  - add license header,
>  - fix architecture variations not being handled in interrupt handlers or
>read raw functions,
>  - fix unability to return negative values from thermal sensor,
>  - add gotos to reduce code repetition,
>  - fix irq variable being unsigned int instead of int,
>  - remove useless dev_err and dev_info,
>  - deactivate all interrupts if probe fails,
>  - fix iio_device_register on NULL variable,
>  - deactivate ADC in the IP when probe fails or when removing driver,
> 
>  drivers/iio/adc/Kconfig   |  12 ++
>  drivers/iio/adc/Makefile  |   1 +
>  drivers/iio/adc/sunxi-gpadc-iio.c | 417 
> ++
>  3 files changed, 430 insertions(+)
>  create mode 100644 drivers/iio/adc/sunxi-gpadc-iio.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 25378c5..184856f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -338,6 +338,18 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config SUNXI_ADC
> + tristate "ADC driver for sunxi platforms"
> + depends on IIO
> + depends on MFD_SUNXI_ADC
> + help
> +   Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
> +   ADC. This ADC provides 4 channels which can be used as an ADC or as a
> +   touchscreen input and one channel for thermal sensor.
> +
> +  To compile this driver as a module, choose M here: the module will 
> be
> +   called sunxi-gpadc-iio.
> +
>  config PALMAS_GPADC
>   tristate "TI Palmas General Purpose ADC"
>   depends on MFD_PALMAS
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 38638d4..3e60a1d 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> +obj-$(CONFIG_SUNXI_ADC) += sunxi-gpadc-iio.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> diff --git a/drivers/iio/adc/sunxi-gpadc-iio.c 
> b/drivers/iio/adc/sunxi-gpadc-iio.c
> new file mode 100644
> index 000..87cc913
> --- /dev/null
> +++ b/drivers/iio/adc/sunxi-gpadc-iio.c
> @@ -0,0 +1,417 @@
> +/* ADC driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SUNXI_GPADC_TP_CTRL0 0x00
> +#define SUNXI_GPADC_TP_CTRL1 0x04
> +#define SUNXI_GPADC_TP_CTRL2 0x08
> +#define SUNXI_GPADC_TP_CTRL3 0x0c
> +#define SUNXI_GPADC_TP_TPR   0x18
> +#define SUNXI_GPADC_TP_CDAT  0x1c
> +#define SUNXI_GPADC_TEMP_DATA0x20
> +#define SUNXI_GPADC_TP_DATA  0x24
> +
> +/* TP_CTRL0 bits */
> +#define SUNXI_GPADC_ADC_FIRST_DLY(x) ((x) << 24) /* 8 bits */
> +#define SUNXI_GPADC_ADC_FIRST_DLY_MODE   BIT(23)
> +#define SUNXI_GPADC_ADC_CLK_SELECT   BIT(22)
> +#define SUNXI_GPADC_ADC_CLK_DIVIDER(x)   ((x) << 20) /* 2 bits */
> +#define SUNXI_GPADC_FS_DIV(x)((x) << 16) /* 4 bits */
> +#define SUNXI_GPADC_T_ACQ(x) ((x) << 0)  /* 16 bits */
> +
> +/* TP_CTRL1 bits */
> +#define SUNXI_GPADC_STYLUS_UP_DEBOUNCE(x)((x) << 12) /* 8 bits */
> +#define SUNXI_GPADC_STYLUS_UP_DEBOUNCE_ENBIT(9)
> +#define SUNXI_GPADC_TOUCH_PAN_CALI_ENBIT(6)
> +#define SUNXI_GPADC_TP_DUAL_EN

Re: [PATCH v2 2/2] iio: adc: sun4i_lradc: new driver

[Jonathan Cameron]

On 12/07/16 20:04, Alexandre Belloni wrote:
> Add an IIO driver for the Allwinner Low Resolution ADC. This ADC is usually
> used for physical buttons connected using a resistor ladder.
> 
> Signed-off-by: Alexandre Belloni 
A few small bits and pieces from me...

Jonathan
> ---
> Changes in v2:
>  - prefixed defines with SUN4I_LRADC_
>  - removed sun4i_lradc_write_raw_get_fmt
>  - set indio_dev->dev.of_node
>  - pushed devm_iio_device_register() at the end of the probe function
>  - added a remove function to call regulator_disable()
> 
>  drivers/iio/adc/Kconfig   |  10 ++
>  drivers/iio/adc/Makefile  |   3 +-
>  drivers/iio/adc/sun4i_lradc.c | 323 
> ++
>  3 files changed, 335 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/iio/adc/sun4i_lradc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 25378c5882e2..87aaac6a5f44 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -384,6 +384,16 @@ config ROCKCHIP_SARADC
> To compile this driver as a module, choose M here: the
> module will be called rockchip_saradc.
>  
> +config SUN4I_LRADC
> + tristate "Allwinner sun4i LRADC driver"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + select IIO_TRIGGER
> + help
> +   Say yes here to build support for the LRADC found on Allwinner SoCs.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called sun4i_lradc.
> +
>  config TI_ADC081C
>   tristate "Texas Instruments ADC081C/ADC101C/ADC121C family"
>   depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 38638d46f972..a3b165af6bde 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -1,4 +1,4 @@
> -#
> +
??
>  # Makefile for IIO ADC drivers
>  #
>  
> @@ -37,6 +37,7 @@ obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> +obj-$(CONFIG_SUN4I_LRADC) += sun4i_lradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> diff --git a/drivers/iio/adc/sun4i_lradc.c b/drivers/iio/adc/sun4i_lradc.c
> new file mode 100644
> index ..cd42e1a994b9
> --- /dev/null
> +++ b/drivers/iio/adc/sun4i_lradc.c
> @@ -0,0 +1,323 @@
> +/*
> + * Driver for the LRADC present on the  Allwinner sun4i
> + *
> + * Copyright 2016 Free Electrons
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SUN4I_LRADC_CTRL 0x00
> +#define SUN4I_LRADC_INTC 0x04
> +#define SUN4I_LRADC_INTS 0x08
> +#define SUN4I_LRADC_DATA00x0c
> +#define SUN4I_LRADC_DATA10x10
> +
> +/* LRADC_CTRL bits */
> +#define SUN4I_LRADC_FIRST_CONVERT_DLY(x) ((x) << 24) /* 8 bits */
> +#define SUN4I_LRADC_CHAN_SELECT(x)   ((x) << 22) /* 2 bits */
> +#define SUN4I_LRADC_CONTINUE_TIME_SEL(x) ((x) << 16) /* 4 bits */
> +#define SUN4I_LRADC_KEY_MODE_SEL(x)  ((x) << 12) /* 2 bits */
> +#define SUN4I_LRADC_LEVELA_B_CNT(x)  ((x) << 8)  /* 4 bits */
> +#define SUN4I_LRADC_HOLD_EN  BIT(6)
> +#define SUN4I_LRADC_LEVELB_VOL(x)((x) << 4)  /* 2 bits */
> +#define SUN4I_LRADC_SAMPLE_RATE(x)   ((x) << 2)  /* 2 bits */
> +#define SUN4I_LRADC_EN   BIT(0)
> +
> +/* LRADC_INTC and LRADC_INTS bits */
> +#define SUN4I_LRADC_CHAN1_KEYUP_IRQ  BIT(12)
> +#define SUN4I_LRADC_CHAN1_ALRDY_HOLD_IRQ BIT(11)
> +#define SUN4I_LRADC_CHAN1_HOLD_IRQ   BIT(10)
> +#define  SUN4I_LRADC_CHAN1_KEYDOWN_IRQ   BIT(9)
> +#define SUN4I_LRADC_CHAN1_DATA_IRQ   BIT(8)
> +#define SUN4I_LRADC_CHAN0_KEYUP_IRQ  BIT(4)
> +#define SUN4I_LRADC_CHAN0_ALRDY_HOLD_IRQ BIT(3)
> +#define SUN4I_LRADC_CHAN0_HOLD_IRQ   BIT(2)
> +#define  SUN4I_LRADC_CHAN0_KEYDOWN_IRQ   BIT(1)
> +#define SUN4I_LRADC_CHAN0_DATA_IRQ   BIT(0)
> +
> +#define NUM_SUN4I_LRADC_CHANS2
> +
> +struct sun4i_lradc_state {
> + void __iomem *base;
> + struct regulator *vref_supply;
> + u32 vref_mv;
> + struct completion data_ok[

Re: [PATCH 06/10] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub.
> Creates an IIO device for each functions.
> 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
Few more nitpicks, but basically the same as the previous..

Jonathan
> ---
>  drivers/iio/common/cros_ec_sensors/Kconfig |   9 +
>  drivers/iio/common/cros_ec_sensors/Makefile|   1 +
>  .../common/cros_ec_sensors/cros_ec_light_prox.c| 288 
> +
>  3 files changed, 298 insertions(+)
>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> 
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index 18002d6..02559d2 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -20,3 +20,12 @@ config IIO_CROS_EC_SENSORS
> Accelerometers, Gyroscope and Magnetometer that are
> presented by the ChromeOS EC Sensor hub.
> Creates an IIO device for each functions.
> +
> +config IIO_CROS_EC_LIGHT_PROX
> + tristate "ChromeOS EC Light and Proximity Sensors"
> + select IIO_CROS_EC_SENSORS_CORE
> + help
> +   Module to handle Light and Proximity sensors
> +   presented by the ChromeOS EC Sensor hub.
> +   Creates an IIO device for each functions.
> +   Only one source is exposed by the EC.
> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
> b/drivers/iio/common/cros_ec_sensors/Makefile
> index ec716ff..7aaf2a2 100644
> --- a/drivers/iio/common/cros_ec_sensors/Makefile
> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> @@ -4,3 +4,4 @@
>  
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
> +obj-$(CONFIG_IIO_CROS_EC_LIGHT_PROX) += cros_ec_light_prox.o
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c 
> b/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> new file mode 100644
> index 000..333e927
> --- /dev/null
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_light_prox.c
> @@ -0,0 +1,288 @@
> +/*
> + * cros_ec_light_proxmity - Driver for light and prox sensors behing CrOS EC.
> + *
> + * Copyright (C) 2015 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the cros-ec interface to communicate with the Chrome OS
> + * EC about accelerometer data. Accelerometer access is presented through
> + * iio sysfs.
Fix this comment as I doubt this driver does that ;)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cros_ec_sensors_core.h"
> +
> +/*
> + * We only represent one entry for light or proximity.
> + * EC is merging different light sensors to return the
> + * what the eye would see.
> + * For proximity, we currently support only one light source.
> + */
> +#define MAX_CHANNELS (1 + 1)
> +
> +/* State data for ec_sensors iio driver. */
> +struct cros_ec_sensors_state {
> + /* Shared by all sensors */
> + struct cros_ec_sensors_core_state core;
> +
> + struct iio_chan_spec channels[MAX_CHANNELS];
> +};
> +
> +static int cros_ec_light_prox_read(struct iio_dev *indio_dev,
> +   struct iio_chan_spec const *chan,
> +   int *val, int *val2, long mask)
> +{
> + struct cros_ec_sensors_state *st = iio_priv(indio_dev);
> + u16 data = 0;
> + s64 val64;
> + int ret = IIO_VAL_INT;
> + int idx = chan->scan_index;
> +
> + mutex_lock(&st->core.cmd_lock);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (cros_ec_sensors_read_cmd(indio_dev, 1 << idx,
> + (s16 *)&data) < 0)
> + ret = -EIO;
> + *val = data;
> + break;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + st->core.param.cmd = MOTIONSENSE_CMD_SENSOR_OFFSET;
> + st->core.param.sensor_offset.flags = 0;
> +
> + if (cros_ec_motion_send_host_cmd(&st->core, 0)) {
> + ret = -EIO;
> + break;
> + }
> +
> + /* Save values */
> + st->core.calib[0].offset =
> + st->core.resp->sensor_offset.offset[0];
> +
> + *val = st->core.calib[idx].offset;
> + brea

Re: [PATCH v4 5/8] drm/mediatek: add dsi interrupt control

[CK Hu]

Hi, YT:

Some comments inline.

On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  130 
> 
>  1 file changed, 130 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 2d808e5..de5ad7f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,13 @@
>  
>  #define DSI_START0x00
>  
> +#define DSI_INTEN0x08
> +
> +#define DSI_INTSTA   0x0c
> +#define LPRX_RD_RDY_INT_FLAG BIT(0)
> +#define CMD_DONE_INT_FLAGBIT(1)
> +#define DSI_BUSY BIT(31)

Why need LPRX_RD_RDY_INT_FLAG, CMD_DONE_INT_FLAG, and DSI_BUSY? Maybe
these three should be moved to other patch.

> +
>  #define DSI_CON_CTRL 0x10
>  #define DSI_RESETBIT(0)
>  #define DSI_EN   BIT(1)
> @@ -74,6 +82,9 @@
>  
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RACK 0x84
> +#define RACK BIT(0)
> +
>  #define DSI_PHY_LCCON0x104
>  #define LC_HS_TX_EN  BIT(0)
>  #define LC_ULPM_EN   BIT(1)
> @@ -134,6 +145,18 @@ struct mtk_dsi {
>   struct videomode vm;
>   int refcount;
>   bool enabled;
> + int irq_num, irq_data;
> +};
> +
> +enum {
> + DSI_INT_SLEEPOUT_DONE_FLAG  = BIT(6),
> + DSI_INT_VM_CMD_DONE_FLAG= BIT(5),
> + DSI_INT_EXT_TE_RDY_FLAG = BIT(4),
> + DSI_INT_VM_DONE_FLAG= BIT(3),
> + DSI_INT_TE_RDY_FLAG = BIT(2),
> + DSI_INT_CMD_DONE_FLAG   = BIT(1),
> + DSI_INT_LPRX_RD_RDY_FLAG= BIT(0),
> + DSI_INT_ALL_BITS= (0x7f)
>  };

I think you should use '#define' instead of 'enum'. The code would be
like below, and these definition should be moved to after DSI_INTEN or
DSI_INTSTA.

#define DSI_INT_LPRX_RD_RDY_FLAGBIT(0)
#define DSI_INT_CMD_DONE_FLAG   BIT(1)
#define DSI_INT_TE_RDY_FLAG BIT(2)
#define DSI_INT_VM_DONE_FLAGBIT(3)
#define DSI_INT_EXT_TE_RDY_FLAG BIT(4)
#define DSI_INT_VM_CMD_DONE_FLAGBIT(5)
#define DSI_INT_SLEEPOUT_DONE_FLAG  BIT(6)
#define DSI_INT_ALL_BITS(DSI_INT_LPRX_RD_RDY_FLAG | \
DSI_INT_CMD_DONE_FLAG | \
DSI_INT_TE_RDY_FLAG | \
DSI_INT_VM_DONE_FLAG | \
DSI_INT_EXT_TE_RDY_FLAG | \
DSI_INT_VM_CMD_DONE_FLAG | \
DSI_INT_SLEEPOUT_DONE_FLAG)

>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -440,6 +463,94 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = DSI_INT_ALL_BITS;
> +
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO)
> + inten &= ~(DSI_INT_TE_RDY_FLAG | DSI_INT_EXT_TE_RDY_FLAG);
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +
> +static void mtk_dsi_irq_wakeup(struct mtk_dsi *dsi, u32 irq_bit)
> +{
> + dsi->irq_data |= irq_bit;
> +}
> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> +
> + u32 status, tmp;
> +
> + status = readl(dsi->regs + DSI_INTSTA);
> +
> + if (status & DSI_INT_LPRX_RD_RDY_FLAG) {
> + /* write clear RD_RDY interrupt */
> + /* write clear RD_RDY interrupt must be before DSI_RACK */
> + /* because CMD_DONE will raise after DSI_RACK, */
> + /* so write clear RD_RDY after that will clear CMD_DONE too */
> + do {
> + /* send read ACK */
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, DSI_INT_LPRX_RD_RDY_FLAG, 0);
> + mtk_dsi_irq_wakeup(dsi, DSI_INT_LPRX_RD_RDY_FLAG);
> + }
> +
> + if (status & DSI_INT_CMD_DONE_FLAG) {
> + mtk_dsi_mask(dsi, DSI_INTSTA, DSI_INT_CMD_DONE_FLAG, 0);
> + mtk_dsi_irq_wakeup(dsi, DSI_INT_CMD_DONE_FLAG);
> + }
> +
> + if (status & DSI_INT_TE_RDY_FLAG) {
> + mtk_dsi_mask(dsi, DSI_INTSTA, DSI_INT_TE_RDY_FLAG, 0);
> + mtk_dsi_irq_wakeup(dsi, DSI_INT_TE_RDY_FLAG);
> + }
> +
> + if (status & DSI_INT_VM_DONE_FLAG) {
> + mtk_dsi_mask(dsi, DSI_INTSTA, DSI_INT_VM_DONE_FLAG, 0);
> + mtk_dsi_irq

Re: [PATCH 05/10] iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> Handle 3d contiguous sensors like Accelerometers, Gyroscope and
> Magnetometer that are presented by the ChromeOS EC Sensor hub.
> 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
Various nitpicks inline.

Jonathan
> ---
>  drivers/iio/common/cros_ec_sensors/Kconfig |   8 +
>  drivers/iio/common/cros_ec_sensors/Makefile|   1 +
>  .../iio/common/cros_ec_sensors/cros_ec_sensors.c   | 322 
> +
>  3 files changed, 331 insertions(+)
>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> 
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index a30f41e..18002d6 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -12,3 +12,11 @@ config IIO_CROS_EC_SENSORS_CORE
> driver.
> Define common attributes and sysfs interrupt handler.
>  
> +config IIO_CROS_EC_SENSORS
> + tristate "ChromeOS EC Contiguous Sensors"
> + select IIO_CROS_EC_SENSORS_CORE
> + help
> +   Module to handle 3d contiguous sensors like
> +   Accelerometers, Gyroscope and Magnetometer that are
> +   presented by the ChromeOS EC Sensor hub.
> +   Creates an IIO device for each functions.
> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
> b/drivers/iio/common/cros_ec_sensors/Makefile
> index 95b6901..ec716ff 100644
> --- a/drivers/iio/common/cros_ec_sensors/Makefile
> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> @@ -3,3 +3,4 @@
>  #
>  
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
> +obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c 
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> new file mode 100644
> index 000..4741118
> --- /dev/null
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -0,0 +1,322 @@
> +/*
> + * cros_ec_sensors - Driver for Chrome OS Embedded Controller sensors.
> + *
> + * Copyright (C) 2015 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the cros-ec interface to communicate with the Chrome OS
> + * EC about accelerometer data. Accelerometer access is presented through
> + * iio sysfs.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cros_ec_sensors_core.h"
> +
> +#define MAX_CHANNELS (MAX_AXIS + 1)
Really needs a prefix - chances of another define for MAX_CHANNELS in an
included header is way too high!
Same for MAX_AXIS etc...  Basically prefix everything and you'll have it
about right...
> +
> +/* State data for ec_sensors iio driver. */
> +struct cros_ec_sensors_state {
> + /* Shared by all sensors */
> + struct cros_ec_sensors_core_state core;
> +
> + struct iio_chan_spec channels[MAX_CHANNELS];
> +};
> +
> +static int cros_ec_sensors_read(struct iio_dev *indio_dev,
> +   struct iio_chan_spec const *chan,
> +   int *val, int *val2, long mask)
> +{
> + struct cros_ec_sensors_state *st = iio_priv(indio_dev);
> + s16 data = 0;
> + s64 val64;
> + int i;
> + int ret = IIO_VAL_INT;
> + int idx = chan->scan_index;
> +
> + mutex_lock(&st->core.cmd_lock);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (st->core.read_ec_sensors_data(indio_dev,
> +   1 << idx, &data) < 0)
> + ret = -EIO;
Never get any useful errors in from the function?  Seems like you are eating
it if there is.
> + *val = data;
> + break;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + st->core.param.cmd = MOTIONSENSE_CMD_SENSOR_OFFSET;
> + st->core.param.sensor_offset.flags = 0;
> +
> + if (cros_ec_motion_send_host_cmd(&st->core, 0)) {
< 0 for consistency?
> + ret = -EIO;
> + break;
> + }
> +
> + /* Save values */
> + for (i = X; i < MAX_AXIS; i++)
> + st->core.calib[i].offset =
> + st->core.resp->sensor_offset.offset[i];
> +
> + *val = st->core.calib[idx].offset;
> + break;
> + case IIO_CHAN_INFO_SCALE:
> + st->core.param.cmd =

Re: [PATCH 04/10] iio: cros_ec: Add common functions for cros_ec sensors.

[Jonathan Cameron]

On 18/07/16 08:29, Peter Meerwald-Stadler wrote:
> 
>> Add the core functions to be able to support the sensors attached behind
>> the ChromeOS Embedded Controller and used by other IIO cros-ec sensor
>> drivers.
> 
> comments below from a quick read
> there is plenty on undocumented private API
Few more comments from me. Peter is of course quite correct, its the
new, undocumented ABI, which is the biggest issue.

Interesting looking device.  Any docs out there?

Jonathan
>  
>> The cros_ec_sensor_core driver matches with current driver in ChromeOS
>> 4.4 tree, so it includes all the fixes at the moment. The support for
>> this driver was made by Gwendal Grignou. The original patch and all the
>> fixes has been squashed and rebased on top of mainline.
>>
>> Signed-off-by: Gwendal Grignou 
>> Signed-off-by: Guenter Roeck 
>> [eballetbo: split, squash and rebase on top of mainline the patches
>> found in ChromeOS tree]
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  drivers/iio/common/Kconfig |   1 +
>>  drivers/iio/common/Makefile|   1 +
>>  drivers/iio/common/cros_ec_sensors/Kconfig |  14 +
>>  drivers/iio/common/cros_ec_sensors/Makefile|   5 +
>>  .../common/cros_ec_sensors/cros_ec_sensors_core.c  | 564 
>> +
>>  .../common/cros_ec_sensors/cros_ec_sensors_core.h  | 155 ++
>>  6 files changed, 740 insertions(+)
>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Kconfig
>>  create mode 100644 drivers/iio/common/cros_ec_sensors/Makefile
>>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h
>>
>> diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
>> index 26a6026..e108996 100644
>> --- a/drivers/iio/common/Kconfig
>> +++ b/drivers/iio/common/Kconfig
>> @@ -2,6 +2,7 @@
>>  # IIO common modules
>>  #
>>  
>> +source "drivers/iio/common/cros_ec_sensors/Kconfig"
>>  source "drivers/iio/common/hid-sensors/Kconfig"
>>  source "drivers/iio/common/ms_sensors/Kconfig"
>>  source "drivers/iio/common/ssp_sensors/Kconfig"
>> diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
>> index 585da6a..6fa760e 100644
>> --- a/drivers/iio/common/Makefile
>> +++ b/drivers/iio/common/Makefile
>> @@ -7,6 +7,7 @@
>>  #
>>  
>>  # When adding new entries keep the list in alphabetical order
>> +obj-y += cros_ec_sensors/
>>  obj-y += hid-sensors/
>>  obj-y += ms_sensors/
>>  obj-y += ssp_sensors/
>> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
>> b/drivers/iio/common/cros_ec_sensors/Kconfig
>> new file mode 100644
>> index 000..a30f41e
>> --- /dev/null
>> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
>> @@ -0,0 +1,14 @@
>> +#
>> +# Chrome OS Embedded Controller managed sensors library
>> +#
>> +config IIO_CROS_EC_SENSORS_CORE
>> +tristate "ChromeOS EC Sensors Core"
>> +depends on SYSFS && MFD_CROS_EC
>> +select IIO_BUFFER
>> +select IIO_TRIGGERED_BUFFER
>> +help
>> +  Base module for the ChromeOS EC Sensors module.
>> +  Contains core functions used by other IIO CrosEC sensor
>> +  driver.
> 
> 'drivers' probably
> 
>> +  Define common attributes and sysfs interrupt handler.
>> +
>> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
>> b/drivers/iio/common/cros_ec_sensors/Makefile
>> new file mode 100644
>> index 000..95b6901
>> --- /dev/null
>> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for sensors seen through the ChromeOS EC sensor hub.
>> +#
>> +
>> +obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
>> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c 
>> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>> new file mode 100644
>> index 000..cb3de8f
>> --- /dev/null
>> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>> @@ -0,0 +1,564 @@
>> +/*
>> + * cros_ec_sensors_core - Common function for Chrome OS EC sensor driver.
>> + *
>> + * Copyright (C) 2015 Google, Inc
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * This driver uses the cros-ec interface to communicate with the Chrome OS
>> + * EC about accelerometer data. Accelerometer access is presented through
>> + * iio sysfs.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include

Re: [PATCH 02/10] mfd: cros_ec: update MOTIONSENSE definitions and commands.

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> Let's update the command header to include the definitions related to
> the sensors attached behind the ChromeOS Embedded Controller. The new
> commands and definitions allow us to get information from these sensors.
> 
> Signed-off-by: Gwendal Grignou 
> Signed-off-by: Enric Balletbo i Serra 
Again, I'd be happier seeing this stuff introduced as and when it
is needed rather than in a magic patch. It's hard to review stuff
if it's broken up across multiple patches like this.

A few other bits and pieces inline.

Jonathan
> ---
>  include/linux/mfd/cros_ec_commands.h | 260 
> +++
>  1 file changed, 231 insertions(+), 29 deletions(-)
> 
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 76728ff..f26a806 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -1290,7 +1290,13 @@ enum motionsense_command {
>  
>   /*
>* EC Rate command is a setter/getter command for the EC sampling rate
> -  * of all motion sensors in milliseconds.
> +  * in milliseconds.
> +  * It is per sensor, the EC run sample task  at the minimum of all
> +  * sensors EC_RATE.
> +  * For sensors without hardware FIFO, EC_RATE should be equals to 1/ODR
> +  * to collect all the sensor samples.
> +  * For sensor with hardware FIFO, EC_RATE is used as the maximal delay
> +  * to process of all motion sensors in milliseconds.
>*/
>   MOTIONSENSE_CMD_EC_RATE = 2,
>  
> @@ -1315,37 +1321,138 @@ enum motionsense_command {
>*/
>   MOTIONSENSE_CMD_KB_WAKE_ANGLE = 5,
>  
> - /* Number of motionsense sub-commands. */
> - MOTIONSENSE_NUM_CMDS
> -};
> + /*
> +  * Returns a single sensor data.
> +  */
Please use standard kernel documentation formats throughout.
If not you may face a Linus rant ;)
> + MOTIONSENSE_CMD_DATA = 6,
> +
> + /*
> +  * Return sensor fifo info.
> +  */
> + MOTIONSENSE_CMD_FIFO_INFO = 7,
> +
> + /*
> +  * Insert a flush element in the fifo and return sensor fifo info.
> +  * The host can use that element to synchronize its operation.
> +  */
> + MOTIONSENSE_CMD_FIFO_FLUSH = 8,
>  
> -enum motionsensor_id {
> - EC_MOTION_SENSOR_ACCEL_BASE = 0,
> - EC_MOTION_SENSOR_ACCEL_LID = 1,
> - EC_MOTION_SENSOR_GYRO = 2,
> + /*
> +  * Return a portion of the fifo.
> +  */
> + MOTIONSENSE_CMD_FIFO_READ = 9,
> +
> + /*
> +  * Perform low level calibration.
> +  * On sensors that support it, ask to do offset calibration.
> +  */
> + MOTIONSENSE_CMD_PERFORM_CALIB = 10,
> +
> + /*
> +  * Sensor Offset command is a setter/getter command for the offset
> +  * used for calibration.
> +  * The offsets can be calculated by the host, or via
> +  * PERFORM_CALIB command.
> +  */
> + MOTIONSENSE_CMD_SENSOR_OFFSET = 11,
> +
> + /*
> +  * List available activities for a MOTION sensor.
> +  * Indicates if they are enabled or disabled.
> +  */
> + MOTIONSENSE_CMD_LIST_ACTIVITIES = 12,
>  
>   /*
> -  * Note, if more sensors are added and this count changes, the padding
> -  * in ec_response_motion_sense dump command must be modified.
> +  * Activity management
> +  * Enable/Disable activity recognition.
>*/
> - EC_MOTION_SENSOR_COUNT = 3
> + MOTIONSENSE_CMD_SET_ACTIVITY = 13,
> +
> + /* Number of motionsense sub-commands. */
> + MOTIONSENSE_NUM_CMDS
>  };
>  
>  /* List of motion sensor types. */
>  enum motionsensor_type {
>   MOTIONSENSE_TYPE_ACCEL = 0,
>   MOTIONSENSE_TYPE_GYRO = 1,
> + MOTIONSENSE_TYPE_MAG = 2,
> + MOTIONSENSE_TYPE_PROX = 3,
> + MOTIONSENSE_TYPE_LIGHT = 4,
> + MOTIONSENSE_TYPE_ACTIVITY = 5,
> + MOTIONSENSE_TYPE_MAX,
>  };
>  
>  /* List of motion sensor locations. */
>  enum motionsensor_location {
>   MOTIONSENSE_LOC_BASE = 0,
>   MOTIONSENSE_LOC_LID = 1,
> + MOTIONSENSE_LOC_MAX,
>  };
>  
>  /* List of motion sensor chips. */
>  enum motionsensor_chip {
>   MOTIONSENSE_CHIP_KXCJ9 = 0,
> + MOTIONSENSE_CHIP_LSM6DS0 = 1,
> + MOTIONSENSE_CHIP_BMI160 = 2,
> + MOTIONSENSE_CHIP_SI1141 = 3,
> + MOTIONSENSE_CHIP_SI1142 = 4,
> + MOTIONSENSE_CHIP_SI1143 = 5,
> + MOTIONSENSE_CHIP_KX022 = 6,
> + MOTIONSENSE_CHIP_L3GD20H = 7,
Interesting.  So the driver needs some knowledge of what
is behind it.  I'll read on with interest ;)
> +};
> +
> +struct ec_response_motion_sensor_data {
> + /* Flags for each sensor. */
> + uint8_t flags;
> + /* sensor number the data comes from */
> + uint8_t sensor_num;
> + /* Each sensor is up to 3-axis. */
> + union {
> + int16_t data[3];
> + struct {
> + uint16_trsvd;
> + uint32_ttimestamp;
> +

Re: [PATCH v2 4/4] hwmon: iio: add label for channels read by iio_hwmon

[Jonathan Cameron]

On 15/07/16 10:59, Quentin Schulz wrote:
> Currently, iio_hwmon only exposes values of the IIO channels it can read
> but no label by channel is exposed.
> 
> This adds exposition of sysfs files containing label for IIO channels it
> can read based on extended_name field of the iio_chan_spec of the channel.
> If the extended_name field is empty, the sysfs file is not created by
> iio_hwmon.
Hmm. This is not the intent of extended name at all.  That exists to add
a small amount of information to an constructed IIO channel name.
Typically it's used to indicate physically wired stuff like:

in_voltage0_vdd_raw for cases where that channel of the ADC is hard wired
to the vdd.  In this particular case the use might actually work as the
vdd makes it clear it's a voltage - in general that's not the case.

Use of extended_name at all in IIO is only done after extensive review.
It adds nasty custom ABI to a device, so the gain has to be considerable
to use it.

When I read your original suggestion of adding labels, I was expecting the
use of datasheet_name.  That has the advantage of being well defined by
the datasheet (if not it should not be provided) + not being used in
the construction of the IIO channel related attributes.  However, that
may still not correspond well to the expected labelling in hwmon.
Thinking more on this, the label is going to often be a function of how
the board is wired up...  Perhaps it should be a characteristic of the
channel_map (hence from DT or similar) rather than part of the IIO driver
itself?

At first glance hwmon labels appear to be pretty freeform...  However
we need to be very careful here as this is effectively defining a large
chunk of new ABI.

This isn't a thing that I have a particularly clear view on (as you
might be able to tell ;).  Other opinions sought!

Jonathan
> 
> Signed-off-by: Quentin Schulz 
> ---
> 
> patch added in v2
> 
>  drivers/hwmon/iio_hwmon.c | 77 
> +--
>  1 file changed, 68 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
> index c0da4d9..28d15b2 100644
> --- a/drivers/hwmon/iio_hwmon.c
> +++ b/drivers/hwmon/iio_hwmon.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /**
> @@ -57,12 +58,26 @@ static ssize_t iio_hwmon_read_val(struct device *dev,
>   return sprintf(buf, "%d\n", result);
>  }
>  
> +static ssize_t iio_hwmon_read_label(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> + struct iio_hwmon_state *state = dev_get_drvdata(dev);
> + const char *label = state->channels[sattr->index].channel->extend_name;
> +
> + if (label)
> + return sprintf(buf, "%s\n", label);
> +
> + return 0;
> +}
> +
>  static int iio_hwmon_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   struct iio_hwmon_state *st;
> - struct sensor_device_attribute *a;
> - int ret, i;
> + struct sensor_device_attribute *a, *b;
> + int ret, i, j = 0;
>   int in_i = 1, temp_i = 1, curr_i = 1, humidity_i = 1;
>   enum iio_chan_type type;
>   struct iio_channel *channels;
> @@ -92,7 +107,8 @@ static int iio_hwmon_probe(struct platform_device *pdev)
>   st->num_channels++;
>  
>   st->attrs = devm_kzalloc(dev,
> -  sizeof(*st->attrs) * (st->num_channels + 1),
> +  sizeof(*st->attrs) *
> +  (2 * st->num_channels + 1),
>GFP_KERNEL);
>   if (st->attrs == NULL) {
>   ret = -ENOMEM;
> @@ -107,6 +123,18 @@ static int iio_hwmon_probe(struct platform_device *pdev)
>   }
>  
>   sysfs_attr_init(&a->dev_attr.attr);
> +
> + b = NULL;
> + if (st->channels[i].channel->extend_name) {
> + b = devm_kzalloc(dev, sizeof(*b), GFP_KERNEL);
> + if (b == NULL) {
> + ret = -ENOMEM;
> + goto error_release_channels;
> + }
> +
> + sysfs_attr_init(&b->dev_attr.attr);
> + }
> +
>   ret = iio_get_channel_type(&st->channels[i], &type);
>   if (ret < 0)
>   goto error_release_channels;
> @@ -115,35 +143,66 @@ static int iio_hwmon_probe(struct platform_device *pdev)
>   case IIO_VOLTAGE:
>   a->dev_attr.attr.name = kasprintf(GFP_KERNEL,
> "in%d_input",
> -   in_i++);
> +   in_i);
> + if (b)
> + b->dev_attr

Re: [PATCH v4 2/3] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

[Jonathan Cameron]

On 11/07/16 07:39, Zhiyong Tao wrote:
> Add Mediatek auxadc driver based on iio.
> It will register a device in iio and support iio.
> So thermal can read auxadc channel to sample data by iio device.
> It is tested successfully on mt2701 platform.
> Mt8173 and mt6577 platforms are not tested.
> But the expectation is compatible.
> 
> Signed-off-by: Zhiyong Tao 
Looks good to me.  Couple of really minor points / questions inline...

Just one thing to confirm... (you probably already answered this!)
What are the units of the voltage channels?

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   13 ++
>  drivers/iio/adc/Makefile|1 +
>  drivers/iio/adc/mt6577_auxadc.c |  294 
> +++
>  3 files changed, 308 insertions(+)
>  create mode 100644 drivers/iio/adc/mt6577_auxadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 25378c5..14929fc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -305,6 +305,19 @@ config MCP3422
> This driver can also be built as a module. If so, the module will be
> called mcp3422.
>  
> +config MEDIATEK_MT6577_AUXADC
> +tristate "MediaTek AUXADC driver"
> +depends on ARCH_MEDIATEK || COMPILE_TEST
> +depends on HAS_IOMEM
> +help
> +  Say yes here to enable support for MediaTek mt65xx AUXADC.
> +
> +  The driver supports immediate mode operation to read from one of 
> sixteen
> +  channels (external or internal).
> +
> +  This driver can also be built as a module. If so, the module will 
> be
> +  called mt6577_auxadc.
> +
>  config MEN_Z188_ADC
>   tristate "MEN 16z188 ADC IP Core support"
>   depends on MCB
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 38638d4..8306347 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
>  obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
> +obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
>  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
>  obj-$(CONFIG_NAU7802) += nau7802.o
> diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
> new file mode 100644
> index 000..c7cc901
> --- /dev/null
> +++ b/drivers/iio/adc/mt6577_auxadc.c
> @@ -0,0 +1,294 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Zhiyong Tao 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register definitions */
> +#define MT6577_AUXADC_CON00x00
> +#define MT6577_AUXADC_CON10x04
> +#define MT6577_AUXADC_CON20x10
> +#define MT6577_AUXADC_STA BIT(0)
> +
> +#define MT6577_AUXADC_DAT00x14
> +#define MT6577_AUXADC_RDY0BIT(12)
> +
> +#define MT6577_AUXADC_MISC0x94
> +#define MT6577_AUXADC_PDN_EN  BIT(14)
> +
> +#define MT6577_AUXADC_DAT_MASK0xfff
> +#define MT6577_AUXADC_SLEEP_US1000
> +#define MT6577_AUXADC_TIMEOUT_US  1
> +#define MT6577_AUXADC_POWER_READY_MS  1
> +#define MT6577_AUXADC_SAMPLE_READY_US 25
> +
> +struct mt6577_auxadc_device {
> + void __iomem *reg_base;
> + struct clk *adc_clk;
> + struct mutex lock;
> +};
> +
> +#define MT6577_AUXADC_CHANNEL(idx) { \
> + .type = IIO_VOLTAGE,\
> + .indexed = 1,   \
> + .channel = (idx),   \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> +}
> +
> +static const struct iio_chan_spec mt6577_auxadc_iio_channels[] = {
> + MT6577_AUXADC_CHANNEL(0),
> + MT6577_AUXADC_CHANNEL(1),
> + MT6577_AUXADC_CHANNEL(2),
> + MT6577_AUXADC_CHANNEL(3),
> + MT6577_AUXADC_CHANNEL(4),
> + MT6577_AUXADC_CHANNEL(5),
> + MT6577_AUXADC_CHANNEL(6),
> + MT6577_AUXADC_CHANNEL(7),
> + MT6577_AUXADC_CHANNEL(8),
> + MT6577_AUXADC_CHANNEL(9),
> + MT6577_AUXADC_CHANNEL(10),
> + MT6577_AUXADC_CHANNEL(11),
> + MT6577_AUXADC_CHANNEL(12),
> + MT6577_AUXADC_CHANNEL(13),
> + MT6577_AUXADC_CHANNEL(1

Re: [PATCH 03/10] iio: core: Add double tap as possible gesture

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> From: Gwendal Grignou 
> 
> This is an interface change: however, the sysfs entry is based on string,
> so if other gestures are added on the trunk in the meantime, we will
> still be able to merge this change.
> 
> Signed-off-by: Gwendal Grignou 
> Signed-off-by: Guenter Roeck 
> [enric: Rebased and resolved conflicts]
> Signed-off-by: Enric Balletbo i Serra 
So you are creating an entire channel type for double tap?

Not keen on this I'm afraid.

The activity types in there are the moment are not events, but rather
attempts to estimate the 'likelihood' that a given activity is currently
being undertaken.

Hmm. Double tap is more of an event type.  It's one I've been wondering
how to describe for a while... At the end of the day it's just a
reasonably sophisticated filter - kind of a 'magic' version of Rate
of Change.  Unfortunately there isn't a clean mathematical definition
as it can be implemented in lots of ways.  

I guess the best may be to just have it as an event type on it's own...

What do others think?

Jonathan
> ---
>  drivers/iio/industrialio-core.c | 1 +
>  include/uapi/linux/iio/types.h  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index e6319a9..f700e67 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -119,6 +119,7 @@ static const char * const iio_modifier_names[] = {
>   [IIO_MOD_Q] = "q",
>   [IIO_MOD_CO2] = "co2",
>   [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_DOUBLE_TAP] = "double_tap",
>  };
>  
>  /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index b0916fc..c290167 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -79,6 +79,7 @@ enum iio_modifier {
>   IIO_MOD_CO2,
>   IIO_MOD_VOC,
>   IIO_MOD_LIGHT_UV,
> + IIO_MOD_DOUBLE_TAP,
>  };
>  
>  enum iio_event_type {
> 

Re: [PATCH] staging: iio: light: isl29018/28: remove I2C_CLASS_HWMON .class setting

[Jonathan Cameron]

On 18/07/16 09:50, Laxman Dewangan wrote:
> 
> On Saturday 16 July 2016 07:58 AM, Alison Schofield wrote:
>> I2C_CLASS_HWMON is for a hardware monitoring chip wanting
>> auto-detection.  IIO drivers don't typically use .class.
>> Remove it.
>>
>> Signed-off-by: Alison Schofield 
>> Cc: Daniel Baluta 
>>
> 
> Agree.
> Acked-by: Laxman Dewangan 
Any resulting ABI change from dropping it?
I don't think so, as it doesn't support detection anyway,
but best to be sure ;)

> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] iio: cros_ec_sensors_ring: add ChromeOS EC Sensors Ring

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> Add support for handling sensor events FIFO produced by the sensor
> hub. A single device with a buffer will collect all samples produced
> by the sensors managed by the CrosEC sensor hub.
So you are defining a different device to support the buffer?
That's 'unusual'...
> 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/iio/common/cros_ec_sensors/Kconfig |   9 +
>  drivers/iio/common/cros_ec_sensors/Makefile|   1 +
>  .../common/cros_ec_sensors/cros_ec_sensors_ring.c  | 541 
> +
>  3 files changed, 551 insertions(+)
>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_ring.c
> 
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index 22b4211..778c3bf 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -39,3 +39,12 @@ config IIO_CROS_EC_ACTIVITY
> Activities can be simple (low/no motion) or more complex (riding 
> train).
> They are being reported by physical devices or the EC itself.
> Creates an IIO device to manage all activities.
> +
> +config IIO_CROS_EC_SENSORS_RING
> + tristate "ChromeOS EC Sensors Ring"
> + depends on IIO_CROS_EC_SENSORS || IIO_CROS_EC_LIGHT_PROX
> + help
> +   Add support for handling sensor events FIFO produced by
> +   the sensor hub.
> +   A single device with a buffer will collect all samples produced
> +   by the sensors managed by the CrosEC sensor hub
> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
> b/drivers/iio/common/cros_ec_sensors/Makefile
> index 8f54f1e..0eb3fc5 100644
> --- a/drivers/iio/common/cros_ec_sensors/Makefile
> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += 
> cros_ec_sensors_core.o
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
>  obj-$(CONFIG_IIO_CROS_EC_LIGHT_PROX) += cros_ec_light_prox.o
>  obj-$(CONFIG_IIO_CROS_EC_ACTIVITY) += cros_ec_activity.o
> +obj-$(CONFIG_IIO_CROS_EC_SENSORS_RING) += cros_ec_sensors_ring.o
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_ring.c 
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_ring.c
> new file mode 100644
> index 000..1c74df9
> --- /dev/null
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_ring.c
> @@ -0,0 +1,541 @@
> +/*
> + * cros_ec_sensors_ring - Driver for Chrome OS EC Sensor hub FIFO.
> + *
> + * Copyright (C) 2015 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the cros-ec interface to communicate with the Chrome OS
> + * EC about accelerometer data. Accelerometer access is presented through
> + * iio sysfs.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cros_ec_sensors_core.h"
> +
> +/* The ring is a FIFO that return sensor information from
> + * the single EC FIFO.
> + * There are always 5 channels returned:
> +* | ID | FLAG | X | Y | Z | Timestamp |
> + * ID is the EC sensor id
> + * FLAG is for meta data, only flush bit is defined.
> + */
> +#define CROS_EC_FLUSH_BIT 1
> +
> +enum {
> + CHANNEL_SENSOR_ID,
> + CHANNEL_SENSOR_FLAG,
Ah, I'm beginning to understand.

I think you really need to demux these into the appropriate devices individual
buffers... If these are coming in fairly randomly (guessing so?) then you'll
want a top level mfd pushing data to each of the child devices (representing
the different possible sensors).

Simply pushing it into a buffer with metadata doesn't fit with the IIO ABI
at all.

Note that there is no obligation to have any triggers involved at all. Here I'd
suggest you don't as it'll just make life difficult for little gain.

> + CHANNEL_X,
> + CHANNEL_Y,
> + CHANNEL_Z,
> + CHANNEL_TIMESTAMP,
> + MAX_CHANNEL,
> +};
> +
> +enum {
> + LAST_TS,
> + NEW_TS,
> + ALL_TS
> +};
> +
> +#define CROS_EC_SENSOR_MAX 16
> +
> +struct cros_ec_fifo_info {
> + struct ec_response_motion_sense_fifo_info info;
> + uint16_t lost[CROS_EC_SENSOR_MAX];
> +};
> +
single blank line is plenty.
> +
> +struct cros_ec_sensors_ring_sample {
> + uint8_t sensor_id;
> + uint8_t flag;
> + int16_t  vector[MAX_AXIS];
> + s64  timestamp;
> +} __packed;
> +
> +/* Stat

Re: [PATCH v2 3/4] mfd: add support for Allwinner SoCs ADC

[Jonathan Cameron]

On 15/07/16 10:59, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. For now, only the ADC and the thermal
> sensor drivers are probed by the MFD, the touchscreen controller support
> will be added later.
> 
> Signed-off-by: Quentin Schulz 
Hmm. Previous patch includes the header this one creates.  Ordering issue?
The depends kind of prevents build failures by ensuring that can't be built
until this one is in place, but it is certainly an ugly way to do it.

Few little bits innline.
> ---
> 
> v2:
>  - add license headers,
>  - reorder alphabetically includes,
>  - add SUNXI_GPADC_ prefixes for defines,
> 
>  drivers/mfd/Kconfig |  14 +++
>  drivers/mfd/Makefile|   2 +
>  drivers/mfd/sunxi-gpadc-mfd.c   | 197 
> 
>  include/linux/mfd/sunxi-gpadc-mfd.h |  23 +
>  4 files changed, 236 insertions(+)
>  create mode 100644 drivers/mfd/sunxi-gpadc-mfd.c
>  create mode 100644 include/linux/mfd/sunxi-gpadc-mfd.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 1bcf601..67b55d0 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -82,6 +82,20 @@ config MFD_ATMEL_FLEXCOM
> by the probe function of this MFD driver according to a device tree
> property.
>  
> +config MFD_SUNXI_ADC
> + tristate "ADC MFD core driver for sunxi platforms"
> + select MFD_CORE
> + select REGMAP_MMIO
> + help
> +   Select this to get support for Allwinner SoCs (A10, A13 and A31) ADC.
> +   This driver will only map the hardware interrupt and registers, you
> +   have to select individual drivers based on this MFD to be able to use
> +   the ADC or the thermal sensor. This will try to probe the ADC driver
> +   sunxi-gpadc-iio and the hwmon driver iio_hwmon.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called sunxi-gpadc-mfd.
> +
>  config MFD_ATMEL_HLCDC
>   tristate "Atmel HLCDC (High-end LCD Controller)"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 42a66e1..dcf43cd 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -201,6 +201,8 @@ obj-$(CONFIG_MFD_DLN2)+= dln2.o
>  obj-$(CONFIG_MFD_RT5033) += rt5033.o
>  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
>  
> +obj-$(CONFIG_MFD_SUNXI_ADC)  += sunxi-gpadc-mfd.o
> +
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/sunxi-gpadc-mfd.c b/drivers/mfd/sunxi-gpadc-mfd.c
> new file mode 100644
> index 000..f0005a6
> --- /dev/null
> +++ b/drivers/mfd/sunxi-gpadc-mfd.c
> @@ -0,0 +1,197 @@
> +/* ADC MFD core driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define SUNXI_IRQ_FIFO_DATA  0
> +#define SUNXI_IRQ_TEMP_DATA  1
> +
> +static struct resource adc_resources[] = {
> + {
> + .name   = "FIFO_DATA_PENDING",
> + .start  = SUNXI_IRQ_FIFO_DATA,
> + .end= SUNXI_IRQ_FIFO_DATA,
> + .flags  = IORESOURCE_IRQ,
> + }, {
> + .name   = "TEMP_DATA_PENDING",
> + .start  = SUNXI_IRQ_TEMP_DATA,
> + .end= SUNXI_IRQ_TEMP_DATA,
> + .flags  = IORESOURCE_IRQ,
> + },
> +};
> +
> +static const struct regmap_irq sunxi_gpadc_mfd_regmap_irq[] = {
> + REGMAP_IRQ_REG(SUNXI_IRQ_FIFO_DATA, 0, BIT(16)),
> + REGMAP_IRQ_REG(SUNXI_IRQ_TEMP_DATA, 0, BIT(18)),
> +};
> +
> +static const struct regmap_irq_chip sunxi_gpadc_mfd_regmap_irq_chip = {
> + .name = "sunxi_gpadc_mfd_irq_chip",
> + .status_base = SUNXI_GPADC_TP_INT_FIFOS,
> + .ack_base = SUNXI_GPADC_TP_INT_FIFOS,
> + .mask_base = SUNXI_GPADC_TP_INT_FIFOC,
> + .init_ack_masked = true,
> + .mask_invert = true,
> + .irqs = sunxi_gpadc_mfd_regmap_irq,
> + .num_irqs = ARRAY_SIZE(sunxi_gpadc_mfd_regmap_irq),
> + .num_regs = 1,
> +};
> +
> +static struct mfd_cell sun4i_gpadc_mfd_cells[] = {
> + {
> + .name   = "sun4i-a10-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + }, {
> + .name = "iio_hwmon",
> + }
> +};
> +
> +static struct mfd_cell sun5i_gpadc_mfd_cells[] = {
> + {
> + .name   = "sun5i-a13-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> +   

Re: [PATCH 01/10] mfd: cros_ec: add ChromeOS EC sensor platform information.

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> The platform information will be used for the new cros-ec sensors driver
> that presents sensors attached to the ChromeOS Embedded Controller.
> 
> Signed-off-by: Gwendal Grignou 
> Signed-off-by: Enric Balletbo i Serra 
Bring this in as an when you need it in the rest of the series.
It certainly doesn't need it's own patch.
> ---
>  include/linux/mfd/cros_ec.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index d6539c1..cd4833a 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -151,6 +151,16 @@ struct cros_ec_device {
>   int event_size;
>  };
>  
Check your kernel doc formatting.
> +/* struct cros_ec_sensor_platform - ChromeOS EC sensor platform information
> + *
> + * On top of cros_ec_devicem information cros_ec_sensors needs.
> + *
> + * @sensor_num: Id of the sensor, as reported by the EC.
> + */
> +struct cros_ec_sensor_platform {
> + u8 sensor_num;
> +};
> +
>  /* struct cros_ec_platform - ChromeOS EC platform information
>   *
>   * @ec_name: name of EC device (e.g. 'cros-ec', 'cros-pd', ...)
> 

Re: [PATCH 07/10] iio: cros_ec_activity: add ChromeOS EC Activity Sensors

[Jonathan Cameron]

On 18/07/16 08:02, Enric Balletbo i Serra wrote:
> Handle activity events detections presented by the ChromeOS
> EC Sensor hub. Activities can be simple (low/no motion) or more complex
> (riding train). They are being reported by physical devices or the EC
> itself.
> 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Enric Balletbo i Serra 
Interesting.  What docs exist?

For now this is probably more of an RFC than a finished driver, but
certainly interesting to know this stuff exists.

Jonathan
> ---
>  drivers/iio/common/cros_ec_sensors/Kconfig |  10 +
>  drivers/iio/common/cros_ec_sensors/Makefile|   1 +
>  .../iio/common/cros_ec_sensors/cros_ec_activity.c  | 294 
> +
>  3 files changed, 305 insertions(+)
>  create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_activity.c
> 
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig 
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index 02559d2..22b4211 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -29,3 +29,13 @@ config IIO_CROS_EC_LIGHT_PROX
> presented by the ChromeOS EC Sensor hub.
> Creates an IIO device for each functions.
> Only one source is exposed by the EC.
> +
> +config IIO_CROS_EC_ACTIVITY
> + tristate "ChromeOS EC Activity Sensors"
> + select IIO_CROS_EC_SENSORS_CORE
> + help
> +   Module to handle activity events detections presented by the ChromeOS
> +   EC Sensor hub.
> +   Activities can be simple (low/no motion) or more complex (riding 
> train).
> +   They are being reported by physical devices or the EC itself.
> +   Creates an IIO device to manage all activities.
> diff --git a/drivers/iio/common/cros_ec_sensors/Makefile 
> b/drivers/iio/common/cros_ec_sensors/Makefile
> index 7aaf2a2..8f54f1e 100644
> --- a/drivers/iio/common/cros_ec_sensors/Makefile
> +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> @@ -5,3 +5,4 @@
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
>  obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
>  obj-$(CONFIG_IIO_CROS_EC_LIGHT_PROX) += cros_ec_light_prox.o
> +obj-$(CONFIG_IIO_CROS_EC_ACTIVITY) += cros_ec_activity.o
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_activity.c 
> b/drivers/iio/common/cros_ec_sensors/cros_ec_activity.c
> new file mode 100644
> index 000..b2e39d6
> --- /dev/null
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_activity.c
> @@ -0,0 +1,294 @@
> +/*
> + * cros_ec_sensors_activity - Driver for activities/gesture recognition.
> + *
> + * Copyright (C) 2015 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the cros-ec interface to communicate with the Chrome OS
> + * EC about accelerometer data. Accelerometer access is presented through
> + * iio sysfs.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cros_ec_sensors_core.h"
> +
> +/* st data for ec_sensors iio driver. */
> +struct cros_ec_sensors_state {
> + /* Shared by all sensors */
> + struct cros_ec_sensors_core_state core;
> +
> + struct iio_chan_spec *channels;
> + unsigned int nb_activities;
> +};
> +
> +static const struct iio_event_spec cros_ec_activity_single_shot[] = {
> + {
> + .type = IIO_EV_TYPE_CHANGE,
> + /* significant motion trigger when we get out of still. */
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> +  },
> +};
> +
> +static int ec_sensors_read(struct iio_dev *indio_dev,
> +   struct iio_chan_spec const *chan,
> +   int *val, int *val2, long mask)
> +{
> + dev_warn(&indio_dev->dev, "%s: Not Expected: %d\n", __func__,
> +  chan->channel2);
> + return -EPERM;
> +}
> +
> +static int ec_sensors_write(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int val, int val2, long mask)
> +{
> + dev_warn(&indio_dev->dev, "%s: Not Expected: %d\n", __func__,
> +  chan->channel2);
> + return -EPERM;
> +}
> +
> +static int cros_ec_read_event_config(struct iio_dev *indio_dev,
> +  const struct iio_chan_spec *chan,
> +  enum iio_event_type type,
> +  enum iio_event_direction dir)
> +{
> + struct

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

[Bin Gao]

On Mon, Jul 18, 2016 at 10:07:24AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Gao  writes:
> >> > +int pd_sink_queue_msg(struct pd_sink_msg *msg)
> >> > +{
> >> > +unsigned long flags;
> >> > +struct pd_sink_port *port;
> >> > +
> >> > +if (msg->port < 0 || msg->port >= MAX_NR_SINK_PORTS) {
> >> > +pr_err("Invalid port number\n");
> >> > +return -EINVAL;
> >> > +}
> >> > +
> >> > +port = sink_ports[msg->port];
> >> > +
> >> > +spin_lock_irqsave(&port->rx_lock, flags);
> >> > +list_add_tail(&msg->list, &port->rx_list);
> >> > +spin_unlock_irqrestore(&port->rx_lock, flags);
> >> > +
> >> > +queue_work(port->rx_wq, &port->rx_work);
> >> 
> >> can we really queue several messages at a time? It seems unfeasible to
> >> me. It's not like we can queue several power request in a role. Why do
> >> you need this workqueue? Why don't you process message here, in place?
> > Some Type-C chargers send two messages in a short duration(less than 1 ms),
> > e.g. a SOURCE_CAPABILITY follows the previous SOURCE_CAPABILITY, or a
> > GET_SINK_CAPABILITY follows a previous SOURCE_CAPABILITY, etc. Queuing
> > message to PD stack by Type-C phy driver typically happens in a interrupt
> > context. So in this case a nested interrupt may happen. Our whole PD
> > stack while processing one message is not re-entrant so the nested
> > interrupt would cause a problem.
> 
> keep interrupts masked for as long as necessary until your message is
> processed.

Yes, that's a right way to go. 
We'll have to document this because there might be other Type-C
PHY drivers(other than Intel Whiskey Cove PMIC) to use the PD stack.

> 
> -- 
> balbi

Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support

[Bin Gao]

On Sat, Jul 16, 2016 at 08:49:53AM +0900, Greg Kroah-Hartman wrote:
> On Fri, Jul 15, 2016 at 03:41:10PM -0700, Bin Gao wrote:
> > On Fri, Jul 15, 2016 at 02:21:48PM +0300, Felipe Balbi wrote:
> > > Greg Kroah-Hartman  writes:
> > > > On Fri, Jul 15, 2016 at 01:38:12PM +0300, Felipe Balbi wrote:
> > > >> 
> > > >> Hi,
> > > >> 
> > > >> Bin Gao  writes:
> > > >> > +static void print_message(int port, bool is_cmsg, u8 msg, bool recv)
> > > >> > +{
> > > >> > +pr_info("sink port %d: %s message %s %s\n", port,
> > > >> > +is_cmsg ? "Control" : "Data",
> > > >> > +msg_to_string(is_cmsg, msg),
> > > >> > + recv ? "received" : "sent(wait GOODCRC)");
> > > >> > +}
> > > >> 
> > > >> this is problematic. By default, we're all using 115200 8N1 baud
> > > >> rate. This message alone prints anywhere from 50 to 100 characters (I
> > > >> didn't really count properly, these are rough numbers), and that takes:
> > > >> 
> > > >> n50chars_time = 50 / (115200 / 10) = 4.3ms
> > > >> n100chars_time = 100 / (115200 / 10) = 8.6ms
> > > >> 
> > > >> Considering you have 30ms to reply with Power Request after GoodCRC, 
> > > >> and
> > > >> considering you're printing several of these messages, they become
> > > >> really expensive and eat up valuable time from tSenderReply.
> > > >
> > > > printk() should be async, so it shouldn't be that big of a deal.
> > > 
> > > I can actually see this causing problems ;-) With this pr_info(),
> > > sometimes tSenderReply times out and Source gives a HardReset. Without
> > > pr_info(), type-c analyzer tells me we reply in less than 1ms.
> > > 
> > > > What is wrong is that this isn't using dev_info().
> > > 
> > > right, that too.
> > > 
> > > -- 
> > > balbi
> > 
> > When we don't have a struct device pointer for this driver,
> 
> Then you should fix that, as this is a driver for hardware :)
This is actualy a software stack to implement the USB PD spec.
Only the USB Type-C phy driver has a device pointer.
The PD stack vs. USB Type-C phy driver is similar to TCP/IP stack
vs. ethernet driver in the kernel. We don't have a device pointer
for TCP/IP stack code either.

Thanks,
Bin

> 
> thanks,
> 
> greg k-h

Re: [PATCH v3 4/4] vfs: Use dlock list for superblock's inode list

[Al Viro]

On Fri, Jul 15, 2016 at 01:39:43PM -0400, Waiman Long wrote:
>  void iterate_bdevs(void (*func)(struct block_device *, void *), void *arg)
>  {
>   struct inode *inode, *old_inode = NULL;
> + DEFINE_DLOCK_LIST_ITER(iter);
>  
> - spin_lock(&blockdev_superblock->s_inode_list_lock);
> - list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) {
> - struct address_space *mapping = inode->i_mapping;
> + while (dlock_list_next(&blockdev_superblock->s_inodes, &iter)) {
> + struct address_space *mapping;
>  
> + inode   = list_entry(iter.curr, struct inode, i_sb_list);
> + mapping = inode->i_mapping;

TBH, I would very much prefer something like
DEFINE_DLOCK_LIST_ITER(iter, &blockdev_superblock->s_inodes);

dlist_for_each_entry(inode, &iter, i_sb_list) {
mapping = inode->i_mapping;

> - spin_unlock(&blockdev_superblock->s_inode_list_lock);
> + spin_unlock(iter.lock);

... and this might be worth dlist_{un,re}lock(&iter);

Re: [PATCH net-next] macvtap: correctly free skb during socket destruction

[David Miller]

From: Jason Wang 
Date: Tue, 19 Jul 2016 11:02:59 +0800

> We should use kfree_skb() instead of kfree() to free an skb.
> 
> Fixes: 362899b8725b ("macvtap: switch to use skb array")
> Reported-by: Dan Carpenter 
> Signed-off-by: Jason Wang 

Applied, thanks Jason.

Re: [RFC PATCH 00/30] Kernel NET policy

[David Miller]

From: "Liang, Kan" 
Date: Tue, 19 Jul 2016 01:49:41 +

> Yes, rtnl will bring some overheads. But the configuration is one
> time thing for application or socket. It only happens on receiving
> first packet.

Thanks for destroying our connection rates.

This kind of overhead is simply unacceptable.

Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists

[Al Viro]

On Fri, Jul 15, 2016 at 01:39:40PM -0400, Waiman Long wrote:

> +struct dlock_list_head_percpu {
> + struct list_head list;
> + spinlock_t lock;
> +};

> +#define DLOCK_LIST_HEAD_PERCPU_INIT(name)\
> + {   \
> + .list.prev = &name.list,\
> + .list.next = &name.list,\
> + .list.lock = __SPIN_LOCK_UNLOCKED(name),\

What's .list.lock and how does that even compile?

> +extern bool dlock_list_next(struct dlock_list_head *dlist,
> + struct dlock_list_iter *iter);

Ugh...  Why not dlist_for_each_entry(), seeing that all users end up with
the same boilerplate?

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

[Greg Ungerer]

Hi Nicolas,

On 18/07/16 13:31, Nicolas Pitre wrote:
> Remove excessive casts, do some code grouping, etc.
> No functional changes.
> 
> Signed-off-by: Nicolas Pitre 
> ---
>  fs/binfmt_flat.c | 118 
> ++-
>  1 file changed, 56 insertions(+), 62 deletions(-)
> 
> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> index caf9e39bb8..085059d879 100644
> --- a/fs/binfmt_flat.c
> +++ b/fs/binfmt_flat.c
> @@ -80,7 +80,7 @@ struct lib_info {
>   unsigned long text_len; /* Length of text 
> segment */
>   unsigned long entry;/* Start address for 
> this module */
>   unsigned long build_date;   /* When this one was 
> compiled */
> - short loaded;   /* Has this library 
> been loaded? */
> + bool loaded;/* Has this library 
> been loaded? */
>   } lib_list[MAX_SHARED_LIBS];
>  };
>  
> @@ -107,7 +107,7 @@ static struct linux_binfmt flat_format = {
>  static int flat_core_dump(struct coredump_params *cprm)
>  {
>   printk("Process %s:%d received signr %d and should have core dumped\n",
> - current->comm, current->pid, (int) 
> cprm->siginfo->si_signo);
> + current->comm, current->pid, cprm->siginfo->si_signo);
>   return(1);
>  }
>  
> @@ -190,7 +190,7 @@ static int decompress_exec(
>   loff_t fpos;
>   int ret, retval;
>  
> - DBG_FLT("decompress_exec(offset=%x,buf=%x,len=%x)\n",(int)offset, 
> (int)dst, (int)len);
> + DBG_FLT("decompress_exec(offset=%lx,buf=%p,len=%lx)\n",offset, dst, 
> len);
>  
>   memset(&strm, 0, sizeof(strm));
>   strm.workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
> @@ -358,8 +358,8 @@ calc_reloc(unsigned long r, struct lib_info *p, int 
> curid, int internalp)
>   text_len = p->lib_list[id].text_len;
>  
>   if (!flat_reloc_valid(r, start_brk - start_data + text_len)) {
> - printk("BINFMT_FLAT: reloc outside program 0x%x (0 - 
> 0x%x/0x%x)",
> -(int) 
> r,(int)(start_brk-start_data+text_len),(int)text_len);
> + printk("BINFMT_FLAT: reloc outside program 0x%lx (0 - 
> 0x%lx/0x%lx)",
> +r, start_brk-start_data+text_len, text_len);

Seeing as you have modified quite a few printk calls is it worth
while annotating them with appropriate KERN_ERR, KERN_INFO, etc?
Just a thought.

Regards
Greg

Re: Kernel stability on baytrail machines

[Michal Feix]

Dne 13.7.2016 v 12:48 Pavel Machek napsal(a)


Are there any updates on the status of this issue?

The current bugzilla report [1] marks this as a power management
issue. However, many reports indicate that it would only freeze
when running X, so it's not completely clear if it's related to
the gfx driver too.

Does

"intel_idle.max_cstate=1"

fix it for you?

Yes, it does.

If you feel it is X-only problem, you may want to provide details
about your graphics subsystem (DRM enabled? framebuffer only?) and
probably cc.

It's not X-only problem. Happens even in console mode, which is KMS
switched during boot though.

...actually... you may want to verify if it happens in unaccelerated X.

As it happens even in console mode, is this relevant test?

No, no need to test with X.

Would it be possible to test in good old VGA mode?
For past few days I updated to 4.6.3 kernel and tested with X and 
without X, in console mode and no KMS. My machine is way more stable 
than with previous 4.5.* and 4.4.* kernels I tried.


With 4.6.3 kernel and X running, I had only one freeze during Firefox 
session with video playback. For the rest of two days of testing, no hang.


I was not able to hang the machine during another 2 days of testing with 
4.6.3 kernel and console mode with KMS disabled. It's fair to say, that 
stress testing of GFX is quite limited when running in console mode :-). 
I tried hard with mplayer with libcaca and with repeated kernel 
compilation task. No hang occured.


My conclussion is that 4.6.3 is surelly a huge improvement, compared to 
4.5 and 4.4. kernels regarding Bay trail stability issue.


Michal Feix

Re: [PATCH v3 12/17] mm, compaction: more reliably increase direct compaction priority

[Joonsoo Kim]

On Mon, Jul 18, 2016 at 02:21:02PM +0200, Vlastimil Babka wrote:
> On 07/18/2016 06:41 AM, Joonsoo Kim wrote:
> >On Fri, Jul 15, 2016 at 03:37:52PM +0200, Vlastimil Babka wrote:
> >>On 07/06/2016 07:39 AM, Joonsoo Kim wrote:
> >>>On Fri, Jun 24, 2016 at 11:54:32AM +0200, Vlastimil Babka wrote:
> During reclaim/compaction loop, compaction priority can be increased by 
> the
> should_compact_retry() function, but the current code is not optimal. 
> Priority
> is only increased when compaction_failed() is true, which means that 
> compaction
> has scanned the whole zone. This may not happen even after multiple 
> attempts
> with the lower priority due to parallel activity, so we might needlessly
> struggle on the lower priority and possibly run out of compaction retry
> attempts in the process.
> 
> We can remove these corner cases by increasing compaction priority 
> regardless
> of compaction_failed(). Examining further the compaction result can be
> postponed only after reaching the highest priority. This is a simple 
> solution
> and we don't need to worry about reaching the highest priority "too soon" 
> here,
> because hen should_compact_retry() is called it means that the system is
> already struggling and the allocation is supposed to either try as hard as
> possible, or it cannot fail at all. There's not much point staying at 
> lower
> priorities with heuristics that may result in only partial compaction.
> Also we now count compaction retries only after reaching the highest 
> priority.
> >>>
> >>>I'm not sure that this patch is safe. Deferring and skip-bit in
> >>>compaction is highly related to reclaim/compaction. Just ignoring them and 
> >>>(almost)
> >>>unconditionally increasing compaction priority will result in less
> >>>reclaim and less success rate on compaction.
> >>
> >>I don't see why less reclaim? Reclaim is always attempted before
> >>compaction and compaction priority doesn't affect it. And as long as
> >>reclaim wants to retry, should_compact_retry() isn't even called, so the
> >>priority stays. I wanted to change that in v1, but Michal suggested I
> >>shouldn't.
> >
> >I assume the situation that there is no !costly highorder freepage
> >because of fragmentation. In this case, should_reclaim_retry() would
> >return false since watermark cannot be met due to absence of high
> >order freepage. Now, please see should_compact_retry() with assumption
> >that there are enough order-0 free pages. Reclaim/compaction is only
> >retried two times (SYNC_LIGHT and SYNC_FULL) with your patchset since
> >compaction_withdrawn() return false with enough freepages and
> >!COMPACT_SKIPPED.
> >
> >But, before your patchset, COMPACT_PARTIAL_SKIPPED and
> >COMPACT_DEFERRED is considered as withdrawn so will retry
> >reclaim/compaction more times.
> 
> Perhaps, but it wouldn't guarantee to reach the highest priority.

Yes.

> 
> >As I said before, more reclaim (more freepage) increase migration
> >scanner's scan range and then increase compaction success probability.
> >Therefore, your patchset which makes reclaim/compaction retry less times
> >deterministically would not be safe.
> 
> After the patchset, we are guaranteed a full compaction has
> happened. If that doesn't help, yeah maybe we can try reclaiming
> more... but where to draw the line? Reclaim everything for an

To draw the line is a difficult problem. I know that. As I said before,
one of ideas is that reclaim/compaction continue until nr_reclaimed
reaches number of lru pages at beginning phase of reclaim/compaction
loop. It would not cause persistent thrashing, I guess.

> order-3 allocation just to avoid OOM, ignoring that the system might
> be thrashing heavily? Previously it also wasn't guaranteed to
> reclaim everything, but what is the optimal number of retries?

So, you say the similar logic in other thread we talked yesterday.
The fact that it wasn't guaranteed to reclaim every thing before
doesn't mean that we could relax guarantee more.

I'm not sure below is relevant to this series but just note.

I don't know the optimal number of retries. We are in a way to find
it and I hope this discussion would help. I don't think that we can
judge the point properly with simple checking on stat information at some
moment. It only has too limited knowledge about the system so it would
wrongly advise us to invoke OOM prematurely.

I think that using compaction result isn't a good way to determine if
further reclaim/compaction is useless or not because compaction result
can vary with further reclaim/compaction itself.

If we want to check more accurately if compaction is really impossible,
scanning whole range and checking arrangement of freepage and lru(movable)
pages would more help. Although there is some possibility to fail
the compaction even if this check is passed, it would give us more
information about the system state and we would

RE: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new usage model

[Zheng, Lv]

Hi, Benjamin

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v3 1/2] ACPI / button: Add KEY_LID_CLOSE for new
> usage model
> 
> Hi,
> 
> On Tue, Jul 12, 2016 at 12:17 PM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid open state. As a proxy layer acting between, ACPI
> > button driver is not able to handle all such cases, but need to re-define
> > the usage model of the ACPI lid. That is:
> > 1. It's initial state is not reliable;
> > 2. There may not be an open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds a new input key event so that the new userspace
> programs
> > can use it to handle this usage model correctly. And in the meanwhile, no
> > old programs will be broken by the userspace changes.
> > This patch also adds a button.lid_event_type parameter to allow the
> users
> > to switch between the 2 event types.
> 
> I think we are getting closer to what would be acceptable for
> user-space, but I still have a few comments:
[Lv Zheng] 
OK.

> 
> >
> > Signed-off-by: Lv Zheng 
> > Cc: Dmitry Torokhov 
> > Cc: Benjamin Tissoires 
> > Cc: Bastien Nocera: 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  drivers/acpi/button.c  |  109 +--
> -
> >  include/uapi/linux/input-event-codes.h |6 ++
> >  2 files changed, 91 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 148f4e5..1298ef8 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -57,6 +57,9 @@
> >  #define ACPI_BUTTON_LID_INIT_OPEN  0x01
> >  #define ACPI_BUTTON_LID_INIT_METHOD0x02
> >
> > +#define ACPI_BUTTON_LID_EVENT_KEY  0x00
> > +#define ACPI_BUTTON_LID_EVENT_SWITCH   0x01
> > +
> >  #define _COMPONENT ACPI_BUTTON_COMPONENT
> >  ACPI_MODULE_NAME("button");
> >
> > @@ -110,6 +113,7 @@ struct acpi_button {
> >  static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
> >  static struct acpi_device *lid_device;
> >  static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
> > +static u8 lid_event_type = ACPI_BUTTON_LID_EVENT_SWITCH;
> >
> >  /* 
> > --
> >FS Interface (/proc)
> > @@ -136,8 +140,17 @@ static int acpi_lid_notify_state(struct
> acpi_device *device, int state)
> > int ret;
> >
> > /* input layer checks if event is redundant */
> > -   input_report_switch(button->input, SW_LID, !state);
> > -   input_sync(button->input);
> > +   if (lid_event_type == ACPI_BUTTON_LID_EVENT_SWITCH) {
> > +   input_report_switch(button->input, SW_LID, !state);
> > +   input_sync(button->input);
> > +   }
> > +   if (lid_event_type == ACPI_BUTTON_LID_EVENT_KEY &&
> > +  !state) {
> > +   input_report_key(button->input, KEY_LID_CLOSE, 1);
> > +   input_sync(button->input);
> > +   input_report_key(button->input, KEY_LID_CLOSE, 0);
> > +   input_sync(button->input);
> > +   }
> >
> > if (state)
> > pm_wakeup_event(&device->dev, 0);
> > @@ -292,6 +305,9 @@ static int acpi_lid_update_state(struct
> acpi_device *device)
> >
> >  static void acpi_lid_initialize_state(struct acpi_device *device)
> >  {
> > +   if (lid_event_type == ACPI_BUTTON_LID_EVENT_KEY)
> > +   return;
> > +
> > switch (lid_init_state) {
> > case ACPI_BUTTON_LID_INIT_OPEN:
> > (void)acpi_lid_notify_state(device, 1);
> > @@ -436,6 +452,7 @@ static int acpi_button_add(struct acpi_device
> *device)
> >
> > case ACPI_BUTTON_TYPE_LID:
> > input_set_capability(input, EV_SW, SW_LID);
> > +   input_set_capability(input, EV_KEY, KEY_LID_CLOSE);
> 
> Here you are basically exporting the 2 input events but only update
> one of the 2. It will confuse userspace and it is generally better not
> to export unused input codes.
[Lv Zheng] 
I just do not know if it is proper to clear the capability during runtime via 
module parameters.


> 
> However, as I'll say below, I think we should keep the code that way here.
[Lv Zheng] 
Great. So we needn't think about input_clear_capability().

> 
> 
> > break;
> > }
> >
> > @@ -475,35 +492,49 @@ static int acpi_button_remove(struct
> acpi_device *device)
> >
> >  static int param_set_lid_init_state(const char *val, struct kernel_param
> *kp)
> >  {
> > -   int result = 0;
> > -
> > -   if (!strncmp(val, "open", sizeof("open") - 1)) {
> > -   lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
> > -   pr_info("Notify initial lid state as open\n");
> > -   } else if (!strncmp(val, "method", sizeof("method") - 1)) {
> > -  

Re: [PATCH 3/3] f2fs: support clone_file_range

[Jaegeuk Kim]

On Mon, Jul 18, 2016 at 08:47:36PM -0700, Christoph Hellwig wrote:
> On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote:
> > This patch implements clone_file_range in f2fs.
> 
> [...]
> 
> > +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in,
> > +   struct file *file_out, loff_t pos_out, u64 len)
> > +{
> > +   return f2fs_clone_files(file_in, pos_in, file_out, pos_out, len);
> > +}
> > +
> 
> Falling back from copy to clone should be done in the VFS.  I look into
> implementing the fallback, and the code is trivial, but we don't seem
> to have any useful coverage for copy_file_range yet, so I didn't dare
> to add it yet.  How did you test copy and clone in f2fs?  And how did
> you handle the difference in corner cases (e.g. the lacking 0 special
> case in copy)?

Frankly speaking, I confused the behaviors without being aware of corner cases.
And thus, I dropped the patches already. Instead, I realized that what I did
was moving a range of blocks from one file to another file. So, I've been
testing a new ioctl, F2FS_IOC_MOVE_RANGE.
In terms of coverage, I just did some unit tests only.

Thanks,

[PATCH][v2] timekeeping: Fix memory overwrite of sleep_time_bin array

[Chen Yu]

It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is actually no other process would like to grab
this lock on that problematic platform.

Further investigation shows that, the problem is caused by setting
/sys/power/pm_trace to 1 before the 1st hibernation, since once
pm_trace is enabled, the rtc becomes an unmeaningful value after resumed,
which might bring a significant long sleep time in timekeeping_resume,
thus in tk_debug_account_sleep_time, if the bit31 happened to be set to 1,
the fls might return 32 and then we add 1 to sleep_time_bin[32], which
caused a memory overwritten. As System.map shows:

81c9d080 b sleep_time_bin
81c9d100 B dma_spin_lock

Thus set the dma_spin_lock.val to 1, which caused this problem.

To fix this problem, we ignore those abnormal sleep time,
since no one would like to sleep that long.

Cc: Stable  # 3.17+
Suggested-by: Rafael J. Wysocki 
Reported-and-tested-by: Janek Kozicki 
Signed-off-by: Chen Yu 
---
 kernel/time/timekeeping_debug.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index f6bd652..b164bb9 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -24,6 +24,7 @@
 #include "timekeeping_internal.h"
 
 static unsigned int sleep_time_bin[32] = {0};
+#define MAX_SLEEP_TIME 0x7fff
 
 static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
 {
@@ -69,6 +70,7 @@ late_initcall(tk_debug_sleep_time_init);
 
 void tk_debug_account_sleep_time(struct timespec64 *t)
 {
-   sleep_time_bin[fls(t->tv_sec)]++;
+   if ((t->tv_sec >= 0) && (t->tv_sec <= MAX_SLEEP_TIME))
+   sleep_time_bin[fls(t->tv_sec)]++;
 }
 
-- 
2.7.4

RE: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by implementing prepare_late/finish_early suspend_ops callbacks

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Subject: Re: [RFC PATCH 3/3] ACPI / PM: Fix EC polling issue by
> implementing prepare_late/finish_early suspend_ops callbacks
> 
> On Tuesday, June 28, 2016 04:04:46 PM Lv Zheng wrote:
> > _PTS/_WAK may contain EC transactions, it is better to have them
> handled
> > with IRQ enabled. This patch moves the 2 suspend PM ops from noirq
> stage
> > to late/early stage.
> >
> > Signed-off-by: Lv Zheng 
> 
> There are systems that won't work with this patch applied, so I don't
> see a point in applying the other two.
[Lv Zheng] 
I see.
Then instead of moving _WAK/_PTS out of noirq stage, we need to think about 
tuning the performance of the EC polling mode.

Thanks and best regards
-Lv

> 
> > ---
> >  drivers/acpi/sleep.c |5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> > index d30fce7f..c5c374c9 100644
> > --- a/drivers/acpi/sleep.c
> > +++ b/drivers/acpi/sleep.c
> > @@ -595,9 +595,10 @@ static int
> acpi_suspend_state_valid(suspend_state_t pm_state)
> >  static const struct platform_suspend_ops acpi_suspend_ops = {
> > .valid = acpi_suspend_state_valid,
> > .begin = acpi_suspend_begin,
> > -   .prepare_noirq = acpi_pm_prepare,
> > +   .prepare_late = __acpi_pm_prepare,
> > +   .prepare_noirq = acpi_pm_pre_suspend,
> > .enter = acpi_suspend_enter,
> > -   .finish_noirq = acpi_pm_finish,
> > +   .finish_early = acpi_pm_finish,
> > .end = acpi_pm_end,
> >  };
> >
> >
> 
> Thanks,
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] virtio_blk: Fix a slient kernel panic

[Minfei Huang]

From: Minfei Huang 

We do a lot of memory allocation in function init_vq, and don't handle
the allocation failure properly. Then this function will return 0,
although initialization fails due to lacking memory. At that moment,
kernel will panic in guest machine, if virtio is used to drive disk.

To fix this bug, we should take care of allocation failure, and return
correct value to let caller know what happen.

Tested-by: Chao Fan 
Signed-off-by: Minfei Huang 
Signed-off-by: Minfei Huang 
---
v2:
- Remove useless initialisation to NULL
v1:
- Refactor the patch to make code more readable
---
 drivers/block/virtio_blk.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 42758b5..4ee78c0 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
num_vqs = 1;
 
vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
-   if (!vblk->vqs) {
-   err = -ENOMEM;
-   goto out;
-   }
+   if (!vblk->vqs)
+   return -ENOMEM;
 
names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
-   if (!names)
-   goto err_names;
-
callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
-   if (!callbacks)
-   goto err_callbacks;
-
vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
-   if (!vqs)
-   goto err_vqs;
+   if (!names || !callbacks || !vqs) {
+   err = -ENOMEM;
+   goto out;
+   }
 
for (i = 0; i < num_vqs; i++) {
callbacks[i] = virtblk_done;
@@ -420,7 +414,7 @@ static int init_vq(struct virtio_blk *vblk)
/* Discover virtqueues and write information to configuration.  */
err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names);
if (err)
-   goto err_find_vqs;
+   goto out;
 
for (i = 0; i < num_vqs; i++) {
spin_lock_init(&vblk->vqs[i].lock);
@@ -428,16 +422,12 @@ static int init_vq(struct virtio_blk *vblk)
}
vblk->num_vqs = num_vqs;
 
- err_find_vqs:
+out:
kfree(vqs);
- err_vqs:
kfree(callbacks);
- err_callbacks:
kfree(names);
- err_names:
if (err)
kfree(vblk->vqs);
- out:
return err;
 }
 
-- 
2.7.4 (Apple Git-66)

Re: [PATCH v1] ESIA : Dummy eisa_driver_register should return error code

[Christoph Hellwig]

On Tue, Jul 19, 2016 at 12:15:01AM +0530, Arvind Yadav wrote:
> The inline eisa_driver_register stub simply allows compilation on
> systems with CONFIG_EISA disabled. the dummy eisa_driver_register
> does not register an *_eisa_driver at all. The inline
> eisa_driver_register should return to indicate lack of support
> when attempting to register an *_eisa_driver on such a system with
> CONFIG_EISA disabled.

Why?  The idea is that you can simply leave the stub in if registering
say PCI / EISA.  With your change such a driver will fail to load even
if it could serve PCI device in a !CONFIG_EISA config, which is the
behavior we want.

Re: [PATCH net-next v3 10/12] net: dsa: support switchdev ageing time attr

[Florian Fainelli]

Le 18/07/2016 à 20:24, Andrew Lunn a écrit :
> On Mon, Jul 18, 2016 at 08:45:38PM -0400, Vivien Didelot wrote:
>> Add a new function for DSA drivers to handle the switchdev
>> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute.
>>
>> The ageing time is passed as milliseconds.
>>
>> Also because we can have multiple logical bridges on top of a physical
>> switch and ageing time are switch-wide, call the driver function with
>> the fastest ageing time in use on the chip instead of the requested one.
>>
>> Signed-off-by: Vivien Didelot 
>> ---
>>  include/net/dsa.h |  2 ++
>>  net/dsa/slave.c   | 41 +
> 

Hi Andrew,

> Hi Florian
> 
> It looks like the SF2 can do fast ageing per port. What i don't see if
> what configuration options you have. Can you get the fast and the
> normal age time per port? Or is it global?

The normal ageing is global and the value needs to be programmed in
seconds, can can range from 10 to 1,048,575 (encoded on 20 bits). The
fast-ageing can actually be per-port, per-VLAN id, for just dynamic or
static entries etc. and is just a poor name for a flush based on any of
these criteria.
-- 
Florian

Re: [PATCH] radix-tree: fix radix_tree_iter_retry() for tagged iterators.

[Ross Zwisler]

On Sat, Jul 16, 2016 at 04:45:31PM +0300, Konstantin Khlebnikov wrote:
> On Fri, Jul 15, 2016 at 10:00 PM, Ross Zwisler
>  wrote:
<>
> > 3) radix_tree_iter_next() via via a non-tagged iteration like
> > radix_tree_for_each_slot().  This currently happens in shmem_tag_pins()
> > and shmem_partial_swap_usage().
> >
> > I think that this case is currently unhandled.  Unlike with
> > radix_tree_iter_retry() case (#1 above) we can't rely on 'count' in the else
> > case of radix_tree_next_slot() to be zero, so I think it's possible we'll 
> > end
> > up executing code in the while() loop in radix_tree_next_slot() that assumes
> > 'slot' is valid.
> >
> > I haven't actually seen this crash on a test setup, but I don't think the
> > current code is safe.
> 
> This is becase distance between ->index and ->next_index now could be
> more that one?
>
> We could fix that by adding "iter->index = iter->next_index - 1;" into
> radix_tree_iter_next()
> right after updating next_index and tweak multi-order itreration logic
> if it depends on that.
> 
> I'd like to keep radix_tree_next_slot() as small as possible because
> this is supposed to be a fast-path.

I think it'll be exactly one?

iter->next_index = __radix_tree_iter_add(iter, 1);

So iter->index will be X, iter->next_index will be X+1, accounting for the
iterator's shift.  So, basically, whatever your height is, you'll be set up to
process one more entry, I think.

This means that radix_tree_chunk_size() will return 1.  I guess with the
current logic this is safe:

static __always_inline void **
radix_tree_next_slot(void **slot, struct radix_tree_iter *iter, unsigned flags)
{
...
} else {
long count = radix_tree_chunk_size(iter);
void *canon = slot;

while (--count > 0) {
/* code that assumes 'slot' is non-NULL */

So 'count' will be 1, the prefix decrement will make it 0, so we won't execute
the code in the while() loop.  So maybe all the cases are covered after all.

It seems like we need some unit tests in tools/testing/radix-tree around this
- I'll try and find time to add them this week.

I just feel like this isn't very organized.  We have a lot of code in
radix_tree_next_slot() that assumes that 'slot' is non-NULL, but we don't
check it anywhere.  We know it *can* be NULL, but we just happen to have
things set up so that none of the code that uses 'slot' is executed.

I personally feel like a quick check for slot==NULL at the beginning of the
function is the simplest way to keep ourselves safe, and it doesn't seem like
we'd be adding that much overhead.

Re: [PATCH] i2c: efm32: fix a failure path in efm32_i2c_probe()

[Wolfram Sang]

On Sat, Jul 16, 2016 at 02:36:38AM +0300, Alexey Khoroshilov wrote:
> There is the only failure path in efm32_i2c_probe(),
> where clk_disable_unprepare() is missed.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

[PATCH V2 2/2] crypto: vmx - Convert to CPU feature based module autoloading

[alastair]

From: Alastair D'Silva 

This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.

Signed-off-by: Alastair D'Silva 
---
 drivers/crypto/vmx/Kconfig | 2 +-
 drivers/crypto/vmx/vmx.c   | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index 89d8208..a83ead1 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,7 +1,7 @@
 config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
depends on CRYPTO_DEV_VMX
-   default y
+   default m
help
  Support for VMX cryptographic acceleration instructions on Power8 CPU.
  This module supports acceleration for AES and GHASH in hardware. If 
you
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index e163d57..5a40f2f 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,9 +44,6 @@ int __init p8_init(void)
int ret = 0;
struct crypto_alg **alg_it;
 
-   if (!(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_VEC_CRYPTO))
-   return -ENODEV;
-
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
printk(KERN_INFO "crypto_register_alg '%s' = %d\n",
@@ -78,7 +76,7 @@ void __exit p8_exit(void)
crypto_unregister_shash(&p8_ghash_alg);
 }
 
-module_init(p8_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, p8_init);
 module_exit(p8_exit);
 
 MODULE_AUTHOR("Marcelo Cerri");
-- 
2.7.4

V2: No change

[PATCH V2 0/2] Automatically load the vmx_crypto module if supported

[alastair]

From: Alastair D'Silva 

This series allows the vmx_crypto module to be detected and automatically
loaded via UDEV if the CPU supports the vector crypto feature.

Alastair D'Silva (2):
  powerpc: Add module autoloading based on CPU features
  crypto: vmx - Convert to CPU feature based module autoloading

 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/include/asm/cpufeature.h | 70 +++
 drivers/crypto/vmx/Kconfig|  2 +-
 drivers/crypto/vmx/vmx.c  |  6 +--
 4 files changed, 74 insertions(+), 5 deletions(-)
 create mode 100644 arch/powerpc/include/asm/cpufeature.h

-- 
2.7.4

[PATCH V2 1/2] powerpc: Add module autoloading based on CPU features

[alastair]

From: Alastair D'Silva 

This patch provides the necessary infrastructure to allow drivers
to be automatically loaded via UDEV. It implements the minimum
required to be able to use module_cpu_feature_match to trigger
the GENERIC_CPU_AUTOPROBE mechanisms.

The features exposed are a mirror of the cpu_user_features
(converted to an offset from a mask). This decision was made to
ensure that the behavior between features for module loading and
userspace are consistent.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/include/asm/cpufeature.h | 70 +++
 2 files changed, 71 insertions(+)
 create mode 100644 arch/powerpc/include/asm/cpufeature.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a9d439..a6e49db 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -164,6 +164,7 @@ config PPC
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
+   select GENERIC_CPU_AUTOPROBE
 
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/cpufeature.h 
b/arch/powerpc/include/asm/cpufeature.h
new file mode 100644
index 000..f6b2ac9
--- /dev/null
+++ b/arch/powerpc/include/asm/cpufeature.h
@@ -0,0 +1,70 @@
+/* CPU feature definitions for module loading, used by
+ * module_cpu_feature_match(), see asm/cputable.h for powerpc CPU features
+ *
+ * Copyright 2016 Alastair D'Silva, IBM Corporation.
+ *
+ * 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.
+ */
+
+#ifndef __ASM_POWERPC_CPUFEATURE_H
+#define __ASM_POWERPC_CPUFEATURE_H
+
+#include 
+
+/* Keep these in step with powerpc/include/asm/cputable.h */
+#define MAX_CPU_FEATURES (2 * 32)
+
+#define PPC_MODULE_FEATURE_32  (ilog2(PPC_FEATURE_32))
+#define PPC_MODULE_FEATURE_64  (ilog2(PPC_FEATURE_64))
+#define PPC_MODULE_FEATURE_601_INSTR   
(ilog2(PPC_FEATURE_601_INSTR))
+#define PPC_MODULE_FEATURE_HAS_ALTIVEC 
(ilog2(PPC_FEATURE_HAS_ALTIVEC))
+#define PPC_MODULE_FEATURE_HAS_FPU 
(ilog2(PPC_FEATURE_HAS_FPU))
+#define PPC_MODULE_FEATURE_HAS_MMU 
(ilog2(PPC_FEATURE_HAS_MMU))
+#define PPC_MODULE_FEATURE_HAS_4xxMAC  
(ilog2(PPC_FEATURE_HAS_4xxMAC))
+#define PPC_MODULE_FEATURE_UNIFIED_CACHE   
ilog2(PPC_FEATURE_UNIFIED_CACHE))
+#define PPC_MODULE_FEATURE_HAS_SPE 
(ilog2(PPC_FEATURE_HAS_SPE))
+#define PPC_MODULE_FEATURE_HAS_EFP_SINGLE  
(ilog2(PPC_FEATURE_HAS_EFP_SINGLE))
+#define PPC_MODULE_FEATURE_HAS_EFP_DOUBLE  
(ilog2(PPC_FEATURE_HAS_EFP_DOUBLE))
+#define PPC_MODULE_FEATURE_NO_TB   
(ilog2(PPC_FEATURE_NO_TB))
+#define PPC_MODULE_FEATURE_POWER4  
(ilog2(PPC_FEATURE_POWER4))
+#define PPC_MODULE_FEATURE_POWER5  
(ilog2(PPC_FEATURE_POWER5))
+#define PPC_MODULE_FEATURE_POWER5_PLUS 
(ilog2(PPC_FEATURE_POWER5_PLUS))
+#define PPC_MODULE_FEATURE_CELL
(ilog2(PPC_FEATURE_CELL))
+#define PPC_MODULE_FEATURE_BOOKE   
(ilog2(PPC_FEATURE_BOOKE))
+#define PPC_MODULE_FEATURE_SMT (ilog2(PPC_FEATURE_SMT))
+#define PPC_MODULE_FEATURE_ICACHE_SNOOP
(ilog2(PPC_FEATURE_ICACHE_SNOOP))
+#define PPC_MODULE_FEATURE_ARCH_2_05   
(ilog2(PPC_FEATURE_ARCH_2_05))
+#define PPC_MODULE_FEATURE_PA6T
(ilog2(PPC_FEATURE_PA6T))
+#define PPC_MODULE_FEATURE_HAS_DFP 
(ilog2(PPC_FEATURE_HAS_DFP))
+#define PPC_MODULE_FEATURE_POWER6_EXT  
(ilog2(PPC_FEATURE_POWER6_EXT))
+#define PPC_MODULE_FEATURE_ARCH_2_06   
(ilog2(PPC_FEATURE_ARCH_2_06))
+#define PPC_MODULE_FEATURE_HAS_VSX 
(ilog2(PPC_FEATURE_HAS_VSX))
+#define PPC_MODULE_FEATURE_PSERIES_PERFMON_COMPAT  
(ilog2(PPC_FEATURE_PSERIES_PERFMON_COMPAT))
+#define PPC_MODULE_FEATURE_TRUE_LE 
(ilog2(PPC_FEATURE_TRUE_LE))
+#define PPC_MODULE_FEATURE_PPC_LE  
(ilog2(PPC_FEATURE_PPC_LE))
+
+#define PPC_MODULE_FEATURE_ARCH_2_07   (32 + 
ilog2(PPC_FEATURE2_ARCH_2_07))
+#define PPC_MODULE_FEATURE_HTM (32 + 
ilog2(PPC_FEATURE2_HTM))
+#define PPC_MODULE_FEATURE_DSCR(32 + 
ilog2(PPC_FEATURE2_DSCR))
+#define PPC_MODULE_FEATURE_EBB (32 + 
ilog2(PPC_FEATURE2_EBB))
+#define PPC_MODULE_FEATURE_ISEL(32 + 
ilog2(PPC_FEATURE2_ISEL))
+#define PPC_MODULE_FEATURE_TAR (32 + 

Re: [PATCH 5/5] f2fs: use blk_plug in all the possible paths

[Christoph Hellwig]

On Thu, Jul 14, 2016 at 08:05:02PM -0700, Jaegeuk Kim wrote:
> >From kernel guys working on android.

Well, until it's mainline it simply doesn't matter, so NAK to this
patch.  Tying power behavior to plugs also sounds pretty broken, so we'd
probably come up with something better if they bothered to actually
submit their patches upsteam or at least explaining what they want
to archive.

Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

[Herbert Xu]

On Tue, Jul 19, 2016 at 11:01:55AM +1000, Michael Ellerman wrote:
>
> Can you please ask for an ack before merging arch patches?
> 
> That's a 70 line powerpc patch and a 6 line crypto patch. It has no
> reviews and no acks. I would have preferred it if we could take it via
> the powerpc tree.

Sorry, I'll delete them from the crypto tree.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the pm tree with the i2c tree

[Wolfram Sang]

> > Well, not knowing much about ACPI, I just need the conflict resolution
> > for my latest i2c/for-next and your above branch. If you want to do it,
> > fine with me. But maybe Jarkko will be back to office on Monday, too.
> 
> Unfortunately, I don't see how these branches can be merged in a sensible
> way without adding too much new code into the merge itself.
> 
> Something needs to be dropped and then rebased and applied again.

Okay, I'll drop the I2C parts. Next to the core parts which I will drop,
there was also a driver patch making use of the core changes for which I
requested some updates. Since those did not happen yet (Jarkko on
holiday?), the core patches alone are not important anyhow.

Thanks for looking into it!

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH 3/3] f2fs: support clone_file_range

[Christoph Hellwig]

On Sat, Jul 16, 2016 at 11:24:27PM -0700, Jaegeuk Kim wrote:
> This patch implements clone_file_range in f2fs.

[...]

> +int f2fs_clone_file_range(struct file *file_in, loff_t pos_in,
> + struct file *file_out, loff_t pos_out, u64 len)
> +{
> + return f2fs_clone_files(file_in, pos_in, file_out, pos_out, len);
> +}
> +

Falling back from copy to clone should be done in the VFS.  I look into
implementing the fallback, and the code is trivial, but we don't seem
to have any useful coverage for copy_file_range yet, so I didn't dare
to add it yet.  How did you test copy and clone in f2fs?  And how did
you handle the difference in corner cases (e.g. the lacking 0 special
case in copy)?

Re: [PATCH] hwmon-ntc_thermistor: Delete an unnecessary check before the function call "iio_channel_release"

[Guenter Roeck]

On 07/18/2016 11:54 AM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Mon, 18 Jul 2016 20:34:41 +0200

The iio_channel_release() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 


A much better change would be to use devm_iio_channel_get() instead of
iio_channel_get(), and to remove ntc_iio_channel_release() completely.

Guenter

Re: [RFC PATCH V2] s390/perf: fix 'start' address of module's map

[Songshan Gong]

在 7/19/2016 9:50 AM, Songshan Gong 写道:



在 7/19/2016 9:37 AM, Songshan Gong 写道:



在 7/18/2016 10:07 PM, Jiri Olsa 写道:

On Fri, Jul 15, 2016 at 06:15:11PM +0800, Song Shan Gong wrote:

At preset, when creating module's map, perf gets 'start' address by
parsing
'/proc/modules', but it's module base address, isn't the start
address of
'.text' section. In most archs, it's OK. But for s390, it places
'GOT' and
'PLT' relocations before '.text' section. So there exists an offset
between
module base address and '.text' section, which will incur wrong symbol
resolution for modules.

Fix this bug by getting 'start' address of module's map from parsing
'/sys/module/[module name]/sections/.text', not from '/proc/modules'.

Signed-off-by: Song Shan Gong 
---
 tools/perf/arch/s390/util/Build  |  2 ++
 tools/perf/arch/s390/util/sym-handling.c | 27
+++
 tools/perf/util/machine.c|  8 
 tools/perf/util/machine.h|  1 +
 4 files changed, 38 insertions(+)
 create mode 100644 tools/perf/arch/s390/util/sym-handling.c

diff --git a/tools/perf/arch/s390/util/Build
b/tools/perf/arch/s390/util/Build
index 8a61372..5e322ed 100644
--- a/tools/perf/arch/s390/util/Build
+++ b/tools/perf/arch/s390/util/Build
@@ -2,3 +2,5 @@ libperf-y += header.o
 libperf-y += kvm-stat.o

 libperf-$(CONFIG_DWARF) += dwarf-regs.o
+
+libperf-y += sym-handling.o
diff --git a/tools/perf/arch/s390/util/sym-handling.c
b/tools/perf/arch/s390/util/sym-handling.c
new file mode 100644
index 000..ff51336
--- /dev/null
+++ b/tools/perf/arch/s390/util/sym-handling.c
@@ -0,0 +1,27 @@
+#include 
+#include 
+#include 
+#include "util.h"
+#include "machine.h"
+#include "api/fs/fs.h"
+
+int arch__fix_module_text_start(u64 *start, const char *name)
+{
+char path[PATH_MAX];
+char *module_name = NULL;
+int len;
+
+if (!(module_name = strdup(name)))
+return -1;
+
+len = strlen(module_name);
+module_name[len - 1] = '\0';
+snprintf(path, PATH_MAX, "module/%s/sections/.text",
+module_name + 1);


why can't you use 'name' in here? I can't see the reason
you allocated module_name..


Oh, yes.


Sorry, just ignore the upper reply.

I use the 'module_name' here instead of 'name', because 'name' is
something like '[module_name]', I need strip the '[' and ']', so I have
to set the tail ']' to '\0' to indicate the string end, which will need
change the constant variable 'name'.


, I found a new way to implement it.

I could use '%.*s' to format the 'path', 'name' is enough indeed.

It's so concise now. Appreciate.





+
+if (sysfs__read_ull(path, (unsigned long long *)start) < 0) {
+free(module_name);
+return -1;
+}


leaking module_name in here


yes, thanks.



+return 0;
+}


SNIP

thanks,
jirka







--
SongShan Gong

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo  
wrote:
>
> Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
>  
> > If you have a single patch (or few) relative to yesterday's tip tree,
> > please send it to me as well and I will apply it as a fix patch if Ingo
> > doesn't get to pulling in time.  
> 
> [acme@jouet linux]$ git log --pretty=oneline  
> 9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf
>  
> ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h 
> and check for drift
> 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove 
> include/linux/list.h from perf's MANIFEST
> de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files 
> accessed from the kernel and check for drift
> ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from 
> perf's MANIFEST, not used
> e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove 
> tools/perf/util/include/linux/const.h
> 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove 
> tools/perf/util/include/asm/byteorder.h
> 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing 
> linux/compiler.h include to perf-sys.h
> 
> Available on my repo/branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> 
> I don't know exactly how linux-next works, would it be possible to merge in 
> this branch
> till it gets into tip/perf/core?

OK, I added this to linux-next today (as a temporary measure), but it
fails the same way.  To be clear, I merged the above branch (without
the rest of the tip tree) and it fails the same way. :-(

It produces these errors (from the x86_64 allmodconfig build):

In file included from 
/home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from /home/sfr/next/next/tools/include/linux/types.h:9,
 from /home/sfr/next/next/tools/include/linux/list.h:4,
 from elf.h:23,
 from elf.c:30:
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error 
Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

(and more similar).

I have applied my patch from yesterday ("tools: Simplify
__BITS_PER_LONG define"), and will continue on.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v13 00/12] support "task_isolation" mode

[Chris Metcalf]

On 7/18/2016 6:11 PM, Andy Lutomirski wrote:

As an example, enough vmalloc/vfree activity will eventually cause
flush_tlb_kernel_range to be called and*boom*, there goes your shiny
production dataplane application.


Well, that's actually a refinement that I did not inflict on this patch
series.

Submit it separately, perhaps?

The "kill the process if it goofs" thing while there are known goofs
in the kernel, apparently with patches written but unsent, seems
questionable.


Sure, that's a good idea.

I think what I will plan to do is, once the patch series is accepted into
some tree, return to this piece.  I'll have to go back and look at the internal
Tilera version of this code, since we have diverged quite a ways from that
in the 13 versions of the patch series, but my memory is that the kernel TLB
flush management was the only substantial piece of additional code not in
the initial batch of changes.  The extra requirement is the need to have a
hook very early on in the kernel entry path that you can hook in all paths;
arm64 has the ct_user_exit macro and tile has the finish_interrupt_save macro,
but I'm not sure there's something equivalent on x86 to catch all entries.

It's worth noting that the typical target application for task isolation, though
(at least in our experience) is a pretty dedicated machine, with the primary
application running in task isolation mode almost all of the time, and so
you are generally in pretty good control of all aspects of the system, including
whether or not you are generating kernel TLB flushes from your non task
isolation cores.  So I would argue the kernel TLB flush management piece is
an improvement to, not a requirement for, the main patch series.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: [PATCH net-next v3 10/12] net: dsa: support switchdev ageing time attr

[Andrew Lunn]

On Mon, Jul 18, 2016 at 08:45:38PM -0400, Vivien Didelot wrote:
> Add a new function for DSA drivers to handle the switchdev
> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute.
> 
> The ageing time is passed as milliseconds.
> 
> Also because we can have multiple logical bridges on top of a physical
> switch and ageing time are switch-wide, call the driver function with
> the fastest ageing time in use on the chip instead of the requested one.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  include/net/dsa.h |  2 ++
>  net/dsa/slave.c   | 41 +

Hi Florian

It looks like the SF2 can do fast ageing per port. What i don't see if
what configuration options you have. Can you get the fast and the
normal age time per port? Or is it global?

   Andrew

[PATCH net-next] macvtap: correctly free skb during socket destruction

[Jason Wang]

We should use kfree_skb() instead of kfree() to free an skb.

Fixes: 362899b8725b ("macvtap: switch to use skb array")
Reported-by: Dan Carpenter 
Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 9204d19..a38c0da 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -536,7 +536,7 @@ static void macvtap_sock_destruct(struct sock *sk)
struct sk_buff *skb;
 
while ((skb = skb_array_consume(&q->skb_array)) != NULL)
-   kfree(skb);
+   kfree_skb(skb);
 }
 
 static int macvtap_open(struct inode *inode, struct file *file)
-- 
2.7.4

Re: linux-next: manual merge of the rcu tree with the tip tree

[Paul E. McKenney]

On Mon, Jul 18, 2016 at 03:26:28PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next merge of the rcu tree got a conflict in:
> 
>   kernel/rcu/tree.c
> 
> between commit:
> 
>   4df8374254ea ("rcu: Convert rcutree to hotplug state machine")
> 
> from the tip tree and commit:
> 
>   2a84cde733b0 ("rcu: Exact CPU-online tracking for RCU")
> 
> from the rcu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Ah, that is in -tip now?  Easier to test, then!

Thank you, the patch looks good at first glance, but will beat it up
a bit.

Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tree.c
> index e5164deb51e1,5663d1e899d3..
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@@ -3812,54 -3809,34 +3809,80 @@@ int rcutree_prepare_cpu(unsigned int cp
>   
>   for_each_rcu_flavor(rsp)
>   rcu_init_percpu_data(cpu, rsp);
>  +
>  +rcu_prepare_kthreads(cpu);
>  +rcu_spawn_all_nocb_kthreads(cpu);
>  +
>  +return 0;
>  +}
>  +
>  +static void rcutree_affinity_setting(unsigned int cpu, int outgoing)
>  +{
>  +struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
>  +
>  +rcu_boost_kthread_setaffinity(rdp->mynode, outgoing);
>  +}
>  +
>  +int rcutree_online_cpu(unsigned int cpu)
>  +{
>  +sync_sched_exp_online_cleanup(cpu);
>  +rcutree_affinity_setting(cpu, -1);
>  +return 0;
>  +}
>  +
>  +int rcutree_offline_cpu(unsigned int cpu)
>  +{
>  +rcutree_affinity_setting(cpu, cpu);
>  +return 0;
>  +}
>  +
>  +
>  +int rcutree_dying_cpu(unsigned int cpu)
>  +{
>  +struct rcu_state *rsp;
>  +
>  +for_each_rcu_flavor(rsp)
>  +rcu_cleanup_dying_cpu(rsp);
>  +return 0;
>  +}
>  +
>  +int rcutree_dead_cpu(unsigned int cpu)
>  +{
>  +struct rcu_state *rsp;
>  +
>  +for_each_rcu_flavor(rsp) {
>  +rcu_cleanup_dead_cpu(cpu, rsp);
>  +do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu));
>  +}
>  +return 0;
>   }
>   
> + /*
> +  * Mark the specified CPU as being online so that subsequent grace periods
> +  * (both expedited and normal) will wait on it.  Note that this means that
> +  * incoming CPUs are not allowed to use RCU read-side critical sections
> +  * until this function is called.  Failing to observe this restriction
> +  * will result in lockdep splats.
> +  */
> + void rcu_cpu_starting(unsigned int cpu)
> + {
> + unsigned long flags;
> + unsigned long mask;
> + struct rcu_data *rdp;
> + struct rcu_node *rnp;
> + struct rcu_state *rsp;
> + 
> + for_each_rcu_flavor(rsp) {
> + rdp = this_cpu_ptr(rsp->rda);
> + rnp = rdp->mynode;
> + mask = rdp->grpmask;
> + raw_spin_lock_irqsave_rcu_node(rnp, flags);
> + rnp->qsmaskinitnext |= mask;
> + rnp->expmaskinitnext |= mask;
> + raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> + }
> + }
> + 
>   #ifdef CONFIG_HOTPLUG_CPU
>   /*
>* The CPU is exiting the idle loop into the arch_cpu_idle_dead()
> @@@ -4208,9 -4231,12 +4231,11 @@@ void __init rcu_init(void
>* this is called early in boot, before either interrupts
>* or the scheduler are operational.
>*/
>  -cpu_notifier(rcu_cpu_notify, 0);
>   pm_notifier(rcu_pm_notify, 0);
> - for_each_online_cpu(cpu)
> + for_each_online_cpu(cpu) {
>  -rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
>  +rcutree_prepare_cpu(cpu);
> + rcu_cpu_starting(cpu);
> + }
>   }
>   
>   #include "tree_exp.h"
> 

Re: [PATCH net-next v3 03/12] net: dsa: mv88e6xxx: extract device mapping

[Andrew Lunn]

On Mon, Jul 18, 2016 at 08:45:31PM -0400, Vivien Didelot wrote:
> The Device Mapping register is an indirect table access.
> 
> Provide helpers to access this table and explicit the checking of the
> new DSA_RTABLE_NONE routing table value.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH] [media] gspca: finepix: Remove deprecated create_singlethread_workqueue

[Frank Zago]

On 07/16/2016 03:55 AM, Bhaktipriya Shridhar wrote:
> The workqueue "work_thread" is involved in streaming the camera data.
> It has a single work item(&dev->work_struct) and hence doesn't require
> ordering. Also, it is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> System workqueues have been able to handle high level of concurrency
> for a long time now and hence it's not required to have a singlethreaded
> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
> created with create_singlethread_workqueue(), system_wq allows multiple
> work items to overlap executions even on the same CPU; however, a
> per-cpu workqueue doesn't have any CPU locality or global ordering
> guarantee unless the target CPU is explicitly specified and thus the
> increase of local concurrency shouldn't make any difference.
> 
> Work item has been flushed in sd_stop0() to ensure that there are no
> pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Frank Zago 

Thanks for the patch.