[PATCH v7 2/4] sched/fair: Move load and util avgs from wake_up_new_task() to sched_fork()

[Yuyang Du]

Move new task initialization to sched_fork(). For initial non-fair class
task, the first switched_to_fair() will do the attach correctly.

Suggested-by: Peter Zijlstra 
Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |5 +++--
 kernel/sched/fair.c  |   14 +-
 kernel/sched/sched.h |2 +-
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 31c30e5..6b7d0b1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2384,6 +2384,9 @@ int sched_fork(unsigned long clone_flags, struct 
task_struct *p)
if (p->sched_class->task_fork)
p->sched_class->task_fork(p);
 
+   /* Initialize new task's sched averages */
+   init_entity_sched_avg(&p->se);
+
/*
 * The child is not yet in the pid-hash so no cgroup attach races,
 * and the cgroup is pinned to this child due to cgroup_fork()
@@ -2524,8 +2527,6 @@ void wake_up_new_task(struct task_struct *p)
struct rq_flags rf;
struct rq *rq;
 
-   /* Initialize new task's runnable average */
-   init_entity_runnable_average(&p->se);
raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
 #ifdef CONFIG_SMP
/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d43d242..35d76cf 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -668,8 +668,8 @@ static unsigned long task_h_load(struct task_struct *p);
 #define LOAD_AVG_MAX 47742 /* maximum possible load avg */
 #define LOAD_AVG_MAX_N 345 /* number of full periods to produce LOAD_AVG_MAX */
 
-/* Give new sched_entity start runnable values to heavy its load in infant 
time */
-void init_entity_runnable_average(struct sched_entity *se)
+/* Give new sched_entity start load values to heavy its load in infant time */
+void init_entity_sched_avg(struct sched_entity *se)
 {
struct sched_avg *sa = &se->avg;
 
@@ -738,12 +738,8 @@ void post_init_entity_util_avg(struct sched_entity *se)
 static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq);
 static inline unsigned long cfs_rq_load_avg(struct cfs_rq *cfs_rq);
 #else
-void init_entity_runnable_average(struct sched_entity *se)
-{
-}
-void post_init_entity_util_avg(struct sched_entity *se)
-{
-}
+void init_entity_sched_avg(struct sched_entity *se) { }
+void post_init_entity_util_avg(struct sched_entity *se) { }
 #endif
 
 /*
@@ -8527,7 +8523,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct 
task_group *parent)
 
init_cfs_rq(cfs_rq);
init_tg_cfs_entry(tg, cfs_rq, se, i, parent->se[i]);
-   init_entity_runnable_average(se);
+   init_entity_sched_avg(se);
 
raw_spin_lock_irq(&rq->lock);
post_init_entity_util_avg(se);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index bf6fea9..1b1d439 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1321,7 +1321,7 @@ extern void init_dl_task_timer(struct sched_dl_entity 
*dl_se);
 
 unsigned long to_ratio(u64 period, u64 runtime);
 
-extern void init_entity_runnable_average(struct sched_entity *se);
+extern void init_entity_sched_avg(struct sched_entity *se);
 extern void post_init_entity_util_avg(struct sched_entity *se);
 
 #ifdef CONFIG_NO_HZ_FULL
-- 
1.7.9.5

[PATCH v7 0/4] sched/fair: Fix attach and detach sched avgs for task group change and sched class change

[Yuyang Du]

Hi Peter,

This new version attaches sched avgs in task_move_group_fair(), since Vincent
and Peter are concerned with delaying it to task enqueue, and I agreed.

Thanks a lot to Vincent and Peter.

Thanks,
Yuyang

--

Yuyang Du (4):
  sched/fair: Fix attaching task sched avgs twice when switching to
fair or changing task group
  sched/fair: Move load and util avgs from wake_up_new_task() to
sched_fork()
  sched/fair: Skip detach sched avgs for new task when changing task
groups
  sched/fair: Add inline to detach_entity_load_evg()

 kernel/sched/core.c  |5 ++-
 kernel/sched/fair.c  |  106 +++---
 kernel/sched/sched.h |2 +-
 3 files changed, 71 insertions(+), 42 deletions(-)

-- 
1.7.9.5

[PATCH v7 1/4] sched/fair: Fix attaching task sched avgs twice when switching to fair or changing task group

[Yuyang Du]

Vincent reported that the first task to a new task group's cfs_rq will
be attached in attach_task_cfs_rq() and once more when it is enqueued
(see https://lkml.org/lkml/2016/5/25/388).

Actually, it is worse. The sched avgs can be sometimes attached twice
not only when we change task groups but also when we switch to fair class.
These two scenarios will be described in the following respectively.

(1) Switch to fair class:

The sched class change is done like this:

if (queued)
  enqueue_task();
check_class_changed()
  switched_from()
  switched_to()

If the task is on_rq, before switched_to(), it has been enqueued, which
already attached sched avgs to the cfs_rq if the task's last_update_time
is 0, which can happen if the task was never fair class, if so, we
shouldn't attach it again in switched_to(), otherwise, we attach it twice.

To address both the on_rq and !on_rq cases, as well as both the task
was switched from fair and otherwise, the simplest solution is to reset
the task's last_update_time to 0 when the task is switched from fair.
Then let task enqueue do the sched avgs attachment uniformly only once.

(2) Change between fair task groups:

The task groups are changed like this:

if (queued)
  dequeue_task()
task_move_group()
if (queued)
  enqueue_task()

Unlike the switch to fair class case, if the task is on_rq, it will be
enqueued right away after we move task groups, and if not, in the future
when the task is runnable. The attach twice problem can happen if the
cfs_rq and the task are both new as Vincent discovered. The simplest
solution is to only reset the task's last_update_time in task_move_group(),
and then let enqueue_task() do the sched avgs attachment.

Reported-by: Vincent Guittot 
Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |   82 ++-
 1 file changed, 55 insertions(+), 27 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f75930b..d43d242 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2933,26 +2933,9 @@ static inline void update_load_avg(struct sched_entity 
*se, int update_tg)
update_tg_load_avg(cfs_rq, 0);
 }
 
-static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+/* Synchronize task with its cfs_rq */
+static inline void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
sched_entity *se)
 {
-   if (!sched_feat(ATTACH_AGE_LOAD))
-   goto skip_aging;
-
-   /*
-* If we got migrated (either between CPUs or between cgroups) we'll
-* have aged the average right before clearing @last_update_time.
-*/
-   if (se->avg.last_update_time) {
-   __update_load_avg(cfs_rq->avg.last_update_time, 
cpu_of(rq_of(cfs_rq)),
- &se->avg, 0, 0, NULL);
-
-   /*
-* XXX: we could have just aged the entire load away if we've 
been
-* absent from the fair class for too long.
-*/
-   }
-
-skip_aging:
se->avg.last_update_time = cfs_rq->avg.last_update_time;
cfs_rq->avg.load_avg += se->avg.load_avg;
cfs_rq->avg.load_sum += se->avg.load_sum;
@@ -3036,6 +3019,11 @@ static inline u64 cfs_rq_last_update_time(struct cfs_rq 
*cfs_rq)
 }
 #endif
 
+static inline void reset_task_last_update_time(struct task_struct *p)
+{
+   p->se.avg.last_update_time = 0;
+}
+
 /*
  * Task first catches up with cfs_rq, and then subtract
  * itself from the cfs_rq (task must be off the queue now).
@@ -3088,9 +3076,8 @@ dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct 
sched_entity *se) {}
 static inline void remove_entity_load_avg(struct sched_entity *se) {}
 
 static inline void
-attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
-static inline void
 detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
+static inline void reset_task_last_update_time(struct task_struct *p) {}
 
 static inline int idle_balance(struct rq *rq)
 {
@@ -8376,8 +8363,19 @@ static void attach_task_cfs_rq(struct task_struct *p)
se->depth = se->parent ? se->parent->depth + 1 : 0;
 #endif
 
-   /* Synchronize task with its cfs_rq */
-   attach_entity_load_avg(cfs_rq, se);
+   /*
+* At this point, we don't do sched avgs attachment. Instead,
+* we uniformly do the attachement at enqueue time in all
+* scenarios:
+*
+* (1) Actually, we may have already done it (e.g., at enqueue_task()
+* in __sched_setscheduler() when a task switches to fair class).
+*
+* (2) We will do it right away (e.g., in sched_move_task() when
+* an on_rq task moves between groups)
+*
+* (3) In the future when this currently !on_rq task is enqueued.
+*/
 
if (!vruntime_normalized(p))
se->vruntime += cfs_rq-

Re: [PATCH v3 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Fri, Jun 17, 2016 at 03:38:49PM +0800, Chen Feng wrote:
> Hi Kim & feng,
> 
> Thanks for the share. In our platform also has the same use case.
> 
> We only let the alloc with GFP_HIGHUSER_MOVABLE in memory.c to use cma memory.
> 
> If we add zone_cma, It seems can resolve the cma migrate issue.
> 
> But when free_hot_cold_page, we need let the cma page goto system directly 
> not the pcp.
> It can be fail while cma_alloc and cma_release. If we alloc the whole cma 
> pages which
> declared before.

Hmm...I'm not sure I understand your explanation. So, if I miss
something, please let me know. We calls drain_all_pages() when
isolating pageblock and alloc_contig_range() also has one
drain_all_pages() calls to drain pcp pages. And, after pageblock isolation,
freed pages belonging to MIGRATE_ISOLATE pageblock will go to the
buddy directly so there would be no problem you mentioned. Isn't it?

Thanks.

[PATCH v7 3/4] sched/fair: Skip detach sched avgs for new task when changing task groups

[Yuyang Du]

Newly forked task has not been enqueued, so should not be removed from
cfs_rq in task_move_group_fair(). To do so, we identify newly forked
tasks if their sum_exec_runtime is 0, an existing heuristic as per
vruntime_normalized(). In addition to that, uniformly use this test
in remove_entity_load_avg().

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 35d76cf..c1de063 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2943,6 +2943,10 @@ static inline void attach_entity_load_avg(struct cfs_rq 
*cfs_rq, struct sched_en
 
 static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
+   /* Newly forked tasks are not attached yet. */
+   if (!se->sum_exec_runtime)
+   return;
+
__update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
  &se->avg, se->on_rq * 
scale_load_down(se->load.weight),
  cfs_rq->curr == se, NULL);
@@ -3033,7 +3037,7 @@ void remove_entity_load_avg(struct sched_entity *se)
 * Newly created task or never used group entity should not be removed
 * from its (source) cfs_rq
 */
-   if (se->avg.last_update_time == 0)
+   if (!se->sum_exec_runtime)
return;
 
last_update_time = cfs_rq_last_update_time(cfs_rq);
-- 
1.7.9.5

[PATCH v7 4/4] sched/fair: Add inline to detach_entity_load_evg()

[Yuyang Du]

detach_entity_load_evg() is only called by detach_task_cfs_rq(), so
explicitly add inline attribute to it.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c1de063..a679407 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2941,7 +2941,8 @@ static inline void attach_entity_load_avg(struct cfs_rq 
*cfs_rq, struct sched_en
cfs_rq_util_change(cfs_rq);
 }
 
-static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+/* Catch up with the cfs_rq and remove our load when we leave */
+static inline void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
sched_entity *se)
 {
/* Newly forked tasks are not attached yet. */
if (!se->sum_exec_runtime)
@@ -8346,7 +8347,6 @@ static void detach_task_cfs_rq(struct task_struct *p)
se->vruntime -= cfs_rq->min_vruntime;
}
 
-   /* Catch up with the cfs_rq and remove our load when we leave */
detach_entity_load_avg(cfs_rq, se);
 }
 
-- 
1.7.9.5

Re: [PATCH] fix error: a bin file can truncate itself while running at overlayfs.

[Miklos Szeredi]

On Mon, Jun 20, 2016 at 4:51 AM,   wrote:
> From: Aihua Zhang 
>
> I wrote a testcase to truncate a bin file while it is running at overlayfs.
> the result as below:
>
> Bus error (core dumped)

Thanks for the report.

Please tell us more information about how to trigger the bug:

 - how did you set up the overlay filesystem?
 - which test case from which test suite was this?

> I think it's not appropriate for filesystem, and fixed it by this patch.
> after the patch, result as below:
>
> status:-1
> errno:26
> ETXTBSY:26
> PASS
>
> This is because the inode is not correct ,it should point to overlayfs rather
> than the upper filesystem.

Changeing denty_write_access() without a similar change in
allow_write_access() is sure to buggy.

But even with that fixed, it's not clear to me why exactly this change
is needed.  More thought needs to be going into this.

Thanks,
Miklos



>
> Signed-off-by: Aihua Zhang 
> ---
>  include/linux/fs.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index dd28814..54fdbf9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2589,7 +2589,7 @@ static inline int get_write_access(struct inode *inode)
>  }
>  static inline int deny_write_access(struct file *file)
>  {
> -   struct inode *inode = file_inode(file);
> +   struct inode *inode = d_inode(file->f_path.dentry);
> return atomic_dec_unless_positive(&inode->i_writecount) ? 0 : 
> -ETXTBSY;
>  }
>  static inline void put_write_access(struct inode * inode)
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ARM: AM43XX: hwmod: Fix RSTST register offset for pruss

[Mohammed, Afzal]

Hi,

J, KEERTHY wrote on Monday, June 20, 2016 9:22 AM:

> pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of
> am43xx. Fix the RSTST register offset value.

> This can lead to setting of wrong power state values for PER domain.

Just curious, does it happen or noticed by going thr' the code ?

Regards
afzal

Re: [linux-sunxi] [PATCH v2] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[Hans de Goede]

Hi,

On 20-06-16 08:42, Stefan Mavrodiev wrote:

A33-OLinuXino is A33 development board designed by Olimex LTD.

It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector,
headphone and mic jacks, connector for LiPo battery and optional
4GB NAND Flash.

It has two 40-pin headers. One for LCD panel, and one for
additional modules. Also there is CSI/DSI connector.

Signed-off-by: Stefan Mavrodiev 


The new looks good to me:

Reviewed-by: Hans de Goede 


Regards,

Hans



---
Changes for v2:
- Removed unused power nodes
- Removed default-trigger for green led
- Removed "always-on" option for LCD power

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 207 ++
 2 files changed, 208 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a33-olinuxino.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 970e906..b78f363 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -760,6 +760,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-ippo-q8h-v1.2.dtb \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
+   sun8i-a33-olinuxino.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts 
b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
new file mode 100644
index 000..14fa801
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
@@ -0,0 +1,207 @@
+/*
+ * Copyright 2016 - Stefan Mavrodiev 
+ *  Olimex LTD. 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "A33-OLinuXino";
+   compatible = "allwinner,sun8i-a33";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led_pin_olinuxino>;
+
+   green {
+   label = "olinuxino:green:usr";
+   gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LED2 */
+   };
+   };
+};
+
+&ehci0 {
+   status = "okay";
+};
+
+&ohci0 {
+   status = "okay";
+};
+
+&mmc0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxino>;
+   vmmc-supply = <®_dcdc1>;
+   bus-width = <4>;
+   cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
+   cd-inverted;
+   status = "okay";
+};
+
+&pio {
+   mmc0_cd_pin_olinuxino: mmc0_cd_pin@0 {
+   allwinner,pins = "PB4";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   led_pin_olinuxino: led_pins@0 {
+   allwinner,pins = "PB7";
+   allwi

Re: RFC: Fix kdump failed with 'notsc'

[Wei, Jiangang]

ping...

On Tue, 2016-06-14 at 17:54 +0800, Wei Jiangang wrote:
> Hi,
> 
> When I trigger kernel crash and specify 'notsc' for capture-kernel,
> The process of kdump will be blocked at calibrate_delay_converge().
> 
> /* wait for "start of" clock tick */
> ticks = jiffies;
> while (ticks == jiffies)
> ; /* nothing */
> 
> The reason is that the jiffies remains the same, no changed.
> 
> serial console log as following,
> 
> [0.00] Linux version 4.7.0-rc2+ (root@localhost.localdomain)
> (gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #2 SMP Wed Jun
> 156
> [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-rc2+ 
> root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap
> vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=256M
> vconsole.keymap=us console=tty0 console=ttyS0,115200n8 LANG=en_US.UTF-8
> irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off
> panic=10 rootflags=nofail acpi_no_memhotplug notsc 
> 
> [0.00] tsc: Kernel compiled with CONFIG_X86_TSC, cannot disable
> TSC completely
> 
> [0.00] clocksource: hpet: mask: 0x max_cycles:
> 0x, max_idle_ns: 133484882848 ns
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] tsc: Detected 3192.714 MHz processor
> [0.00] Calibrating delay loop... 
> 
> # The last log is raised by calibrate_delay(), which calls
> calibrate_delay_converge() to compute the lpj value. 
> 
> # So far, I don't know why the jiffies stays the same.
> # But I found two methods can avoid this problem。
> 
> 1）specify the 'lpj='  with 'notsc' together.
> 
> 2)  revert the 70de9a9.
> 
> commit 70de9a97049e0ba79dc040868564408d5ce697f9
> Author: Alok Kataria 
> Date:   Mon Nov 3 11:18:47 2008 -0800
> 
> x86: don't use tsc_khz to calculate lpj if notsc is passed
> 
> Impact: fix udelay when "notsc" boot parameter is passed
> 
> With notsc passed on commandline, tsc may not be used for
> udelays, make sure that we do not use tsc_khz to calculate
> the lpj value in such cases.
> 
> IMO,
> The flow of getting tsc_khz as following,
> tsc_init()->x86_platform.calibrate_tsc()->native_calibrate_tsc()->quick_pit_calibrate().
> No codes use or call 'rdtsc'.
> 
> Even if  ‘notsc’  is passed, the tsc_khz is credible.
> and we can get lpj by it.
> 
> So I want to push a patch to revert the 70de9a9.
> Any comments or suggestions is appreciated.
> 
> Thanks,
> wei
> 
> 
>  

Re: [PATCH v2] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[Chen-Yu Tsai]

On Mon, Jun 20, 2016 at 2:42 PM, Stefan Mavrodiev
 wrote:
> A33-OLinuXino is A33 development board designed by Olimex LTD.
>
> It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector,
> headphone and mic jacks, connector for LiPo battery and optional
> 4GB NAND Flash.
>
> It has two 40-pin headers. One for LCD panel, and one for
> additional modules. Also there is CSI/DSI connector.
>
> Signed-off-by: Stefan Mavrodiev 
> ---
> Changes for v2:
> - Removed unused power nodes
> - Removed default-trigger for green led
> - Removed "always-on" option for LCD power
>
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 207 
> ++
>  2 files changed, 208 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-a33-olinuxino.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 970e906..b78f363 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -760,6 +760,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a33-ippo-q8h-v1.2.dtb \
> sun8i-a33-q8-tablet.dtb \
> sun8i-a33-sinlinx-sina33.dtb \
> +   sun8i-a33-olinuxino.dtb \
> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-h3-orangepi-2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts 
> b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
> new file mode 100644
> index 000..14fa801
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
> @@ -0,0 +1,207 @@
> +/*
> + * Copyright 2016 - Stefan Mavrodiev 
> + *  Olimex LTD. 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a33.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +   model = "A33-OLinuXino";
> +   compatible = "allwinner,sun8i-a33";
> +
> +   aliases {
> +   serial0 = &uart0;
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +
> +   leds {
> +   compatible = "gpio-leds";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&led_pin_olinuxino>;
> +
> +   green {
> +   label = "olinuxino:green:usr";
> +   gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LED2 */
> +   };
> +   };
> +};
> +
> +&ehci0 {
> +   status = "okay";
> +};
> +
> +&ohci0 {
> +   status = "okay";
> +};

Please sort the nodes alphabetically.

> +
> +&mmc0 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_olinuxino>;
> +   vmmc-supply = <®_dcdc1>;
> +   bus-width = <4>;
> +   cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> +   cd-inverted;
> +   status = "okay";
> +};
> +
> +&pio {
> +   mmc0_cd_pin_olinuxino: mmc0_cd_pin@0 {
> +   allwinner,pins =

Re: [patch net-next] net: hns: add skb_reset_mac_header() after skb being alloc

[Yisen Zhuang]

在 2016/6/15 18:30, Yisen Zhuang 写道:
> Hi David,
> 
> Thanks for your suggestions.
> 
> Please see my comments below.
> 
> Thanks,
> 
> Yisen
> 
> 在 2016/6/15 13:41, David Miller 写道:
>> From: Yisen Zhuang 
>> Date: Mon, 13 Jun 2016 20:41:22 +0800
>>
>>> From: Kejian Yan 
>>>
>>> HNS receives a packet without doing anything, but it should call
>>> skb_reset_mac_header() to initialize the header before using
>>> eth_hdr().
>>>
>>> Fixes: 0d6b425a3773c3445b0f51b2f333821beaacb619
>>> Signed-off-by: Kejian Yan 
>>> Signed-off-by: Yisen Zhuang 
>>
>> Well, this patch made me look at this function.
>>
>> You really shouldn't be filtering packets looped back, that is
>> the stack's job.  It shouldn't be happening in the driver.
> 
> If we use ping6 to test if it is connected to network, CPUs would send out 
> the NS packets
> and these packets will be looped back to CPUs. If driver does not drop these 
> packets,
> they will be sent to protocol stack and protocol stack consider that there is 
> a device
> with the same address and it is not available address. It will show us the 
> log like
> "connect: Cannot assign requested address". Then it can not connect to the 
> network enviroment.
> Thus, we drop these packets looped back in HNS driver.
> 

Hi David,

What is the opinion about this issue? We need this patch to resolve the issue.

Hoping for your suggestions.

Many thanks,

Yisen

>>
>> And once you remove that code, this patch here is no longer
>> necessary.
>>
>> Second of all, unless you card supports every protocol that
>> exists in the past, present, and _future_ you cannot set
>> skb->ip_summed to CHECKSUM_UNNECSSARY unconditionally like
>> that.
>>
>> You can only set that for protocols your chip actually supports.
> 
> Thanks for your suggestions. I will prepare a new patch to fix it.
> 
>>
>> .
>>
> 
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> 

Re: [PATCH v2 3/3] KVM: VMX: enable guest access to LMCE related MSRs

[Paolo Bonzini]

On 20/06/2016 03:49, Haozhong Zhang wrote:
> Thanks for the explanation!
> 
> If we disable LMCE in QEMU by default (even for -cpu host), will it
> still be a problem? That is,
> 
> - pc-2.7 can continue to run on old kernels unless users explicitly
>   require LMCE
> 
> - existing libvirt VM configurations can continue to work on pc-2.7
>   because LMCE is not specified in those configurations and are
>   disabled by default (i.e. no requirement for new kernels)
> 
> - existing QEMU configurations/scripts using pc alias can continue to
>   work on pc-27 for the same reason above.

Yes, that would be fine.  "-cpu host" can leave LMCE enabled if
supported by the kernel.

Paolo

Re: [PATCH v3] cpu/hotplug: handle unbalanced hotplug enable/disable

[Lianwei Wang]

On Thu, Jun 9, 2016 at 11:43 PM, Lianwei Wang  wrote:
> Currently it just print a warning message but did not
> reset cpu_hotplug_disabled when the enable/disable is
> unbalanced. The unbalanced enable/disable will lead
> the cpu hotplug work abnormally.
>
> Do nothing if an unablanced hotplug enable detected.
>
> Signed-off-by: Lianwei Wang 
> ---
>  kernel/cpu.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 3e3f6e49eabb..5e26a3c64934 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -245,6 +245,14 @@ void cpu_hotplug_done(void)
> cpuhp_lock_release();
>  }
>
> +static void __cpu_hotplug_enable(void)
> +{
> +   if (WARN_ONCE(!cpu_hotplug_disabled, "Unbalanced cpu hotplug 
> enable\n"))
> +   return;
> +
> +   cpu_hotplug_disabled--;
> +}
> +
>  /*
>   * Wait for currently running CPU hotplug operations to complete (if any) and
>   * disable future CPU hotplug (from sysfs). The 'cpu_add_remove_lock' 
> protects
> @@ -263,7 +271,7 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
>  void cpu_hotplug_enable(void)
>  {
> cpu_maps_update_begin();
> -   WARN_ON(--cpu_hotplug_disabled < 0);
> +   __cpu_hotplug_enable();
> cpu_maps_update_done();
>  }
>  EXPORT_SYMBOL_GPL(cpu_hotplug_enable);
> @@ -1091,7 +1099,7 @@ void enable_nonboot_cpus(void)
>
> /* Allow everyone to use the CPU hotplug again */
> cpu_maps_update_begin();
> -   WARN_ON(--cpu_hotplug_disabled < 0);
> +   __cpu_hotplug_enable();
> if (cpumask_empty(frozen_cpus))
> goto out;
>
> --
> 1.9.1
>

Hi Thomas Gleixner,

Does this change look good to you?

Re: [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> The OTG core will use struct otg_gadget_ops to
> start/stop the gadget controller.
>
> The main purpose of this interface is to avoid directly
> calling usb_gadget_start/stop() from the OTG core as they
> wouldn't be defined in the built-in symbol table if
> CONFIG_USB_GADGET is m.
>
> Signed-off-by: Roger Quadros 
> ---
>  include/linux/usb/gadget.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 2dd9e6b..f4fc0aa 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -639,6 +639,22 @@ struct usb_gadget_driver {
>  };
>  
>  
> +/*-*/
> +
> +/**
> + * struct otg_gadget_ops - Interface between OTG core and gadget
> + *
> + * Provided by the gadget core to allow the OTG core to start/stop the gadget
> + *
> + * @start: function to start the gadget
> + * @stop: function to stop the gadget
> + * @connect_control: function to connect/disconnect from the bus
> + */
> +struct otg_gadget_ops {
> + int (*start)(struct usb_gadget *gadget);
> + int (*stop)(struct usb_gadget *gadget);
> + int (*connect_control)(struct usb_gadget *gadget, bool connect);
> +};

you shouldn't need these at all. They are already part of the gadget
framework as ->udc_start(), ->udc_stop() and ->pullup()

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v4 7/7] max8903: adds support for initiation via device tree

[Chris Lapa]

From: Chris Lapa 

Adds support for device tree to setup a max8903 battery charger. DC and USB
validity are determined by looking the presence of the dok and uok gpios.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 78 +
 1 file changed, 72 insertions(+), 6 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 9453bbf..47e3929 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -23,6 +23,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -75,6 +78,7 @@ static int max8903_get_property(struct power_supply *psy,
default:
return -EINVAL;
}
+
return 0;
 }
 
@@ -179,6 +183,56 @@ static irqreturn_t max8903_fault(int irq, void *_data)
return IRQ_HANDLED;
 }
 
+static struct max8903_pdata *max8903_parse_dt_data(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct max8903_pdata *pdata = NULL;
+
+   if (!np)
+   return NULL;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata->dc_valid = false;
+   pdata->usb_valid = false;
+
+   pdata->cen = of_get_named_gpio(np, "cen-gpios", 0);
+   if (!gpio_is_valid(pdata->cen))
+   pdata->cen = -EINVAL;
+
+   pdata->chg = of_get_named_gpio(np, "chg-gpios", 0);
+   if (!gpio_is_valid(pdata->chg))
+   pdata->chg = -EINVAL;
+
+   pdata->flt = of_get_named_gpio(np, "flt-gpios", 0);
+   if (!gpio_is_valid(pdata->flt))
+   pdata->flt = -EINVAL;
+
+   pdata->usus = of_get_named_gpio(np, "usus-gpios", 0);
+   if (!gpio_is_valid(pdata->usus))
+   pdata->usus = -EINVAL;
+
+   pdata->dcm = of_get_named_gpio(np, "dcm-gpios", 0);
+   if (!gpio_is_valid(pdata->dcm))
+   pdata->dcm = -EINVAL;
+
+   pdata->dok = of_get_named_gpio(np, "dok-gpios", 0);
+   if (!gpio_is_valid(pdata->dok))
+   pdata->dok = -EINVAL;
+   else
+   pdata->dc_valid = true;
+
+   pdata->uok = of_get_named_gpio(np, "uok-gpios", 0);
+   if (!gpio_is_valid(pdata->uok))
+   pdata->uok = -EINVAL;
+   else
+   pdata->usb_valid = true;
+
+   return pdata;
+}
+
 static int max8903_setup_gpios(struct platform_device *pdev)
 {
struct max8903_data *data = platform_get_drvdata(pdev);
@@ -298,16 +352,20 @@ static int max8903_probe(struct platform_device *pdev)
struct power_supply_config psy_cfg = {};
int ret = 0;
 
-   if (pdata == NULL) {
-   dev_err(dev, "No platform data.\n");
-   return -EINVAL;
-   }
-
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
if (!data)
return -ENOMEM;
 
-   data->pdata = pdev->dev.platform_data;
+   if (IS_ENABLED(CONFIG_OF) && !pdata && dev->of_node)
+   pdata = max8903_parse_dt_data(dev);
+
+   if (!pdata) {
+   dev_err(dev, "No platform data.\n");
+   return -EINVAL;
+   }
+
+   pdev->dev.platform_data = pdata;
+   data->pdata = pdata;
data->dev = dev;
platform_set_drvdata(pdev, data);
 
@@ -328,6 +386,7 @@ static int max8903_probe(struct platform_device *pdev)
data->psy_desc.properties = max8903_charger_props;
data->psy_desc.num_properties = ARRAY_SIZE(max8903_charger_props);
 
+   psy_cfg.of_node = dev->of_node;
psy_cfg.drv_data = data;
 
data->psy = devm_power_supply_register(dev, &data->psy_desc, &psy_cfg);
@@ -378,10 +437,17 @@ static int max8903_probe(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id max8903_match_ids[] = {
+   { .compatible = "maxim,max8903-charger", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, max8903_match_ids);
+
 static struct platform_driver max8903_driver = {
.probe  = max8903_probe,
.driver = {
.name   = "max8903-charger",
+   .of_match_table = max8903_match_ids
},
 };
 
-- 
1.9.1

[PATCH v4 2/7] max8903: store pointer to pdata instead of copying it.

[Chris Lapa]

From: Chris Lapa 

Stores pointer to pdata because it easily allows pdata to reference
either platform data or in the future device tree data.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 17876ca..0a5b0e1 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -29,7 +29,7 @@
 #include 
 
 struct max8903_data {
-   struct max8903_pdata pdata;
+   struct max8903_pdata *pdata;
struct device *dev;
struct power_supply *psy;
struct power_supply_desc psy_desc;
@@ -53,8 +53,8 @@ static int max8903_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
-   if (data->pdata.chg) {
-   if (gpio_get_value(data->pdata.chg) == 0)
+   if (data->pdata->chg) {
+   if (gpio_get_value(data->pdata->chg) == 0)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (data->usb_in || data->ta_in)
val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
@@ -81,7 +81,7 @@ static int max8903_get_property(struct power_supply *psy,
 static irqreturn_t max8903_dcin(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = &data->pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool ta_in;
enum power_supply_type old_type;
 
@@ -122,7 +122,7 @@ static irqreturn_t max8903_dcin(int irq, void *_data)
 static irqreturn_t max8903_usbin(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = &data->pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool usb_in;
enum power_supply_type old_type;
 
@@ -161,7 +161,7 @@ static irqreturn_t max8903_usbin(int irq, void *_data)
 static irqreturn_t max8903_fault(int irq, void *_data)
 {
struct max8903_data *data = _data;
-   struct max8903_pdata *pdata = &data->pdata;
+   struct max8903_pdata *pdata = data->pdata;
bool fault;
 
fault = gpio_get_value(pdata->flt) ? false : true;
@@ -190,12 +190,18 @@ static int max8903_probe(struct platform_device *pdev)
int ta_in = 0;
int usb_in = 0;
 
+   if (pdata == NULL) {
+   dev_err(dev, "No platform data.\n");
+   return -EINVAL;
+   }
+
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
if (data == NULL) {
dev_err(dev, "Cannot allocate memory.\n");
return -ENOMEM;
}
-   memcpy(&data->pdata, pdata, sizeof(struct max8903_pdata));
+
+   data->pdata = pdev->dev.platform_data;
data->dev = dev;
platform_set_drvdata(pdev, data);
 
-- 
1.9.1

[PATCH v4 6/7] max8903: remove unnecessary 'out of memory' error message.

[Chris Lapa]

From: Chris Lapa 

Remove the 'out of memory' error message as it is printed by the core.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 643a87a..9453bbf 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -304,10 +304,8 @@ static int max8903_probe(struct platform_device *pdev)
}
 
data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
-   if (data == NULL) {
-   dev_err(dev, "Cannot allocate memory.\n");
+   if (!data)
return -ENOMEM;
-   }
 
data->pdata = pdev->dev.platform_data;
data->dev = dev;
-- 
1.9.1

[lkp] [fs] c43edc7bd9: BUG: unable to handle kernel NULL pointer dereference at 00000450

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Deepa-Dinamani/Delete-CURRENT_TIME-and-CURRENT_TIME_SEC-macros/20160620-104147
commit c43edc7bd9c06af9a7278101d462eb0ba0299605 ("fs: Replace CURRENT_TIME with 
current_time() for inode timestamps")


on test machine: vm-kbuild-yocto-i386: 2 threads qemu-system-i386 -enable-kvm 
with 320M memory

caused below changes:


++++
|| 58b11bff28 | 
c43edc7bd9 |
++++
| boot_successes | 0  | 0   
   |
| boot_failures  | 6  | 14  
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(goldfish_pdev_bus) | 6  | 
   |
| genirq:Flags_mismatch_irq  | 1  | 
   |
| BUG:unable_to_handle_kernel| 0  | 14  
   |
| Oops   | 0  | 14  
   |
| EIP_is_at_current_time | 0  | 14  
   |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 14  
   |
| backtrace:_do_fork | 0  | 14  
   |
++++



Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
CPU: Intel QEMU Virtual CPU version 2.4.0 (family: 0x6, model: 0x6, stepping: 
0x3)
BUG: unable to handle kernel NULL pointer dereference at 0450
IP: [<810d76ba>] current_time+0x17/0x2b
*pde =  
Oops:  [#1] DEBUG_PAGEALLOC
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc3-next-20160617-2-gc43edc7 
#1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 
04/01/2014
task: 8182c600 ti: 81826000 task.ti: 81826000
EIP: 0060:[<810d76ba>] EFLAGS: 00210246 CPU: 0
EIP is at current_time+0x17/0x2b
EAX:  EBX: 92804dcc ECX: 0008 EDX: 1b0ef314
ESI: 92804dcc EDI: 81842680 EBP: 81827e0c ESP: 81827dfc
 DS: 007b ES: 007b FS:  GS:  SS: 0068
CR0: 80050033 CR2: 0450 CR3: 01922000 CR4: 0690
Stack:
 576775b1  1b0ef314 92804db0 81827e1c 810ff1ea 92c27800 92c27800
 81827e2c 810d6db3 92c27800 8184da40 81827e3c 810d7f57 92c27800 8184da40
 81827e4c 810ff40e 92c27800  81827e58 810ff527 92c27800 81827e70
Call Trace:
 [<810ff1ea>] proc_alloc_inode+0x56/0x70
 [<810d6db3>] alloc_inode+0x14/0x5f
 [<810d7f57>] new_inode_pseudo+0xa/0x40
 [<810ff40e>] proc_get_inode+0xc/0xe5
 [<810ff527>] proc_fill_super+0x40/0x80
 [<810ff71d>] proc_mount+0x93/0xce
 [<810c5cf2>] mount_fs+0xe/0x7a
 [<810d9dcf>] vfs_kern_mount+0x4b/0xf5
 [<810d9e89>] kern_mount_data+0x10/0x21
 [<810ff81f>] pid_ns_prepare_proc+0x12/0x21
 [<8103ac1d>] alloc_pid+0x233/0x2ea
 [<8103c5b4>] ? create_new_namespaces+0x121/0x121
 [<810283df>] copy_process+0xc5a/0x1232
 [<81501e05>] ? rest_init+0xa2/0xa2
 [<812b4b49>] ? acpi_hw_read+0xe9/0x15f
 [<81028acc>] _do_fork+0x61/0x28f
 [<812b4d37>] ? acpi_hw_register_read+0x4f/0xaf
 [<812b5511>] ? acpi_read_bit_register+0x1e/0x3d
 [<81501e05>] ? rest_init+0xa2/0xa2
 [<81028d16>] kernel_thread+0x1c/0x21
 [<81501d7d>] rest_init+0x1a/0xa2
 [<818adac9>] start_kernel+0x34e/0x353
 [<818ad2b5>] i386_start_kernel+0xa0/0xa4
Code: 00 89 e5 b8 00 1a 84 81 e8 ab 67 f5 ff eb 03 b0 01 c3 5d c3 55 89 e5 53 
89 c3 83 ec 0c 8d 45 f0 e8 4a b8 f8 ff 8b 43 1c 8b 55 f8 <8b> 88 50 04 00 00 8b 
45 f0 e8 40 6b f8 ff 83 c4 0c 5b 5d c3 55
EIP: [<810d76ba>] current_time+0x17/0x2b SS:ESP 0068:81827dfc
CR2: 0450
---[ end trace a8594f352bea28f0 ]---
Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -kernel 
/pkg/linux/i386-randconfig-n0-201625/gcc-6/c43edc7bd9c06af9a7278101d462eb0ba0299605/vmlinuz-4.7.0-rc3-next-20160617-2-gc43edc7
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-i386-29/bisect_boot-1-yocto-minimal-i386.cgz-i386-randconfig-n0-201625-c43edc7bd9c06af9a7278101d462eb0ba0299605-20160620-50311-gdkngs-0.yaml~
 ARCH=i386 kconfig=i386-randconfig-n0-201625 
branch=linux-review/Deepa-Dinamani/Delete-CURRENT_TIME-and-CURRENT_TIME_SEC-macros/20160620-104147
 commit=c43edc7bd9c06af9a7278101d462eb0ba0299605 
BOOT_IMAGE=/pkg/linux/i386-randconfig-n0-201625/gcc-6/c43edc7bd9c06af9a7278101d462eb0ba0299605/vmlinuz-4.7.0-rc3-next-20160617-2-gc43edc7
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-n0-201625/gcc-

[PATCH v4 4/7] max8903: adds requesting of gpios.

[Chris Lapa]

From: Chris Lapa 

This change ensures all gpios are available for the driver to use and also
splits off gpio setup into its own function for readability.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 136 ++--
 1 file changed, 102 insertions(+), 34 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 6ec705f..3f35593 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -179,39 +179,27 @@ static irqreturn_t max8903_fault(int irq, void *_data)
return IRQ_HANDLED;
 }
 
-static int max8903_probe(struct platform_device *pdev)
+static int max8903_setup_gpios(struct platform_device *pdev)
 {
-   struct max8903_data *data;
+   struct max8903_data *data = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;
struct max8903_pdata *pdata = pdev->dev.platform_data;
-   struct power_supply_config psy_cfg = {};
int ret = 0;
int gpio;
int ta_in = 0;
int usb_in = 0;
 
-   if (pdata == NULL) {
-   dev_err(dev, "No platform data.\n");
-   return -EINVAL;
-   }
-
-   data = devm_kzalloc(dev, sizeof(struct max8903_data), GFP_KERNEL);
-   if (data == NULL) {
-   dev_err(dev, "Cannot allocate memory.\n");
-   return -ENOMEM;
-   }
-
-   data->pdata = pdev->dev.platform_data;
-   data->dev = dev;
-   platform_set_drvdata(pdev, data);
-
-   if (pdata->dc_valid == false && pdata->usb_valid == false) {
-   dev_err(dev, "No valid power sources.\n");
-   return -EINVAL;
-   }
-
if (pdata->dc_valid) {
if (pdata->dok && gpio_is_valid(pdata->dok)) {
+   ret = devm_gpio_request(dev, pdata->dok,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dok: %d err 
%d\n",
+   pdata->dok, ret);
+   return ret;
+   }
+
gpio = pdata->dok; /* PULL_UPed Interrupt */
ta_in = gpio_get_value(gpio) ? 0 : 1;
} else {
@@ -222,6 +210,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->dcm) {
if (gpio_is_valid(pdata->dcm)) {
+   ret = devm_gpio_request(dev, pdata->dcm,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dcm: %d err 
%d\n",
+   pdata->dcm, ret);
+   return ret;
+   }
+
gpio = pdata->dcm; /* Output */
gpio_set_value(gpio, ta_in);
} else {
@@ -232,6 +229,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->usb_valid) {
if (pdata->uok && gpio_is_valid(pdata->uok)) {
+   ret = devm_gpio_request(dev, pdata->uok,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for uok: %d err 
%d\n",
+   pdata->uok, ret);
+   return ret;
+   }
+
gpio = pdata->uok;
usb_in = gpio_get_value(gpio) ? 0 : 1;
} else {
@@ -243,6 +249,15 @@ static int max8903_probe(struct platform_device *pdev)
 
if (pdata->cen) {
if (gpio_is_valid(pdata->cen)) {
+   ret = devm_gpio_request(dev, pdata->cen,
+   data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for cen: %d err 
%d\n",
+   pdata->cen, ret);
+   return ret;
+   }
+
gpio_set_value(pdata->cen, (ta_in || usb_in) ? 0 : 1);
} else {
dev_err(dev, "Invalid pin: cen.\n");
@@ -251,23 +266,41 @@ static int max8903_probe(struct platform_device *pdev)
}
 
if (pdata->chg) {
-   if (!gpio_is_valid(pdata->chg)) {
-   dev_err(dev, "Invalid pin: chg.\n");
-   return -EINVAL;
+   if (gpio_is_valid(pdata->chg)) {
+   ret = devm_gpio_request(dev, pdata->chg,
+   

[PATCH v4 0/7] max8903: Add device tree support and misc fixes

[Chris Lapa]

From: Chris Lapa 

This patch set adds device tree support for the MAX8903 battery charger.
It also cleans up logic with dc_valid, dok and dcm pins as well as
fixing up validity checking of gpios.

I verified these patches work on a board I have here, which uses the
DC power side (not the USB portition) of the MAX8903.

Changes v3 -> v4:
 * Fixed formatting, such as multiline strings and indentation mistakes
 * Moved gpio setup code into max8903_setup_gpios() in 3/7
 * Fixed typo in 5/7
 * Renamed of_node to np in 7/7

Changes v2 -> v3:
 * Separate requesting of gpio's into its own commit
 * Fixed up validity checking of GPIO's
 * Remove dc_valid and usb_valid from device tree
 * Remove some unncessary init to psy_cfg.num_supplicants and 
psy_cfg.supplied_to
 * Reorder patches so device tree implementation is final patch

Changes v1 -> v2:
 * Separate DT bindings documentation into its own commit
 * Add maxim prefix to DT compatible field
 * Add gpios suffix to gpio's in DT
 * Remove malloc failed error message

Chris Lapa (7):
  max8903: adds documentation for device tree bindings.
  max8903: store pointer to pdata instead of copying it.
  max8903: cleans up confusing relationship between dc_valid, dok and
dcm.
  max8903: adds requesting of gpios.
  max8903: removes non zero validity checks on gpios.
  max8903: remove unnecessary 'out of memory' error message.
  max8903: adds support for initiation via device tree

 .../devicetree/bindings/power/max8903-charger.txt  |  25 +++
 drivers/power/max8903_charger.c| 239 +++--
 include/linux/power/max8903_charger.h  |   6 +-
 3 files changed, 204 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt

-- 
1.9.1

[PATCH v4 1/7] max8903: adds documentation for device tree bindings.

[Chris Lapa]

From: Chris Lapa 

Signed-off-by: Chris Lapa 
---
 .../devicetree/bindings/power/max8903-charger.txt  | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/max8903-charger.txt

diff --git a/Documentation/devicetree/bindings/power/max8903-charger.txt 
b/Documentation/devicetree/bindings/power/max8903-charger.txt
new file mode 100644
index 000..aea1dd2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/max8903-charger.txt
@@ -0,0 +1,25 @@
+Maxim Semiconductor MAX8903 Battery Charger bindings
+
+Required properties:
+- compatible: "maxim,max8903-charger" for MAX8903 Battery Charger
+- dok-gpios: Valid DC power has been detected, optional if uok-gpios is 
provided
+- uok-gpios: Valid USB power has been detected, optional if dok-gpios is 
provided
+
+Optional properties:
+- cen-gpios: Charge enable pin
+- chg-gpios: Charger status pin
+- flt-gpios: Fault pin
+- dcm-gpios: Current limit mode setting (DC or USB)
+- usus-gpios: USB suspend pin
+
+
+Example:
+
+   max8903-charger {
+   compatible = "maxim,max8903-charger";
+   dok-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
+   flt-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>;
+   chg-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
+   cen-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+   status = "okay";
+   };
-- 
1.9.1

Re: kernel, mm: NULL deref in copy_process while OOMing

[Michal Hocko]

On Sun 19-06-16 12:06:53, Tetsuo Handa wrote:
> On 2016/06/16 18:39, Michal Hocko wrote:
> > On Wed 15-06-16 12:50:43, Sasha Levin wrote:
> >> Hi all,
> >>
> >> I'm seeing the following NULL ptr deref in copy_process right after a bunch
> >> of OOM killing activity on -next kernels:
> >>
> >> Out of memory (oom_kill_allocating_task): Kill process 3477 (trinity-c159) 
> >> score 0 or sacrifice child
> >> Killed process 3477 (trinity-c159) total-vm:3226820kB, anon-rss:36832kB, 
> >> file-rss:1640kB, shmem-rss:444kB
> >> oom_reaper: reaped process 3477 (trinity-c159), now anon-rss:0kB, 
> >> file-rss:0kB, shmem-rss:444kB
> >> Out of memory (oom_kill_allocating_task): Kill process 3450 (trinity-c156) 
> >> score 0 or sacrifice child
> >> Killed process 3450 (trinity-c156) total-vm:3769768kB, anon-rss:36832kB, 
> >> file-rss:1652kB, shmem-rss:508kB
> >> oom_reaper: reaped process 3450 (trinity-c156), now anon-rss:0kB, 
> >> file-rss:0kB, shmem-rss:572kB
> >> BUG: unable to handle kernel NULL pointer dereference at 0150
> >> IP: copy_process (./arch/x86/include/asm/atomic.h:103 kernel/fork.c:484 
> >> kernel/fork.c:964 kernel/fork.c:1018 kernel/fork.c:1484)
> >> PGD 1ff944067 PUD 1ff929067 PMD 0
> >> Oops: 0002 [#1] PREEMPT SMP KASAN
> >> Modules linked in:
> >> CPU: 18 PID: 8761 Comm: trinity-main Not tainted 
> >> 4.7.0-rc3-sasha-02101-g1e1b9fa #3108
> > 
> > Is this a common parent of the oom killed children?
> > 
> >> task: 880165564000 ti: 880337ad task.ti: 880337ad
> >> RIP: copy_process (./arch/x86/include/asm/atomic.h:103 kernel/fork.c:484 
> >> kernel/fork.c:964 kernel/fork.c:1018 kernel/fork.c:1484)
> > 
> > IIUC this should be:
> > _do_fork
> >   copy_process
> > copy_mm
> >   dup_mm
> > dup_mmap
> >   if (tmp->vm_flags & VM_DENYWRITE)
> > atomic_dec(&inode->i_writecount);
> > 
> > I am not really sure how f->f_inode can become NULL when file should pin
> > the inode AFAIR, and VMA should pin the file. Anyway this shouldn't be
> > directly related to the OOM killer or at least the recent changes
> > in that area because the oom reaper doesn't touch VMAs file.
> 
> These OOM messages say that oom_kill_allocating_task != 0 is used.
> That is, a __GFP_FS allocation by a child process which is trying to
> duplicate the parent's mm_struct was killed by the OOM killer and
> reaped by the OOM reaper. I guess that mmap related stuff are not
> fully initialized (or consistent) yet while the OOM reaper assumed
> that it is safe to access such child's mmap related stuff.

I will double check but the oom_reaper only unmaps VMAs. We are not
deleting or modifying the VMA layout or disassociate VMAs from their
files. So I do not see how this could be related.
 
> So, if this bug is reproducible (I thing it is), first try to reproduce
> this bug without the OOM reaper enabled (i.e. comment out the

Yes, that would be definitely good to test.

> 
> subsys_initcall(oom_init)
> 
> line in mm/oom_kill.c ).

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface

[Roger Quadros]

On 20/06/16 10:21, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> The OTG core will use struct otg_gadget_ops to
>> start/stop the gadget controller.
>>
>> The main purpose of this interface is to avoid directly
>> calling usb_gadget_start/stop() from the OTG core as they
>> wouldn't be defined in the built-in symbol table if
>> CONFIG_USB_GADGET is m.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  include/linux/usb/gadget.h | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index 2dd9e6b..f4fc0aa 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -639,6 +639,22 @@ struct usb_gadget_driver {
>>  };
>>  
>>  
>> +/*-*/
>> +
>> +/**
>> + * struct otg_gadget_ops - Interface between OTG core and gadget
>> + *
>> + * Provided by the gadget core to allow the OTG core to start/stop the 
>> gadget
>> + *
>> + * @start: function to start the gadget
>> + * @stop: function to stop the gadget
>> + * @connect_control: function to connect/disconnect from the bus
>> + */
>> +struct otg_gadget_ops {
>> +int (*start)(struct usb_gadget *gadget);
>> +int (*stop)(struct usb_gadget *gadget);
>> +int (*connect_control)(struct usb_gadget *gadget, bool connect);
>> +};
> 
> you shouldn't need these at all. They are already part of the gadget
> framework as ->udc_start(), ->udc_stop() and ->pullup()
> 

This is to avoid the undefined symbol errors during build when OTG has is
built-in because USB (host) is built-in but GADGET is still a module.

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [RFC 12/12] x86/dumpstack: Optimize save_stack_trace

[xinhui]

On 2016年06月20日 12:55, Byungchul Park wrote:

Currently, x86 implementation of save_stack_trace() is walking all stack
region word by word regardless of what the trace->max_entries is.
However, it's unnecessary to walk after already fulfilling caller's
requirement, say, if trace->nr_entries >= trace->max_entries is true.

For example, CONFIG_LOCKDEP_CROSSRELEASE implementation calls
save_stack_trace() with max_entries = 5 frequently. I measured its
overhead and printed its difference of sched_clock() with my QEMU x86
machine.

The latency was improved over 70% when trace->max_entries = 5.


[snip]


+static int save_stack_end(void *data)
+{
+   struct stack_trace *trace = data;
+   return trace->nr_entries >= trace->max_entries;
+}
+
  static const struct stacktrace_ops save_stack_ops = {
.stack  = save_stack_stack,
.address= save_stack_address,

then why not check the return value of ->address(), -1 indicate there is no 
room to store any pointer.


.walk_stack = print_context_stack,
+   .end_walk   = save_stack_end,
  };

  static const struct stacktrace_ops save_stack_ops_nosched = {

Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms

[Gabriel Fernandez]

Hi Rob,

On 19 June 2016 at 17:04, Rob Herring  wrote:
> On Thu, Jun 16, 2016 at 11:20:22AM +0200, Gabriel Fernandez wrote:
>> This patch reworks the clock binding to avoid too much detail in DT.
>> Now we have only compatible string per type of clock
>> (remark from Rob https://lkml.org/lkml/2016/5/25/492)
>>
>
> I have no idea what the clock trees and clock controller in these chips
> look like, so it's hard to say if the changes here are good. It still
> looks like things are somewhat fine grained clocks in DT. I'll leave
> it up to the platform maintainers to decide...
>
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>  .../devicetree/bindings/clock/st/st,clkgen-mux.txt |  2 +-
>>  .../devicetree/bindings/clock/st/st,clkgen-pll.txt | 11 ++--
>>  .../devicetree/bindings/clock/st/st,clkgen.txt |  2 +-
>>  .../devicetree/bindings/clock/st/st,quadfs.txt |  6 +--
>>  drivers/clk/st/clkgen-fsyn.c   | 41 ++
>>  drivers/clk/st/clkgen-mux.c| 28 --
>>  drivers/clk/st/clkgen-pll.c| 62 
>> ++
>>  7 files changed, 65 insertions(+), 87 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt 
>> b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
>> index 4d277d6..9a46cb1d7 100644
>> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
>> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
>> @@ -10,7 +10,7 @@ This binding uses the common clock binding[1].
>>  Required properties:
>>
>>  - compatible : shall be:
>> - "st,stih407-clkgen-a9-mux", "st,clkgen-mux"
>> + "st,stih407-clkgen-a9-mux"
>>
>>  - #clock-cells : from common clock binding; shall be set to 0.
>>
>> diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt 
>> b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
>> index c9fd674..be0b043 100644
>> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
>> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
>> @@ -9,11 +9,10 @@ Base address is located to the parent node. See clock 
>> binding[2]
>>  Required properties:
>>
>>  - compatible : shall be:
>> - "st,stih407-plls-c32-a0",   "st,clkgen-plls-c32"
>> - "st,stih407-plls-c32-a9",   "st,clkgen-plls-c32"
>> - "sst,plls-c32-cx_0","st,clkgen-plls-c32"
>> - "sst,plls-c32-cx_1","st,clkgen-plls-c32"
>> - "st,stih418-plls-c28-a9",   "st,clkgen-plls-c32"
>
>> + "st,clkgen-pll0"
>> + "st,clkgen-pll0"
>
> Repeated. Supposed to be 0 and 1? This seems a bit generic, too.
Yes you are right, it's 0 and 1.
I wait remarks from Mike or Stephen before send a V3.

Thanks Rob

BR
Gabriel

>
>> + "st,stih407-clkgen-plla9"
>> + "st,stih418-clkgen-plla9"

Re: [RESEND PATCH v9 00/22] Add HiSilicon RoCE driver

[oulijun]

On 2016/6/8 19:55, Doug Ledford wrote:
> On 6/8/2016 2:44 AM, Lijun Ou wrote:
>> The HiSilicon Network Substem is a long term evolution IP which is
>> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
>> Sybsystem) also has a hardware support of performing RDMA with
>> RoCEE.
>> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and
>> will support mulitple versions of SOCs in future. This version of driver
>> is meant to support Hip06 SoC(which confirms to RoCEEv1 hardware
>> specifications).
> 
> Please don't resend unless you think the patch has gotten lost.  This is
> a large patchset and takes a considerable deal of time to process.
> 
> That said, I pulled the v9 patchset into my repo in a branch called hns
> yesterday and am doing final review before I accept it into my for-next
> area.
> 
Hi, Doug
  I see. Please forgive my impatience.
  Now, I have sent v10 according to Leon Romanovsky's reviews.

Thanks
Lijun Ou

[lkp] [x86 tsc] 19fa5e7364: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x72/0x80

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git x86
commit 19fa5e73647fde1e6a7038a8f05cddf4c43f08d3 ("x86 tsc: enumerate SKL 
cpu_khz and tsc_khz via CPUID")


on test machine: vm-kbuild-yocto-x86_64: 1 threads qemu-system-x86_64 
-enable-kvm -cpu SandyBridge with 320M memory

caused below changes:


+--+++
|  | cc50dc7f73 
| 19fa5e7364 |
+--+++
| boot_successes   | 0  
| 0  |
| boot_failures| 10 
| 12 |
| invoked_oom-killer:gfp_mask=0x   | 10 
| 10 |
| Mem-Info | 10 
| 10 |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 10 
| 10 |
| backtrace:btrfs_test_extent_io   | 10 
| 10 |
| backtrace:init_btrfs_fs  | 10 
| 10 |
| backtrace:kernel_init_freeable   | 10 
| 10 |
| WARNING:at_arch/x86/mm/extable.c:#ex_handler_rdmsr_unsafe| 0  
| 10 |
| backtrace:native_calibrate_cpu   | 0  
| 10 |
| backtrace:tsc_init   | 0  
| 10 |
| backtrace:x86_late_time_init | 0  
| 10 |
+--+++



[0.00] clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 19112604467 ns
[0.00] hpet clockevent registered
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 
ex_handler_rdmsr_unsafe+0x72/0x80
[0.00] unchecked MSR access error: RDMSR from 0xce
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.7.0-rc3-9-g19fa5e7 #1
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.00]   83203c38 816da89d 
83203c88
[0.00]   82e71808 8104e8c2 
83203c78
[0.00]  810b796b 00328453b4a0 82e71808 
0032
[0.00] Call Trace:
[0.00]  [] dump_stack+0x83/0xb6
[0.00]  [] ? ex_handler_rdmsr_unsafe+0x72/0x80
[0.00]  [] __warn+0x10b/0x130
[0.00]  [] warn_slowpath_fmt+0x63/0x70
[0.00]  [] ex_handler_rdmsr_unsafe+0x72/0x80
[0.00]  [] fixup_exception+0x46/0x60
[0.00]  [] do_general_protection+0x7b/0x150
[0.00]  [] general_protection+0x28/0x30
[0.00]  [] ? native_read_msr+0x6/0x20
[0.00]  [] cpu_khz_from_msr+0xf1/0x150
[0.00]  [] ? trap_init+0x22e/0x22e
[0.00]  [] native_calibrate_cpu+0x85/0x5b0
[0.00]  [] ? native_restore_fl+0x6/0x10
[0.00]  [] ? __setup_irq+0x196/0x750
[0.00]  [] ? trap_init+0x22e/0x22e
[0.00]  [] tsc_init+0x42/0x3c3
[0.00]  [] ? setup_irq+0x6f/0xc0
[0.00]  [] ? trap_init+0x22e/0x22e
[0.00]  [] ? trap_init+0x22e/0x22e
[0.00]  [] x86_late_time_init+0xf/0x11
[0.00]  [] ? x86_late_time_init+0xf/0x11
[0.00]  [] start_kernel+0x3f3/0x4b1
[0.00]  [] ? early_idt_handler_array+0x120/0x120
[0.00]  [] x86_64_start_reservations+0x2f/0x31
[0.00]  [] x86_64_start_kernel+0xe6/0xf3
[0.00] ---[ end trace 7c0d92684f22f4ac ]---
[0.00] tsc: Fast TSC calibration using PIT


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-32/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-w0-06180628-19fa5e73647fde1e6a7038a8f05cddf4c43f08d3-20160618-25535-h82bax-0.yaml~
 ARCH=x86_64 kconfig=x86_64-randconfig-w0-06180628 branch=internal-eywa/master 
commit=19fa5e73647fde1e6a7038a8f05cddf4c43f08d3 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/vmlinuz-4.7.0-rc3-9-g19fa5e7
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-w0-06180628/gcc-6/19fa5e73647fde1e6a7038a8f05cddf4c43f08d3/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=10

[PATCH] x86/mm: only allow memmap=XX!YY over existing RAM

[Yigal Korman]

Before this patch, passing a range that is beyond the physical memory
range will succeed, the user will see a /dev/pmem0 and will be able to
access it. Reads will always return 0 and writes will be silently
ignored.

I've gotten more than one bug report about mkfs.{xfs,ext4} or nvml
failing that were eventually tracked down to be wrong values passed to
memmap.

This patch prevents the above issue by instead of adding a new memory
range, only update a RAM memory range with the PRAM type. This way,
passing the wrong memmap will either not give you a pmem at all or give
you a smaller one that actually has RAM behind it.

And if someone still needs to fake a pmem that doesn't have RAM behind
it, they can simply do memmap=XX@YY,XX!YY.

Signed-off-by: Yigal Korman 
---
 arch/x86/kernel/e820.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 621b501..4bd4207 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -878,7 +878,7 @@ static int __init parse_memmap_one(char *p)
e820_add_region(start_at, mem_size, E820_RESERVED);
} else if (*p == '!') {
start_at = memparse(p+1, &p);
-   e820_add_region(start_at, mem_size, E820_PRAM);
+   e820_update_range(start_at, mem_size, E820_RAM, E820_PRAM);
} else
e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
 
-- 
1.9.3

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

[Heiko Carstens]

On Sun, Jun 19, 2016 at 11:01:48PM -0700, Andy Lutomirski wrote:
> > The tmll instruction tests if any of the higher bits within the 16k
> > stackframe address are set. In this specific case that would be bits 7-15
> > (mask 0x3f80). If no bit would be set we know that only up to 128 bytes
> > would be left on the stack, and thus trigger an exception.
> >
> > This check does of course only work if a 16k stack is also 16k aligned,
> > which is always the case.
> >
> 
> Oh, interesting.  How do you handle the case of a single function that
> uses more than 128 bytes of stack?

The compiler uses the next larger value of the stackframe size that is a
power of 2 for checking. So another example with a stackframe size of 472
bytes would be the below one with a mask of 0x3e00:

00392db8 :
  392db8:   eb 6f f0 48 00 24   stmg%r6,%r15,72(%r15)
  392dbe:   a7 f1 3e 00 tmll%r15,15872
  392dc2:   b9 04 00 ef lgr %r14,%r15
  392dc6:   a7 84 00 01 je  392dc8 

  392dca:   e3 f0 fe 28 ff 71   lay %r15,-472(%r15)

Re: [PATCH v2] gpio: add Intel WhiskeyCove GPIO driver

[Mika Westerberg]

On Sun, Jun 19, 2016 at 08:54:32PM -0700, Bin Gao wrote:
> > > +#define DRV_NAME "bxt_wcove_gpio"
> > 
> > Drop this.
> We have _TWO_ places using DRV_NAME(near the end of the file):
> static struct platform_driver wcove_gpio_driver = {
>.driver = {
>.name = DRV_NAME,
>},
> 
> and
> 
> MODULE_ALIAS("platform:" DRV_NAME);
> 
> You are suggesting to replace DRV_NAME with bxt_wcove_gpio(but why?)
> or something else?

Do instead this:

.driver = {
.name ="bxt_wcove_gpio",
},

and

MODULE_ALIAS("platform:bxt_wcove_gpio");

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年6月9日 4:27
> To: Yang, Wenyou 
> Cc: Alan Stern ; Greg Kroah-Hartman
> ; Ferre, Nicolas ;
> Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> Alexandre Belloni ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On Wed, Jun 08, 2016 at 12:15:10PM +0800, Wenyou Yang wrote:
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> > Changes in v3:
> >  - Change the compatible description for more precise.
> >
> > Changes in v2:
> >  - Add compatible to support forcibly suspend the ports.
> >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >  - Add error checking for .sfr_regmap.
> >  - Remove unnecessary regmap_read() statement.
> >
> >  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> >  drivers/usb/host/ohci-at91.c   | 80 
> > +-
> >  include/soc/at91/at91_sfr.h| 29 
> >  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> > 100644 include/soc/at91/at91_sfr.h
> >
> > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > index 5883b73..888deaa 100644
> > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > @@ -3,8 +3,10 @@ Atmel SOC USB controllers  OHCI
> >
> >  Required properties:
> > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > -   used in host mode.
> > + - compatible: Should be one of the following
> > +  "atmel,at91rm9200-ohci" for USB controllers used in host mode.
> > +  "atmel,sama5d2-ohci" for USB controllers used in host mode
> > +  on SAMA5D2 which can force to suspend.
> 
> Guess I wasn't clear enough before. Drop "which can force to suspend".

In previous mail, Nicolas gave a suggestion with "...on SAMA5D2 and compatible 
SoCs that must explicitly force suspend through the Special Function Register 
(SFR)."

I think it is more clear, what is your opinion?

> 
> >   - reg: Address and length of the register set for the device
> >   - interrupts: Should contain ehci interrupt
> >   - clocks: Should reference the peripheral, host and system clocks
> > diff --git a/drivers/usb/host/ohci-at91.c
> > b/drivers/usb/host/ohci-at91.c index d177372..54e8feb 100644
> > --- a/drivers/usb/host/ohci-at91.c
> > +++ b/drivers/usb/host/ohci-at91.c
> > @@ -21,8 +21,11 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "ohci.h"
> >
> > @@ -45,12 +48,18 @@ struct at91_usbh_data {
> > u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
> >  };
> >
> > +struct ohci_at91_caps {
> > +   bool suspend_ctrl;
> > +};
> > +
> >  struct ohci_at91_priv {
> > struct clk *iclk;
> > struct clk *fclk;
> > struct clk *hclk;
> > bool clocked;
> > bool wakeup;/* Saved wake-up state for resume */
> > +   const struct ohci_at91_caps *caps;
> > +   struct regmap *sfr_regmap;
> >  };
> >  /* interface and function clocks; sometimes also an AHB clock */
> >
> > @@ -132,6 +141,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   regmap = NULL;
> > +
> > +   return regmap;
> > +}
> > +
> >  static void usb_hcd_at91_remove (struct usb_hcd *, struct
> > platform_device *);
> >
> >  /* configure so an HC device and id are always provided */ @@ -197,6
> > +217,17 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->caps = (const struct ohci_at91_caps *)
> > + of_device_get_match_data(&pdev->dev);
> > +   if (!ohci_at91->caps)
> > +   return -ENODEV;
> > +
> > +   if (ohci_at91->caps->suspend_ctrl) {
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> > +   if (!ohci_at91->sfr_regmap)
> > +   dev_warn(dev, "failed to find sfr node\n");
> > +   }
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> > @@ -440,8 +471,17 @@ 

[RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding

[Nicolas Boichat]

ANX7688 is a transmitter to support DisplayPort over USB-C for
smartphone and tablets.

This binding only describes the HDMI to DP component of the chip.

Signed-off-by: Nicolas Boichat 
---
 .../devicetree/bindings/video/bridge/anx7688.txt   | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7688.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7688.txt 
b/Documentation/devicetree/bindings/video/bridge/anx7688.txt
new file mode 100644
index 000..78b55bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7688.txt
@@ -0,0 +1,32 @@
+Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C)
+-
+
+The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per
+second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video
+resolution from a smartphone or tablet with full function USB-C.
+
+This binding only describes the HDMI to DP display bridge.
+
+Required properties:
+
+ - compatible  : "analogix,anx7688"
+ - reg : I2C address of the device (fixed at 0x2c)
+
+Optional properties:
+
+ - Video port for HDMI input, using the DT bindings defined in [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   anx7688: anx7688@2c {
+   compatible = "analogix,anx7688";
+   reg = <0x2c>;
+
+   port {
+   anx7688_in: endpoint {
+   remote-endpoint = <&hdmi0_out>;
+   };
+   };
+   };
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> It provides APIs for the following tasks
>
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine

I think I have already mentioned this, but after over 10 years of OTG,
nobody seems to care about it, why are we still touching at all I don't
know. For common non-OTG role-swapping we really don't need any of this
and, quite frankly, I fail to see enough users for this.

Apparently there's only chipidea which, AFAICT, already had working
dual-role before this OTG State Machine was added to the kernel.

> Provide a dual-role device (DRD) state machine.

there's not such thing as DRD state machine. You don't need to go
through all these states, actually.

> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
>
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
>
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
>
> Signed-off-by: Roger Quadros 
> ---
> v11:
> - remove usb_otg_kick_fsm().
> - typo fixes: structa/structure, upto/up to.
> - remove "obj-$(CONFIG_USB_OTG_CORE) += common/" from Makefile.
>
>  drivers/usb/Kconfig  |  18 +
>  drivers/usb/common/Makefile  |   6 +-
>  drivers/usb/common/usb-otg.c | 877 
> +++
>  drivers/usb/core/Kconfig |  14 -
>  drivers/usb/gadget/Kconfig   |   1 +
>  include/linux/usb/gadget.h   |   2 +
>  include/linux/usb/hcd.h  |   1 +
>  include/linux/usb/otg-fsm.h  |   7 +
>  include/linux/usb/otg.h  | 174 -
>  9 files changed, 1070 insertions(+), 30 deletions(-)
>  create mode 100644 drivers/usb/common/usb-otg.c
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8689dcb..ed596ec 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -32,6 +32,23 @@ if USB_SUPPORT
>  config USB_COMMON
>   tristate
>  
> +config USB_OTG_CORE
> + tristate

why tristate if you can never set it to 'M'?

> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> new file mode 100644
> index 000..a23ab1e
> --- /dev/null
> +++ b/drivers/usb/common/usb-otg.c
> @@ -0,0 +1,877 @@
> +/**
> + * drivers/usb/common/usb-otg.c - USB OTG core
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Roger Quadros 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* OTG device list */
> +LIST_HEAD(otg_list);

not static? Who needs to touch this private list?

> +static DEFINE_MUTEX(otg_list_mutex);
> +
> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
> +{
> + if (!hcd->primary_hcd)
> + return 1;

these seems inverted. If hcd->primary is NULL (meaning, there's no
->primary_hcd), then we tell caller that this _is_ a primary hcd? Care
to explain?

> + return hcd == hcd->primary_hcd;
> +}
> +
> +/**
> + * usb_otg_get_data() - get usb_otg data structure
> + * @otg_dev: OTG controller device
> + *
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + *
> + * Return: usb_otg data on success, NULL otherwise.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev)
> +{
> + struct usb_otg *otg;
> +
> + if (!otg_dev)
> + return NULL;
> +
> + list_for_each_entry(otg, &otg_list, list) {
> + if (otg->dev == otg_dev)
> + return otg;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * usb_otg_start_host() - start/stop the host controller
> + * @otg: usb_otg instance
> + * @on:  true to start, false to stop
> + *
> + * Start/stop the USB host controller. This function is meant
> + * for use by the OTG controller driver.
> + *
> + * Return: 0 on success, error value otherwise.
> + */
> +int usb_otg_start_host(struct usb_otg *otg, int on)
> +{
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> + int ret;
> +
> + dev_dbg(otg->dev, "otg:

Re: [PATCH v3] gpio: sch: Fix Oops on module load on Asus Eee PC 1201

[Mika Westerberg]

On Sat, Jun 18, 2016 at 07:05:04PM +0100, Colin Pitrat wrote:
> This fixes the issue descirbe in bug 117531 
> (https://bugzilla.kernel.org/show_bug.cgi?id=117531).
> It's a regression introduced in linux 4.5 that causes a Oops at load of
> gpio_sch and prevents powering off the computer.
> 
> The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
> gpio_chip data is initialized with the pointer to the sch_gpio struct. As
> sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
> the Oops.
> 
> The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
> consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
> sch_gpio struct directly instead of a gpio_chip, which avoids the call to
> gpiochip_get_data.
> 
> Thanks Mika for your patience with me :-)
> 
> Signed-off-by: Colin Pitrat 

Looks good now, thanks :)

Acked-by: Mika Westerberg 

Re: [PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

[Lee Jones]

On Fri, 17 Jun 2016, Brian Norris wrote:

> On Thu, Jun 16, 2016 at 04:38:17PM +0100, Lee Jones wrote:
> > On Thu, 02 Jun 2016, Brian Norris wrote:
> > > The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is
> > > attached to the EC, rather than the main host SoC. The API provides
> > > functionality-based (e.g., keyboard light, backlight) or index-based
> > > addressing of the PWM(s). Duty cycles are represented by a 16-bit value,
> > > where 0 maps to 0% duty cycle and U16_MAX maps to 100%. The period
> > > cannot be controlled.
> > > 
> > > This command set is more generic than, e.g.,
> > > EC_CMD_PWM_{GET,SET}_KEYBOARD_BACKLIGHT and could possibly used to
> > > replace it on future products.
> > > 
> > > Let's update the command header to include the definitions.
> > > 
> > > Signed-off-by: Brian Norris 
> > > ---
> > > v2: no change
> > > 
> > >  include/linux/mfd/cros_ec_commands.h | 31 +++
> > >  1 file changed, 31 insertions(+)
> > > 
> > > diff --git a/include/linux/mfd/cros_ec_commands.h 
> > > b/include/linux/mfd/cros_ec_commands.h
> > > index 13b630c10d4c..d673575e0ada 100644
> > > --- a/include/linux/mfd/cros_ec_commands.h
> > > +++ b/include/linux/mfd/cros_ec_commands.h
> > > @@ -949,6 +949,37 @@ struct ec_params_pwm_set_fan_duty {
> > >   uint32_t percent;
> > >  } __packed;
> > >  
> > > +#define EC_CMD_PWM_SET_DUTY 0x25
> > > +/* 16 bit duty cycle, 65535 = 100% */
> > > +#define EC_PWM_MAX_DUTY 65535
> > 
> > Any reason this isn't represented in hex, like we do normally?
> 
> Hex would probably be clearer. I'll try to change that.
> 
> > > +enum ec_pwm_type {
> > > + /* All types, indexed by board-specific enum pwm_channel */
> > > + EC_PWM_TYPE_GENERIC = 0,
> > > + /* Keyboard backlight */
> > > + EC_PWM_TYPE_KB_LIGHT,
> > > + /* Display backlight */
> > > + EC_PWM_TYPE_DISPLAY_LIGHT,
> > > + EC_PWM_TYPE_COUNT,
> > > +};
> > 
> > Are these comments really necessary?  I'd recommend that if your
> > defines require comments, then they are not adequately named.  In this
> > case however, I'd suggest that they are and the comments are
> > superfluous.
> 
> I don't think your rule holds water: there are definitely cases where
> defines/enums require (or at least are better with) additional comments.
> Sentence-long identifier names are not very readable, but sometimes a
> sentence of comment can help.

I was generalising.  There will always be exceptions to the rule, but
in the standard case we can be forthcoming enough with our naming
conventions that comments aren't required.

> Anyway, I think two of the three are probably unnecessary, if you really
> want to ask. The first (EC_PWM_TYPE_GENERIC) seems useful.
> 
> But then, how do you suggest handling this in conjunction with your
> kerneldoc suggestion? IIRC, kerneldoc requires that if one
> entry/field/parameter is documented, then all most be documented. So
> avoid kerneldoc on the enum, and just use inline comments?

Sounds reasonable.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年6月8日 18:46
> To: Yang, Wenyou ; Alan Stern
> ; Greg Kroah-Hartman
> ; Rob Herring ; Alexandre
> Belloni 
> Cc: Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> Le 08/06/2016 12:04, Nicolas Ferre a écrit :
> > Le 08/06/2016 06:15, Wenyou Yang a écrit :
> >> In order to the save power consumption, as a workaround, suspend
> >> forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> >> Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >>
> >> This suspend operation must be done before the USB clock is disabled,
> >> resume after the USB clock is enabled.
> >>
> >> Signed-off-by: Wenyou Yang 
> >
> > Little nitpicking below...
> >
> >> ---
> >>
> >> Changes in v3:
> >>  - Change the compatible description for more precise.
> >>
> >> Changes in v2:
> >>  - Add compatible to support forcibly suspend the ports.
> >>  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >>  - Add error checking for .sfr_regmap.
> >>  - Remove unnecessary regmap_read() statement.
> >>
> >>  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> >>  drivers/usb/host/ohci-at91.c   | 80 
> >> +-
> >>  include/soc/at91/at91_sfr.h| 29 
> 
> Oops sorry, additional comment which is not nitpicking, this one:
> 
> We already have SFR header file in this patch:
> 
> Author: Cyrille Pitchen 
> Date:   Thu Mar 17 17:04:00 2016 +0100
> 
> ARM: dts: at91: sama5d2: add SFR node
> 
> This SFR node is looked up by the I2S controller driver to tune the
> SFR_I2SCLKSEL register.
> 
> Signed-off-by: Cyrille Pitchen 
> Signed-off-by: Ludovic Desroches 
> Acked-by: Alexandre Belloni 
> Acked-by: Rob Herring 
> Signed-off-by: Nicolas Ferre 
> 
> Which is already accepted by arm-soc guys for 4.7... So my ack transforms 
> into a
> nack, sorry...
> 
> We will have to coordinate the effort and maybe take the whole series with 
> us. But
> for sure, you'll have to use the existing include/soc/at91/atmel-sfr.h file 
> and build
> on top of it...

Sorry, not notice this file.

I will built it on this file.

> 
> Bye,
> 
> >>  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> >> 100644 include/soc/at91/at91_sfr.h
> 
> [..]
> 
> >
> > But you can take my:
> >
> > Acked-by: Nicolas Ferre 
> >
> > with the little corrections listed.
> >
> > Alan, We plan to take the second patch of this series with AT91 git
> > tree through arm-soc. Do you agree to take this one through yours?
> 
> Alan, forget this request, we'll have to coordinate differently.
> 
> Sorry for the noise. Bye,
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

Re: [PATCH] ARM: remove unused CONFIG_ARCH_HAS_BARRIERS

[Arnd Bergmann]

On Monday, June 20, 2016 10:28:29 AM CEST Masahiro Yamada wrote:
> Hi.
> 
> I have not had any comment on this patch,
> but it looks correct to me.

Yes, I agree. Feel free to add my 

Acked-by: Arnd Bergmann 

> I will put it into Russell's patch tracker
> if nobody is against it.

Ok, thanks!

Arnd

RE: [RFC 12/12] x86/dumpstack: Optimize save_stack_trace

[byungchul.park]

> -Original Message-
> From: xinhui [mailto:xinhui@linux.vnet.ibm.com]
> Sent: Monday, June 20, 2016 4:29 PM
> To: Byungchul Park; pet...@infradead.org; mi...@kernel.org
> Cc: linux-kernel@vger.kernel.org; npig...@suse.de; wal...@google.com;
> a...@suse.de; t...@inhelltoy.tec.linutronix.de
> Subject: Re: [RFC 12/12] x86/dumpstack: Optimize save_stack_trace
> 
> 
> On 2016年06月20日 12:55, Byungchul Park wrote:
> > Currently, x86 implementation of save_stack_trace() is walking all stack
> > region word by word regardless of what the trace->max_entries is.
> > However, it's unnecessary to walk after already fulfilling caller's
> > requirement, say, if trace->nr_entries >= trace->max_entries is true.
> >
> > For example, CONFIG_LOCKDEP_CROSSRELEASE implementation calls
> > save_stack_trace() with max_entries = 5 frequently. I measured its
> > overhead and printed its difference of sched_clock() with my QEMU x86
> > machine.
> >
> > The latency was improved over 70% when trace->max_entries = 5.
> >
> [snip]
> 
> > +static int save_stack_end(void *data)
> > +{
> > +   struct stack_trace *trace = data;
> > +   return trace->nr_entries >= trace->max_entries;
> > +}
> > +
> >   static const struct stacktrace_ops save_stack_ops = {
> > .stack  = save_stack_stack,
> > .address= save_stack_address,
> then why not check the return value of ->address(), -1 indicate there is
> no room to store any pointer.

Hello,

Indeed. It also looks good to me even though it has to propagate the condition
between callback functions. I will modify it if it's better.

Thank you.
Byungchul

> 
> > .walk_stack = print_context_stack,
> > +   .end_walk   = save_stack_end,
> >   };
> >
> >   static const struct stacktrace_ops save_stack_ops_nosched = {
> >

Re: [PATCH 1/4] thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal bindings

[Geert Uytterhoeven]

Hi Khiem,

On Sun, Jun 19, 2016 at 5:33 AM, Khiem Nguyen
 wrote:
>
> Signed-off-by: Hien Dang 
> Signed-off-by: Khiem Nguyen 

Thanks for your patch!

> ---
>  .../bindings/thermal/rcar-gen3-thermal.txt | 79 
> ++
>  1 file changed, 79 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
> new file mode 100644
> index 000..ed6ce45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
> @@ -0,0 +1,79 @@
> +* DT bindings for Renesas R-Car Gen3 Thermal Sensor driver
> +
> +Required properties:
> +- compatible   : "renesas,thermal-",

Please use "renesas,-thermal", as this is the preferred order for
new bindings.

> + Examples with soctypes are:
> +   - "renesas,thermal-r8a7795" (R-Car H3)

renesas,r8a7795-thermal

> +   - "renesas,thermal-r8a7796" (R-Car M3)

renesas,r8a7796-thermal, M3-W

> +   - "renesas,rcar-gen3-thermal" as fallback
> +- reg  : Address range of the thermal registers.
> +- clocks   : Must contain a reference to the functional clock.

According to the datasheet, the USB_EXTAL clock is also an input for the
thermal block. Should it be added?

> +- #thermal-sensor-cells : Please see ./thermal.txt
> +
> +Option properties:

Optional

> +
> +- interrupts   : Use interrupt
> +- power-domain : Must contain a reference to the power domain. This 
> property is
> + mandatory if the thermal sensor instance is part of 
> a controllable power
> + domain.
> +
> +Example (non interrupt support):

Is there a good reason why you wouldn't want to use interrupts?
If not, please make it mandatory.

> +
> +   tsc1: thermal@e6198000 {
> +   compatible = "renesas,thermal-r8a7795",
> +   "renesas,rcar-gen3-thermal";
> +   reg = <0 0xe6198000 0 0x5c>;

According to the datasheet, there are more registers beyond this range.
Shouldn't it be "reg = <0 0xe6198000 0 0x68>;"?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 5/6] memory: samsung/exynos-srom: make it explicitly non-modular

[Krzysztof Kozlowski]

On 06/17/2016 02:37 AM, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> memory/samsung/Kconfig:config EXYNOS_SROM
> memory/samsung/Kconfig: bool "Exynos SROM controller driver" if COMPILE_TEST
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> We explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Pankaj Dubey 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---
>  drivers/memory/samsung/exynos-srom.c | 21 +++--
>  1 file changed, 3 insertions(+), 18 deletions(-)

Thanks, applied for v4.8.

Best regards,
Krzysztof

Re: [PATCH 0/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal support

[Geert Uytterhoeven]

Hi Khiem,

On Sun, Jun 19, 2016 at 5:31 AM, Khiem Nguyen
 wrote:
> This patchset adds new thermal sensor driver to support 3 sensors
> found in R-Car Gen3 series.
>
> It has been decided to create new driver, instead of using the existing
> thermal driver due to many differences in HW setting flows, the method
> to calculate temperatures value and some newly supported features.
>
> The new driver can support both polling mode and interrupt mode.
> It has been tested with R-Car H3.
>
> This driver is developed based on early work of Hien Dang and Thao Nguyen.
> All comments are welcome.

Thanks for your series!

Please CC linux-renesas-soc for drivers related to Renesas SoCs.
Please CC Simon for dts and defconfig updates that should go through his tree.

> Khiem Nguyen (4):
>   thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal bindings
>   thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver support
>   arm64: dts: r8a7795: Add R-Car Gen3 thermal support
>   arm64: defconfig: Enable R-Car Gen3 thermal support
>
>  .../bindings/thermal/rcar-gen3-thermal.txt |  79 
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  86 
>  arch/arm64/configs/defconfig   |   2 +
>  drivers/thermal/Kconfig|   9 +
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/rcar_gen3_thermal.c| 524 
> +
>  6 files changed, 701 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
>  create mode 100644 drivers/thermal/rcar_gen3_thermal.c

Gr{oetje,eeting}s,

Geert

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

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

[GIT PULL] AVR32 update for 4.7

[Hans-Christian Noren Egtvedt]

Hello Linus,

please pull newly rebased to 4.7-rc4 tag

git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git for-linus

to receive the following AVR32 update for 4.7

Hans-Christian Noren Egtvedt (2):
  avr32: wire up preadv2 and pwritev2 syscalls
  avr32: fixup code style in unistd.h and syscall_table.S

 arch/avr32/include/uapi/asm/unistd.h | 646 +-
 arch/avr32/kernel/syscall-stubs.S|  18 +
 arch/avr32/kernel/syscall_table.S| 662 ++-
 3 files changed, 674 insertions(+), 652 deletions(-)

-- 
mvh
Hans-Christian Noren Egtvedt

Re: [PATCH/RFC 3/3] arm64: dts: r8a7795: Support shared irq for thermal sensors

[Geert Uytterhoeven]

Hi Khiem,

On Sun, Jun 19, 2016 at 6:16 AM, Khiem Nguyen
 wrote:
> This patch adds the shared interrupts for thermal sensors
> TSC1/TSC2/TSC3.
>
> Signed-off-by: Gaku Inami 
> Signed-off-by: Khiem Nguyen 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index db203db..761df2b 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -1628,7 +1628,8 @@
> compatible = "renesas,thermal-r8a7795",
> "renesas,rcar-gen3-thermal";
> reg = <0 0xe6198000 0 0x5c>;
> -   interrupts = ;
> +   interrupts = ,
> +;

If you make this change, the DT bindings should be updated first.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set

[Jacek Anaszewski]

On 06/18/2016 12:46 AM, Andrew F. Davis wrote:

On 06/15/2016 01:48 AM, Jacek Anaszewski wrote:

Hi Andrew,

Thanks for the patch.

Please address the issue [1] raised by test bot and resubmit.

Thanks,
Jacek Anaszewski

[1] https://lkml.org/lkml/2016/6/13/1091



It looks like some systems use 'gpio_led_register_device' to make an
in-memory copy of their LED device table so the original can be removed
as .init.rodata. This doesn't necessarily depend on the LED subsystem
but it kind of seems useless when the rest of the subsystem is disabled.

One solution could be to use a dummy 'gpio_led_register_device' when the
subsystem is not enabled.


It sounds good. Please add a no-op version of gpio_led_register_device()
to include/leds.h, in a separate patch.

Thanks,
Jacek Anaszewski


Another is just to remove the five or so uses
of 'gpio_led_register_device' and have those systems register LED device
tables like other systems do.

If nether of these are acceptable then this patch can be dropped from
this series for now.

Thanks,
Andrew


On 06/13/2016 10:02 PM, Andrew F. Davis wrote:

When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.

Signed-off-by: Andrew F. Davis 
---
   drivers/Makefile | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 567e32c..fa514d5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -127,7 +127,7 @@ obj-$(CONFIG_CPU_FREQ)+= cpufreq/
   obj-$(CONFIG_CPU_IDLE)+= cpuidle/
   obj-$(CONFIG_MMC)+= mmc/
   obj-$(CONFIG_MEMSTICK)+= memstick/
-obj-y+= leds/
+obj-$(CONFIG_NEW_LEDS)+= leds/
   obj-$(CONFIG_INFINIBAND)+= infiniband/
   obj-$(CONFIG_SGI_SN)+= sn/
   obj-y+= firmware/

Re: [PATCH v10 08/22] IB/hns: Add icm support

[Wei Hu (Xavier)]

On 2016/6/20 14:06, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:


On 2016/6/17 17:58, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:

This patch mainly added icm support for RoCE. It initializes icm
which managers the relative memory blocks for RoCE. The data
structures of RoCE will be located in it. For example, CQ table,
QP table and MTPT table so on.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---

<...>


+
+static int hns_roce_alloc_icm_pages(struct scatterlist *mem, int order,
+   gfp_t gfp_mask)
+{
+   struct page *page;
+
+   page = alloc_pages(gfp_mask, order);
+   if (!page)
+   return -ENOMEM;
+
+   sg_set_page(mem, page, PAGE_SIZE << order, 0);
+
+   return 0;
+}
+
+static int hns_roce_alloc_icm_coherent(struct device *dev,
+  struct scatterlist *mem, int order,
+  gfp_t gfp_mask)
+{
+   void *buf = dma_alloc_coherent(dev, PAGE_SIZE << order,
+  &sg_dma_address(mem), gfp_mask);
+   if (!buf)
+   return -ENOMEM;
+
+   sg_set_buf(mem, buf, PAGE_SIZE << order);
+   WARN_ON(mem->offset);
+   sg_dma_len(mem) = PAGE_SIZE << order;
+   return 0;
+}
+

<...>


+
+static void hns_roce_free_icm_pages(struct hns_roce_dev *hr_dev,
+   struct hns_roce_icm_chunk *chunk)
+{
+   int i;
+
+   if (chunk->nsg > 0)
+   dma_unmap_sg(&hr_dev->pdev->dev, chunk->mem, chunk->npages,
+DMA_BIDIRECTIONAL);
+
+   for (i = 0; i < chunk->npages; ++i)
+   __free_pages(sg_page(&chunk->mem[i]),
+get_order(chunk->mem[i].length));

You used alloc_pages for this allocation, so why are you using
__free_pages instead of free_pages?

Hi, Leon
 The function prototype of these functions as below：
 static inline struct page * alloc_pages(gfp_t gfp_mask, unsigned int
order);
 void free_pages(unsigned long addr, unsigned int order);
 void __free_pages(struct page *page, unsigned int order);

 The type of the first parameter of free_pages is same with the type of
return value of alloc_pages.
 Maybe it is better to call __free_pages to release memory that allocated
by calling alloc_pages.

OK, I see.

Another question which you didn't answer [1].

"I wonder if you have the same needs for ICM as it is in mlx4 device.
Do you have firmware?"

[1] http://marc.info/?l=linux-rdma&m=146545553104913&w=2

Hi, Leon
Now we haven't firmware.
But hardware still need memory for QPC\CQC\MTPT\mtt etc.

Thanks
Wei Hu

Regards
Wei Hu

[PATCH v4 3/7] max8903: cleans up confusing relationship between dc_valid, dok and dcm.

[Chris Lapa]

From: Chris Lapa 

The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.

It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclusively.

The previous implementation already allowed for this somewhat, however no
error was given if dok wasn't given whilst dc_valid was.

The new implementation enforces dok presence when dc_valid is given. Whilst
allowing dcm to be optional.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c   | 22 +-
 include/linux/power/max8903_charger.h |  6 +++---
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 0a5b0e1..6ec705f 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -211,27 +211,23 @@ static int max8903_probe(struct platform_device *pdev)
}
 
if (pdata->dc_valid) {
-   if (pdata->dok && gpio_is_valid(pdata->dok) &&
-   pdata->dcm && gpio_is_valid(pdata->dcm)) {
+   if (pdata->dok && gpio_is_valid(pdata->dok)) {
gpio = pdata->dok; /* PULL_UPed Interrupt */
ta_in = gpio_get_value(gpio) ? 0 : 1;
+   } else {
+   dev_err(dev, "When DC is wired, DOK should be wired as 
well.\n");
+   return -EINVAL;
+   }
+   }
 
+   if (pdata->dcm) {
+   if (gpio_is_valid(pdata->dcm)) {
gpio = pdata->dcm; /* Output */
gpio_set_value(gpio, ta_in);
} else {
-   dev_err(dev, "When DC is wired, DOK and DCM should"
-   " be wired as well.\n");
+   dev_err(dev, "Invalid pin: dcm.\n");
return -EINVAL;
}
-   } else {
-   if (pdata->dcm) {
-   if (gpio_is_valid(pdata->dcm))
-   gpio_set_value(pdata->dcm, 0);
-   else {
-   dev_err(dev, "Invalid pin: dcm.\n");
-   return -EINVAL;
-   }
-   }
}
 
if (pdata->usb_valid) {
diff --git a/include/linux/power/max8903_charger.h 
b/include/linux/power/max8903_charger.h
index 24f51db..89d3f1c 100644
--- a/include/linux/power/max8903_charger.h
+++ b/include/linux/power/max8903_charger.h
@@ -26,8 +26,8 @@
 struct max8903_pdata {
/*
 * GPIOs
-* cen, chg, flt, and usus are optional.
-* dok, dcm, and uok are not optional depending on the status of
+* cen, chg, flt, dcm and usus are optional.
+* dok and uok are not optional depending on the status of
 * dc_valid and usb_valid.
 */
int cen;/* Charger Enable input */
@@ -41,7 +41,7 @@ struct max8903_pdata {
/*
 * DC(Adapter/TA) is wired
 * When dc_valid is true,
-*  dok and dcm should be valid.
+*  dok should be valid.
 *
 * At least one of dc_valid or usb_valid should be true.
 */
-- 
1.9.1

Re: [PATCH V2 08/63] clocksource/drivers/st_lpc: Convert init function to return error

[Patrice Chotard]

Hi Daniel

On 06/16/2016 11:26 PM, Daniel Lezcano wrote:

The init functions do not return any error. They behave as the following:

  - panic, thus leading to a kernel crash while another timer may work and
make the system boot up correctly

  or

  - print an error and let the caller unaware if the state of the system

Change that by converting the init functions to return an error conforming
to the CLOCKSOURCE_OF_RET prototype.

Proper error handling (rollback, errno value) will be changed later case
by case, thus this change just return back an error or success in the init
function.

Signed-off-by: Daniel Lezcano 
---
  drivers/clocksource/clksrc_st_lpc.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/clksrc_st_lpc.c 
b/drivers/clocksource/clksrc_st_lpc.c
index 65ec467..c9022a9 100644
--- a/drivers/clocksource/clksrc_st_lpc.c
+++ b/drivers/clocksource/clksrc_st_lpc.c
@@ -92,7 +92,7 @@ static int __init st_clksrc_setup_clk(struct device_node *np)
return 0;
  }
  
-static void __init st_clksrc_of_register(struct device_node *np)

+static int __init st_clksrc_of_register(struct device_node *np)
  {
int ret;
uint32_t mode;
@@ -100,32 +100,36 @@ static void __init st_clksrc_of_register(struct 
device_node *np)
ret = of_property_read_u32(np, "st,lpc-mode", &mode);
if (ret) {
pr_err("clksrc-st-lpc: An LPC mode must be provided\n");
-   return;
+   return ret;
}
  
  	/* LPC can either run as a Clocksource or in RTC or WDT mode */

if (mode != ST_LPC_MODE_CLKSRC)
-   return;
+   return 0;
  
  	ddata.base = of_iomap(np, 0);

if (!ddata.base) {
pr_err("clksrc-st-lpc: Unable to map iomem\n");
-   return;
+   return -ENXIO;
}
  
-	if (st_clksrc_setup_clk(np)) {

+   ret = st_clksrc_setup_clk(np);
+   if (ret) {
iounmap(ddata.base);
-   return;
+   return ret;
}
  
-	if (st_clksrc_init()) {

+   ret = st_clksrc_init();
+   if (ret) {
clk_disable_unprepare(ddata.clk);
clk_put(ddata.clk);
iounmap(ddata.base);
-   return;
+   return ret;
}
  
  	pr_info("clksrc-st-lpc: clocksource initialised - running @ %luHz\n",

clk_get_rate(ddata.clk));
+
+   return ret;
  }
-CLOCKSOURCE_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
+CLOCKSOURCE_OF_DECLARE_RET(ddata, "st,stih407-lpc", st_clksrc_of_register);


Acked-by: Patrice Chotard 

Re: [PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

[Lee Jones]

On Fri, 17 Jun 2016, Doug Anderson wrote:

> Lee,
> 
> On Fri, Jun 17, 2016 at 1:06 AM, Lee Jones  wrote:
> >> Probably the reason for all of these non-kernel-isms is that this
> >> isn't a kernel file.  From the top of the file:
> >>
> >>  * NOTE: This file is copied verbatim from the ChromeOS EC Open Source
> >>  * project in an attempt to make future updates easy to make.
> >>
> >> So the source of truth for this file is
> >> .
> >>
> >> Someone could probably submit a CL to that project to make it a little
> >> more kernel-ish and then we'd have to see if the EC team would accept
> >> such changes...
> >
> > Hmmm... that kinda puts me in a difficult position.  Do I except
> > non-kernel code, which does not conform to our stands?
> 
> What about if Brian made sure to just fully copy the latest version of
> "cros_ec_commands.h" from the EC codebase and changed this commit
> message to say:
> 
> Copy the latest version of "cros_ec_commands.h" from the Chrome OS EC
> code base, which is the source of truth for this file.  See
> .
> 
> From the commit message it would be clear that this is an external
> file linked into the kernel for convenience.
> 
> 
> > Naturally I'd be happier if you could try to make the code more
> > 'kernely'.  The practices I mention above are still good ones, even if
> > you're not writing kernel specific code.
> 
> In general requesting that code from outside the kernel conform to
> "kerneldoc" seems like a bit of a stretch.  In general having some
> type of parse-able format for comments is nice, but I could see that
> in the Chrome OS EC codebase it would be a bit overkill.

It's unfortunate that kerneldoc is named so, since I think it's a nice
way to write structure/function headers regardless of code base and
not overkill at all.  It's certainly harder to convince !kernel code
to use the format, or at least easier for others to push back due to
the fact that is has 'kernel' in the name.

> Also: it would be awfully strange if we suddenly started changing the
> coding convention of this file or we had half the file in one
> convention and half in another.  The rest of this file is in EC
> convention and it seems sane to keep it that way...

Right.  It's also a shame we're only catching this now.  Really we
should have had this discussion in the first instance.

Taking into consideration that this file is already in the kernel and
that it's current format is also represented, I'm willing to keep
adding to it.  I would like to see an internal request to adopt
so-called kerneldoc.  Not because I am wish to blindly push our
standards to other code-bases, but because I am an advocate of the
format in general.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] zram: update zram to use zpool

[Minchan Kim]

On Fri, Jun 17, 2016 at 10:30:58AM +0200, Vitaly Wool wrote:
> Hi Minchan,
> 
> On Thu, Jun 16, 2016 at 1:17 AM, Minchan Kim  wrote:
> > On Wed, Jun 15, 2016 at 10:42:07PM +0800, Geliang Tang wrote:
> >> Change zram to use the zpool api instead of directly using zsmalloc.
> >> The zpool api doesn't have zs_compact() and zs_pool_stats() functions.
> >> I did the following two things to fix it.
> >> 1) I replace zs_compact() with zpool_shrink(), use zpool_shrink() to
> >>call zs_compact() in zsmalloc.
> >> 2) The 'pages_compacted' attribute is showed in zram by calling
> >>zs_pool_stats(). So in order not to call zs_pool_state() I move the
> >>attribute to zsmalloc.
> >>
> >> Signed-off-by: Geliang Tang 
> >
> > NACK.
> >
> > I already explained why.
> > http://lkml.kernel.org/r/20160609013411.GA29779@bbox
> 
> This is a fair statement, to a certain extent. I'll let Geliang speak
> for himself but I am personally interested in this zram extension
> because I want it to work on MMU-less systems. zsmalloc can not handle
> that, so I want to be able to use zram over z3fold.

Could you tell me more detail? What's the usecase?

> 
> Best regards,
>Vitaly
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

Re: [v2 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399

[Chris Zhong]

Hi Tomasz

Thanks for your comments.
I will modify all the the part of snip. Please find my reply in the 
following.


On 06/18/2016 12:06 AM, Tomasz Figa wrote:

Hi Chris,


[snip]


+struct phy_reg {
+   int value;
+   int addr;
+};
+
+struct phy_reg usb_pll_cfg[] = {
+   {0xf0,  CMN_PLL0_VCOCAL_INIT},

CodingStyle: Please add spaces after opening and before closing braces.


+   {0x18,  CMN_PLL0_VCOCAL_ITER},
+   {0xd0,  CMN_PLL0_INTDIV},
+   {0x4a4a,CMN_PLL0_FRACDIV},
+   {0x34,  CMN_PLL0_HIGH_THR},
+   {0x1ee, CMN_PLL0_SS_CTRL1},
+   {0x7f03,CMN_PLL0_SS_CTRL2},
+   {0x20,  CMN_PLL0_DSM_DIAG},
+   {0, CMN_DIAG_PLL0_OVRD},
+   {0, CMN_DIAG_PLL0_FBH_OVRD},
+   {0, CMN_DIAG_PLL0_FBL_OVRD},
+   {0x7,   CMN_DIAG_PLL0_V2I_TUNE},
+   {0x45,  CMN_DIAG_PLL0_CP_TUNE},
+   {0x8,   CMN_DIAG_PLL0_LF_PROG},

It would be generally much, much better if these magic numbers were
dissected into particular bitfields and defined using macros, if
possible... The same applies to all other magic numbers in this file.
This magic number is very hard to describe, it is a initialization 
sequence from vendor.

Their names are very close to the description.
From spec of cdn type-c phy:
Iteration wait timer value
pll_fb_div_integer value: Value of the pll_fb_div_integer signal.
pll_fb_div_fractional: Value of the pll_fb_div_fractional signal.
pll_fb_div_high_theshold: Value of the pll_fb_div_high_threshold signal.
...


+};
+
+struct phy_reg dp_pll_cfg[] = {

[snip]

+static void tcphy_cfg_usb_pll(struct rockchip_typec_phy *tcphy)
+{
+   u32 rdata;
+   u32 i;
+
+   /*
+* Selects which PLL clock will be driven on the analog high speed
+* clock 0: PLL 0 div 1.
+*/
+   rdata = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
+   writel(rdata & 0xfffc, tcphy->base + CMN_DIAG_HSCLK_SEL);

This mask looks suspiciously. Is clearing bits 31-16 and 1-0 what we
want here? I'd advise for manipulating the value in separate line and
then only calling writel() with the final value already in the
variable.
Yes, the register valid length is 16 bits, but the they are stored with 
32bit.

readl will return 0 in higher 16bit + valid value in lower 16bit.
and writel will ignore the higher 16bit.





+
+   /* load the configuration of PLL0 */
+   for (i = 0; i < ARRAY_SIZE(usb_pll_cfg); i++)
+   writel(usb_pll_cfg[i].value, tcphy->base + usb_pll_cfg[i].addr);
+}
+
+static void tcphy_cfg_dp_pll(struct rockchip_typec_phy *tcphy)
+{
+   u32 rdata;
+   u32 i;
+
+   /* set the default mode to RBR */
+   writel(DP_PLL_CLOCK_ENABLE | DP_PLL_ENABLE | DP_PLL_DATA_RATE_RBR,
+  tcphy->base + DP_CLK_CTL);

This looks (and is understandable) much better than magic numbers in
other parts of this file!


+
+   /*
+* Selects which PLL clock will be driven on the analog high speed
+* clock 1: PLL 1 div 2.
+*/
+   rdata = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
+   rdata = (rdata & 0xffcf) | 0x30;

If the & operation here is used to clear a bitfield, please use the
negative notation, e.g.

rdata &= ~0x30;
rdata |= 0x30;

(By the way, the AND NOT and OR with the same value is what the code
above does, which would make sense if the bitfield mask was defined by
a macro, but doesn't make any sense with magic numbers.)

It looks like the registers are 16-bit. Should they really be accessed
with readl() and not readw()? If they are accessed with readl(), what
is returned in most significant 16 bits and what should be written
there?

I will use macro here at next version



+   writel(rdata, tcphy->base + CMN_DIAG_HSCLK_SEL);
+
+   /* load the configuration of PLL1 */
+   for (i = 0; i < ARRAY_SIZE(dp_pll_cfg); i++)
+   writel(dp_pll_cfg[i].value, tcphy->base + dp_pll_cfg[i].addr);
+}

[snip]

+   }
+
+   ret = clk_prepare_enable(tcphy->clk_ref);
+   if (ret) {
+   dev_err(tcphy->dev, "Failed to prepare_enable ref clock\n");
+   goto clk_ref_failed;
+   }

[snip]

+static void tcphy_phy_deinit(struct rockchip_typec_phy *tcphy)
+{
+   clk_disable_unprepare(tcphy->clk_core);
+   clk_disable_unprepare(tcphy->clk_ref);
+}
+
+static const struct phy_ops rockchip_tcphy_ops = {
+   .owner  = THIS_MODULE,

Hmm, if there is no phy ops, how the phy consumer drivers request the
PHY to do anything?
There is no consumer call this phy, the power on and power off are 
called by notification.

So I am going to delete this ops next version.

+};
+
+static int tcphy_pd_event(struct notifier_block *nb,
+ unsigned long event, void *priv)
+{

[snip]

+static int tcphy_get_param(struct device *dev,
+  struct usb3phy_reg *reg,
+  const char 

[PATCH v4 5/7] max8903: removes non zero validity checks on gpios.

[Chris Lapa]

From: Chris Lapa 

Prior to this commit a zero gpio was treated as invalid. Whereas
gpio_is_valid() will treat a zero gpio as valid.

This commit removes the confusion and explicitly uses gpio_is_valid()
throughout. Which in turn results in several of the error messages becoming
redundant and thus removed.

Signed-off-by: Chris Lapa 
---
 drivers/power/max8903_charger.c | 115 
 1 file changed, 47 insertions(+), 68 deletions(-)

diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 3f35593..643a87a 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -53,7 +53,7 @@ static int max8903_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
-   if (data->pdata->chg) {
+   if (gpio_is_valid(data->pdata->chg)) {
if (gpio_get_value(data->pdata->chg) == 0)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (data->usb_in || data->ta_in)
@@ -93,11 +93,11 @@ static irqreturn_t max8903_dcin(int irq, void *_data)
data->ta_in = ta_in;
 
/* Set Current-Limit-Mode 1:DC 0:USB */
-   if (pdata->dcm)
+   if (gpio_is_valid(pdata->dcm))
gpio_set_value(pdata->dcm, ta_in ? 1 : 0);
 
/* Charger Enable / Disable (cen is negated) */
-   if (pdata->cen)
+   if (gpio_is_valid(pdata->cen))
gpio_set_value(pdata->cen, ta_in ? 0 :
(data->usb_in ? 0 : 1));
 
@@ -136,7 +136,7 @@ static irqreturn_t max8903_usbin(int irq, void *_data)
/* Do not touch Current-Limit-Mode */
 
/* Charger Enable / Disable (cen is negated) */
-   if (pdata->cen)
+   if (gpio_is_valid(pdata->cen))
gpio_set_value(pdata->cen, usb_in ? 0 :
(data->ta_in ? 0 : 1));
 
@@ -190,7 +190,7 @@ static int max8903_setup_gpios(struct platform_device *pdev)
int usb_in = 0;
 
if (pdata->dc_valid) {
-   if (pdata->dok && gpio_is_valid(pdata->dok)) {
+   if (gpio_is_valid(pdata->dok)) {
ret = devm_gpio_request(dev, pdata->dok,
data->psy_desc.name);
if (ret) {
@@ -208,27 +208,21 @@ static int max8903_setup_gpios(struct platform_device 
*pdev)
}
}
 
-   if (pdata->dcm) {
-   if (gpio_is_valid(pdata->dcm)) {
-   ret = devm_gpio_request(dev, pdata->dcm,
-   data->psy_desc.name);
-   if (ret) {
-   dev_err(dev,
-   "Failed GPIO request for dcm: %d err 
%d\n",
-   pdata->dcm, ret);
-   return ret;
-   }
-
-   gpio = pdata->dcm; /* Output */
-   gpio_set_value(gpio, ta_in);
-   } else {
-   dev_err(dev, "Invalid pin: dcm.\n");
-   return -EINVAL;
+   if (gpio_is_valid(pdata->dcm)) {
+   ret = devm_gpio_request(dev, pdata->dcm, data->psy_desc.name);
+   if (ret) {
+   dev_err(dev,
+   "Failed GPIO request for dcm: %d err %d\n",
+   pdata->dcm, ret);
+   return ret;
}
+
+   gpio = pdata->dcm; /* Output */
+   gpio_set_value(gpio, ta_in);
}
 
if (pdata->usb_valid) {
-   if (pdata->uok && gpio_is_valid(pdata->uok)) {
+   if (gpio_is_valid(pdata->uok)) {
ret = devm_gpio_request(dev, pdata->uok,
data->psy_desc.name);
if (ret) {
@@ -247,60 +241,45 @@ static int max8903_setup_gpios(struct platform_device 
*pdev)
}
}
 
-   if (pdata->cen) {
-   if (gpio_is_valid(pdata->cen)) {
-   ret = devm_gpio_request(dev, pdata->cen,
-   data->psy_desc.name);
-   if (ret) {
-   dev_err(dev,
-   "Failed GPIO request for cen: %d err 
%d\n",
-   pdata->cen, ret);
-   return ret;
-   }
-
-   gpio_set_value(pdata->cen, (ta_in || usb_in) ? 0 : 1);
-   } else {
-   dev_err(dev, "Invalid pin: cen.\n");
-   return -EINVAL;
+   if (gpio_is_valid(pdata->cen)) {
+   ret = devm_gpio_request(dev, pdata->cen

Re: [RESEND PATCH v2 0/1] mmc: dw_mmc: Fix UHS tuning on some brand of cards.

[Jaehoon Chung]

Hi Enric,

On 06/20/2016 04:59 PM, Enric Balletbo Serra wrote:
> Hi Jaehoon,
> 
> 2016-04-27 10:53 GMT+02:00 Enric Balletbo i Serra
> :
>>
>>
>> On 27/04/16 10:35, Jaehoon Chung wrote:
>>> On 04/26/2016 05:03 PM, Enric Balletbo i Serra wrote:
 Hi,

 I introduced the cover letter to give some background about this.

 I have been investigating a problem related to at least one specific 
 sdcard when
 UHS-I is set. The card is not detected due the tuning phase reports a
 failure. Since the problem is only reproduced with a single model of a 
 single
 brand of card, it is probably a card firmware issue, but the card works 
 fine
 on my laptop.
>>>
>>> I think you have analyzed many case..of course..it was successful to switch 
>>> voltage, right?
>>> Maybe this patch too old..so can you remember which specific sdcard is 
>>> produced?
>>>
>>
>> Yes it was successful to switch voltage. The specific card is an UNIREX 16GB 
>> Class 10
>> SD card (Compatible with UHS-1)
>>
> 
> Any feedback for this patch?

Sorry..I missed this patch..Thanks for reminding!
I will check this patch as soon as possible.

Best Regards,
Jaehoon Chung

> 
> 

 The first attempt to fix this was a patch sent by Doug Anderson [1], but 
 Alim
 Akhtar found that this produced randomly a hung task on Peach-pi. I can 
 confirm
 that it's easy to reproduce the hung task, either, with cold boots or 
 suspend to
 ram tests.
>>>
>>> Yep..I have already tested and checked for this.
>>>

 I tried to fix both problems (the original issue and the one introduced by 
 the
 patch) in different ways, but I ended thinking that this second proposal 
 is the
 most simple that solves both issues. So let's try to fix this by handling 
 the
 response CRC error slightly differently when tuning command is happening.

 I tested the patch on both platforms, on exynos and on rockhip. I did lots 
 of
 tests and at the moment the patch seems to fix the rockchip issue and don't
 hung on exynos. I'll continue testing meanwhile we discuss about it.

 I think the patch, at least, needs the Doug's approval (as he dig into the 
 issue
 before) and the Tested-by Alim. So will be good if you have a slot of time 
 to
 look a bit into this.

 Thanks in advance.
  Enric

 [1] https://lkml.org/lkml/2015/5/18/495

 Changelog since v1:
 - Fix the issue found by Alim with exynos letting the data transfer
   take place only when MMC_SEND_TUNING_BLOCK is issued.

 Doug Anderson (1):
   mmc: dw_mmc: Wait for data transfer after response errors.

  drivers/mmc/host/dw_mmc.c | 27 +++
  1 file changed, 27 insertions(+)

>>>
> 
> 
> 

Re: linux-next: manual merge of the iommu tree with the arm tree

[Russell King]

On Mon, Jun 20, 2016 at 01:20:09PM +1000, Stephen Rothwell wrote:
> Hi Joerg,
> 
> Today's linux-next merge of the iommu tree got a conflict in:
> 
>   drivers/iommu/mtk_iommu.c
> 
> between commit:
> 
>   d267804c8457 ("iommu: convert DT component matching to 
> component_match_add_release()")
> 
> from the arm tree and commit:
> 
>   da4d6e6d3b3e ("iommu/mediatek: Convert DT component matching to 
> component_match_add_release()")
> 
> from the iommu tree.

This looks like it's going to end up being broken.  I self-NACK'd my v2
patch series was, and it looks like the v2 patch was picked up instead
of v1.

It's also part of a _three_ patch series, where the _second two_ patches
depend on the _first_ patch.  Such series can't be split up.

-- 
Russell King
ARM architecture Linux Kernel maintainer

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

Cc: Ville

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

If that turns out to be the bad commit, it doesn't really surprise me,
and that in itself is depressing.

It might be helpful if you could add drm.debug=14 module parameter, and
provide dmesgs from boot both with and without the above commit (it's
enough to see i915 load). Please also provide
/sys/kernel/debug/dri/0/i915_opregion.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v7 8/8] perf record: Unmap overwrite evlist when event terminate

[Wangnan (F)]

On 2016/6/17 4:59, Arnaldo Carvalho de Melo wrote:

Em Wed, Jun 15, 2016 at 02:23:35AM +, Wang Nan escreveu:

When see POLLERR or POLLHUP, unmap ring buffer from both the main
evlist and overwrite evlist.

When you use an auxiliary evlist this makes evlist->parent be different
than evlist, right? So can't we just hide this from tools and do it all
in perf_evlist__filter_pollfd?


So we need to find all children from parent. Currently we can only track
parent from children. This is not enough. Although currently we can pass
rec->overwrite_evlist to the filter so perf_evlist__filter_pollfd knows
it should release mmaps from both evlists, if in future we have more than
one aux_evlists it doesn't work.

Thank you.



This way we will not need to expose perf_evlist__mmap_put(), etc.

I haven't tried to _actually_ do this, just asking from browsing the
patchkit and with the goal of hiding the internals of this thing inside
evlist.c as much as possible.

- Arnaldo
  

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
---
  tools/perf/builtin-record.c | 30 +-
  tools/perf/util/evlist.c|  3 +--
  tools/perf/util/evlist.h|  2 +-
  3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index b9094f0..ca6376c 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -914,6 +914,26 @@ out:
return err;
  }
  
+static void record__munmap_filtered(struct fdarray *fda, int fd, void *arg)

+{
+   struct record *rec = (struct record *)arg;
+
+   perf_evlist__mmap_put(rec->evlist, fda->priv[fd].idx);
+   if (rec->overwrite_evlist)
+   perf_evlist__mmap_put(rec->overwrite_evlist, fda->priv[fd].idx);
+}
+
+static int record__filter_pollfd(struct record *rec)
+{
+   /*
+* Although we may have auxiliray evlist, there is
+* only one pollfd, so we don't need to filter pollfd
+* for auxiliray evlist.
+*/
+   return fdarray__filter(&rec->evlist->pollfd, POLLERR | POLLHUP,
+  record__munmap_filtered, rec);
+}
+
  static int __cmd_record(struct record *rec, int argc, const char **argv)
  {
int err;
@@ -1150,15 +1170,7 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
err = 0;
waking++;
  
-			/*

-* Although we may have auxiliray evlist, there is
-* only one pollfd, so we don't need to filter pollfd
-* for auxiliray evlist.
-*
-* TODO: if an event is terminated (POLLERR | POLLHUP),
-* unmap mmaps for auxiliray evlist too.
-*/
-   if (perf_evlist__filter_pollfd(rec->evlist, POLLERR | 
POLLHUP) == 0)
+   if (record__filter_pollfd(rec) == 0)
draining = true;
}
  
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c

index e8fcb22..d43ee81 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -27,7 +27,6 @@
  #include 
  #include 
  
-static void perf_evlist__mmap_put(struct perf_evlist *evlist, int idx);

  static void __perf_evlist__munmap(struct perf_evlist *evlist, int idx);
  
  #define FD(e, x, y) (*(int *)xyarray__entry(e->fd, x, y))

@@ -863,7 +862,7 @@ static void perf_evlist__mmap_get(struct perf_evlist 
*evlist, int idx)
atomic_inc(&evlist->mmap[idx].refcnt);
  }
  
-static void perf_evlist__mmap_put(struct perf_evlist *evlist, int idx)

+void perf_evlist__mmap_put(struct perf_evlist *evlist, int idx)
  {
struct perf_mmap *md = &evlist->mmap[idx];
  
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h

index 41e65ac..ba5e006 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -141,7 +141,7 @@ union perf_event *perf_evlist__mmap_read_backward(struct 
perf_evlist *evlist,
  void perf_evlist__mmap_read_catchup(struct perf_evlist *evlist, int idx);
  
  void perf_evlist__mmap_consume(struct perf_evlist *evlist, int idx);

-
+void perf_evlist__mmap_put(struct perf_evlist *evlist, int idx);
  int perf_evlist__pause(struct perf_evlist *evlist);
  int perf_evlist__resume(struct perf_evlist *evlist);
  int perf_evlist__open(struct perf_evlist *evlist);
--
1.8.3.4

Re: [PATCH 3.12 00/56] 3.12.61-stable review

[Jiri Slaby]

On 06/15/2016, 05:34 PM, Shuah Khan wrote:
> Compiled and booted on my test system. No dmesg regressions.

On 06/15/2016, 08:42 PM, Guenter Roeck wrote:
> Build results:
>   total: 127 pass: 127 fail: 0
> Qemu test results:
>   total: 85 pass: 85 fail: 0
>
> Details are available at http://kerneltests.org/builders.

Thanks!

-- 
js
suse labs

Re: [RESEND PATCH v2 0/1] mmc: dw_mmc: Fix UHS tuning on some brand of cards.

[Enric Balletbo Serra]

Hi Jaehoon,

2016-04-27 10:53 GMT+02:00 Enric Balletbo i Serra
:
>
>
> On 27/04/16 10:35, Jaehoon Chung wrote:
>> On 04/26/2016 05:03 PM, Enric Balletbo i Serra wrote:
>>> Hi,
>>>
>>> I introduced the cover letter to give some background about this.
>>>
>>> I have been investigating a problem related to at least one specific sdcard 
>>> when
>>> UHS-I is set. The card is not detected due the tuning phase reports a
>>> failure. Since the problem is only reproduced with a single model of a 
>>> single
>>> brand of card, it is probably a card firmware issue, but the card works fine
>>> on my laptop.
>>
>> I think you have analyzed many case..of course..it was successful to switch 
>> voltage, right?
>> Maybe this patch too old..so can you remember which specific sdcard is 
>> produced?
>>
>
> Yes it was successful to switch voltage. The specific card is an UNIREX 16GB 
> Class 10
> SD card (Compatible with UHS-1)
>

Any feedback for this patch?


>>>
>>> The first attempt to fix this was a patch sent by Doug Anderson [1], but 
>>> Alim
>>> Akhtar found that this produced randomly a hung task on Peach-pi. I can 
>>> confirm
>>> that it's easy to reproduce the hung task, either, with cold boots or 
>>> suspend to
>>> ram tests.
>>
>> Yep..I have already tested and checked for this.
>>
>>>
>>> I tried to fix both problems (the original issue and the one introduced by 
>>> the
>>> patch) in different ways, but I ended thinking that this second proposal is 
>>> the
>>> most simple that solves both issues. So let's try to fix this by handling 
>>> the
>>> response CRC error slightly differently when tuning command is happening.
>>>
>>> I tested the patch on both platforms, on exynos and on rockhip. I did lots 
>>> of
>>> tests and at the moment the patch seems to fix the rockchip issue and don't
>>> hung on exynos. I'll continue testing meanwhile we discuss about it.
>>>
>>> I think the patch, at least, needs the Doug's approval (as he dig into the 
>>> issue
>>> before) and the Tested-by Alim. So will be good if you have a slot of time 
>>> to
>>> look a bit into this.
>>>
>>> Thanks in advance.
>>>  Enric
>>>
>>> [1] https://lkml.org/lkml/2015/5/18/495
>>>
>>> Changelog since v1:
>>> - Fix the issue found by Alim with exynos letting the data transfer
>>>   take place only when MMC_SEND_TUNING_BLOCK is issued.
>>>
>>> Doug Anderson (1):
>>>   mmc: dw_mmc: Wait for data transfer after response errors.
>>>
>>>  drivers/mmc/host/dw_mmc.c | 27 +++
>>>  1 file changed, 27 insertions(+)
>>>
>>

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

[Will Deacon]

On Sat, Jun 18, 2016 at 04:46:20PM +0800, Boqun Feng wrote:
> On Fri, Jun 17, 2016 at 02:17:27PM -0400, Waiman Long wrote:
> > keep the xchg() function as it is or use smp_store_release(&next->locked,
> > 1). So which one is a better alternative for ARM or PPC?
> > 
> 
> For PPC, I think xchg_release() + smp_store_release() is better than the 
> current code, because the former has two lwsync while the latter has two
> sync, and sync is quite expensive than lwsync on PPC.
> 
> I need to leave the ARM part to Will ;-)

I doubt there's much in it, but xchg() has DMB + release, so xchg_release +
smp_store_release is probably slightly better for us too.

Will

Re: [PATCH 10/10] mm: balance LRU lists based on relative thrashing

[Minchan Kim]

On Fri, Jun 17, 2016 at 01:01:29PM -0400, Johannes Weiner wrote:
> On Fri, Jun 17, 2016 at 04:49:45PM +0900, Minchan Kim wrote:
> > On Thu, Jun 16, 2016 at 11:12:07AM -0400, Johannes Weiner wrote:
> > > On Wed, Jun 15, 2016 at 11:23:41AM +0900, Minchan Kim wrote:
> > > > On Mon, Jun 13, 2016 at 11:52:31AM -0400, Johannes Weiner wrote:
> > > > > On Fri, Jun 10, 2016 at 11:19:35AM +0900, Minchan Kim wrote:
> > > > > > Other concern about PG_workingset is naming. For file-backed pages, 
> > > > > > it's
> > > > > > good because file-backed pages started from inactive's head and 
> > > > > > promoted
> > > > > > active LRU once two touch so it's likely to be workingset. However,
> > > > > > for anonymous page, it starts from active list so every anonymous 
> > > > > > page
> > > > > > has PG_workingset while mlocked pages cannot have a chance to have 
> > > > > > it.
> > > > > > It wouldn't matter in eclaim POV but if we would use PG_workingset 
> > > > > > as
> > > > > > indicator to identify real workingset page, it might be confused.
> > > > > > Maybe, We could mark mlocked pages as workingset unconditionally.
> > > > > 
> > > > > Hm I'm not sure it matters. Technically we don't have to set it on
> > > > > anon, but since it's otherwise unused anyway, it's nice to set it to
> > > > > reinforce the notion that anon is currently always workingset.
> > > > 
> > > > When I read your description firstly, I thought the flag for anon page
> > > > is set on only swapin but now I feel you want to set it for all of
> > > > anonymous page but it has several holes like mlocked pages, shmem pages
> > > > and THP and you want to fix it in THP case only.
> > > > Hm, What's the rule?
> > > > It's not consistent and confusing to me. :(
> > > 
> > > I think you are might be over thinking this a bit ;)
> > > 
> > > The current LRU code has a notion of workingset pages, which is anon
> > > pages and multi-referenced file pages. shmem are considered file for
> > > this purpose. That's why anon start out active and files/shmem do
> > > not. This patch adds refaulting pages to the mix.
> > > 
> > > PG_workingset keeps track of pages that were recently workingset, so
> > > we set it when the page enters the workingset (activations and
> > > refaults, and new anon from the start). The only thing we need out of
> > > this flag is to tell us whether reclaim is going after the workingset
> > > because the LRUs have become too small to hold it.
> > 
> > Understood.
> > 
> > Divergence comes from here. It seems you design the page flag for only
> > aging/balancing logic working well while I am thinking to leverage the
> > flag to identify real workingset. I mean a anonymous page would be a cold
> > if it has just cold data for the application which would be swapped
> > out after a short time and never swap-in until process exits. However,
> > we put it from active list so that it has PG_workingset but it's cold
> > page.
> > 
> > Yes, we cannot use the flag for such purpose in this SEQ replacement so
> > I will not insist on it.
> 
> Well, I'm designing the flag so that it's useful for the case I am
> introducing it for :)
> 
> I have no problem with changing its semantics later on if you want to
> build on top of it, rename it, anything - so far as the LRU balancing
> is unaffected of course.
> 
> But I don't think it makes sense to provision it for potential future
> cases that may or may not materialize.

I admit I was so far from the topic. Sorry, Johannes. :)

The reason I guess is naming of the flag. When you introduced the flag,
I popped a vague idea to utilize the flag in future if it represents real
workingset but as I reviewed code, I realized it's not what I want but just
thing to detect activated page before reclaiming. So to me, it looks like
PG_activated rather than PG_workingset. ;-)

> 
> > > > Do we want to retain [1]?
> > > > 
> > > > This patch motivates from swap IO could be much faster than file IO
> > > > so that it would be natural if we rely on refaulting feedback rather
> > > > than forcing evicting file cache?
> > > > 
> > > > [1] e9868505987a, mm,vmscan: only evict file pages when we have plenty?
> > > 
> > > Yes! We don't want to go after the workingset, whether it be cache or
> > > anonymous, while there is single-use page cache lying around that we
> > > can reclaim for free, with no IO and little risk of future IO. Anon
> > > memory doesn't have this equivalent. Only cache is lazy-reclaimed.
> > > 
> > > Once the cache refaults, we activate it to reflect the fact that it's
> > > workingset. Only when we run out of single-use cache do we want to
> > > reclaim multi-use pages, and *then* we balance workingsets based on
> > > cost of refetching each side from secondary storage.
> > 
> > If pages in inactive file LRU are really single-use page cache, I agree.
> > 
> > However, how does the logic can work like that?
> > If reclaimed file pages were part of workingset(i.e., refault happens),
> > we give the pres

Re: [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> [ Unknown signature status ]
> On 20/06/16 10:21, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Roger Quadros  writes:
>>> The OTG core will use struct otg_gadget_ops to
>>> start/stop the gadget controller.
>>>
>>> The main purpose of this interface is to avoid directly
>>> calling usb_gadget_start/stop() from the OTG core as they
>>> wouldn't be defined in the built-in symbol table if
>>> CONFIG_USB_GADGET is m.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>>  include/linux/usb/gadget.h | 16 
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>>> index 2dd9e6b..f4fc0aa 100644
>>> --- a/include/linux/usb/gadget.h
>>> +++ b/include/linux/usb/gadget.h
>>> @@ -639,6 +639,22 @@ struct usb_gadget_driver {
>>>  };
>>>  
>>>  
>>> +/*-*/
>>> +
>>> +/**
>>> + * struct otg_gadget_ops - Interface between OTG core and gadget
>>> + *
>>> + * Provided by the gadget core to allow the OTG core to start/stop the 
>>> gadget
>>> + *
>>> + * @start: function to start the gadget
>>> + * @stop: function to stop the gadget
>>> + * @connect_control: function to connect/disconnect from the bus
>>> + */
>>> +struct otg_gadget_ops {
>>> +   int (*start)(struct usb_gadget *gadget);
>>> +   int (*stop)(struct usb_gadget *gadget);
>>> +   int (*connect_control)(struct usb_gadget *gadget, bool connect);
>>> +};
>> 
>> you shouldn't need these at all. They are already part of the gadget
>> framework as ->udc_start(), ->udc_stop() and ->pullup()
>> 
>
> This is to avoid the undefined symbol errors during build when OTG has is
> built-in because USB (host) is built-in but GADGET is still a module.

change your Kconfig dependencies. OTG layer shouldn't be built-in unless
both Gadget and Host are built-in.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc3: gadget: Add the suspend state checking when stopping gadget

[Felipe Balbi]

Baolin Wang  writes:

> It will be crash to stop gadget when the dwc3 device had been into suspend
> state, thus we need to check if the dwc3 device had been into suspend state
> when UDC try to stop gadget.
>
> By the way I have rebased on your 'testing/next' branch.

do you really want this note to be in commit log? Seems like this should
be after tearline below.

>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/usb/dwc3/gadget.c |3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 6dde376..351769e 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1791,6 +1791,9 @@ err0:
>  
>  static void __dwc3_gadget_stop(struct dwc3 *dwc)
>  {
> + if (pm_runtime_suspended(dwc->dev))
> + return;
> +
>   dwc3_gadget_disable_irq(dwc);
>   __dwc3_gadget_ep_disable(dwc->eps[0]);
>   __dwc3_gadget_ep_disable(dwc->eps[1]);
> -- 
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: ktime_get_ts64() splat during resume

[chenyu]

On Fri, Jun 17, 2016 at 11:28 PM, Rafael J. Wysocki  wrote:
> On Fri, Jun 17, 2016 at 4:33 PM, Borislav Petkov  wrote:
>> Ok,
>>
>> bisect is done, full log below.
>>
>> Rafael, that fix
>>
>>   70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code passes 
>> control to the image kernel")
>>
>> breaks s2disk here. It explodes during resume and a statically allocated
>> struct's member is NULL. See
>>
>> https://lkml.kernel.org/r/20160617105435.gb15...@pd.tnic
>>
>> for the splat and some debugging attempts.
>>
>> Reverting 70595b479ce1 fixes the issue here.
>
> Quite evidently, memory is corrupted in the image kernel, but this
> particular commit only affects the boot kernel, so it can't really
> corrupt anything in the image one.
>
In previous patch,
before we jump to the new kernel entry, we add the
text mapping to temp_level4_pgt,

 /* switch over to the temporary kernel text mapping */
movq%r8, (%r9)
If I understand correctly,  r9 contains the virtual address
of restore_pgd_addr, since the page table for restore_pgd_addr might be
incoherent across hibernation(as NX patch changes the kernel text mapping
to dynamically mapping), so we might write pmd entry to an incorrect place in
temp_level4_pgt?

Yu

Re: [PATCH] usb: dwc3: gadget: Add the suspend state checking when stopping gadget

[Baolin Wang]

On 20 June 2016 at 16:15, Felipe Balbi  wrote:
> Baolin Wang  writes:
>
>> It will be crash to stop gadget when the dwc3 device had been into suspend
>> state, thus we need to check if the dwc3 device had been into suspend state
>> when UDC try to stop gadget.
>>
>> By the way I have rebased on your 'testing/next' branch.
>
> do you really want this note to be in commit log? Seems like this should
> be after tearline below.

Sorry. I'll remove this in next version. Thanks for your comment.

>
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/dwc3/gadget.c |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 6dde376..351769e 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1791,6 +1791,9 @@ err0:
>>
>>  static void __dwc3_gadget_stop(struct dwc3 *dwc)
>>  {
>> + if (pm_runtime_suspended(dwc->dev))
>> + return;
>> +
>>   dwc3_gadget_disable_irq(dwc);
>>   __dwc3_gadget_ep_disable(dwc->eps[0]);
>>   __dwc3_gadget_ep_disable(dwc->eps[1]);
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> balbi



-- 
Baolin.wang
Best Regards

Re: [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero

[Lee Jones]

On Mon, 20 Jun 2016, Phil Reid wrote:

> On 20/06/2016 14:21, Lothar Waßmann wrote:
> >Hi,
> >
> >On Fri, 17 Jun 2016 15:17:19 +0100 Lee Jones wrote:
> >>On Sat, 11 Jun 2016, Lothar Waßmann wrote:
> >>>On Fri, 10 Jun 2016 15:54:49 +0100 Lee Jones wrote:
> On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> >On Fri, 10 Jun 2016 08:44:49 +0100 Lee Jones wrote:
> >>On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> >>
> >>>Hi,
> >>>
> >>>On Thu, 9 Jun 2016 14:51:25 +0100 Lee Jones wrote:
> On Tue, 07 Jun 2016, Lothar Waßmann wrote:
> 
> >'brightness' is usually an index into a table of duty_cycle values,
> >where the value at index 0 may well be non-zero
> >(tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are 
> >real-life
> >examples).
> >Thus brightness == 0 does not necessarily mean that the PWM output
> >will be inactive.
> >Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide
> >whether to disable the PWM.
> >
> >Signed-off-by: Lothar Waßmann 
> >---
> >Changes wrt. v1:
> >  - update binding docs to reflect the change
> >
> > .../devicetree/bindings/leds/backlight/pwm-backlight.txt | 
> > 9 ++---
> > drivers/video/backlight/pwm_bl.c | 
> > 4 ++--
> > 2 files changed, 8 insertions(+), 5 deletions(-)
> >
> >diff --git 
> >a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt 
> >b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >index 764db86..95fa8a9 100644
> >--- 
> >a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >+++ 
> >b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >@@ -4,10 +4,13 @@ Required properties:
> >   - compatible: "pwm-backlight"
> >   - pwms: OF device-tree PWM specification (see PWM binding[0])
> >   - brightness-levels: Array of distinct brightness levels. 
> > Typically these
> >-  are in the range from 0 to 255, but any range starting at 0 
> >will do.
> >+  are in the range from 0 to 255, but any range will do.
> >   The actual brightness level (PWM duty cycle) will be 
> > interpolated
> >-  from these values. 0 means a 0% duty cycle (darkest/off), 
> >while the
> >-  last value in the array represents a 100% duty cycle 
> >(brightest).
> >+  from these values. 0 means a 0% duty cycle, while the highest 
> >value in
> >+  the array represents a 100% duty cycle.
> >+  The range may be in reverse order (starting with the maximum 
> >duty cycle
> >+  value) to create a PWM signal with the 100% duty cycle 
> >representing
> >+  minimum and 0% duty cycle maximum brigthness.
> >   - default-brightness-level: the default brightness level (index 
> > into the
> >   array defined by the "brightness-levels" property)
> >   - power-supply: regulator for supply voltage
> >diff --git a/drivers/video/backlight/pwm_bl.c 
> >b/drivers/video/backlight/pwm_bl.c
> >index b2b366b..80b2b52 100644
> >--- a/drivers/video/backlight/pwm_bl.c
> >+++ b/drivers/video/backlight/pwm_bl.c
> >@@ -103,8 +103,8 @@ static int pwm_backlight_update_status(struct 
> >backlight_device *bl)
> > if (pb->notify)
> > brightness = pb->notify(pb->dev, brightness);
> >
> >-if (brightness > 0) {
> >-duty_cycle = compute_duty_cycle(pb, brightness);
> >+duty_cycle = compute_duty_cycle(pb, brightness);
> >+if (duty_cycle > 0) {
> 
> How does this work in the aforementioned:
> 
>   "The range may be in reverse order"
> 
> ... case?  Surely when duty_cycle is when the screen should be at it's
> brightest?  Wouldn't it confuse the user if they turn their brightness
> *up* and the screen goes *off*?
> 
> >>>Assuming that the PWM output is inactive (LOW) when the duty_cycle is
> >>>set to zero, there will be no difference between operating the PWM at
> >>>duty_cycle 0 or disabling it.
> >>>
> >>>Currently, the screen will go bright when it should be off in this
> >>>case.
> >>
> >>It sounds like we need something that lets the framework know if
> >>duty_cycle = MAX is the brightest or if duty_cycle = 0 is.  Either way
> >>someone is going to get screwed by this logic.
> >>
> >The backlight framework does not (and does not need to) know anything
> >about PWM duty cycles. Its 'brightness' values are consistently 0 ==

Re: [PATCH] sparse: Track the boundaries of memory sections for accurate checks

[Michal Hocko]

On Sat 18-06-16 12:11:19, KarimAllah Ahmed wrote:
> When sparse memory model is used an array of memory sections is created to
> track each block of contiguous physical pages. Each element of this array
> contains PAGES_PER_SECTION pages. During the creation of this array the actual
> boundaries of the memory block is lost, so the whole block is either 
> considered
> as present or not.
> 
> pfn_valid() in the sparse memory configuration checks which memory sections 
> the
> pfn belongs to then checks whether it's present or not. This yields 
> sub-optimal
> results when the available memory doesn't cover the whole memory section,
> because pfn_valid will return 'true' even for the unavailable pfns at the
> boundaries of the memory section.

Please be more verbose of _why_ the patch is needed. Why those
"sub-optimal results" matter?

> Cc: Andrew Morton 
> Cc: Mel Gorman 
> Cc: Vlastimil Babka 
> Cc: Michal Hocko 
> Cc: Johannes Weiner 
> Cc: Yaowei Bai 
> Cc: Dan Williams 
> Cc: Joe Perches 
> Cc: Tejun Heo 
> Cc: Anthony Liguori 
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed 
> Signed-off-by: Jan H. Schönherr 
> ---
>  include/linux/mmzone.h | 22 --
>  mm/sparse.c| 37 -
>  2 files changed, 52 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 02069c2..f76a0e1 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1067,8 +1067,12 @@ struct mem_section {
>* section. (see page_ext.h about this.)
>*/
>   struct page_ext *page_ext;
> - unsigned long pad;
> + unsigned long pad[3];
>  #endif
> +
> + unsigned long first_pfn;
> + unsigned long last_pfn;
> +
>   /*
>* WARNING: mem_section must be a power-of-2 in size for the
>* calculation and use of SECTION_ROOT_MASK to make sense.
> @@ -1140,23 +1144,29 @@ static inline int valid_section_nr(unsigned long nr)
>  
>  static inline struct mem_section *__pfn_to_section(unsigned long pfn)
>  {
> + if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> + return NULL;
> +
>   return __nr_to_section(pfn_to_section_nr(pfn));
>  }
>  
>  #ifndef CONFIG_HAVE_ARCH_PFN_VALID
>  static inline int pfn_valid(unsigned long pfn)
>  {
> - if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> + struct mem_section *ms;
> +
> + ms = __pfn_to_section(pfn);
> +
> + if (ms && !(ms->first_pfn <= pfn && ms->last_pfn >= pfn))
>   return 0;
> - return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
> +
> + return valid_section(ms);
>  }
>  #endif
>  
>  static inline int pfn_present(unsigned long pfn)
>  {
> - if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> - return 0;
> - return present_section(__nr_to_section(pfn_to_section_nr(pfn)));
> + return present_section(__pfn_to_section(pfn));
>  }
>  
>  /*
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 5d0cf45..3c91837 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -166,24 +166,59 @@ void __meminit mminit_validate_memmodel_limits(unsigned 
> long *start_pfn,
>   }
>  }
>  
> +static int __init
> +overlaps(u64 start1, u64 end1, u64 start2, u64 end2)
> +{
> + u64 start, end;
> +
> + start = max(start1, start2);
> + end = min(end1, end2);
> + return start <= end;
> +}
> +
>  /* Record a memory area against a node. */
>  void __init memory_present(int nid, unsigned long start, unsigned long end)
>  {
> + unsigned long first_pfn = start;
>   unsigned long pfn;
>  
>   start &= PAGE_SECTION_MASK;
>   mminit_validate_memmodel_limits(&start, &end);
>   for (pfn = start; pfn < end; pfn += PAGES_PER_SECTION) {
>   unsigned long section = pfn_to_section_nr(pfn);
> + unsigned long last_pfn = min(pfn + PAGES_PER_SECTION, end) - 1;
>   struct mem_section *ms;
>  
>   sparse_index_init(section, nid);
>   set_section_nid(section, nid);
>  
>   ms = __nr_to_section(section);
> - if (!ms->section_mem_map)
> + if (!ms->section_mem_map) {
>   ms->section_mem_map = sparse_encode_early_nid(nid) |
>   SECTION_MARKED_PRESENT;
> + } else {
> + /* Merge the two regions */
> + WARN_ON(sparse_early_nid(ms) != nid);
> +
> + /*
> +  * If they don't overlap there will be a hole in
> +  * between where meta-data says it's valid even though
> +  * it's not.
> +  */
> + if (!overlaps(first_pfn, last_pfn + 1,
> +   ms->first_pfn, ms->last_pfn + 1)) {
> + pr_info("Merging non-contiguous pfn ranges 
> 0x%lx-0x%lx and 0x%lx-0x%

Re: [PATCH] ARM: AM43XX: hwmod: Fix RSTST register offset for pruss

[Keerthy]

On Monday 20 June 2016 12:35 PM, Mohammed, Afzal wrote:

Hi,

J, KEERTHY wrote on Monday, June 20, 2016 9:22 AM:


pruss hwmod RSTST register wrongly points to PWRSTCTRL register in case of
am43xx. Fix the RSTST register offset value.



This can lead to setting of wrong power state values for PER domain.


Just curious, does it happen or noticed by going thr' the code ?


No i was trying omap4_prminst_deassert_hardreset on AM43XX on my local 
tree and i saw issues and then saw that RSTST register offsets were 
wrongly populated. Hence fixing the same.




Regards
afzal

Re: [PATCH v4 1/2] i2c: qup: add ACPI support

[Mika Westerberg]

On Sat, Jun 18, 2016 at 04:10:34PM +0200, Wolfram Sang wrote:
> On Wed, Jun 08, 2016 at 12:19:44PM -0600, Austin Christ wrote:
> > From: Naveen Kaje 
> > 
> > Add support to get the device parameters from ACPI. Assume
> > that the clocks are managed by firmware.
> 
> Adding Mika to CC: Can you have a look at the ACPI binding? Looks ok to
> me...
> 
> > 
> > Signed-off-by: Naveen Kaje 
> > Signed-off-by: Austin Christ 
> > Reviewed-by: sricha...@codeaurora.org
> 
> Please add a name before the email address
> 
> > ---
> >  drivers/i2c/busses/i2c-qup.c | 59 
> > 
> >  1 file changed, 43 insertions(+), 16 deletions(-)
> > 
> > Changes:
> > - v4:
> >  - remove warning for fall back to default clock frequency
> > - v3:
> >  - clean up unused variable
> > - v2:
> >  - clean up redundant checks and variables
> > 
> > diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> > index 4da..0f23d58 100644
> > --- a/drivers/i2c/busses/i2c-qup.c
> > +++ b/drivers/i2c/busses/i2c-qup.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> Keep includes sorted.
> 
> >  
> >  /* QUP Registers */
> >  #define QUP_CONFIG 0x000
> > @@ -132,6 +133,10 @@
> >  /* Max timeout in ms for 32k bytes */
> >  #define TOUT_MAX   300
> >  
> > +/* Default values. Use these if FW query fails */
> > +#define DEFAULT_CLK_FREQ 10
> > +#define DEFAULT_SRC_CLK 2000
> > +
> >  struct qup_i2c_block {
> > int count;
> > int pos;
> > @@ -1354,14 +1359,13 @@ static void qup_i2c_disable_clocks(struct 
> > qup_i2c_dev *qup)
> >  static int qup_i2c_probe(struct platform_device *pdev)
> >  {
> > static const int blk_sizes[] = {4, 16, 32};
> > -   struct device_node *node = pdev->dev.of_node;
> > struct qup_i2c_dev *qup;
> > unsigned long one_bit_t;
> > struct resource *res;
> > u32 io_mode, hw_ver, size;
> > int ret, fs_div, hs_div;
> > -   int src_clk_freq;
> > -   u32 clk_freq = 10;
> > +   u32 src_clk_freq = 0;
> > +   u32 clk_freq = DEFAULT_CLK_FREQ;
> > int blocks;
> >  
> > qup = devm_kzalloc(&pdev->dev, sizeof(*qup), GFP_KERNEL);
> > @@ -1372,7 +1376,11 @@ static int qup_i2c_probe(struct platform_device 
> > *pdev)
> > init_completion(&qup->xfer);
> > platform_set_drvdata(pdev, qup);
> >  
> > -   of_property_read_u32(node, "clock-frequency", &clk_freq);
> > +   ret = device_property_read_u32(qup->dev, "clock-frequency", &clk_freq);
> > +   if (ret) {
> > +   dev_notice(qup->dev, "using default clock-frequency %d",
> > +   DEFAULT_CLK_FREQ);
> > +   }
> >  
> > if (of_device_is_compatible(pdev->dev.of_node, "qcom,i2c-qup-v1.1.1")) {
> > qup->adap.algo = &qup_i2c_algo;
> > @@ -1454,20 +1462,31 @@ nodma:
> > return qup->irq;
> > }
> >  
> > -   qup->clk = devm_clk_get(qup->dev, "core");
> > -   if (IS_ERR(qup->clk)) {
> > -   dev_err(qup->dev, "Could not get core clock\n");
> > -   return PTR_ERR(qup->clk);
> > -   }
> > +   if (ACPI_HANDLE(qup->dev)) {

Use has_acpi_companion() if you need to.

> > +   ret = device_property_read_u32(qup->dev,
> > +   "src-clock-hz", &src_clk_freq);

Alternatively you can make qup_i2c_acpi_probe() which creates clock for
you based on the ACPI ID of the device. Then you do not need to have
these custom properties just because ACPI does not have native support
for clocks.

Ideally if one uses device_property_* API it should not need to
distinguish between DT/ACPI/whatnot.

> > +   if (ret) {
> > +   dev_warn(qup->dev, "using default src-clock-hz %d",
> > +   DEFAULT_SRC_CLK);

Why this is warning?

> > +   src_clk_freq = DEFAULT_SRC_CLK;
> > +   }

> > +   ACPI_COMPANION_SET(&qup->adap.dev, ACPI_COMPANION(qup->dev));
> > +   } else {
> > +   qup->clk = devm_clk_get(qup->dev, "core");
> > +   if (IS_ERR(qup->clk)) {
> > +   dev_err(qup->dev, "Could not get core clock\n");
> > +   return PTR_ERR(qup->clk);
> > +   }
> >  
> > -   qup->pclk = devm_clk_get(qup->dev, "iface");
> > -   if (IS_ERR(qup->pclk)) {
> > -   dev_err(qup->dev, "Could not get iface clock\n");
> > -   return PTR_ERR(qup->pclk);
> > +   qup->pclk = devm_clk_get(qup->dev, "iface");
> > +   if (IS_ERR(qup->pclk)) {
> > +   dev_err(qup->dev, "Could not get iface clock\n");
> > +   return PTR_ERR(qup->pclk);
> > +   }
> > +   qup_i2c_enable_clocks(qup);
> > +   src_clk_freq = clk_get_rate(qup->clk);
> > }
> >  
> > -   qup_i2c_enable_clocks(qup);
> > -
> > /*
> >  * Bootloaders might leave a pending interrupt on certain QUP's,
> >  * so we reset the core before registering for interrupts.
> > @@ -1514,7 +1533,6 @@ nodma:
> > 

Re: [PATCH v5 0/7] /dev/random - a new approach

[Pavel Machek]

Hi!

> > On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> > > Hi Herbert, Ted,
> > > 
> > > The following patch set provides a different approach to /dev/random which
> > > I call Linux Random Number Generator (LRNG) to collect entropy within the
> > > Linux kernel. The main improvements compared to the legacy /dev/random is
> > > to provide sufficient entropy during boot time as well as in virtual
> > > environments and when using SSDs. A secondary design goal is to limit the
> > > impact of the entropy collection on massive parallel systems and also
> > > allow the use accelerated cryptographic primitives. Also, all steps of
> > > the entropic data processing are testable. Finally massive performance
> > > improvements are visible at /dev/urandom and get_random_bytes.
> > 
> > Dunno. It is very similar to existing rng, AFAICT. And at the very
> > least, constants in existing RNG could be tuned to provide "entropy at
> > the boot time".
> 
> The key differences and thus my main concerns I have with the current design 
> are the following items. If we would change them, it is an intrusive change. 
> As of now, I have not seen that intrusive changes were accepted. This led me 
> to develop a competing algorithm.

Well, intrusive changes are hard to do, but replacing whole subsystems
is even harder -- and rightly so.

> - There was a debate around my approach assuming one bit of entropy per 
> received IRQ. I am really wondering about that discussion when there is a 
> much 
> bigger "forcast" problem with the legacy /dev/random: how can we credit HIDs 
> up to 11 bits of entropy when the user (a potential adversary) triggers these 
> events? I am sure I would be shot down with such an approach if I would 
> deliver that with a new implementation.

Well, if you can demonstrate 11 bits is too much, go ahead... I'm sure
that is rather easy to adjust.

But I believe that 1) user is not normally an adversary and 2) the
best thing for him to do would still be "pressing nothing". It will be
hard to press keys (etc) with great enough precision...

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] Bluetooth: btmrvl: fix slab-out-of-bounds access in btmrvl_sdio

[Ricky Liang]

Kasan reported slab-out-of-bounds access in btmrvl_sdio:

[   33.055400] 
==
[   33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr 
ffc0d89b4a00
[   33.070529] Read of size 256 by task btmrvl_main_ser/3576
[   33.075885] 
=
[   33.084002] BUG kmalloc-256 (Tainted: GB ): kasan: bad access 
detected
[   33.091511] 
-

[   33.413498] Call trace:
[   33.415928] [] dump_backtrace+0x0/0x190
[   33.421288] [] show_stack+0x1c/0x28
[   33.426305] [] dump_stack+0xa0/0xf8
[   33.431320] [] print_trailer+0x158/0x16c
[   33.436765] [] object_err+0x48/0x5c
[   33.441780] [] kasan_report+0x344/0x510
[   33.447141] [] __asan_loadN+0x20/0x150
[   33.452413] [] memcpy+0x20/0x50
[   33.457084] [] swiotlb_tbl_map_single+0x2ec/0x310
[   33.463305] [] map_single+0x24/0x30
[   33.468320] [] swiotlb_map_sg_attrs+0xec/0x21c
[   33.474286] [] __swiotlb_map_sg_attrs+0x48/0xec
[   33.480339] [] msdc_prepare_data.isra.11+0xf0/0x11c
[   33.486733] [] msdc_ops_request+0x74/0xf0
[   33.492266] [] __mmc_start_request+0x78/0x8c
[   33.498057] [] mmc_start_request+0x220/0x240
[   33.503848] [] mmc_wait_for_req+0x78/0x250
[   33.509468] [] mmc_io_rw_extended+0x2ec/0x388
[   33.515347] [] sdio_io_rw_ext_helper+0x160/0x268
[   33.521483] [] sdio_writesb+0x40/0x50
[   33.526677] [] btmrvl_sdio_host_to_card+0x124/0x1bc 
[btmrvl_sdio]
[   33.534283] [] btmrvl_service_main_thread+0x384/0x428 
[btmrvl]
[   33.541626] [] kthread+0x140/0x158
[   33.546550] Memory state around the buggy address:
[   33.551305]  ffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.558474]  ffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[   33.565643] >ffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
fc
[   33.572809] ^
[   33.579889]  ffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.587055]  ffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[   33.594221] 
==

The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:

  1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
  2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.

This patch fixes the issue by allocating a buffer which is big enough for
SDIO_BLOCK_SIZE transfer and/or BTSDIO_DMA_ALIGN address relocation.

Signed-off-by: Ricky Liang 
---
 drivers/bluetooth/btmrvl_sdio.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index f425ddf..0bfeb19 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1071,7 +1071,6 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private 
*priv,
 {
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret = 0;
-   int buf_block_len;
int blksz;
int i = 0;
u8 *buf = NULL;
@@ -1083,9 +1082,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
return -EINVAL;
}
 
+   blksz = DIV_ROUND_UP(nb, SDIO_BLOCK_SIZE) * SDIO_BLOCK_SIZE;
+
buf = payload;
if ((unsigned long) payload & (BTSDIO_DMA_ALIGN - 1)) {
-   tmpbufsz = ALIGN_SZ(nb, BTSDIO_DMA_ALIGN);
+   tmpbufsz = ALIGN_SZ(blksz, BTSDIO_DMA_ALIGN) +
+  BTSDIO_DMA_ALIGN;
tmpbuf = kzalloc(tmpbufsz, GFP_KERNEL);
if (!tmpbuf)
return -ENOMEM;
@@ -1093,15 +1095,12 @@ static int btmrvl_sdio_host_to_card(struct 
btmrvl_private *priv,
memcpy(buf, payload, nb);
}
 
-   blksz = SDIO_BLOCK_SIZE;
-   buf_block_len = DIV_ROUND_UP(nb, blksz);
-
sdio_claim_host(card->func);
 
do {
/* Transfer data to card */
ret = sdio_writesb(card->func, card->ioport, buf,
-  buf_block_len * blksz);
+  blksz);
if (ret < 0) {
i++;
BT_ERR("i=%d writesb failed: %d", i, ret);
-- 
2.1.2

Re: [PATCH v9 2/4] power: reset: add reboot mode driver

[Andy Yan]

Hi Krzysztof:

On 2016年06月20日 16:09, Krzysztof Kozlowski wrote:

On 06/20/2016 08:38 AM, Andy Yan wrote:

This driver parses the reboot commands like "reboot bootloader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram, which can
be read by the bootloader after system reboot, then the bootloader
can take different action according to the mode stored.

This is commonly used on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Reviewed-by: Matthias Brugger 
Reviewed-by: Moritz Fischer 
Tested-by: John Stultz 
Acked-by: John Stultz 
Signed-off-by: Andy Yan 

---

Changes in v9:
- select MFD_SYSCON when syscon-reboot-mode driver enabled
- refactoring error handling in reboot_mode_register

Changes in v8:
- do some cleanup when driver ubind

Changes in v7:
- address some suggestions from Krzysztof, make syscon-reboot-mode driver data 
self-contained.

Changes in v6: None
Changes in v5:
- use two blank space under help in Kconfig
- use unsigned int instead of int for member magic in struct mode_info

Changes in v4:
- make this driver depends on OF to avoid kbuild test error

Changes in v3:
- scan multi properities
- add mask value for some platform which only use some bits of the register
   to store boot mode magic value

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

  drivers/power/reset/Kconfig  |  14 
  drivers/power/reset/Makefile |   2 +
  drivers/power/reset/reboot-mode.c| 128 +++
  drivers/power/reset/reboot-mode.h|  14 
  drivers/power/reset/syscon-reboot-mode.c | 100 
  5 files changed, 258 insertions(+)
  create mode 100644 drivers/power/reset/reboot-mode.c
  create mode 100644 drivers/power/reset/reboot-mode.h
  create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9bb2622..4ceaf74 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -183,5 +183,19 @@ config POWER_RESET_ZX
help
  Reboot support for ZTE SoCs.
  
+config REBOOT_MODE

+   tristate
+
+config SYSCON_REBOOT_MODE
+   bool "Generic SYSCON regmap reboot mode driver"

Why not tristate?


   I see many reset drivers in this directories  use bool, so I follow 
them.


Beside that the patch looks good.

Best regards,
Krzysztof


+   depends on OF
+   select REBOOT_MODE
+   select MFD_SYSCON
+   help
+ Say y here will enable reboot mode driver. This will
+ get reboot mode arguments and store it in SYSCON mapped
+ register, then the bootloader can read it to take different
+ action according to the mode.
+

Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Alexandre Belloni]

On 20/06/2016 at 03:16:35 +, Yang, Wenyou wrote :
> > Sure, what I mean is that you can try to get the regmap for the SFR in 
> > every case.
> > Depending on whether you were able to get it, you can decide to call
> > ohci_at91_port_suspend/resume or not (just test for sfr_regmap != NULL).
> 
> I don't think so. The SFR includes a lot of miscellaneous functions, more 
> than this one.
> 

I know but this is irrelevant to this discussion. If you need to use the
SFR from another driver you will simply get it from that other driver.

I that case, you will try to get "atmel,sama5d2-sfr". It is only present
on sama5d2 so you have enough information to know whether or not you can
use it to suspend/resume.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2] usb: dwc3: gadget: Add the suspend state checking when stopping gadget

[Baolin Wang]

It will be crash to stop gadget when the dwc3 device had been into suspend
state, thus we need to check if the dwc3 device had been into suspend state
when UDC try to stop gadget.

Signed-off-by: Baolin Wang 
---
 drivers/usb/dwc3/gadget.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6dde376..351769e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1791,6 +1791,9 @@ err0:
 
 static void __dwc3_gadget_stop(struct dwc3 *dwc)
 {
+   if (pm_runtime_suspended(dwc->dev))
+   return;
+
dwc3_gadget_disable_irq(dwc);
__dwc3_gadget_ep_disable(dwc->eps[0]);
__dwc3_gadget_ep_disable(dwc->eps[1]);
-- 
1.7.9.5

Re: [PATCH 2/2] arm64: dts: mediatek: add mt6755 support

[Matthias Brugger]

On 14/06/16 04:20, Mars Cheng wrote:

This adds basic chip support for MT6755 SoC.

Signed-off-by: Mars Cheng 
---
  arch/arm64/boot/dts/mediatek/Makefile |1 +
  arch/arm64/boot/dts/mediatek/mt6755-phone.dts |   39 +++
  arch/arm64/boot/dts/mediatek/mt6755.dtsi  |  143 +
  3 files changed, 183 insertions(+)
  create mode 100644 arch/arm64/boot/dts/mediatek/mt6755-phone.dts
  create mode 100644 arch/arm64/boot/dts/mediatek/mt6755.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index e0a4bff..9abdb01 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-phone.dtb


I suppose this is a evaluation platform? Is this different to the EVB 
for this SoC? Or will the only phone build with this SoC be this one?


Thanks,
Matthias


  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb

diff --git a/arch/arm64/boot/dts/mediatek/mt6755-phone.dts 
b/arch/arm64/boot/dts/mediatek/mt6755-phone.dts
new file mode 100644
index 000..f551666
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6755-phone.dts
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "mt6755.dtsi"
+
+/ {
+   model = "MediaTek MT6755 phone";
+   compatible = "mediatek,mt6755-phone", "mediatek,mt6755";
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;


we don't enable uart1, so we don't need the alias.


+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x1e80>;
+   };
+
+   chosen {
+   stdout-path = "serial0:921600n8";
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6755.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6755.dtsi
new file mode 100644
index 000..36c3384
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6755.dtsi
@@ -0,0 +1,143 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt6755";
+   interrupt-parent = <&sysirq>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x000>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x001>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x002>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x003>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x100>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x101>;
+   };
+
+   cpu6: cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   re

Re: [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface

[Roger Quadros]

On 20/06/16 11:13, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> [ Unknown signature status ]
>> On 20/06/16 10:21, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros  writes:
 The OTG core will use struct otg_gadget_ops to
 start/stop the gadget controller.

 The main purpose of this interface is to avoid directly
 calling usb_gadget_start/stop() from the OTG core as they
 wouldn't be defined in the built-in symbol table if
 CONFIG_USB_GADGET is m.

 Signed-off-by: Roger Quadros 
 ---
  include/linux/usb/gadget.h | 16 
  1 file changed, 16 insertions(+)

 diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
 index 2dd9e6b..f4fc0aa 100644
 --- a/include/linux/usb/gadget.h
 +++ b/include/linux/usb/gadget.h
 @@ -639,6 +639,22 @@ struct usb_gadget_driver {
  };
  
  
 +/*-*/
 +
 +/**
 + * struct otg_gadget_ops - Interface between OTG core and gadget
 + *
 + * Provided by the gadget core to allow the OTG core to start/stop the 
 gadget
 + *
 + * @start: function to start the gadget
 + * @stop: function to stop the gadget
 + * @connect_control: function to connect/disconnect from the bus
 + */
 +struct otg_gadget_ops {
 +  int (*start)(struct usb_gadget *gadget);
 +  int (*stop)(struct usb_gadget *gadget);
 +  int (*connect_control)(struct usb_gadget *gadget, bool connect);
 +};
>>>
>>> you shouldn't need these at all. They are already part of the gadget
>>> framework as ->udc_start(), ->udc_stop() and ->pullup()
>>>
>>
>> This is to avoid the undefined symbol errors during build when OTG has is
>> built-in because USB (host) is built-in but GADGET is still a module.
> 
> change your Kconfig dependencies. OTG layer shouldn't be built-in unless
> both Gadget and Host are built-in.
> 

That is only one side of the story.
What happens if OTG is (m), Host is (m) but Gadget is (built in).

Gadget build will fail because of undefined symbol errors for all of the
OTG APIs.

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: tg_load_down NULL pointer dereference

[Peter Zijlstra]

On Mon, Jun 20, 2016 at 06:14:01AM +, AMIT NAGAL wrote:
> Hi 
> I am using  Linux kernel version 3.10.28 (ARM platform) .
> I am getting NULL pointer dereference in tg_load_down() .
> At the time of error  , tg->parent->cfs_rq  value is 0 and  tg->se value is 
> 0x0400 . ( refer to backtrace in 5) ).

Were you destroying cgroups at the time?

If so, there were some problems with cgroup teardown recently, see
patches:

  6fe1f348b3dd ("sched/cgroup: Fix cgroup entity load tracking tear-down")
  2f5177f0fd7e ("sched/cgroup: Fix/cleanup cgroup teardown/init")

Which depend on:

  aa226ff4a1ce ("cgroup: make sure a parent css isn't offlined before its 
children")
  8bb5ef79bc0f ("cgroup: make sure a parent css isn't freed before its 
children")

I've no idea if any of that is relevant to your ancient kernel, let
alone applies, that's your problem for using ancient wares.

If you can reproduce with a current kernel (4.6+) then I might look more.

mmc: dw_mmc: warning with CONFIG_DMA_API_DEBUG

[Seung-Woo Kim]

Hi folks,

During booting test on my Exynos5422 based Odroid-XU3, kernel compiled
with CONFIG_DMA_API_DEBUG reported following warning:

[ cut here ]
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1096 check_unmap+0x7bc/0xb38
dwmmc_exynos 1220.mmc: DMA-API: device driver tries to free DMA memory it 
has not allocated [device address=0x6d9d2200]
[size=128 bytes]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc4 #26
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x80/0x94)
[] (dump_stack) from [] (__warn+0xf8/0x110)
[] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
[] (warn_slowpath_fmt) from [] (check_unmap+0x7bc/0xb38)
[] (check_unmap) from [] (debug_dma_unmap_sg+0x118/0x148)
[] (debug_dma_unmap_sg) from [] 
(dw_mci_dma_cleanup+0x7c/0xb8)
[] (dw_mci_dma_cleanup) from [] (dw_mci_stop_dma+0x40/0x50)
[] (dw_mci_stop_dma) from [] 
(dw_mci_tasklet_func+0x130/0x3b4)
[] (dw_mci_tasklet_func) from [] (tasklet_action+0xb4/0x150)
[] (tasklet_action) from [] (__do_softirq+0xe4/0x3cc)
[] (__do_softirq) from [] (irq_exit+0xd0/0x10c)
[] (irq_exit) from [] (__handle_domain_irq+0x90/0xfc)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x64/0xa8)
[] (gic_handle_irq) from [] (__irq_svc+0x54/0x90)
Exception stack(0xc1101ef8 to 0xc1101f40)
1ee0:   0001 
1f00:  c011b600 c110 c110753c  c11c3984 c11074d4 c1107548
1f20:  c1101f54 c1101f58 c1101f48 c010a1fc c010a200 6013 
[] (__irq_svc) from [] (arch_cpu_idle+0x48/0x4c)
[] (arch_cpu_idle) from [] (default_idle_call+0x30/0x3c)
[] (default_idle_call) from [] 
(cpu_startup_entry+0x358/0x3b4)
[] (cpu_startup_entry) from [] (rest_init+0x94/0x98)
[] (rest_init) from [] (start_kernel+0x3a4/0x3b0)
[] (start_kernel) from [<4000807c>] (0x4000807c)
---[ end trace 256f83eed365daf0 ]---

The warning occurs because after complete callback function,
dw_mci_dmac_complete_dma() is called, then dw_mci_stop_dma() is called
again. So it causes dma_unmap_sg() is called twice for same sg. It
occurs during clock setting at booting time.

Simply, clearing host->using_dma flag on dw_mci_dmac_complete_dma() and
dw_mci_stop_dma() like following fixes the issue, but I am not sure
this approach is proper.
---
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 2cc6123..a71c94b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -388,6 +388,7 @@ static void dw_mci_stop_dma(struct dw_mci *host)
if (host->using_dma) {
host->dma_ops->stop(host);
host->dma_ops->cleanup(host);
+   host->using_dma = 0;
}
 
/* Data transfer was stopped by the interrupt handler */
@@ -455,6 +456,7 @@ static void dw_mci_dmac_complete_dma(void *arg)
DMA_FROM_DEVICE);
 
host->dma_ops->cleanup(host);
+   host->using_dma = 0;
 
/*
 * If the card was removed, data will be NULL. No point in trying to
@@ -943,8 +945,6 @@ static int dw_mci_submit_data_dma(struct dw_mci *host, 
struct mmc_data *data)
int sg_len;
u32 temp;
 
-   host->using_dma = 0;
-
/* If we don't have a channel, we can't do DMA */
if (!host->use_dma)
return -ENODEV;
---

Best Regards,
- Seung-Woo Kim

Re: [PATCH] THP: Fix comments of __pmd_trans_huge_lock

[Kirill A. Shutemov]

On Fri, Jun 17, 2016 at 02:46:36PM -0700, Huang, Ying wrote:
> From: Huang Ying 
> 
> To make the comments consistent with the already changed code.
> 
> Signed-off-by: "Huang, Ying" 

Acked-by: Kirill A. Shutemov 

-- 
 Kirill A. Shutemov

Re: [PATCH v3 1/7] leds: convert IDE trigger to common disk trigger

[Jacek Anaszewski]

Hi Stephan,

On 06/09/2016 12:29 AM, Stephan Linz wrote:

This patch converts the IDE specific LED trigger to a generic disk
activity LED trigger. The libata core is now a trigger source just
like before the IDE disk driver. It's merely a replacement of the
string ide by disk.

The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is
widely used by any ibook/powerbook owners with great satisfaction.
Likewise, it is very often used successfully on different ARM platforms.

The original patch was split into different parts to clarify platform
independent and dependent changes.

Cc: Joseph Jezak 
Cc: Nico Macrionitis 
Cc: Jörg Sommer 
Cc: Richard Purdie 
Cc: Jacek Anaszewski 
Signed-off-by: Stephan Linz 
---
Changes in v3:
   - Port to kernel 4.x
   - Split into platform independent and dependent parts.

v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
  drivers/ata/libata-core.c|  4 
  drivers/ide/ide-disk.c   |  2 +-
  drivers/leds/leds-hp6xx.c|  2 +-
  drivers/leds/trigger/Kconfig |  8 
  drivers/leds/trigger/Makefile|  2 +-
  .../trigger/{ledtrig-ide-disk.c => ledtrig-disk.c}   | 20 ++--
  include/linux/leds.h |  6 +++---
  7 files changed, 24 insertions(+), 20 deletions(-)
  rename drivers/leds/trigger/{ledtrig-ide-disk.c => ledtrig-disk.c} (50%)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6be7770..2eca572 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -69,6 +69,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -5072,6 +5073,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
  {
struct ata_port *ap = qc->ap;

+   /* Trigger the LED (if available) */
+   ledtrig_disk_activity();
+
/* XXX: New EH and old EH use different mechanisms to
 * synchronize EH with regular execution path.
 *
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index 05dbcce..5ceb176 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive, 
struct request *rq,
BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED);
BUG_ON(rq->cmd_type != REQ_TYPE_FS);

-   ledtrig_ide_activity();
+   ledtrig_disk_activity();

pr_debug("%s: %sing: block=%llu, sectors=%u\n",
 drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
index a6b8db0..137969f 100644
--- a/drivers/leds/leds-hp6xx.c
+++ b/drivers/leds/leds-hp6xx.c
@@ -50,7 +50,7 @@ static struct led_classdev hp6xx_red_led = {

  static struct led_classdev hp6xx_green_led = {
.name   = "hp6xx:green",
-   .default_trigger= "ide-disk",
+   .default_trigger= "disk-activity",
.brightness_set = hp6xxled_green_set,
.flags  = LED_CORE_SUSPENDRESUME,
  };
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 9893d91..3f9ddb9 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -33,12 +33,12 @@ config LEDS_TRIGGER_ONESHOT

  If unsure, say Y.

-config LEDS_TRIGGER_IDE_DISK
-   bool "LED IDE Disk Trigger"
-   depends on IDE_GD_ATA
+config LEDS_TRIGGER_DISK
+   bool "LED Disk Trigger"
+   depends on IDE_GD_ATA || ATA
depends on LEDS_TRIGGERS
help
- This allows LEDs to be controlled by IDE disk activity.
+ This allows LEDs to be controlled by disk activity.
  If unsure, say Y.

  config LEDS_TRIGGER_MTD
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 8cc64a4..a72c43c 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -1,6 +1,6 @@
  obj-$(CONFIG_LEDS_TRIGGER_TIMER)  += ledtrig-timer.o
  obj-$(CONFIG_LEDS_TRIGGER_ONESHOT)+= ledtrig-oneshot.o
-obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
+obj-$(CONFIG_LEDS_TRIGGER_DISK)+= ledtrig-disk.o
  obj-$(CONFIG_LEDS_TRIGGER_MTD)+= ledtrig-mtd.o
  obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT)  += ledtrig-heartbeat.o
  obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT)  += ledtrig-backlight.o
diff --git a/drivers/leds/trigger/ledtrig-ide-disk.c 
b/drivers/leds/trigger/ledtrig-disk.c
similarity index 50%
rename from drivers/leds/trigger/ledtrig-ide-disk.c
rename to drivers/leds/trigger/ledtrig-disk.c
index 15123d3..7a1fe44 100644
--- a/drivers/leds/trigger/ledtrig-ide-disk.c
+++ b/drivers/leds/trigger/ledtrig-disk.c
@@ -1,5 +1,5 @@
  /*
- * LED IDE-Disk Activity Trigger
+ * LED Disk Activity Trigger
   *
   * Copyright 2006 Openedhand Ltd.
   *
@@ -17,20 +17,20 @@

  #define BLINK_DELAY 30

-DEFINE_LED_TR

Re: [PATCH 4/4] ASoC: tpa6130a2: Add DAPM support

[Peter Ujfalusi]

On 06/18/2016 07:42 AM, Helen Koike wrote:
> Add DAPM support and updated rx51 accordingly.
> As a consequence:
> - the exported function tpa6130a2_stereo_enable is not needed anymore
> - the mutex is dealt in the DAPM
> - the power state is tracked by the DAPM
> 
> Signed-off-by: Lars-Peter Clausen 
> [koike: port for upstream]
> Signed-off-by: Helen Koike 
> ---
>  sound/soc/codecs/tpa6130a2.c | 184 
> +--
>  sound/soc/codecs/tpa6130a2.h |  11 +--
>  sound/soc/omap/rx51.c|  22 ++
>  3 files changed, 86 insertions(+), 131 deletions(-)
> 
> diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
> index dc7bfc9..7cb5066 100644
> --- a/sound/soc/codecs/tpa6130a2.c
> +++ b/sound/soc/codecs/tpa6130a2.c
> @@ -41,79 +41,71 @@ enum tpa_model {
>   TPA6140A2,
>  };
>  
> -static struct i2c_client *tpa6130a2_client;
> -
>  /* This struct is used to save the context */
>  struct tpa6130a2_data {
> - struct mutex mutex;
>   struct regmap *regmap;
>   struct regulator *supply;
>   int power_gpio;
> - u8 power_state:1;
>   enum tpa_model id;
>  };
>  
> -static int tpa6130a2_power(u8 power)
> +static int tpa6130a2_power(struct device *dev, bool enable)

I would rather add 'struct device *dev' to tpa6130a2_data and pass the pointer
to the private struct instead to the device.

>  {
> - struct  tpa6130a2_data *data;
> - int ret = 0;
> -
> - if (WARN_ON(!tpa6130a2_client))
> - return -EINVAL;
> - data = i2c_get_clientdata(tpa6130a2_client);
> -
> - mutex_lock(&data->mutex);
> - if (power == data->power_state)
> - goto exit;
> + struct tpa6130a2_data *data = dev_get_drvdata(dev);
> + int ret;
>  
> - if (power) {
> + if (enable) {

-- 
Péter

Re: Stable -rc git trees and email headers

[Jiri Slaby]

On 06/18/2016, 07:22 AM, Fengguang Wu wrote:
> Hi Greg,
> 
> On Fri, Jun 17, 2016 at 08:16:20PM -0700, Greg KH wrote:
>> Hi,
>>
>> I've finally gotten off my butt and made my quilt trees of patches into
>> a "semi-proper" git tree to make it easier for people to test them.
>>
>> I'm now pushing the patches I accept into the stable queues into the git
>> tree here:
>>  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> 
>> Fengguang, can you add these to the 0-day bot?
> 
> Sure. It's great to see these early testing branches!

Hi,

may I ask to add the 3.12 stable tree to the testing pipeline too?

git://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux-stable.git

thanks,
-- 
js
suse labs

Re: [PATCH v5 0/6] Support calling functions on dedicated physical cpu

[Juergen Gross]

On 06/04/16 16:17, Juergen Gross wrote:
> Some hardware (e.g. Dell Studio laptops) require special functions to
> be called on physical cpu 0 in order to avoid occasional hangs. When
> running as dom0 under Xen this could be achieved only via special boot
> parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> decisions.
> 
> This patch series is adding a generic function to be able to temporarily
> pin a (virtual) cpu to a dedicated physical cpu for executing above
> mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
> requiring this functionality are modified accordingly.

Peter, Ingo,

is one of you considering to take this series for 4.8? I know not all
patches got an Ack, OTOH maintainers had 2.5 months time to object.

I'd really appreciate this series would make it into 4.8.


Juergen

> 
> Changes in V5:
> - patch 3: rename and reshuffle parameters of smp_call_on_cpu() as requested
>   by Peter Zijlstra
> - patch 3: test target cpu to be online as requested by Peter Zijlstra
> - patch 4: less wordy messages as requested by David Vrabel
> 
> Changes in V4:
> - move patches 5 and 6 further up in the series
> - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning
>   as requested by Peter Zijlstra
> - patch 3 (was 2): change return value in case of illegal cpu as
>   requested by Peter Zijlstra
> - patch 3 (was 2): make pinning of vcpu an option as suggested by
>   Peter Zijlstra
> - patches 5 and 6 (were 3 and 4): add call to get_online_cpus()
> 
> Changes in V3:
> - use get_cpu()/put_cpu() as suggested by David Vrabel
> 
> Changes in V2:
> - instead of manipulating the allowed set of cpus use cpu specific
>   workqueue as requested by Peter Zijlstra
> - add include/linux/hypervisor.h to hide architecture specific stuff
>   from generic kernel code
> 
> Juergen Gross (6):
>   xen: sync xen header
>   virt, sched: add generic vcpu pinning support
>   smp: add function to execute a function synchronously on a cpu
>   xen: add xen_pin_vcpu() to support calling functions on a dedicated
> pcpu
>   dcdbas: make use of smp_call_on_cpu()
>   hwmon: use smp_call_on_cpu() for dell-smm i8k
> 
>  MAINTAINERS   |   1 +
>  arch/x86/include/asm/hypervisor.h |   4 ++
>  arch/x86/kernel/cpu/hypervisor.c  |  11 +
>  arch/x86/xen/enlighten.c  |  40 +++
>  drivers/firmware/dcdbas.c |  51 +--
>  drivers/hwmon/dell-smm-hwmon.c|  35 +++--
>  include/linux/hypervisor.h|  17 +++
>  include/linux/smp.h   |   3 ++
>  include/xen/interface/sched.h | 100 
> +++---
>  kernel/smp.c  |  51 +++
>  kernel/up.c   |  18 +++
>  11 files changed, 273 insertions(+), 58 deletions(-)
>  create mode 100644 include/linux/hypervisor.h
> 

Re: [PATCH v9 2/4] power: reset: add reboot mode driver

[Krzysztof Kozlowski]

On 06/20/2016 08:38 AM, Andy Yan wrote:
> This driver parses the reboot commands like "reboot bootloader"
> and "reboot recovery" to get a boot mode described in the
> device tree , then call the write interfae to store the boot
> mode in some place like special register or sram, which can
> be read by the bootloader after system reboot, then the bootloader
> can take different action according to the mode stored.
> 
> This is commonly used on Android based devices, in order to
> reboot the device into fastboot or recovery mode.
> 
> Reviewed-by: Matthias Brugger 
> Reviewed-by: Moritz Fischer 
> Tested-by: John Stultz 
> Acked-by: John Stultz 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v9:
> - select MFD_SYSCON when syscon-reboot-mode driver enabled
> - refactoring error handling in reboot_mode_register
> 
> Changes in v8:
> - do some cleanup when driver ubind
> 
> Changes in v7:
> - address some suggestions from Krzysztof, make syscon-reboot-mode driver 
> data self-contained.
> 
> Changes in v6: None
> Changes in v5:
> - use two blank space under help in Kconfig
> - use unsigned int instead of int for member magic in struct mode_info
> 
> Changes in v4:
> - make this driver depends on OF to avoid kbuild test error
> 
> Changes in v3:
> - scan multi properities
> - add mask value for some platform which only use some bits of the register
>   to store boot mode magic value
> 
> Changes in v2:
> - move to dir drivers/power/reset/
> - make syscon-reboot-mode a generic driver
> 
> Changes in v1:
> - fix the embarrassed compile warning
> - correct the maskrom magic number
> - check for the normal reboot
> 
>  drivers/power/reset/Kconfig  |  14 
>  drivers/power/reset/Makefile |   2 +
>  drivers/power/reset/reboot-mode.c| 128 
> +++
>  drivers/power/reset/reboot-mode.h|  14 
>  drivers/power/reset/syscon-reboot-mode.c | 100 
>  5 files changed, 258 insertions(+)
>  create mode 100644 drivers/power/reset/reboot-mode.c
>  create mode 100644 drivers/power/reset/reboot-mode.h
>  create mode 100644 drivers/power/reset/syscon-reboot-mode.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index 9bb2622..4ceaf74 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -183,5 +183,19 @@ config POWER_RESET_ZX
>   help
> Reboot support for ZTE SoCs.
>  
> +config REBOOT_MODE
> + tristate
> +
> +config SYSCON_REBOOT_MODE
> + bool "Generic SYSCON regmap reboot mode driver"

Why not tristate?

Beside that the patch looks good.

Best regards,
Krzysztof

> + depends on OF
> + select REBOOT_MODE
> + select MFD_SYSCON
> + help
> +   Say y here will enable reboot mode driver. This will
> +   get reboot mode arguments and store it in SYSCON mapped
> +   register, then the bootloader can read it to take different
> +   action according to the mode.
> +

Re: [PATCH 7/9] mfd: tps65218: add version check to the PMIC probe

[Keerthy]

On Monday 20 June 2016 02:13 PM, Keerthy wrote:

From: Tero Kristo 

Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.


+ Lee Jones.



Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
  drivers/mfd/tps65218.c   | 9 +
  include/linux/mfd/tps65218.h | 1 +
  2 files changed, 10 insertions(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 80b9dc3..ba610ad 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -219,6 +219,7 @@ static int tps65218_probe(struct i2c_client *client,
struct tps65218 *tps;
const struct of_device_id *match;
int ret;
+   unsigned int chipid;

match = of_match_device(of_tps65218_match_table, &client->dev);
if (!match) {
@@ -250,6 +251,14 @@ static int tps65218_probe(struct i2c_client *client,
if (ret < 0)
return ret;

+   ret = tps65218_reg_read(tps, TPS65218_REG_CHIPID, &chipid);
+   if (ret) {
+   dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
+   return ret;
+   }
+
+   tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
+
ret = of_platform_populate(client->dev.of_node, NULL, NULL,
   &client->dev);
if (ret < 0)
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 7fdf532..85e464e 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -267,6 +267,7 @@ struct tps_info {
  struct tps65218 {
struct device *dev;
unsigned int id;
+   u8 rev;

struct mutex tps_lock;  /* lock guarding the data structure */
/* IRQ Data */

[PATCH 9/9] ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode

[Keerthy]

From: Tero Kristo 

Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.

Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-sk-evm.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 03e3d02..1c04e27 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -457,6 +457,9 @@
regulator-state-mem {
regulator-on-in-suspend;
};
+   regulator-state-disk {
+   regulator-off-in-suspend;
+   };
};
 
dcdc4: regulator-dcdc4 {
-- 
1.9.1

[PATCH 2/9] regulator: of: setup initial suspend state

[Keerthy]

Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.

Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
 drivers/regulator/of_regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index cd828db..4f613ec 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -163,6 +163,9 @@ static void of_get_regulation_constraints(struct 
device_node *np,
"regulator-suspend-microvolt", &pval))
suspend_state->uV = pval;
 
+   if (i == PM_SUSPEND_MEM)
+   constraints->initial_state = PM_SUSPEND_MEM;
+
of_node_put(suspend_np);
suspend_state = NULL;
suspend_np = NULL;
-- 
1.9.1

[PATCH 5/9] regulator: tps65218: force set power-up/down strobe to 3 for dcdc3

[Keerthy]

From: Tero Kristo 

The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.

Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
 drivers/regulator/tps65218-regulator.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c 
b/drivers/regulator/tps65218-regulator.c
index 8eca1eb..d1e631d 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,8 +180,12 @@ static int tps65218_pmic_set_suspend_disable(struct 
regulator_dev *dev)
if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
return -EINVAL;
 
-   if (!tps->info[rid]->strobe)
-   return -EINVAL;
+   if (!tps->info[rid]->strobe) {
+   if (rid == TPS65218_DCDC_3)
+   tps->info[rid]->strobe = 3;
+   else
+   return -EINVAL;
+   }
 
return tps65218_set_bits(tps, dev->desc->bypass_reg,
 dev->desc->bypass_mask,
-- 
1.9.1

Re: [PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

[Lee Jones]

On Sun, 19 Jun 2016, Bin Gao wrote:

> On Fri, Jun 17, 2016 at 09:01:59AM +0100, Lee Jones wrote:
> > > +static struct trip_config_map str0_trip_config[] = {
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x01,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x01,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x01,
> > > + .trip_num = 0
> > > + },
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x10,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x10,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x10,
> > > + .trip_num = 1
> > > + }
> > > +};
> > > +
> > > +static struct trip_config_map str1_trip_config[] = {
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x02,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x02,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x02,
> > > + .trip_num = 0
> > > + },
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x20,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x20,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x20,
> > > + .trip_num = 1
> > > + },
> > > +};
> > > +
> > > +static struct trip_config_map str2_trip_config[] = {
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x04,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x04,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x04,
> > > + .trip_num = 0
> > > + },
> > > + {
> > > + .irq_reg = BXTWC_THRM0IRQ,
> > > + .irq_mask = 0x40,
> > > + .irq_en = BXTWC_MTHRM0IRQ,
> > > + .irq_en_mask = 0x40,
> > > + .evt_stat = BXTWC_STHRM0IRQ,
> > > + .evt_mask = 0x40,
> > > + .trip_num = 1
> > > + },
> > > +};
> > > +
> > > +static struct trip_config_map str3_trip_config[] = {
> > > + {
> > > + .irq_reg = BXTWC_THRM2IRQ,
> > > + .irq_mask = 0x10,
> > > + .irq_en = BXTWC_MTHRM2IRQ,
> > > + .irq_en_mask = 0x10,
> > > + .evt_stat = BXTWC_STHRM2IRQ,
> > > + .evt_mask = 0x10,
> > > + .trip_num = 0
> > > + },
> > > +};
> > 
> > This looks like a register map to me.
> > 
> > Can you use the regmap framework instead?
> 
> These are platform data used by another driver(thermal driver) which
> uses regmap framework to access some of the fields of the structure(
> irq_reg, irq_en and evt_stat).

I suggest you create the regmap here and pass it to the thermal driver
instead.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 3/9] regulator: tps65218: Enable suspend configuration

[Keerthy]

From: Tero Kristo 

This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Tero Kristo 
Signed-off-by: Keerthy 
---
 drivers/regulator/tps65218-regulator.c | 72 --
 include/linux/mfd/tps65218.h   |  2 +
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c 
b/drivers/regulator/tps65218-regulator.c
index a5e5634..8eca1eb 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -31,7 +31,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
   DCDC5, DCDC6, LDO1, LS3 };
 
 #define TPS65218_REGULATOR(_name, _id, _type, _ops, _n, _vr, _vm, _er, _em, \
-   _cr, _cm, _lr, _nlr, _delay, _fuv)  \
+  _cr, _cm, _lr, _nlr, _delay, _fuv, _sr, _sm) \
{   \
.name   = _name,\
.id = _id,  \
@@ -49,7 +49,9 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
.linear_ranges  = _lr,  \
.n_linear_ranges= _nlr, \
.ramp_delay = _delay,   \
-   .fixed_uV   = _fuv  \
+   .fixed_uV   = _fuv, \
+   .bypass_reg = _sr,  \
+   .bypass_mask= _sm,  \
}   \
 
 #define TPS65218_INFO(_id, _nm, _min, _max)\
@@ -157,6 +159,36 @@ static int tps65218_pmic_disable(struct regulator_dev *dev)
   dev->desc->enable_mask, TPS65218_PROTECT_L1);
 }
 
+static int tps65218_pmic_set_suspend_enable(struct regulator_dev *dev)
+{
+   struct tps65218 *tps = rdev_get_drvdata(dev);
+   unsigned int rid = rdev_get_id(dev);
+
+   if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+   return -EINVAL;
+
+   return tps65218_clear_bits(tps, dev->desc->bypass_reg,
+  dev->desc->bypass_mask,
+  TPS65218_PROTECT_L1);
+}
+
+static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev)
+{
+   struct tps65218 *tps = rdev_get_drvdata(dev);
+   unsigned int rid = rdev_get_id(dev);
+
+   if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
+   return -EINVAL;
+
+   if (!tps->info[rid]->strobe)
+   return -EINVAL;
+
+   return tps65218_set_bits(tps, dev->desc->bypass_reg,
+dev->desc->bypass_mask,
+tps->info[rid]->strobe,
+TPS65218_PROTECT_L1);
+}
+
 /* Operations permitted on DCDC1, DCDC2 */
 static struct regulator_ops tps65218_dcdc12_ops = {
.is_enabled = regulator_is_enabled_regmap,
@@ -167,6 +199,8 @@ static struct regulator_ops tps65218_dcdc12_ops = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
+   .set_suspend_enable = tps65218_pmic_set_suspend_enable,
+   .set_suspend_disable= tps65218_pmic_set_suspend_disable,
 };
 
 /* Operations permitted on DCDC3, DCDC4 and LDO1 */
@@ -178,6 +212,8 @@ static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
.set_voltage_sel= tps65218_pmic_set_voltage_sel,
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
+   .set_suspend_enable = tps65218_pmic_set_suspend_enable,
+   .set_suspend_disable= tps65218_pmic_set_suspend_disable,
 };
 
 static const int ls3_currents[] = { 100, 200, 500, 1000 };
@@ -247,6 +283,8 @@ static struct regulator_ops tps65218_dcdc56_pmic_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = tps65218_pmic_enable,
.disable= tps65218_pmic_disable,
+   .set_suspend_enable = tps65218_pmic_set_suspend_enable,
+   .set_suspend_disable= tps65218_pmic_set_suspend_disable,
 };
 
 static const struct regulator_desc regulators[] = {
@@ -254,42 +292,47 @@ static const struct regulator_desc regulators[] = {
   tps65218_dcdc12_ops, 64, TPS65218_REG_CONTROL_DCDC1,
   TPS65218_CONTROL_DCDC1_MASK, TPS65218_REG_ENABLE1,
   TPS65218_ENABLE1_DC1_EN, 0, 0, dcdc1_dcdc2_ranges,
-  2, 4000, 0),
+  2, 4000, 0, TPS

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Alexandre & Nicolas,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年6月20日 16:04
> To: Yang, Wenyou 
> Cc: Rob Herring ; Alan Stern ;
> Greg Kroah-Hartman ; Ferre, Nicolas
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> u...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On 20/06/2016 at 03:16:35 +, Yang, Wenyou wrote :
> > > Sure, what I mean is that you can try to get the regmap for the SFR in 
> > > every
> case.
> > > Depending on whether you were able to get it, you can decide to call
> > > ohci_at91_port_suspend/resume or not (just test for sfr_regmap != NULL).
> >
> > I don't think so. The SFR includes a lot of miscellaneous functions, more 
> > than
> this one.
> >
> 
> I know but this is irrelevant to this discussion. If you need to use the SFR 
> from
> another driver you will simply get it from that other driver.
> 
> I that case, you will try to get "atmel,sama5d2-sfr". It is only present on 
> sama5d2
> so you have enough information to know whether or not you can use it to
> suspend/resume.

I understand what your meaning :).
Use "atmel,sama5d2-sfr" compatible to distinguish whether forcibly suspend USB 
port via SFR or not.

I am not sure if it is a better solution.

Nicolas, could you give your opinion?

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

[PATCH 8/9] regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

[Keerthy]

From: Tero Kristo 

Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.

Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
 drivers/regulator/tps65218-regulator.c | 8 
 include/linux/mfd/tps65218.h   | 5 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/regulator/tps65218-regulator.c 
b/drivers/regulator/tps65218-regulator.c
index d1e631d..eb0f5b1 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -180,6 +180,14 @@ static int tps65218_pmic_set_suspend_disable(struct 
regulator_dev *dev)
if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
return -EINVAL;
 
+   /*
+* Certain revisions of TPS65218 will need to have DCDC3 regulator
+* enabled always, otherwise an immediate system reboot will occur
+* during poweroff.
+*/
+   if (rid == TPS65218_DCDC_3 && tps->rev == TPS65218_REV_2_1)
+   return 0;
+
if (!tps->info[rid]->strobe) {
if (rid == TPS65218_DCDC_3)
tps->info[rid]->strobe = 3;
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 85e464e..d1db952 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -63,6 +63,11 @@
 #define TPS65218_CHIPID_CHIP_MASK  0xF8
 #define TPS65218_CHIPID_REV_MASK   0x07
 
+#define TPS65218_REV_1_0   0x0
+#define TPS65218_REV_1_1   0x1
+#define TPS65218_REV_2_0   0x2
+#define TPS65218_REV_2_1   0x3
+
 #define TPS65218_INT1_VPRG BIT(5)
 #define TPS65218_INT1_AC   BIT(4)
 #define TPS65218_INT1_PB   BIT(3)
-- 
1.9.1

Re: [PATCH v2] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel-zone mapping

[Lee Jones]

On Mon, 20 Jun 2016, Lee Jones wrote:
> On Sun, 19 Jun 2016, Bin Gao wrote:

> > On Fri, Jun 17, 2016 at 09:01:59AM +0100, Lee Jones wrote:
> > > > +static struct trip_config_map str0_trip_config[] = {
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x01,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x01,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x01,
> > > > +   .trip_num = 0
> > > > +   },
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x10,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x10,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x10,
> > > > +   .trip_num = 1
> > > > +   }
> > > > +};
> > > > +
> > > > +static struct trip_config_map str1_trip_config[] = {
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x02,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x02,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x02,
> > > > +   .trip_num = 0
> > > > +   },
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x20,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x20,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x20,
> > > > +   .trip_num = 1
> > > > +   },
> > > > +};
> > > > +
> > > > +static struct trip_config_map str2_trip_config[] = {
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x04,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x04,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x04,
> > > > +   .trip_num = 0
> > > > +   },
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM0IRQ,
> > > > +   .irq_mask = 0x40,
> > > > +   .irq_en = BXTWC_MTHRM0IRQ,
> > > > +   .irq_en_mask = 0x40,
> > > > +   .evt_stat = BXTWC_STHRM0IRQ,
> > > > +   .evt_mask = 0x40,
> > > > +   .trip_num = 1
> > > > +   },
> > > > +};
> > > > +
> > > > +static struct trip_config_map str3_trip_config[] = {
> > > > +   {
> > > > +   .irq_reg = BXTWC_THRM2IRQ,
> > > > +   .irq_mask = 0x10,
> > > > +   .irq_en = BXTWC_MTHRM2IRQ,
> > > > +   .irq_en_mask = 0x10,
> > > > +   .evt_stat = BXTWC_STHRM2IRQ,
> > > > +   .evt_mask = 0x10,
> > > > +   .trip_num = 0
> > > > +   },
> > > > +};
> > > 
> > > This looks like a register map to me.
> > > 
> > > Can you use the regmap framework instead?
> > 
> > These are platform data used by another driver(thermal driver) which
> > uses regmap framework to access some of the fields of the structure(
> > irq_reg, irq_en and evt_stat).
> 
> I suggest you create the regmap here and pass it to the thermal driver
> instead.

Better yet, why don't you just create the regmap in the thermal
driver?  There is no need (in fact, it's not even allowed) to pass
register addresses though platform data.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/9] ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode

[Keerthy]

From: Tero Kristo 

Without this, the memory will remain active during poweroff consuming
extra power.

Signed-off-by: Tero Kristo 
Signed-off-by: Dave Gerlach 
Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 7b7ccc0..a9b09b4 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -540,6 +540,9 @@
regulator-state-mem {
regulator-on-in-suspend;
};
+   regulator-state-disk {
+   regulator-off-in-suspend;
+   };
};
 
dcdc5: regulator-dcdc5 {
-- 
1.9.1

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Nicolas Boichat]

ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.

The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.

Signed-off-by: Nicolas Boichat 
---

Hi,

I tested this driver using the Mediatek HDMI controller (MT8173) upstream
of the ANX bridge chip (Phillip sent a PULL request on June 13:
git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13
).

I have 2 concerns, that I'm not sure how to address within the kernel DRM
framework:
 1. All other bridge drivers also have a connector attached to it. However, in
this case, we cannot read the monitor EDID directly, so I'm not sure what
I could put in a "get_modes" function. Instead, ANX7688 provides a I2C
passthru/repeater, so the EDID is read on the Mediatek HDMI controller side.

That leads to a somewhat strange layout, where we have:
- MTK HDMI bridge/encoder
  - MTK connector (HDMI)
  - ANX7688 bridge
- No connector

Resolution filtering works fine though, thanks to mode_fixup callback on the
bridge. It also helps that Mediatek HDMI bridge calls mode_fixup from its
connector mode_valid callback, so that invalid modes are not even presented
to userspace.

 2. In the bandwidth computation, I hard-code 8-bit per channel (bpc). bpc does
not seem to be included in the mode setting itself. We could possibly 
iterate
over connectors on the DRM device, but then, IIUC, 
connector->display_info.bpc
indicates the _maximum_ bpc supported by the monitor.

Any pointers? Thanks!

Best,

Nicolas

 drivers/gpu/drm/bridge/Kconfig|   9 ++
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/analogix-anx7688.c | 227 ++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8f7423f..0c1eb41 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -7,6 +7,15 @@ config DRM_BRIDGE
 menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
 
+config DRM_ANALOGIX_ANX7688
+   tristate "Analogix ANX7688 bridge"
+   depends on DRM
+   select DRM_KMS_HELPER
+   ---help---
+ ANX7688 is a transmitter to support DisplayPort over USB-C for
+ smartphone and tablets.
+ This driver only supports the HDMI to DP component of the chip.
+
 config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 96b13b3..d744c6c 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
 ccflags-y := -Iinclude/drm
 
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c 
b/drivers/gpu/drm/bridge/analogix-anx7688.c
new file mode 100644
index 000..2c34029
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
@@ -0,0 +1,227 @@
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register addresses */
+#define VENDOR_ID_REG 0x00
+#define DEVICE_ID_REG 0x02
+
+#define FW_VERSION_REG 0x80
+
+#define DP_BANDWIDTH_REG 0x85
+#define DP_LANE_COUNT_REG 0x86
+
+#define VENDOR_ID 0x1f29
+#define DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define MINIMUM_FW_VERSION 0x0085
+
+struct anx7688 {
+   struct drm_bridge bridge;
+   struct i2c_client *client;
+
+   bool filter;
+};
+
+static int anx7688_read(struct i2c_client *client, u8 reg, u8 *data,
+   u16 data_len)
+{
+   int ret;
+   struct i2c_msg msgs[] = {
+   {
+.addr = client->addr,
+.flags = 0,
+.len = 1,
+.buf = ®,
+},
+   {
+.addr = client->addr,
+.flags = I2C_M_RD,
+.len = data_len,
+.buf = data,
+   

Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Alexandre Belloni]

On 20/06/2016 at 08:46:02 +, Yang, Wenyou wrote :
> Hi Alexandre & Nicolas,
> 
> > -Original Message-
> > From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> > Sent: 2016年6月20日 16:04
> > To: Yang, Wenyou 
> > Cc: Rob Herring ; Alan Stern ;
> > Greg Kroah-Hartman ; Ferre, Nicolas
> > ; Pawel Moll ; Mark Brown
> > ; Ian Campbell ; Kumar
> > Gala ; linux-kernel@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > u...@vger.kernel.org
> > Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> > suspend
> > 
> > On 20/06/2016 at 03:16:35 +, Yang, Wenyou wrote :
> > > > Sure, what I mean is that you can try to get the regmap for the SFR in 
> > > > every
> > case.
> > > > Depending on whether you were able to get it, you can decide to call
> > > > ohci_at91_port_suspend/resume or not (just test for sfr_regmap != NULL).
> > >
> > > I don't think so. The SFR includes a lot of miscellaneous functions, more 
> > > than
> > this one.
> > >
> > 
> > I know but this is irrelevant to this discussion. If you need to use the 
> > SFR from
> > another driver you will simply get it from that other driver.
> > 
> > I that case, you will try to get "atmel,sama5d2-sfr". It is only present on 
> > sama5d2
> > so you have enough information to know whether or not you can use it to
> > suspend/resume.
> 
> I understand what your meaning :).
> Use "atmel,sama5d2-sfr" compatible to distinguish whether forcibly suspend 
> USB port via SFR or not.
> 
> I am not sure if it is a better solution.
> 

It is definitively superior. There is only one lookup in the device tree
instead of two because whatever happens, you will have to get the SFR
regmap and you don't need to add a compatible string for an IP that
didn't change.

> Nicolas, could you give your opinion?
> 
> > 
> > --
> > Alexandre Belloni, Free Electrons
> > Embedded Linux, Kernel and Android engineering http://free-electrons.com
> 
> 
> Best Regards,
> Wenyou Yang

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/9] regulator: Enable suspend configuration

[Keerthy]

The series adds suspend configuration for tps65218 and tps65217 PMICs.

Boot tested on am437x-sk-evm, am437x-gp-evm, am335x-bone, am335x-boneblack

Keerthy (2):
  regulator: of: setup initial suspend state
  ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6
enable during suspend

Russ Dill (1):
  regulator: tps65217: Enable suspend configuration

Tero Kristo (6):
  regulator: tps65218: Enable suspend configuration
  regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
  ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff
mode
  mfd: tps65218: add version check to the PMIC probe
  regulator: tps65218: do not disable DCDC3 during poweroff on broken
PMICs
  ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff
mode

 arch/arm/boot/dts/am437x-gp-evm.dts| 13 ++
 arch/arm/boot/dts/am437x-sk-evm.dts| 30 
 drivers/mfd/tps65218.c |  9 
 drivers/regulator/of_regulator.c   |  3 ++
 drivers/regulator/tps65217-regulator.c | 74 ++
 drivers/regulator/tps65218-regulator.c | 84 +-
 include/linux/mfd/tps65218.h   |  8 
 7 files changed, 201 insertions(+), 20 deletions(-)

-- 
1.9.1

[PATCH 1/9] regulator: tps65217: Enable suspend configuration

[Keerthy]

From: Russ Dill 

This allows platform data to specify which power rails should be on or off
during RTC only suspend. This is necessary to keep DDR state while in RTC
only suspend.

Signed-off-by: Russ Dill 
Signed-off-by: Keerthy 
---
 drivers/regulator/tps65217-regulator.c | 74 +-
 1 file changed, 65 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/tps65217-regulator.c 
b/drivers/regulator/tps65217-regulator.c
index adbe4fc..c15659c 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -28,7 +28,7 @@
 #include 
 
 #define TPS65217_REGULATOR(_name, _id, _of_match, _ops, _n, _vr, _vm, _em, \
-   _t, _lr, _nlr) \
+  _t, _lr, _nlr,  _sr, _sm)\
{   \
.name   = _name,\
.id = _id,  \
@@ -45,6 +45,8 @@
.volt_table = _t,   \
.linear_ranges  = _lr,  \
.n_linear_ranges = _nlr,\
+   .bypass_reg = _sr,  \
+   .bypass_mask= _sm,  \
}   \
 
 static const unsigned int LDO1_VSEL_table[] = {
@@ -118,6 +120,42 @@ static int tps65217_pmic_set_voltage_sel(struct 
regulator_dev *dev,
return ret;
 }
 
+struct tps65217_regulator_data {
+   int strobe;
+};
+
+static struct tps65217_regulator_data regulator_data[TPS65217_NUM_REGULATOR];
+
+static int tps65217_pmic_set_suspend_enable(struct regulator_dev *dev)
+{
+   struct tps65217 *tps = rdev_get_drvdata(dev);
+   unsigned int rid = rdev_get_id(dev);
+
+   if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
+   return -EINVAL;
+
+   return tps65217_clear_bits(tps, dev->desc->bypass_reg,
+  dev->desc->bypass_mask,
+  TPS65217_PROTECT_L1);
+}
+
+static int tps65217_pmic_set_suspend_disable(struct regulator_dev *dev)
+{
+   struct tps65217 *tps = rdev_get_drvdata(dev);
+   unsigned int rid = rdev_get_id(dev);
+
+   if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4)
+   return -EINVAL;
+
+   if (!regulator_data[rid].strobe)
+   return -EINVAL;
+
+   return tps65217_set_bits(tps, dev->desc->bypass_reg,
+dev->desc->bypass_mask,
+regulator_data[rid].strobe,
+TPS65217_PROTECT_L1);
+}
+
 /* Operations permitted on DCDCx, LDO2, LDO3 and LDO4 */
 static struct regulator_ops tps65217_pmic_ops = {
.is_enabled = regulator_is_enabled_regmap,
@@ -127,6 +165,8 @@ static struct regulator_ops tps65217_pmic_ops = {
.set_voltage_sel= tps65217_pmic_set_voltage_sel,
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
+   .set_suspend_enable = tps65217_pmic_set_suspend_enable,
+   .set_suspend_disable= tps65217_pmic_set_suspend_disable,
 };
 
 /* Operations permitted on LDO1 */
@@ -138,41 +178,50 @@ static struct regulator_ops tps65217_pmic_ldo1_ops = {
.set_voltage_sel= tps65217_pmic_set_voltage_sel,
.list_voltage   = regulator_list_voltage_table,
.map_voltage= regulator_map_voltage_ascend,
+   .set_suspend_enable = tps65217_pmic_set_suspend_enable,
+   .set_suspend_disable= tps65217_pmic_set_suspend_disable,
 };
 
 static const struct regulator_desc regulators[] = {
TPS65217_REGULATOR("DCDC1", TPS65217_DCDC_1, "dcdc1",
   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC1,
   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC1_EN,
-  NULL, tps65217_uv1_ranges, 2),
+  NULL, tps65217_uv1_ranges, 2, TPS65217_REG_SEQ1,
+  TPS65217_SEQ1_DC1_SEQ_MASK),
TPS65217_REGULATOR("DCDC2", TPS65217_DCDC_2, "dcdc2",
   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC2,
   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC2_EN,
   NULL, tps65217_uv1_ranges,
-  ARRAY_SIZE(tps65217_uv1_ranges)),
+  ARRAY_SIZE(tps65217_uv1_ranges), TPS65217_REG_SEQ1,
+  TPS65217_SEQ1_DC2_SEQ_MASK),
TPS65217_REGULATOR("DCDC3", TPS65217_DCDC_3, "dcdc3",
   tps65217_pmic_ops, 64, TPS65217_REG_DEFDCDC3,
   TPS65217_DEFDCDCX_DCDC_MASK, TPS65217_ENABLE_DC3_EN,
-  NULL, tps65217_uv1_ranges, 1),
+  NULL, tps65217_uv1_ranges, 1, TPS65217_REG_SEQ2,
+ 

Re: [PATCH] mfd: twl6040: Handle mclk used for HPPLL and optional internal clock source

[Peter Ujfalusi]

On 06/16/2016 06:16 PM, Lee Jones wrote:
> On Wed, 11 May 2016, Peter Ujfalusi wrote:
> 
>> On some boards, like omap5-uevm the MCLK is gated by default and in order
>> to be able to use the High performance modes of twl6040 it need to be
>> enabled by SW.
>> Add support for handling the MCLK source clock via CCF.
>> At the same time lover the print priority of the notification that the 32K
> 
> Mr Lover Lover!

Oh. :D

>>  twl6040->supplies[0].supply = "vio";
>> diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
>> index 8f9fc3d26e6d..a7c50e54f3e0 100644
>> --- a/include/linux/mfd/twl6040.h
>> +++ b/include/linux/mfd/twl6040.h
>> @@ -224,7 +224,8 @@ struct twl6040 {
>>  struct regmap *regmap;
>>  struct regmap_irq_chip_data *irq_data;
>>  struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
>> -struct clk *clk32k;
>> +struct clk *clk32k_clk;
>> +struct clk *mclk_clk;
>
> Not sure I get the naming here.
> 
> What's wrong with clk32k and mclk?

The struct already have mclk (unsigned int) member to store the rate of the
reference clock (32768 in case of LPPLL or the rate of the mclk clock in case
of HPPLL). I could use clk32k and mclk for the clk and rename the current mclk
to refclk_rate or something if that is better. This value is only important
for the HPPLL usage, if I restructure the driver I might be able to rename it
as mclk_rate and store only the MCLK freq there.

> 
>>  struct mutex mutex;
>>  struct mutex irq_mutex;
>>  struct mfd_cell cells[TWL6040_CELLS];
> 


-- 
Péter

Re: [PATCH] ARM: multi_v7_defconfig: Build Atmel maXTouch driver as a module

[Sjoerd Simons]

Hey,

On Tue, 2016-06-14 at 17:20 -0400, Javier Martinez Canillas wrote:
> The driver is for a trackpad device so is not needed for booting and
> makes more sense to have it as module to reduce the kernel image
> size.
> 
> It was probably enabled as built-in because module autoload was not
> working when the I2C device was registered by OF but this got fixed
> in commit b7d21058b40b ("Input: atmel_mxt_ts - add maxtouch to I2C
> table for module autoload") so it's safe to enable as a module now.
> 
> Signed-off-by: Javier Martinez Canillas 

Make sense to me,
Reviewed-by: Sjoerd Simons 
> ---
> 
>  arch/arm/configs/multi_v7_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig
> b/arch/arm/configs/multi_v7_defconfig
> index ee7c884ab5d8..c29bdd070721 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -269,7 +269,7 @@ CONFIG_MOUSE_PS2_ELANTECH=y
>  CONFIG_MOUSE_CYAPA=m
>  CONFIG_MOUSE_ELAN_I2C=y
>  CONFIG_INPUT_TOUCHSCREEN=y
> -CONFIG_TOUCHSCREEN_ATMEL_MXT=y
> +CONFIG_TOUCHSCREEN_ATMEL_MXT=m
>  CONFIG_TOUCHSCREEN_MMS114=m
>  CONFIG_TOUCHSCREEN_ST1232=m
>  CONFIG_TOUCHSCREEN_STMPE=y

-- 

Sjoerd Simons
Collabora Ltd.

Re: [PATCH v1 1/2] mm: thp: move pmd check inside ptl for freeze_page()

[Naoya Horiguchi]

On Fri, Jun 17, 2016 at 11:40:41AM +0300, Kirill A. Shutemov wrote:
> On Fri, Jun 17, 2016 at 11:30:03AM +0900, Naoya Horiguchi wrote:
> > I found a race condition triggering VM_BUG_ON() in freeze_page(), when 
> > running
> > a testcase with 3 processes:
> >   - process 1: keep writing thp,
> >   - process 2: keep clearing soft-dirty bits from virtual address of 
> > process 1
> >   - process 3: call migratepages for process 1,
> >
> > The kernel message is like this:
> > 
> >   kernel BUG at /src/linux-dev/mm/huge_memory.c:3096!
> >   invalid opcode:  [#1] SMP
> >   Modules linked in: cfg80211 rfkill crc32c_intel ppdev serio_raw pcspkr 
> > virtio_balloon virtio_console parport_pc parport pvpanic acpi_cpufreq 
> > tpm_tis tpm i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi floppy 
> > virtio_pci virtio_ring virtio
> >   CPU: 0 PID: 28863 Comm: migratepages Not tainted 4.6.0-v4.6-160602-0827-+ 
> > #2
> >   Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> >   task: 88003732 ti: 88007cdd task.ti: 88007cdd
> >   RIP: 0010:[]  [] 
> > split_huge_page_to_list+0x496/0x590
> >   RSP: 0018:88007cdd3b70  EFLAGS: 00010202
> >   RAX: 0001 RBX: 88007c7b88c0 RCX: 
> >   RDX:  RSI: 00070200 RDI: ea0003188000
> >   RBP: 88007cdd3bb8 R08: 0001 R09: 3000
> >   R10: 8800 R11: c01f R12: ea0003188000
> >   R13: ea0003188000 R14:  R15: 0480
> >   FS:  7f8ec241d740() GS:88007dc0() 
> > knlGS: CS:  0010 DS:  ES:  CR0: 
> > 80050033
> >   CR2: 7f8ec1f3ed20 CR3: 3707b000 CR4: 06f0
> >   Stack:
> >8139ef6d ea00031c6280 88011ffec000 
> >7040 7020 88007cdd3d08 8800dbbe3008
> >0480 88007cdd3c20 811dd0b1 88007cdd3d68
> >   Call Trace:
> >[] ? list_del+0xd/0x30
> >[] queue_pages_pte_range+0x4d1/0x590
> >[] __walk_page_range+0x204/0x4e0
> >[] walk_page_range+0x71/0xf0
> >[] queue_pages_range+0x75/0x90
> >[] ? queue_pages_hugetlb+0x190/0x190
> >[] ? new_node_page+0xc0/0xc0
> >[] ? change_prot_numa+0x40/0x40
> >[] migrate_to_node+0x71/0xd0
> >[] do_migrate_pages+0x1c3/0x210
> >[] SyS_migrate_pages+0x261/0x290
> >[] entry_SYSCALL_64_fastpath+0x1a/0xa4
> >   Code: e8 b0 87 fb ff 0f 0b 48 c7 c6 30 32 9f 81 e8 a2 87 fb ff 0f 0b 48 
> > c7 c6 b8 46 9f 81 e8 94 87 fb ff 0f 0b 85 c0 0f 84 3e fd ff ff <0f> 0b 85 
> > c0 0f 85 a6 00 00 00 48 8b 75 c0 4c 89 f7 41 be f0 ff
> >   RIP  [] split_huge_page_to_list+0x496/0x590
> >RSP 
> > 
> > I'm not sure of the full scenario of the reproduction, but my debug showed 
> > that
> > split_huge_pmd_address(freeze=true) returned without running main code of 
> > pmd
> > splitting because pmd_present(*pmd) was 0. If this happens, the subsequent
> > try_to_unmap() fails and returns non-zero (because page_mapcount() still > 
> > 0),
> > and finally VM_BUG_ON() fires.
> > 
> > This patch fixes it by adding a separate split_huge_pmd_address()'s variant
> > for freeze=true and checking pmd's state within ptl for that case.
> 
> Checking pmd under ptl is right thing to do, but I want to understand the
> scenario first.
> 
> Do you have code to trigger this?

Here's the testcode (maybe takes 5-10 min to trigger.)

  background_migratepages() {
local pid=$1
  
while kill -0 $pid 2> /dev/null ; do
migratepages $pid 0 1
migratepages $pid 1 0
done
  }
  
  background_clear_refs() {
local pid=$1
  
while kill -0 $pid 2> /dev/null ; do
echo 4 > /proc/$pid/clear_refs 2> /dev/null
done
  }
  
  while true ; do
$(dirname $BASH_SOURCE)/thp_alloc &
PID=$!
sleep 0.$RANDOM
background_migratepages $PID > /dev/null &
background_clear_refs $PID   > /dev/null &
sleep 0.$RANDOM
kill -9 $PID
  done


  # thp_alloc.c

  #include 
  #include 
  #include 
  
  int main(int argc, char **argv) {
size_t size = 2*1024*1024*10;
char *p = mmap((void *)0x7000UL, size, PROT_READ|PROT_WRITE,
   MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
madvise(p, size, MADV_HUGEPAGE);
while (1)
memset(p, 0, size);
  }



> > I think that this change seems to fit the comment in 
> > split_huge_pmd_address()
> > that says "Caller holds the mmap_sem write mode, so a huge pmd cannot
> > materialize from under us." We don't hold mmap_sem write if called from
> > split_huge_page(), so maybe there were some different assumptions between
> > callers (split_huge_page() and vma_adjust_trans_huge().)
> > 
> > Signed-off-by: Naoya Horiguchi 
> > ---
> >  include/linux/huge_mm.h |  8 
> >  mm/huge_memory.c| 50 
> > ++