Re: x86/PCI: Scan all functions during probing

[Jan Kiszka]

On 2016-08-24 04:39, Thomas Gleixner wrote:
> On Thu, 18 Aug 2016, Bjorn Helgaas wrote:
>> I looked up the spec: PCI (not PCIe) r3.0, sec 3.2.2.3.4, says:
>>
>>   A single-function device may optionally respond to all function
>>   numbers as the same function or may ... respond only to function 0
>>   and not respond to the other function numbers.
>>
>> I'm concerned that a single-function device that responds to all
>> function numbers might break with this patch.
>>
>>   [multi-function devices] are also required to always implement
>>   function 0 in the device.
>>
>> Here's the reason we can advance by 8 in the "Go find them" loop.
>>
>>   If a single function device is detected (i.e., bit 7 in the Header
>>   Type register of function 0 is 0), no more functions for that Device
>>   Number will be checked.  If a multi-function device is detected
>>   (i.e., bit 7 in the Header Type register of function 0 is 1), then
>>   all remaining Function Numbers will be checked.
>>
>> This patch does the opposite of what the first sentence recommends.
> 
> Fair enough. We'll need to find a way to deal with that in jailhouse then.

Wouldn't it also be an option to have this fine-grained scanning only
activated if we detect to run over Jailhouse (which we have to anyway)?
Such code hasn't been proposed for upstream yet, but we will eventually.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] zd1211rw: fix spelling mistake "firmeware" -> "firmware"

[Julian Calaby]

Hi All,

On Tue, Aug 23, 2016 at 4:35 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in dev_err message.
>
> Signed-off-by: Colin Ian King 

Looks right to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[PATCH v2 1/3] tracing: Deference pointers without RCU checks

[Binoy Jayan]

From: Daniel Wagner 

The tracepoint can't be used in code section where we are in the
middle of a state transition.

For example if we place a tracepoint inside start/stop_critical_section(),
lockdep complains with

[0.035589] WARNING: CPU: 0 PID: 3 at kernel/locking/lockdep.c:3560 \
check_flags.part.36+0x1bc/0x210() [0.036000] \
DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [0.036000] Kernel panic - 
not \
syncing: panic_on_warn set ... [0.036000]
[0.036000] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.0.0-rc7+ #460
[0.036000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS \
1.7.5-20140709_153950- 04/01/2014 [0.036000]  81f2463a 
88007c93bb98 \
81afb317 0001 [0.036000]  81f212b3 
88007c93bc18 \
81af7bc2 88007c93bbb8 [0.036000]  0008 
88007c93bc28 \
88007c93bbc8 0093bbd8 [0.036000] Call Trace:
[0.036000]  [] dump_stack+0x4f/0x7b
[0.036000]  [] panic+0xc0/0x1e9
[0.036000]  [] ? _raw_spin_unlock_irqrestore+0x38/0x80
[0.036000]  [] warn_slowpath_common+0xc0/0xc0
[0.036000]  [] ? __local_bh_enable+0x36/0x70
[0.036000]  [] warn_slowpath_fmt+0x46/0x50
[0.036000]  [] check_flags.part.36+0x1bc/0x210
[0.036000]  [] lock_is_held+0x78/0x90
[0.036000]  [] ? __local_bh_enable+0x36/0x70
[0.036000]  [] ? __do_softirq+0x3db/0x500
[0.036000]  [] trace_preempt_on+0x255/0x260
[0.036000]  [] preempt_count_sub+0xab/0xf0
[0.036000]  [] __local_bh_enable+0x36/0x70
[0.036000]  [] __do_softirq+0x3db/0x500
[0.036000]  [] run_ksoftirqd+0x1f/0x60
[0.036000]  [] smpboot_thread_fn+0x193/0x2a0
[0.036000]  [] ? SyS_setgroups+0x150/0x150
[0.036000]  [] kthread+0xf2/0x110
[0.036000]  [] ? wait_for_completion+0xc3/0x120
[0.036000]  [] ? preempt_count_sub+0xab/0xf0
[0.036000]  [] ? kthread_create_on_node+0x240/0x240
[0.036000]  [] ret_from_fork+0x58/0x90
[0.036000]  [] ? kthread_create_on_node+0x240/0x240
[0.036000] ---[ end Kernel panic - not syncing: panic_on_warn set ...

PeterZ was so kind to explain it to me what is happening:

"__local_bh_enable() tests if this is the last SOFTIRQ_OFFSET, if so it
tells lockdep softirqs are enabled with trace_softirqs_on() after that
we go an actually modify the preempt_count with preempt_count_sub().
Then in preempt_count_sub() you call into trace_preempt_on() if this
was the last preempt_count increment but you do that _before_ you
actually change the preempt_count with __preempt_count_sub() at this
point lockdep and preempt_count think the world differs and *boom*"

So the simplest way to avoid this is by disabling the consistency
checks.

We also need to take care of the iterating in trace_events_trigger.c
to avoid a splatter in conjunction with the hist trigger.

Signed-off-by: Daniel Wagner 
---
 include/linux/rculist.h | 36 
 include/linux/tracepoint.h  |  4 ++--
 kernel/trace/trace_events_trigger.c |  6 +++---
 3 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 8beb98d..bee836b 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -279,6 +279,24 @@ static inline void list_splice_tail_init_rcu(struct 
list_head *list,
container_of(lockless_dereference(ptr), type, member)
 
 /**
+ * list_entry_rcu_notrace - get the struct for this entry (for tracing)
+ * @ptr:the &struct list_head pointer.
+ * @type:   the type of the struct this is embedded in.
+ * @member: the name of the list_head within the struct.
+ *
+ * This primitive may safely run concurrently with the _rcu list-mutation
+ * primitives such as list_add_rcu() as long as it's guarded by 
rcu_read_lock().
+ *
+ * This is the same as list_entry_rcu() except that it does
+ * not do any RCU debugging or tracing.
+ */
+#define list_entry_rcu_notrace(ptr, type, member) \
+({ \
+   typeof(*ptr) __rcu *__ptr = (typeof(*ptr) __rcu __force *)ptr; \
+   container_of((typeof(ptr))rcu_dereference_raw_notrace(__ptr), type, 
member); \
+})
+
+/**
  * Where are list_empty_rcu() and list_first_entry_rcu()?
  *
  * Implementing those functions following their counterparts list_empty() and
@@ -391,6 +409,24 @@ static inline void list_splice_tail_init_rcu(struct 
list_head *list,
 pos = list_entry_lockless(pos->member.next, typeof(*pos), member))
 
 /**
+ * list_for_each_entry_rcu_notrace -   iterate over rcu list of given 
type (for tracing)
+ * @pos:   the type * to use as a loop cursor.
+ * @head:  the head for your list.
+ * @member:the name of the list_head within the struct.
+ *
+ * This list-traversal primitive may safely run concurrently with
+ * the _rcu list-mutation primitives such as list_add_rcu()
+ * as long as the traversal is guarded by rcu_read_lock().
+ *
+ * This is the same as list_for_each_entry_rcu() exce

[PATCH v2 2/3] tracing: Add trace_irqsoff tracepoints

[Binoy Jayan]

This work is based on work by Daniel Wagner. A few tracepoints are added
at the end of the critical section. With the hist trigger in place, the
hist trigger plots may be generated, with per-cpu breakdown of events
captured. It is based on linux kernel's event infrastructure.

The following filter(s) may be used

'hist:key=latency.log2:val=hitcount:sort=latency'
'hist:key=cpu,latency:val=hitcount:sort=latency if cpu==1'
'hist:key=common_pid.execname'

This captures only the latencies introduced by disabled irqs and
preemption. Additional per process data has to be captured to calculate
the effective latencies introduced for individual processes.

Initial work - latency.patch

[1] 
https://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v3.14-rt-rebase&id=56d50cc34943bbba12b8c5942ee1ae3b29f73acb

Signed-off-by: Binoy Jayan 
---
 include/trace/events/latency.h | 43 ++
 kernel/trace/trace_irqsoff.c   | 42 -
 2 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 include/trace/events/latency.h

diff --git a/include/trace/events/latency.h b/include/trace/events/latency.h
new file mode 100644
index 000..77896c7
--- /dev/null
+++ b/include/trace/events/latency.h
@@ -0,0 +1,43 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM latency
+
+#if !defined(_TRACE_HIST_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_HIST_H
+
+#include 
+
+DECLARE_EVENT_CLASS(latency_template,
+   TP_PROTO(int cpu, cycles_t latency),
+
+   TP_ARGS(cpu, latency),
+
+   TP_STRUCT__entry(
+   __field(int,cpu)
+   __field(cycles_t,   latency)
+   ),
+
+   TP_fast_assign(
+   __entry->cpu= cpu;
+   __entry->latency= latency;
+   ),
+
+   TP_printk("cpu=%d, latency=%lu", __entry->cpu,
+   (unsigned long) __entry->latency)
+);
+
+DEFINE_EVENT(latency_template, latency_irqs,
+   TP_PROTO(int cpu, cycles_t latency),
+   TP_ARGS(cpu, latency));
+
+DEFINE_EVENT(latency_template, latency_preempt,
+   TP_PROTO(int cpu, cycles_t latency),
+   TP_ARGS(cpu, latency));
+
+DEFINE_EVENT(latency_template, latency_critical_timings,
+   TP_PROTO(int cpu, cycles_t latency),
+   TP_ARGS(cpu, latency));
+
+#endif /* _TRACE_HIST_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 03cdff8..3fcf446 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -13,14 +13,22 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include "trace.h"
 
+#define CREATE_TRACE_POINTS
+#include 
+
 static struct trace_array  *irqsoff_trace __read_mostly;
 static int tracer_enabled __read_mostly;
 
 static DEFINE_PER_CPU(int, tracing_cpu);
-
+static DEFINE_PER_CPU(cycle_t __maybe_unused, ts_irqs);
+static DEFINE_PER_CPU(cycle_t __maybe_unused, ts_preempt);
+static DEFINE_PER_CPU(cycle_t __maybe_unused, ts_critical_timings);
 static DEFINE_RAW_SPINLOCK(max_trace_lock);
 
 enum {
@@ -419,9 +427,17 @@ stop_critical_timing(unsigned long ip, unsigned long 
parent_ip)
atomic_dec(&data->disabled);
 }
 
+static inline cycle_t get_delta(cycle_t __percpu *ts)
+{
+   return (cycle_t) trace_clock_local() - this_cpu_read(*ts);
+}
 /* start and stop critical timings used to for stoppage (in idle) */
 void start_critical_timings(void)
 {
+   if (trace_latency_critical_timings_enabled())
+   this_cpu_write(ts_critical_timings,
+   (cycle_t) trace_clock_local());
+
if (preempt_trace() || irq_trace())
start_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
 }
@@ -431,6 +447,13 @@ void stop_critical_timings(void)
 {
if (preempt_trace() || irq_trace())
stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
+
+   if (trace_latency_critical_timings_enabled()) {
+   trace_latency_critical_timings(
+   raw_smp_processor_id(),
+   get_delta(&ts_critical_timings));
+   }
+
 }
 EXPORT_SYMBOL_GPL(stop_critical_timings);
 
@@ -438,6 +461,10 @@ EXPORT_SYMBOL_GPL(stop_critical_timings);
 #ifdef CONFIG_PROVE_LOCKING
 void time_hardirqs_on(unsigned long a0, unsigned long a1)
 {
+   if (trace_latency_irqs_enabled()) {
+   trace_latency_irqs(raw_smp_processor_id(),
+   get_delta(&ts_irqs));
+   }
if (!preempt_trace() && irq_trace())
stop_critical_timing(a0, a1);
 }
@@ -446,6 +473,10 @@ void time_hardirqs_off(unsigned long a0, unsigned long a1)
 {
if (!preempt_trace() && irq_trace())
start_critical_timing(a0, a1);
+
+   if (trace_latency_irqs_enabled()) {
+this_cpu_write(ts_irqs, (cycle_t) trace_clock_local());
+ 

[PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***

[Binoy Jayan]

Hi,

Thank you Steven and Daniel for reviewing v1 and providing suggestions.
These set of patches [v2] capture latency events caused by interrupts and
premption disabled in kernel. The patches are based on the hist trigger
feature developed by Tom Zanussi.

Git-commit: 7ef224d1d0e3a1ade02d02c01ce1dcffb736d2c3

As mentioned by Daniel, there is also a good write up in the following 
blog by Brendan Gregg:
http://www.brendangregg.com/blog/2016-06-08/linux-hist-triggers.html

The perf interface for the same have not been developed yet.
Related efforts: https://patchwork.kernel.org/patch/8439401

hwlat_detector tracer:
https://lkml.org/lkml/2016/8/4/348
https://lkml.org/lkml/2016/8/4/346

The patch series also contains histogram triggers for missed
hrtimer offsets.

Dependencies:
CONFIG_IRQSOFF_TRACER
CONFIG_PREEMPT_TRACER
CONFIG_PROVE_LOCKING
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG

Usage of triggers to generate histograms:

mount -t debugfs nodev /sys/kernel/debug
echo 'hist:key=latency.log2:val=hitcount:sort=latency' > 
/sys/kernel/debug/tracing/events/latency/latency_irqs/trigger
echo 'hist:key=common_pid.execname' > 
/sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/trigger

CPU specific breakdown of events:

echo 'hist:key=cpu,latency:val=hitcount:sort=latency' > 
/sys/kernel/debug/tracing/events/latency/latency_preempt/trigger
echo 'hist:key=cpu,latency:val=hitcount:sort=latency if cpu==1' > 
/sys/kernel/debug/tracing/events/latency/latency_preempt/trigger

Histogram output:
cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist
cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist
cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist
cat /sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/hist

Disable a trigger:
echo '!hist:key=latency.log2' > 
/sys/kernel/debug/tracing/events/latency/latency_irqs/trigger

Changes from v1 as per comments from Steven/Daniel
  - Use single tracepoint for irq/preempt/critical timings by introducing
a trace type field to differentiate trace type in the same tracepoint.
A suspicious RCU usage error was introduced, while using the trigger
command by mentioning the trace type as a key along with cpu.
I couldn't figure out why. Also, this type of arrangement may also 
be substandard performance vice.
  - Using a more accurate fast local clock instead of a global ftrace clock.

TODO:
1. perf interface. Not sure if this is needed
2. Latency histograms - process wakeup latency
  - Suggestion from Daniel to not introduce tracepoints in scheduler's hotpaths
  - Alternative to attach kprobes to functions which falls in critical paths
and find diff of timestamps using event trigger commands.

For example:

echo "p:myprobe1 start_critical_timings" > 
/sys/kernel/debug/tracing/kprobe_events
echo "p:myprobe2 stop_critical_timings" >>  
/sys/kernel/debug/tracing/kprobe_events
cat /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe1/enable
echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe2/enable
cat /sys/kernel/debug/tracing/kprobe_events

And somehow save the timestamps for 'myprobe1' and 'myprobe2' in
'event_hist_trigger()'. This seems not feasible now as the histogram
data is saved as a 'sum' only for the conditions met in the key definition.
This makes it impossible to save timestamps for individual events.

kernel/trace/trace_events_hist.c +840: hist_trigger_elt_update()

Mhiramat and Steve, suggested an alternative to keep this timestamp is
to create a new ftrace map, store the timestamp with context "key" on the
named map upon event start. Then, at the event end trigger the histogram,
pick timestamp from the map by using context "key" and calculate the
difference. Basically this needs is a "map" which can be accessed from both
the events, .i.e that is the "global variable".

Binoy

Binoy Jayan (2):
  tracing: Add trace_irqsoff tracepoints
  tracing: Histogram for missed timer offsets

Daniel Wagner (1):
  tracing: Deference pointers without RCU checks

 include/linux/hrtimer.h |  3 ++
 include/linux/rculist.h | 36 ++
 include/linux/tracepoint.h  |  4 +-
 include/trace/events/latency.h  | 74 +
 kernel/time/hrtimer.c   | 39 +++
 kernel/trace/trace_events_trigger.c |  6 +--
 kernel/trace/trace_irqsoff.c| 42 -
 7 files changed, 198 insertions(+), 6 deletions(-)
 create mode 100644 include/trace/events/latency.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/3] tracing: Histogram for missed timer offsets

[Binoy Jayan]

Latencies of missed timer offsets. Generate a histogram of missed
timer offsets in microseconds. This will be a based along with irq
and preemption latencies to calculate the effective process wakeup
latencies.

The following filter(s) may be used

'hist:key=common_pid.execname'
'hist:key=common_pid.execname,cpu:val=toffset,hitcount'

Signed-off-by: Binoy Jayan 
---
 include/linux/hrtimer.h|  3 +++
 include/trace/events/latency.h | 31 +++
 kernel/time/hrtimer.c  | 39 +++
 3 files changed, 73 insertions(+)

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 5e00f80..e09de14 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -104,6 +104,9 @@ struct hrtimer {
struct hrtimer_clock_base   *base;
u8  state;
u8  is_rel;
+#if defined(CONFIG_PREEMPT_TRACER) || defined(CONFIG_IRQSOFF_TRACER)
+   ktime_t praecox;
+#endif
 #ifdef CONFIG_TIMER_STATS
int start_pid;
void*start_site;
diff --git a/include/trace/events/latency.h b/include/trace/events/latency.h
index 77896c7..24cf009 100644
--- a/include/trace/events/latency.h
+++ b/include/trace/events/latency.h
@@ -37,6 +37,37 @@ DEFINE_EVENT(latency_template, latency_critical_timings,
TP_PROTO(int cpu, cycles_t latency),
TP_ARGS(cpu, latency));
 
+TRACE_EVENT(latency_hrtimer_interrupt,
+
+   TP_PROTO(int cpu, long long toffset, struct task_struct *curr,
+   struct task_struct *task),
+
+   TP_ARGS(cpu, toffset, curr, task),
+
+   TP_STRUCT__entry(
+   __field(int,cpu)
+   __field(long long,  toffset)
+   __array(char,   ccomm,  TASK_COMM_LEN)
+   __field(int,cprio)
+   __array(char,   tcomm,  TASK_COMM_LEN)
+   __field(int,tprio)
+   ),
+
+   TP_fast_assign(
+   __entry->cpu = cpu;
+   __entry->toffset = toffset;
+   memcpy(__entry->ccomm, curr->comm, TASK_COMM_LEN);
+   __entry->cprio  = curr->prio;
+   memcpy(__entry->tcomm, task != NULL ? task->comm : "",
+   task != NULL ? TASK_COMM_LEN : 7);
+   __entry->tprio  = task != NULL ? task->prio : -1;
+   ),
+
+   TP_printk("cpu=%d toffset=%lld curr=%s[%d] thread=%s[%d]",
+   __entry->cpu, __entry->toffset, __entry->ccomm,
+   __entry->cprio, __entry->tcomm, __entry->tprio)
+);
+
 #endif /* _TRACE_HIST_H */
 
 /* This part must be outside protection */
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 9ba7c82..1a96e34 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -53,9 +53,12 @@
 #include 
 
 #include 
+#include 
 
 #include "tick-internal.h"
 
+static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
+
 /*
  * The timer bases:
  *
@@ -960,6 +963,38 @@ static inline ktime_t hrtimer_update_lowres(struct hrtimer 
*timer, ktime_t tim,
return tim;
 }
 
+static inline void trace_latency_mark_ts(struct hrtimer *timer,
+struct hrtimer_clock_base *new_base,
+ktime_t tim)
+{
+#if defined(CONFIG_PREEMPT_TRACER) || defined(CONFIG_IRQSOFF_TRACER)
+   if (trace_latency_hrtimer_interrupt_enabled()) {
+   ktime_t now = new_base->get_time();
+
+   if (ktime_to_ns(tim) < ktime_to_ns(now))
+   timer->praecox = now;
+   else
+   timer->praecox = ktime_set(0, 0);
+   }
+#endif
+}
+
+static inline void trace_missed_hrtimer(struct hrtimer *timer, ktime_t basenow)
+{
+#if defined(CONFIG_PREEMPT_TRACER) || defined(CONFIG_IRQSOFF_TRACER)
+   if (trace_latency_hrtimer_interrupt_enabled())
+   trace_latency_hrtimer_interrupt(raw_smp_processor_id(),
+   ktime_to_ns(ktime_sub(ktime_to_ns(timer->praecox) ?
+   timer->praecox : hrtimer_get_expires(timer),
+   basenow)),
+   current,
+   timer->function == hrtimer_wakeup ?
+   container_of(timer, struct hrtimer_sleeper,
+   timer)->task : NULL);
+#endif
+
+}
+
 /**
  * hrtimer_start_range_ns - (re)start an hrtimer on the current CPU
  * @timer: the timer to be added
@@ -992,6 +1027,8 @@ void hrtimer_start_range_ns(struct hrtimer *timer, ktime_t 
tim,
 
timer_stats_hrtimer_set_start_info(timer);
 
+   trace_latency_mark_ts(timer, new_base, tim);
+
leftmost = enqueue_hrtimer(timer, new_base);
if (!leftmost)
goto unlock;
@@ -1284,6 +1321,8 @@ static void

Applied "ASoC: tas5086: fix typo: "Inavlid" -> "Invalid"" to the asoc tree

[Mark Brown]

The patch

   ASoC: tas5086: fix typo: "Inavlid" -> "Invalid"

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e56375155e95019cd4abc55d30c2c1a415037e27 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Wed, 24 Aug 2016 07:48:06 +0100
Subject: [PATCH] ASoC: tas5086: fix typo: "Inavlid" -> "Invalid"

trivial typo fix in dev_err message

Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tas5086.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c
index d49d25d51957..1666ea697647 100644
--- a/sound/soc/codecs/tas5086.c
+++ b/sound/soc/codecs/tas5086.c
@@ -387,7 +387,7 @@ static int tas5086_hw_params(struct snd_pcm_substream 
*substream,
val = index_in_array(tas5086_ratios, ARRAY_SIZE(tas5086_ratios),
 priv->mclk / priv->rate);
if (val < 0) {
-   dev_err(codec->dev, "Inavlid MCLK / Fs ratio\n");
+   dev_err(codec->dev, "Invalid MCLK / Fs ratio\n");
return -EINVAL;
}
 
-- 
2.8.1

Re: [RFC] rlimit exceed notification events

[Jiri Olsa]

On Fri, Aug 19, 2016 at 05:41:20PM +0300, Yauheni Kaliuta wrote:
> Hi!
> 
> At the moment there is no clear indication if a process exceeds resource
> limit. In some cases the problematic syscall can return a error, in some cases
> the process can be just killed.
> 
> I'm trying to implement some sort of monitoring of such events and have a
> question, what way would be acceptable.

> 
> 1) The straight forward solution would be to instrument every such a place 
> with
> a printk (something related implemented, for example, by
> d977d56ce5b3e8842236f2f9e7483d4914c9592e).
> 
> It has some concerns about reliablity and performance (giving a way to flood
> printk buffer because of bad application, for example).
> 
> 2) Using tracepoints. I've used a simple program, which dup()s until gets the
> error 3 times:

just to start up the discussion.. ;-)

I'd think this one (2) is the proper way, but generaly you need to
come with good justification/usecase to add new tracepoint

also rlimit seems to be difficult to add tracepoints to,
because the checks are spread all over the code.. 

can't think of a good solution ATM

> $ sudo ./perf record -e rlimit:rlimit_exceeded ./a.out
> Couldn't dup file: Too many open files, iteration 1020
> Couldn't dup file: Too many open files, iteration 1021
> Couldn't dup file: Too many open files, iteration 1022
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.010 MB perf.data (3 samples) ]
> 
> $ sudo ./perf report  
> # To display the perf.data header info, please use --header/--header-only 
> options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 3  of event 'rlimit:rlimit_exceeded'
> # Event count (approx.): 3
> #
> # Overhead  Trace output
> #   
> #
>100.00%  RLIMIT NOFILE violation. Current 1024, requested Unknown
> 
> The code to demonstrate the idea below:
> 
> diff --git a/fs/file.c b/fs/file.c
> index 6b1acdfe59da..a358de041ac4 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -947,6 +947,9 @@ SYSCALL_DEFINE1(dup, unsigned int, fildes)
>   else
>   fput(file);
>   }
> + if (ret == -EMFILE)
> + rlimit_exceeded(RLIMIT_NOFILE,
> + rlimit(RLIMIT_NOFILE), (u64)-1);
>   return ret;

how about other places? alloc_fd/get_unused_fd_flags/replace_fd..

jirka

Re: [PATCH V5, 0/5] Add MediaTek USB3 DRD Driver

[Oliver Neukum]

On Wed, 2016-08-24 at 14:42 +0800, chunfeng yun wrote:
> Dear all,
> 
> Could you please help me to review the code? 

Is the structure

struct qmu_gpd

shared with the hardware? Do I read this correctly that
you do PIO to endpoint 0 but DMA to the others?

Could you resend the series?

Regards
Oliver

Re: [PATCH v2 1/1] pwm: sun4i: fix a possible NULL dereference

[LABBE Corentin]

On Mon, Aug 22, 2016 at 08:57:37AM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Aug 16, 2016 at 03:18:06PM +0200, LABBE Corentin wrote:
> > of_match_device could return NULL, and so cause a NULL pointer
> > dereference later.
> > 
> > For fixing this problem, we use of_device_get_match_data(), this will
> > simplify the code a little by using a standard function for
> > getting the match data.
> > 
> > Reported-by: coverity (CID 1324139)
> > Signed-off-by: LABBE Corentin 
> > ---
> >  drivers/pwm/pwm-sun4i.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > index 03a99a5..72f0060 100644
> > --- a/drivers/pwm/pwm-sun4i.c
> > +++ b/drivers/pwm/pwm-sun4i.c
> > @@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
> > struct resource *res;
> > u32 val;
> > int i, ret;
> > -   const struct of_device_id *match;
> > -
> > -   match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
> >  
> > pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
> > if (!pwm)
> > @@ -326,7 +323,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
> > if (IS_ERR(pwm->clk))
> > return PTR_ERR(pwm->clk);
> >  
> > -   pwm->data = match->data;
> > +   pwm->data = of_device_get_match_data(&pdev->dev);
> 
> How does that fix anything?
> 
> If of_match_data fails, it will return NULL, and the NULL pointer
> dereference will occur in the exact same cases.
> 
> You should just check for match to be NULL, and return in this case.
> 
> Maxime
> 

I apologize for havent seen this subsuquent NULL deref.

I send an updated version soon.

Regards

[tip:perf/core] perf top: Use MSEC_PER_SEC

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  b9c4b0f40d22d4b1d29540f5faf6ca4269f25848
Gitweb: http://git.kernel.org/tip/b9c4b0f40d22d4b1d29540f5faf6ca4269f25848
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 8 Aug 2016 15:37:58 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 23 Aug 2016 15:37:33 -0300

perf top: Use MSEC_PER_SEC

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Steven Rostedt 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-iof4j6mutyogdeie1sj98...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 418ed94..a3223aa 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -68,6 +68,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 static volatile int done;
@@ -624,7 +625,7 @@ static void *display_thread(void *arg)
display_setup_sig();
pthread__unblock_sigwinch();
 repeat:
-   delay_msecs = top->delay_secs * 1000;
+   delay_msecs = top->delay_secs * MSEC_PER_SEC;
set_term_quiet_input(&save);
/* trash return*/
getc(stdin);

Re: perf: WARNING: kernel/events/core.c:4893 perf_mmap_close

[Alexander Shishkin]

Will Deacon  writes:

> A little bit of digging suggests that the preempt count isn't balanced
> across the call to perf_pmu_output_stop from perf_mmap_close. Further
> digging revealed the unbalanced get_cpu_ptr in __perf_pmu_output_stop.
> Fix below!

Oh gee, that's embarrassing. Thanks!

> This patch uses this_cpu_ptr instead of get_cpu_ptr, since preemption is
> already disabled by the caller.
>
> Fixes: 95ff4ca26c49 ("perf/core: Free AUX pages in unmap path")
> Cc: Alexander Shishkin 
> Cc: Peter Zijlstra 
> Signed-off-by: Will Deacon 

Reviewed-by: Alexander Shishkin 

Regards,
--
Alex

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Thierry Reding]

On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
> Add documentation for lt070me05000 panel
> 
> Cc: Archit Taneja 
> Cc: John Stultz 
> Cc: Thierry Reding 
> Cc: Sumit Semwal 
> Signed-off-by: Vinay Simha BN 
> Acked-by: Rob Herring 
> 
> ---
> v2:
>  * incorporated rob herring and thierry reviews
>gpio to gpios, gpio to regulator using fixed regulators
>and pwm backlight is removed, since it is controlled by
>dcs commands
> ---
>  .../bindings/display/panel/jdi,lt070me05000.txt| 57 
> ++
>  1 file changed, 57 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> new file mode 100644
> index 000..613b76f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> @@ -0,0 +1,57 @@
> +JDI model LT070ME05000 1200x1920 7" DSI Panel
> +
> +Required properties:
> +- compatible: should be "jdi,lt070me05000"
> +- vddp-supply: phandle of the regulator that provides the supply voltage
> +  Power IC supply (3-5V)
> +- dcdc_en-supply: phandle of the regulator that provides the supply voltage
> +  Power IC supply enable, High active
> +- vcc-supply: phandle of the regulator that provides the supply voltage
> +  IOVCC , power supply for LCM (1.8V)

I was just going to apply this and wanted to add some information about
how many lanes the panel uses, so I looked at the datasheet linked to in
patch 4/4:

http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet

and noticed that the power supplies in the binding here don't match the
ones listed in the datasheet. Granted, the datasheet is somewhat meager,
but it lists the following three input voltages:

- IOVCC at 1.8 V
- VDD at 3.0 V
- VDDP at 3.0 V

This matches in part what the above binding describes, but it's not
quite right, so I'm wondering if the name for dcdc_en-supply came from
the board schematics and reflects the name of the rail on the board
design that provides this rather than the input voltage on the panel.

I think we should follow the names in the panel datasheet so that people
can more easily reference the correct regulators when using this panel
on a different board. I'd suggest:

- iovcc-supply: phandle of the regulator that supplies power to
  the IOVCC voltage input (1.8 V)
- vdd-supply: phandle of the regulator that supplies power to
  the VDD voltage input (3.0 V)
- vddp-supply: phandle of the regulator that supplies power to
  the VDDP voltage input (3.0 V)

Any objections?

Thierry


signature.asc
Description: PGP signature

[tip:perf/core] perf tools: Fix typo: "ehough" -> "enough"

[tip-bot for Colin Ian King]

Commit-ID:  dd6fa4e197f0123bcd751e47c171121b2451f148
Gitweb: http://git.kernel.org/tip/dd6fa4e197f0123bcd751e47c171121b2451f148
Author: Colin Ian King 
AuthorDate: Sun, 21 Aug 2016 15:12:56 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 23 Aug 2016 17:06:38 -0300

perf tools: Fix typo: "ehough" -> "enough"

Trivial typo fix in pr_debug message

Signed-off-by: Colin King 
Cc: Alexander Shishkin 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20160821141256.7530-1-colin.k...@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/backward-ring-buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/backward-ring-buffer.c 
b/tools/perf/tests/backward-ring-buffer.c
index 615780c..e6d1816 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -97,7 +97,7 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
 
evlist = perf_evlist__new();
if (!evlist) {
-   pr_debug("No ehough memory to create evlist\n");
+   pr_debug("No enough memory to create evlist\n");
return TEST_FAIL;
}
 

Re: [RESEND] [PATCH v3 3/4] drm/dsi: Implement dcs set/get display brightness

[Thierry Reding]

On Sun, Jul 31, 2016 at 08:45:22PM +0530, Vinay Simha BN wrote:
> Provide a small convenience wrapper that set/get the
> display brightness value
> 
> Cc: John Stultz 
> Cc: Sumit Semwal 
> Cc: Archit Taneja 
> Cc: Rob Clark 
> Cc: Jani Nikula 
> Cc: Thierry Reding 
> Cc: Emil Velikov 
> Signed-off-by: Vinay Simha BN 
> Reviewed-by: Emil Velikov 
> 
> ---
> v1:
>  *tested in nexus7 2nd gen.
> 
> v2:
>  * implemented jani review comments
>-functions name mapped accordingly
>-bl value increased from 0xff to 0x
>-backlight interface will be handled in panel driver,
> so it is moved from the mipi_dsi helper function
> 
> v3:
>  * emil review comments
>(err < 0) supposed to be (err <= 0)
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 49 
> ++
>  include/drm/drm_mipi_dsi.h |  4 
>  2 files changed, 53 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

[Xunlei Pang]

On 2016/08/24 at 16:20, Dave Young wrote:
> On 08/23/16 at 06:11pm, Yinghai Lu wrote:
>> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young  wrote:
>>> On 08/17/16 at 09:50am, Xunlei Pang wrote:
 "/sys/kernel/kexec_crash_size" only handles crashk_res, it
 is fine in most cases, but sometimes we have crashk_low_res.
 For example, when "crashkernel=size[KMG],high" combined with
 "crashkernel=size[KMG],low" is used for 64-bit x86.

 Like crashk_res, we introduce the corresponding sysfs file
 "/sys/kernel/kexec_crash_low_size" for crashk_low_res.

 So, the exact total reserved memory is the sum of the two.

 crashk_low_res can also be shrunk via this new interface,
 and users should be aware of what they are doing.
>> ...
 @@ -218,6 +238,7 @@ static struct attribute * kernel_attrs[] = {
  #ifdef CONFIG_KEXEC_CORE
   &kexec_loaded_attr.attr,
   &kexec_crash_loaded_attr.attr,
 + &kexec_crash_low_size_attr.attr,
   &kexec_crash_size_attr.attr,
   &vmcoreinfo_attr.attr,
  #endif
>> would be better if you can use attribute_group .is_visible to control 
>> showing of
>> crash_low_size only when the crash_base is above 4G.
> I have same feeling that it looks odd to show low in sysfs in case no
> crashkernel=,high being used. Even if crashkernel=,high is used only in
> x86 the resource crashk_low is in common code. What do you think to move
> it to x86?

If want to put some restriction on it, I'd prefer to move crashk_low to arch 
x86, to make
it x86-specific.

We can show the interface unconditionally. If it isn't used, its size is 0, it 
doesn't matter.

Regards,
Xunlei

>
> Thanks
> Dave
>
>> Thanks
>>
>> Yinghai
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

[Matthias Brugger]

On 24/08/16 13:02, Rafał Miłecki wrote:

On 24 August 2016 at 12:49, Matthias Brugger  wrote:

On 24/08/16 00:03, Rafał Miłecki wrote:


[...]


+static int usbport_trig_notify(struct notifier_block *nb, unsigned long
action,
+  void *data)
+{
+   struct usbport_trig_data *usbport_data =
+   container_of(nb, struct usbport_trig_data, nb);
+   struct led_classdev *led_cdev = usbport_data->led_cdev;
+
+   switch (action) {
+   case USB_DEVICE_ADD:
+   if (usbport_trig_usb_dev_observed(usbport_data, data)) {



Maybe we should switch this and fist see if the usbport is observed before
evaluating the action. Also cast data to "struct usb_device *" to make that
clear.


I'm aware there is one duplicated line of code, I did to first
evaluate very quick test (checking unsigned long value), then iterate
over ports & keep only 1 switch block. I could move
usbport_trig_usb_dev_observed call up, but it would be executed for
other actions as well (currently just USB_BUS_ADD and USB_BUS_REMOVE).



Ok. I'm a USB noop but from my understanding the notifier is only called 
when a device or a hub gets added/removed. So this shouldn't happen that 
much. Therefor it has no impact if we check if the usb device is in the 
observer list for all actions.





+   if (usbport_data->count++ == 0)



I'm a bit puzzled. I think:
if (++usbport_data->count > 0)
makes this more consistent with the remove case.


Your condition would be always true (as we don't use negative
numbers). The point is to enable LED only if it was disabled before.
So I need to increase counter unconditionally but enable LED only if
initial value (before increasing it) was 0.



Got it. My personal opinion is, that adding one line for 
incrementing/decrementing the counter would help to make this 
crystal-clear to everyone (at least to me :)


Cheers,
Matthias




+module_init(usbport_trig_init);
+module_exit(usbport_trig_exit);
+
+MODULE_AUTHOR("Rafał Miłecki ");



Nit: ra...@milecki.pl


Oops, thanks!

Re: include/linux/io-mapping.h:130:39: error: implicit declaration of function 'ioremap_wc'

[Linus Walleij]

On Tue, Aug 23, 2016 at 10:03 PM, Chris Wilson  wrote:
> On Tue, Aug 16, 2016 at 10:14:57AM +0200, Linus Walleij wrote:
>> On Mon, Aug 15, 2016 at 5:08 PM, kbuild test robot

>> I think I've finally fixed this now by making OF_GPIO depend on !NO_IOMEM.
>
> I've stumbled over this patch

(...)
> Fix this by including  explicitly.
>
> having touched io-mapping.h
>
> The original patch is incorrect as io-mapping.h is not the right header
> for iounmap() - that is #include  (pulling in )
> which is (and was) already present.

You're right, I'll revert this patch.

> So the root cause here is arch/um not supplying enough stubs?

arch/um is explicitly not supporting IOMEM so anyone code
using iomap()/iounmap() have to make sure they do not get
compiled on UM.

> But in the
> meantime, do you mind removing the incorrect include now that you have a
> w/a to keep 0day quiet? :)

OK

Yours,
Linus Walleij

[PATCH v2] mm: memcontrol: avoid unused function warning

[Arnd Bergmann]

A bugfix in v4.8-rc2 introduced a harmless warning when CONFIG_MEMCG_SWAP
is disabled but CONFIG_MEMCG is enabled:

mm/memcontrol.c:4085:27: error: 'mem_cgroup_id_get_online' defined but not used 
[-Werror=unused-function]
 static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)

This moves the function inside of the #ifdef block that hides the
calling function, to avoid the warning.

Signed-off-by: Arnd Bergmann 
Fixes: 1f47b61fb407 ("mm: memcontrol: fix swap counter leak on swapout from 
offline cgroup")
Acked-by: Michal Hocko 
Acked-by: Vladimir Davydov 
---
 mm/memcontrol.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

This is the alternative to the original patch, as suggested by Michal Hocko.
Andrew, please pick whichever version you like better.

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2ff0289ad061..9a6a51a7c416 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4082,24 +4082,6 @@ static void mem_cgroup_id_get_many(struct mem_cgroup 
*memcg, unsigned int n)
atomic_add(n, &memcg->id.ref);
 }
 
-static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
-{
-   while (!atomic_inc_not_zero(&memcg->id.ref)) {
-   /*
-* The root cgroup cannot be destroyed, so it's refcount must
-* always be >= 1.
-*/
-   if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
-   VM_BUG_ON(1);
-   break;
-   }
-   memcg = parent_mem_cgroup(memcg);
-   if (!memcg)
-   memcg = root_mem_cgroup;
-   }
-   return memcg;
-}
-
 static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
 {
if (atomic_sub_and_test(n, &memcg->id.ref)) {
@@ -5821,6 +5803,24 @@ static int __init mem_cgroup_init(void)
 subsys_initcall(mem_cgroup_init);
 
 #ifdef CONFIG_MEMCG_SWAP
+static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
+{
+   while (!atomic_inc_not_zero(&memcg->id.ref)) {
+   /*
+* The root cgroup cannot be destroyed, so it's refcount must
+* always be >= 1.
+*/
+   if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
+   VM_BUG_ON(1);
+   break;
+   }
+   memcg = parent_mem_cgroup(memcg);
+   if (!memcg)
+   memcg = root_mem_cgroup;
+   }
+   return memcg;
+}
+
 /**
  * mem_cgroup_swapout - transfer a memsw charge to swap
  * @page: page whose memsw charge to transfer
-- 
2.9.0

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Jakub Narębski]

W dniu 11.08.2016 o 00:07, Josh Triplett pisze:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum
>  wrote:
>> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
[...]

>>> If you use a format-patch diff that includes the headers and
>>> commit message, you could also support commenting on those in the
>>> same way. Does the notedb format support commenting on those?
>> 
>> Comments in notedb are just a git note keyed on the sha of the 
>> commit being commented on, I'm not certain what advantage a 
>> format-patch diff provides in this case?
> 
> I meant for opening in an editor to write email-reply-style comments.
> The review tool and review storage format should allow commenting on
> commit messages, not just diffs.

There is also cover letter and interdiff, and one would want to
be able to comment also on those.

So how notedb solve problem of in-diff comments, in-commit comments,
post-commit comments, whole series cover letter and cover-letter
comments, interdiff and interdiff message / comments?


Nb. GitHub Pull Requests include only some of those, compared to
the mailing list / Usenet news interface.
 
>> I've been closely following the 'patch submission process' thread, 
>> and given the discussion there I'm having doubts over the value of
>> comments in git-candidate vs the mailing list. It seems to me that 
>> git-candidate has many of the disadvantages of Github/Gitlab when
>> it comes to comments, for example, there is no threading.
> 
> That's not inherent, though. You could allow commenting on a comment
> easily enough. (Of course, at some point you've recreated email-style
> in-reply-to headers...)

I wonder if we could use 'parent' header of a commit message for this,
or equivalent...
 
>> Also the system would be less open than the mailing list, since, as
>> it stands currently you would require push access to the
>> repository to comment on anything.
> 
> You'd need a federation mechanism.

...which is as easy to set up and use as mailing list, for sending
patches, applying patches, and patch review.  And/or provide 
bi-directional interface to the mailing list (I think Debian 
infrastructure tries to be (inter)operable by email).

There are various federated technologies (like pump.io), the
problem might be their popularity.

>> It may be worth reflecting that one reason some organizations have
>> switched away from mailing list reviews to Github/Gitlab is that 
>> they provide patch tracking, where the mailing list provides none, 
>> so patches there can be 'lost'. So instead of trying to
>> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I
>> wonder whether it would be sufficient to add the minimum
>> functionality necessary to provide git with native patch tracking,
>> and leave comments for the mailing list. Of course this is exactly
>> what git-series seems to do, so in some sense I may be advocating
>> dropping my own work in favour of improving git-series.
> 
> I think the two serve different (though related) functions. I'd love
> to be able to use a text editor and command-line tool to produce and
> submit comments to systems like Gerrit or GitHub.

I think there are command-line tools that allow to submit comments
to GitHub.

-- 
Jakub Narębski

Re: [PATCH] gpio: Remove superfluous include of io-mapping.h

[Linus Walleij]

On Tue, Aug 23, 2016 at 10:32 PM, Chris Wilson  wrote:

> The io-mapping.h include arose from the need to workaround an arch/um
> compile failure:
>
>drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_probe':
>>> drivers/gpio/gpio-mpc8xxx.c:373:2: error: implicit declaration of
>>> function 'iounmap' [-Werror=implicit-function-declaration]
>  iounmap(mpc8xxx_gc->regs);
>  ^~~
>
> from commit 296ad4acb8ef ("gpio: remove deps on
> ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") but io-mapping.h doesn't provide
> iounmap so the problem persisted and eventually (will be) silenced by
> making OF_GPIO depend on !NO_IOMEM (i.e. disabling building under
> arch/um). My desire to remove the unneed include to io-mapping is to
> simplify verification of changes to io-mapping.h
>
> Signed-off-by: Chris Wilson 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: linux-g...@vger.kernel.org

I chose to to a proper revert instead, but I have added your for
Reported-by:

Thanks a lot.

Yours,
Linus Walleij

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Thierry Reding]

On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
[...]
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
[...]
> +- reset-gpios: phandle of gpio for reset line
> +  This should be 8mA, gpio can be configured using mux, pinctrl, 
> pinctrl-names
> +  XRES, Reset, Low active
> +- enable-gpios: phandle of gpio for enable line
> +  LED_EN, LED backlight enable, High active

This is a little confusing. Shouldn't we rather completely omit any
mention of the polarity of these and let the board design handle this?

If the reset is low active, then I'd expect that to be reflected in the
GPIO specifier of the reset-gpios property, like so:

panel@0 {
...
reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>;
...
};

With that a driver can simply deal with a high active reset, which it
currently doesn't. The problem with the current description is that it
is unclear who's to deal with the polarity. In order for this to work
properly with the current driver you'll have to specify the GPIO as
GPIO_ACTIVE_HIGH, which is not what the binding says it should be.

Thierry


signature.asc
Description: PGP signature

[patch 2/2] i2c: mux: mellanox: add driver

[vadimp]

From: Vadim Pasternak 

This driver allows I2C routing controlled through CPLD select registers on wide
range of Mellanox systems (CPLD Lattice device).
MUX selection is provided by digital and analog HW. Analog part is not under SW
control. Digital part is under CPLD control (channel selection/de-selection).

MUX logic description.
Mux selector can control 256 mux (channels), if utilized one CPLD register
(8 bits) as select register - register value specifies mux id.
Mux selector can control n*256 mux, if utilized n CPLD registers as select
registers.
The number of registers within the same CPLD can be combined to support mux
hierarchy.
This logic can be applied for LPC attached CPLD and fro I2C attached CPLD.
Driver can support different mux control logic, according to CPLD
implementation.

Connectivity schema.
i2c-mlxcpld Digital   Analog
driver
** * -> mux1 (virt bus2) -> mux -> |
| I2CLPC | i2c physical* -> mux2 (virt bus3) -> mux -> |
| bridge | bus 1 *-*   |
| logic  |-> * mux reg *   |
| in CPLD|   *-*   |
**   i2c-mux-mlxpcld  ^* -> muxn (virt busn) -> mux -> |
|driver   ||
|*---*|  Devices
|* CPLD (LPC bus)* select |
|* registers for **
|* mux selection * deselect
|*---*
| |
<> <--->
i2c cntrl  Board cntrl reg
reg space  space (mux select,
|  IO, LED, WD, info)
| |  *-*   *-*
*- LPC bus --| PCH |---| CPU |
 *-*   *-*

i2c-mux-mlxpcld does not necessary required i2c-mlxcpld. It can be use along
with another bus driver, and still control i2c routing through CPLD mux
selection, in case the system is equipped with CPLD capable of mux selection
control.

The Kconfig currently controlling compilation of this code is:
drivers/i2c/muxes/Kconfig:config I2C_MUX_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
---
 drivers/i2c/muxes/Kconfig   |  11 ++
 drivers/i2c/muxes/Makefile  |   1 +
 drivers/i2c/muxes/i2c-mux-mlxcpld.c | 352 
 include/linux/i2c/mlxcpld.h |  67 +++
 4 files changed, 431 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-mux-mlxcpld.c
 create mode 100644 include/linux/i2c/mlxcpld.h

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index e280c8e..b7ab144 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -81,4 +81,15 @@ config I2C_DEMUX_PINCTRL
  demultiplexer that uses the pinctrl subsystem. This is useful if you
  want to change the I2C master at run-time depending on features.
 
+config I2C_MUX_MLXCPLD
+tristate "Mellanox CPLD based I2C multiplexer"
+help
+  If you say yes to this option, support will be included for a
+  CPLD based I2C multiplexer. This driver provides access to
+  I2C busses connected through a MUX, which is controlled
+  by a CPLD registers.
+
+  This driver can also be built as a module.  If so, the module
+  will be called i2c-mux-mlxcpld.
+
 endmenu
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 7c267c2..e5c990e 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
 obj-$(CONFIG_I2C_MUX_PINCTRL)  += i2c-mux-pinctrl.o
 obj-$(CONFIG_I2C_MUX_REG)  += i2c-mux-reg.o
+obj-$(CONFIG_I2C_MUX_MLXCPLD)  += i2c-mux-mlxcpld.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/muxes/i2c-mux-mlxcpld.c 
b/drivers/i2c/muxes/i2c-mux-mlxcpld.c
new file mode 100644
index 000..ae860de
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-mlxcpld.c
@@ -0,0 +1,352 @@
+/*
+ * drivers/i2c/muxes/i2c-mux-mlxcpld.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Michael Shych 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. 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.
+ *

[patch 1/2] i2c: add master driver for mellanox systems

[vadimp]

From: Vadim Pasternak 

Device driver for Mellanox I2C controller logic, implemented in Lattice CPLD 
device.
Device supports:
 - Master mode
 - One physical bus
-  Polling mode

The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
---
 drivers/i2c/busses/Kconfig   |  12 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-mlxcpld.c | 609 +++
 3 files changed, 622 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-mlxcpld.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5c3993b..1126142a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1203,4 +1203,16 @@ config I2C_OPAL
  This driver can also be built as a module. If so, the module will be
  called as i2c-opal.
 
+config I2C_MLXCPLD
+tristate "Mellanox I2C driver"
+depends on X86_64
+default y
+help
+ This exposes the Mellanox platform I2C busses to the linux I2C layer
+ for X86 based systems.
+ Controller is implemented as CPLD logic.
+
+ This driver can also be built as a module. If so, the module will be
+ called as i2c-mlxcpld.
+
 endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 37f2819..4df3578 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -118,5 +118,6 @@ obj-$(CONFIG_I2C_PCA_ISA)   += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
 obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
+obj-$(CONFIG_I2C_MLXCPLD)  += i2c-mlxcpld.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-mlxcpld.c b/drivers/i2c/busses/i2c-mlxcpld.c
new file mode 100644
index 000..04cd987
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mlxcpld.c
@@ -0,0 +1,609 @@
+/*
+ * drivers/i2c/busses/i2c-mlxcpld.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Michael Shych 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. 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.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* General defines */
+#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
+#define MLXCPLD_I2C_DEVICE_NAME"mlxcpld_i2c"
+#define MLXCPLD_I2C_VALID_FLAG (I2C_M_RECV_LEN | I2C_M_RD)
+#define MLXCPLD_I2C_BUS_NUM1
+#define MLXCPLD_I2C_DATA_REG_SZ36
+#define MLXCPLD_I2C_MAX_ADDR_LEN   4
+#define MLXCPLD_I2C_RETR_NUM   2
+#define MLXCPLD_I2C_XFER_TO50 /* msec */
+#define MLXCPLD_I2C_POLL_TIME  2000   /* msec */
+
+/* LPC I2C registers */
+#define MLXCPLD_LPCI2C_LPF_REG 0x0
+#define MLXCPLD_LPCI2C_CTRL_REG0x1
+#define MLXCPLD_LPCI2C_HALF_CYC_REG0x4
+#define MLXCPLD_LPCI2C_I2C_HOLD_REG0x5
+#define MLXCPLD_LPCI2C_CMD_REG 0x6
+#define MLXCPLD_LPCI2C_NUM_DAT_REG 0x7
+#define MLXCPLD_LPCI2C_NUM_ADDR_REG0x8
+#define MLXCPLD_LPCI2C_STATUS_REG  0x9
+#define MLXCPLD_LPCI2C_DATA_REG0xa
+
+/* LPC I2C masks and parametres */
+#define MLXCPLD_LPCI2C_RST_SEL_MASK0x1
+#d

[PATCH v3] pwm: sun4i: fix a possible NULL dereference

[LABBE Corentin]

of_match_device could return NULL, and so cause a NULL pointer
dereference later.

For fixing this problem, we use of_device_get_match_data(), this will
simplify the code a little by using a standard function for
getting the match data.

Testing the return value of of_device_get_match_data is also necessary
for avoiding a second NULL deref on pwm->data.

Reported-by: coverity (CID 1324139)
Signed-off-by: LABBE Corentin 
---
Changes since v2:
 - Add a test on pwm->data for avoiding a second NULL deref.
Changes since v1:
 - Use of_device_get_match_data()

 drivers/pwm/pwm-sun4i.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 03a99a5..fb76c55 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
struct resource *res;
u32 val;
int i, ret;
-   const struct of_device_id *match;
-
-   match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
 
pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
if (!pwm)
@@ -326,7 +323,9 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm->clk))
return PTR_ERR(pwm->clk);
 
-   pwm->data = match->data;
+   pwm->data = of_device_get_match_data(&pdev->dev);
+   if (!pwm->data)
+   return -EINVAL;
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &sun4i_pwm_ops;
pwm->chip.base = -1;
-- 
2.7.3

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Vinay Simha]

thierry,

this is the reference pinouts of the panel
http://www.tonylabs.com/wp-content/uploads/LT070ME05000-pinouts.jpg

as you suggest , i will change the vcc-supply,

 - iovcc-supply: phandle of the regulator that supplies power to
  the IOVCC voltage input (1.8 V)

will keep the other two(vddp-supply, dcdc_en-supply) remaining same.

On Wed, Aug 24, 2016 at 5:15 PM, Thierry Reding
 wrote:
> On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
>> Add documentation for lt070me05000 panel
>>
>> Cc: Archit Taneja 
>> Cc: John Stultz 
>> Cc: Thierry Reding 
>> Cc: Sumit Semwal 
>> Signed-off-by: Vinay Simha BN 
>> Acked-by: Rob Herring 
>>
>> ---
>> v2:
>>  * incorporated rob herring and thierry reviews
>>gpio to gpios, gpio to regulator using fixed regulators
>>and pwm backlight is removed, since it is controlled by
>>dcs commands
>> ---
>>  .../bindings/display/panel/jdi,lt070me05000.txt| 57 
>> ++
>>  1 file changed, 57 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> new file mode 100644
>> index 000..613b76f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>> @@ -0,0 +1,57 @@
>> +JDI model LT070ME05000 1200x1920 7" DSI Panel
>> +
>> +Required properties:
>> +- compatible: should be "jdi,lt070me05000"
>> +- vddp-supply: phandle of the regulator that provides the supply voltage
>> +  Power IC supply (3-5V)
>> +- dcdc_en-supply: phandle of the regulator that provides the supply voltage
>> +  Power IC supply enable, High active
>> +- vcc-supply: phandle of the regulator that provides the supply voltage
>> +  IOVCC , power supply for LCM (1.8V)
>
> I was just going to apply this and wanted to add some information about
> how many lanes the panel uses, so I looked at the datasheet linked to in
> patch 4/4:
>
> http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
>
> and noticed that the power supplies in the binding here don't match the
> ones listed in the datasheet. Granted, the datasheet is somewhat meager,
> but it lists the following three input voltages:
>
> - IOVCC at 1.8 V
> - VDD at 3.0 V
> - VDDP at 3.0 V
>
> This matches in part what the above binding describes, but it's not
> quite right, so I'm wondering if the name for dcdc_en-supply came from
> the board schematics and reflects the name of the rail on the board
> design that provides this rather than the input voltage on the panel.
>
> I think we should follow the names in the panel datasheet so that people
> can more easily reference the correct regulators when using this panel
> on a different board. I'd suggest:
>
> - iovcc-supply: phandle of the regulator that supplies power to
>   the IOVCC voltage input (1.8 V)
> - vdd-supply: phandle of the regulator that supplies power to
>   the VDD voltage input (3.0 V)
> - vddp-supply: phandle of the regulator that supplies power to
>   the VDDP voltage input (3.0 V)
>
> Any objections?
>
> Thierry



-- 
regards,
vinaysimha

Re: [PATCH] gpio: Remove superfluous include of io-mapping.h

[Chris Wilson]

On Wed, Aug 24, 2016 at 01:55:28PM +0200, Linus Walleij wrote:
> On Tue, Aug 23, 2016 at 10:32 PM, Chris Wilson  
> wrote:
> 
> > The io-mapping.h include arose from the need to workaround an arch/um
> > compile failure:
> >
> >drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_probe':
> >>> drivers/gpio/gpio-mpc8xxx.c:373:2: error: implicit declaration of
> >>> function 'iounmap' [-Werror=implicit-function-declaration]
> >  iounmap(mpc8xxx_gc->regs);
> >  ^~~
> >
> > from commit 296ad4acb8ef ("gpio: remove deps on
> > ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") but io-mapping.h doesn't provide
> > iounmap so the problem persisted and eventually (will be) silenced by
> > making OF_GPIO depend on !NO_IOMEM (i.e. disabling building under
> > arch/um). My desire to remove the unneed include to io-mapping is to
> > simplify verification of changes to io-mapping.h
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Linus Walleij 
> > Cc: Alexandre Courbot 
> > Cc: linux-g...@vger.kernel.org
> 
> I chose to to a proper revert instead, but I have added your for
> Reported-by:

Thanks, this will help me hide from 0day as well :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Replacing specific kmalloc() calls by kmalloc_array()?

[SF Markus Elfring]

> Or kmalloc_array, since zeroing is not necessary.  Might be an idea for
> a new Coccinelle script, like
> 
> - kmalloc (N * sizeof T, GFP)
> + kmalloc_array(N, sizeof T, GFP)

I have picked your idea up. The corresponding script for the semantic
patch language became longer than your general suggestion
(if additional source code control flow aspects are integrated).

Would it make sense to check any more function combinations
in a similar way?

Regards,
Markus

Re: [RFC PATCH v2 0/7] AC97 device/driver model revamp

[Mark Brown]

On Tue, Aug 23, 2016 at 06:39:35PM +0200, Robert Jarzmik wrote:

> In the old ac97 bus, the match function was always returning "true", and the
> driver did probe. With this new implementation, the ac97 is discovered and
> sound/soc/codecs/wm9713.c#wm9713_ac97_probe() is called. I don't export
> ac97_bus_type (nor want to do it), and only _one_ device is created upon
> discovery, while the wm97xx-core.c would benefic a second ac97 device.

> I'm wondering how to work around this :
>  - either I add a wm97xx-ts ac97 device in wm9713_ac97_probe()
>  - or I add a platform device in wm9713_ac97_probe() and add a new
>platform_driver in wm97xx-core ...
>  - or something smarter

That device really should be a MFD.

> What's behind this question is : should I keep to my initial solution of 1 
> ac97
> device discovered is bound on the ac97 to _at most_ 1 ac97 driver, or is 
> there a
> know smart way to have several drivers for one device (that sounds a bit 
> heretic
> regarding my understanding of the device/driver model but who knows ...) ?

MFDs are how we do multiple drivers per device.


signature.asc
Description: PGP signature

Re: [PATCH v2] mm: memcontrol: avoid unused function warning

[Michal Hocko]

On Wed 24-08-16 12:23:00, Arnd Bergmann wrote:
> A bugfix in v4.8-rc2 introduced a harmless warning when CONFIG_MEMCG_SWAP
> is disabled but CONFIG_MEMCG is enabled:
> 
> mm/memcontrol.c:4085:27: error: 'mem_cgroup_id_get_online' defined but not 
> used [-Werror=unused-function]
>  static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> 
> This moves the function inside of the #ifdef block that hides the
> calling function, to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 1f47b61fb407 ("mm: memcontrol: fix swap counter leak on swapout from 
> offline cgroup")
> Acked-by: Michal Hocko 
> Acked-by: Vladimir Davydov 

Thanks a lot for respinning this Arnd!

> ---
>  mm/memcontrol.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> This is the alternative to the original patch, as suggested by Michal Hocko.
> Andrew, please pick whichever version you like better.
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 2ff0289ad061..9a6a51a7c416 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4082,24 +4082,6 @@ static void mem_cgroup_id_get_many(struct mem_cgroup 
> *memcg, unsigned int n)
>   atomic_add(n, &memcg->id.ref);
>  }
>  
> -static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> -{
> - while (!atomic_inc_not_zero(&memcg->id.ref)) {
> - /*
> -  * The root cgroup cannot be destroyed, so it's refcount must
> -  * always be >= 1.
> -  */
> - if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
> - VM_BUG_ON(1);
> - break;
> - }
> - memcg = parent_mem_cgroup(memcg);
> - if (!memcg)
> - memcg = root_mem_cgroup;
> - }
> - return memcg;
> -}
> -
>  static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
>  {
>   if (atomic_sub_and_test(n, &memcg->id.ref)) {
> @@ -5821,6 +5803,24 @@ static int __init mem_cgroup_init(void)
>  subsys_initcall(mem_cgroup_init);
>  
>  #ifdef CONFIG_MEMCG_SWAP
> +static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> +{
> + while (!atomic_inc_not_zero(&memcg->id.ref)) {
> + /*
> +  * The root cgroup cannot be destroyed, so it's refcount must
> +  * always be >= 1.
> +  */
> + if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
> + VM_BUG_ON(1);
> + break;
> + }
> + memcg = parent_mem_cgroup(memcg);
> + if (!memcg)
> + memcg = root_mem_cgroup;
> + }
> + return memcg;
> +}
> +
>  /**
>   * mem_cgroup_swapout - transfer a memsw charge to swap
>   * @page: page whose memsw charge to transfer
> -- 
> 2.9.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 0/5] dts patches for qcom tsens support

[Nayak, Rajendra]

On 8/24/2016 3:52 PM, Paolo Pisati wrote:

On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:

On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:

Hey Andy,

This is a respin of v2 with some minor fixes pointed out by Rob.
Please pull these in for 4.9

Thanks,
Rajendra


I pulled these in.


Did you try to read the content of the qfprom from userspace?


Hi, no I haven't tried it, I can give it a try tomorrow when I
have access to my board and see whats going wrong, but I did
look at Andys for-next and the defconfig still does not have
either nvmem or qcom-qfprom drivers enabled.
Did you manually enable them? or are you seeing this with the drivers 
still disabled?




$ uname -a
Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016 aarch64
aarch64 aarch64 GNU/Linux
$ lsmod
Module  Size  Used by
nvmem_qfprom   16384  0
nvmem_core 24576  1 nvmem_qfprom
$ ls -la /sys/bus/nvmem/devices/
total 0
drwxr-xr-x 2 root root 0 Aug 24 10:17 .
drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
../../../devices/platform/soc/5c000.qfprom/qfprom0
$ cat /sys/bus/nvmem/devices/qfprom0/nvmem

[spontaneous reboot]

This using agross's for-next tree as of today ("54ba896 Merge branch
'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.

Re: [RFC PATCH v1 18/28] crypto: add AMD Platform Security Processor driver

[Tom Lendacky]

On 08/23/2016 02:14 AM, Herbert Xu wrote:
> On Mon, Aug 22, 2016 at 07:27:22PM -0400, Brijesh Singh wrote:
>> The driver to communicate with Secure Encrypted Virtualization (SEV)
>> firmware running within the AMD secure processor providing a secure key
>> management interface for SEV guests.
>>
>> Signed-off-by: Tom Lendacky 
>> Signed-off-by: Brijesh Singh 
> 
> This driver doesn't seem to hook into the Crypto API at all, is
> there any reason why it should be in drivers/crypto?

Yes, this needs to be cleaned up.  The PSP and the CCP share the same
PCI id, so this has to be integrated with the CCP. It could either
be moved into the drivers/crypto/ccp directory or both the psp and
ccp device specific support can be moved somewhere else leaving just
the ccp crypto API related files in drivers/crypto/ccp.

Thanks,
Tom

> 
> Thanks,
> 

Re: [PATCH] dt-bindings: GPIO: Add TPIC2810 binding

[Linus Walleij]

On Tue, Aug 23, 2016 at 1:45 PM, Roger Quadros  wrote:

> From: "Andrew F. Davis" 
>
> Add binding for TPIC2810 GPO device.
>
> Signed-off-by: Andrew F. Davis 
> Signed-off-by: Roger Quadros 

Patch applied.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] UART slave device bus

[Linus Walleij]

On Mon, Aug 22, 2016 at 5:45 PM, One Thousand Gnomes
 wrote:

> and if I look at the usermode crapfest on a lot of Android systems it
> looks similar but with the notion of things like being able to describe
>
> -   Use GPIO mode sleeping and assume first char is X to save power

It's really nasty hardware design, or a software hack to solve
a hardware problem: what should have been done is
of course create a UART with an asynchronous low-power mode
that can recieve a character and wake up the system at any time,
handing over the wakeup character(s) to the driver. That is
obviously the usecase they were designing for.

But yeah, I guess we have to contain hacks like that.

> -   Power up, wait n ms, write, read, wait n ms, power down (which
> has to be driven at the ldisc/user level as only the ldisc
> understands transactions, or via ioctls (right now Android user
> space tends to do hardcoded writes to /sys.. gpio to drive power

This kind of abominational abuse of the GPIO sysfs ABI is
partly why I've obsoleted it. The right abstraction is the
fixed regulator with a GPIO line obviously, then some
sequencing along the lines of what you can find in
drivers/mmc/core/pwrseq*

Unfortunately that sysfs ABI crept in during a window of time
when GPIO was unmaintained and I am trying my best to
contain and improve the situation.

Yours,
Linus Walleij

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Vinay Simha]

if we do not set the polarity to 8mA, panel will have gibberish display.
(information to set 8mA is available only in
nexus7-msm-flo-3.4-lollipop-release_dsi kernel nx7 release)

i will add this
reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>;

On Wed, Aug 24, 2016 at 5:26 PM, Thierry Reding
 wrote:
> On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
> [...]
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> [...]
>> +- reset-gpios: phandle of gpio for reset line
>> +  This should be 8mA, gpio can be configured using mux, pinctrl, 
>> pinctrl-names
>> +  XRES, Reset, Low active
>> +- enable-gpios: phandle of gpio for enable line
>> +  LED_EN, LED backlight enable, High active
>
> This is a little confusing. Shouldn't we rather completely omit any
> mention of the polarity of these and let the board design handle this?
>
> If the reset is low active, then I'd expect that to be reflected in the
> GPIO specifier of the reset-gpios property, like so:
>
> panel@0 {
> ...
> reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>;
> ...
> };
>
> With that a driver can simply deal with a high active reset, which it
> currently doesn't. The problem with the current description is that it
> is unclear who's to deal with the polarity. In order for this to work
> properly with the current driver you'll have to specify the GPIO as
> GPIO_ACTIVE_HIGH, which is not what the binding says it should be.
>
> Thierry



-- 
regards,
vinaysimha

Re: [PATCH v2 1/2] pinctrl: meson-gxbb: add pins for PWM

[Linus Walleij]

On Tue, Aug 23, 2016 at 1:25 PM, Neil Armstrong  wrote:

> Add support for PWM pins, for EE and AO domains.
>
> Signed-off-by: Neil Armstrong 

Patch applied!

Yours,
Linus Walleij

Re: [PATCH 2/2] reset: uniphier: use of_device_get_match_data() to get matched data

[Philipp Zabel]

Hi Masahiro,

Am Mittwoch, den 24.08.2016, 15:40 +0900 schrieb Masahiro Yamada:
> Use of_device_get_match_data() instead of of_match_node().  With
> this, we can retrieve the .data field of the OF match table more
> easily.  No more need to define (or declare) the match table before
> the probe callback.  I prefer to collect boilerplates at the bottom
> of the file, so moved it below.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/reset/reset-uniphier.c | 81 
> +-
>  1 file changed, 40 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 41c62af..9b3f2cd 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -285,6 +286,45 @@ static const struct reset_control_ops uniphier_reset_ops 
> = {
>   .status = uniphier_reset_status,
>  };
>  
> +static int uniphier_reset_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct uniphier_reset_priv *priv;
> + const struct uniphier_reset_data *p, *data;
> + struct regmap *regmap;
> + struct device_node *parent;
> + unsigned int nr_resets = 0;
> +
> + data = of_device_get_match_data(dev);
> + WARN_ON(!data);

I know right now this can't happen anyway, but you did return -EINVAL
here before. Maybe use:

if (WARN_ON(!data))
return -EINVAL;

instead? I can fix it up if you agree.

> + parent = of_get_parent(dev->of_node); /* parent should be syscon node */
> + regmap = syscon_node_to_regmap(parent);
> + of_node_put(parent);
> + if (IS_ERR(regmap)) {
> + dev_err(dev, "failed to get regmap (error %ld)\n",
> + PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + for (p = data; p->id != UNIPHIER_RESET_ID_END; p++)

If in the future somebody forgets to set OF match data, this would be a
NULL pointer dereference.

regards
Philipp

Re: [PATCH 1/2] reset: uniphier: add static qualifier to probe function

[Philipp Zabel]

Am Mittwoch, den 24.08.2016, 15:40 +0900 schrieb Masahiro Yamada:
> I missed this in the initial commit.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/reset/reset-uniphier.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 9de071f..41c62af 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -385,7 +385,7 @@ static const struct of_device_id uniphier_reset_match[] = 
> {
>  };
>  MODULE_DEVICE_TABLE(of, uniphier_reset_match);
>  
> -int uniphier_reset_probe(struct platform_device *pdev)
> +static int uniphier_reset_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   const struct of_device_id *match;

Thanks, I've squashed this into the original commit.

regards
Philipp

Re: [PATCH 1/3] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

[Alexander Shishkin]

Alexander Shishkin  writes:

> The intel_bts driver is using a cpu-local 'started' variable to order
> callbacks and PMIs and make sure that AUX transactions don't get messed
> up. However, the ordering rules in regard to this variable is a complete
> mess, which recently resulted in perf_fuzzer-triggered warnings and
> panics.
>
> The general ordering rule that is patch is enforcing is that this
> cpu-local variable be set only when the cpu-local AUX transaction is
> active; consequently, this variable is to be checked before the AUX
> related bits can be touched.
>
> Signed-off-by: Alexander Shishkin 

Ok, this one is broken, please disregard.

Regards,
--
Alex

Re: Why do we need reset_control_get_optional() ?

[Philipp Zabel]

Am Mittwoch, den 24.08.2016, 15:58 +0900 schrieb Masahiro Yamada:
> Hi Philipp,
> 
> 2016-08-16 23:36 GMT+09:00 Masahiro Yamada :
> > Hi Philipp, Arnd.
> >
> >
> >
> > 2016-08-09 1:39 GMT+09:00 Philipp Zabel :
> >> Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann:
> >>> On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote:
> >>> > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada:
> >>>
> >>> > > > In my experimental patch, I make the _optional functions
> >>> > > > return NULL if no "resets" property is provided but return
> >>> > > > an error if there are reset lines but the subsystem is
> >>> > > > disabled, i.e. an optional reset must be used if it's in the
> >>> > > > DT, but can be ignored otherwise.
> >>> > >
> >>> > > I do not like this idea.
> >>> > >
> >>> > > reset_control_get() (or variants) should not return NULL, it is 
> >>> > > ambiguous.
> >>> > > It should return ERR_PTR(-ENOENT) if no "resets" property.
> >>> > >
> >>> > > I only want two types for functions that return a pointer.
> >>> > >
> >>> > > [1] return a valid pointer on success, or return NULL on failure
> >>> > > (for example, kmalloc())
> >>> > > [2] return a valid pointer on success, or return error pointer on 
> >>> > > failure
> >>> > >(many of _register() functions)
> >>> > >
> >>> > > Mixing [1] and [2] will be a mess.
> >>>
> >>> Ah, right. I was thinking only of the case where the reset subsystem
> >>> is completely disabled here, so returning NULL could be considered
> >>> a valid return code that can in turn be passed into the other
> >>> functions.
> >>>
> >>> However, I agree that returning NULL as a valid result from
> >>> ..._get_optional() would be bad style, so let's drop my idea
> >>> there.
> >>>
> >>> > I too would prefer to keep that as-is. The reset_control_get_optional
> >>> > stub could return -ENOENT if there is no resets device tree property.
> >>>
> >>> Now I'm also confused about what we really need
> >>> reset_control_get_optional() for, and which error codes the callers
> >>> are supposed to check.
> >>>
> >>> This is the matrix I think you mean for _get_optional:
> >>>
> >> [...]
> >>> CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
> >>> CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
> >>
> >> ^^ I didn't consider this distiction.
> >>
> >>> Is this what you had in mind? If so, what is the value of the
> >>> added runtime warning for reset_control_get? Any caller of that
> >>> function would already check for errors, the only difference
> >>> I see is that callers of _optional can ignore -ENOENT.
> >>
> >> My initial motivation was to make it as hard as possible to misconfigure
> >> the kernel, which is why I initially didn't want stubs for the
> >> non-optional variant. Of course that would cause build failures and/or
> >> reduced compile test coverage, so we added the stubs and the warning to
> >> make it obvious when a misconfigured kernel is running: on a kernel with
> >> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
> >> build, but they are not expected to work. I suppose the same is the case
> >> for _optional, if the dt entry is present, so maybe we should drop
> >> reset_control_get_optional and add always a warning in case of
> >> -EOPNOTSUPP.
> >> I don't want all drivers to have to differentiate between -EOPNOTSUPP
> >> and -ENOENT error codes, only current reset_control_get_optional users
> >> have to do that.
> >
> >
> > I've posted a patch to drop reset_control_get_optional;
> > https://patchwork.kernel.org/patch/9284063/
> >
> > Could you check if it works?
> >
> > If we go this way, my patch
> > 289363fd99a17d6249ee1373541f1da43cbb22c5
> > in your reset/next branch is completely useless.
> >
> > As the commits in the reset-subsystem do not appear
> > even in linux-next until they are pulled into the ASOC tree,
> > how about dropping 289363fd and turning around?
> >
> 
> 
> If you want to take time for this topic,
> how about dropping 289363fd99a17d6249ee1373541f1da43cbb22c5
> ("reset: add WARN_ON(1) to non-optional reset_control_get variants")
> for now?
> 
> 
> I noticed some reset consumers already started dropping _optional,
> while their reset lines should be really optional.
> 
> See
> commit d0e08b0077f49e209bc90305ddf1ca434ac6cc0e
> commit 62d9694a003dba585026df36c181e3ca930aeafc
> 
> Even generic drivers such as ehci-platform.c / ohci-platform.c
> opted out of _optional.
> 
> 
> If commit 289363fd99a17d6249ee1373541f1da43cbb22c5 is merged,
> users of the generic drivers but without reset-controller
> will start to complain about the WARN_ON(1)  sooner or later.

Hmm, I would really like to keep the warnings, but as Arnd suggested,
only if the device tree property is present. I'll drop your patch for
now.

regards
Philipp

Re: [PATCH 2/2] reset: uniphier: use of_device_get_match_data() to get matched data

[Masahiro Yamada]

Hi Philipp,

2016-08-24 21:27 GMT+09:00 Philipp Zabel :
> Hi Masahiro,
>
> Am Mittwoch, den 24.08.2016, 15:40 +0900 schrieb Masahiro Yamada:
>> Use of_device_get_match_data() instead of of_match_node().  With
>> this, we can retrieve the .data field of the OF match table more
>> easily.  No more need to define (or declare) the match table before
>> the probe callback.  I prefer to collect boilerplates at the bottom
>> of the file, so moved it below.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/reset/reset-uniphier.c | 81 
>> +-
>>  1 file changed, 40 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
>> index 41c62af..9b3f2cd 100644
>> --- a/drivers/reset/reset-uniphier.c
>> +++ b/drivers/reset/reset-uniphier.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -285,6 +286,45 @@ static const struct reset_control_ops 
>> uniphier_reset_ops = {
>>   .status = uniphier_reset_status,
>>  };
>>
>> +static int uniphier_reset_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct uniphier_reset_priv *priv;
>> + const struct uniphier_reset_data *p, *data;
>> + struct regmap *regmap;
>> + struct device_node *parent;
>> + unsigned int nr_resets = 0;
>> +
>> + data = of_device_get_match_data(dev);
>> + WARN_ON(!data);
>
> I know right now this can't happen anyway, but you did return -EINVAL
> here before. Maybe use:
>
> if (WARN_ON(!data))
> return -EINVAL;
>
> instead? I can fix it up if you agree.

I agree.

Please fix it up.  Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Thierry Reding]

On Wed, Aug 24, 2016 at 05:34:55PM +0530, Vinay Simha wrote:
> thierry,
> 
> this is the reference pinouts of the panel
> http://www.tonylabs.com/wp-content/uploads/LT070ME05000-pinouts.jpg

I can't open that file.

> as you suggest , i will change the vcc-supply,
> 
>  - iovcc-supply: phandle of the regulator that supplies power to
>   the IOVCC voltage input (1.8 V)
> 
> will keep the other two(vddp-supply, dcdc_en-supply) remaining same.

"dcdc_en" sounds to me like it should be a GPIO rather than a regulator.

According to this datasheet:


http://kb.52solution.com/data/uploads/2016/04/07/3172846545705cc22d050e.pdf

the input voltages are indeed VDD, VDDp and IOVCC, though with slightly
larger tolerances than the previous datasheet. VDD and VDDp can both go
from 3.0 V to 5.0 V. DCDC_EN is indeed an additional GPIO to enable the
VDDp supply.

I think you'd need something along these lines:

- vdd-supply: LED power supply (3.0-5.0 V)
- vddp-supply: power IC supply (3.0-5.0 V)
- iovcc-supply: LCM power supply (1.8 V)
- dcdc-en-gpios: power IC supply enable
- led-en-gpios: LED backlight enable

Or perhaps your vddp-supply should be a regulator that's controlled by
the GPIO that you'd put in dcdc-en-gpios. That might work better. That
would leave only led-en-gpios as the only enable GPIOs property, so it
would be okay to keep the name "enable-gpios", I guess.

Thierry

> On Wed, Aug 24, 2016 at 5:15 PM, Thierry Reding
>  wrote:
> > On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
> >> Add documentation for lt070me05000 panel
> >>
> >> Cc: Archit Taneja 
> >> Cc: John Stultz 
> >> Cc: Thierry Reding 
> >> Cc: Sumit Semwal 
> >> Signed-off-by: Vinay Simha BN 
> >> Acked-by: Rob Herring 
> >>
> >> ---
> >> v2:
> >>  * incorporated rob herring and thierry reviews
> >>gpio to gpios, gpio to regulator using fixed regulators
> >>and pwm backlight is removed, since it is controlled by
> >>dcs commands
> >> ---
> >>  .../bindings/display/panel/jdi,lt070me05000.txt| 57 
> >> ++
> >>  1 file changed, 57 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
> >> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> >> new file mode 100644
> >> index 000..613b76f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> >> @@ -0,0 +1,57 @@
> >> +JDI model LT070ME05000 1200x1920 7" DSI Panel
> >> +
> >> +Required properties:
> >> +- compatible: should be "jdi,lt070me05000"
> >> +- vddp-supply: phandle of the regulator that provides the supply voltage
> >> +  Power IC supply (3-5V)
> >> +- dcdc_en-supply: phandle of the regulator that provides the supply 
> >> voltage
> >> +  Power IC supply enable, High active
> >> +- vcc-supply: phandle of the regulator that provides the supply voltage
> >> +  IOVCC , power supply for LCM (1.8V)
> >
> > I was just going to apply this and wanted to add some information about
> > how many lanes the panel uses, so I looked at the datasheet linked to in
> > patch 4/4:
> >
> > http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
> >
> > and noticed that the power supplies in the binding here don't match the
> > ones listed in the datasheet. Granted, the datasheet is somewhat meager,
> > but it lists the following three input voltages:
> >
> > - IOVCC at 1.8 V
> > - VDD at 3.0 V
> > - VDDP at 3.0 V
> >
> > This matches in part what the above binding describes, but it's not
> > quite right, so I'm wondering if the name for dcdc_en-supply came from
> > the board schematics and reflects the name of the rail on the board
> > design that provides this rather than the input voltage on the panel.
> >
> > I think we should follow the names in the panel datasheet so that people
> > can more easily reference the correct regulators when using this panel
> > on a different board. I'd suggest:
> >
> > - iovcc-supply: phandle of the regulator that supplies power to
> >   the IOVCC voltage input (1.8 V)
> > - vdd-supply: phandle of the regulator that supplies power to
> >   the VDD voltage input (3.0 V)
> > - vddp-supply: phandle of the regulator that supplies power to
> >   the VDDP voltage input (3.0 V)
> >
> > Any objections?
> >
> > Thierry
> 
> 
> 
> -- 
> regards,
> vinaysimha


signature.asc
Description: PGP signature

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Thierry Reding]

On Wed, Aug 24, 2016 at 05:53:00PM +0530, Vinay Simha wrote:
> if we do not set the polarity to 8mA, panel will have gibberish display.
> (information to set 8mA is available only in
> nexus7-msm-flo-3.4-lollipop-release_dsi kernel nx7 release)
> 
> i will add this
> reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>;

I don't think that will work with the current driver, because the GPIO
subsystem will automatically invert the value for you. Currently the
panel driver sets the GPIO value to 0 to assert the reset. With the
GPIO_ACTIVE_LOW flag you'd end up setting the actual level of the GPIO
to high, which is going to deassert. So I think if you make the above
change (which I think is the right thing to do), you'll also have to
update the driver to use high-active logic.

Thierry


signature.asc
Description: PGP signature

Applied "ASoC: samsung: i2s: Add missing clk_disable_unprepare() on error in samsung_i2s_probe()" to the asoc tree

[Mark Brown]

The patch

   ASoC: samsung: i2s: Add missing clk_disable_unprepare() on error in 
samsung_i2s_probe()

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From fd61576fdda88c9677f9ea62e6f32997ce39daea Mon Sep 17 00:00:00 2001
From: Wei Yongjun 
Date: Tue, 23 Aug 2016 15:16:42 +
Subject: [PATCH] ASoC: samsung: i2s: Add missing clk_disable_unprepare() on
 error in samsung_i2s_probe()

Add the missing clk_disable_unprepare() before return
from samsung_i2s_probe() in the error handling case.

Signed-off-by: Wei Yongjun 
Acked-by: Sylwester Nawrocki 
Signed-off-by: Mark Brown 
---
 sound/soc/samsung/i2s.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index fa3ff03d97d5..7e32cf4581f8 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1318,7 +1318,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai = i2s_alloc_dai(pdev, true);
if (!sec_dai) {
dev_err(&pdev->dev, "Unable to alloc I2S_sec\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_disable_clk;
}
 
sec_dai->lock = &pri_dai->spinlock;
@@ -1342,7 +1343,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 
if (i2s_pdata && i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
dev_err(&pdev->dev, "Unable to configure gpio\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_disable_clk;
}
 
ret = devm_snd_soc_register_component(&pri_dai->pdev->dev,
@@ -1366,6 +1368,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 err_free_dai:
if (sec_dai)
i2s_free_sec_dai(sec_dai);
+err_disable_clk:
+   clk_disable_unprepare(pri_dai->clk);
return ret;
 }
 
-- 
2.8.1

Re: [PATCH v2 1/8] hisi_sas: add internal abort main code

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Add main code for internal abort functionality.
> 
> The internal abort features allows the host controller
> to abort commands which are still active in the
> controller but have not yet been sent to the slave
> device.
> 
> Typically a command only spends a relatively
> short time in the controller when compared to the
> amount of the time after it is sent to the slave
> device.
> Two modes of internal abort are supported:
> - device
> - individual command
> 
> For device, when the internal abort is issued all
> commands in the host for that device are aborted.
> For a single command, only that command is aborted
> if it is still in the host.
> 
> In HW the internal abort command is executed
> similar to any other sort of command, like SSP.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas.h  |   8 ++
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 163 
> ++
>  2 files changed, 171 insertions(+)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 2/8] hisi_sas: add internal abort in hisi_sas_dev_gone()

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Execute an internal abort for that device when it is removed,
> so that commands for that device are not processed.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 763c6c5..c4e59cd 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -621,6 +621,9 @@ static void hisi_sas_dev_gone(struct domain_device 
> *device)
>   dev_info(dev, "found dev[%lld:%x] is gone\n",
>sas_dev->device_id, sas_dev->dev_type);
>  
> + hisi_sas_internal_task_abort(hisi_hba, device,
> +  HISI_SAS_INT_ABT_DEV, 0);
> +
>   hisi_hba->hw->free_device(hisi_hba, sas_dev);
>   device->lldd_dev = NULL;
>   memset(sas_dev, 0, sizeof(*sas_dev));
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/8] hisi_sas: add internal abort to hisi_sas_abort_task()

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Execute an internal abort for executing a task abort.
> This is for case of the command still being present
> in host when abort is executed.
> 
> For a SATA internal abort, we set abort for all tasks
> associated with the device.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 4/8] hisi_sas: add prep_abort_v2_hw()

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Add function to prepare the an internal abort
> for v2 hw.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 33 +
>  1 file changed, 33 insertions(+)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [RFC PATCH v3 0/2] Type-C Port Manager

[Heikki Krogerus]

Hi Guenter,

On Tue, Aug 23, 2016 at 02:10:49PM -0700, Guenter Roeck wrote:
> The following series of patches implements a USB Type-C Port Manager
> using the pending USB Type-C class code as basis. The code is still WIP,
> but I think it is important to get feedback from the community at this point.
> 
> There are two patches in the series. The first patch implements the Type-C
> Port Manager state machine. The forth patch is an interface between the
> Type-C Port Manager and a TCPCI (Type-C Port Controller Interface) compliant
> USB Type-C Port Controller.
> 
> Patch 2/2 (the interface to a TCPCI compliant chip) is currently untested
> since I don't have the necessary hardware available. The port manager code
> was tested connecting to an Embedded Controller on a Chromebook, bypassing
> the Port Manager implementation in the EC.
> 
> Both Source and Sink operation was tested with various Type-C chargers, docks,
> and connectors. Alternate mode support is partially implemented (Alternate 
> mode
> support is requested from the partner), but alternate modes are not actually
> selected. Implementing this will require more thought, since the actual
> alternate mode support has to be implemented elsewhere, such as in a dedicated
> Phy driver. It should be possible to implement the interface between phy 
> driver
> and Type-C Port Controller driver using extcon, but I have not further 
> explored
> the possibilities, and other options might be possible and/or better.
> 
> v3:
> - Improve TCPM state machine resiliency if there are spurious CC line changes
>   while the state machine is in a transient change (waiting for a timeout)
> - Update current limit after CC voltage level changes on a port which is not
>   PD capable.
> - Applies to v6 of "USB Type-C Connector class" patch series.
> 
> v2:
> - Class code no longer uses locking, so the patch to remove it is no longer
>   necessary.
> - tcpm: Only update polarity if setting it was successful
>   If setting the CC line polarity in the driver was not successful,
>   don't update the internal polarity state.
> - tcpm: All PD messages are little endian; convert to and from CPU endianness.
> - tcpm: Avoid comparisons against NULL.
> - tcpm: Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
> - tcpm/tcpc: Callbacks into tcpm need to be lockless to avoid timing problems
>   in low level drivers.
> - tcpm/tcpc: Simplify callbacks; tcpm can request the current state of cc/vbus
>   when it is ready to use it.
> - Applies to v5 of "USB Type-C Connector class" patch series.

I have not reviewed these yet completely, but so far the series looks
really good. Nice job!

There are a lot of things that look generic and not tied to TCPCs, for
example the USB PD message handling. Couldn't those already be
separated from TCPM code or made otherwise available for non-TCPC
PHYs? The struct tcpc_dev looks to me like it would be usable for also
non-TCPC PHYs as is and enough for most cases.


Thanks,

-- 
heikki

Re: [PATCH 4/7] pinctrl: samsung: Add GPFx support of Exynos5433

[Chanwoo Choi]

Hi Tomasz,

I'm sorry for delay reply.

On 2016년 08월 19일 20:31, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> 2016-08-19 18:07 GMT+09:00 Chanwoo Choi :
>> Hi Tomasz Figa,
>>
>> Due to wrong setting of email client,
>> your reply is deleted on my email client at the company.
> 
> I used Gmail (in plain text mode) to reply, was that related?

The mistake depend on my filer setting of mail client.

> 
>> I'm so sorry. So, I add your comment on below and then
>> I reply the detailed description.
> 
> No problem. Thanks for description.
> 
>>
>> On 2016년 08월 16일 15:27, Chanwoo Choi wrote:
>>> From: Joonyoung Shim 
>>>
>>> This patch add the support of GPFx pin of Exynos5433 SoC. Exynos5433 has
>>> different memory map of GPFx from previous Exynos SoC. Exynos GPIO has
>>> following register to control gpio funciton. Usually, all registers of GPIO
>>> are included in same domain.
>>> - CON / DAT / PUD / DRV / CONPDN / PUDPDN
>>> - EINT_CON/ EINT_FLTCON0, EINT_FLTCON1 / EINT_MASK / EINT_PEND
>>>
>>> But, GPFx are included in two domain as following. So, this patch supports
>>> the GPFx pin which handle the on separate two domains.
>>> - ALIVE domain : CON / DAT / PUD / DRV / CONPDN / PUDPDN
>>> - IMEM domain  : EINT_CON/ EINT_FLTCON0, EINT_FLTCON1 / EINT_MASK / 
>>> EINT_PEND
>>
>> -
>> I'm afraid I don't get anything from the description above. Could you
>> describe the layout of registers in memory map and IRQ routing of the
>> pins?
>>
>> Best regards,
>> Tomasz
>> --
>>
>> On this patch, I'm sorry that I described the wrong information about GFP1~5.
>> I explained the memory map of GPF[1-5] the oppositely. Following compositions
>> are correct.
>> - ALIVE : WEINT_FLTCONx, WEINT_MASK, WEING_PEND
>> - IMEM : CON, DAT, PUD, DRV, CONPDN, PUDPDN
>> And, I add the memory map for GPF[1~5][2] and the wakeup interrupt 
>> information[1].
>>
>> [1] Memory map for GPF1~5
>> [ALIVE]
>> WEINT_GPA0_CON : 0x1058_ (ALIVE) + (0x0700 = 0x0700 + 0x0)
>> WEINT_GPA1_CON : 0x1058_ (ALIVE) + (0x0704 = 0x0700 + 0x4)
>> WEINT_GPA2_CON : 0x1058_ (ALIVE) + (0x0708 = 0x0700 + 0x8)
>> WEINT_GPA3_CON : 0x1058_ (ALIVE) + (0x070C = 0x0700 + 0xC)
>>
>> WEINT_GPF1_CON : 0x1058_ (ALIVE) + (0x1704 = 0x0700 + 0x1004)
>> WEINT_GPF2_CON : 0x1058_ (ALIVE) + (0x1708 = 0x0700 + 0x1008)
>> WEINT_GPF3_CON : 0x1058_ (ALIVE) + (0x170C = 0x0700 + 0x100C)
>> WEINT_GPF4_CON : 0x1058_ (ALIVE) + (0x1710 = 0x0700 + 0x10010)
>> WEINT_GPF5_CON : 0x1058_ (ALIVE) + (0x1714 = 0x0700 + 0x1014)
>>
>> WEINT_GPF[x]_MASK : 0x1058_ (ALIVE) + (0x1900 + (x * 4))
>> WEINT_GPF[x]_PEND : 0x1058_ (ALIVE) + (0x1A00 + (x * 4))
>> (x : 1 ~ 5)
>>
>> [IMEM]
>> GPF1_CON  : 0X1109_ (IMEM) + 0x0020
>> GPF1_DAT   : 0X1109_ (IMEM) + 0x0024
>> GPF1_PUD  : 0X1109_ (IMEM) + 0x0028
>> GPF1_DRV  : 0X1109_ (IMEM) + 0x002C
>> GPF1_CONPDN  : 0X1109_ (IMEM) + 0x0030
>> GPF1_PUDPDN  : 0X1109_ (IMEM) + 0x0034
>>
>> GPF2_CON : 0X1109_ (IMEM) + 0x0040
>> ...
>> GPF3_CON : 0X1109_ (IMEM) + 0x0060
>> ...
>> GPF4_CON : 0X1109_ (IMEM) + 0x0080
>> ...
>> GPF5_CON : 0X1109_ (IMEM) + 0x00A0
>>
>> [2] Interrput pin information
>> - the total number of wakeup external IRQ is 64.
>> --
>> domain| gpio : nr  | wakeup interrput name   | SPI number   |
>> ---
>> ALIVE | GPA0 : 8 | INTREQ__EINT[0~7] | SPI[0] ~ SPI[7]   |
>> ALIVE | GPA1 : 8 | INTREQ__EINT[8~15]   | SPI[8] ~ SPI[15] |
>> ALIVE | GPA2 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPA3 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ---
>> ALIVE | GPF1 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF2 : 4 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF3 : 4 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF4 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF5 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ---
>>
>> In summary,
>> If gpf[1-5] handle the CON/DAT/PUD/DRV register,
>> the driver will use the drvdata->ext_base (IMEM base address)
>> instead of drvdata->virt_base(ALIVE base address)
>> because the CON/DAT/PUD/DRV register of gpf[1-5] are included
>> in the IMEM domain.
>>
>> If gpf[1-5] handle the WEINT_* register,
>> the driver will use the drvdata->virt_base(ALIVE base address)
>> because the WEINT_* registers of gpf[1-5] are included in the ALIVE domain.
> 
> Okay, so Krzysztof's suggestion doesn't apply because it's not the
> eint base which is displaced, but the pinctrl base. I'd suggest the
> fol

Re: [RFC PATCH 2/4] perf-probe: Add offline output directory option

[Arnaldo Carvalho de Melo]

Em Wed, Aug 24, 2016 at 02:58:12PM +0900, Masami Hiramatsu escreveu:
> Add offline output direcrtory option. This allows user to
> store probe event definition in offline output directory.

In such cases you should show it in action, like I am doing now to test
this patch:

  [root@jouet ~]# perf probe --outdir=my_probes do_open
  kprobe_events file does not exist - please rebuild kernel with 
CONFIG_KPROBE_EVENTS.
Error: Failed to add events.
  [root@jouet ~]# 

Oops, misleading error message, probably I need to first do a mkdir:

  [root@jouet ~]# mkdir my_probes
  [root@jouet ~]# perf probe --outdir=my_probes do_open
  Added new event:
probe:do_open(on do_open)

  You can now use it in all perf tools, such as:

  perf record -e probe:do_open -aR sleep 1

  [root@jouet ~]# ls -la my_probes
  total 12
  drwxr-xr-x.  2 root root 4096 Aug 24 09:47 .
  dr-xr-x---. 31 root root 4096 Aug 24 09:47 ..
  -rw-r--r--.  1 root root   30 Aug 24 09:47 kprobe_events
  [root@jouet ~]# cat my_probes/kprobe_events 
  p:probe/do_open _text+3481584
  [root@jouet ~]# 

Wouldn't it be better to call it some other name and imply --dry-run? "outdir"
seems too vague. Perhaps --definition and instead have it run like:

  # perf probe --definition do_open
  p:probe/do_open _text+3481584
  #

Then one could even use it to redirect it to a file, tee + file and even test 
it as:

  # perf probe --definition do_open > /sys/kernel/debug/tracing/kprobe_events
  #

For debugging:

  # perf probe --definition do_open | tee 
/sys/kernel/debug/tracing/kprobe_events

:-)

I picked "--kprobes" first, but that would left out e.g. uprobes, then I
thought about --event, but also sounds vague, read
Documentation/trace/kprobetrace.txt and saw this bit:

 ---
Usage examples
--
To add a probe as a new event, write a new definition to kprobe_events
as below.

  echo 'p:myprobe do_sys_open dfd=%ax filename=%dx flags=%cx mode=+4($stack)' > 
/sys/kernel/debug/tracing/kprobe_events
 ---

So you used "definition" for that string, might as well be consistent and use
it here as well.

Also please fix the OPT_STRING string, it should start with a capital
letter:

--max-probes   Set how many probe points can be found for a probe.
--no-inlines  Don't search inlined functions
--outdir 
  path to offline output directory
--range   Show variables location range in scope (with --vars 
only)


See how it stands out? All the others start with a capital letter.

I applied the first patch, totally trivial.

- Arnaldo
 
> Signed-off-by: Masami Hiramatsu 
> ---
>  tools/perf/builtin-probe.c|2 ++
>  tools/perf/util/probe-event.h |1 +
>  tools/perf/util/probe-file.c  |   19 ---
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> index ee5b421..5b45ec8 100644
> --- a/tools/perf/builtin-probe.c
> +++ b/tools/perf/builtin-probe.c
> @@ -517,6 +517,8 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   "Show variables location range in scope (with --vars only)"),
>   OPT_STRING('k', "vmlinux", &symbol_conf.vmlinux_name,
>  "file", "vmlinux pathname"),
> + OPT_STRING(0, "outdir", &probe_conf.output_dir,
> + "directory", "path to offline output directory"),
>   OPT_STRING('s', "source", &symbol_conf.source_prefix,
>  "directory", "path to kernel source"),
>   OPT_BOOLEAN('\0', "no-inlines", &probe_conf.no_inlines,
> diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
> index f4f45db..75b572a 100644
> --- a/tools/perf/util/probe-event.h
> +++ b/tools/perf/util/probe-event.h
> @@ -14,6 +14,7 @@ struct probe_conf {
>   boolno_inlines;
>   boolcache;
>   int max_probes;
> + const char  *output_dir;
>  };
>  extern struct probe_conf probe_conf;
>  extern bool probe_event_dry_run;
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 6f931e4..41db430 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -73,16 +73,25 @@ static void print_both_open_warning(int kerr, int uerr)
>  static int open_probe_events(const char *trace_file, bool readwrite)
>  {
>   char buf[PATH_MAX];
> + const char *tracing_dir = tracing_path;
> + int oflag = 0;
> + mode_t mode = 0;
>   int ret;
>  
> + if (probe_conf.output_dir) {
> + tracing_dir = probe_conf.output_dir;
> + oflag = O_CREAT;
> + mode = 0644;
> + }
> +
>   ret = e_snprintf(buf, PATH_MAX, "%s/%s",
> -  tracing_path, trace_file);
> +  tracing_dir, trace_file);
>   if (ret >= 0) {
>   pr_debug("Opening %s write=%d\n", buf, readwrite);
>   if (readwrite && !probe_event_dry_run)
> -

Re: [PATCH v2 5/8] hisi_sas: add v2 hw slot complete internal abort support

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Add code in slot_complete_v2_hw() to deal with the
> slots which have completed due to internal abort.
> 
> The status codes have the following meaning:
> - STAT_IO_ABORTED: the IO has been aborted due to
> internal abort, whether by device or individual
> abort command
> - STAT_IO_COMPLETE: internal abort command has
> completed successfully for device or individual
> abort command
> - STAT_IO_NO_DEVICE: internal abort command has
> completed for device but cannot find any IO
> - STAT_IO_NOT_VALID: internal abort command has
> completed for single command but could not
> find the command
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
> b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> index fec1675..bf9b693 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> @@ -227,6 +227,13 @@
>  #define CMPLT_HDR_RSPNS_XFRD_MSK (0x1 << CMPLT_HDR_RSPNS_XFRD_OFF)
>  #define CMPLT_HDR_ERX_OFF12
>  #define CMPLT_HDR_ERX_MSK(0x1 << CMPLT_HDR_ERX_OFF)
> +#define CMPLT_HDR_ABORT_STAT_OFF 13
> +#define CMPLT_HDR_ABORT_STAT_MSK (0x7 << CMPLT_HDR_ABORT_STAT_OFF)
> +/* abort_stat */
> +#define STAT_IO_NOT_VALID0x1
> +#define STAT_IO_NO_DEVICE0x2
> +#define STAT_IO_COMPLETE 0x3
> +#define STAT_IO_ABORTED  0x4
>  /* dw1 */
>  #define CMPLT_HDR_IPTT_OFF   0
>  #define CMPLT_HDR_IPTT_MSK   (0x << CMPLT_HDR_IPTT_OFF)
> @@ -1569,6 +1576,30 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba, struct 
> hisi_sas_slot *slot,
>   goto out;
>   }
>  
> + /* Use SAS+TMF status codes */
> + switch ((complete_hdr->dw0 & CMPLT_HDR_ABORT_STAT_MSK)
> + >> CMPLT_HDR_ABORT_STAT_OFF) {
> + case STAT_IO_ABORTED:
> + /* this io has been aborted by abort command */
> + ts->stat = SAS_ABORTED_TASK;
> + goto out;
> + case STAT_IO_COMPLETE:
> + /* internal abort command complete */
> + ts->stat = TMF_RESP_FUNC_COMPLETE;
> + goto out;
> + case STAT_IO_NO_DEVICE:
> + ts->stat = TMF_RESP_FUNC_COMPLETE;
> + goto out;
> + case STAT_IO_NOT_VALID:
> + /* abort single io, controller don't find
> +  * the io need to abort
> +  */
> + ts->stat = TMF_RESP_FUNC_FAILED;
> + goto out;
Hmm. This will cause the SCSI EH to kick in.
And then, according to the description abort has succeeded, it's just
that for some reason the associated command couldn't be found.
So couldn't this be due to a race condition, and the command has in fact
been aborted correctly (and the code is just too slow acknowledging it)?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 7/8] hisi_sas: add TMF success check

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> When a tmf is issued, various response codes can be
> returned from the target. For a query tmf the
> response may be TMF_RESP_FUNC_COMPLETE or
> TMF_RESP_FUNC_SUCC.
> Add a condition for TMF_RESP_FUNC_SUCC to
> hisi_sas_exec_internal_tmf_task().
> This affects query tmf, as the result is success
> the returned value was for failure.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 73f581f..85c73d3 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -744,6 +744,12 @@ static int hisi_sas_exec_internal_tmf_task(struct 
> domain_device *device,
>   }
>  
>   if (task->task_status.resp == SAS_TASK_COMPLETE &&
> + task->task_status.stat == TMF_RESP_FUNC_SUCC) {
> + res = TMF_RESP_FUNC_SUCC;
> + break;
> + }
> +
> + if (task->task_status.resp == SAS_TASK_COMPLETE &&
> task->task_status.stat == SAS_DATA_UNDERRUN) {
>   /* no error, but return the number of bytes of
>* underrun
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 6/8] hisi_sas: fail tmf task prep when port detached

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> When the port is detached we cannot execute a TMF,
> as there can be no device attached to the port.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 280a19d..73f581f 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -204,7 +204,7 @@ static int hisi_sas_task_prep(struct sas_task *task, 
> struct hisi_hba *hisi_hba,
>   return rc;
>   }
>   port = device->port->lldd_port;
> - if (port && !port->port_attached && !tmf) {
> + if (port && !port->port_attached) {
>   if (sas_protocol_ata(task->task_proto)) {
>   struct task_status_struct *ts = &task->task_status;
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 8/8] hisi_sas: update version to 1.6

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas.h 
> b/drivers/scsi/hisi_sas/hisi_sas.h
> index 8311360..ca55ec2 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas.h
> +++ b/drivers/scsi/hisi_sas/hisi_sas.h
> @@ -23,7 +23,7 @@
>  #include 
>  #include 
>  
> -#define DRV_VERSION "v1.5"
> +#define DRV_VERSION "v1.6"
>  
>  #define HISI_SAS_MAX_PHYS9
>  #define HISI_SAS_MAX_QUEUES  32
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[tip:x86/apic] x86/apic: Update comment about disabling processor focus

[tip-bot for Wei Jiangang]

Commit-ID:  5035da41996d346c648a65c1d7a9f6469c7d358a
Gitweb: http://git.kernel.org/tip/5035da41996d346c648a65c1d7a9f6469c7d358a
Author: Wei Jiangang 
AuthorDate: Fri, 19 Aug 2016 11:22:37 +0800
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 11:24:33 +0200

x86/apic: Update comment about disabling processor focus

Fix references to discarded end_level_ioapic_irq().

Signed-off-by: Wei Jiangang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@suse.de
Link: 
http://lkml.kernel.org/r/1471576957-12961-2-git-send-email-weijg.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/apic.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 63b7484..1cbae30 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1374,7 +1374,6 @@ void setup_local_APIC(void)
 * Actually disabling the focus CPU check just makes the hang less
 * frequent as it makes the interrupt distributon model be more
 * like LRU than MRU (the short-term load is more even across CPUs).
-* See also the comment in end_level_ioapic_irq().  --macro
 */
 
/*

Re: [REGRESSION] Select hang with zero sized UDP packets

[Eric Dumazet]

On Wed, 2016-08-24 at 11:22 +0300, Dan Akunis wrote:
> When select wakes up on a UDP socket, user is expecting to get data. Getting 
> 0 from recvfrom() or whatever read function she uses, is a wrong attitude.
> I agree with David.
> 
> The unit test that expects select to wake up is wrong and should be changed.
> 

Please do not top post on netdev mailing list.

Program is fine and wont be changed to work around a kernel bug.

We definitely can send and receive UDP messages with 0 payload.

So select() should unblock when one such frame is received, otherwise
you could fill up the receive queue with a lot of frames like that and
when SO_RCVBUF limit is reached, block future messages.

UDP is a datagram protocol.

Bug fix is merged :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=e83c6744e81abc93a20d0eb3b7f504a176a6126a

[tip:x86/apic] x86/smpboot: Check APIC ID before setting up default routing

[tip-bot for Wei Jiangang]

Commit-ID:  384d9fe3741657c8ed8cd9bf30bc1d4611864d56
Gitweb: http://git.kernel.org/tip/384d9fe3741657c8ed8cd9bf30bc1d4611864d56
Author: Wei Jiangang 
AuthorDate: Fri, 19 Aug 2016 11:22:36 +0800
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 11:24:33 +0200

x86/smpboot: Check APIC ID before setting up default routing

This is not a bugfix, but code optimization.

If the BSP's APIC ID in local APIC is unexpected,
a kernel panic will occur and the system will halt.
That means no need to enable APIC mode, and no reason
to set up the default routing for APIC.

The combination of default_setup_apic_routing() and
apic_bsp_setup() are used to enable APIC mode.
They two should be kept together, rather than being
separated by the codes of checking APIC ID.
Just like their usage in APIC_init_uniprocessor().

Signed-off-by: Wei Jiangang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@suse.de
Link: 
http://lkml.kernel.org/r/1471576957-12961-1-git-send-email-weijg.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/smpboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 2a6e84a..8216b99 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1316,14 +1316,13 @@ void __init native_smp_prepare_cpus(unsigned int 
max_cpus)
break;
}
 
-   default_setup_apic_routing();
-
if (read_apic_id() != boot_cpu_physical_apicid) {
panic("Boot APIC ID in local APIC unexpected (%d vs %d)",
 read_apic_id(), boot_cpu_physical_apicid);
/* Or can we switch back to PIC here? */
}
 
+   default_setup_apic_routing();
cpu0_logical_apicid = apic_bsp_setup(false);
 
pr_info("CPU%d: ", 0);

[tip:x86/asm] dma-api: Teach the "DMA-from-stack" check about vmapped stacks

[tip-bot for Andy Lutomirski]

Commit-ID:  b4a0f533e5976cb1a79f31d6152e1d322d79b7f1
Gitweb: http://git.kernel.org/tip/b4a0f533e5976cb1a79f31d6152e1d322d79b7f1
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:22 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:41 +0200

dma-api: Teach the "DMA-from-stack" check about vmapped stacks

If we're using CONFIG_VMAP_STACK=y and we manage to point an sg entry
at the stack, then either the sg page will be in highmem or sg_virt()
will return the direct-map alias.  In neither case will the existing
check_for_stack() implementation realize that it's a stack page.

Fix it by explicitly checking for stack pages.

This has no effect by itself.  It's broken out for ease of review.

Signed-off-by: Andy Lutomirski 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/448460622731312298bf19dcbacb1606e75de7a9.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 lib/dma-debug.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index fcfa193..06f02f6 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1164,11 +1165,32 @@ static void check_unmap(struct dma_debug_entry *ref)
put_hash_bucket(bucket, &flags);
 }
 
-static void check_for_stack(struct device *dev, void *addr)
+static void check_for_stack(struct device *dev,
+   struct page *page, size_t offset)
 {
-   if (object_is_on_stack(addr))
-   err_printk(dev, NULL, "DMA-API: device driver maps memory from "
-   "stack [addr=%p]\n", addr);
+   void *addr;
+   struct vm_struct *stack_vm_area = task_stack_vm_area(current);
+
+   if (!stack_vm_area) {
+   /* Stack is direct-mapped. */
+   if (PageHighMem(page))
+   return;
+   addr = page_address(page) + offset;
+   if (object_is_on_stack(addr))
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [addr=%p]\n", addr);
+   } else {
+   /* Stack is vmalloced. */
+   int i;
+
+   for (i = 0; i < stack_vm_area->nr_pages; i++) {
+   if (page != stack_vm_area->pages[i])
+   continue;
+
+   addr = (u8 *)current->stack + i * PAGE_SIZE + offset;
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [probable addr=%p]\n", addr);
+   break;
+   }
+   }
 }
 
 static inline bool overlap(void *addr, unsigned long len, void *start, void 
*end)
@@ -1291,10 +1313,11 @@ void debug_dma_map_page(struct device *dev, struct page 
*page, size_t offset,
if (map_single)
entry->type = dma_debug_single;
 
+   check_for_stack(dev, page, offset);
+
if (!PageHighMem(page)) {
void *addr = page_address(page) + offset;
 
-   check_for_stack(dev, addr);
check_for_illegal_area(dev, addr, size);
}
 
@@ -1386,8 +1409,9 @@ void debug_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
entry->sg_call_ents   = nents;
entry->sg_mapped_ents = mapped_ents;
 
+   check_for_stack(dev, sg_page(s), s->offset);
+
if (!PageHighMem(sg_page(s))) {
-   check_for_stack(dev, sg_virt(s));
check_for_illegal_area(dev, sg_virt(s), sg_dma_len(s));
}
 

Re: [RFC PATCH 4/4] perf-probe: Support probing on offline cross-arch binary

[Arnaldo Carvalho de Melo]

Em Wed, Aug 24, 2016 at 02:58:41PM +0900, Masami Hiramatsu escreveu:
> Support probing on offline cross-architecture binary by
> adding getting the target machine arch from ELF and
> choose correct register string for the machine.
> 
> Here is an example:
>   -
>   $ mkdir tracing

No need for the sudo here, right?

>   $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
> do_sys_open '$vars'

Going with the --definition (or any other name that spits out what needs
to go to kprobes_events, this could be further short circuited, ie.:

  $ perf probe --vmlinux=./vmlinux-arm do_sys_open '$vars'
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 
mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  $

Because in this case clearly the probe is not for the running kernel,
thus we could imply that this is to generate probes for running on
some other place.

Also perhaps even this could be made shorter:

  $ perf probe vmlinux-arm do_sys_open '$vars'
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 
mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  $

As it can easily figure out the first argument _is_ a vmlinux :-)

- Arnaldo


>   Added new event:
>   probe:do_sys_open(on do_sys_open with $vars)
> 
>   You can now use it in all perf tools, such as:
> 
>   perf record -e probe:do_sys_open -aR sleep 1
> 
>   $ cat tracing/kprobe_events
>   p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
>flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
>   -
> Here, we can get probe/do_sys_open event by "copy & paste" from
> ./tracing/kprobe_events to target-machine's debugfs/tracing/kprobe_events
> 
> To make sure it is correct:
>   -
>   $ nm vmlinux-arm | grep "T _text"
>   80008000 T _text
>   $ nm vmlinux-arm | grep "T do_sys_open"
>   801410f4 T do_sys_open
>   $ expr `printf "%d + %d" 0x80008000 1282292`
>   2148798708
>   $ printf "%x\n" 2148798708
>   801410f4
>   -
> So "_text+12882292" indicates do_sys_open on the target binary correctly.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
>  tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
>  tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
>  tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
>  tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
>  tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
>  tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
>  tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
>  tools/perf/util/Build  |1 
>  tools/perf/util/dwarf-regs.c   |   55 
> 
>  tools/perf/util/include/dwarf-regs.h   |6 ++
>  tools/perf/util/probe-finder.c |   27 ++
>  tools/perf/util/probe-finder.h |1 
>  13 files changed, 201 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/util/dwarf-regs.c
> 
> diff --git a/tools/perf/arch/arm/include/dwarf-regs-table.h 
> b/tools/perf/arch/arm/include/dwarf-regs-table.h
> new file mode 100644
> index 000..f298d03
> --- /dev/null
> +++ b/tools/perf/arch/arm/include/dwarf-regs-table.h
> @@ -0,0 +1,9 @@
> +#ifdef DEFINE_DWARF_REGSTR_TABLE
> +/* This is included in perf/util/dwarf-regs.c */
> +
> +static const char * const arm_regstr_tbl[] = {
> + "%r0", "%r1", "%r2", "%r3", "%r4",
> + "%r5", "%r6", "%r7", "%r8", "%r9", "%r10",
> + "%fp", "%ip", "%sp", "%lr", "%pc",
> +};
> +#endif
> diff --git a/tools/perf/arch/arm64/include/dwarf-regs-table.h 
> b/tools/perf/arch/arm64/include/dwarf-regs-table.h
> new file mode 100644
> index 000..2675936
> --- /dev/null
> +++ b/tools/perf/arch/arm64/include/dwarf-regs-table.h
> @@ -0,0 +1,13 @@
> +#ifdef DEFINE_DWARF_REGSTR_TABLE
> +/* This is included in perf/util/dwarf-regs.c */
> +
> +static const char * const aarch64_regstr_tbl[] = {
> + "%r0", "%r1", "%r2", "%r3", "%r4",
> + "%r5", "%r6", "%r7", "%r8", "%r9",
> + "%r10", "%r11", "%r12", "%r13", "%r14",
> + "%r15", "%r16", "%r17", "%r18", "%r19",
> + "%r20", "%r21", "%r22", "%r23", "%r24",
> + "%r25", "%r26", "%r27", "%r28", "%r29",
> + "%lr", "%sp",
> +};
> +#endif
> diff --git a/tools/perf/arch/powerp

[tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

[tip-bot for Andy Lutomirski]

Commit-ID:  e37e43a497d5a8b7c0cc1736d56986f432c394c9
Gitweb: http://git.kernel.org/tip/e37e43a497d5a8b7c0cc1736d56986f432c394c9
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:23 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:42 +0200

x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

This allows x86_64 kernels to enable vmapped stacks by setting
HAVE_ARCH_VMAP_STACK=y - which enables the CONFIG_VMAP_STACK=y
high level Kconfig option.

There are a couple of interesting bits:

First, x86 lazily faults in top-level paging entries for the vmalloc
area.  This won't work if we get a page fault while trying to access
the stack: the CPU will promote it to a double-fault and we'll die.
To avoid this problem, probe the new stack when switching stacks and
forcibly populate the pgd entry for the stack when switching mms.

Second, once we have guard pages around the stack, we'll want to
detect and handle stack overflow.

I didn't enable it on x86_32.  We'd need to rework the double-fault
code a bit and I'm concerned about running out of vmalloc virtual
addresses under some workloads.

This patch, by itself, will behave somewhat erratically when the
stack overflows while RSP is still more than a few tens of bytes
above the bottom of the stack.  Specifically, we'll get #PF and make
it to no_context and them oops without reliably triggering a
double-fault, and no_context doesn't know about stack overflows.
The next patch will improve that case.

Thank you to Nadav and Brian for helping me pay enough attention to
the SDM to hopefully get this right.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Nadav Amit 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/c88f3e2920b18e6cc621d772a04a62c06869037e.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig |  1 +
 arch/x86/include/asm/switch_to.h | 28 +-
 arch/x86/kernel/traps.c  | 61 
 arch/x86/mm/tlb.c| 15 ++
 4 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..21a6d0e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -94,6 +94,7 @@ config X86
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select HAVE_ARCH_WITHIN_STACK_FRAMES
select HAVE_EBPF_JITif X86_64
+   select HAVE_ARCH_VMAP_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8f321a1..14e4b20 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -8,6 +8,28 @@ struct tss_struct;
 void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
  struct tss_struct *tss);
 
+/* This runs runs on the previous thread's stack. */
+static inline void prepare_switch_to(struct task_struct *prev,
+struct task_struct *next)
+{
+#ifdef CONFIG_VMAP_STACK
+   /*
+* If we switch to a stack that has a top-level paging entry
+* that is not present in the current mm, the resulting #PF will
+* will be promoted to a double-fault and we'll panic.  Probe
+* the new stack now so that vmalloc_fault can fix up the page
+* tables if needed.  This can only happen if we use a stack
+* in vmap space.
+*
+* We assume that the stack is aligned so that it never spans
+* more than one top-level paging entry.
+*
+* To minimize cache pollution, just follow the stack pointer.
+*/
+   READ_ONCE(*(unsigned char *)next->thread.sp);
+#endif
+}
+
 #ifdef CONFIG_X86_32
 
 #ifdef CONFIG_CC_STACKPROTECTOR
@@ -39,6 +61,8 @@ do {  
\
 */ \
unsigned long ebx, ecx, edx, esi, edi;  \
\
+   prepare_switch_to(prev, next);  \
+   \
asm volatile("pushl %%ebp\n\t"  /* saveEBP   */ \
 "movl %%esp,%[prev_sp]\n\t"/* saveESP   */ \
 "movl %[next_sp],%%esp\n\t"/* restore ESP   */ \
@@ -103,7 +127,9 @@ do {
\
  * clean in kernel mode, with the possible exception of IOPL.  Kernel IOPL
  * has no effect.
  */
-#define switch_to(prev, next, last) \
+#define switch_to(prev, next, last) 

[tip:x86/asm] fork: Add generic vmalloced stack support

[tip-bot for Andy Lutomirski]

Commit-ID:  ba14a194a434ccc8f733e263ad2ce941e35e5787
Gitweb: http://git.kernel.org/tip/ba14a194a434ccc8f733e263ad2ce941e35e5787
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:21 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:41 +0200

fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK=y is selected, kernel stacks are allocated with
__vmalloc_node_range().

Grsecurity has had a similar feature (called GRKERNSEC_KSTACKOVERFLOW=y)
for a long time.

Signed-off-by: Andy Lutomirski 
Acked-by: Michal Hocko 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Dmitry Vyukov 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/14c07d4fd173a5b117f51e8b939f9f4323e39899.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 arch/Kconfig| 34 +
 arch/ia64/include/asm/thread_info.h |  2 +-
 include/linux/sched.h   | 15 ++
 kernel/fork.c   | 96 +
 4 files changed, 126 insertions(+), 21 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index e9c9334..9ecf9f6 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -707,4 +707,38 @@ config ARCH_NO_COHERENT_DMA_MMAP
 config CPU_NO_EFFICIENT_FFS
def_bool n
 
+config HAVE_ARCH_VMAP_STACK
+   def_bool n
+   help
+ An arch should select this symbol if it can support kernel stacks
+ in vmalloc space.  This means:
+
+ - vmalloc space must be large enough to hold many kernel stacks.
+   This may rule out many 32-bit architectures.
+
+ - Stacks in vmalloc space need to work reliably.  For example, if
+   vmap page tables are created on demand, either this mechanism
+   needs to work while the stack points to a virtual address with
+   unpopulated page tables or arch code (switch_to() and switch_mm(),
+   most likely) needs to ensure that the stack's page table entries
+   are populated before running on a possibly unpopulated stack.
+
+ - If the stack overflows into a guard page, something reasonable
+   should happen.  The definition of "reasonable" is flexible, but
+   instantly rebooting without logging anything would be unfriendly.
+
+config VMAP_STACK
+   default y
+   bool "Use a virtually-mapped stack"
+   depends on HAVE_ARCH_VMAP_STACK && !KASAN
+   ---help---
+ Enable this if you want the use virtually-mapped kernel stacks
+ with guard pages.  This causes kernel stack overflows to be
+ caught immediately rather than causing difficult-to-diagnose
+ corruption.
+
+ This is presently incompatible with KASAN because KASAN expects
+ the stack to map directly to the KASAN shadow map using a formula
+ that is incorrect if the stack is in vmalloc space.
+
 source "kernel/gcov/Kconfig"
diff --git a/arch/ia64/include/asm/thread_info.h 
b/arch/ia64/include/asm/thread_info.h
index 29bd597..c702642 100644
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -56,7 +56,7 @@ struct thread_info {
 #define alloc_thread_stack_node(tsk, node) ((unsigned long *) 0)
 #define task_thread_info(tsk)  ((struct thread_info *) 0)
 #endif
-#define free_thread_stack(ti)  /* nothing */
+#define free_thread_stack(tsk) /* nothing */
 #define task_stack_page(tsk)   ((void *)(tsk))
 
 #define __HAVE_THREAD_FUNCTIONS
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 62c68e5..20f9f47 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1923,6 +1923,9 @@ struct task_struct {
 #ifdef CONFIG_MMU
struct task_struct *oom_reaper_list;
 #endif
+#ifdef CONFIG_VMAP_STACK
+   struct vm_struct *stack_vm_area;
+#endif
 /* CPU-specific state of this task */
struct thread_struct thread;
 /*
@@ -1939,6 +1942,18 @@ extern int arch_task_struct_size __read_mostly;
 # define arch_task_struct_size (sizeof(struct task_struct))
 #endif
 
+#ifdef CONFIG_VMAP_STACK
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return t->stack_vm_area;
+}
+#else
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return NULL;
+}
+#endif
+
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
 #define tsk_cpus_allowed(tsk) (&(tsk)->cpus_allowed)
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 52e725d..9b85f6b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -158,19 +158,39 @@ void __weak arch_release_thread_stack(unsigned long 
*stack)
  * Allocate pages if THREAD_SIZE is >= PAGE_SIZE, otherwise use a
  * kmemcache based allocator.
  */
-# if THREAD_SIZE >= PAGE_SIZE
-static unsigned long *alloc_thread_stack_node(struct task_struct *tsk,
-  

[tip:x86/asm] ftrace: Only allocate the ret_stack 'fp' field when needed

[tip-bot for Josh Poimboeuf]

Commit-ID:  daa460a88c09b26b68e8b017de589c217e901afb
Gitweb: http://git.kernel.org/tip/daa460a88c09b26b68e8b017de589c217e901afb
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:56 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

ftrace: Only allocate the ret_stack 'fp' field when needed

This saves some memory when HAVE_FUNCTION_GRAPH_FP_TEST isn't defined.
On x86_64 with newer versions of gcc which have -mfentry, it saves 400
bytes per task.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/5c7747d9ea7b5cb47ef0a8ce8a6cea6bf7aa94bf.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 include/linux/ftrace.h   | 2 ++
 kernel/trace/trace_functions_graph.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 7d565af..4ad9ccc 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -795,7 +795,9 @@ struct ftrace_ret_stack {
unsigned long func;
unsigned long long calltime;
unsigned long long subtime;
+#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
unsigned long fp;
+#endif
 };
 
 /*
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index fc173cd..0e03ed0 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
current->ret_stack[index].func = func;
current->ret_stack[index].calltime = calltime;
current->ret_stack[index].subtime = 0;
+#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
current->ret_stack[index].fp = frame_pointer;
+#endif
*depth = current->curr_ret_stack;
 
return 0;

[tip:x86/asm] ftrace: Add return address pointer to ftrace_ret_stack

[tip-bot for Josh Poimboeuf]

Commit-ID:  9a7c348ba6a46f6270d4fe49577649dad5664fe7
Gitweb: http://git.kernel.org/tip/9a7c348ba6a46f6270d4fe49577649dad5664fe7
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:57 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

ftrace: Add return address pointer to ftrace_ret_stack

Storing this value will help prevent unwinders from getting out of sync
with the function graph tracer ret_stack.  Now instead of needing a
stateful iterator, they can compare the return address pointer to find
the right ret_stack entry.

Note that an array of 50 ftrace_ret_stack structs is allocated for every
task.  So when an arch implements this, it will add either 200 or 400
bytes of memory usage per task (depending on whether it's a 32-bit or
64-bit platform).

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/a95cfcc39e8f26b89a430c56926af0bb217bc0a1.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 Documentation/trace/ftrace-design.txt | 11 +++
 arch/arm/kernel/ftrace.c  |  2 +-
 arch/arm64/kernel/ftrace.c|  2 +-
 arch/blackfin/kernel/ftrace.c |  2 +-
 arch/microblaze/kernel/ftrace.c   |  2 +-
 arch/mips/kernel/ftrace.c |  4 ++--
 arch/parisc/kernel/ftrace.c   |  2 +-
 arch/powerpc/kernel/ftrace.c  |  3 ++-
 arch/s390/kernel/ftrace.c |  3 ++-
 arch/sh/kernel/ftrace.c   |  2 +-
 arch/sparc/kernel/ftrace.c|  2 +-
 arch/tile/kernel/ftrace.c |  2 +-
 arch/x86/kernel/ftrace.c  |  2 +-
 include/linux/ftrace.h|  5 -
 kernel/trace/trace_functions_graph.c  |  5 -
 15 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/Documentation/trace/ftrace-design.txt 
b/Documentation/trace/ftrace-design.txt
index dd5f916..a273dd0 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -203,6 +203,17 @@ along to ftrace_push_return_trace() instead of a stub 
value of 0.
 
 Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.
 
+HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+
+
+An arch may pass in a pointer to the return address on the stack.  This
+prevents potential stack unwinding issues where the unwinder gets out of
+sync with ret_stack and the wrong addresses are reported by
+ftrace_graph_ret_addr().
+
+Adding support for it is easy: just define the macro in asm/ftrace.h and
+pass the return address pointer as the 'retp' argument to
+ftrace_push_return_trace().
 
 HAVE_FTRACE_NMI_ENTER
 -
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 709ee1d..3f17594 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -218,7 +218,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
}
 
err = ftrace_push_return_trace(old, self_addr, &trace.depth,
-  frame_pointer);
+  frame_pointer, NULL);
if (err == -EBUSY) {
*parent = old;
return;
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index ebecf9a..40ad08a 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -138,7 +138,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
return;
 
err = ftrace_push_return_trace(old, self_addr, &trace.depth,
-  frame_pointer);
+  frame_pointer, NULL);
if (err == -EBUSY)
return;
else
diff --git a/arch/blackfin/kernel/ftrace.c b/arch/blackfin/kernel/ftrace.c
index 095de0f..8dad758 100644
--- a/arch/blackfin/kernel/ftrace.c
+++ b/arch/blackfin/kernel/ftrace.c
@@ -107,7 +107,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
return;
 
if (ftrace_push_return_trace(*parent, self_addr, &trace.depth,
-frame_pointer) == -EBUSY)
+frame_pointer, NULL) == -EBUSY)
return;
 
trace.func = self_addr;
diff --git a/arch/microblaze/kernel/ftrace.c b/arch/microblaze/kernel/ftrace.c
index fc7b48a..d57563c 100644
--- a/arch/microblaze/kernel/ftrace.c
+++ b/arch/microblaze/kernel/ftrace.c
@@ -63,7 +63,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr)
return;
}
 
-   err = ftrace_push_return_trace(old, self_addr, &trace.depth, 0);
+   err = ftrace_push_return_trace(old, self

[tip:x86/asm] ftrace: Remove CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST from config

[tip-bot for Josh Poimboeuf]

Commit-ID:  e4a744ef2fef5c803348b650a3a2d01da7797a9b
Gitweb: http://git.kernel.org/tip/e4a744ef2fef5c803348b650a3a2d01da7797a9b
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:55 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:13 +0200

ftrace: Remove CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST from config

Make HAVE_FUNCTION_GRAPH_FP_TEST a normal define, independent from
kconfig.  This removes some config file pollution and simplifies the
checking for the fp test.

Suggested-by: Steven Rostedt 
Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/2c4e5f05054d6d367f702fd153af7a0109dd5c81.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/arm64/kernel/entry-ftrace.S | 2 +-
 arch/blackfin/kernel/ftrace-entry.S  | 4 ++--
 arch/sparc/Kconfig   | 1 -
 arch/sparc/include/asm/ftrace.h  | 4 
 arch/x86/Kconfig | 1 -
 arch/x86/include/asm/ftrace.h| 1 +
 kernel/trace/Kconfig | 5 -
 kernel/trace/trace_functions_graph.c | 2 +-
 8 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 0f03a8f..aef02d2 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -219,7 +219,7 @@ ENDPROC(ftrace_graph_caller)
  *
  * Run ftrace_return_to_handler() before going back to parent.
  * @fp is checked against the value passed by ftrace_graph_caller()
- * only when CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
+ * only when HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
  */
 ENTRY(return_to_handler)
save_return_regs
diff --git a/arch/blackfin/kernel/ftrace-entry.S 
b/arch/blackfin/kernel/ftrace-entry.S
index 28d0595..3b8bdcb 100644
--- a/arch/blackfin/kernel/ftrace-entry.S
+++ b/arch/blackfin/kernel/ftrace-entry.S
@@ -169,7 +169,7 @@ ENTRY(_ftrace_graph_caller)
r0 = sp;/* unsigned long *parent */
r1 = [sp];  /* unsigned long self_addr */
 # endif
-# ifdef CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST
+# ifdef HAVE_FUNCTION_GRAPH_FP_TEST
r2 = fp;/* unsigned long frame_pointer */
 # endif
r0 += 16;   /* skip the 4 local regs on stack */
@@ -190,7 +190,7 @@ ENTRY(_return_to_handler)
[--sp] = r1;
 
/* get original return address */
-# ifdef CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST
+# ifdef HAVE_FUNCTION_GRAPH_FP_TEST
r0 = fp;/* Blackfin is sane, so omit this */
 # endif
call _ftrace_return_to_handler;
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 59b0960..f5d60f1 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -56,7 +56,6 @@ config SPARC64
def_bool 64BIT
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
-   select HAVE_FUNCTION_GRAPH_FP_TEST
select HAVE_KRETPROBES
select HAVE_KPROBES
select HAVE_RCU_TABLE_FREE if SMP
diff --git a/arch/sparc/include/asm/ftrace.h b/arch/sparc/include/asm/ftrace.h
index 3192a8e..62755a3 100644
--- a/arch/sparc/include/asm/ftrace.h
+++ b/arch/sparc/include/asm/ftrace.h
@@ -9,6 +9,10 @@
 void _mcount(void);
 #endif
 
+#endif /* CONFIG_MCOUNT */
+
+#if defined(CONFIG_SPARC64) && !defined(CC_USE_FENTRY)
+#define HAVE_FUNCTION_GRAPH_FP_TEST
 #endif
 
 #ifdef CONFIG_DYNAMIC_FTRACE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21a6d0e..ce8860c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -111,7 +111,6 @@ config X86
select HAVE_EXIT_THREAD
select HAVE_FENTRY  if X86_64
select HAVE_FTRACE_MCOUNT_RECORD
-   select HAVE_FUNCTION_GRAPH_FP_TEST
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index a4820d4..37f67cb 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -6,6 +6,7 @@
 # define MCOUNT_ADDR   ((unsigned long)(__fentry__))
 #else
 # define MCOUNT_ADDR   ((unsigned long)(mcount))
+# define HAVE_FUNCTION_GRAPH_FP_TEST
 #endif
 #define MCOUNT_INSN_SIZE   5 /* sizeof mcount call */
 
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index f4b86e8..ba33267 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -24,11 +24,6 @@ config HAVE_FUNCTION_GRAPH_TRACER
help
  See Documentation/trace/ftrace-design.txt
 
-config HAVE_FUNCTION_GRAPH_FP_TEST
-   bool
-   help
- See Documentation/trace/ftrace-design.txt
-
 config HAVE_DYNAMIC_FTRACE
bool
help
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace

Re: [PATCH v2] pwm: add pwm driver for HiSilicon BVT SOCs

[Thierry Reding]

On Mon, Aug 22, 2016 at 03:50:13PM +0800, Jian Yuan wrote:
> From: yuanjian 
> 
> Add pwm driver for HiSilicon BVT SOCs

pwm -> PWM, please. It'd be good to have more information here about
what the hardware can do, where to find it, etc.

> 
> Reviewed-by: Jiancheng Xue 
> Signed-off-by: Jian Yuan 
> ---
> Change Log:
> v2:
> The number of PWMs is change to be probeable based on the compatible string.
> 
>  .../devicetree/bindings/pwm/pwm-hibvt.txt  |  18 ++
>  drivers/pwm/Kconfig|  10 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-hibvt.c| 274 
> +
>  4 files changed, 303 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
>  create mode 100644 drivers/pwm/pwm-hibvt.c
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> new file mode 100644
> index 000..1274119
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> @@ -0,0 +1,18 @@
> +Hisilicon PWM controller
> +
> +Required properties:
> +-compatible: should contain one soc specific compatible string and one 
> generic compatible
> +string "hisilicon, hibvt-pwm". The soc specific strings supported including:

Why the generic compatible string? You've already shown in the driver
that the two versions you support aren't compatible.

Also soc -> SoC, please.

> + "hisilicon,hi3516cv300-pwm"
> +- reg: physical base address and length of the controller's registers.
> +- clocks: phandle and clock specifier of the PWM reference clock.
> +- resets: offset address and offset bit for reset or unreset of the 
> controller.

That's weird. Usually this should say just that the property should
contain the phandle plus a reset specifier for the controller reset. The
above description already defines what the specifier looks like, which
may not be true on all SoCs that this hardware gets integrated into.

> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index c182efc..3c48768 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -158,6 +158,15 @@ config PWM_FSL_FTM
> To compile this driver as a module, choose M here: the module
> will be called pwm-fsl-ftm.
>  
> +config PWM_HIBVT
> + tristate "HiSilicon BVT PWM support"
> + depends on ARCH_HISI
> + help
> +   Generic PWM framework driver for hisilicon BVT SOCs.

Please use a consistent spelling for HiSilicon. Also: SOC -> SoC.

> @@ -438,4 +447,5 @@ config PWM_VT8500
> To compile this driver as a module, choose M here: the module
> will be called pwm-vt8500.
>  
> +

Please don't add this extra blank line.

> diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
[...]
> new file mode 100644
> index 000..84f617e
> --- /dev/null
> +++ b/drivers/pwm/pwm-hibvt.c
> @@ -0,0 +1,274 @@
> +/*
> + * PWM Controller Driver for HiSilicon BVT SOCs
> + *
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PWM_CFG0_ADDR(x)(((x) * 0x20) + 0x0)
> +#define PWM_CFG1_ADDR(x)(((x) * 0x20) + 0x4)
> +#define PWM_CFG2_ADDR(x)(((x) * 0x20) + 0x8)
> +#define PWM_CTRL_ADDR(x)(((x) * 0x20) + 0xC)
> +
> +#define PWM_ENABLE_SHIFT0
> +#define PWM_ENABLE_MASK  BIT(0)
> +
> +#define PWM_POLARITY_SHIFT   1
> +#define PWM_POLARITY_MASKBIT(1)
> +
> +#define PWM_KEEP_SHIFT   2
> +#define PWM_KEEP_MASKBIT(2)
> +
> +#define PWM_PERIOD_MASK  GENMASK(31, 0)
> +#define PWM_DUTY_MASKGENMASK(31, 0)

There's inconsistent padding in the above. I thought checkpatch warned
about this nowadays.

> +
> +struct hibvt_pwm_chip {
> + struct pwm_chip chip;
> + struct clk  *clk;
> + void __iomem*mmio_base;
> + struct reset_control *rstc;
> +};

No artificial padding with tabs above. A single space between type and
variable name is good enough. Also why the extra mmio_ prefix for the
I/O memory base address? You use the much shorter "base" for variables
elsewhere, why not in this structure?

> +
> +static int p

[tip:x86/asm] ftrace: Add ftrace_graph_ret_addr() stack unwinding helpers

[tip-bot for Josh Poimboeuf]

Commit-ID:  223918e32a87c79ac55ca4aa513ba405ba4d57cd
Gitweb: http://git.kernel.org/tip/223918e32a87c79ac55ca4aa513ba405ba4d57cd
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:58 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

ftrace: Add ftrace_graph_ret_addr() stack unwinding helpers

When function graph tracing is enabled for a function, ftrace modifies
the stack by replacing the original return address with the address of a
hook function (return_to_handler).

Stack unwinders need a way to get the original return address.  Add an
arch-independent helper function for that named ftrace_graph_ret_addr().

This adds two variations of the function: one depends on
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, and the other relies on an index state
variable.

The former is recommended because, in some cases, the latter can cause
problems when the unwinder skips stack frames.  It can get out of sync
with the ret_stack index and wrong addresses can be reported for the
stack trace.

Once all arches have been ported to use
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, we can get rid of the distinction.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/36bd90f762fc5e5af3929e3797a68a64906421cf.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 include/linux/ftrace.h   | 10 +++
 kernel/trace/trace_functions_graph.c | 58 
 2 files changed, 68 insertions(+)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 483e02a..6f93ac4 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -814,6 +814,9 @@ extern int
 ftrace_push_return_trace(unsigned long ret, unsigned long func, int *depth,
 unsigned long frame_pointer, unsigned long *retp);
 
+unsigned long ftrace_graph_ret_addr(struct task_struct *task, int *idx,
+   unsigned long ret, unsigned long *retp);
+
 /*
  * Sometimes we don't want to trace a function with the function
  * graph tracer but we want them to keep traced by the usual function
@@ -875,6 +878,13 @@ static inline int task_curr_ret_stack(struct task_struct 
*tsk)
return -1;
 }
 
+static inline unsigned long
+ftrace_graph_ret_addr(struct task_struct *task, int *idx, unsigned long ret,
+ unsigned long *retp)
+{
+   return ret;
+}
+
 static inline void pause_graph_tracing(void) { }
 static inline void unpause_graph_tracing(void) { }
 #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index f7212ec..0cbe38a 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -284,6 +284,64 @@ unsigned long ftrace_return_to_handler(unsigned long 
frame_pointer)
return ret;
 }
 
+/**
+ * ftrace_graph_ret_addr - convert a potentially modified stack return address
+ *to its original value
+ *
+ * This function can be called by stack unwinding code to convert a found stack
+ * return address ('ret') to its original value, in case the function graph
+ * tracer has modified it to be 'return_to_handler'.  If the address hasn't
+ * been modified, the unchanged value of 'ret' is returned.
+ *
+ * 'idx' is a state variable which should be initialized by the caller to zero
+ * before the first call.
+ *
+ * 'retp' is a pointer to the return address on the stack.  It's ignored if
+ * the arch doesn't have HAVE_FUNCTION_GRAPH_RET_ADDR_PTR defined.
+ */
+#ifdef HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+unsigned long ftrace_graph_ret_addr(struct task_struct *task, int *idx,
+   unsigned long ret, unsigned long *retp)
+{
+   int index = task->curr_ret_stack;
+   int i;
+
+   if (ret != (unsigned long)return_to_handler)
+   return ret;
+
+   if (index < -1)
+   index += FTRACE_NOTRACE_DEPTH;
+
+   if (index < 0)
+   return ret;
+
+   for (i = 0; i <= index; i++)
+   if (task->ret_stack[i].retp == retp)
+   return task->ret_stack[i].ret;
+
+   return ret;
+}
+#else /* !HAVE_FUNCTION_GRAPH_RET_ADDR_PTR */
+unsigned long ftrace_graph_ret_addr(struct task_struct *task, int *idx,
+   unsigned long ret, unsigned long *retp)
+{
+   int task_idx;
+
+   if (ret != (unsigned long)return_to_handler)
+   return ret;
+
+   task_idx = task->curr_ret_stack;
+
+   if (!task->ret_stack || task_idx < *idx)
+   return ret;
+
+   task_idx -= *idx;
+   (*idx)++;
+
+   return task->ret_stack[task_idx].ret;
+}
+#endif

[tip:x86/asm] sched/x86: Add 'struct inactive_task_frame' to better document the sleeping task stack frame

[tip-bot for Brian Gerst]

Commit-ID:  7b32aeadbc95d4a41402c1c0da6aa3ab51af4c10
Gitweb: http://git.kernel.org/tip/7b32aeadbc95d4a41402c1c0da6aa3ab51af4c10
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:18 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:41 +0200

sched/x86: Add 'struct inactive_task_frame' to better document the sleeping 
task stack frame

Add 'struct inactive_task_frame', which defines the layout of the stack for
a sleeping process.  For now, the only defined field is the BP register
(frame pointer).

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-4-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/stacktrace.h | 4 ++--
 arch/x86/include/asm/switch_to.h  | 5 +
 arch/x86/kernel/kgdb.c| 3 ++-
 arch/x86/kernel/process.c | 3 ++-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/stacktrace.h 
b/arch/x86/include/asm/stacktrace.h
index 0944218..7646fb2 100644
--- a/arch/x86/include/asm/stacktrace.h
+++ b/arch/x86/include/asm/stacktrace.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 extern int kstack_depth_to_print;
 
@@ -70,8 +71,7 @@ stack_frame(struct task_struct *task, struct pt_regs *regs)
return bp;
}
 
-   /* bp is the last reg pushed by switch_to */
-   return *(unsigned long *)task->thread.sp;
+   return ((struct inactive_task_frame *)task->thread.sp)->bp;
 }
 #else
 static inline unsigned long
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 14e4b20..ec689c6 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -30,6 +30,11 @@ static inline void prepare_switch_to(struct task_struct 
*prev,
 #endif
 }
 
+/* data that is pointed to by thread.sp */
+struct inactive_task_frame {
+   unsigned long bp;
+};
+
 #ifdef CONFIG_X86_32
 
 #ifdef CONFIG_CC_STACKPROTECTOR
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 5e3f294..8e36f24 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] =
 {
@@ -166,7 +167,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_DX]= 0;
gdb_regs[GDB_SI]= 0;
gdb_regs[GDB_DI]= 0;
-   gdb_regs[GDB_BP]= *(unsigned long *)p->thread.sp;
+   gdb_regs[GDB_BP]= ((struct inactive_task_frame 
*)p->thread.sp)->bp;
 #ifdef CONFIG_X86_32
gdb_regs[GDB_DS]= __KERNEL_DS;
gdb_regs[GDB_ES]= __KERNEL_DS;
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 62c0b0e..0115a4a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -556,7 +557,7 @@ unsigned long get_wchan(struct task_struct *p)
if (sp < bottom || sp > top)
return 0;
 
-   fp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
+   fp = READ_ONCE_NOCHECK(((struct inactive_task_frame *)sp)->bp);
do {
if (fp < bottom || fp > top)
return 0;

[tip:x86/asm] ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

[tip-bot for Josh Poimboeuf]

Commit-ID:  471bd10f5e2880bd91a2627d887f6062494cfe9c
Gitweb: http://git.kernel.org/tip/471bd10f5e2880bd91a2627d887f6062494cfe9c
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:00 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

Use the more reliable version of ftrace_graph_ret_addr() so we no longer
have to worry about the unwinder getting out of sync with the function
graph ret_stack index, which can happen if the unwinder skips any frames
before calling ftrace_graph_ret_addr().

This fixes this issue (and several others like it):

  $ cat /proc/self/stack
  [] save_stack_trace_tsk+0x22/0x40
  [] proc_pid_stack+0xb9/0x110
  [] proc_single_show+0x54/0x80
  [] seq_read+0x108/0x3e0
  [] __vfs_read+0x37/0x140
  [] vfs_read+0x99/0x140
  [] SyS_read+0x58/0xc0
  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
  [] 0x

  $ echo function_graph > /sys/kernel/debug/tracing/current_tracer

  $ cat /proc/self/stack
  [] return_to_handler+0x0/0x27
  [] print_context_stack+0xfc/0x100
  [] return_to_handler+0x0/0x27
  [] dump_trace+0x12b/0x350
  [] return_to_handler+0x0/0x27
  [] save_stack_trace_tsk+0x22/0x40
  [] return_to_handler+0x0/0x27
  [] proc_pid_stack+0xb9/0x110
  [] return_to_handler+0x0/0x27
  [] proc_single_show+0x54/0x80
  [] return_to_handler+0x0/0x27
  [] seq_read+0x108/0x3e0
  [] return_to_handler+0x0/0x27
  [] __vfs_read+0x37/0x140
  [] return_to_handler+0x0/0x27
  [] vfs_read+0x99/0x140
  [] 0x

Enabling function graph tracing causes the stack trace to change in two
ways:

First, the real call addresses are confusingly interspersed with
'return_to_handler' addresses.  This issue will be fixed by the next
patch.

Second, the stack trace is offset by two frames, because the unwinder
skipped the first two frames and got out of sync with the ret_stack
index.  This patch fixes this issue.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/a6d623e36f8d08f9a17bd74d804d201177a23afd.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/ftrace.h | 2 ++
 arch/x86/kernel/ftrace.c  | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 37f67cb..eccd0ac 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -14,6 +14,8 @@
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #endif
 
+#define HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+
 #ifndef __ASSEMBLY__
 extern void mcount(void);
 extern atomic_t modifying_ftrace_code;
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index ae3b1fb..8639bb2 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -1029,7 +1029,7 @@ void prepare_ftrace_return(unsigned long self_addr, 
unsigned long *parent,
}
 
if (ftrace_push_return_trace(old, self_addr, &trace.depth,
-frame_pointer, NULL) == -EBUSY) {
+frame_pointer, parent) == -EBUSY) {
*parent = old;
return;
}

[tip:x86/asm] sched/x86: Pass kernel thread parameters in 'struct fork_frame'

[tip-bot for Brian Gerst]

Commit-ID:  616d24835eeafa8ef3466479db028abfdfc77531
Gitweb: http://git.kernel.org/tip/616d24835eeafa8ef3466479db028abfdfc77531
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:20 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:50 +0200

sched/x86: Pass kernel thread parameters in 'struct fork_frame'

Instead of setting up a fake pt_regs context, put the kernel thread
function pointer and arg into the unused callee-restored registers
of 'struct fork_frame'.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-6-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S| 31 +++
 arch/x86/entry/entry_64.S| 37 +
 arch/x86/include/asm/switch_to.h |  2 ++
 arch/x86/kernel/process_32.c | 18 --
 arch/x86/kernel/process_64.c | 12 +++-
 5 files changed, 41 insertions(+), 59 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index bf8f221..b75a8bc 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -240,35 +240,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * eax: prev task we switched from
+ * ebx: kernel thread func (NULL for user thread)
+ * edi: kernel thread arg
  */
 ENTRY(ret_from_fork)
pushl   %eax
callschedule_tail
popl%eax
 
+   testl   %ebx, %ebx
+   jnz 1f  /* kernel threads are uncommon */
+
+2:
/* When we fork, we trace the syscall return in the child, too. */
movl%esp, %eax
callsyscall_return_slowpath
jmp restore_all
-END(ret_from_fork)
-
-ENTRY(ret_from_kernel_thread)
-   pushl   %eax
-   callschedule_tail
-   popl%eax
-   movlPT_EBP(%esp), %eax
-   call*PT_EBX(%esp)
-   movl$0, PT_EAX(%esp)
 
+   /* kernel thread */
+1: movl%edi, %eax
+   call*%ebx
/*
-* Kernel threads return to userspace as if returning from a syscall.
-* We should check whether anything actually uses this path and, if so,
-* consider switching it over to ret_from_fork.
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete the execve()
+* syscall.
 */
-   movl%esp, %eax
-   callsyscall_return_slowpath
-   jmp restore_all
-ENDPROC(ret_from_kernel_thread)
+   movl$0, PT_EAX(%esp)
+   jmp 2b
+END(ret_from_fork)
 
 /*
  * Return to user mode is not as complex as all this looks,
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c1af8ac..c0373d6 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -407,37 +407,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * rax: prev task we switched from
+ * rbx: kernel thread func (NULL for user thread)
+ * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
-   testb   $3, CS(%rsp)/* from kernel_thread? */
-   jnz 1f
-
-   /*
-* We came from kernel_thread.  This code path is quite twisted, and
-* someone should clean it up.
-*
-* copy_thread_tls stashes the function pointer in RBX and the
-* parameter to be passed in RBP.  The called function is permitted
-* to call do_execve and thereby jump to user mode.
-*/
-   movqRBP(%rsp), %rdi
-   call*RBX(%rsp)
-   movl$0, RAX(%rsp)
-
-   /*
-* Fall through as though we're exiting a syscall.  This makes a
-* twisted sort of sense if we just called do_execve.
-*/
+   testq   %rbx, %rbx  /* from kernel_thread? */
+   jnz 1f  /* kernel threads are uncommon 
*/
 
-1:
+2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
TRACE_IRQS_ON   /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
+
+1:
+   /* kernel thread */
+   movq%r12, %rdi
+   call*%rbx
+   /*
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete the execve()
+* syscall.
+*/
+   movq$0, RAX(%rsp)
+   jmp 2b
 END(ret_from_fork)
 
 /*
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 886d5ea..5cb436a 100644
--- a/a

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

[Eric Dumazet]

On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote:
> Initially, a NAPI TX routine has been implemented separately from
> NAPI RX, as done on the freescale/gianfar driver.
> 
> By merging NAPI RX and NAPI TX, we reduce the amount of TX completion
> interrupts.
> 
> Handling of the budget in association with TX interrupts is based on
> indications provided at https://wiki.linuxfoundation.org/networking/napi
> 
> At the same time, we fix an issue in the handling of fep->tx_free:
> 
> It is only when fep->tx_free goes up to MAX_SKB_FRAGS that
> we need to wake up the queue. There is no need to call
> netif_wake_queue() at every packet successfully transmitted.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  .../net/ethernet/freescale/fs_enet/fs_enet-main.c  | 259 
> +
>  drivers/net/ethernet/freescale/fs_enet/fs_enet.h   |  16 +-
>  drivers/net/ethernet/freescale/fs_enet/mac-fcc.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-fec.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-scc.c   |  57 ++---
>  5 files changed, 153 insertions(+), 293 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
> b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> index 61fd486..7cd3ef9 100644
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -79,8 +79,8 @@ static void skb_align(struct sk_buff *skb, int align)
>   skb_reserve(skb, align - off);
>  }
>  
> -/* NAPI receive function */
> -static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
> +/* NAPI function */
> +static int fs_enet_napi(struct napi_struct *napi, int budget)
>  {
>   struct fs_enet_private *fep = container_of(napi, struct 
> fs_enet_private, napi);
>   struct net_device *dev = fep->ndev;
> @@ -90,9 +90,100 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int 
> budget)
>   int received = 0;
>   u16 pkt_len, sc;
>   int curidx;
> + int dirtyidx, do_wake, do_restart;
>  
> - if (budget <= 0)
> - return received;
> + spin_lock(&fep->tx_lock);
> + bdp = fep->dirty_tx;
> +
> + /* clear status bits for napi*/
> + (*fep->ops->napi_clear_event)(dev);
> +
> + do_wake = do_restart = 0;
> + while (((sc = CBDR_SC(bdp)) & BD_ENET_TX_READY) == 0) {

I am afraid you could live lock here on SMP.

You should make sure you do not loop forever, not assuming cpu is faster
than NIC.



> + dirtyidx = bdp - fep->tx_bd_base;
> +
> + if (fep->tx_free == fep->tx_ring)
> + break;
> +
> + skb = fep->tx_skbuff[dirtyidx];
> +
> + /*
> +  * Check for errors.
> +  */
> + if (sc & (BD_ENET_TX_HB | BD_ENET_TX_LC |
> +   BD_ENET_TX_RL | BD_ENET_TX_UN | BD_ENET_TX_CSL)) {
> +
> + if (sc & BD_ENET_TX_HB) /* No heartbeat */
> + fep->stats.tx_heartbeat_errors++;
> + if (sc & BD_ENET_TX_LC) /* Late collision */
> + fep->stats.tx_window_errors++;
> + if (sc & BD_ENET_TX_RL) /* Retrans limit */
> + fep->stats.tx_aborted_errors++;
> + if (sc & BD_ENET_TX_UN) /* Underrun */
> + fep->stats.tx_fifo_errors++;
> + if (sc & BD_ENET_TX_CSL)/* Carrier lost */
> + fep->stats.tx_carrier_errors++;
> +
> + if (sc & (BD_ENET_TX_LC | BD_ENET_TX_RL | 
> BD_ENET_TX_UN)) {
> + fep->stats.tx_errors++;
> + do_restart = 1;
> + }
> + } else
> + fep->stats.tx_packets++;
> +
> + if (sc & BD_ENET_TX_READY) {
> + dev_warn(fep->dev,
> +  "HEY! Enet xmit interrupt and TX_READY.\n");
> + }
> +
> + /*
> +  * Deferred means some collisions occurred during transmit,
> +  * but we eventually sent the packet OK.
> +  */
> + if (sc & BD_ENET_TX_DEF)
> + fep->stats.collisions++;
> +
> + /* unmap */
> + if (fep->mapped_as_page[dirtyidx])
> + dma_unmap_page(fep->dev, CBDR_BUFADDR(bdp),
> +CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> + else
> + dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
> +  CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> +
> + /*
> +  * Free the sk buffer associated with this last transmit.
> +  */
> + if (skb) {
> + dev_kfree_skb(skb);
> + fep->tx_skbuff[dirtyidx] = NULL;
> + }
> +
> +   

[tip:x86/asm] sched/x86: Rewrite the switch_to() code

[tip-bot for Brian Gerst]

Commit-ID:  0100301bfdf56a2a370c7157b5ab0fbf9313e1cd
Gitweb: http://git.kernel.org/tip/0100301bfdf56a2a370c7157b5ab0fbf9313e1cd
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:19 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:41 +0200

sched/x86: Rewrite the switch_to() code

Move the low-level context switch code to an out-of-line asm stub instead of
using complex inline asm.  This allows constructing a new stack frame for the
child process to make it seamlessly flow to ret_from_fork without an extra
test and branch in __switch_to().  It also improves code generation for
__schedule() by using the C calling convention instead of clobbering all
registers.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-5-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S  |  37 ++
 arch/x86/entry/entry_64.S  |  41 ++-
 arch/x86/include/asm/processor.h   |   3 -
 arch/x86/include/asm/switch_to.h   | 139 ++---
 arch/x86/include/asm/thread_info.h |   2 -
 arch/x86/kernel/asm-offsets.c  |   6 ++
 arch/x86/kernel/asm-offsets_32.c   |   5 ++
 arch/x86/kernel/asm-offsets_64.c   |   5 ++
 arch/x86/kernel/process_32.c   |   9 ++-
 arch/x86/kernel/process_64.c   |   9 ++-
 arch/x86/kernel/smpboot.c  |   1 -
 11 files changed, 125 insertions(+), 132 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 0b5..bf8f221 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -204,6 +204,43 @@
POP_GS_EX
 .endm
 
+/*
+ * %eax: prev task
+ * %edx: next task
+ */
+ENTRY(__switch_to_asm)
+   /*
+* Save callee-saved registers
+* This must match the order in struct inactive_task_frame
+*/
+   pushl   %ebp
+   pushl   %ebx
+   pushl   %edi
+   pushl   %esi
+
+   /* switch stack */
+   movl%esp, TASK_threadsp(%eax)
+   movlTASK_threadsp(%edx), %esp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+   movlTASK_stack_canary(%edx), %ebx
+   movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
+#endif
+
+   /* restore callee-saved registers */
+   popl%esi
+   popl%edi
+   popl%ebx
+   popl%ebp
+
+   jmp __switch_to
+END(__switch_to_asm)
+
+/*
+ * A newly forked process directly context switches into this address.
+ *
+ * eax: prev task we switched from
+ */
 ENTRY(ret_from_fork)
pushl   %eax
callschedule_tail
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index f6b40e5..c1af8ac 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -368,13 +368,48 @@ END(ptregs_\func)
 #include 
 
 /*
+ * %rdi: prev task
+ * %rsi: next task
+ */
+ENTRY(__switch_to_asm)
+   /*
+* Save callee-saved registers
+* This must match the order in inactive_task_frame
+*/
+   pushq   %rbp
+   pushq   %rbx
+   pushq   %r12
+   pushq   %r13
+   pushq   %r14
+   pushq   %r15
+
+   /* switch stack */
+   movq%rsp, TASK_threadsp(%rdi)
+   movqTASK_threadsp(%rsi), %rsp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+   movqTASK_stack_canary(%rsi), %rbx
+   movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+#endif
+
+   /* restore callee-saved registers */
+   popq%r15
+   popq%r14
+   popq%r13
+   popq%r12
+   popq%rbx
+   popq%rbp
+
+   jmp __switch_to
+END(__switch_to_asm)
+
+/*
  * A newly forked process directly context switches into this address.
  *
- * rdi: prev task we switched from
+ * rax: prev task we switched from
  */
 ENTRY(ret_from_fork)
-   LOCK ; btr $TIF_FORK, TI_flags(%r8)
-
+   movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
testb   $3, CS(%rsp)/* from kernel_thread? */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 63def95..6fee863 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -389,9 +389,6 @@ struct thread_struct {
unsigned short  fsindex;
unsigned short  gsindex;
 #endif
-#ifdef CONFIG_X86_32
-   unsigned long   ip;
-#endif
 #ifdef CONFIG_X86_64
unsigned long   fsbase;
unsigned long   gsbase;
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index ec689c6..886d5ea 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -2,8 +2,12 @@
 #define _ASM_X86_SWITCH_TO_H
 
 struct task_struct; /* one of the stranger aspects of C forward d

[tip:x86/asm] sched/x86: Fix thread_saved_pc()

[tip-bot for Brian Gerst]

Commit-ID:  ffcb043ba524d3fbd979a9dac2c9ce8ad352000d
Gitweb: http://git.kernel.org/tip/ffcb043ba524d3fbd979a9dac2c9ce8ad352000d
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:21 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:51 +0200

sched/x86: Fix thread_saved_pc()

thread_saved_pc() was using a completely bogus method to get the return
address.  Since switch_to() was previously inlined, there was no sane way
to know where on the stack the return address was stored.  Now with the
frame of a sleeping thread well defined, this can be implemented correctly.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-7-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/processor.h | 10 ++
 arch/x86/kernel/process.c| 11 +++
 arch/x86/kernel/process_32.c |  8 
 3 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 6fee863..b22fb5a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -721,8 +721,6 @@ static inline void spin_lock_prefetch(const void *x)
.addr_limit = KERNEL_DS,  \
 }
 
-extern unsigned long thread_saved_pc(struct task_struct *tsk);
-
 /*
  * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack.
  * This is necessary to guarantee that the entire "struct pt_regs"
@@ -773,17 +771,13 @@ extern unsigned long thread_saved_pc(struct task_struct 
*tsk);
.addr_limit = KERNEL_DS,\
 }
 
-/*
- * Return saved PC of a blocked thread.
- * What is this good for? it will be always the scheduler or ret_from_fork.
- */
-#define thread_saved_pc(t) READ_ONCE_NOCHECK(*(unsigned long 
*)((t)->thread.sp - 8))
-
 #define task_pt_regs(tsk)  ((struct pt_regs *)(tsk)->thread.sp0 - 1)
 extern unsigned long KSTK_ESP(struct task_struct *task);
 
 #endif /* CONFIG_X86_64 */
 
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
 extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
   unsigned long new_sp);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 0115a4a..c1fa790 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -514,6 +514,17 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 }
 
 /*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+unsigned long thread_saved_pc(struct task_struct *tsk)
+{
+   struct inactive_task_frame *frame =
+   (struct inactive_task_frame *) READ_ONCE(tsk->thread.sp);
+   return READ_ONCE_NOCHECK(frame->ret_addr);
+}
+
+/*
  * Called from fs/proc with a reference on @p to find the function
  * which called into schedule(). This needs to be done carefully
  * because the task might wake up and we might look at a stack
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 18714a1..404efdf 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -55,14 +55,6 @@
 #include 
 #include 
 
-/*
- * Return saved PC of a blocked thread.
- */
-unsigned long thread_saved_pc(struct task_struct *tsk)
-{
-   return ((unsigned long *)tsk->thread.sp)[3];
-}
-
 void __show_regs(struct pt_regs *regs, int all)
 {
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;

[PATCH] pstore/core: drop cmpxchg based updates

[Sebastian Andrzej Siewior]

I have here a FPGA behind PCIe which exports SRAM which I use for
pstore. Now it seems that the FPGA no longer supports cmpxchg based
updates and writes back 0xff…ff and returns the same.  This leads to
crash during crash rendering pstore useless.
Since I doubt that there is much benefit from using cmpxchg() here, I am
dropping this atomic access and use the spinlock based version.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Signed-off-by: Sebastian Andrzej Siewior 
---
 fs/pstore/ram_core.c | 43 ++-
 1 file changed, 2 insertions(+), 41 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 76c3f80efdfa..4bae54bb61cd 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -47,39 +47,6 @@ static inline size_t buffer_start(struct persistent_ram_zone 
*prz)
return atomic_read(&prz->buffer->start);
 }
 
-/* increase and wrap the start pointer, returning the old value */
-static size_t buffer_start_add_atomic(struct persistent_ram_zone *prz, size_t 
a)
-{
-   int old;
-   int new;
-
-   do {
-   old = atomic_read(&prz->buffer->start);
-   new = old + a;
-   while (unlikely(new >= prz->buffer_size))
-   new -= prz->buffer_size;
-   } while (atomic_cmpxchg(&prz->buffer->start, old, new) != old);
-
-   return old;
-}
-
-/* increase the size counter until it hits the max size */
-static void buffer_size_add_atomic(struct persistent_ram_zone *prz, size_t a)
-{
-   size_t old;
-   size_t new;
-
-   if (atomic_read(&prz->buffer->size) == prz->buffer_size)
-   return;
-
-   do {
-   old = atomic_read(&prz->buffer->size);
-   new = old + a;
-   if (new > prz->buffer_size)
-   new = prz->buffer_size;
-   } while (atomic_cmpxchg(&prz->buffer->size, old, new) != old);
-}
-
 static DEFINE_RAW_SPINLOCK(buffer_lock);
 
 /* increase and wrap the start pointer, returning the old value */
@@ -124,9 +91,6 @@ static void buffer_size_add_locked(struct 
persistent_ram_zone *prz, size_t a)
raw_spin_unlock_irqrestore(&buffer_lock, flags);
 }
 
-static size_t (*buffer_start_add)(struct persistent_ram_zone *, size_t) = 
buffer_start_add_atomic;
-static void (*buffer_size_add)(struct persistent_ram_zone *, size_t) = 
buffer_size_add_atomic;
-
 static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz,
uint8_t *data, size_t len, uint8_t *ecc)
 {
@@ -338,9 +302,9 @@ int notrace persistent_ram_write(struct persistent_ram_zone 
*prz,
c = prz->buffer_size;
}
 
-   buffer_size_add(prz, c);
+   buffer_size_add_locked(prz, c);
 
-   start = buffer_start_add(prz, c);
+   start = buffer_start_add_locked(prz, c);
 
rem = prz->buffer_size - start;
if (unlikely(rem < c)) {
@@ -426,9 +390,6 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t 
size,
return NULL;
}
 
-   buffer_start_add = buffer_start_add_locked;
-   buffer_size_add = buffer_size_add_locked;
-
if (memtype)
va = ioremap(start, size);
else
-- 
2.9.3

[PATCH v2] perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2

[Matt Fleming]

While the Intel PMU monitors the LLC when perf enables the
HW_CACHE_REFERENCES and HW_CACHE_MISSES events, these events monitor
L1 instruction cache fetches (0x0080) and instruction cache misses
(0x0081) on the AMD PMU.

This is extremely confusing when monitoring the same workload across
Intel and AMD machines, since parameters like,

  $ perf stat -e cache-references,cache-misses

measure completely different things.

Instead, make the AMD PMU measure instruction/data cache and TLB fill
requests to the L2 and instruction/data cache and TLB misses in the L2
when HW_CACHE_REFERENCES and HW_CACHE_MISSES are enabled,
respectively. That way the events measure unified caches on both
platforms.

Signed-off-by: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: 
---

Changes in v2:
  - Update the KVM AMD PMU code
  - Also measure TLB hits/misses in the L2

 arch/x86/events/amd/core.c | 4 ++--
 arch/x86/kvm/pmu_amd.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index e07a22bb9308..f5f4b3fbbbc2 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -119,8 +119,8 @@ static const u64 amd_perfmon_event_map[PERF_COUNT_HW_MAX] =
 {
   [PERF_COUNT_HW_CPU_CYCLES]   = 0x0076,
   [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0,
-  [PERF_COUNT_HW_CACHE_REFERENCES] = 0x0080,
-  [PERF_COUNT_HW_CACHE_MISSES] = 0x0081,
+  [PERF_COUNT_HW_CACHE_REFERENCES] = 0x077d,
+  [PERF_COUNT_HW_CACHE_MISSES] = 0x077e,
   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS]  = 0x00c2,
   [PERF_COUNT_HW_BRANCH_MISSES]= 0x00c3,
   [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND]  = 0x00d0, /* "Decoder empty" 
event */
diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86/kvm/pmu_amd.c
index 39b91127ef07..cd944435dfbd 100644
--- a/arch/x86/kvm/pmu_amd.c
+++ b/arch/x86/kvm/pmu_amd.c
@@ -23,8 +23,8 @@
 static struct kvm_event_hw_type_mapping amd_event_mapping[] = {
[0] = { 0x76, 0x00, PERF_COUNT_HW_CPU_CYCLES },
[1] = { 0xc0, 0x00, PERF_COUNT_HW_INSTRUCTIONS },
-   [2] = { 0x80, 0x00, PERF_COUNT_HW_CACHE_REFERENCES },
-   [3] = { 0x81, 0x00, PERF_COUNT_HW_CACHE_MISSES },
+   [2] = { 0x7d, 0x07, PERF_COUNT_HW_CACHE_REFERENCES },
+   [3] = { 0x7e, 0x07, PERF_COUNT_HW_CACHE_MISSES },
[4] = { 0xc2, 0x00, PERF_COUNT_HW_BRANCH_INSTRUCTIONS },
[5] = { 0xc3, 0x00, PERF_COUNT_HW_BRANCH_MISSES },
[6] = { 0xd0, 0x00, PERF_COUNT_HW_STALLED_CYCLES_FRONTEND },
-- 
2.7.3

Re: [PATCH V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator

[Herbert Xu]

On Tue, Aug 16, 2016 at 09:49:45PM +0200, Fabian Frederick wrote:
> We can directly depend on SOC_IMX31 since commit c9ee94965dce
> ("ARM: imx: deconstruct mxc_rnga initialization")
> 
> Since that commit, CONFIG_HW_RANDOM_MXC_RNGA could not be switched on
> with unknown symbol ARCH_HAS_RNGA and mxc-rnga.o can't be generated with
> ARCH=arm make M=drivers/char/hw_random
> Previously, HW_RANDOM_MXC_RNGA required ARCH_HAS_RNGA
> which was based on IMX_HAVE_PLATFORM_MXC_RNGA  && ARCH_MXC.
> IMX_HAVE_PLATFORM_MXC_RNGA  was based on SOC_IMX31.
> 
> Fixes: c9ee94965dce ("ARM: imx: deconstruct mxc_rnga initialization")
> Signed-off-by: Fabian Frederick 
> ---
> -Cc to linux-crypto (suggested by Herbert Xu)
> -Adding "Fixes:" (suggested by Arnd Bergmann)
> -This patch appeared in 4.8-rc1 (not in stable yet)
> -Improving patch description

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

[tip:perf/urgent] perf/core: Use this_cpu_ptr() when stopping AUX events

[tip-bot for Will Deacon]

Commit-ID:  8b6a3fe8fab97716990a3abde1a01fb5a34552a3
Gitweb: http://git.kernel.org/tip/8b6a3fe8fab97716990a3abde1a01fb5a34552a3
Author: Will Deacon 
AuthorDate: Wed, 24 Aug 2016 10:07:14 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 15:03:10 +0200

perf/core: Use this_cpu_ptr() when stopping AUX events

When tearing down an AUX buf for an event via perf_mmap_close(),
__perf_event_output_stop() is called on the event's CPU to ensure that
trace generation is halted before the process of unmapping and
freeing the buffer pages begins.

The callback is performed via cpu_function_call(), which ensures that it
runs with interrupts disabled and is therefore not preemptible.
Unfortunately, the current code grabs the per-cpu context pointer using
get_cpu_ptr(), which unnecessarily disables preemption and doesn't pair
the call with put_cpu_ptr(), leading to a preempt_count() imbalance and
a BUG when freeing the AUX buffer later on:

  WARNING: CPU: 1 PID: 2249 at kernel/events/ring_buffer.c:539 
__rb_free_aux+0x10c/0x120
  Modules linked in:
  [...]
  Call Trace:
   [] dump_stack+0x4f/0x72
   [] __warn+0xc6/0xe0
   [] warn_slowpath_null+0x18/0x20
   [] __rb_free_aux+0x10c/0x120
   [] rb_free_aux+0x13/0x20
   [] perf_mmap_close+0x29e/0x2f0
   [] ? perf_iterate_ctx+0xe0/0xe0
   [] remove_vma+0x25/0x60
   [] exit_mmap+0x106/0x140
   [] mmput+0x1c/0xd0
   [] do_exit+0x253/0xbf0
   [] do_group_exit+0x3e/0xb0
   [] get_signal+0x249/0x640
   [] do_signal+0x23/0x640
   [] ? _raw_write_unlock_irq+0x12/0x30
   [] ? _raw_spin_unlock_irq+0x9/0x10
   [] ? __schedule+0x2c6/0x710
   [] exit_to_usermode_loop+0x74/0x90
   [] prepare_exit_to_usermode+0x26/0x30
   [] retint_user+0x8/0x10

This patch uses this_cpu_ptr() instead of get_cpu_ptr(), since preemption is
already disabled by the caller.

Signed-off-by: Will Deacon 
Reviewed-by: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: 95ff4ca26c49 ("perf/core: Free AUX pages in unmap path")
Link: http://lkml.kernel.org/r/20160824091905.ga16...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5650f53..3cfabdf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6166,7 +6166,7 @@ static int __perf_pmu_output_stop(void *info)
 {
struct perf_event *event = info;
struct pmu *pmu = event->pmu;
-   struct perf_cpu_context *cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
+   struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
struct remote_output ro = {
.rb = event->rb,
};

Re: [PATCH] hw_random: Improve description of the ->read() interface

[Herbert Xu]

On Thu, Aug 18, 2016 at 01:37:21PM +0100, Daniel Thompson wrote:
> Currently, very few RNG drivers support single byte reads using the
> ->read() interface. Of the 14 drivers in drivers/char/hw_random that
> support this interface only three of these actually support max == 1.
> The other behaviours vary between return 0, return 2, return 4 and return
> -EIO).
> 
> This is not a problem in practice because the core hw_random code never
> performs a read shorter than 16 bytes. The documentation for this function
> already contrains the alignment of the buffer pointer, so let's also
> guarantee that the buffer is at least as large as its alignment.
> 
> This constraint is intended to be the weakest guarantee neccessary to
> allow driver writers to safely simplify their code.
> 
> Signed-off-by: Daniel Thompson 

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

Re: [BUGFIX, 1/2] brcmfmac: Check rtnl_lock is locked when removing interface

[Kalle Valo]

mhira...@kernel.org wrote:
> Check rtnl_lock is locked in brcmf_p2p_ifp_removed() by passing
> rtnl_locked flag. Actually the caller brcmf_del_if() checks whether
> the rtnl_lock is locked, but doesn't pass it to brcmf_p2p_ifp_removed().
> 
> Without this fix, wpa_supplicant goes softlockup with rtnl_lock
> holding (this means all other process using netlink are locked up too)
> 
> e.g.
> [ 4495.876627] INFO: task wpa_supplicant:7307 blocked for more than 10 
> seconds.
> [ 4495.876632]   Tainted: GW   4.8.0-rc1+ #8
> [ 4495.876635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 4495.876638] wpa_supplicant  D 974c647b39a0 0  7307  1 
> 0x
> [ 4495.876644]  974c647b39a0  974c 
> 974c7dc59c58
> [ 4495.876651]  974c6b7417c0 974c645017c0 974c647b4000 
> 86f16c08
> [ 4495.876657]  974c645017c0 0246  
> 974c647b39b8
> [ 4495.876664] Call Trace:
> [ 4495.876671]  [] schedule+0x3c/0x90
> [ 4495.876676]  [] schedule_preempt_disabled+0x15/0x20
> [ 4495.876682]  [] mutex_lock_nested+0x176/0x3b0
> [ 4495.876686]  [] ? rtnl_lock+0x17/0x20
> [ 4495.876690]  [] rtnl_lock+0x17/0x20
> [ 4495.876720]  [] brcmf_p2p_ifp_removed+0x4d/0x70 
> [brcmfmac]
> [ 4495.876741]  [] brcmf_remove_interface+0x196/0x1b0 
> [brcmfmac]
> [ 4495.876760]  [] brcmf_p2p_del_vif+0x111/0x220 [brcmfmac]
> [ 4495.876777]  [] brcmf_cfg80211_del_iface+0x21b/0x270 
> [brcmfmac]
> [ 4495.876820]  [] nl80211_del_interface+0xfe/0x3a0 
> [cfg80211]
> [ 4495.876825]  [] genl_family_rcv_msg+0x1b5/0x370
> [ 4495.876832]  [] ? trace_hardirqs_on+0xd/0x10
> [ 4495.876836]  [] genl_rcv_msg+0x7d/0xb0
> [ 4495.876839]  [] ? genl_family_rcv_msg+0x370/0x370
> [ 4495.876846]  [] netlink_rcv_skb+0x97/0xb0
> [ 4495.876849]  [] genl_rcv+0x28/0x40
> [ 4495.876854]  [] netlink_unicast+0x1d3/0x2f0
> [ 4495.876860]  [] ? netlink_unicast+0x14b/0x2f0
> [ 4495.876866]  [] netlink_sendmsg+0x2eb/0x3a0
> [ 4495.876870]  [] sock_sendmsg+0x38/0x50
> [ 4495.876874]  [] ___sys_sendmsg+0x27f/0x290
> [ 4495.876882]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876888]  [] ? mntput_no_expire+0x8e/0x3f0
> [ 4495.876894]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876899]  [] ? mntput+0x24/0x40
> [ 4495.876904]  [] ? __fput+0x190/0x200
> [ 4495.876909]  [] __sys_sendmsg+0x45/0x80
> [ 4495.876914]  [] SyS_sendmsg+0x12/0x20
> [ 4495.876918]  [] entry_SYSCALL_64_fastpath+0x23/0xc1
> [ 4495.876924]  [] ? trace_hardirqs_off_caller+0x1f/0xc0
> 
> Signed-off-by: Masami Hiramatsu 
> Acked-by: Rafał Miłecki 

Thanks, 2 patches applied to wireless-drivers.git:

15dacf880e49 brcmfmac: Check rtnl_lock is locked when removing interface
b64abcb7dae6 brcmfmac: Change vif_event_lock to spinlock

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9280681/

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

[Eric Dumazet]

On Wed, 2016-08-24 at 06:07 -0700, Eric Dumazet wrote:

> I am afraid you could live lock here on SMP.
> 
> You should make sure you do not loop forever, not assuming cpu is faster
> than NIC.

You are protected by the tx_lock spinlock, but this is fragile as you
could very well remove this spinlock in the future to get lockless
transmit, like many other drivers.

Re: [PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions

[Herbert Xu]

On Sat, Aug 20, 2016 at 09:31:06PM +0530, PrasannaKumar Muralidharan wrote:
> Remove omap3_rom_rng_data_present method as it was returning 1 always.
> Use .read callback instead of .data_read callback. This avoids use of
> obsolete callbacks.
> 
> This patch is not tested with hardware as I don't have access to it.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

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

[PATCH v3 2/5] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

[Milo Kim]

This patch enables getting a HPD GPIO descriptor quickly.
The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.

static int hdmi_resources_init(struct hdmi_context *hdata)
{
...
hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
...
}

This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.

However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
always retries to get a GPIO descriptor because the first GPIO suffix is not
'gpio' but 'gpios'. So you always see the debug message below.

of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
'/soc/hdmi@1453[0]'

Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.

Acked-by: Rob Herring 
Reviewed-by: Andrzej Hajda 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim 
---
 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
 arch/arm/boot/dts/exynos4210-universal_c210.dts  | 2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
 arch/arm/boot/dts/exynos5250-spring.dts  | 2 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts   | 2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi   | 2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index a2ec4c1..6394ea9 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -9,7 +9,7 @@ Required properties:
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
+- hpd-gpios: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
@@ -56,7 +56,7 @@ Example:
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
-   hpd-gpio = <&gpx3 7 1>;
+   hpd-gpios = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
samsung,syscon-phandle = <&pmu_system_controller>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 9a75e3e..cf95202 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -269,7 +269,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
hdmi-en-supply = <&hdmi_en>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 58ad48e7..be644fe 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -227,7 +227,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index ea70603..3d981f3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -152,7 +152,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_LOW>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 381af13..7f27263 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -116,7 +116,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
 };
 
 &i2c_0 {
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boo

Re: [PATCH] crypto: rockchip - use devm_add_action_or_reset()

[Herbert Xu]

On Tue, Aug 23, 2016 at 08:28:54PM +0530, Sudip Mukherjee wrote:
> If devm_add_action() fails we are explicitly calling the cleanup to free
> the resources allocated.  Lets use the helper devm_add_action_or_reset()
> and return directly in case of error, as we know that the cleanup function
> has been already called by the helper if there was any error.
> 
> Signed-off-by: Sudip Mukherjee 

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

Re: perf: fuzzer crashes immediately on AMD system

[Vince Weaver]

On Wed, 24 Aug 2016, Ingo Molnar wrote:
> If there's no progress finding the root cause I'd be happy to exchange a 
> crash for 
> a leak ...

It's actually a crash of the program doing the perf_event_open() call, not 
a crash of the system (at least in my experience).

However, it's possible that if you have bad luck and if the kfree'd space 
is reused with just the right combination of values you could potentially 
end up crashing the system.

Vince

[PATCH v3 3/5] gpu: drm: exynos_hdmi: Move DDC logic into single function

[Milo Kim]

Paring DT properties and getting the I2C adapter in one function.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 46 
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..8d99b5d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
 };
 
-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
+   struct i2c_adapter *adpt;
 
np = of_find_compatible_node(NULL, NULL, compatible_str);
if (np)
-   return of_get_next_parent(np);
+   np = of_get_next_parent(np);
+   else
+   np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
+
+   if (!np) {
+   DRM_ERROR("Failed to find ddc node in device tree\n");
+   return -ENODEV;
+   }
 
-   return NULL;
+   adpt = of_find_i2c_adapter_by_node(np);
+   if (!adpt) {
+   DRM_ERROR("Failed to get ddc i2c adapter by node\n");
+   of_node_put(np);
+   return -EPROBE_DEFER;
+   }
+
+   hdata->ddc_adpt = adpt;
+   of_node_put(np);
+
+   return 0;
 }
 
 static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1781,7 +1799,7 @@ static struct device_node 
*hdmi_legacy_phy_dt_binding(struct device *dev)
 
 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *ddc_node, *phy_node;
+   struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
 
-   ddc_node = hdmi_legacy_ddc_dt_binding(dev);
-   if (ddc_node)
-   goto out_get_ddc_adpt;
-
-   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
-   if (!ddc_node) {
-   DRM_ERROR("Failed to find ddc node in device tree\n");
-   return -ENODEV;
-   }
-   of_node_put(dev->of_node);
-
-out_get_ddc_adpt:
-   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdata->ddc_adpt) {
-   DRM_ERROR("Failed to get ddc i2c adapter by node\n");
-   return -EPROBE_DEFER;
-   }
+   ret = hdmi_get_ddc_adapter(hdata);
+   if (ret)
+   return ret;
 
phy_node = hdmi_legacy_phy_dt_binding(dev);
if (phy_node)
-- 
1.9.1

[PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Milo Kim]

* GPIO for HDMI hot plug detect
  GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
  single ended.

* Enable HDMI block in Exynos5420
  HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
  requires 1.8V LDO7 (PVDD_ANAIP_1V8).

* Support HDMI display data channel
  I2C #2 is assigned for the HDMI DDC. It enables the EDID access.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Rob Herring 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..2fb5708 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,19 @@
status = "disabled";
 };
 
+&hdmi {
+   hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
+   vdd_osc-supply = <&ldo7_reg>;
+   vdd_pll-supply = <&ldo6_reg>;
+   vdd-supply = <&ldo6_reg>;
+   ddc = <&i2c_2>;
+   status = "okay";
+};
+
+&i2c_2 {
+   status = "okay";
+};
+
 &hsi2c_4 {
status = "okay";
 
-- 
1.9.1

Re: [PATCH 8/8] arm64: Work around systems with mismatched cache line sizes

[Suzuki K Poulose]

On 22/08/16 14:02, Will Deacon wrote:

On Thu, Aug 18, 2016 at 02:10:32PM +0100, Suzuki K Poulose wrote:

Systems with differing CPU i-cache/d-cache line sizes can cause
problems with the cache management by software when the execution
is migrated from one to another. Usually, the application reads
the cache size on a CPU and then uses that length to perform cache
operations. However, if it gets migrated to another CPU with a smaller
cache line size, things could go completely wrong. To prevent such
cases, always use the smallest cache line size among the CPUs. The
kernel CPU feature infrastructure already keeps track of the safe
value for all CPUID registers including CTR. This patch works around
the problem by :

For kernel, dynamically patch the kernel to read the cache size
from the system wide copy of CTR_EL0.


Is it only CTR that is mismatched in practice, or do we need to worry
about DCZID_EL0 too?


A mismatched DCZID_EL0 is quite possible. However, there is no way to
trap accesses to DCZID_EL0. Rather, we can trap DC ZVA if we clear
SCTLR_EL1.DZE. But then clearing the SCTLR_EL1.DZE implies reading DCZID.DZP
returns 1, indicating DC ZVA is not supported. So if a proper application
checks the DZP before issuing a DC ZVA, we may never be able to emulate it.
Or in other words, if there is a mismatch, the work around is to disable
the DC ZVA operations (which could possibly affect existing (incorrect) 
userspace
applications assuming DC ZVA is supported without checking the DZP bit).
 

 static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 93c5287..db2d6cb 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -480,6 +480,14 @@ static void user_cache_maint_handler(unsigned int esr, 
struct pt_regs *regs)
regs->pc += 4;
 }

+static void ctr_read_handler(unsigned int esr, struct pt_regs *regs)
+{
+   int rt = (esr & ESR_ELx_SYS64_ISS_RT_MASK) >> 
ESR_ELx_SYS64_ISS_RT_SHIFT;
+
+   regs->regs[rt] = sys_ctr_ftr->sys_val;
+   regs->pc += 4;
+}


Whilst this is correct, I wonder if there's any advantage in reporting a
*larger* size to userspace and avoid incurring additional trap overhead?


Combining the trapping of user space dc operations for Errata work around for
clean cache, we could possibly report a larger size and emulate it properly
in the kernel. But I think that can be a enhancement on top of this series.



Any idea what sort of size typical JITs are using?


I have no clue about it. I have Cc-ed Rodolph and Stuart, who may have better
idea about the JIT's usage.

Suzuki

[PATCH v3 5/5] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer

[Milo Kim]

The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
so this code can be ignored.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 249cb23..4e17877f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
if (ret)
return ret;
 
-   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+   for (i = 0; i < ARRAY_SIZE(supply); ++i)
hdata->regul_bulk[i].supply = supply[i];
-   hdata->regul_bulk[i].consumer = NULL;
-   }
+
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), 
hdata->regul_bulk);
if (ret) {
if (ret != -EPROBE_DEFER)
-- 
1.9.1

[PATCH v3 4/5] gpu: drm: exynos_hdmi: Move PHY logic into single function

[Milo Kim]

Paring DT properties and getting PHY IO (memory mapped or I2C) in one function.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 63 +++-
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8d99b5d..249cb23 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1790,16 +1790,44 @@ static int hdmi_get_ddc_adapter(struct hdmi_context 
*hdata)
return 0;
 }
 
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static int hdmi_get_phy_io(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+   struct device_node *np;
+   int ret = 0;
+
+   np = of_find_compatible_node(NULL, NULL, compatible_str);
+   if (!np) {
+   np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
+   if (!np) {
+   DRM_ERROR("Failed to find hdmiphy node in device 
tree\n");
+   return -ENODEV;
+   }
+   }
+
+   if (hdata->drv_data->is_apb_phy) {
+   hdata->regs_hdmiphy = of_iomap(np, 0);
+   if (!hdata->regs_hdmiphy) {
+   DRM_ERROR("failed to ioremap hdmi phy\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+   } else {
+   hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
+   if (!hdata->hdmiphy_port) {
+   DRM_ERROR("Failed to get hdmi phy i2c client\n");
+   ret = -EPROBE_DEFER;
+   goto out;
+   }
+   }
 
-   return of_find_compatible_node(NULL, NULL, compatible_str);
+out:
+   of_node_put(np);
+   return ret;
 }
 
 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1833,34 +1861,9 @@ static int hdmi_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   phy_node = hdmi_legacy_phy_dt_binding(dev);
-   if (phy_node)
-   goto out_get_phy_port;
-
-   phy_node = of_parse_phandle(dev->of_node, "phy", 0);
-   if (!phy_node) {
-   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
-   ret = -ENODEV;
+   ret = hdmi_get_phy_io(hdata);
+   if (ret)
goto err_ddc;
-   }
-   of_node_put(dev->of_node);
-
-out_get_phy_port:
-   if (hdata->drv_data->is_apb_phy) {
-   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
-   if (!hdata->regs_hdmiphy) {
-   DRM_ERROR("failed to ioremap hdmi phy\n");
-   ret = -ENOMEM;
-   goto err_ddc;
-   }
-   } else {
-   hdata->hdmiphy_port = of_find_i2c_device_by_node(phy_node);
-   if (!hdata->hdmiphy_port) {
-   DRM_ERROR("Failed to get hdmi phy i2c client\n");
-   ret = -EPROBE_DEFER;
-   goto err_ddc;
-   }
-   }
 
INIT_DELAYED_WORK(&hdata->hotplug_work, hdmi_hotplug_work_func);
 
-- 
1.9.1

Re: [PATCH v3] pwm: sun4i: fix a possible NULL dereference

[Thierry Reding]

On Wed, Aug 24, 2016 at 01:43:58PM +0200, LABBE Corentin wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
> 
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
> 
> Testing the return value of of_device_get_match_data is also necessary
> for avoiding a second NULL deref on pwm->data.
> 
> Reported-by: coverity (CID 1324139)
> Signed-off-by: LABBE Corentin 
> ---
> Changes since v2:
>  - Add a test on pwm->data for avoiding a second NULL deref.
> Changes since v1:
>  - Use of_device_get_match_data()
> 
>  drivers/pwm/pwm-sun4i.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..fb76c55 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   struct resource *res;
>   u32 val;
>   int i, ret;
> - const struct of_device_id *match;
> -
> - match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
>  
>   pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>   if (!pwm)
> @@ -326,7 +323,9 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   if (IS_ERR(pwm->clk))
>   return PTR_ERR(pwm->clk);
>  
> - pwm->data = match->data;
> + pwm->data = of_device_get_match_data(&pdev->dev);
> + if (!pwm->data)
> + return -EINVAL;

I don't see how this would ever be NULL. You'd have to add an entry to
the table that has a NULL data field, which is very unlikely to happen.
If you really want to check for this, which I think isn't necessary,
please wrap this in a WARN_ON() or something to make more noise when
this completely unexpected case happens.

Thierry


signature.asc
Description: PGP signature

[PATCH 01/10] reset: ath79: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Alban Bedel 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 7 +++
 drivers/reset/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 7dfe8d8..9da0507 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -14,6 +14,13 @@ menuconfig RESET_CONTROLLER
 
 if RESET_CONTROLLER
 
+config RESET_ATH79
+   bool "AR71xx Reset Driver" if COMPILE_TEST
+   default ATH79
+   help
+ This enables the ATH79 reset controller driver that supports the
+ AR71xx SoC reset controller.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 9b45dcf..e3fc337 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
-obj-$(CONFIG_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 04/10] reset: meson: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Neil Armstrong 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 8e33de2..fdf942d 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -34,6 +34,12 @@ config RESET_LPC18XX
  This enables the LPC18xx/43 reset driver that supports the reset
  controllers on AR71xx SoCs.
 
+config RESET_MESON
+   bool "Meson Reset Driver" if COMPILE_TEST
+   default ARCH_MESON
+   help
+ This enables the reset driver for Amlogic Meson SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 25aa05a..1408cba 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
-obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 07/10] reset: stm32: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Maxime Coquelin 
Cc: Gabriel Fernandez 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 354e281..3a54a66 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -55,6 +55,12 @@ config RESET_SOCFPGA
help
  This enables the reset driver for Altera SoC FPGAs.
 
+config RESET_STM32
+   bool "STM32 Reset Driver" if COMPILE_TEST
+   default ARCH_STM32
+   help
+ This enables the RCC reset controller driver for STM32 MCUs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 61e4c64..6276f82 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 09/10] reset: zynq: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Moritz Fischer 
Cc: Michal Simek 
Cc: Sören Brinkmann 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 17030e2..86b49a2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -67,6 +67,12 @@ config RESET_SUNXI
help
  This enables the reset driver for Allwinner SoCs.
 
+config RESET_ZYNQ
+   bool "ZYNQ Reset Driver" if COMPILE_TEST
+   default ARCH_ZYNQ
+   help
+ This enables the reset driver for Xilinx Zynq FPGAs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4a163c7..56f90ea 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
-obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
@@ -13,3 +12,4 @@ obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
+obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
-- 
2.8.1

[PATCH 10/10] reset: hi6220: allow to compile test driver on other architectures

[Philipp Zabel]

Also remove the RESET_CONTROLLER dependency, this Kconfig file is
included inside the menuconfig already.

Cc: Chen Feng 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/hisilicon/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
index 26bf95a..1ff8b0c 100644
--- a/drivers/reset/hisilicon/Kconfig
+++ b/drivers/reset/hisilicon/Kconfig
@@ -1,5 +1,6 @@
 config COMMON_RESET_HI6220
tristate "Hi6220 Reset Driver"
-   depends on (ARCH_HISI && RESET_CONTROLLER)
+   depends on ARCH_HISI || COMPILE_TEST
+   default ARCH_HISI
help
  Build the Hisilicon Hi6220 reset driver.
-- 
2.8.1

[PATCH v3 0/5] ARM: dts: exynos: Enable HDMI in Arndale Octa board

[Milo Kim]

This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property.
It also includes code refactoring on ddc and phy.

v3:
  Add 'vdd-supply' property in dts.
  Use generic 'ddc' property instead of legacy property.
  Clean up DDC and PHY logic in _probe().
  Remove duplicate code of regulator consumer initialization.

v2:
  Include DRM and Exynos maintainers and resend the patch-set.
  Add Rob's ack for the patch,
[PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

Milo Kim (5):
  ARM: dts: exynos: Enable HDMI for Arndale Octa board
  ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
  gpu: drm: exynos_hdmi: Move DDC logic into single function
  gpu: drm: exynos_hdmi: Move PHY logic into single function
  gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator
bulk consumer

 .../bindings/display/exynos/exynos_hdmi.txt|   4 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |   2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  |   2 +-
 arch/arm/boot/dts/exynos5250-spring.dts|   2 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  13 +++
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 112 +++--
 13 files changed, 84 insertions(+), 65 deletions(-)

-- 
1.9.1

[PATCH 02/10] reset: berlin: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Antoine Tenart 
Cc: Sebastian Hesselbarth 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9da0507..1194cbe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -21,6 +21,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.
 
+config RESET_BERLIN
+   bool "Berlin Reset Driver" if COMPILE_TEST
+   default ARCH_BERLIN
+   help
+ This enables the reset controller driver for Marvell Berlin SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index e3fc337..34c0b23 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 06/10] reset: socfpga: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Dinh Nguyen 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 6ac631e..354e281 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -49,6 +49,12 @@ config RESET_PISTACHIO
help
  This enables the reset driver for ImgTec Pistachio SoCs.
 
+config RESET_SOCFPGA
+   bool "SoC FPGA Reset Driver" if COMPILE_TEST
+   default ARCH_SOCFPGA
+   help
+ This enables the reset driver for Altera SoC FPGAs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index c796a14..61e4c64 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
+obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 03/10] reset: lpc18xx: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Joachim Eastwood 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 7 +++
 drivers/reset/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 1194cbe..8e33de2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -27,6 +27,13 @@ config RESET_BERLIN
help
  This enables the reset controller driver for Marvell Berlin SoCs.
 
+config RESET_LPC18XX
+   bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
+   default ARCH_LPC18XX
+   help
+ This enables the LPC18xx/43 reset driver that supports the reset
+ controllers on AR71xx SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 34c0b23..25aa05a 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_ARCH_MESON) += reset-meson.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 08/10] reset: sunxi: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 3a54a66..17030e2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -61,6 +61,12 @@ config RESET_STM32
help
  This enables the RCC reset controller driver for STM32 MCUs.
 
+config RESET_SUNXI
+   bool "Allwinner SoCs Reset Driver" if COMPILE_TEST
+   default ARCH_SUNXI
+   help
+ This enables the reset driver for Allwinner SoCs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 6276f82..4a163c7 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_RESET_STM32) += reset-stm32.o
+obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1