[PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

[simran singhal]

This patch fixes the following sparse warning:
warning: cast to restricted __le16

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 51 ++---
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 984804b..82d3a70 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -372,10 +372,9 @@ static int prism2sta_mlmerequest(struct wlandevice 
*wlandev,
qualmsg->noise.status =
P80211ENUM_msgitem_status_data_ok;
 
-   qualmsg->link.data = le16_to_cpu(hw->qual.cq_curr_bss);
-   qualmsg->level.data =
-   le16_to_cpu(hw->qual.asl_curr_bss);
-   qualmsg->noise.data = le16_to_cpu(hw->qual.anl_curr_fc);
+   qualmsg->link.data = hw->qual.cq_curr_bss;
+   qualmsg->level.data = hw->qual.asl_curr_bss;
+   qualmsg->noise.data = hw->qual.anl_curr_fc;
qualmsg->txrate.data = hw->txrate;
 
break;
@@ -603,10 +602,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the nic id fields in host byte order */
-   hw->ident_nic.id = le16_to_cpu(hw->ident_nic.id);
-   hw->ident_nic.variant = le16_to_cpu(hw->ident_nic.variant);
-   hw->ident_nic.major = le16_to_cpu(hw->ident_nic.major);
-   hw->ident_nic.minor = le16_to_cpu(hw->ident_nic.minor);
+   hw->ident_nic.id = hw->ident_nic.id;
+   hw->ident_nic.variant = hw->ident_nic.variant;
+   hw->ident_nic.major = hw->ident_nic.major;
+   hw->ident_nic.minor = hw->ident_nic.minor;
 
netdev_info(wlandev->netdev, "ident: nic h/w: id=0x%02x %d.%d.%d\n",
hw->ident_nic.id, hw->ident_nic.major,
@@ -622,10 +621,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the private fw id fields in host byte order */
-   hw->ident_pri_fw.id = le16_to_cpu(hw->ident_pri_fw.id);
-   hw->ident_pri_fw.variant = le16_to_cpu(hw->ident_pri_fw.variant);
-   hw->ident_pri_fw.major = le16_to_cpu(hw->ident_pri_fw.major);
-   hw->ident_pri_fw.minor = le16_to_cpu(hw->ident_pri_fw.minor);
+   hw->ident_pri_fw.id = hw->ident_pri_fw.id;
+   hw->ident_pri_fw.variant = hw->ident_pri_fw.variant;
+   hw->ident_pri_fw.major = hw->ident_pri_fw.major;
+   hw->ident_pri_fw.minor = hw->ident_pri_fw.minor;
 
netdev_info(wlandev->netdev, "ident: pri f/w: id=0x%02x %d.%d.%d\n",
hw->ident_pri_fw.id, hw->ident_pri_fw.major,
@@ -648,10 +647,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the station fw id fields in host byte order */
-   hw->ident_sta_fw.id = le16_to_cpu(hw->ident_sta_fw.id);
-   hw->ident_sta_fw.variant = le16_to_cpu(hw->ident_sta_fw.variant);
-   hw->ident_sta_fw.major = le16_to_cpu(hw->ident_sta_fw.major);
-   hw->ident_sta_fw.minor = le16_to_cpu(hw->ident_sta_fw.minor);
+   hw->ident_sta_fw.id = hw->ident_sta_fw.id;
+   hw->ident_sta_fw.variant = hw->ident_sta_fw.variant;
+   hw->ident_sta_fw.major = hw->ident_sta_fw.major;
+   hw->ident_sta_fw.minor = hw->ident_sta_fw.minor;
 
/* strip out the 'special' variant bits */
hw->mm_mods = hw->ident_sta_fw.variant & GENMASK(15, 14);
@@ -683,11 +682,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
/* get all the Compatibility range, modem interface supplier
 * fields in byte order
 */
-   hw->cap_sup_mfi.role = le16_to_cpu(hw->cap_sup_mfi.role);
-   hw->cap_sup_mfi.id = le16_to_cpu(hw->cap_sup_mfi.id);
-   hw->cap_sup_mfi.variant = le16_to_cpu(hw->cap_sup_mfi.variant);
-   hw->cap_sup_mfi.bottom = le16_to_cpu(hw->cap_sup_mfi.bottom);
-   hw->cap_sup_mfi.top = le16_to_cpu(hw->cap_sup_mfi.top);
+   hw->cap_sup_mfi.role = hw->cap_sup_mfi.role;
+   hw->cap_sup_mfi.id = hw->cap_sup_mfi.id;
+   hw->cap_sup_mfi.variant = hw->cap_sup_mfi.variant;
+   hw->cap_sup_mfi.bottom = hw->cap_sup_mfi.bottom;
+   hw->cap_sup_mfi.top = hw->cap_sup_mfi.top;
 
netdev_info(wlandev->netdev,
"MFI:SUP:role=0x%02x:id=0x%02x:var=0x%02x:b/t=%d/%d\n",
@@ -707,11 +706,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
/* get all the Compatibility range, controller interface supplier
 * fields in byte order
 */
-   hw->cap_sup_cfi.role = le16_to_cpu(hw->cap_sup_cfi.role);
-   hw->cap_sup_cfi.id = le16_to_cpu(hw->cap_sup_cfi.id);
-   hw->cap_sup_cfi.variant = le16_to_cpu(hw->cap_sup_cfi.variant);
-   hw->cap_sup_cfi.bottom = le16_to_cpu(hw->cap_sup_cfi.bottom);
-   

[PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

[simran singhal]

This patch fixes the following sparse warning:
warning: cast to restricted __le16

Signed-off-by: simran singhal 
---
 drivers/staging/wlan-ng/prism2sta.c | 51 ++---
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index 984804b..82d3a70 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -372,10 +372,9 @@ static int prism2sta_mlmerequest(struct wlandevice 
*wlandev,
qualmsg->noise.status =
P80211ENUM_msgitem_status_data_ok;
 
-   qualmsg->link.data = le16_to_cpu(hw->qual.cq_curr_bss);
-   qualmsg->level.data =
-   le16_to_cpu(hw->qual.asl_curr_bss);
-   qualmsg->noise.data = le16_to_cpu(hw->qual.anl_curr_fc);
+   qualmsg->link.data = hw->qual.cq_curr_bss;
+   qualmsg->level.data = hw->qual.asl_curr_bss;
+   qualmsg->noise.data = hw->qual.anl_curr_fc;
qualmsg->txrate.data = hw->txrate;
 
break;
@@ -603,10 +602,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the nic id fields in host byte order */
-   hw->ident_nic.id = le16_to_cpu(hw->ident_nic.id);
-   hw->ident_nic.variant = le16_to_cpu(hw->ident_nic.variant);
-   hw->ident_nic.major = le16_to_cpu(hw->ident_nic.major);
-   hw->ident_nic.minor = le16_to_cpu(hw->ident_nic.minor);
+   hw->ident_nic.id = hw->ident_nic.id;
+   hw->ident_nic.variant = hw->ident_nic.variant;
+   hw->ident_nic.major = hw->ident_nic.major;
+   hw->ident_nic.minor = hw->ident_nic.minor;
 
netdev_info(wlandev->netdev, "ident: nic h/w: id=0x%02x %d.%d.%d\n",
hw->ident_nic.id, hw->ident_nic.major,
@@ -622,10 +621,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the private fw id fields in host byte order */
-   hw->ident_pri_fw.id = le16_to_cpu(hw->ident_pri_fw.id);
-   hw->ident_pri_fw.variant = le16_to_cpu(hw->ident_pri_fw.variant);
-   hw->ident_pri_fw.major = le16_to_cpu(hw->ident_pri_fw.major);
-   hw->ident_pri_fw.minor = le16_to_cpu(hw->ident_pri_fw.minor);
+   hw->ident_pri_fw.id = hw->ident_pri_fw.id;
+   hw->ident_pri_fw.variant = hw->ident_pri_fw.variant;
+   hw->ident_pri_fw.major = hw->ident_pri_fw.major;
+   hw->ident_pri_fw.minor = hw->ident_pri_fw.minor;
 
netdev_info(wlandev->netdev, "ident: pri f/w: id=0x%02x %d.%d.%d\n",
hw->ident_pri_fw.id, hw->ident_pri_fw.major,
@@ -648,10 +647,10 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
}
 
/* get all the station fw id fields in host byte order */
-   hw->ident_sta_fw.id = le16_to_cpu(hw->ident_sta_fw.id);
-   hw->ident_sta_fw.variant = le16_to_cpu(hw->ident_sta_fw.variant);
-   hw->ident_sta_fw.major = le16_to_cpu(hw->ident_sta_fw.major);
-   hw->ident_sta_fw.minor = le16_to_cpu(hw->ident_sta_fw.minor);
+   hw->ident_sta_fw.id = hw->ident_sta_fw.id;
+   hw->ident_sta_fw.variant = hw->ident_sta_fw.variant;
+   hw->ident_sta_fw.major = hw->ident_sta_fw.major;
+   hw->ident_sta_fw.minor = hw->ident_sta_fw.minor;
 
/* strip out the 'special' variant bits */
hw->mm_mods = hw->ident_sta_fw.variant & GENMASK(15, 14);
@@ -683,11 +682,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
/* get all the Compatibility range, modem interface supplier
 * fields in byte order
 */
-   hw->cap_sup_mfi.role = le16_to_cpu(hw->cap_sup_mfi.role);
-   hw->cap_sup_mfi.id = le16_to_cpu(hw->cap_sup_mfi.id);
-   hw->cap_sup_mfi.variant = le16_to_cpu(hw->cap_sup_mfi.variant);
-   hw->cap_sup_mfi.bottom = le16_to_cpu(hw->cap_sup_mfi.bottom);
-   hw->cap_sup_mfi.top = le16_to_cpu(hw->cap_sup_mfi.top);
+   hw->cap_sup_mfi.role = hw->cap_sup_mfi.role;
+   hw->cap_sup_mfi.id = hw->cap_sup_mfi.id;
+   hw->cap_sup_mfi.variant = hw->cap_sup_mfi.variant;
+   hw->cap_sup_mfi.bottom = hw->cap_sup_mfi.bottom;
+   hw->cap_sup_mfi.top = hw->cap_sup_mfi.top;
 
netdev_info(wlandev->netdev,
"MFI:SUP:role=0x%02x:id=0x%02x:var=0x%02x:b/t=%d/%d\n",
@@ -707,11 +706,11 @@ static int prism2sta_getcardinfo(struct wlandevice 
*wlandev)
/* get all the Compatibility range, controller interface supplier
 * fields in byte order
 */
-   hw->cap_sup_cfi.role = le16_to_cpu(hw->cap_sup_cfi.role);
-   hw->cap_sup_cfi.id = le16_to_cpu(hw->cap_sup_cfi.id);
-   hw->cap_sup_cfi.variant = le16_to_cpu(hw->cap_sup_cfi.variant);
-   hw->cap_sup_cfi.bottom = le16_to_cpu(hw->cap_sup_cfi.bottom);
-   hw->cap_sup_cfi.top = 

Re: [PATCH v4 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller

[Rob Herring]

On Wed, Mar 01, 2017 at 10:18:55PM -0300, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C24XX
> MMC/SD/SDIO controller, used as a connectivity interface with external
> MMC, SD and SDIO storage mediums.
> 
> Signed-off-by: Sergio Prado 
> ---
>  .../devicetree/bindings/mmc/samsung,s3cmci.txt | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt

Acked-by: Rob Herring 

Re: [PATCH v4 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller

[Rob Herring]

On Wed, Mar 01, 2017 at 10:18:55PM -0300, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C24XX
> MMC/SD/SDIO controller, used as a connectivity interface with external
> MMC, SD and SDIO storage mediums.
> 
> Signed-off-by: Sergio Prado 
> ---
>  .../devicetree/bindings/mmc/samsung,s3cmci.txt | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt

Acked-by: Rob Herring 

Re: mm: fault in __do_fault

[Dmitry Vyukov]

On Tue, Feb 28, 2017 at 4:42 PM, Andrea Arcangeli  wrote:
> Hello Dmitry,
>
> On Tue, Feb 28, 2017 at 03:04:53PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in __do_fault:
>> https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
>
> Can you verify this fix:


Applied the patch on bots.


> From a65381bc86d2963713b6a9c4a73cded7dd184282 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli 
> Date: Tue, 28 Feb 2017 16:36:59 +0100
> Subject: [PATCH 1/1] userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE
>
> __do_fault assumes vmf->page has been initialized and is valid if
> VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf).
>
> handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't
> return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two
> possibilities).
>
> This VM_FAULT_NOPAGE case is only invoked when signal are pending and
> it didn't matter for anonymous memory before. It only started to
> matter since shmem was introduced. hugetlbfs also takes a different
> path and doesn't exercise __do_fault.
>
> Signed-off-by: Andrea Arcangeli 
> ---
>  fs/userfaultfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index fb6d02b..de28f43 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -500,7 +500,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long 
> reason)
>  * in such case.
>  */
> down_read(>mmap_sem);
> -   ret = 0;
> +   ret = VM_FAULT_NOPAGE;
> }
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: mm: fault in __do_fault

[Dmitry Vyukov]

On Tue, Feb 28, 2017 at 4:42 PM, Andrea Arcangeli  wrote:
> Hello Dmitry,
>
> On Tue, Feb 28, 2017 at 03:04:53PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in __do_fault:
>> https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
>
> Can you verify this fix:


Applied the patch on bots.


> From a65381bc86d2963713b6a9c4a73cded7dd184282 Mon Sep 17 00:00:00 2001
> From: Andrea Arcangeli 
> Date: Tue, 28 Feb 2017 16:36:59 +0100
> Subject: [PATCH 1/1] userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE
>
> __do_fault assumes vmf->page has been initialized and is valid if
> VM_FAULT_NOPAGE is not returned by vma->vm_ops->fault(vma, vmf).
>
> handle_userfault() in turn should return VM_FAULT_NOPAGE if it doesn't
> return VM_FAULT_SIGBUS or VM_FAULT_RETRY (the other two
> possibilities).
>
> This VM_FAULT_NOPAGE case is only invoked when signal are pending and
> it didn't matter for anonymous memory before. It only started to
> matter since shmem was introduced. hugetlbfs also takes a different
> path and doesn't exercise __do_fault.
>
> Signed-off-by: Andrea Arcangeli 
> ---
>  fs/userfaultfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index fb6d02b..de28f43 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -500,7 +500,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long 
> reason)
>  * in such case.
>  */
> down_read(>mmap_sem);
> -   ret = 0;
> +   ret = VM_FAULT_NOPAGE;
> }
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

[Viresh Kumar]

On 02-03-17, 15:45, Patrick Bellasi wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index e2ed46d..739b29d 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -3653,6 +3653,7 @@ static inline unsigned long rlimit_max(unsigned int 
> limit)
>  #define SCHED_CPUFREQ_RT (1U << 0)
>  #define SCHED_CPUFREQ_DL (1U << 1)
>  #define SCHED_CPUFREQ_IOWAIT (1U << 2)
> +#define SCHED_CPUFREQ_IDLE   (1U << 3)
>  
>  #define SCHED_CPUFREQ_RT_DL  (SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
>  
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index fd46593..084a98b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -281,6 +281,12 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  
>   raw_spin_lock(_policy->update_lock);
>  
> + /* CPU is entering IDLE, reset flags without triggering an update */
> + if (flags & SCHED_CPUFREQ_IDLE) {

Will "flags == SCHED_CPUFREQ_IDLE" generate better assembly ?

> + sg_cpu->flags = 0;
> + goto done;
> + }
> +
>   sg_cpu->util = util;
>   sg_cpu->max = max;
>   sg_cpu->flags = flags;
> @@ -293,6 +299,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   sugov_update_commit(sg_policy, time, next_f);
>   }
>  
> +done:
>   raw_spin_unlock(_policy->update_lock);
>  }
>  
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 0c00172..a844c91 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -29,6 +29,10 @@ pick_next_task_idle(struct rq *rq, struct task_struct 
> *prev, struct rq_flags *rf
>   put_prev_task(rq, prev);
>   update_idle_core(rq);
>   schedstat_inc(rq->sched_goidle);
> +
> + /* kick cpufreq (see the comment in kernel/sched/sched.h). */
> + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IDLE);
> +
>   return rq->idle;
>  }
>  
> -- 
> 2.7.4

-- 
viresh

Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

[Viresh Kumar]

On 02-03-17, 15:45, Patrick Bellasi wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index e2ed46d..739b29d 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -3653,6 +3653,7 @@ static inline unsigned long rlimit_max(unsigned int 
> limit)
>  #define SCHED_CPUFREQ_RT (1U << 0)
>  #define SCHED_CPUFREQ_DL (1U << 1)
>  #define SCHED_CPUFREQ_IOWAIT (1U << 2)
> +#define SCHED_CPUFREQ_IDLE   (1U << 3)
>  
>  #define SCHED_CPUFREQ_RT_DL  (SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
>  
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index fd46593..084a98b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -281,6 +281,12 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  
>   raw_spin_lock(_policy->update_lock);
>  
> + /* CPU is entering IDLE, reset flags without triggering an update */
> + if (flags & SCHED_CPUFREQ_IDLE) {

Will "flags == SCHED_CPUFREQ_IDLE" generate better assembly ?

> + sg_cpu->flags = 0;
> + goto done;
> + }
> +
>   sg_cpu->util = util;
>   sg_cpu->max = max;
>   sg_cpu->flags = flags;
> @@ -293,6 +299,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   sugov_update_commit(sg_policy, time, next_f);
>   }
>  
> +done:
>   raw_spin_unlock(_policy->update_lock);
>  }
>  
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 0c00172..a844c91 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -29,6 +29,10 @@ pick_next_task_idle(struct rq *rq, struct task_struct 
> *prev, struct rq_flags *rf
>   put_prev_task(rq, prev);
>   update_idle_core(rq);
>   schedstat_inc(rq->sched_goidle);
> +
> + /* kick cpufreq (see the comment in kernel/sched/sched.h). */
> + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IDLE);
> +
>   return rq->idle;
>  }
>  
> -- 
> 2.7.4

-- 
viresh

[PATCH] mtd: mtdram: check offs and len in mtdram->point madram->unpoint,mtdram->write and mtdram->read

[chenwy]

We should prevent user to erasing mtd device with
an unaligned offset or length.

Signed-off-by: Chen  Wenyong 
---
 drivers/mtd/devices/mtdram.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/devices/mtdram.c b/drivers/mtd/devices/mtdram.c
index cbd8547..b0468c1 100644
--- a/drivers/mtd/devices/mtdram.c
+++ b/drivers/mtd/devices/mtdram.c
@@ -67,6 +67,8 @@ static int ram_erase(struct mtd_info *mtd, struct erase_info 
*instr)
 static int ram_point(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, void **virt, resource_size_t *phys)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
*virt = mtd->priv + from;
*retlen = len;
return 0;
@@ -74,6 +76,8 @@ static int ram_point(struct mtd_info *mtd, loff_t from, 
size_t len,
 
 static int ram_unpoint(struct mtd_info *mtd, loff_t from, size_t len)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
return 0;
 }
 
@@ -93,6 +97,8 @@ static unsigned long ram_get_unmapped_area(struct mtd_info 
*mtd,
 static int ram_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
memcpy(buf, mtd->priv + from, len);
*retlen = len;
return 0;
@@ -101,6 +107,8 @@ static int ram_read(struct mtd_info *mtd, loff_t from, 
size_t len,
 static int ram_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
 {
+   if (check_offs_len(mtd, to, len))
+   return -EINVAL;
memcpy((char *)mtd->priv + to, buf, len);
*retlen = len;
return 0;
-- 
2.9.3

[PATCH] mtd: mtdram: check offs and len in mtdram->point madram->unpoint,mtdram->write and mtdram->read

[chenwy]

We should prevent user to erasing mtd device with
an unaligned offset or length.

Signed-off-by: Chen  Wenyong 
---
 drivers/mtd/devices/mtdram.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/devices/mtdram.c b/drivers/mtd/devices/mtdram.c
index cbd8547..b0468c1 100644
--- a/drivers/mtd/devices/mtdram.c
+++ b/drivers/mtd/devices/mtdram.c
@@ -67,6 +67,8 @@ static int ram_erase(struct mtd_info *mtd, struct erase_info 
*instr)
 static int ram_point(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, void **virt, resource_size_t *phys)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
*virt = mtd->priv + from;
*retlen = len;
return 0;
@@ -74,6 +76,8 @@ static int ram_point(struct mtd_info *mtd, loff_t from, 
size_t len,
 
 static int ram_unpoint(struct mtd_info *mtd, loff_t from, size_t len)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
return 0;
 }
 
@@ -93,6 +97,8 @@ static unsigned long ram_get_unmapped_area(struct mtd_info 
*mtd,
 static int ram_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
 {
+   if (check_offs_len(mtd, from, len))
+   return -EINVAL;
memcpy(buf, mtd->priv + from, len);
*retlen = len;
return 0;
@@ -101,6 +107,8 @@ static int ram_read(struct mtd_info *mtd, loff_t from, 
size_t len,
 static int ram_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
 {
+   if (check_offs_len(mtd, to, len))
+   return -EINVAL;
memcpy((char *)mtd->priv + to, buf, len);
*retlen = len;
return 0;
-- 
2.9.3

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Heiko Stuebner]

Am Freitag, 3. März 2017, 00:21:56 CET schrieb Rob Herring:
> On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:
> > Due to the u2phy registers are separated from general grf, we need to
> > add u2phy grf node and place u2phy node in it. So this patch add u2phy
> > grf node.
> 
> Similar comment on the subject.
> 
> > Changes in v2:
> >  - add u2phy grf specification
> > 
> > Signed-off-by: Meng Dongyang 
> > ---
> > 
> >  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15
> >  +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > b/Documentation/devicetree/bindings/soc/rockchip/grf.txt index
> > 013e71a..6ac23f9 100644
> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > @@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
> > 
> >  - GRF, used for general non-secure system,
> >  - PMUGRF, used for always on system
> > 
> > +On RK3328 SoCs, the GRF is divided into three sections,
> > +except GRF and PMUGRF, add a section for USB2PHYGRF,
> > +
> > 
> >  Required Properties:
> >  
> >  - compatible: GRF should be one of the followings
> > 
> > @@ -19,6 +22,8 @@ Required Properties:
> >  - compatible: PMUGRF should be one of the followings
> >  
> > - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> > - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> > 
> > +- compatible: USB2GRF should be one of the followings
> > +   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> > 
> >  - reg: physical base address of the controller and length of memory
> >  mapped
> >  
> >region.
> > 
> > @@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs
> > 
> > compatible = "rockchip,rk3399-grf", "syscon";
> > reg = <0x0 0xff77 0x0 0x1>;
> > 
> > };
> > 
> > +
> > +Example: USB2GRF of RK3328 SoCs
> > +
> > +   usb2phy_grf: syscon@ff45 {
> > +   compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> > +"simple-mfd";
> 
> simple-mfd is not documented. Do you have child nodes?

Yes, this will have child nodes and I guess we don't really need the 
additional example, that only differs in the compatible.


> What makes this a syscon? It has non-PHY registers?

It is still a "General Register Files" block in all of the socs manual
and yes, that special area also contains registers not used by the phy driver.


Heiko

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Heiko Stuebner]

Am Freitag, 3. März 2017, 00:21:56 CET schrieb Rob Herring:
> On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:
> > Due to the u2phy registers are separated from general grf, we need to
> > add u2phy grf node and place u2phy node in it. So this patch add u2phy
> > grf node.
> 
> Similar comment on the subject.
> 
> > Changes in v2:
> >  - add u2phy grf specification
> > 
> > Signed-off-by: Meng Dongyang 
> > ---
> > 
> >  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15
> >  +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > b/Documentation/devicetree/bindings/soc/rockchip/grf.txt index
> > 013e71a..6ac23f9 100644
> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > @@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
> > 
> >  - GRF, used for general non-secure system,
> >  - PMUGRF, used for always on system
> > 
> > +On RK3328 SoCs, the GRF is divided into three sections,
> > +except GRF and PMUGRF, add a section for USB2PHYGRF,
> > +
> > 
> >  Required Properties:
> >  
> >  - compatible: GRF should be one of the followings
> > 
> > @@ -19,6 +22,8 @@ Required Properties:
> >  - compatible: PMUGRF should be one of the followings
> >  
> > - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> > - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> > 
> > +- compatible: USB2GRF should be one of the followings
> > +   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> > 
> >  - reg: physical base address of the controller and length of memory
> >  mapped
> >  
> >region.
> > 
> > @@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs
> > 
> > compatible = "rockchip,rk3399-grf", "syscon";
> > reg = <0x0 0xff77 0x0 0x1>;
> > 
> > };
> > 
> > +
> > +Example: USB2GRF of RK3328 SoCs
> > +
> > +   usb2phy_grf: syscon@ff45 {
> > +   compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> > +"simple-mfd";
> 
> simple-mfd is not documented. Do you have child nodes?

Yes, this will have child nodes and I guess we don't really need the 
additional example, that only differs in the compatible.


> What makes this a syscon? It has non-PHY registers?

It is still a "General Register Files" block in all of the socs manual
and yes, that special area also contains registers not used by the phy driver.


Heiko

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Mats Karrman]

On 2017-03-03 04:13, Guenter Roeck wrote:


On 03/02/2017 07:22 AM, Mats Karrman wrote:


Looking forward, one thing I have run into is how to connect the typec driver 
with a
driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification
includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in 
the
Attention message. These signals are needed by the DisplayPort driver to know 
when to
start negotiation etc.
Have you got any thoughts on how to standardize such interfaces?

That really depends on the lower level driver. For Chromebooks, where the Type-C
Protocol Manager runs on the EC, we have an extcon driver which reports the pin 
states
to the graphics drivers and connects to the Type-C class code using the Type-C 
class
API. I still need to update, re-test, and publish that code. The published code 
in
https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch 
chromeos-4.4,
shows how it can be done, though that code currently still uses the Android 
Type-C
infrastructure.


OK, thanks!

My system is a bit different. It's an i.MX6 SoC with the typec phy and DP 
controller connected

directly to the SoC and it's using DTB/OF.

Using extcon I would have a driver that is both typec class and extcon driver 
at the same time

since I can't share the access to the typec phy. Is this done elsewhere in the 
kernel?

I don't know much about the wcove PMIC and what alternate modes it might 
support but I

guess that driver would end up in the same place.

Do we need to further standardize attributes under (each) specific alternate 
mode to

include things such as HPD for the DP mode?

BR // Mats

Re: [PATCH 2/2] drivers: pwm: pwm-atmel: enable pwm on sama5d2

[Rob Herring]

On Tue, Feb 28, 2017 at 12:40:15PM +0200, Claudiu Beznea wrote:
> sama5d2 can use the same atmel_pwm_data as sama5d3.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  Documentation/devicetree/bindings/pwm/atmel-pwm.txt | 1 +
>  drivers/pwm/pwm-atmel.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> index 02331b9..c8c831d 100644
> --- a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> @@ -4,6 +4,7 @@ Required properties:
>- compatible: should be one of:
>  - "atmel,at91sam9rl-pwm"
>  - "atmel,sama5d3-pwm"
> +- "atmel,sama5d2-pwm"

Perhaps sama5d3 should be a fallback, then you don't need a driver 
change.

Rob

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Mats Karrman]

On 2017-03-03 04:13, Guenter Roeck wrote:


On 03/02/2017 07:22 AM, Mats Karrman wrote:


Looking forward, one thing I have run into is how to connect the typec driver 
with a
driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification
includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in 
the
Attention message. These signals are needed by the DisplayPort driver to know 
when to
start negotiation etc.
Have you got any thoughts on how to standardize such interfaces?

That really depends on the lower level driver. For Chromebooks, where the Type-C
Protocol Manager runs on the EC, we have an extcon driver which reports the pin 
states
to the graphics drivers and connects to the Type-C class code using the Type-C 
class
API. I still need to update, re-test, and publish that code. The published code 
in
https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch 
chromeos-4.4,
shows how it can be done, though that code currently still uses the Android 
Type-C
infrastructure.


OK, thanks!

My system is a bit different. It's an i.MX6 SoC with the typec phy and DP 
controller connected

directly to the SoC and it's using DTB/OF.

Using extcon I would have a driver that is both typec class and extcon driver 
at the same time

since I can't share the access to the typec phy. Is this done elsewhere in the 
kernel?

I don't know much about the wcove PMIC and what alternate modes it might 
support but I

guess that driver would end up in the same place.

Do we need to further standardize attributes under (each) specific alternate 
mode to

include things such as HPD for the DP mode?

BR // Mats

Re: [PATCH 2/2] drivers: pwm: pwm-atmel: enable pwm on sama5d2

[Rob Herring]

On Tue, Feb 28, 2017 at 12:40:15PM +0200, Claudiu Beznea wrote:
> sama5d2 can use the same atmel_pwm_data as sama5d3.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  Documentation/devicetree/bindings/pwm/atmel-pwm.txt | 1 +
>  drivers/pwm/pwm-atmel.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> index 02331b9..c8c831d 100644
> --- a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> @@ -4,6 +4,7 @@ Required properties:
>- compatible: should be one of:
>  - "atmel,at91sam9rl-pwm"
>  - "atmel,sama5d3-pwm"
> +- "atmel,sama5d2-pwm"

Perhaps sama5d3 should be a fallback, then you don't need a driver 
change.

Rob

Re: [PATCH 1/2] Documentation: dt-bindings: Use generic property for hardware enable pins

[Kim, Milo]

On 3/3/2017 3:21 PM, Rob Herring wrote:

On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:

With index usages, device specific properties can be replaced with generic
one. Vpos is index 0 and Vneg is index 1.
DT examples are added as well.

Signed-off-by: Milo Kim 
---
 .../bindings/regulator/lm363x-regulator.txt| 78 +-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
index 8f14df9d1205..cc5a6151d85f 100644
--- a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
@@ -8,8 +8,8 @@ Required property:

 Optional properties:
   LM3632 has external enable pins for two LDOs.
-  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
-  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.
+  - enable-gpios: Two GPIO specifiers for Vpos and Vneg control pins.
+  The first entry is Vpos, the second is Vneg enable pin.


You're breaking compatibility with existing DTBs. You need to explain
that and why it is okay in the commit message. In this case, I don't
think it is okay as this chip could be used across vendors' platforms.


Thanks for your comment.

The lm363x-regulator has a dependency on ti-lmu MFD driver which is not 
upstreamed. So I don't think this patch will break the compatibility 
because two properties are not used anywhere at this moment.

Please correct me if it's incorrect.

Using general DT property is simple/clear because two enable pins are 
differentiable by selecting the index number. That's the main reason of 
this patch.


Best regards,
Milo

Re: [PATCH 1/2] Documentation: dt-bindings: Use generic property for hardware enable pins

[Kim, Milo]

On 3/3/2017 3:21 PM, Rob Herring wrote:

On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:

With index usages, device specific properties can be replaced with generic
one. Vpos is index 0 and Vneg is index 1.
DT examples are added as well.

Signed-off-by: Milo Kim 
---
 .../bindings/regulator/lm363x-regulator.txt| 78 +-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
index 8f14df9d1205..cc5a6151d85f 100644
--- a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
@@ -8,8 +8,8 @@ Required property:

 Optional properties:
   LM3632 has external enable pins for two LDOs.
-  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
-  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.
+  - enable-gpios: Two GPIO specifiers for Vpos and Vneg control pins.
+  The first entry is Vpos, the second is Vneg enable pin.


You're breaking compatibility with existing DTBs. You need to explain
that and why it is okay in the commit message. In this case, I don't
think it is okay as this chip could be used across vendors' platforms.


Thanks for your comment.

The lm363x-regulator has a dependency on ti-lmu MFD driver which is not 
upstreamed. So I don't think this patch will break the compatibility 
because two properties are not used anywhere at this moment.

Please correct me if it's incorrect.

Using general DT property is simple/clear because two enable pins are 
differentiable by selecting the index number. That's the main reason of 
this patch.


Best regards,
Milo

[PATCH v7 kernel 1/5] virtio-balloon: rework deflate to add page to a list

[Wei Wang]

From: Liang Li 

When doing the inflating/deflating operation, the current virtio-balloon
implementation uses an array to save 256 PFNS, then send these PFNS to
host through virtio and process each PFN one by one. This way is not
efficient when inflating/deflating a large mount of memory because too
many times of the following operations:

1. Virtio data transmission
2. Page allocate/free
3. Address translation(GPA->HVA)
4. madvise

The over head of these operations will consume a lot of CPU cycles and
will take a long time to complete, it may impact the QoS of the guest as
well as the host. The overhead will be reduced a lot if batch processing
is used. E.g. If there are several pages whose address are physical
contiguous in the guest, these bulk pages can be processed in one
operation.

The main idea for the optimization is to reduce the above operations as
much as possible. And it can be achieved by using a {pfn|length} array
instead of a PFN array. Comparing with PFN array, {pfn|length} array can
present more pages and is fit for batch processing.

This patch saves the deflated pages to a list instead of the PFN array,
which will allow faster notifications using the {pfn|length} down the
road. balloon_pfn_to_page() can be removed because it's useless.

Signed-off-by: Liang Li 
Signed-off-by: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
Cc: Dave Hansen 
Cc: Andrea Arcangeli 
Cc: David Hildenbrand 
Cc: Liang Li 
Cc: Wei Wang 
---
 drivers/virtio/virtio_balloon.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 181793f..f59cb4f 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -103,12 +103,6 @@ static u32 page_to_balloon_pfn(struct page *page)
return pfn * VIRTIO_BALLOON_PAGES_PER_PAGE;
 }
 
-static struct page *balloon_pfn_to_page(u32 pfn)
-{
-   BUG_ON(pfn % VIRTIO_BALLOON_PAGES_PER_PAGE);
-   return pfn_to_page(pfn / VIRTIO_BALLOON_PAGES_PER_PAGE);
-}
-
 static void balloon_ack(struct virtqueue *vq)
 {
struct virtio_balloon *vb = vq->vdev->priv;
@@ -181,18 +175,16 @@ static unsigned fill_balloon(struct virtio_balloon *vb, 
size_t num)
return num_allocated_pages;
 }
 
-static void release_pages_balloon(struct virtio_balloon *vb)
+static void release_pages_balloon(struct virtio_balloon *vb,
+struct list_head *pages)
 {
-   unsigned int i;
-   struct page *page;
+   struct page *page, *next;
 
-   /* Find pfns pointing at start of each page, get pages and free them. */
-   for (i = 0; i < vb->num_pfns; i += VIRTIO_BALLOON_PAGES_PER_PAGE) {
-   page = balloon_pfn_to_page(virtio32_to_cpu(vb->vdev,
-  vb->pfns[i]));
+   list_for_each_entry_safe(page, next, pages, lru) {
if (!virtio_has_feature(vb->vdev,
VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
adjust_managed_page_count(page, 1);
+   list_del(>lru);
put_page(page); /* balloon reference */
}
 }
@@ -202,6 +194,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
unsigned num_freed_pages;
struct page *page;
struct balloon_dev_info *vb_dev_info = >vb_dev_info;
+   LIST_HEAD(pages);
 
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -215,6 +208,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
if (!page)
break;
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+   list_add(>lru, );
vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
}
 
@@ -226,7 +220,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
 */
if (vb->num_pfns != 0)
tell_host(vb, vb->deflate_vq);
-   release_pages_balloon(vb);
+   release_pages_balloon(vb, );
mutex_unlock(>balloon_lock);
return num_freed_pages;
 }
-- 
2.7.4

[PATCH v7 kernel 1/5] virtio-balloon: rework deflate to add page to a list

[Wei Wang]

From: Liang Li 

When doing the inflating/deflating operation, the current virtio-balloon
implementation uses an array to save 256 PFNS, then send these PFNS to
host through virtio and process each PFN one by one. This way is not
efficient when inflating/deflating a large mount of memory because too
many times of the following operations:

1. Virtio data transmission
2. Page allocate/free
3. Address translation(GPA->HVA)
4. madvise

The over head of these operations will consume a lot of CPU cycles and
will take a long time to complete, it may impact the QoS of the guest as
well as the host. The overhead will be reduced a lot if batch processing
is used. E.g. If there are several pages whose address are physical
contiguous in the guest, these bulk pages can be processed in one
operation.

The main idea for the optimization is to reduce the above operations as
much as possible. And it can be achieved by using a {pfn|length} array
instead of a PFN array. Comparing with PFN array, {pfn|length} array can
present more pages and is fit for batch processing.

This patch saves the deflated pages to a list instead of the PFN array,
which will allow faster notifications using the {pfn|length} down the
road. balloon_pfn_to_page() can be removed because it's useless.

Signed-off-by: Liang Li 
Signed-off-by: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
Cc: Dave Hansen 
Cc: Andrea Arcangeli 
Cc: David Hildenbrand 
Cc: Liang Li 
Cc: Wei Wang 
---
 drivers/virtio/virtio_balloon.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 181793f..f59cb4f 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -103,12 +103,6 @@ static u32 page_to_balloon_pfn(struct page *page)
return pfn * VIRTIO_BALLOON_PAGES_PER_PAGE;
 }
 
-static struct page *balloon_pfn_to_page(u32 pfn)
-{
-   BUG_ON(pfn % VIRTIO_BALLOON_PAGES_PER_PAGE);
-   return pfn_to_page(pfn / VIRTIO_BALLOON_PAGES_PER_PAGE);
-}
-
 static void balloon_ack(struct virtqueue *vq)
 {
struct virtio_balloon *vb = vq->vdev->priv;
@@ -181,18 +175,16 @@ static unsigned fill_balloon(struct virtio_balloon *vb, 
size_t num)
return num_allocated_pages;
 }
 
-static void release_pages_balloon(struct virtio_balloon *vb)
+static void release_pages_balloon(struct virtio_balloon *vb,
+struct list_head *pages)
 {
-   unsigned int i;
-   struct page *page;
+   struct page *page, *next;
 
-   /* Find pfns pointing at start of each page, get pages and free them. */
-   for (i = 0; i < vb->num_pfns; i += VIRTIO_BALLOON_PAGES_PER_PAGE) {
-   page = balloon_pfn_to_page(virtio32_to_cpu(vb->vdev,
-  vb->pfns[i]));
+   list_for_each_entry_safe(page, next, pages, lru) {
if (!virtio_has_feature(vb->vdev,
VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
adjust_managed_page_count(page, 1);
+   list_del(>lru);
put_page(page); /* balloon reference */
}
 }
@@ -202,6 +194,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
unsigned num_freed_pages;
struct page *page;
struct balloon_dev_info *vb_dev_info = >vb_dev_info;
+   LIST_HEAD(pages);
 
/* We can only do one array worth at a time. */
num = min(num, ARRAY_SIZE(vb->pfns));
@@ -215,6 +208,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
if (!page)
break;
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+   list_add(>lru, );
vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
}
 
@@ -226,7 +220,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb, 
size_t num)
 */
if (vb->num_pfns != 0)
tell_host(vb, vb->deflate_vq);
-   release_pages_balloon(vb);
+   release_pages_balloon(vb, );
mutex_unlock(>balloon_lock);
return num_freed_pages;
 }
-- 
2.7.4

Re: [PATCH V3 3/4] dt-bindings: serial: add a new compatible string for SC9860

[Rob Herring]

On Thu, Mar 02, 2017 at 02:22:09PM +0800, Chunyan Zhang wrote:
> SC9860 use the same serial device, so added a new compatible string to
> support SC9860 as well, also added an example of how to describe this
> serial device in DT.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  Documentation/devicetree/bindings/serial/sprd-uart.txt | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
> b/Documentation/devicetree/bindings/serial/sprd-uart.txt
> index 2aff0f2..8bd8144 100644
> --- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
> @@ -1,7 +1,20 @@
>  * Spreadtrum serial UART
>  
>  Required properties:
> -- compatible: must be "sprd,sc9836-uart"
> +- compatible must contain:
> +  * "sprd,sc9836-uart" for SC9836 and all Spreadtrum SoCs
> +  This also can be specific with:
> +  * "sprd,sc9860-uart" for SC9860

Just say:

- compatible: must be one of:
"sprd,sc9836-uart"
"sprd,sc9860-uart", "sprd,sc9836-uart"

> +
>  - reg: offset and length of the register set for the device
>  - interrupts: exactly one interrupt specifier
>  - clocks: phandles to input clocks.
> +
> +Example:
> + uart0: serial@7000 {
> + compatible = "sprd,sc9860-uart",
> +  "sprd,sc9836-uart";
> + reg = <0x00 0x100>;

unit address doesn't match the reg property.

> + interrupts = ;
> + clocks = <_26m>;
> + };
> -- 
> 2.7.4
> 

Re: [PATCH V3 3/4] dt-bindings: serial: add a new compatible string for SC9860

[Rob Herring]

On Thu, Mar 02, 2017 at 02:22:09PM +0800, Chunyan Zhang wrote:
> SC9860 use the same serial device, so added a new compatible string to
> support SC9860 as well, also added an example of how to describe this
> serial device in DT.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  Documentation/devicetree/bindings/serial/sprd-uart.txt | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
> b/Documentation/devicetree/bindings/serial/sprd-uart.txt
> index 2aff0f2..8bd8144 100644
> --- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
> @@ -1,7 +1,20 @@
>  * Spreadtrum serial UART
>  
>  Required properties:
> -- compatible: must be "sprd,sc9836-uart"
> +- compatible must contain:
> +  * "sprd,sc9836-uart" for SC9836 and all Spreadtrum SoCs
> +  This also can be specific with:
> +  * "sprd,sc9860-uart" for SC9860

Just say:

- compatible: must be one of:
"sprd,sc9836-uart"
"sprd,sc9860-uart", "sprd,sc9836-uart"

> +
>  - reg: offset and length of the register set for the device
>  - interrupts: exactly one interrupt specifier
>  - clocks: phandles to input clocks.
> +
> +Example:
> + uart0: serial@7000 {
> + compatible = "sprd,sc9860-uart",
> +  "sprd,sc9836-uart";
> + reg = <0x00 0x100>;

unit address doesn't match the reg property.

> + interrupts = ;
> + clocks = <_26m>;
> + };
> -- 
> 2.7.4
> 

Re: [PATCH] clk: sunxi-ng: sun5i: Fix mux width for csi clock

[Maxime Ripard]

On Thu, Mar 02, 2017 at 10:55:27PM +0200, Priit Laes wrote:
> Mux for CSI clock is 3 bits, not 2.
> 
> Signed-off-by: Priit Laes 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] clk: sunxi-ng: sun5i: Fix mux width for csi clock

[Maxime Ripard]

On Thu, Mar 02, 2017 at 10:55:27PM +0200, Priit Laes wrote:
> Mux for CSI clock is 3 bits, not 2.
> 
> Signed-off-by: Priit Laes 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 4/4] dt-bindings: List devicetree binding for the CCU of Allwinner A20

[Rob Herring]

On Mon, Feb 27, 2017 at 11:09:14PM +0200, Priit Laes wrote:
> Allwinner A20 is now driven by sunxi-ng CCU driver.
> 
> Add devicetree binding for it.
> 
> Signed-off-by: Priit Laes 
> ---
>  Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 4/4] dt-bindings: List devicetree binding for the CCU of Allwinner A20

[Rob Herring]

On Mon, Feb 27, 2017 at 11:09:14PM +0200, Priit Laes wrote:
> Allwinner A20 is now driven by sunxi-ng CCU driver.
> 
> Add devicetree binding for it.
> 
> Signed-off-by: Priit Laes 
> ---
>  Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 2/2] HID: hiddev: store hiddev's minor number when hiddev is connected

[Kim Jaejoong]

2017-03-02 23:13 GMT+09:00 Benjamin Tissoires :
> On Mar 02 2017 or thereabouts, Jaejoong Kim wrote:
>> The hid-core announces kernel message which driver is loaded if there is
>> a hiddev, but hiddev's minor number is always zero even though it's not
>> zero.
>>
>> So, we need to store the minor number asked from usb core and do some
>> refactoring work(move from hiddev.c to hiddev.h) to access hiddev in
>> hid-core.
>>
>> Signed-off-by: Jaejoong Kim 
>> ---
>>  drivers/hid/hid-core.c  |  2 +-
>>  drivers/hid/usbhid/hiddev.c | 26 +++---
>>  include/linux/hiddev.h  | 24 
>>  3 files changed, 28 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index e9e87d3..1a0b910 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -1695,7 +1695,7 @@ int hid_connect(struct hid_device *hdev, unsigned int 
>> connect_mask)
>>   len += sprintf(buf + len, "input");
>>   if (hdev->claimed & HID_CLAIMED_HIDDEV)
>>   len += sprintf(buf + len, "%shiddev%d", len ? "," : "",
>> - hdev->minor);
>> + ((struct hiddev *)hdev->hiddev)->minor);
>>   if (hdev->claimed & HID_CLAIMED_HIDRAW)
>>   len += sprintf(buf + len, "%shidraw%d", len ? "," : "",
>>   ((struct hidraw *)hdev->hidraw)->minor);
>> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
>> index 5c2c489..ef83d68 100644
>> --- a/drivers/hid/usbhid/hiddev.c
>> +++ b/drivers/hid/usbhid/hiddev.c
>> @@ -44,29 +44,6 @@
>>  #define HIDDEV_MINOR_BASE96
>>  #define HIDDEV_MINORS16
>>  #endif
>> -#define HIDDEV_BUFFER_SIZE   2048
>> -
>> -struct hiddev {
>> - int minor;
>> - int exist;
>> - int open;
>> - struct mutex existancelock;
>> - wait_queue_head_t wait;
>> - struct hid_device *hid;
>> - struct list_head list;
>> - spinlock_t list_lock;
>> -};
>> -
>> -struct hiddev_list {
>> - struct hiddev_usage_ref buffer[HIDDEV_BUFFER_SIZE];
>> - int head;
>> - int tail;
>> - unsigned flags;
>> - struct fasync_struct *fasync;
>> - struct hiddev *hiddev;
>> - struct list_head node;
>> - struct mutex thread_lock;
>> -};
>>
>>  /*
>>   * Find a report, given the report's type and ID.  The ID can be specified
>> @@ -911,6 +888,9 @@ int hiddev_connect(struct hid_device *hid, unsigned int 
>> force)
>>   kfree(hiddev);
>>   return -1;
>>   }
>> +
>> + hiddev->minor = usbhid->intf->minor;
>> +
>>   return 0;
>>  }
>>
>> diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
>> index a5dd814..ff3701b 100644
>> --- a/include/linux/hiddev.h
>> +++ b/include/linux/hiddev.h
>> @@ -32,6 +32,30 @@
>>   * In-kernel definitions.
>>   */
>>
>> +#define HIDDEV_BUFFER_SIZE  2048
>> +
>> +struct hiddev {
>> + int minor;
>> + int exist;
>> + int open;
>> + struct mutex existancelock;
>> + wait_queue_head_t wait;
>> + struct hid_device *hid;
>> + struct list_head list;
>> + spinlock_t list_lock;
>> +};
>> +
>> +struct hiddev_list {
>> + struct hiddev_usage_ref buffer[HIDDEV_BUFFER_SIZE];
>> + int head;
>> + int tail;
>> + unsigned flags;
>> + struct fasync_struct *fasync;
>> + struct hiddev *hiddev;
>> + struct list_head node;
>> + struct mutex thread_lock;
>> +};
>
> Why do you need to also export struct hiddev_list? Unless I am missing
> something we don't need it elsewhere but in hiddev.c, and so there is no
> point exporting this struct to the world.

You're right. I will export only struct hiddev.

>
> With this change amended, the end result looks good and the series
> should be ready to be integrated IMO.
>

I will resend v2 patchset your said.

Thanks,
jaejoong

> Cheers,
> Benjamin
>
>> +
>>  struct hid_device;
>>  struct hid_usage;
>>  struct hid_field;
>> --
>> 2.7.4
>>

Re: [PATCH 2/2] HID: hiddev: store hiddev's minor number when hiddev is connected

[Kim Jaejoong]

2017-03-02 23:13 GMT+09:00 Benjamin Tissoires :
> On Mar 02 2017 or thereabouts, Jaejoong Kim wrote:
>> The hid-core announces kernel message which driver is loaded if there is
>> a hiddev, but hiddev's minor number is always zero even though it's not
>> zero.
>>
>> So, we need to store the minor number asked from usb core and do some
>> refactoring work(move from hiddev.c to hiddev.h) to access hiddev in
>> hid-core.
>>
>> Signed-off-by: Jaejoong Kim 
>> ---
>>  drivers/hid/hid-core.c  |  2 +-
>>  drivers/hid/usbhid/hiddev.c | 26 +++---
>>  include/linux/hiddev.h  | 24 
>>  3 files changed, 28 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index e9e87d3..1a0b910 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -1695,7 +1695,7 @@ int hid_connect(struct hid_device *hdev, unsigned int 
>> connect_mask)
>>   len += sprintf(buf + len, "input");
>>   if (hdev->claimed & HID_CLAIMED_HIDDEV)
>>   len += sprintf(buf + len, "%shiddev%d", len ? "," : "",
>> - hdev->minor);
>> + ((struct hiddev *)hdev->hiddev)->minor);
>>   if (hdev->claimed & HID_CLAIMED_HIDRAW)
>>   len += sprintf(buf + len, "%shidraw%d", len ? "," : "",
>>   ((struct hidraw *)hdev->hidraw)->minor);
>> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
>> index 5c2c489..ef83d68 100644
>> --- a/drivers/hid/usbhid/hiddev.c
>> +++ b/drivers/hid/usbhid/hiddev.c
>> @@ -44,29 +44,6 @@
>>  #define HIDDEV_MINOR_BASE96
>>  #define HIDDEV_MINORS16
>>  #endif
>> -#define HIDDEV_BUFFER_SIZE   2048
>> -
>> -struct hiddev {
>> - int minor;
>> - int exist;
>> - int open;
>> - struct mutex existancelock;
>> - wait_queue_head_t wait;
>> - struct hid_device *hid;
>> - struct list_head list;
>> - spinlock_t list_lock;
>> -};
>> -
>> -struct hiddev_list {
>> - struct hiddev_usage_ref buffer[HIDDEV_BUFFER_SIZE];
>> - int head;
>> - int tail;
>> - unsigned flags;
>> - struct fasync_struct *fasync;
>> - struct hiddev *hiddev;
>> - struct list_head node;
>> - struct mutex thread_lock;
>> -};
>>
>>  /*
>>   * Find a report, given the report's type and ID.  The ID can be specified
>> @@ -911,6 +888,9 @@ int hiddev_connect(struct hid_device *hid, unsigned int 
>> force)
>>   kfree(hiddev);
>>   return -1;
>>   }
>> +
>> + hiddev->minor = usbhid->intf->minor;
>> +
>>   return 0;
>>  }
>>
>> diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
>> index a5dd814..ff3701b 100644
>> --- a/include/linux/hiddev.h
>> +++ b/include/linux/hiddev.h
>> @@ -32,6 +32,30 @@
>>   * In-kernel definitions.
>>   */
>>
>> +#define HIDDEV_BUFFER_SIZE  2048
>> +
>> +struct hiddev {
>> + int minor;
>> + int exist;
>> + int open;
>> + struct mutex existancelock;
>> + wait_queue_head_t wait;
>> + struct hid_device *hid;
>> + struct list_head list;
>> + spinlock_t list_lock;
>> +};
>> +
>> +struct hiddev_list {
>> + struct hiddev_usage_ref buffer[HIDDEV_BUFFER_SIZE];
>> + int head;
>> + int tail;
>> + unsigned flags;
>> + struct fasync_struct *fasync;
>> + struct hiddev *hiddev;
>> + struct list_head node;
>> + struct mutex thread_lock;
>> +};
>
> Why do you need to also export struct hiddev_list? Unless I am missing
> something we don't need it elsewhere but in hiddev.c, and so there is no
> point exporting this struct to the world.

You're right. I will export only struct hiddev.

>
> With this change amended, the end result looks good and the series
> should be ready to be integrated IMO.
>

I will resend v2 patchset your said.

Thanks,
jaejoong

> Cheers,
> Benjamin
>
>> +
>>  struct hid_device;
>>  struct hid_usage;
>>  struct hid_field;
>> --
>> 2.7.4
>>

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

[Umesh Patel]

>From the kernel source code i came to know below things.

4.1 kernel version onward 
*""nr_pages = min(sdio->pages_in_io, bio_get_nr_vecs(map_bh->b_bdev))""*
line has been removed which was considering max_sectors_kb of queue. 

Now new code is something like this* "nr_pages = min(sdio->pages_in_io,
BIO_MAX_PAGES)"*, which is sending 256 bytes of data to our device which we
are not supporting.

Please let me know is there any other place where i can register my
max_sectors_kb to kernel.



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/Kernel-bio-layer-is-sending-bio-size-more-than-our-block-device-is-capable-of-handling-tp1381843p1381844.html
Sent from the Linux Kernel mailing list archive at Nabble.com.

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

[Umesh Patel]

>From the kernel source code i came to know below things.

4.1 kernel version onward 
*""nr_pages = min(sdio->pages_in_io, bio_get_nr_vecs(map_bh->b_bdev))""*
line has been removed which was considering max_sectors_kb of queue. 

Now new code is something like this* "nr_pages = min(sdio->pages_in_io,
BIO_MAX_PAGES)"*, which is sending 256 bytes of data to our device which we
are not supporting.

Please let me know is there any other place where i can register my
max_sectors_kb to kernel.



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/Kernel-bio-layer-is-sending-bio-size-more-than-our-block-device-is-capable-of-handling-tp1381843p1381844.html
Sent from the Linux Kernel mailing list archive at Nabble.com.

Re: [PATCH v3 19/25] dt-bindings: arm: cpus: Add S500 enable-method

[Rob Herring]

On Tue, Feb 28, 2017 at 07:35:29AM +0100, Andreas Färber wrote:
> The Actions Semi S500 SoC requires a special secondary CPU boot procedure.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v3: new
>  
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v3 19/25] dt-bindings: arm: cpus: Add S500 enable-method

[Rob Herring]

On Tue, Feb 28, 2017 at 07:35:29AM +0100, Andreas Färber wrote:
> The Actions Semi S500 SoC requires a special secondary CPU boot procedure.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v3: new
>  
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

RE: [PATCH] mmc: core: fix changing bus witdh in hs400es mode

[Piotr Sroka]

Hi Shawn

Thanks for the information.

Best Regards
Piotr Sroka

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: 03 March, 2017 4:43 AM
> Subject: Re: [PATCH] mmc: core: fix changing bus witdh in hs400es mode
> 
> Hi Poitr,
> 
> On 2017/3/2 21:47, Piotr Sroka wrote:
> > Fix the code to avoid changing bus width if HS400ES mode is selected.
> >
> 
> Thanks for catching this, but Guenter posted a fix[1] already. :)
> 
> [1]: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patchwork.kernel.org_patch_9599261_=DwICbg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-
> _haXqY=TGZtNfZu5Cjhu2K8A0Qhsot4HlKpSJ0Xmyc_L8hPwSI=z53GwiPyaRw9P09VfO84zhV8cTwdYWUhcbZBPTOUbXE=vtPh-
> 0g7-O6PZJOdgFp0jZeMrve8EG6qLDpphJN1vuM=
> 
> > Signed-off-by: Piotr Sroka 
> > ---
> >  drivers/mmc/core/mmc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
> > 7fd7228..c7d9c9f 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1730,7 +1730,7 @@ static int mmc_init_card(struct mmc_host *host, u32 
> > ocr,
> > err = mmc_select_hs400(card);
> > if (err)
> > goto free_card;
> > -   } else {
> > +   } else if (!mmc_card_hs400(card)) {
> > /* Select the desired bus width optionally */
> > err = mmc_select_bus_width(card);
> > if (err > 0 && mmc_card_hs(card)) {
> >
> 
> 
> --
> Best Regards
> Shawn Lin

RE: [PATCH] mmc: core: fix changing bus witdh in hs400es mode

[Piotr Sroka]

Hi Shawn

Thanks for the information.

Best Regards
Piotr Sroka

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: 03 March, 2017 4:43 AM
> Subject: Re: [PATCH] mmc: core: fix changing bus witdh in hs400es mode
> 
> Hi Poitr,
> 
> On 2017/3/2 21:47, Piotr Sroka wrote:
> > Fix the code to avoid changing bus width if HS400ES mode is selected.
> >
> 
> Thanks for catching this, but Guenter posted a fix[1] already. :)
> 
> [1]: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__patchwork.kernel.org_patch_9599261_=DwICbg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-
> _haXqY=TGZtNfZu5Cjhu2K8A0Qhsot4HlKpSJ0Xmyc_L8hPwSI=z53GwiPyaRw9P09VfO84zhV8cTwdYWUhcbZBPTOUbXE=vtPh-
> 0g7-O6PZJOdgFp0jZeMrve8EG6qLDpphJN1vuM=
> 
> > Signed-off-by: Piotr Sroka 
> > ---
> >  drivers/mmc/core/mmc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
> > 7fd7228..c7d9c9f 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1730,7 +1730,7 @@ static int mmc_init_card(struct mmc_host *host, u32 
> > ocr,
> > err = mmc_select_hs400(card);
> > if (err)
> > goto free_card;
> > -   } else {
> > +   } else if (!mmc_card_hs400(card)) {
> > /* Select the desired bus width optionally */
> > err = mmc_select_bus_width(card);
> > if (err > 0 && mmc_card_hs(card)) {
> >
> 
> 
> --
> Best Regards
> Shawn Lin

[RFC PATCH v2 15/32] x86: Add support for changing memory encryption attribute in early boot

[Brijesh Singh]

Some KVM-specific custom MSRs shares the guest physical address with
hypervisor. When SEV is active, the shared physical address must be mapped
with encryption attribute cleared so that both hypervsior and guest can
access the data.

Add APIs to change memory encryption attribute in early boot code.

Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/mem_encrypt.h |   15 +
 arch/x86/mm/mem_encrypt.c  |   63 
 2 files changed, 78 insertions(+)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 9799835..95bbe4c 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -47,6 +47,9 @@ void __init sme_unmap_bootdata(char *real_mode_data);
 
 void __init sme_early_init(void);
 
+int __init early_set_memory_decrypted(void *addr, unsigned long size);
+int __init early_set_memory_encrypted(void *addr, unsigned long size);
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void);
 
@@ -110,6 +113,18 @@ static inline void __init sme_early_init(void)
 {
 }
 
+static inline int __init early_set_memory_decrypted(void *addr,
+   unsigned long size)
+{
+   return 1;
+}
+
+static inline int __init early_set_memory_encrypted(void *addr,
+   unsigned long size)
+{
+   return 1;
+}
+
 #define __sme_pa   __pa
 #define __sme_pa_nodebug   __pa_nodebug
 
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 7df5f4c..567e0d8 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -258,6 +259,68 @@ static void sme_free(struct device *dev, size_t size, void 
*vaddr,
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
 
+static unsigned long __init get_pte_flags(unsigned long address)
+{
+   int level;
+   pte_t *pte;
+   unsigned long flags = _KERNPG_TABLE_NOENC | _PAGE_ENC;
+
+   pte = lookup_address(address, );
+   if (!pte)
+   return flags;
+
+   switch (level) {
+   case PG_LEVEL_4K:
+   flags = pte_flags(*pte);
+   break;
+   case PG_LEVEL_2M:
+   flags = pmd_flags(*(pmd_t *)pte);
+   break;
+   case PG_LEVEL_1G:
+   flags = pud_flags(*(pud_t *)pte);
+   break;
+   default:
+   break;
+   }
+
+   return flags;
+}
+
+int __init early_set_memory_enc_dec(void *vaddr, unsigned long size,
+   unsigned long flags)
+{
+   unsigned long pfn, npages;
+   unsigned long addr = (unsigned long)vaddr & PAGE_MASK;
+
+   /* We are going to change the physical page attribute from C=1 to C=0.
+* Flush the caches to ensure that all the data with C=1 is flushed to
+* memory. Any caching of the vaddr after function returns will
+* use C=0.
+*/
+   clflush_cache_range(vaddr, size);
+
+   npages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   pfn = slow_virt_to_phys((void *)addr) >> PAGE_SHIFT;
+
+   return kernel_map_pages_in_pgd(init_mm.pgd, pfn, addr, npages,
+   flags & ~sme_me_mask);
+
+}
+
+int __init early_set_memory_decrypted(void *vaddr, unsigned long size)
+{
+   unsigned long flags = get_pte_flags((unsigned long)vaddr);
+
+   return early_set_memory_enc_dec(vaddr, size, flags & ~sme_me_mask);
+}
+
+int __init early_set_memory_encrypted(void *vaddr, unsigned long size)
+{
+   unsigned long flags = get_pte_flags((unsigned long)vaddr);
+
+   return early_set_memory_enc_dec(vaddr, size, flags | _PAGE_ENC);
+}
+
 static struct dma_map_ops sme_dma_ops = {
.alloc  = sme_alloc,
.free   = sme_free,

[RFC PATCH v2 15/32] x86: Add support for changing memory encryption attribute in early boot

[Brijesh Singh]

Some KVM-specific custom MSRs shares the guest physical address with
hypervisor. When SEV is active, the shared physical address must be mapped
with encryption attribute cleared so that both hypervsior and guest can
access the data.

Add APIs to change memory encryption attribute in early boot code.

Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/mem_encrypt.h |   15 +
 arch/x86/mm/mem_encrypt.c  |   63 
 2 files changed, 78 insertions(+)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 9799835..95bbe4c 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -47,6 +47,9 @@ void __init sme_unmap_bootdata(char *real_mode_data);
 
 void __init sme_early_init(void);
 
+int __init early_set_memory_decrypted(void *addr, unsigned long size);
+int __init early_set_memory_encrypted(void *addr, unsigned long size);
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void);
 
@@ -110,6 +113,18 @@ static inline void __init sme_early_init(void)
 {
 }
 
+static inline int __init early_set_memory_decrypted(void *addr,
+   unsigned long size)
+{
+   return 1;
+}
+
+static inline int __init early_set_memory_encrypted(void *addr,
+   unsigned long size)
+{
+   return 1;
+}
+
 #define __sme_pa   __pa
 #define __sme_pa_nodebug   __pa_nodebug
 
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 7df5f4c..567e0d8 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -258,6 +259,68 @@ static void sme_free(struct device *dev, size_t size, void 
*vaddr,
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
 
+static unsigned long __init get_pte_flags(unsigned long address)
+{
+   int level;
+   pte_t *pte;
+   unsigned long flags = _KERNPG_TABLE_NOENC | _PAGE_ENC;
+
+   pte = lookup_address(address, );
+   if (!pte)
+   return flags;
+
+   switch (level) {
+   case PG_LEVEL_4K:
+   flags = pte_flags(*pte);
+   break;
+   case PG_LEVEL_2M:
+   flags = pmd_flags(*(pmd_t *)pte);
+   break;
+   case PG_LEVEL_1G:
+   flags = pud_flags(*(pud_t *)pte);
+   break;
+   default:
+   break;
+   }
+
+   return flags;
+}
+
+int __init early_set_memory_enc_dec(void *vaddr, unsigned long size,
+   unsigned long flags)
+{
+   unsigned long pfn, npages;
+   unsigned long addr = (unsigned long)vaddr & PAGE_MASK;
+
+   /* We are going to change the physical page attribute from C=1 to C=0.
+* Flush the caches to ensure that all the data with C=1 is flushed to
+* memory. Any caching of the vaddr after function returns will
+* use C=0.
+*/
+   clflush_cache_range(vaddr, size);
+
+   npages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   pfn = slow_virt_to_phys((void *)addr) >> PAGE_SHIFT;
+
+   return kernel_map_pages_in_pgd(init_mm.pgd, pfn, addr, npages,
+   flags & ~sme_me_mask);
+
+}
+
+int __init early_set_memory_decrypted(void *vaddr, unsigned long size)
+{
+   unsigned long flags = get_pte_flags((unsigned long)vaddr);
+
+   return early_set_memory_enc_dec(vaddr, size, flags & ~sme_me_mask);
+}
+
+int __init early_set_memory_encrypted(void *vaddr, unsigned long size)
+{
+   unsigned long flags = get_pte_flags((unsigned long)vaddr);
+
+   return early_set_memory_enc_dec(vaddr, size, flags | _PAGE_ENC);
+}
+
 static struct dma_map_ops sme_dma_ops = {
.alloc  = sme_alloc,
.free   = sme_free,

[PATCH v4 4/5] perf report: Show inline stack in stdio mode

[Jin Yao]

If the address belongs to an inlined function, the source information
back to the first non-inlined function will be printed.

For example:
perf report --stdio --inline

0.69% 0.00%  inline   ld-2.23.so   [.] dl_main
   |
   ---dl_main
  |
   --0.56%--_dl_relocate_object
 |
 ---_dl_relocate_object (inline)
elf_dynamic_do_Rela (inline)

Signed-off-by: Jin Yao 
Tested-by: Milian Wolff 
---
 tools/perf/ui/stdio/hist.c | 76 +-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 668f4ae..3356bfb 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -17,6 +17,57 @@ static size_t callchain__fprintf_left_margin(FILE *fp, int 
left_margin)
return ret;
 }
 
+static size_t inline__fprintf(struct map *map, u64 ip,
+ int left_margin, FILE *fp)
+{
+   struct dso *dso;
+   struct inline_node *node;
+   struct inline_list *ilist;
+   int ret = 0, i = 0;
+
+   if (map == NULL)
+   return 0;
+
+   dso = map->dso;
+   if (dso == NULL)
+   return 0;
+
+   if (dso->kernel != DSO_TYPE_USER)
+   return 0;
+
+   node = dso__parse_addr_inlines(dso,
+  map__rip_2objdump(map, ip));
+   if (node == NULL)
+   return 0;
+
+   ret += callchain__fprintf_left_margin(fp, left_margin);
+   ret += fprintf(fp, "|\n");
+   ret += callchain__fprintf_left_margin(fp, left_margin);
+   ret += fprintf(fp, "---");
+   left_margin += 3;
+
+   list_for_each_entry(ilist, >val, list) {
+   if (ilist->filename != NULL) {
+   if (i++ > 0)
+   ret = callchain__fprintf_left_margin(fp,
+   left_margin);
+
+   if (ilist->funcname)
+   ret += fprintf(fp, "%s (inline)",
+  ilist->funcname);
+   else
+   ret += fprintf(fp, "%s:%d (inline)",
+  ilist->filename,
+  ilist->line_nr);
+
+   ret += fprintf(fp, "\n");
+   }
+   }
+
+   inline_node__delete(node);
+   return ret;
+}
+
 static size_t ipchain__fprintf_graph_line(FILE *fp, int depth, int depth_mask,
  int left_margin)
 {
@@ -78,6 +129,10 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct 
callchain_node *node,
fputs(str, fp);
fputc('\n', fp);
free(alloc_str);
+
+   if (symbol_conf.inline_name)
+   ret += inline__fprintf(chain->ms.map, chain->ip,
+  left_margin + 11, fp);
return ret;
 }
 
@@ -229,6 +284,7 @@ static size_t callchain__fprintf_graph(FILE *fp, struct 
rb_root *root,
if (!i++ && field_order == NULL &&
sort_order && !prefixcmp(sort_order, "sym"))
continue;
+
if (!printed) {
ret += callchain__fprintf_left_margin(fp, 
left_margin);
ret += fprintf(fp, "|\n");
@@ -251,6 +307,12 @@ static size_t callchain__fprintf_graph(FILE *fp, struct 
rb_root *root,
 
if (++entries_printed == callchain_param.print_limit)
break;
+
+   if (symbol_conf.inline_name)
+   ret += inline__fprintf(chain->ms.map,
+  chain->ip,
+  left_margin,
+  fp);
}
root = >rb_root;
}
@@ -529,6 +591,8 @@ static int hist_entry__fprintf(struct hist_entry *he, 
size_t size,
   bool use_callchain)
 {
int ret;
+   int callchain_ret = 0;
+   int inline_ret = 0;
struct perf_hpp hpp = {
.buf= bf,
.size   = size,
@@ -547,7 +611,17 @@ static int hist_entry__fprintf(struct hist_entry *he, 
size_t size,
ret = fprintf(fp, "%s\n", bf);
 
if (use_callchain)
-   ret += hist_entry_callchain__fprintf(he, total_period, 0, fp);
+   callchain_ret = hist_entry_callchain__fprintf(he, total_period,
+ 0, fp);
+
+   if ((callchain_ret == 0) &&
+   (symbol_conf.inline_name)) {
+   inline_ret = 

Business proposal

[Qatif Oil Group Of Companies---]

--
Dear Friend,

I would like to discuss a very important issue with you. I am writing  
to find out if this is your valid email. Please, let me know if this  
email is valid


Kind regards
Adrien Saif
Attorney to Qatif Group of Companies.

[PATCH v4 4/5] perf report: Show inline stack in stdio mode

[Jin Yao]

If the address belongs to an inlined function, the source information
back to the first non-inlined function will be printed.

For example:
perf report --stdio --inline

0.69% 0.00%  inline   ld-2.23.so   [.] dl_main
   |
   ---dl_main
  |
   --0.56%--_dl_relocate_object
 |
 ---_dl_relocate_object (inline)
elf_dynamic_do_Rela (inline)

Signed-off-by: Jin Yao 
Tested-by: Milian Wolff 
---
 tools/perf/ui/stdio/hist.c | 76 +-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 668f4ae..3356bfb 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -17,6 +17,57 @@ static size_t callchain__fprintf_left_margin(FILE *fp, int 
left_margin)
return ret;
 }
 
+static size_t inline__fprintf(struct map *map, u64 ip,
+ int left_margin, FILE *fp)
+{
+   struct dso *dso;
+   struct inline_node *node;
+   struct inline_list *ilist;
+   int ret = 0, i = 0;
+
+   if (map == NULL)
+   return 0;
+
+   dso = map->dso;
+   if (dso == NULL)
+   return 0;
+
+   if (dso->kernel != DSO_TYPE_USER)
+   return 0;
+
+   node = dso__parse_addr_inlines(dso,
+  map__rip_2objdump(map, ip));
+   if (node == NULL)
+   return 0;
+
+   ret += callchain__fprintf_left_margin(fp, left_margin);
+   ret += fprintf(fp, "|\n");
+   ret += callchain__fprintf_left_margin(fp, left_margin);
+   ret += fprintf(fp, "---");
+   left_margin += 3;
+
+   list_for_each_entry(ilist, >val, list) {
+   if (ilist->filename != NULL) {
+   if (i++ > 0)
+   ret = callchain__fprintf_left_margin(fp,
+   left_margin);
+
+   if (ilist->funcname)
+   ret += fprintf(fp, "%s (inline)",
+  ilist->funcname);
+   else
+   ret += fprintf(fp, "%s:%d (inline)",
+  ilist->filename,
+  ilist->line_nr);
+
+   ret += fprintf(fp, "\n");
+   }
+   }
+
+   inline_node__delete(node);
+   return ret;
+}
+
 static size_t ipchain__fprintf_graph_line(FILE *fp, int depth, int depth_mask,
  int left_margin)
 {
@@ -78,6 +129,10 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct 
callchain_node *node,
fputs(str, fp);
fputc('\n', fp);
free(alloc_str);
+
+   if (symbol_conf.inline_name)
+   ret += inline__fprintf(chain->ms.map, chain->ip,
+  left_margin + 11, fp);
return ret;
 }
 
@@ -229,6 +284,7 @@ static size_t callchain__fprintf_graph(FILE *fp, struct 
rb_root *root,
if (!i++ && field_order == NULL &&
sort_order && !prefixcmp(sort_order, "sym"))
continue;
+
if (!printed) {
ret += callchain__fprintf_left_margin(fp, 
left_margin);
ret += fprintf(fp, "|\n");
@@ -251,6 +307,12 @@ static size_t callchain__fprintf_graph(FILE *fp, struct 
rb_root *root,
 
if (++entries_printed == callchain_param.print_limit)
break;
+
+   if (symbol_conf.inline_name)
+   ret += inline__fprintf(chain->ms.map,
+  chain->ip,
+  left_margin,
+  fp);
}
root = >rb_root;
}
@@ -529,6 +591,8 @@ static int hist_entry__fprintf(struct hist_entry *he, 
size_t size,
   bool use_callchain)
 {
int ret;
+   int callchain_ret = 0;
+   int inline_ret = 0;
struct perf_hpp hpp = {
.buf= bf,
.size   = size,
@@ -547,7 +611,17 @@ static int hist_entry__fprintf(struct hist_entry *he, 
size_t size,
ret = fprintf(fp, "%s\n", bf);
 
if (use_callchain)
-   ret += hist_entry_callchain__fprintf(he, total_period, 0, fp);
+   callchain_ret = hist_entry_callchain__fprintf(he, total_period,
+ 0, fp);
+
+   if ((callchain_ret == 0) &&
+   (symbol_conf.inline_name)) {
+   inline_ret = inline__fprintf(he->ms.map, he->ip, 0, fp);
+   

Business proposal

[Qatif Oil Group Of Companies---]

--
Dear Friend,

I would like to discuss a very important issue with you. I am writing  
to find out if this is your valid email. Please, let me know if this  
email is valid


Kind regards
Adrien Saif
Attorney to Qatif Group of Companies.

Re: [PATCH v2 2/2] dt-bindings: extcon: Add support for cros-ec device

[Rob Herring]

On Wed, Mar 01, 2017 at 12:19:43PM +0100, Enric Balletbo i Serra wrote:
> From: Benson Leung 
> 
> This patch add documentation for binding of USB Type C cable detection
> mechanism is using EXTCON subsystem. The device can detect the presence
> of display out but it may also detect other external accessories when
> external accessories is attached or detached.
> 
> Signed-off-by: Benson Leung 
> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Chanwoo Choi 
> ---
>  - Added Reviewed-by: Chanwoo Choi 
>  Requested by Rob Herring
>  - Remove the Extcon word in the binding and replace it to describe better the
>h/w.
>  - 'google,extcon-cros-ec' renamed to 'google,extcon-usbc-cros-ec' to indicate
>this is USB Type C related.
> 
>  .../bindings/extcon/extcon-usbc-cros-ec.txt| 24 
> ++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.txt

Acked-by: Rob Herring 

Re: [PATCH v2 2/2] dt-bindings: extcon: Add support for cros-ec device

[Rob Herring]

On Wed, Mar 01, 2017 at 12:19:43PM +0100, Enric Balletbo i Serra wrote:
> From: Benson Leung 
> 
> This patch add documentation for binding of USB Type C cable detection
> mechanism is using EXTCON subsystem. The device can detect the presence
> of display out but it may also detect other external accessories when
> external accessories is attached or detached.
> 
> Signed-off-by: Benson Leung 
> Signed-off-by: Enric Balletbo i Serra 
> Reviewed-by: Chanwoo Choi 
> ---
>  - Added Reviewed-by: Chanwoo Choi 
>  Requested by Rob Herring
>  - Remove the Extcon word in the binding and replace it to describe better the
>h/w.
>  - 'google,extcon-cros-ec' renamed to 'google,extcon-usbc-cros-ec' to indicate
>this is USB Type C related.
> 
>  .../bindings/extcon/extcon-usbc-cros-ec.txt| 24 
> ++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.txt

Acked-by: Rob Herring 

[PATCH v3 0/5] coresight: enable debug module

[Leo Yan]

ARMv8 architecture reference manual (ARM DDI 0487A.k) Chapter H7 "The
Sample-based Profiling Extension" has description for sampling
registers, we can utilize these registers to check program counter
value with combined CPU exception level, secure state, etc. So this is
helpful for CPU lockup bugs, e.g. if one CPU has run into infinite loop
with IRQ disabled; the 'hang' CPU cannot switch context and handle any
interrupt, so it cannot handle SMP call for stack dump, etc.

This patch series is to enable coresight debug module with sample-based
registers and register call back notifier for PCSR register dumping
when panic happens, so we can see below dumping info for panic; and
this patch series has considered the conditions for access permission
for debug registers self, so this can avoid access debug registers when
CPU power domain is off; the driver also try to figure out the CPU is
in secure or non-secure state.

The last two patches in this series is to enable debug unit on 96boards
Hikey, the first patch is to add apb clock for debug unit and the second
patch is to add DT nodes for debug unit. As result we can below log
after input command: echo c > /proc/sysrq-trigger:

ARM external debug module:
CPU[0]:
 EDPRSR:  000b (Power:On DLK:Unlock)
 EDPCSR:  [] handle_IPI+0xe4/0x150
 EDCIDSR: 
 EDVIDSR: 9000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
CPU[1]:
 EDPRSR:  000b (Power:On DLK:Unlock)
 EDPCSR:  [] debug_notifier_call+0x108/0x288
 EDCIDSR: 
 EDVIDSR: 9000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)

[...]

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.


Leo Yan (5):
  coresight: bindings for debug module
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for debug module
  clk: hi6220: add debug APB clock
  arm64: dts: hi6220: register debug module

 .../devicetree/bindings/arm/coresight-debug.txt|  40 +++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 
 drivers/clk/hisilicon/clk-hi6220.c |   1 +
 drivers/hwtracing/coresight/Kconfig|  10 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-debug.c  | 377 +
 drivers/hwtracing/coresight/of_coresight.c |  37 +-
 include/dt-bindings/clock/hi6220-clock.h   |   5 +-
 include/linux/coresight.h  |   2 +
 9 files changed, 524 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/coresight-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

-- 
2.7.4

Re: [PATCH 1/2] HID: hiddev: move hiddev's minor number from struct hid_device to hiddev

[Kim Jaejoong]

2017-03-02 23:10 GMT+09:00 Benjamin Tissoires :
> On Mar 02 2017 or thereabouts, Jaejoong Kim wrote:
>> We need to store the minor number each drivers. In case of hidraw, it's
>> minor number stores in struct hidraw. But hiddev's minor is located in
>> struct hid_device.
>>
>> So reallocates for hiddev's minor number.
>>
>
> There is not a real need to have this one in a separate patch. Also, it
> depends on the patch "[PATCH] HID: cp2112: use proper hidraw name with
> minor number", so better include this cp2112 in this series (as I
> mentioned in the cp2112 patch).
>
> I'd say simply squash this patch with 2/2 and have the cp2112 as 1/2.

Ok. I will resend v2 patchset.

Thanks.
jaejoong

>
> Cheers,
> Benjamin
>
>> Signed-off-by: Jaejoong Kim 
>> ---
>>  drivers/hid/usbhid/hiddev.c | 1 +
>>  include/linux/hid.h | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
>> index 700145b..5c2c489 100644
>> --- a/drivers/hid/usbhid/hiddev.c
>> +++ b/drivers/hid/usbhid/hiddev.c
>> @@ -47,6 +47,7 @@
>>  #define HIDDEV_BUFFER_SIZE   2048
>>
>>  struct hiddev {
>> + int minor;
>>   int exist;
>>   int open;
>>   struct mutex existancelock;
>> diff --git a/include/linux/hid.h b/include/linux/hid.h
>> index 28f38e2b8..643c017 100644
>> --- a/include/linux/hid.h
>> +++ b/include/linux/hid.h
>> @@ -541,7 +541,6 @@ struct hid_device {  
>>  /* device report descriptor */
>>   struct list_head inputs;/* The 
>> list of inputs */
>>   void *hiddev;   /* The 
>> hiddev structure */
>>   void *hidraw;
>> - int minor;  /* 
>> Hiddev minor number */
>>
>>   int open;   /* is 
>> the device open by anyone? */
>>   char name[128]; /* 
>> Device name */
>> --
>> 2.7.4
>>

[PATCH v3 0/5] coresight: enable debug module

[Leo Yan]

ARMv8 architecture reference manual (ARM DDI 0487A.k) Chapter H7 "The
Sample-based Profiling Extension" has description for sampling
registers, we can utilize these registers to check program counter
value with combined CPU exception level, secure state, etc. So this is
helpful for CPU lockup bugs, e.g. if one CPU has run into infinite loop
with IRQ disabled; the 'hang' CPU cannot switch context and handle any
interrupt, so it cannot handle SMP call for stack dump, etc.

This patch series is to enable coresight debug module with sample-based
registers and register call back notifier for PCSR register dumping
when panic happens, so we can see below dumping info for panic; and
this patch series has considered the conditions for access permission
for debug registers self, so this can avoid access debug registers when
CPU power domain is off; the driver also try to figure out the CPU is
in secure or non-secure state.

The last two patches in this series is to enable debug unit on 96boards
Hikey, the first patch is to add apb clock for debug unit and the second
patch is to add DT nodes for debug unit. As result we can below log
after input command: echo c > /proc/sysrq-trigger:

ARM external debug module:
CPU[0]:
 EDPRSR:  000b (Power:On DLK:Unlock)
 EDPCSR:  [] handle_IPI+0xe4/0x150
 EDCIDSR: 
 EDVIDSR: 9000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
CPU[1]:
 EDPRSR:  000b (Power:On DLK:Unlock)
 EDPCSR:  [] debug_notifier_call+0x108/0x288
 EDCIDSR: 
 EDVIDSR: 9000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)

[...]

Changes from v2:
* According to Mathieu Poirier suggestion, applied some minor fixes.
* Added two extra patches for enabling debug module on Hikey.

Changes from v1:
* According to Mike Leach suggestion, removed the binding for debug
  module clocks which have been directly provided by CPU clocks.
* According to Mathieu Poirier suggestion, added function
  of_coresight_get_cpu() and some minor refactors for debug module
  driver.

Changes from RFC:
* According to Mike Leach suggestion, added check for EDPRSR to avoid
  lockup; added supporting EDVIDSR and EDCIDSR registers.
* According to Mark Rutland and Mathieu Poirier suggestion, rewrote
  the documentation for DT binding.
* According to Mark and Mathieu suggestion, refined debug driver.


Leo Yan (5):
  coresight: bindings for debug module
  coresight: refactor with function of_coresight_get_cpu
  coresight: add support for debug module
  clk: hi6220: add debug APB clock
  arm64: dts: hi6220: register debug module

 .../devicetree/bindings/arm/coresight-debug.txt|  40 +++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  64 
 drivers/clk/hisilicon/clk-hi6220.c |   1 +
 drivers/hwtracing/coresight/Kconfig|  10 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-debug.c  | 377 +
 drivers/hwtracing/coresight/of_coresight.c |  37 +-
 include/dt-bindings/clock/hi6220-clock.h   |   5 +-
 include/linux/coresight.h  |   2 +
 9 files changed, 524 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/coresight-debug.txt
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

-- 
2.7.4

Re: [PATCH 1/2] HID: hiddev: move hiddev's minor number from struct hid_device to hiddev

[Kim Jaejoong]

2017-03-02 23:10 GMT+09:00 Benjamin Tissoires :
> On Mar 02 2017 or thereabouts, Jaejoong Kim wrote:
>> We need to store the minor number each drivers. In case of hidraw, it's
>> minor number stores in struct hidraw. But hiddev's minor is located in
>> struct hid_device.
>>
>> So reallocates for hiddev's minor number.
>>
>
> There is not a real need to have this one in a separate patch. Also, it
> depends on the patch "[PATCH] HID: cp2112: use proper hidraw name with
> minor number", so better include this cp2112 in this series (as I
> mentioned in the cp2112 patch).
>
> I'd say simply squash this patch with 2/2 and have the cp2112 as 1/2.

Ok. I will resend v2 patchset.

Thanks.
jaejoong

>
> Cheers,
> Benjamin
>
>> Signed-off-by: Jaejoong Kim 
>> ---
>>  drivers/hid/usbhid/hiddev.c | 1 +
>>  include/linux/hid.h | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
>> index 700145b..5c2c489 100644
>> --- a/drivers/hid/usbhid/hiddev.c
>> +++ b/drivers/hid/usbhid/hiddev.c
>> @@ -47,6 +47,7 @@
>>  #define HIDDEV_BUFFER_SIZE   2048
>>
>>  struct hiddev {
>> + int minor;
>>   int exist;
>>   int open;
>>   struct mutex existancelock;
>> diff --git a/include/linux/hid.h b/include/linux/hid.h
>> index 28f38e2b8..643c017 100644
>> --- a/include/linux/hid.h
>> +++ b/include/linux/hid.h
>> @@ -541,7 +541,6 @@ struct hid_device {  
>>  /* device report descriptor */
>>   struct list_head inputs;/* The 
>> list of inputs */
>>   void *hiddev;   /* The 
>> hiddev structure */
>>   void *hidraw;
>> - int minor;  /* 
>> Hiddev minor number */
>>
>>   int open;   /* is 
>> the device open by anyone? */
>>   char name[128]; /* 
>> Device name */
>> --
>> 2.7.4
>>

Re: [PATCH 10/11] dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension

[Rob Herring]

On Thu, Mar 02, 2017 at 04:40:06PM +0100, Neil Armstrong wrote:
> This binding describes the Amlogic Meson specific extension to the
> Synopsys Designware HDMI Controller.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/display/amlogic,meson-dw-hdmi.txt | 111 
> +
>  1 file changed, 111 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt

Acked-by: Rob Herring 

Re: [PATCH 10/11] dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension

[Rob Herring]

On Thu, Mar 02, 2017 at 04:40:06PM +0100, Neil Armstrong wrote:
> This binding describes the Amlogic Meson specific extension to the
> Synopsys Designware HDMI Controller.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/display/amlogic,meson-dw-hdmi.txt | 111 
> +
>  1 file changed, 111 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt

Acked-by: Rob Herring 

[PATCH v3 2/5] coresight: refactor with function of_coresight_get_cpu

[Leo Yan]

This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier 
Signed-off-by: Leo Yan 
---
 drivers/hwtracing/coresight/of_coresight.c | 37 --
 include/linux/coresight.h  |  2 ++
 2 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 629e031..d9a12fb 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,14 +101,36 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(struct device_node *node)
+{
+   int cpu;
+   struct device_node *dn;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   if (dn == of_get_cpu_node(cpu, NULL)) {
+   of_node_put(dn);
+   return cpu;
+   }
+   }
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   of_node_put(dn);
+   return 0;
+}
+
 struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -175,16 +197,7 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
-   dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
-   break;
-   }
-   }
-   of_node_put(dn);
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2a5982c..7b29743 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(struct device_node *node);
 extern struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node);
 #else
+static int of_coresight_get_cpu(struct device_node *node) { return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

[PATCH v3 2/5] coresight: refactor with function of_coresight_get_cpu

[Leo Yan]

This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.

Suggested-by: Mathieu Poirier 
Signed-off-by: Leo Yan 
---
 drivers/hwtracing/coresight/of_coresight.c | 37 --
 include/linux/coresight.h  |  2 ++
 2 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 629e031..d9a12fb 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -101,14 +101,36 @@ static int of_coresight_alloc_memory(struct device *dev,
return 0;
 }
 
+int of_coresight_get_cpu(struct device_node *node)
+{
+   int cpu;
+   struct device_node *dn;
+
+   dn = of_parse_phandle(node, "cpu", 0);
+
+   /* Affinity defaults to CPU0 */
+   if (!dn)
+   return 0;
+
+   for_each_possible_cpu(cpu) {
+   if (dn == of_get_cpu_node(cpu, NULL)) {
+   of_node_put(dn);
+   return cpu;
+   }
+   }
+
+   /* Affinity to CPU0 if no cpu nodes are found */
+   of_node_put(dn);
+   return 0;
+}
+
 struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node)
 {
-   int i = 0, ret = 0, cpu;
+   int i = 0, ret = 0;
struct coresight_platform_data *pdata;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
-   struct device_node *dn;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
struct device_node *rport = NULL;
@@ -175,16 +197,7 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
} while (ep);
}
 
-   /* Affinity defaults to CPU0 */
-   pdata->cpu = 0;
-   dn = of_parse_phandle(node, "cpu", 0);
-   for (cpu = 0; dn && cpu < nr_cpu_ids; cpu++) {
-   if (dn == of_get_cpu_node(cpu, NULL)) {
-   pdata->cpu = cpu;
-   break;
-   }
-   }
-   of_node_put(dn);
+   pdata->cpu = of_coresight_get_cpu(node);
 
return pdata;
 }
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2a5982c..7b29743 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr, 
u32 offset,
 #endif
 
 #ifdef CONFIG_OF
+extern int of_coresight_get_cpu(struct device_node *node);
 extern struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node);
 #else
+static int of_coresight_get_cpu(struct device_node *node) { return 0; }
 static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node) { return NULL; }
 #endif
-- 
2.7.4

Re: [PATCH v4 3/4] fpga dt: bindings for Altera Partial Reconfiguration IP.

[Rob Herring]

On Thu, Mar 02, 2017 at 07:57:11AM -0800, matthew.gerl...@linux.intel.com wrote:
> From: Matthew Gerlach 
> 
> Device Tree bindings for Altera Partial Reconfiguration IP.
> 
> v3: s/altr,pr-ip/altr,a10-pr-ip/
> v2: s/Reconfiguraion/Reconfiguration/
> 

The version info should go after the '---'. Otherwise,

Acked-by: Rob Herring 

> 
> Signed-off-by: Matthew Gerlach 
> ---
>  Documentation/devicetree/bindings/fpga/altera-pr-ip.txt | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt 
> b/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> new file mode 100644
> index 000..52a294c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> @@ -0,0 +1,12 @@
> +Altera Arria10 Partial Reconfiguration IP
> +
> +Required properties:
> +- compatible : should contain "altr,a10-pr-ip"
> +- reg: base address and size for memory mapped io.
> +
> +Example:
> +
> + fpga_mgr: fpga-mgr@ff20c000 {
> + compatible = "altr,a10-pr-ip";
> + reg = <0xff20c000 0x10>;
> + };
> -- 
> 2.7.4
> 

Re: [PATCH v4 3/4] fpga dt: bindings for Altera Partial Reconfiguration IP.

[Rob Herring]

On Thu, Mar 02, 2017 at 07:57:11AM -0800, matthew.gerl...@linux.intel.com wrote:
> From: Matthew Gerlach 
> 
> Device Tree bindings for Altera Partial Reconfiguration IP.
> 
> v3: s/altr,pr-ip/altr,a10-pr-ip/
> v2: s/Reconfiguraion/Reconfiguration/
> 

The version info should go after the '---'. Otherwise,

Acked-by: Rob Herring 

> 
> Signed-off-by: Matthew Gerlach 
> ---
>  Documentation/devicetree/bindings/fpga/altera-pr-ip.txt | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt 
> b/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> new file mode 100644
> index 000..52a294c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-pr-ip.txt
> @@ -0,0 +1,12 @@
> +Altera Arria10 Partial Reconfiguration IP
> +
> +Required properties:
> +- compatible : should contain "altr,a10-pr-ip"
> +- reg: base address and size for memory mapped io.
> +
> +Example:
> +
> + fpga_mgr: fpga-mgr@ff20c000 {
> + compatible = "altr,a10-pr-ip";
> + reg = <0xff20c000 0x10>;
> + };
> -- 
> 2.7.4
> 

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

[Herbert Xu]

On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> ARM ODroid XU4
> 
> $ cat /proc/config.gz | gunzip | grep XTS
> CONFIG_CRYPTO_XTS=y
> 
> $ grep xts /proc/crypto
> //4.9.13
> name : xts(aes)
> driver   : xts(aes-generic)
> //4.10.1
> 
> //cbc can be found though
> 
> CRYPTTAB:
> cryptswap1 UUID= /dev/urandom
> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
> 
> FSTAB:
> /dev/mapper/cryptswap1 none swap sw 0 0
> 
> Boot Log:
> [   10.535985] [ cut here ]
> [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
> skcipher_walk_first+0x13c/0x14c
> [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> ip_tables x_tables
> [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
> [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   10.574171] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [   10.581893] [] (show_stack) from []
> (dump_stack+0x84/0x98)
> [   10.589073] [] (dump_stack) from []
> (__warn+0xe8/0x100)
> [   10.595975] [] (__warn) from []
> (warn_slowpath_null+0x20/0x28)
> [   10.603546] [] (warn_slowpath_null) from []
> (skcipher_walk_first+0x13c/0x14c)
> [   10.612390] [] (skcipher_walk_first) from []
> (skcipher_walk_virt+0x1c/0x38)
> [   10.621056] [] (skcipher_walk_virt) from []
> (post_crypt+0x38/0x1c4)
> [   10.629022] [] (post_crypt) from []
> (decrypt_done+0x4c/0x54)
> [   10.636389] [] (decrypt_done) from []
> (s5p_aes_complete+0x70/0xfc)
> [   10.644274] [] (s5p_aes_complete) from []
> (s5p_aes_interrupt+0x134/0x1a0)
> [   10.652771] [] (s5p_aes_interrupt) from []
> (__handle_irq_event_percpu+0x9c/0x124)

This looks like a bug in the s5p driver.  It's calling the completion
function straight from the IRQ handler, which is triggering the
sanity check in skcipher_walk_first.

The s5p driver needs to schedule a tasklet to call the completion
function.

Do you have crypto self-test enabled? If so it should've caught
this at run-time.  Otherwise you can disable the s5p driver until
it's fixed.

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

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

[Herbert Xu]

On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
> ARM ODroid XU4
> 
> $ cat /proc/config.gz | gunzip | grep XTS
> CONFIG_CRYPTO_XTS=y
> 
> $ grep xts /proc/crypto
> //4.9.13
> name : xts(aes)
> driver   : xts(aes-generic)
> //4.10.1
> 
> //cbc can be found though
> 
> CRYPTTAB:
> cryptswap1 UUID= /dev/urandom
> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
> 
> FSTAB:
> /dev/mapper/cryptswap1 none swap sw 0 0
> 
> Boot Log:
> [   10.535985] [ cut here ]
> [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
> skcipher_walk_first+0x13c/0x14c
> [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
> ip_tables x_tables
> [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
> [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   10.574171] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [   10.581893] [] (show_stack) from []
> (dump_stack+0x84/0x98)
> [   10.589073] [] (dump_stack) from []
> (__warn+0xe8/0x100)
> [   10.595975] [] (__warn) from []
> (warn_slowpath_null+0x20/0x28)
> [   10.603546] [] (warn_slowpath_null) from []
> (skcipher_walk_first+0x13c/0x14c)
> [   10.612390] [] (skcipher_walk_first) from []
> (skcipher_walk_virt+0x1c/0x38)
> [   10.621056] [] (skcipher_walk_virt) from []
> (post_crypt+0x38/0x1c4)
> [   10.629022] [] (post_crypt) from []
> (decrypt_done+0x4c/0x54)
> [   10.636389] [] (decrypt_done) from []
> (s5p_aes_complete+0x70/0xfc)
> [   10.644274] [] (s5p_aes_complete) from []
> (s5p_aes_interrupt+0x134/0x1a0)
> [   10.652771] [] (s5p_aes_interrupt) from []
> (__handle_irq_event_percpu+0x9c/0x124)

This looks like a bug in the s5p driver.  It's calling the completion
function straight from the IRQ handler, which is triggering the
sanity check in skcipher_walk_first.

The s5p driver needs to schedule a tasklet to call the completion
function.

Do you have crypto self-test enabled? If so it should've caught
this at run-time.  Otherwise you can disable the s5p driver until
it's fixed.

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

Re: [PATCH v2 1/3] Documentation: bindings: add assign clock property in u2phy node

[Rob Herring]

On Thu, Mar 02, 2017 at 03:49:03PM +0800, Meng Dongyang wrote:
> On some platform such as RK3328, the 480m clock may need to assign
> clock parent in dts in stead of clock driver. So this patch add
> property of assigned-clocks and assigned-clock-parents to assign
> parent for 480m clock.
> 
> Changes in v2:
>  - move u2phy grf specification to grf.txt
> 
> Signed-off-by: Meng Dongyang 
> ---
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt | 6 ++
>  1 file changed, 6 insertions(+)

If you respin, use "dt-bindings: phy: ..." for the subject.

Acked-by: Rob Herring 

Re: [PATCH v5 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

[Rob Herring]

On Thu, Mar 02, 2017 at 05:48:36AM -0500, Anurup M wrote:
> From: Tan Xiaojun 
> 
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> 
> Signed-off-by: Tan Xiaojun 
> Signed-off-by: Anurup M 
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt| 51 
> ++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt

Please add acks when posting new versions.

Rob

Re: [PATCH v2 1/3] Documentation: bindings: add assign clock property in u2phy node

[Rob Herring]

On Thu, Mar 02, 2017 at 03:49:03PM +0800, Meng Dongyang wrote:
> On some platform such as RK3328, the 480m clock may need to assign
> clock parent in dts in stead of clock driver. So this patch add
> property of assigned-clocks and assigned-clock-parents to assign
> parent for 480m clock.
> 
> Changes in v2:
>  - move u2phy grf specification to grf.txt
> 
> Signed-off-by: Meng Dongyang 
> ---
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt | 6 ++
>  1 file changed, 6 insertions(+)

If you respin, use "dt-bindings: phy: ..." for the subject.

Acked-by: Rob Herring 

Re: [PATCH v5 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

[Rob Herring]

On Thu, Mar 02, 2017 at 05:48:36AM -0500, Anurup M wrote:
> From: Tan Xiaojun 
> 
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> 
> Signed-off-by: Tan Xiaojun 
> Signed-off-by: Anurup M 
> ---
>  .../devicetree/bindings/arm/hisilicon/djtag.txt| 51 
> ++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt

Please add acks when posting new versions.

Rob

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Rob Herring]

On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:
> Due to the u2phy registers are separated from general grf, we need to
> add u2phy grf node and place u2phy node in it. So this patch add u2phy
> grf node.

Similar comment on the subject.

> 
> Changes in v2:
>  - add u2phy grf specification
> 
> Signed-off-by: Meng Dongyang 
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt 
> b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> index 013e71a..6ac23f9 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> @@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
>  - GRF, used for general non-secure system,
>  - PMUGRF, used for always on system
>  
> +On RK3328 SoCs, the GRF is divided into three sections,
> +except GRF and PMUGRF, add a section for USB2PHYGRF,
> +
>  Required Properties:
>  
>  - compatible: GRF should be one of the followings
> @@ -19,6 +22,8 @@ Required Properties:
>  - compatible: PMUGRF should be one of the followings
> - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> +- compatible: USB2GRF should be one of the followings
> +   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
>  - reg: physical base address of the controller and length of memory mapped
>region.
>  
> @@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs
>   compatible = "rockchip,rk3399-grf", "syscon";
>   reg = <0x0 0xff77 0x0 0x1>;
>   };
> +
> +Example: USB2GRF of RK3328 SoCs
> +
> + usb2phy_grf: syscon@ff45 {
> + compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> +  "simple-mfd";

simple-mfd is not documented. Do you have child nodes?

What makes this a syscon? It has non-PHY registers?


> + reg = <0x0 0xff45 0x0 0x1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> -- 
> 1.9.1
> 
> 

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Rob Herring]

On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:
> Due to the u2phy registers are separated from general grf, we need to
> add u2phy grf node and place u2phy node in it. So this patch add u2phy
> grf node.

Similar comment on the subject.

> 
> Changes in v2:
>  - add u2phy grf specification
> 
> Signed-off-by: Meng Dongyang 
> ---
>  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt 
> b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> index 013e71a..6ac23f9 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> @@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
>  - GRF, used for general non-secure system,
>  - PMUGRF, used for always on system
>  
> +On RK3328 SoCs, the GRF is divided into three sections,
> +except GRF and PMUGRF, add a section for USB2PHYGRF,
> +
>  Required Properties:
>  
>  - compatible: GRF should be one of the followings
> @@ -19,6 +22,8 @@ Required Properties:
>  - compatible: PMUGRF should be one of the followings
> - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> +- compatible: USB2GRF should be one of the followings
> +   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
>  - reg: physical base address of the controller and length of memory mapped
>region.
>  
> @@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs
>   compatible = "rockchip,rk3399-grf", "syscon";
>   reg = <0x0 0xff77 0x0 0x1>;
>   };
> +
> +Example: USB2GRF of RK3328 SoCs
> +
> + usb2phy_grf: syscon@ff45 {
> + compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> +  "simple-mfd";

simple-mfd is not documented. Do you have child nodes?

What makes this a syscon? It has non-PHY registers?


> + reg = <0x0 0xff45 0x0 0x1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> -- 
> 1.9.1
> 
> 

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[rock-chips(daniel.meng)]

On 2017/3/3 14:21, Rob Herring wrote:

On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:

Due to the u2phy registers are separated from general grf, we need to
add u2phy grf node and place u2phy node in it. So this patch add u2phy
grf node.

Similar comment on the subject.


Changes in v2:
  - add u2phy grf specification

Signed-off-by: Meng Dongyang 
---
  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt 
b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 013e71a..6ac23f9 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
  - GRF, used for general non-secure system,
  - PMUGRF, used for always on system
  
+On RK3328 SoCs, the GRF is divided into three sections,

+except GRF and PMUGRF, add a section for USB2PHYGRF,
+
  Required Properties:
  
  - compatible: GRF should be one of the followings

@@ -19,6 +22,8 @@ Required Properties:
  - compatible: PMUGRF should be one of the followings
 - "rockchip,rk3368-pmugrf", "syscon": for rk3368
 - "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: USB2GRF should be one of the followings
+   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
  - reg: physical base address of the controller and length of memory mapped
region.
  
@@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs

compatible = "rockchip,rk3399-grf", "syscon";
reg = <0x0 0xff77 0x0 0x1>;
};
+
+Example: USB2GRF of RK3328 SoCs
+
+   usb2phy_grf: syscon@ff45 {
+   compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
+"simple-mfd";

simple-mfd is not documented. Do you have child nodes?

do you mean we need to add a child node of phy here?


What makes this a syscon? It has non-PHY registers?
rk3328 devides grf into three parts and we put all u2phy registers into 
the part of u2phy grf,

so here we add a simple usb2phy_grf.




+   reg = <0x0 0xff45 0x0 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
--
1.9.1

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[rock-chips(daniel.meng)]

On 2017/3/3 14:21, Rob Herring wrote:

On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:

Due to the u2phy registers are separated from general grf, we need to
add u2phy grf node and place u2phy node in it. So this patch add u2phy
grf node.

Similar comment on the subject.


Changes in v2:
  - add u2phy grf specification

Signed-off-by: Meng Dongyang 
---
  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt 
b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 013e71a..6ac23f9 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
  - GRF, used for general non-secure system,
  - PMUGRF, used for always on system
  
+On RK3328 SoCs, the GRF is divided into three sections,

+except GRF and PMUGRF, add a section for USB2PHYGRF,
+
  Required Properties:
  
  - compatible: GRF should be one of the followings

@@ -19,6 +22,8 @@ Required Properties:
  - compatible: PMUGRF should be one of the followings
 - "rockchip,rk3368-pmugrf", "syscon": for rk3368
 - "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: USB2GRF should be one of the followings
+   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
  - reg: physical base address of the controller and length of memory mapped
region.
  
@@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs

compatible = "rockchip,rk3399-grf", "syscon";
reg = <0x0 0xff77 0x0 0x1>;
};
+
+Example: USB2GRF of RK3328 SoCs
+
+   usb2phy_grf: syscon@ff45 {
+   compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
+"simple-mfd";

simple-mfd is not documented. Do you have child nodes?

do you mean we need to add a child node of phy here?


What makes this a syscon? It has non-PHY registers?
rk3328 devides grf into three parts and we put all u2phy registers into 
the part of u2phy grf,

so here we add a simple usb2phy_grf.




+   reg = <0x0 0xff45 0x0 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
--
1.9.1

Re: [PATCH 2/2] hwmon: Aspeed AST2400/AST2500 ADC

[Rob Herring]

On Tue, Feb 28, 2017 at 07:45:23PM -0800, Guenter Roeck wrote:
> On 02/28/2017 04:49 PM, Joel Stanley wrote:
> > On Wed, Mar 1, 2017 at 6:44 AM, Rick Altherr  wrote:
> > > Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. This
> > > driver implements reading the ADC values, enabling channels via device
> > > tree, and optionally providing channel labels via device tree.  Low and
> > > high threshold interrupts are supported by the hardware but not
> > > implemented.
> > > 
> > > Signed-off-by: Rick Altherr 
> > 
> > Looks good. Some minor comments below.
> > 
> > Is there a reason you wrote a hwmon driver instead of an iio driver? I
> > wasn't sure what the recommended subsystem is.
> 
> Excellent point. Question is really if there is a plan to add support for
> thresholds. If not, an iio driver might be more appropriate.

Sigh. We have ADCs in 2 places? Fine for the kernel I guess, but not 
bindings.

Rob

Re: [PATCH 2/2] hwmon: Aspeed AST2400/AST2500 ADC

[Rob Herring]

On Tue, Feb 28, 2017 at 07:45:23PM -0800, Guenter Roeck wrote:
> On 02/28/2017 04:49 PM, Joel Stanley wrote:
> > On Wed, Mar 1, 2017 at 6:44 AM, Rick Altherr  wrote:
> > > Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. This
> > > driver implements reading the ADC values, enabling channels via device
> > > tree, and optionally providing channel labels via device tree.  Low and
> > > high threshold interrupts are supported by the hardware but not
> > > implemented.
> > > 
> > > Signed-off-by: Rick Altherr 
> > 
> > Looks good. Some minor comments below.
> > 
> > Is there a reason you wrote a hwmon driver instead of an iio driver? I
> > wasn't sure what the recommended subsystem is.
> 
> Excellent point. Question is really if there is a plan to add support for
> thresholds. If not, an iio driver might be more appropriate.

Sigh. We have ADCs in 2 places? Fine for the kernel I guess, but not 
bindings.

Rob

Re: [PATCH v3 22/25] dt-bindings: power: Add Owl SPS power domains

[Rob Herring]

On Tue, Feb 28, 2017 at 07:35:32AM +0100, Andreas Färber wrote:
> Define power domains for all non-reserved S500 power gates.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v3: new
>  
>  .../devicetree/bindings/power/actions,owl-sps.txt | 17 +
>  include/dt-bindings/power/s500-powergate.h| 19 
> +++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/actions,owl-sps.txt
>  create mode 100644 include/dt-bindings/power/s500-powergate.h

Acked-by: Rob Herring 

Re: [PATCH v3 22/25] dt-bindings: power: Add Owl SPS power domains

[Rob Herring]

On Tue, Feb 28, 2017 at 07:35:32AM +0100, Andreas Färber wrote:
> Define power domains for all non-reserved S500 power gates.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v3: new
>  
>  .../devicetree/bindings/power/actions,owl-sps.txt | 17 +
>  include/dt-bindings/power/s500-powergate.h| 19 
> +++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/actions,owl-sps.txt
>  create mode 100644 include/dt-bindings/power/s500-powergate.h

Acked-by: Rob Herring 

Re: [PATCH 1/2] Documentation: dt-bindings: Use generic property for hardware enable pins

[Rob Herring]

On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:
> With index usages, device specific properties can be replaced with generic
> one. Vpos is index 0 and Vneg is index 1.
> DT examples are added as well.
> 
> Signed-off-by: Milo Kim 
> ---
>  .../bindings/regulator/lm363x-regulator.txt| 78 
> +-
>  1 file changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> index 8f14df9d1205..cc5a6151d85f 100644
> --- a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> @@ -8,8 +8,8 @@ Required property:
>  
>  Optional properties:
>LM3632 has external enable pins for two LDOs.
> -  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
> -  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.
> +  - enable-gpios: Two GPIO specifiers for Vpos and Vneg control pins.
> +  The first entry is Vpos, the second is Vneg enable pin.

You're breaking compatibility with existing DTBs. You need to explain 
that and why it is okay in the commit message. In this case, I don't 
think it is okay as this chip could be used across vendors' platforms.

Rob

Re: [PATCH 1/2] Documentation: dt-bindings: Use generic property for hardware enable pins

[Rob Herring]

On Tue, Feb 28, 2017 at 04:50:40PM +0900, Milo Kim wrote:
> With index usages, device specific properties can be replaced with generic
> one. Vpos is index 0 and Vneg is index 1.
> DT examples are added as well.
> 
> Signed-off-by: Milo Kim 
> ---
>  .../bindings/regulator/lm363x-regulator.txt| 78 
> +-
>  1 file changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> index 8f14df9d1205..cc5a6151d85f 100644
> --- a/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> @@ -8,8 +8,8 @@ Required property:
>  
>  Optional properties:
>LM3632 has external enable pins for two LDOs.
> -  - ti,lcm-en1-gpio: A GPIO specifier for Vpos control pin.
> -  - ti,lcm-en2-gpio: A GPIO specifier for Vneg control pin.
> +  - enable-gpios: Two GPIO specifiers for Vpos and Vneg control pins.
> +  The first entry is Vpos, the second is Vneg enable pin.

You're breaking compatibility with existing DTBs. You need to explain 
that and why it is okay in the commit message. In this case, I don't 
think it is okay as this chip could be used across vendors' platforms.

Rob

Re: [PATCH V2 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

[Rob Herring]

On Tue, Feb 28, 2017 at 03:28:10PM +0100, Peter Senna Tschudin wrote:
> Devicetree binding documentation for the second video output
> of the GE B850v3:
>STDP4028-ge-b850v3-fw bridges (LVDS-DP)
>STDP2690-ge-b850v3-fw bridges (DP-DP++)
> 
> Added entry for MegaChips at:
>  Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> Cc: Laurent Pinchart 
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>  - New subject
>  - Moved binding documentation from bindings/video/ to 
> bindings/display/bridge/
>  - Reworded to describe hardware instead of the driver
>  - Reformated the bindings to have one set of required properties per device
>  - Updated reg description
>  - Defined number of ports and what they are for
> 
>  .../bridge/megachips-stdp-ge-b850v3-fw.txt | 94 
> ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  2 files changed, 95 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt

Acked-by: Rob Herring 

Re: [PATCH V2 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

[Rob Herring]

On Tue, Feb 28, 2017 at 03:28:10PM +0100, Peter Senna Tschudin wrote:
> Devicetree binding documentation for the second video output
> of the GE B850v3:
>STDP4028-ge-b850v3-fw bridges (LVDS-DP)
>STDP2690-ge-b850v3-fw bridges (DP-DP++)
> 
> Added entry for MegaChips at:
>  Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> Cc: Laurent Pinchart 
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>  - New subject
>  - Moved binding documentation from bindings/video/ to 
> bindings/display/bridge/
>  - Reworded to describe hardware instead of the driver
>  - Reformated the bindings to have one set of required properties per device
>  - Updated reg description
>  - Defined number of ports and what they are for
> 
>  .../bridge/megachips-stdp-ge-b850v3-fw.txt | 94 
> ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  2 files changed, 95 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt

Acked-by: Rob Herring 

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

On Thu, 2017-03-02 at 12:07 +0100, Neil Armstrong wrote:
> Hi Stephen,
> 
> On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> > On 03/01, Neil Armstrong wrote:
> > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> > > index a52063f..31f6090 100644
> > > --- a/drivers/clk/meson/gxbb.c
> > > +++ b/drivers/clk/meson/gxbb.c
> > > @@ -634,6 +634,131 @@
> > >   },
> > >  };
> > >  
> > > +/*
> > > + * The MALI IP is clocked by two identical clocks (mali_0 and
> > > mali_1)
> > > + * muxed by a glitch-free switch.
> > > + */
> > > +
> > > +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> > > +const char *gxbb_mali_0_1_parent_names[] = {
> > 
> > static?
> 
> Will do !
> 
> > 
> > > + "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> > > + "fclk_div4", "fclk_div3", "fclk_div5"
> > > +};
> > > +
> > 
> > [..]
> > > + .reg = (void *)HHI_MALI_CLK_CNTL,
> > > + .bit_idx = 24,
> > > + .lock = _lock,
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "mali_1",
> > > + .ops = _gate_ops,
> > > + .parent_names = (const char *[]){ "mali_1_div"
> > > },
> > > + .num_parents = 1,
> > > + .flags = (CLK_SET_RATE_PARENT |
> > > CLK_IGNORE_UNUSED),
> > > + },
> > > +};
> > > +
> > > +static u32 mux_table_mali[] = {0, 1};
> > > +const char *gxbb_mali_parent_names[] = {
> > 
> > static?
> > 
> > > + "mali_0", "mali_1"
> > > +};
> > 
> > [...]
> > >  static struct clk_mux *gxbb_clk_muxes[] = {
> > >   _mpeg_clk_sel,
> > >   _sar_adc_clk_sel,
> > > + _mali_0_sel,
> > > + _mali_1_sel,
> > > + _mali,
> > >  };
> > >  
> > >  static struct clk_divider *gxbb_clk_dividers[] = {
> > 
> > Can these arrays be const? If so, please do that in a separate
> > patch.
> 
> Hmm, these were introduced by jerome, he should update them
> accordingly.
> 

Will do

> > >   _mpeg_clk_div,
> > >   _sar_adc_clk_div,
> > > + _mali_0_div,
> > > + _mali_1_div,
> > >  };
> 
> 
> Thanks,
> Neil

Re: [PATCH v2] video: fbdev: imxfb: support AUS mode

[Rob Herring]

On Tue, Feb 28, 2017 at 09:04:16PM +0100, Martin Kaiser wrote:
> Some displays require setting AUS mode in the LDCD AUS Mode Control
> Register to work with the imxfb driver. Like the value of the Panel
> Configuration Register, the AUS Mode Control Register's value depends on
> the display mode.
> 
> Allow setting this register from the device tree. Make the device tree
> node optional to keep the DT ABI stable. This register is available only
> on imx21 and compatible chipsets. Update the device tree bindings with
> this info.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>   re-sending DT bindings and code changes as one patch

The opposite is what is prefered.

> 
>  .../devicetree/bindings/display/imx/fsl,imx-fb.txt|  2 ++
>  drivers/video/fbdev/imxfb.c   | 19 
> +++
>  include/linux/platform_data/video-imxfb.h |  1 +
>  3 files changed, 22 insertions(+)

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

On Thu, 2017-03-02 at 12:07 +0100, Neil Armstrong wrote:
> Hi Stephen,
> 
> On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> > On 03/01, Neil Armstrong wrote:
> > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> > > index a52063f..31f6090 100644
> > > --- a/drivers/clk/meson/gxbb.c
> > > +++ b/drivers/clk/meson/gxbb.c
> > > @@ -634,6 +634,131 @@
> > >   },
> > >  };
> > >  
> > > +/*
> > > + * The MALI IP is clocked by two identical clocks (mali_0 and
> > > mali_1)
> > > + * muxed by a glitch-free switch.
> > > + */
> > > +
> > > +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> > > +const char *gxbb_mali_0_1_parent_names[] = {
> > 
> > static?
> 
> Will do !
> 
> > 
> > > + "xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> > > + "fclk_div4", "fclk_div3", "fclk_div5"
> > > +};
> > > +
> > 
> > [..]
> > > + .reg = (void *)HHI_MALI_CLK_CNTL,
> > > + .bit_idx = 24,
> > > + .lock = _lock,
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "mali_1",
> > > + .ops = _gate_ops,
> > > + .parent_names = (const char *[]){ "mali_1_div"
> > > },
> > > + .num_parents = 1,
> > > + .flags = (CLK_SET_RATE_PARENT |
> > > CLK_IGNORE_UNUSED),
> > > + },
> > > +};
> > > +
> > > +static u32 mux_table_mali[] = {0, 1};
> > > +const char *gxbb_mali_parent_names[] = {
> > 
> > static?
> > 
> > > + "mali_0", "mali_1"
> > > +};
> > 
> > [...]
> > >  static struct clk_mux *gxbb_clk_muxes[] = {
> > >   _mpeg_clk_sel,
> > >   _sar_adc_clk_sel,
> > > + _mali_0_sel,
> > > + _mali_1_sel,
> > > + _mali,
> > >  };
> > >  
> > >  static struct clk_divider *gxbb_clk_dividers[] = {
> > 
> > Can these arrays be const? If so, please do that in a separate
> > patch.
> 
> Hmm, these were introduced by jerome, he should update them
> accordingly.
> 

Will do

> > >   _mpeg_clk_div,
> > >   _sar_adc_clk_div,
> > > + _mali_0_div,
> > > + _mali_1_div,
> > >  };
> 
> 
> Thanks,
> Neil

Re: [PATCH v2] video: fbdev: imxfb: support AUS mode

[Rob Herring]

On Tue, Feb 28, 2017 at 09:04:16PM +0100, Martin Kaiser wrote:
> Some displays require setting AUS mode in the LDCD AUS Mode Control
> Register to work with the imxfb driver. Like the value of the Panel
> Configuration Register, the AUS Mode Control Register's value depends on
> the display mode.
> 
> Allow setting this register from the device tree. Make the device tree
> node optional to keep the DT ABI stable. This register is available only
> on imx21 and compatible chipsets. Update the device tree bindings with
> this info.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>   re-sending DT bindings and code changes as one patch

The opposite is what is prefered.

> 
>  .../devicetree/bindings/display/imx/fsl,imx-fb.txt|  2 ++
>  drivers/video/fbdev/imxfb.c   | 19 
> +++
>  include/linux/platform_data/video-imxfb.h |  1 +
>  3 files changed, 22 insertions(+)

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

[Mike Galbraith]

On Wed, 2017-03-01 at 16:46 +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 01:29:57PM +0200, Nikolay Borisov wrote:
> > Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
> > during memory allocation") added the memalloc_noio_(save|restore) functions
> > to enable people to modify the MM behavior by disbaling I/O during memory
> > allocation. This was further extended in Fixes: 934f3072c17c ("mm: clear 
> > __GFP_FS when PF_MEMALLOC_NOIO is set"). memalloc_noio_* functions prevent 
> > allocation paths recursing back into the filesystem without explicitly 
> > changing the flags for every allocation site. However, lockdep hasn't been 
> > keeping up with the changes and it entirely misses handling the 
> > memalloc_noio
> > adjustments. Instead, it is left to the callers of __lockdep_trace_alloc to 
> > call the functino after they have shaven the respective GFP flags. 
> > 
> > Let's fix this by making lockdep explicitly do the shaving of respective
> > GFP flags. 
> 
> I edited that to look like the below, then my compiler said:
> 
> ../kernel/locking/lockdep.c: In function ‘lockdep_set_current_reclaim_state’:
> ../kernel/locking/lockdep.c:3866:33: error: implicit declaration of function 
> ‘memalloc_noio_flags’ [-Werror=implicit-function-declaration]
>   current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);

(ah, another shiny lockdep thingy... /me adds include, tries it)

I had hoped (silly me) that this would make annoying btrfs gripe
finally go the hell away, but alas, didn't happen.

[ 4968.346159] =
[ 4968.346160] [ INFO: possible irq lock inversion dependency detected ]
[ 4968.346163] 4.11.0-rt9-rt #179 Tainted: GW   E  
[ 4968.346164] -
[ 4968.346165] kswapd3/1337 just changed the state of lock:
[ 4968.346167]  (_node->mutex){+.+.-.}, at: [] 
__btrfs_release_delayed_node+0x3f/0x2f0 [btrfs]
[ 4968.346215] but this lock took another, RECLAIM_FS-unsafe lock in the past:
[ 4968.346215]  (pcpu_alloc_mutex){+.+.+.}
[ 4968.346216] 
   
   and interrupts could create inverse lock ordering between them.

[ 4968.346217] 
   other info that might help us debug this:
[ 4968.346217] Chain exists of:
 _node->mutex --> _info->commit_root_sem --> 
pcpu_alloc_mutex

[ 4968.346218]  Possible interrupt unsafe locking scenario:

[ 4968.346219]CPU0CPU1
[ 4968.346219]
[ 4968.346219]   lock(pcpu_alloc_mutex);
[ 4968.346220]local_irq_disable();
[ 4968.346220]lock(_node->mutex);
[ 4968.346221]lock(_info->commit_root_sem);
[ 4968.346221]   
[ 4968.346221] lock(_node->mutex);
[ 4968.346222] 
*** DEADLOCK ***

[ 4968.346223] 2 locks held by kswapd3/1337:
[ 4968.346223]  #0:  (shrinker_rwsem){+.+...}, at: [] 
shrink_slab+0x7a/0x6c0
[ 4968.346231]  #1:  (>s_umount_key#26){..}, at: [] 
trylock_super+0x1b/0x50
[ 4968.346236] 
   the shortest dependencies between 2nd lock and 1st lock:
[ 4968.346238]   -> (pcpu_alloc_mutex){+.+.+.} ops: 4124 {
[ 4968.346239]  HARDIRQ-ON-W at:
[ 4968.346246] __lock_acquire+0x8ec/0x14f0
[ 4968.346247] lock_acquire+0xbd/0x250
[ 4968.346252] _mutex_lock+0x31/0x40
[ 4968.346258] pcpu_alloc+0x197/0x5a0
[ 4968.346260] __alloc_percpu+0x15/0x20
[ 4968.346264] setup_zone_pageset+0x1f/0x71
[ 4968.346273] setup_per_cpu_pageset+0x23/0x65
[ 4968.346279] start_kernel+0x3d4/0x496
[ 4968.346281] x86_64_start_reservations+0x2a/0x2c
[ 4968.346282] x86_64_start_kernel+0x13d/0x14c
[ 4968.346285] verify_cpu+0x0/0xfc
[ 4968.346286]  SOFTIRQ-ON-W at:
[ 4968.346287] __lock_acquire+0x285/0x14f0
[ 4968.346288] lock_acquire+0xbd/0x250
[ 4968.346289] _mutex_lock+0x31/0x40
[ 4968.346291] pcpu_alloc+0x197/0x5a0
[ 4968.346292] __alloc_percpu+0x15/0x20
[ 4968.346293] setup_zone_pageset+0x1f/0x71
[ 4968.346295] setup_per_cpu_pageset+0x23/0x65
[ 4968.346296] start_kernel+0x3d4/0x496
[ 4968.346298] x86_64_start_reservations+0x2a/0x2c
[ 4968.346299] x86_64_start_kernel+0x13d/0x14c
[ 4968.346300] verify_cpu+0x0/0xfc
[ 4968.346301]  RECLAIM_FS-ON-W at:
[ 4968.346303]mark_held_locks+0x66/0x90
[ 4968.346304]lockdep_trace_alloc+0x7d/0xf0
[ 4968.346309]  

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

[Mike Galbraith]

On Wed, 2017-03-01 at 16:46 +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 01:29:57PM +0200, Nikolay Borisov wrote:
> > Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
> > during memory allocation") added the memalloc_noio_(save|restore) functions
> > to enable people to modify the MM behavior by disbaling I/O during memory
> > allocation. This was further extended in Fixes: 934f3072c17c ("mm: clear 
> > __GFP_FS when PF_MEMALLOC_NOIO is set"). memalloc_noio_* functions prevent 
> > allocation paths recursing back into the filesystem without explicitly 
> > changing the flags for every allocation site. However, lockdep hasn't been 
> > keeping up with the changes and it entirely misses handling the 
> > memalloc_noio
> > adjustments. Instead, it is left to the callers of __lockdep_trace_alloc to 
> > call the functino after they have shaven the respective GFP flags. 
> > 
> > Let's fix this by making lockdep explicitly do the shaving of respective
> > GFP flags. 
> 
> I edited that to look like the below, then my compiler said:
> 
> ../kernel/locking/lockdep.c: In function ‘lockdep_set_current_reclaim_state’:
> ../kernel/locking/lockdep.c:3866:33: error: implicit declaration of function 
> ‘memalloc_noio_flags’ [-Werror=implicit-function-declaration]
>   current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);

(ah, another shiny lockdep thingy... /me adds include, tries it)

I had hoped (silly me) that this would make annoying btrfs gripe
finally go the hell away, but alas, didn't happen.

[ 4968.346159] =
[ 4968.346160] [ INFO: possible irq lock inversion dependency detected ]
[ 4968.346163] 4.11.0-rt9-rt #179 Tainted: GW   E  
[ 4968.346164] -
[ 4968.346165] kswapd3/1337 just changed the state of lock:
[ 4968.346167]  (_node->mutex){+.+.-.}, at: [] 
__btrfs_release_delayed_node+0x3f/0x2f0 [btrfs]
[ 4968.346215] but this lock took another, RECLAIM_FS-unsafe lock in the past:
[ 4968.346215]  (pcpu_alloc_mutex){+.+.+.}
[ 4968.346216] 
   
   and interrupts could create inverse lock ordering between them.

[ 4968.346217] 
   other info that might help us debug this:
[ 4968.346217] Chain exists of:
 _node->mutex --> _info->commit_root_sem --> 
pcpu_alloc_mutex

[ 4968.346218]  Possible interrupt unsafe locking scenario:

[ 4968.346219]CPU0CPU1
[ 4968.346219]
[ 4968.346219]   lock(pcpu_alloc_mutex);
[ 4968.346220]local_irq_disable();
[ 4968.346220]lock(_node->mutex);
[ 4968.346221]lock(_info->commit_root_sem);
[ 4968.346221]   
[ 4968.346221] lock(_node->mutex);
[ 4968.346222] 
*** DEADLOCK ***

[ 4968.346223] 2 locks held by kswapd3/1337:
[ 4968.346223]  #0:  (shrinker_rwsem){+.+...}, at: [] 
shrink_slab+0x7a/0x6c0
[ 4968.346231]  #1:  (>s_umount_key#26){..}, at: [] 
trylock_super+0x1b/0x50
[ 4968.346236] 
   the shortest dependencies between 2nd lock and 1st lock:
[ 4968.346238]   -> (pcpu_alloc_mutex){+.+.+.} ops: 4124 {
[ 4968.346239]  HARDIRQ-ON-W at:
[ 4968.346246] __lock_acquire+0x8ec/0x14f0
[ 4968.346247] lock_acquire+0xbd/0x250
[ 4968.346252] _mutex_lock+0x31/0x40
[ 4968.346258] pcpu_alloc+0x197/0x5a0
[ 4968.346260] __alloc_percpu+0x15/0x20
[ 4968.346264] setup_zone_pageset+0x1f/0x71
[ 4968.346273] setup_per_cpu_pageset+0x23/0x65
[ 4968.346279] start_kernel+0x3d4/0x496
[ 4968.346281] x86_64_start_reservations+0x2a/0x2c
[ 4968.346282] x86_64_start_kernel+0x13d/0x14c
[ 4968.346285] verify_cpu+0x0/0xfc
[ 4968.346286]  SOFTIRQ-ON-W at:
[ 4968.346287] __lock_acquire+0x285/0x14f0
[ 4968.346288] lock_acquire+0xbd/0x250
[ 4968.346289] _mutex_lock+0x31/0x40
[ 4968.346291] pcpu_alloc+0x197/0x5a0
[ 4968.346292] __alloc_percpu+0x15/0x20
[ 4968.346293] setup_zone_pageset+0x1f/0x71
[ 4968.346295] setup_per_cpu_pageset+0x23/0x65
[ 4968.346296] start_kernel+0x3d4/0x496
[ 4968.346298] x86_64_start_reservations+0x2a/0x2c
[ 4968.346299] x86_64_start_kernel+0x13d/0x14c
[ 4968.346300] verify_cpu+0x0/0xfc
[ 4968.346301]  RECLAIM_FS-ON-W at:
[ 4968.346303]mark_held_locks+0x66/0x90
[ 4968.346304]lockdep_trace_alloc+0x7d/0xf0
[ 4968.346309]  

[PATCH] doc/ko_KR/memory-barriers: Update control-dependencies section

[SeongJae Park]

This commit applies upstream change, commit c8241f8553e8 ("doc: Update
control-dependencies section of memory-barriers.txt"), to Korean
translation.

Signed-off-by: SeongJae Park 
---
 .../translations/ko_KR/memory-barriers.txt | 68 --
 1 file changed, 37 insertions(+), 31 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index a3228a676cc1..ce0b48d69eaa 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -662,6 +662,10 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 
rcu_dereference() 를
 컨트롤 의존성
 -
 
+현재의 컴파일러들은 컨트롤 의존성을 이해하고 있지 않기 때문에 컨트롤 의존성은
+약간 다루기 어려울 수 있습니다.  이 섹션의 목적은 여러분이 컴파일러의 무시로
+인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다.
+
 로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가
 없어서 읽기 메모리 배리어를 필요로 합니다.  아래의 코드를 봅시다:
 
@@ -689,20 +693,21 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
}
 
 컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다.  그렇다곤
-하나, READ_ONCE() 는 반드시 사용해야 함을 부디 명심하세요!  READ_ONCE() 가
-없다면, 컴파일러가 'a' 로부터의 로드를 'a' 로부터의 또다른 로드와, 'b' 로의
-스토어를 'b' 로의 또다른 스토어와 조합해 버려 매우 비직관적인 결과를 초래할 수
-있습니다.
+하나, READ_ONCE() 도 WRITE_ONCE() 도 선택사항이 아니라 필수사항임을 부디
+명심하세요!  READ_ONCE() 가 없다면, 컴파일러는 'a' 로부터의 로드를 'a' 로부터의
+또다른 로드와 조합할 수 있습니다.  WRITE_ONCE() 가 없다면, 컴파일러는 'b' 로의
+스토어를 'b' 로의 또라느 스토어들과 조합할 수 있습니다.  두 경우 모두 순서에
+있어 상당히 비직관적인 결과를 초래할 수 있습니다.
 
 이걸로 끝이 아닌게, 컴파일러가 변수 'a' 의 값이 항상 0이 아니라고 증명할 수
 있다면, 앞의 예에서 "if" 문을 없애서 다음과 같이 최적화 할 수도 있습니다:
 
q = a;
-   b = p;  /* BUG: Compiler and CPU can both reorder!!! */
+   b = 1;  /* BUG: Compiler and CPU can both reorder!!! */
 
 그러니 READ_ONCE() 를 반드시 사용하세요.
 
@@ -712,11 +717,11 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
q = READ_ONCE(a);
if (q) {
barrier();
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
barrier();
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something_else();
}
 
@@ -725,12 +730,12 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
barrier();
-   WRITE_ONCE(b, p);  /* BUG: No ordering vs. load from a!!! */
+   WRITE_ONCE(b, 1);  /* BUG: No ordering vs. load from a!!! */
if (q) {
-   /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+   /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
do_something();
} else {
-   /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+   /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
do_something_else();
}
 
@@ -742,10 +747,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   smp_store_release(, p);
+   smp_store_release(, 1);
do_something();
} else {
-   smp_store_release(, p);
+   smp_store_release(, 1);
do_something_else();
}
 
@@ -754,10 +759,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -770,10 +775,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q % MAX) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -781,7 +786,7 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 위의 코드를 아래와 같이 바꿔버릴 수 있습니다:
 
q = READ_ONCE(a);
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something_else();
 
 이렇게 되면, CPU 는 변수 'a' 로부터의 로드와 변수 'b' 로의 스토어 사이의 순서를
@@ -793,10 +798,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
q = READ_ONCE(a);
BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
if (q % MAX) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -828,35 +833,33 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
}
-   WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from "a". */
+   WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from 'a'. */
 
-컴파일러는 volatile 타입에 

[PATCH] doc/ko_KR/memory-barriers: Update control-dependencies section

[SeongJae Park]

This commit applies upstream change, commit c8241f8553e8 ("doc: Update
control-dependencies section of memory-barriers.txt"), to Korean
translation.

Signed-off-by: SeongJae Park 
---
 .../translations/ko_KR/memory-barriers.txt | 68 --
 1 file changed, 37 insertions(+), 31 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index a3228a676cc1..ce0b48d69eaa 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -662,6 +662,10 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 
rcu_dereference() 를
 컨트롤 의존성
 -
 
+현재의 컴파일러들은 컨트롤 의존성을 이해하고 있지 않기 때문에 컨트롤 의존성은
+약간 다루기 어려울 수 있습니다.  이 섹션의 목적은 여러분이 컴파일러의 무시로
+인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다.
+
 로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가
 없어서 읽기 메모리 배리어를 필요로 합니다.  아래의 코드를 봅시다:
 
@@ -689,20 +693,21 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
}
 
 컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다.  그렇다곤
-하나, READ_ONCE() 는 반드시 사용해야 함을 부디 명심하세요!  READ_ONCE() 가
-없다면, 컴파일러가 'a' 로부터의 로드를 'a' 로부터의 또다른 로드와, 'b' 로의
-스토어를 'b' 로의 또다른 스토어와 조합해 버려 매우 비직관적인 결과를 초래할 수
-있습니다.
+하나, READ_ONCE() 도 WRITE_ONCE() 도 선택사항이 아니라 필수사항임을 부디
+명심하세요!  READ_ONCE() 가 없다면, 컴파일러는 'a' 로부터의 로드를 'a' 로부터의
+또다른 로드와 조합할 수 있습니다.  WRITE_ONCE() 가 없다면, 컴파일러는 'b' 로의
+스토어를 'b' 로의 또라느 스토어들과 조합할 수 있습니다.  두 경우 모두 순서에
+있어 상당히 비직관적인 결과를 초래할 수 있습니다.
 
 이걸로 끝이 아닌게, 컴파일러가 변수 'a' 의 값이 항상 0이 아니라고 증명할 수
 있다면, 앞의 예에서 "if" 문을 없애서 다음과 같이 최적화 할 수도 있습니다:
 
q = a;
-   b = p;  /* BUG: Compiler and CPU can both reorder!!! */
+   b = 1;  /* BUG: Compiler and CPU can both reorder!!! */
 
 그러니 READ_ONCE() 를 반드시 사용하세요.
 
@@ -712,11 +717,11 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
q = READ_ONCE(a);
if (q) {
barrier();
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
barrier();
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something_else();
}
 
@@ -725,12 +730,12 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
barrier();
-   WRITE_ONCE(b, p);  /* BUG: No ordering vs. load from a!!! */
+   WRITE_ONCE(b, 1);  /* BUG: No ordering vs. load from a!!! */
if (q) {
-   /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+   /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
do_something();
} else {
-   /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+   /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
do_something_else();
}
 
@@ -742,10 +747,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   smp_store_release(, p);
+   smp_store_release(, 1);
do_something();
} else {
-   smp_store_release(, p);
+   smp_store_release(, 1);
do_something_else();
}
 
@@ -754,10 +759,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -770,10 +775,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q % MAX) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -781,7 +786,7 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 위의 코드를 아래와 같이 바꿔버릴 수 있습니다:
 
q = READ_ONCE(a);
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something_else();
 
 이렇게 되면, CPU 는 변수 'a' 로부터의 로드와 변수 'b' 로의 스토어 사이의 순서를
@@ -793,10 +798,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
q = READ_ONCE(a);
BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
if (q % MAX) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
do_something();
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
do_something_else();
}
 
@@ -828,35 +833,33 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
q = READ_ONCE(a);
if (q) {
-   WRITE_ONCE(b, p);
+   WRITE_ONCE(b, 1);
} else {
-   WRITE_ONCE(b, r);
+   WRITE_ONCE(b, 2);
}
-   WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from "a". */
+   WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from 'a'. */
 
-컴파일러는 volatile 타입에 대한 액세스를 재배치 할 수 없고 이 

[GIT PULL] More power management updates for v4.11-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-extra-4.11-rc1

with top-most commit 9b5e9cb164ee93ae19c4c6593e8188a55481f78b

 Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'pm-sleep'

on top of commit 02c3de1105228e367320e7fdeffbf511904f398c

 Merge tag 'pm-4.11-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

to receive extra power management updates for v4.11-rc1.

These fix two bugs introduced by recent power management updates
(in the cpuidle menu governor and intel_pstate) and a few other
issues, clean up things and remove unused code.

Specifics:

 - Fix for a cpuidle menu governor problem that started to take an
   unnecessary spinlock after one of the recent updates and that
   did not play well with the RT patch (Rafael Wysocki).

 - Fix for the new intel_pstate operation mode switching feature
   added recently that did not reinitialize P-state limits properly
   when switching operation modes (Rafael Wysocki).

 - Removal of unused global notifiers from the PM QoS framework
   (Viresh Kumar).

 - Generic power domains framework update to make it handle
   asynchronous invocations of PM callbacks in the "noirq" phases
   of system suspend/hibernation correctly (Ulf Hansson).

 - Two hibernation core cleanups (Rafael Wysocki).

 - intel_idle cleanup related to the sysfs interface (Len Brown).

 - Off-by-one bug fix in the OPP (Operating Performance Points)
   framework (Andrzej Hajda).

 - OPP framework's documentation fix (Viresh Kumar).

 - cpufreq qoriq driver cleanup (Tang Yuantian).

 - Fixes for typos in comments in the device runtime PM framework
   (Christophe Jaillet).

Thanks!

---

Andrzej Hajda (1):
  PM / OPP: fix off-by-one bug in dev_pm_opp_get_max_volt_latency loop

Christophe Jaillet (1):
  PM / runtime: Fix some typos

Len Brown (1):
  intel_idle: stop exposing platform acronyms in sysfs

Rafael J. Wysocki (4):
  cpuidle: menu: Avoid taking spinlock for accessing QoS values
  PM / hibernate: Untangle power_down()
  PM / hibernate: Define pr_fmt() and use pr_*() instead of printk()
  cpufreq: intel_pstate: Fix limits issue with operation mode switching

Tang Yuantian (1):
  cpufreq: qoriq: clean up unused code

Ulf Hansson (3):
  PM / Domains: Move genpd_power_off() above genpd_power_on()
  PM / Domains: Rename is_async to one_dev_on for genpd_power_off()
  PM / Domains: Power off masters immediately in the power off sequence

Viresh Kumar (2):
  PM / QoS: Remove global notifiers
  PM / OPP: Documentation: Fix opp-microvolt in examples

---

 Documentation/devicetree/bindings/opp/opp.txt |  44 +++
 Documentation/power/pm_qos_interface.txt  |  13 +-
 Documentation/power/runtime_pm.txt|   6 +-
 drivers/base/power/domain.c   | 178 ++
 drivers/base/power/opp/core.c |   3 +-
 drivers/base/power/qos.c  |  53 +---
 drivers/cpufreq/intel_pstate.c|  65 --
 drivers/cpufreq/qoriq-cpufreq.c   |   4 -
 drivers/cpuidle/governors/menu.c  |   2 +-
 drivers/idle/intel_idle.c | 172 -
 include/linux/pm_qos.h|  15 +--
 kernel/power/hibernate.c  |  93 +++---
 12 files changed, 286 insertions(+), 362 deletions(-)

[GIT PULL] More power management updates for v4.11-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-extra-4.11-rc1

with top-most commit 9b5e9cb164ee93ae19c4c6593e8188a55481f78b

 Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'pm-sleep'

on top of commit 02c3de1105228e367320e7fdeffbf511904f398c

 Merge tag 'pm-4.11-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

to receive extra power management updates for v4.11-rc1.

These fix two bugs introduced by recent power management updates
(in the cpuidle menu governor and intel_pstate) and a few other
issues, clean up things and remove unused code.

Specifics:

 - Fix for a cpuidle menu governor problem that started to take an
   unnecessary spinlock after one of the recent updates and that
   did not play well with the RT patch (Rafael Wysocki).

 - Fix for the new intel_pstate operation mode switching feature
   added recently that did not reinitialize P-state limits properly
   when switching operation modes (Rafael Wysocki).

 - Removal of unused global notifiers from the PM QoS framework
   (Viresh Kumar).

 - Generic power domains framework update to make it handle
   asynchronous invocations of PM callbacks in the "noirq" phases
   of system suspend/hibernation correctly (Ulf Hansson).

 - Two hibernation core cleanups (Rafael Wysocki).

 - intel_idle cleanup related to the sysfs interface (Len Brown).

 - Off-by-one bug fix in the OPP (Operating Performance Points)
   framework (Andrzej Hajda).

 - OPP framework's documentation fix (Viresh Kumar).

 - cpufreq qoriq driver cleanup (Tang Yuantian).

 - Fixes for typos in comments in the device runtime PM framework
   (Christophe Jaillet).

Thanks!

---

Andrzej Hajda (1):
  PM / OPP: fix off-by-one bug in dev_pm_opp_get_max_volt_latency loop

Christophe Jaillet (1):
  PM / runtime: Fix some typos

Len Brown (1):
  intel_idle: stop exposing platform acronyms in sysfs

Rafael J. Wysocki (4):
  cpuidle: menu: Avoid taking spinlock for accessing QoS values
  PM / hibernate: Untangle power_down()
  PM / hibernate: Define pr_fmt() and use pr_*() instead of printk()
  cpufreq: intel_pstate: Fix limits issue with operation mode switching

Tang Yuantian (1):
  cpufreq: qoriq: clean up unused code

Ulf Hansson (3):
  PM / Domains: Move genpd_power_off() above genpd_power_on()
  PM / Domains: Rename is_async to one_dev_on for genpd_power_off()
  PM / Domains: Power off masters immediately in the power off sequence

Viresh Kumar (2):
  PM / QoS: Remove global notifiers
  PM / OPP: Documentation: Fix opp-microvolt in examples

---

 Documentation/devicetree/bindings/opp/opp.txt |  44 +++
 Documentation/power/pm_qos_interface.txt  |  13 +-
 Documentation/power/runtime_pm.txt|   6 +-
 drivers/base/power/domain.c   | 178 ++
 drivers/base/power/opp/core.c |   3 +-
 drivers/base/power/qos.c  |  53 +---
 drivers/cpufreq/intel_pstate.c|  65 --
 drivers/cpufreq/qoriq-cpufreq.c   |   4 -
 drivers/cpuidle/governors/menu.c  |   2 +-
 drivers/idle/intel_idle.c | 172 -
 include/linux/pm_qos.h|  15 +--
 kernel/power/hibernate.c  |  93 +++---
 12 files changed, 286 insertions(+), 362 deletions(-)

Re: [PATCH v5 1/4] dt-bindings: iio: accel: Document ADXL345 accelerometer binding

[Rob Herring]

On Tue, Feb 28, 2017 at 10:37:16AM +0800, Eva Rachel Retuya wrote:
> Add the device tree binding documentation for the ADXL345 3-axis digital
> accelerometer.
> 
> Signed-off-by: Eva Rachel Retuya 
> ---
> Changes from v4:
> * Update subject-prefix 
> * Update node name from "adxl345@unit-address" to "accelerometer@unit-address"
> 
>  .../devicetree/bindings/iio/accel/adxl345.txt  | 38 
> ++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl345.txt

Acked-by: Rob Herring 

Re: [PATCH v5 1/4] dt-bindings: iio: accel: Document ADXL345 accelerometer binding

[Rob Herring]

On Tue, Feb 28, 2017 at 10:37:16AM +0800, Eva Rachel Retuya wrote:
> Add the device tree binding documentation for the ADXL345 3-axis digital
> accelerometer.
> 
> Signed-off-by: Eva Rachel Retuya 
> ---
> Changes from v4:
> * Update subject-prefix 
> * Update node name from "adxl345@unit-address" to "accelerometer@unit-address"
> 
>  .../devicetree/bindings/iio/accel/adxl345.txt  | 38 
> ++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl345.txt

Acked-by: Rob Herring 

Re: [PATCH] USB: misc: ldusb: Fixed coding style issues

[Greg KH]

On Fri, Mar 03, 2017 at 12:55:46AM +0100, Milian Reichardt wrote:
> Fixed multiple coding style issues.

Please be specific as to exactly what issues you are fixing up.  And
don't do multiple things in the same patch, each different thing needs
to be broken up into an individual patch.

thanks,

greg k-h

Re: [PATCH v1] nvmem: i.MX IIM driver

[Sascha Hauer]

Srinivas, Maxime,

Any comments on this one?

Sascha

On Mon, Feb 13, 2017 at 04:31:47PM +0100, Sascha Hauer wrote:
> 
> This adds a readonly nvmem driver for the i.MX IC Identification Module (IIM)
> which is found on the older i.MX SoCs. The IIM is part of the i.MX dts files
> for long now, but so far there is no binding document for it, so add one now.
> 
> Sascha
> 
> 
> Michael Grzeschik (1):
>   nvmem: Add driver for the i.MX IIM
> 
> Sascha Hauer (1):
>   dt-bindings: nvmem: Add i.MX IIM binding doc
> 
>  .../devicetree/bindings/nvmem/imx-iim.txt  |  22 +++
>  drivers/nvmem/Kconfig  |  11 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/imx-iim.c| 171 
> +
>  4 files changed, 206 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/imx-iim.txt
>  create mode 100644 drivers/nvmem/imx-iim.c
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] selftests: lib.mk Fix individual test builds

[Michael Ellerman]

Shuah Khan  writes:
> In commit a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT"), added
> support to generate compile targets in a user specified directory. OUTPUT
> variable controls the location which is undefined when tests are built in
> the test directory or with "make -C tools/testing/selftests/x86".
>
> make -C tools/testing/selftests/x86/
> make: Entering directory '/lkml/linux_4.11/tools/testing/selftests/x86'
> Makefile:44: warning: overriding recipe for target 'clean'
> ../lib.mk:51: warning: ignoring old recipe for target 'clean'
> gcc -m64 -o /single_step_syscall_64 -O2 -g -std=gnu99 -pthread -Wall  
> single_step_syscall.c -lrt -ldl
> /usr/bin/ld: cannot open output file /single_step_syscall_64: Permission 
> denied
> collect2: error: ld returned 1 exit status
> Makefile:50: recipe for target '/single_step_syscall_64' failed
> make: *** [/single_step_syscall_64] Error 1
> make: Leaving directory '/lkml/linux_4.11/tools/testing/selftests/x86'
>
> Same failure with "cd tools/testing/selftests/x86/;make" run.
>
> Fix this with a change to lib.mk to define OUTPUT to be the pwd when
> MAKELEVEL is 0. This covers both cases mentioned above.
>
> Reported-by: Ingo Molnar 
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/lib.mk | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> index ce96d80..775c589 100644
> --- a/tools/testing/selftests/lib.mk
> +++ b/tools/testing/selftests/lib.mk
> @@ -2,6 +2,10 @@
>  # Makefile can operate with or without the kbuild infrastructure.
>  CC := $(CROSS_COMPILE)gcc
>  
> +ifeq (0,$(MAKELEVEL))
> +OUTPUT := $(shell pwd)
> +endif

I preferred my version which just used =? rather than checking
MAKELEVEL, but I don't mind that much.

Acked-by: Michael Ellerman 

cheers

Re: [PATCH] USB: misc: ldusb: Fixed coding style issues

[Greg KH]

On Fri, Mar 03, 2017 at 12:55:46AM +0100, Milian Reichardt wrote:
> Fixed multiple coding style issues.

Please be specific as to exactly what issues you are fixing up.  And
don't do multiple things in the same patch, each different thing needs
to be broken up into an individual patch.

thanks,

greg k-h

Re: [PATCH v1] nvmem: i.MX IIM driver

[Sascha Hauer]

Srinivas, Maxime,

Any comments on this one?

Sascha

On Mon, Feb 13, 2017 at 04:31:47PM +0100, Sascha Hauer wrote:
> 
> This adds a readonly nvmem driver for the i.MX IC Identification Module (IIM)
> which is found on the older i.MX SoCs. The IIM is part of the i.MX dts files
> for long now, but so far there is no binding document for it, so add one now.
> 
> Sascha
> 
> 
> Michael Grzeschik (1):
>   nvmem: Add driver for the i.MX IIM
> 
> Sascha Hauer (1):
>   dt-bindings: nvmem: Add i.MX IIM binding doc
> 
>  .../devicetree/bindings/nvmem/imx-iim.txt  |  22 +++
>  drivers/nvmem/Kconfig  |  11 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/imx-iim.c| 171 
> +
>  4 files changed, 206 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/imx-iim.txt
>  create mode 100644 drivers/nvmem/imx-iim.c
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] selftests: lib.mk Fix individual test builds

[Michael Ellerman]

Shuah Khan  writes:
> In commit a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT"), added
> support to generate compile targets in a user specified directory. OUTPUT
> variable controls the location which is undefined when tests are built in
> the test directory or with "make -C tools/testing/selftests/x86".
>
> make -C tools/testing/selftests/x86/
> make: Entering directory '/lkml/linux_4.11/tools/testing/selftests/x86'
> Makefile:44: warning: overriding recipe for target 'clean'
> ../lib.mk:51: warning: ignoring old recipe for target 'clean'
> gcc -m64 -o /single_step_syscall_64 -O2 -g -std=gnu99 -pthread -Wall  
> single_step_syscall.c -lrt -ldl
> /usr/bin/ld: cannot open output file /single_step_syscall_64: Permission 
> denied
> collect2: error: ld returned 1 exit status
> Makefile:50: recipe for target '/single_step_syscall_64' failed
> make: *** [/single_step_syscall_64] Error 1
> make: Leaving directory '/lkml/linux_4.11/tools/testing/selftests/x86'
>
> Same failure with "cd tools/testing/selftests/x86/;make" run.
>
> Fix this with a change to lib.mk to define OUTPUT to be the pwd when
> MAKELEVEL is 0. This covers both cases mentioned above.
>
> Reported-by: Ingo Molnar 
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/lib.mk | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> index ce96d80..775c589 100644
> --- a/tools/testing/selftests/lib.mk
> +++ b/tools/testing/selftests/lib.mk
> @@ -2,6 +2,10 @@
>  # Makefile can operate with or without the kbuild infrastructure.
>  CC := $(CROSS_COMPILE)gcc
>  
> +ifeq (0,$(MAKELEVEL))
> +OUTPUT := $(shell pwd)
> +endif

I preferred my version which just used =? rather than checking
MAKELEVEL, but I don't mind that much.

Acked-by: Michael Ellerman 

cheers

[PATCH v4 2/5] perf report: Find the inline stack for a given address

[Jin Yao]

It would be useful for perf to support a mode to query the
inline stack for a given callgraph address. This would simplify
finding the right code in code that does a lot of inlining.

The srcline.c has contained the code which supports to translate
the address to filename:line_nr. This patch just extends the
function to let it support getting the inline stacks.

It introduces the inline_list which will store the inline
function result (filename:line_nr and funcname).

Signed-off-by: Jin Yao 
Tested-by: Milian Wolff 
---
 tools/perf/util/srcline.c| 169 +--
 tools/perf/util/symbol-elf.c |   5 ++
 tools/perf/util/symbol.h |   2 +
 tools/perf/util/util.h   |  16 
 4 files changed, 187 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 2953c9f..f9d4b47 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -7,6 +7,7 @@
 #include "util/dso.h"
 #include "util/util.h"
 #include "util/debug.h"
+#include "util/callchain.h"
 
 #include "symbol.h"
 
@@ -30,6 +31,41 @@ static const char *dso__name(struct dso *dso)
return dso_name;
 }
 
+static int inline_list__append(char *filename, char *funcname, int line_nr,
+  struct inline_node *node, struct dso *dso)
+{
+   struct inline_list *ilist;
+   char *demangled;
+
+   ilist = zalloc(sizeof(*ilist));
+   if (ilist == NULL)
+   return -1;
+
+   ilist->filename = filename;
+   ilist->line_nr = line_nr;
+
+   demangled = dso__demangle_sym(dso, 0, funcname);
+   if (demangled == NULL) {
+   ilist->funcname = funcname;
+   } else {
+   ilist->funcname = demangled;
+   if (funcname != NULL)
+   free(funcname);
+   }
+
+   list_add_tail(>list, >val);
+
+   return 0;
+}
+
+static void inline_list__reverse(struct inline_node *node)
+{
+   struct inline_list *ilist, *n;
+
+   list_for_each_entry_safe_reverse(ilist, n, >val, list)
+   list_move_tail(>list, >val);
+}
+
 #ifdef HAVE_LIBBFD_SUPPORT
 
 /*
@@ -171,7 +207,7 @@ static void addr2line_cleanup(struct a2l_data *a2l)
 
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line, struct dso *dso,
-bool unwind_inlines)
+bool unwind_inlines, struct inline_node *node)
 {
int ret = 0;
struct a2l_data *a2l = dso->a2l;
@@ -196,8 +232,21 @@ static int addr2line(const char *dso_name, u64 addr,
 
while (bfd_find_inliner_info(a2l->abfd, >filename,
 >funcname, >line) &&
-  cnt++ < MAX_INLINE_NEST)
-   ;
+  cnt++ < MAX_INLINE_NEST) {
+
+   if (node != NULL) {
+   if (inline_list__append(strdup(a2l->filename),
+   strdup(a2l->funcname),
+   a2l->line, node,
+   dso) != 0)
+   return 0;
+   }
+   }
+
+   if ((node != NULL) &&
+   (callchain_param.order != ORDER_CALLEE)) {
+   inline_list__reverse(node);
+   }
}
 
if (a2l->found && a2l->filename) {
@@ -223,6 +272,35 @@ void dso__free_a2l(struct dso *dso)
dso->a2l = NULL;
 }
 
+static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
+   struct dso *dso)
+{
+   char *file = NULL;
+   unsigned int line = 0;
+   struct inline_node *node;
+
+   node = zalloc(sizeof(*node));
+   if (node == NULL) {
+   perror("not enough memory for the inline node");
+   return NULL;
+   }
+
+   INIT_LIST_HEAD(>val);
+   node->addr = addr;
+
+   if (!addr2line(dso_name, addr, , , dso, TRUE, node))
+   goto out_free_inline_node;
+
+   if (list_empty(>val))
+   goto out_free_inline_node;
+
+   return node;
+
+out_free_inline_node:
+   inline_node__delete(node);
+   return NULL;
+}
+
 #else /* HAVE_LIBBFD_SUPPORT */
 
 static int filename_split(char *filename, unsigned int *line_nr)
@@ -249,7 +327,8 @@ static int filename_split(char *filename, unsigned int 
*line_nr)
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line_nr,
 struct dso *dso __maybe_unused,
-bool unwind_inlines __maybe_unused)
+bool unwind_inlines __maybe_unused,
+struct inline_node *node __maybe_unused)
 {
FILE *fp;
char cmd[PATH_MAX];
@@ -288,6 +367,57 @@ void 

[PATCH v4 2/5] perf report: Find the inline stack for a given address

[Jin Yao]

It would be useful for perf to support a mode to query the
inline stack for a given callgraph address. This would simplify
finding the right code in code that does a lot of inlining.

The srcline.c has contained the code which supports to translate
the address to filename:line_nr. This patch just extends the
function to let it support getting the inline stacks.

It introduces the inline_list which will store the inline
function result (filename:line_nr and funcname).

Signed-off-by: Jin Yao 
Tested-by: Milian Wolff 
---
 tools/perf/util/srcline.c| 169 +--
 tools/perf/util/symbol-elf.c |   5 ++
 tools/perf/util/symbol.h |   2 +
 tools/perf/util/util.h   |  16 
 4 files changed, 187 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 2953c9f..f9d4b47 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -7,6 +7,7 @@
 #include "util/dso.h"
 #include "util/util.h"
 #include "util/debug.h"
+#include "util/callchain.h"
 
 #include "symbol.h"
 
@@ -30,6 +31,41 @@ static const char *dso__name(struct dso *dso)
return dso_name;
 }
 
+static int inline_list__append(char *filename, char *funcname, int line_nr,
+  struct inline_node *node, struct dso *dso)
+{
+   struct inline_list *ilist;
+   char *demangled;
+
+   ilist = zalloc(sizeof(*ilist));
+   if (ilist == NULL)
+   return -1;
+
+   ilist->filename = filename;
+   ilist->line_nr = line_nr;
+
+   demangled = dso__demangle_sym(dso, 0, funcname);
+   if (demangled == NULL) {
+   ilist->funcname = funcname;
+   } else {
+   ilist->funcname = demangled;
+   if (funcname != NULL)
+   free(funcname);
+   }
+
+   list_add_tail(>list, >val);
+
+   return 0;
+}
+
+static void inline_list__reverse(struct inline_node *node)
+{
+   struct inline_list *ilist, *n;
+
+   list_for_each_entry_safe_reverse(ilist, n, >val, list)
+   list_move_tail(>list, >val);
+}
+
 #ifdef HAVE_LIBBFD_SUPPORT
 
 /*
@@ -171,7 +207,7 @@ static void addr2line_cleanup(struct a2l_data *a2l)
 
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line, struct dso *dso,
-bool unwind_inlines)
+bool unwind_inlines, struct inline_node *node)
 {
int ret = 0;
struct a2l_data *a2l = dso->a2l;
@@ -196,8 +232,21 @@ static int addr2line(const char *dso_name, u64 addr,
 
while (bfd_find_inliner_info(a2l->abfd, >filename,
 >funcname, >line) &&
-  cnt++ < MAX_INLINE_NEST)
-   ;
+  cnt++ < MAX_INLINE_NEST) {
+
+   if (node != NULL) {
+   if (inline_list__append(strdup(a2l->filename),
+   strdup(a2l->funcname),
+   a2l->line, node,
+   dso) != 0)
+   return 0;
+   }
+   }
+
+   if ((node != NULL) &&
+   (callchain_param.order != ORDER_CALLEE)) {
+   inline_list__reverse(node);
+   }
}
 
if (a2l->found && a2l->filename) {
@@ -223,6 +272,35 @@ void dso__free_a2l(struct dso *dso)
dso->a2l = NULL;
 }
 
+static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
+   struct dso *dso)
+{
+   char *file = NULL;
+   unsigned int line = 0;
+   struct inline_node *node;
+
+   node = zalloc(sizeof(*node));
+   if (node == NULL) {
+   perror("not enough memory for the inline node");
+   return NULL;
+   }
+
+   INIT_LIST_HEAD(>val);
+   node->addr = addr;
+
+   if (!addr2line(dso_name, addr, , , dso, TRUE, node))
+   goto out_free_inline_node;
+
+   if (list_empty(>val))
+   goto out_free_inline_node;
+
+   return node;
+
+out_free_inline_node:
+   inline_node__delete(node);
+   return NULL;
+}
+
 #else /* HAVE_LIBBFD_SUPPORT */
 
 static int filename_split(char *filename, unsigned int *line_nr)
@@ -249,7 +327,8 @@ static int filename_split(char *filename, unsigned int 
*line_nr)
 static int addr2line(const char *dso_name, u64 addr,
 char **file, unsigned int *line_nr,
 struct dso *dso __maybe_unused,
-bool unwind_inlines __maybe_unused)
+bool unwind_inlines __maybe_unused,
+struct inline_node *node __maybe_unused)
 {
FILE *fp;
char cmd[PATH_MAX];
@@ -288,6 +367,57 @@ void dso__free_a2l(struct dso *dso __maybe_unused)
 {
 }
 
+static 

Re: [RFC v0 0/2] Introduce on-chip interconnect API

[Rob Herring]

On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> graphics, modem). These cores are talking to each other and can generate a lot
> of data flowing through the on-chip interconnects. These interconnect buses
> could form different topologies such as crossbar, point to point buses,
> hierarchical buses or use the network-on-chip concept.
> 
> These buses have been sized usually to handle use cases with high data
> throughput but it is not necessary all the time and consume a lot of power.
> Furthermore, the priority between masters can vary depending on the running
> use case like video playback or cpu intensive tasks.
> 
> Having an API to control the requirement of the system in term of bandwidth
> and QoS, so we can adapt the interconnect configuration to match those by
> scaling the frequencies, setting link priority and tuning QoS parameters.
> This configuration can be a static, one-time operation done at boot for some
> platforms or a dynamic set of operations that happen at run-time.
> 
> This patchset introduce a new API to get the requirement and configure the
> interconnect buses across the entire chipset to fit with the current demand.
> The API is NOT for changing the performance of the endpoint devices, but only
> the interconnect path in between them.
> 
> The API is using a consumer/provider-based model, where the providers are
> the interconnect controllers and the consumers could be various drivers.
> The consumers request interconnect resources (path) to an endpoint and set
> the desired constraints on this data flow path. The provider(s) receive
> requests from consumers and aggregate these requests for all master-slave
> pairs on that path. Then the providers configure each participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
> 
> Below is a simplified diagram of a real-world SoC topology. The interconnect
> providers are the memory front-end and the NoCs.
> 
> ++++
> | HW Accelerator |--->|  M NoC |<---+
> ++++|
> |  |++
>   +-+  V   +--+ ||
>   |++  | PCIe | ||
>   || Slaves |  +--+ ||
>   |++ | |   C NoC|
>   V   V ||
> +--+   ++   ||   +-+
> |  |-->||-->||-->| CPU |
> |  |-->||<--||   +-+
> |  Memory  |   | S NoC  |   ++
> |  |<--||-+|
> |  |<--||<--+ ||   ++
> +--+   ++   | |+-->| Slaves |
>^ ^^   ^ | |++
>| ||   | | V
> +-+  |  +-++-+  +-+   ++   ++
> | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| Slaves |
> +-+  |  +-++-+  +-+   ++   ++
>  |
>  +---+
>  | Modem |
>  +---+
> 
> This RFC does not implement all features but only main skeleton to check the
> validity of the proposal. Currently it only works with device-tree and 
> platform
> devices.
> 
> TODO:
>  * Constraints are currently stored in internal data structure. Should PM QoS
>  be used instead?
>  * Rework the framework to not depend on DT as frameworks cannot be tied
>  directly to firmware interfaces. Add support for ACPI?

I would start without DT even. You can always have the data you need in 
the kernel. This will be more flexible as you're not defining an ABI as 
this evolves. I think it will take some time to have consensus on how to 
represent the bus master view of buses/interconnects (It's been 
attempted before). 

Rob

Re: [RFC v0 0/2] Introduce on-chip interconnect API

[Rob Herring]

On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> graphics, modem). These cores are talking to each other and can generate a lot
> of data flowing through the on-chip interconnects. These interconnect buses
> could form different topologies such as crossbar, point to point buses,
> hierarchical buses or use the network-on-chip concept.
> 
> These buses have been sized usually to handle use cases with high data
> throughput but it is not necessary all the time and consume a lot of power.
> Furthermore, the priority between masters can vary depending on the running
> use case like video playback or cpu intensive tasks.
> 
> Having an API to control the requirement of the system in term of bandwidth
> and QoS, so we can adapt the interconnect configuration to match those by
> scaling the frequencies, setting link priority and tuning QoS parameters.
> This configuration can be a static, one-time operation done at boot for some
> platforms or a dynamic set of operations that happen at run-time.
> 
> This patchset introduce a new API to get the requirement and configure the
> interconnect buses across the entire chipset to fit with the current demand.
> The API is NOT for changing the performance of the endpoint devices, but only
> the interconnect path in between them.
> 
> The API is using a consumer/provider-based model, where the providers are
> the interconnect controllers and the consumers could be various drivers.
> The consumers request interconnect resources (path) to an endpoint and set
> the desired constraints on this data flow path. The provider(s) receive
> requests from consumers and aggregate these requests for all master-slave
> pairs on that path. Then the providers configure each participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
> 
> Below is a simplified diagram of a real-world SoC topology. The interconnect
> providers are the memory front-end and the NoCs.
> 
> ++++
> | HW Accelerator |--->|  M NoC |<---+
> ++++|
> |  |++
>   +-+  V   +--+ ||
>   |++  | PCIe | ||
>   || Slaves |  +--+ ||
>   |++ | |   C NoC|
>   V   V ||
> +--+   ++   ||   +-+
> |  |-->||-->||-->| CPU |
> |  |-->||<--||   +-+
> |  Memory  |   | S NoC  |   ++
> |  |<--||-+|
> |  |<--||<--+ ||   ++
> +--+   ++   | |+-->| Slaves |
>^ ^^   ^ | |++
>| ||   | | V
> +-+  |  +-++-+  +-+   ++   ++
> | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| Slaves |
> +-+  |  +-++-+  +-+   ++   ++
>  |
>  +---+
>  | Modem |
>  +---+
> 
> This RFC does not implement all features but only main skeleton to check the
> validity of the proposal. Currently it only works with device-tree and 
> platform
> devices.
> 
> TODO:
>  * Constraints are currently stored in internal data structure. Should PM QoS
>  be used instead?
>  * Rework the framework to not depend on DT as frameworks cannot be tied
>  directly to firmware interfaces. Add support for ACPI?

I would start without DT even. You can always have the data you need in 
the kernel. This will be more flexible as you're not defining an ABI as 
this evolves. I think it will take some time to have consensus on how to 
represent the bus master view of buses/interconnects (It's been 
attempted before). 

Rob

[PATCH v7 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

[Wei Wang]

Take over this work from Liang.

This patch series implements two optimizations: 1) transfer pages in chuncks
between the guest and host; 1) transfer the guest unused pages to the host so
that they can be skipped to migrate in live migration.

Please check patch 0003 for more details about optimization 1).

For an idle guest with 8GB RAM, optimization 2) can help shorten the total live
migration time from 2Sec to about 500ms in 10Gbps network
environment. For a guest with quite a lot of page cache and little
unused pages, it's possible to let the guest drop its page cache before
live migration, this case can benefit from this new feature too.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
Cc: Dave Hansen 
Cc: Andrea Arcangeli 
Cc: David Hildenbrand 
Cc: Liang Li 
Cc: Wei Wang 

Liang Li (5):
  virtio-balloon: rework deflate to add page to a list
  virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER
  virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
  virtio-balloon: define flags and head for host request vq
  This patch contains two parts:

 drivers/virtio/virtio_balloon.c | 510 
 include/linux/mm.h  |   3 +
 include/uapi/linux/virtio_balloon.h |  34 +++
 mm/page_alloc.c | 120 +
 4 files changed, 620 insertions(+), 47 deletions(-)

-- 
2.7.4

[PATCH v7 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

[Wei Wang]

Take over this work from Liang.

This patch series implements two optimizations: 1) transfer pages in chuncks
between the guest and host; 1) transfer the guest unused pages to the host so
that they can be skipped to migrate in live migration.

Please check patch 0003 for more details about optimization 1).

For an idle guest with 8GB RAM, optimization 2) can help shorten the total live
migration time from 2Sec to about 500ms in 10Gbps network
environment. For a guest with quite a lot of page cache and little
unused pages, it's possible to let the guest drop its page cache before
live migration, this case can benefit from this new feature too.

Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Cornelia Huck 
Cc: Amit Shah 
Cc: Dave Hansen 
Cc: Andrea Arcangeli 
Cc: David Hildenbrand 
Cc: Liang Li 
Cc: Wei Wang 

Liang Li (5):
  virtio-balloon: rework deflate to add page to a list
  virtio-balloon: VIRTIO_BALLOON_F_CHUNK_TRANSFER
  virtio-balloon: implementation of VIRTIO_BALLOON_F_CHUNK_TRANSFER
  virtio-balloon: define flags and head for host request vq
  This patch contains two parts:

 drivers/virtio/virtio_balloon.c | 510 
 include/linux/mm.h  |   3 +
 include/uapi/linux/virtio_balloon.h |  34 +++
 mm/page_alloc.c | 120 +
 4 files changed, 620 insertions(+), 47 deletions(-)

-- 
2.7.4

Re: [PATCH] PM / OPP: Documentation: Fix opp-microvolt in examples

[Rob Herring]

On Wed, Mar 01, 2017 at 04:39:55PM +0530, Viresh Kumar wrote:
> The triplet present in "opp-microvolt" property should be in the order
> , while all the examples have it in the order
> .
> 
> Fix it.
> 
> Luckily all of the users of "opp-microvolt" property have applied brain
> instead of copying the examples from documentation and none of the
> actual dts files have it wrong.
> 
> Reported-by: Rob Herring 
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 44 
> +--
>  1 file changed, 22 insertions(+), 22 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections

[Viresh Kumar]

On 02-03-17, 15:45, Patrick Bellasi wrote:
> In system where multiple CPUs shares the same frequency domain a small
> workload on a CPU can still be subject frequency spikes, generated by
> the activation of the sugov's kthread.
> 
> Since the sugov kthread is a special RT task, which goal is just that to
> activate a frequency transition, it does not make sense for it to bias
> the schedutil's frequency selection.
> 
> This patch exploits the information related to the current task to silently
> ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
> the sugov kthread is running.
> 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 084a98b..a3fe5e4 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -274,6 +274,8 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  {
>   struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, 
> update_util);
>   struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> + unsigned int cpu = smp_processor_id();
> + struct task_struct *curr = cpu_curr(cpu);

Maybe merge these two as you have done in the next patch.

>   unsigned long util, max;
>   unsigned int next_f;
>  
> @@ -287,6 +289,10 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   goto done;
>   }
>  
> + /* Skip updates generated by sugov kthreads */
> + if (curr == sg_policy->thread)
> + goto done;
> +

I always wanted to avoid such hacks when I moved to the RT thread :(

I was discussing the exact same problem with Vincent few days back and
one of the ideas we had was to clear the flags when any RT task is
dequeued from a rq. AFAIU, the problem we are discussing here
shouldn't normally occur while the sugov RT thread is running as the
work_in_progress flag makes sure we don't reevaluate the load while
the RT thread is updating the frequency. The problem perhaps occurs as
the flag for CPU X is never cleared, and so on the next callback from
the scheduler (after the frequency is updated and work_in_progress is
cleared) we move to the highest frequency.

So what about clearing the flags, just like the previous patch, when
the RT or DL task has finished?

Sorry for the noise if it was all nonsense :)

-- 
viresh

Re: [PATCH] PM / OPP: Documentation: Fix opp-microvolt in examples

[Rob Herring]

On Wed, Mar 01, 2017 at 04:39:55PM +0530, Viresh Kumar wrote:
> The triplet present in "opp-microvolt" property should be in the order
> , while all the examples have it in the order
> .
> 
> Fix it.
> 
> Luckily all of the users of "opp-microvolt" property have applied brain
> instead of copying the examples from documentation and none of the
> actual dts files have it wrong.
> 
> Reported-by: Rob Herring 
> Signed-off-by: Viresh Kumar 
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 44 
> +--
>  1 file changed, 22 insertions(+), 22 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections

[Viresh Kumar]

On 02-03-17, 15:45, Patrick Bellasi wrote:
> In system where multiple CPUs shares the same frequency domain a small
> workload on a CPU can still be subject frequency spikes, generated by
> the activation of the sugov's kthread.
> 
> Since the sugov kthread is a special RT task, which goal is just that to
> activate a frequency transition, it does not make sense for it to bias
> the schedutil's frequency selection.
> 
> This patch exploits the information related to the current task to silently
> ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while
> the sugov kthread is running.
> 
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 084a98b..a3fe5e4 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -274,6 +274,8 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>  {
>   struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, 
> update_util);
>   struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> + unsigned int cpu = smp_processor_id();
> + struct task_struct *curr = cpu_curr(cpu);

Maybe merge these two as you have done in the next patch.

>   unsigned long util, max;
>   unsigned int next_f;
>  
> @@ -287,6 +289,10 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
>   goto done;
>   }
>  
> + /* Skip updates generated by sugov kthreads */
> + if (curr == sg_policy->thread)
> + goto done;
> +

I always wanted to avoid such hacks when I moved to the RT thread :(

I was discussing the exact same problem with Vincent few days back and
one of the ideas we had was to clear the flags when any RT task is
dequeued from a rq. AFAIU, the problem we are discussing here
shouldn't normally occur while the sugov RT thread is running as the
work_in_progress flag makes sure we don't reevaluate the load while
the RT thread is updating the frequency. The problem perhaps occurs as
the flag for CPU X is never cleared, and so on the next callback from
the scheduler (after the frequency is updated and work_in_progress is
cleared) we move to the highest frequency.

So what about clearing the flags, just like the previous patch, when
the RT or DL task has finished?

Sorry for the noise if it was all nonsense :)

-- 
viresh

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

[Namhyung Kim]

Hi Peter,

On Wed, Mar 01, 2017 at 04:07:46PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote:
> 
> > It's a kind of user experience issue.  We provide the asm-only and
> > asm+source annotation, and I think it'd be nice to add source-only
> > option.  And I remember that it was requested some time ago..
> 
> Thing is, an optimizing compiler -- that same beast that ensures your
> objdump -S output is such a garbled mess -- can generate code that
> becomes very hard to relate to the original source code.

I understand that.  Maybe it's not 100% accurate, but it still has
valuable information.  And I think the source-only view can give more
readable outputs using the info.  Also I guess many developers already
aware of the effect of optimizing compilers.

> 
> I'm really sceptical the source line only view is very useful; maybe if
> you build with -O0, but then, if you do that you're not bothered with
> performance.

Even with an optimizing compiler, it can be helpful to overview which
parts of the code are bottlenecks IMHO.  After that, one can see the
asm to identify the problem deeply, if needed.

Thanks,
Namhyung

RE: [PATCH v2] staging: mkspec: added aarch64 ifarch case.

[James Tau]

Hi Will,

This patch (http://lkml.kernel.org/r/20161122213434.14788-1-mma...@suse.com) 
looks better.  It has what Linus calls "good taste". ;-)  I didn't see it in 
mmarek's kbuild branches (for-next,rc-fixes), however.  Still making its way 
there?

But it doesn't quite fix the native 'make rpm' build completely.  While it gets 
beyond the point at which 'make rpm' fails without my patch, it exposes another 
issue for which I am debugging right now:

  ld -EL -r  -T ./scripts/module-common.lds --build-id  -o net/unix/unix.ko 
net/unix/unix.o net/unix/unix.mod.o ;  true
make -f ./scripts/Makefile.fwinst obj=firmware __fw_modbuild
error: Bad exit status from /var/tmp/rpm-tmp.YcfiLf (%build)
Bad exit status from /var/tmp/rpm-tmp.YcfiLf (%build)

RPM build errors:
make[1]: *** [rpm] Error 1
make: *** [rpm] Error 2
  
If I succeed in root-causing the problem, I'll submit a patch for that (if 
another doesn't beat me to it).  And assuming that patch is accepted for having 
Linusian "good taste", then it, and 
http://lkml.kernel.org/r/20161122213434.14788-1-mma...@suse.com, will make my 
current submitted patch extraneous.

Thanks,
James

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com] 
Sent: Wednesday, March 1, 2017 11:06 PM
To: James Tau 
Cc: linux-kernel@vger.kernel.org; linux-kbu...@vger.kernel.org; 
mma...@suse.com; catalin.mari...@arm.com; Chris Metcalf 
Subject: Re: [PATCH v2] staging: mkspec: added aarch64 ifarch case.

On Wed, Mar 01, 2017 at 09:24:14AM -0800, James Tau wrote:
> Patch attempting to fix native 'make rpm' build on ARM64 machines by 
> adding an "ifarch aarch64" case.  Without it, build fails because the 
> 'cp ...' in the default case can't find the built image.
> 
> Signed-off-by: James Tau 
> ---
>  scripts/package/mkspec | 4 
>  1 file changed, 4 insertions(+)

Is this the same issue that was fixed by:

http://lkml.kernel.org/r/20161122213434.14788-1-mma...@suse.com

?

I was assuming that Michael was going to queue those, but I could be wrong.

Will