Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

2017-07-20 Thread Kees Cook
On Thu, Jul 20, 2017 at 6:59 PM, Ye Xiaolong  wrote:
> On 07/19, Linus Torvalds wrote:
>>Hmm. I wonder why the kernel test robot ends up having that annoying
>>line doubling for the dmesg.
>>
>
> Hmm, this line doubling issue should be caused by we set both
> 'earlyprintk=ttyS0,115200' and 'console=ttyS0,115200' in cmdline, after I
> remove any of it, this issue is gone, is it an inappropriate setting?

This is a weird behavior. Normally the boot console (in this case
"earlyser0") should be disabled when the regular console starts. In
your dmesg I see:

[0.00] bootconsole [earlyser0] enabled
...
[0.00] console [ttyS0] enabled
[0.00] console [ttyS0] enabled

This is where repeating starts, and I would have expected to see:

[0.00] bootconsole [earlyser0] enabled
...
[0.00] console [ttyS0] enabled
[0.00] console [ttyS0] enabled
[0.00] bootconsole [earlyser0] disabled
[0.00] bootconsole [earlyser0] disabled

And that would be the end of doubling.

Actually, with your command-line ("earlyprintk=ttyS0,115200
console=ttyS0,115200 console=tty0") I would expect:

[0.00] console [tty0] enabled
[0.00] bootconsole [earlyser0] disabled
[0.00] console [ttyS0] enabled

I don't see any mention of tty0, though. I wonder if that is confusing
the disable code. The only way I would normally expect the boot
console not to get unregistered is if ",keep" was appended to it...
The code is in kernel/printk/printk.c, FWIW.

Also, it looks like your kernel command line is cut off:

... earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 vga=

With your script showing "... vga=normal ..."

That's only 968 characters, well shy of x86's 2048 limit. Is this a
line length issue with qemu output, or does /proc/cmdline report the
same truncation?

-Kees

-- 
Kees Cook
Pixel Security


[PATCH v1] crypto: brcm - Support more FlexRM rings than SPU engines.

2017-07-20 Thread Raveendra Padasalagi
Enhance code to generically support cases where DMA rings
are greater than or equal to number of SPU engines.
New hardware has underlying DMA engine-FlexRM with 32 rings
which can be used to communicate to any of the available
10 SPU engines.

Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
Signed-off-by: Raveendra Padasalagi 
Reviewed-by: Scott Branden 
Reviewed-by: Florian Fainelli 
Cc: sta...@vger.kernel.org
---

Changes in v1:
  - Added error path to clean up mbox channel in spu_mb_init() in case
mbox channel request fails.
  - Removed spu_reg_vbase[] and used spu->reg_vbase[] array to store
mapped registers.
  - spu_dt_read() modified to improve readability

 drivers/crypto/bcm/cipher.c | 109 
 drivers/crypto/bcm/cipher.h |  13 +++---
 2 files changed, 56 insertions(+), 66 deletions(-)

diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index cc0d5b9..875b507 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -89,8 +89,6 @@
 module_param(aead_pri, int, 0644);
 MODULE_PARM_DESC(aead_pri, "Priority for AEAD algos");
 
-#define MAX_SPUS 16
-
 /* A type 3 BCM header, expected to precede the SPU header for SPU-M.
  * Bits 3 and 4 in the first byte encode the channel number (the dma ringset).
  * 0x60 - ring 0
@@ -119,7 +117,7 @@ static u8 select_channel(void)
 {
u8 chan_idx = atomic_inc_return(_priv.next_chan);
 
-   return chan_idx % iproc_priv.spu.num_spu;
+   return chan_idx % iproc_priv.spu.num_chan;
 }
 
 /**
@@ -4527,8 +4525,13 @@ static void spu_functions_register(struct device *dev,
  */
 static int spu_mb_init(struct device *dev)
 {
-   struct mbox_client *mcl = _priv.mcl[iproc_priv.spu.num_spu];
-   int err;
+   struct mbox_client *mcl = _priv.mcl;
+   int err, i;
+
+   iproc_priv.mbox = devm_kcalloc(dev, iproc_priv.spu.num_chan,
+ sizeof(struct mbox_chan *), GFP_KERNEL);
+   if (!iproc_priv.mbox)
+   return -ENOMEM;
 
mcl->dev = dev;
mcl->tx_block = false;
@@ -4537,25 +4540,33 @@ static int spu_mb_init(struct device *dev)
mcl->rx_callback = spu_rx_callback;
mcl->tx_done = NULL;
 
-   iproc_priv.mbox[iproc_priv.spu.num_spu] =
-   mbox_request_channel(mcl, 0);
-   if (IS_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu])) {
-   err = (int)PTR_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu]);
-   dev_err(dev,
-   "Mbox channel %d request failed with err %d",
-   iproc_priv.spu.num_spu, err);
-   iproc_priv.mbox[iproc_priv.spu.num_spu] = NULL;
-   return err;
+   for (i = 0; i < iproc_priv.spu.num_chan; i++) {
+   iproc_priv.mbox[i] = mbox_request_channel(mcl, i);
+   if (IS_ERR(iproc_priv.mbox[i])) {
+   err = (int)PTR_ERR(iproc_priv.mbox[i]);
+   dev_err(dev,
+   "Mbox channel %d request failed with err %d",
+   i, err);
+   iproc_priv.mbox[i] = NULL;
+   goto free_channels;
+   }
}
 
return 0;
+free_channels:
+   for (i = 0; i < iproc_priv.spu.num_chan; i++) {
+   if (iproc_priv.mbox[i])
+   mbox_free_channel(iproc_priv.mbox[i]);
+   }
+
+   return err;
 }
 
 static void spu_mb_release(struct platform_device *pdev)
 {
int i;
 
-   for (i = 0; i < iproc_priv.spu.num_spu; i++)
+   for (i = 0; i < iproc_priv.spu.num_chan; i++)
mbox_free_channel(iproc_priv.mbox[i]);
 }
 
@@ -4566,7 +4577,7 @@ static void spu_counters_init(void)
 
atomic_set(_priv.session_count, 0);
atomic_set(_priv.stream_count, 0);
-   atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_spu);
+   atomic_set(_priv.next_chan, (int)iproc_priv.spu.num_chan);
atomic64_set(_priv.bytes_in, 0);
atomic64_set(_priv.bytes_out, 0);
for (i = 0; i < SPU_OP_NUM; i++) {
@@ -4808,47 +4819,33 @@ static int spu_dt_read(struct platform_device *pdev)
struct resource *spu_ctrl_regs;
const struct of_device_id *match;
const struct spu_type_subtype *matched_spu_type;
-   void __iomem *spu_reg_vbase[MAX_SPUS];
-   int err;
+   struct device_node *dn = pdev->dev.of_node;
+   int err, i;
+
+   /* Count number of mailbox channels */
+   spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
 
match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
matched_spu_type = match->data;
 
-   if (iproc_priv.spu.num_spu > 1) {
-   /* If this is 2nd or later SPU, make sure it's same type */
-   if ((spu->spu_type != 

[PATCH v2 2/3] staging: lustre: ldlm: constify attribute_group structures.

2017-07-20 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
Changes in v2:
  patch was sent to wrong group.

 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c 
b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
index fff930f..e0c3e5d 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
@@ -926,7 +926,7 @@ static ssize_t 
cancel_unused_locks_before_replay_store(struct kobject *kobj,
NULL,
 };
 
-static struct attribute_group ldlm_attr_group = {
+static const struct attribute_group ldlm_attr_group = {
.attrs = ldlm_attrs,
 };
 
-- 
1.9.1



[PATCH v2 0/3] Constify lustre attribute_group structures.

2017-07-20 Thread Arvind Yadav
ttribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Arvind Yadav (3):
  [PATCH v2 1/3] staging: lustre: constify attribute_group structures.
  [PATCH v2 2/3] staging: lustre: ldlm: constify attribute_group structures.
  [PATCH v2 3/3] staging: lustre: obdclass: linux: constify attribute_group 
structures.

 drivers/staging/lustre/lustre/include/lprocfs_status.h  | 4 ++--
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 2 +-
 drivers/staging/lustre/lustre/lmv/lproc_lmv.c   | 2 +-
 drivers/staging/lustre/lustre/lov/lproc_lov.c   | 2 +-
 drivers/staging/lustre/lustre/mdc/lproc_mdc.c   | 2 +-
 drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 2 +-
 drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c | 2 +-
 drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 2 +-
 drivers/staging/lustre/lustre/osc/lproc_osc.c   | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

--
1.9.1



[PATCH v2 3/3] staging: lustre: obdclass: linux: constify attribute_group structures.

2017-07-20 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
Changes in v2:
  patch was sent to wrong group.

 drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 2 +-
 drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c 
b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 9f5e829..eb88bd9 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -405,7 +405,7 @@ static int obd_device_list_open(struct inode *inode, struct 
file *file)
 struct kobject *lustre_kobj;
 EXPORT_SYMBOL_GPL(lustre_kobj);
 
-static struct attribute_group lustre_attr_group = {
+static const struct attribute_group lustre_attr_group = {
.attrs = lustre_attrs,
 };
 
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c 
b/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
index e6c785a..814334b 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-sysctl.c
@@ -151,7 +151,7 @@ static ssize_t max_dirty_mb_store(struct kobject *kobj, 
struct attribute *attr,
NULL,
 };
 
-static struct attribute_group lustre_attr_group = {
+static const struct attribute_group lustre_attr_group = {
.attrs = lustre_attrs,
 };
 
-- 
1.9.1



[PATCH v2 1/3] staging: lustre: constify attribute_group structures.

2017-07-20 Thread Arvind Yadav
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   9489 992  40   105212919 lustre/lustre/osc/lproc_osc.o
   1289 288   01577 629 lustre/lustre/lmv/lproc_lmv.o
   3794 928  404762129a lustre/lustre/lov/lproc_lov.o
   3802 576  4044181142 lustre/lustre/mdc/lproc_mdc.o

File size After adding 'const':
   textdata bss dec hex filename
   9553 928  40   105212919 lustre/lustre/osc/lproc_osc.o
   1353 224   01577 629 lustre/lustre/lmv/lproc_lmv.o
   3858 864  404762129a lustre/lustre/lov/lproc_lov.o
   3866 512  4044181142 lustre/lustre/mdc/lproc_mdc.o

Signed-off-by: Arvind Yadav 
---
Changes in v2:
  Fix kbuild error: conflicting types for 'lprocfs_obd_setup'.
  By changing protype of 'lprocfs_obd_setup'.

 drivers/staging/lustre/lustre/include/lprocfs_status.h  | 4 ++--
 drivers/staging/lustre/lustre/lmv/lproc_lmv.c   | 2 +-
 drivers/staging/lustre/lustre/lov/lproc_lov.c   | 2 +-
 drivers/staging/lustre/lustre/mdc/lproc_mdc.c   | 2 +-
 drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 2 +-
 drivers/staging/lustre/lustre/osc/lproc_osc.c   | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h 
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index 915283c..9054d37 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -59,7 +59,7 @@ struct lprocfs_vars {
 
 struct lprocfs_static_vars {
struct lprocfs_vars *obd_vars;
-   struct attribute_group *sysfs_vars;
+   const struct attribute_group *sysfs_vars;
 };
 
 /* if we find more consumers this could be generalized */
@@ -468,7 +468,7 @@ struct dentry *ldebugfs_register(const char *name,
 void ldebugfs_remove(struct dentry **entryp);
 
 int lprocfs_obd_setup(struct obd_device *obd, struct lprocfs_vars *list,
- struct attribute_group *attrs);
+ const struct attribute_group *attrs);
 int lprocfs_obd_cleanup(struct obd_device *obd);
 
 int ldebugfs_seq_create(struct dentry *parent,
diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c 
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index bf25f88..4c13e39 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -161,7 +161,7 @@ static int lmv_target_seq_open(struct inode *inode, struct 
file *file)
NULL,
 };
 
-static struct attribute_group lmv_attr_group = {
+static const struct attribute_group lmv_attr_group = {
.attrs = lmv_attrs,
 };
 
diff --git a/drivers/staging/lustre/lustre/lov/lproc_lov.c 
b/drivers/staging/lustre/lustre/lov/lproc_lov.c
index eb6d30d..ce46821 100644
--- a/drivers/staging/lustre/lustre/lov/lproc_lov.c
+++ b/drivers/staging/lustre/lustre/lov/lproc_lov.c
@@ -279,7 +279,7 @@ static int lov_target_seq_open(struct inode *inode, struct 
file *file)
NULL,
 };
 
-static struct attribute_group lov_attr_group = {
+static const struct attribute_group lov_attr_group = {
.attrs = lov_attrs,
 };
 
diff --git a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c 
b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
index 9021c46..9fea535 100644
--- a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
+++ b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
@@ -219,7 +219,7 @@ static ssize_t max_pages_per_rpc_show(struct kobject *kobj,
NULL,
 };
 
-static struct attribute_group mdc_attr_group = {
+static const struct attribute_group mdc_attr_group = {
.attrs = mdc_attrs,
 };
 
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c 
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index bc19f19..ba41983 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -1031,7 +1031,7 @@ static void obd_sysfs_release(struct kobject *kobj)
 };
 
 int lprocfs_obd_setup(struct obd_device *obd, struct lprocfs_vars *list,
- struct attribute_group *attrs)
+ const struct attribute_group *attrs)
 {
int rc = 0;
 
diff --git a/drivers/staging/lustre/lustre/osc/lproc_osc.c 
b/drivers/staging/lustre/lustre/osc/lproc_osc.c
index 86f252d..6e0fd15 100644
--- a/drivers/staging/lustre/lustre/osc/lproc_osc.c
+++ b/drivers/staging/lustre/lustre/osc/lproc_osc.c
@@ -831,7 +831,7 @@ int lproc_osc_attach_seqstat(struct obd_device *dev)
NULL,
 };
 
-static struct attribute_group osc_attr_group = {
+static const struct attribute_group osc_attr_group = {
.attrs 

Re: [PATCH] driver core: restrict buffer length in online_store()

2017-07-20 Thread Greg KH
On Fri, Jul 21, 2017 at 08:39:04AM +0800, Tiezhu Yang wrote:
> According to Documentation/ABI/testing/sysfs-devices-online, in order to
> control CPU N's hotplug state, we should write one of 'Yy1Nn0' to the file
> /sys/devices/system/cpu/cpuN/online, other values should be invalid. so the
> buffer length should be 2, buf[0] is one of 'Yy1Nn0' and buf[1] is '\n'.
> 
> without patch:
> [root@localhost home]# echo 0test > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 0
> [root@localhost home]# echo 1test > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 1
> [root@localhost home]# echo ntest > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 0
> [root@localhost home]# echo ytest > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 1
> [root@localhost home]# echo Ntest > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 0
> [root@localhost home]# echo Ytest > /sys/devices/system/cpu/cpu1/online
> [root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
> 1
> 
> with patch:
> [root@localhost home]# echo 0test > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> [root@localhost home]# echo 1test > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> [root@localhost home]# echo ntest > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> [root@localhost home]# echo ytest > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> [root@localhost home]# echo Ntest > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> [root@localhost home]# echo Ytest > /sys/devices/system/cpu/cpu1/online
> bash: echo: write error: Invalid argument
> 
> Signed-off-by: Tiezhu Yang 
> ---
>  drivers/base/core.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 755451f..6588ed5 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1005,6 +1005,12 @@ static ssize_t online_store(struct device *dev, struct 
> device_attribute *attr,
>   bool val;
>   int ret;
>  
> + /* According to Documentation/ABI/testing/sysfs-devices-online,
> +  * the buf length should be 2, buf[0]: one of 'Yy1Nn0', buf[1]: '\n'.
> +  */
> + if (strlen(buf) != 2)
> + return -EINVAL;
> +
>   ret = strtobool(buf, );

strtobool should handle all of this, so let's not force every individual
user of it to check the "length".

What is the problem that this patch is trying to solve?  Who is writing
odd values to this file that is not working properly?  Who writes
"0testfoo" to the file and expect it to reject the value?

thanks,

greg k-h


[PATCH] perf tool sort: Use default sort if evlist is empty

2017-07-20 Thread David Carrillo-Cisneros
Fixes bug noted by Jiri in https://lkml.org/lkml/2017/6/13/755 and caused
by commit d49dadea7862 ("perf tools: Make 'trace' or 'trace_fields' sort
   key default for tracepoint events")
not taking into account that evlist is empty in pipe-mode.

Before this commit, pipe mode will only show bogus "100.00%  N/A" instead
of correct output as follows:

  $ perf record -o - sleep 1 | perf report -i -
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.000 MB - ]
  #
  # Total Lost Samples: 0
  #
  # Samples: 8  of event 'cycles:ppH'
  # Event count (approx.): 145658
  #
  # Overhead  Trace output
  #   
  #
 100.00%  N/A

Correct output, after patch:

  $ perf record -o - sleep 1 | perf report -i -
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.000 MB - ]
  #
  # Total Lost Samples: 0
  #
  # Samples: 8  of event 'cycles:ppH'
  # Event count (approx.): 191331
  #
  # Overhead  Command  Shared Object  Symbol
  #   ...  .  .
  #
  81.63%  sleeplibc-2.19.so   [.] _exit
  13.58%  sleepld-2.19.so [.] do_lookup_x
   2.34%  sleep[kernel.kallsyms]  [k] context_switch
   2.34%  sleeplibc-2.19.so   [.] __GI___libc_nanosleep
   0.11%  perf [kernel.kallsyms]  [k] __intel_pmu_enable_a

Signed-off-by: David Carrillo-Cisneros 
---
 tools/perf/util/evlist.h | 5 +
 tools/perf/util/sort.c   | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 0843746bc389..bf2c4936e35f 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -265,6 +265,11 @@ bool perf_evlist__valid_read_format(struct perf_evlist 
*evlist);
 void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
   struct list_head *list);
 
+static inline bool perf_evlist__empty(struct perf_evlist *evlist)
+{
+   return list_empty(>entries);
+}
+
 static inline struct perf_evsel *perf_evlist__first(struct perf_evlist *evlist)
 {
return list_entry(evlist->entries.next, struct perf_evsel, node);
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 8b327c955a4f..12359bd986db 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2563,7 +2563,7 @@ static const char *get_default_sort_order(struct 
perf_evlist *evlist)
 
BUG_ON(sort__mode >= ARRAY_SIZE(default_sort_orders));
 
-   if (evlist == NULL)
+   if (evlist == NULL || perf_evlist__empty(evlist))
goto out_no_evlist;
 
evlist__for_each_entry(evlist, evsel) {
-- 
2.14.0.rc0.284.gd933b75aa4-goog



Re: [PATCH] zsmalloc: zs_page_migrate: not check inuse if migrate_mode is not MIGRATE_ASYNC

2017-07-20 Thread Minchan Kim
Hi Hui,

On Thu, Jul 20, 2017 at 05:33:45PM +0800, Hui Zhu wrote:

< snip >

> >> >> +++ b/mm/zsmalloc.c
> >> >> @@ -1982,6 +1982,7 @@ int zs_page_migrate(struct address_space 
> >> >> *mapping, struct page *newpage,
> >> >>   unsigned long old_obj, new_obj;
> >> >>   unsigned int obj_idx;
> >> >>   int ret = -EAGAIN;
> >> >> + int inuse;
> >> >>
> >> >>   VM_BUG_ON_PAGE(!PageMovable(page), page);
> >> >>   VM_BUG_ON_PAGE(!PageIsolated(page), page);
> >> >> @@ -1996,21 +1997,24 @@ int zs_page_migrate(struct address_space 
> >> >> *mapping, struct page *newpage,
> >> >>   offset = get_first_obj_offset(page);
> >> >>
> >> >>   spin_lock(>lock);
> >> >> - if (!get_zspage_inuse(zspage)) {
> >> >> + inuse = get_zspage_inuse(zspage);
> >> >> + if (mode == MIGRATE_ASYNC && !inuse) {
> >> >>   ret = -EBUSY;
> >> >>   goto unlock_class;
> >> >>   }
> >> >>
> >> >>   pos = offset;
> >> >>   s_addr = kmap_atomic(page);
> >> >> - while (pos < PAGE_SIZE) {
> >> >> - head = obj_to_head(page, s_addr + pos);
> >> >> - if (head & OBJ_ALLOCATED_TAG) {
> >> >> - handle = head & ~OBJ_ALLOCATED_TAG;
> >> >> - if (!trypin_tag(handle))
> >> >> - goto unpin_objects;
> >> >> + if (inuse) {
> >
> > I don't want to add inuse check for every loop. It might avoid unncessary
> > looping in every loop of zs_page_migrate so it is for optimization, not
> > correction. As I consider it would happen rarely, I think we don't need
> > to add the check. Could you just remove get_zspage_inuse check, instead?
> >
> > like this.
> >
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 013eea76685e..2d3d75fb0f16 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1980,14 +1980,9 @@ int zs_page_migrate(struct address_space *mapping, 
> > struct page *newpage,
> > pool = mapping->private_data;
> > class = pool->size_class[class_idx];
> > offset = get_first_obj_offset(page);
> > +   pos = offset;
> >
> > spin_lock(>lock);
> > -   if (!get_zspage_inuse(zspage)) {
> > -   ret = -EBUSY;
> > -   goto unlock_class;
> > -   }
> > -
> > -   pos = offset;
> > s_addr = kmap_atomic(page);
> > while (pos < PAGE_SIZE) {
> > head = obj_to_head(page, s_addr + pos);
> >
> >
> 
> What about set pos to avoid the loops?
> 
> @@ -1997,8 +1997,10 @@ int zs_page_migrate(struct address_space
> *mapping, struct page *newpage,
> 
> spin_lock(>lock);
> if (!get_zspage_inuse(zspage)) {
> -   ret = -EBUSY;
> -   goto unlock_class;
> +   /* The page is empty.
> +  Set "offset" to the end of page.
> +  Then the loops of page will be avoided.  */
> +   offset = PAGE_SIZE;

Good idea. Just a nitpick:

/*
 * set "offset" to end of the page so that every loops
 * skips unnecessary object scanning.
 */

Thanks!


Re: [PATCH] net: ethernet: ti: cpsw: Push the request_irq function to the end of probe

2017-07-20 Thread Keerthy


On Friday 21 July 2017 04:14 AM, Grygorii Strashko wrote:
> 
> 
> On 07/20/2017 05:28 PM, David Miller wrote:
>> From: Grygorii Strashko 
>> Date: Thu, 20 Jul 2017 11:08:09 -0500
>>
>>> In general patch looks good to me, but it's really unexpected to
>>> receive IRQs while CPSW is probing ;(
>>
>> This is a poor expectation.
>>
>> Boot loaders and other entities can leave the device in any state
>> whatsoever.
>>
>> Furthermore, enabling an IRQ whose handler cannot properly execute
>> without crashing is wrong fundamentally.  All data structures and
>> state must be set up properly before the IRQ is requested.
>>
>> Therefore this patch is correct and I will apply it.
>>
> 
> Thanks. Agree (it just has never triggered before, so I meant - unexpected
>  from current driver code point of view ;().
> And I'm just worry that it might not be enough :(, especially for am335x.

I tried nfs boot on am335x-evm with this patch and it boots fine for me.

> 


[git pull] drm fixes for 4.13-rc2

2017-07-20 Thread Dave Airlie
Hi Linus,

A bunch of fixes for rc2, two imx regressions, vc4 fix, dma-buf fix,
some displayport mst fixes, and an amdkfd fix.

Nothing too crazy, I assume we just haven't see much rc1 testing yet.

Dave.

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc2

for you to fetch changes up to 5896ec77d70d33dd38a455b0aa5f3154aeecea09:

  Merge tag 'imx-drm-fixes-2017-07-18' of
git://git.pengutronix.de/git/pza/linux into drm-fixes (2017-07-21
14:04:44 +1000)


imx, misc and amdkfd fixes


Boris Brezillon (1):
  drm/vc4: Fix VBLANK handling in crtc->enable() path

Chris Wilson (1):
  dma-buf/fence: Avoid use of uninitialised timestamp

Dave Airlie (3):
  Merge tag 'drm-amdkfd-fixes-2017-07-18' of
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-07-20' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'imx-drm-fixes-2017-07-18' of
git://git.pengutronix.de/git/pza/linux into drm-fixes

Imre Deak (3):
  drm/mst: Fix error handling during MST sideband message reception
  drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()
  drm/mst: Avoid processing partially received up/down message transactions

Jay Cornwall (4):
  drm/amdgpu: Fix KFD oversubscription by tracking queues correctly
  drm/amdkfd: Remove unused references to shared_resources.num_mec
  drm/radeon: Remove initialization of shared_resources.num_mec
  drm/amdgpu: Remove unused field kgd2kfd_shared_resources.num_mec

Laurentiu Palcu (1):
  drm/imx: fix typo in ipu_plane_formats[]

Philipp Zabel (1):
  drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failure

Sean Paul (1):
  Merge branch 'drm-misc-next-fixes' into drm-misc-fixes

 drivers/dma-buf/dma-fence.c| 17 ++
 drivers/dma-buf/sync_debug.c   |  2 +-
 drivers/dma-buf/sync_file.c|  8 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  3 +-
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  4 --
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  7 ---
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  1 -
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|  3 -
 drivers/gpu/drm/drm_dp_mst_topology.c  | 41 +++---
 drivers/gpu/drm/imx/ipuv3-plane.c  |  2 +-
 drivers/gpu/drm/imx/parallel-display.c |  2 +-
 drivers/gpu/drm/radeon/radeon_kfd.c|  1 -
 drivers/gpu/drm/vc4/vc4_crtc.c | 66 ++
 include/linux/dma-fence.h  |  2 +
 14 files changed, 95 insertions(+), 64 deletions(-)


Re: [PATCH] efifb: allow user to disable write combined mapping.

2017-07-20 Thread Dave Airlie
On 20 July 2017 at 14:44, Linus Torvalds  wrote:
> On Wed, Jul 19, 2017 at 9:28 PM, Andy Lutomirski  wrote:
>>
>> It shouldn't be that hard to hack up efifb to allocate some actual RAM
>> as "framebuffer", unmap it from the direct map, and ioremap_wc() it as
>> usual.  Then you could see if PCIe is important for it.
>
> The thing is, the "actual RAM" case is unlikely to show this issue.
>
> RAM is special, even when you try to mark it WC or whatever. Yes, it
> might be slowed down by lack of caching, but the uncore still *knows*
> it is RAM. The accesses go to the memory controller, not the PCI side.
>
>> WC streaming writes over PCIe end up doing 64 byte writes, right?
>> Maybe the Matrox chip is just extremely slow handling 64b writes.
>
> .. or maybe there is some unholy "management logic" thing that catches
> those writes, because this is server hardware, and server vendors
> invariably add "value add" (read; shit) to their hardware to justify
> the high price.
>
> Like the Intel "management console" that was such a "security feature".
>
> I think one of the points of those magic graphics cards is that you
> can export the frame buffer over the management network, so that you
> can still run the graphical Windows GUI management stuff. Because you
> wouldn't want to just ssh into it and run command line stuff.
>
> So I wouldn't be surprised at all if the thing has a special back
> channel to the network chip with a queue of changes going over
> ethernet or something, and then when you stream things at high speeds
> to the GPU DRAM, you fill up the management bandwidth.
>
> If it was actual framebuffer DRAM, I would expect it to be *happy*
> with streaming 64-bit writes. But some special "management interface
> ASIC" that tries to keep track of GPU framebuffer "damage" might be
> something else altogether.
>

I think it's just some RAM on the management console device that is
partitioned and exposed via the PCI BAR on the mga vga device.

I expect it possibly can't handle lots of writes very well and sends something
back that causes the stalls. I'm not even sure how to prove it.

So I expect we should at least land this patch for now so people who do suffer
from this can at least disable it for now, and if we can narrow it
down to a pci id
or subsys id for certain HP ilo devices, then we can add a blacklist.

I wonder if anyone knows anyone from HPE ilo team.

Dave.


Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu

2017-07-20 Thread Vijay Kumar


On 7/20/2017 10:45 PM, David Miller wrote:

From: Vijay Kumar 
Date: Thu, 20 Jul 2017 22:36:42 -0500


I can give a try :). But looks to me one thing that will go wrong is
irq accounting done in __irq_enter() and rcu_irq_enter().

Actually, the bigger problem is that scheduler_ipi() can raise a
software interrupt, and nothing will invoke it.

Yes, I see your point.


It's turning quite ugly to avoid the IRQ overhead, I must admit.
So ignore this for now.

In the longer term a probably cleaner way to do this is to have
a special direct version of scheduler_ipi() that invokes all the
necessary work, even the rebalance softirq, directly rather than
indirectly.


Sure. Thanks.



Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

2017-07-20 Thread Viresh Kumar
On 20-07-17, 12:49, Joel Fernandes wrote:
> Yes I think that's fine, I thought about it some more and I think this
> can be an issue in a scenario where
> 
> iowait_boost_max < policy->min  but:

We will never have this case as boost-max is set to cpuinfo.max_freq.

-- 
viresh


linux-next: Tree for Jul 21

2017-07-20 Thread Stephen Rothwell
Hi all,

Changes since 20170720:

The kbuild tree still produces a large number of build warnings so I
reverted a commit from it.

The drm tree gained a conflict against the drm-intel-fixes tree.

The userns tree lost its build failure.

Non-merge commits (relative to Linus' tree): 2018
 2161 files changed, 82061 insertions(+), 39649 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (63a86362130f Merge tag 'pm-4.13-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (029d9252b116 powerpc/mm: Mark __init memory 
no-execute when STRICT_KERNEL_RWX=y)
Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of 
full_name)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (cbf5ecb30560 net: bonding: Fix transmit load balancing in 
balance-alb mode)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (36ac344e16e0 netfilter: expect: fix crash when 
putting uninited expectation)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (610e1ae9b533 ALSA: fm801: Initialize chip 
after IRQ handler is registered)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (c6325179238f tty: Fix TIOCGPTPEER ioctl 
definition)
Merging usb.current/usb-linus (d6f5f071f1e1 xhci: fix memleak in xhci_run())
Merging usb-gadget-fixes/fixes (b8b9c974afee usb: renesas_usbhs: gadget: 
disable all eps when the driver stops)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (5a1d4c5dd4eb staging: rtl8188eu: add 
TL-WN722N v2 support)
Merging char-misc.current/char-misc-linus (c89876dda018 w1: omap-hdq: fix error 
return code in omap_hdq_probe())
Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 
buttons when buttons detection fails)
Merging crypto-current/master (41cdf7a45389 crypto: authencesn - Fi

Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]

2017-07-20 Thread Joe Perches
On Thu, 2017-07-20 at 10:57 -0700, Mark Salyzyn wrote:
> It would probably need to take struct timespec64 as an argument. Pass by 
> structure might be difficult to swallow, so pass by pointer?

Every %p extension is passed via a pointer.



[PATCH v4 2/2] ARM: dts: imx: add CX9020 Embedded PC device tree

2017-07-20 Thread linux-kernel-dev
From: Patrick Bruenn 

The CX9020 differs from i.MX53 Quick Start Board by:
- use uart2 instead of uart1
- DVI-D connector instead of VGA
- no audio
- no SATA connector
- CCAT FPGA connected to emi
- enable rtc

Signed-off-by: Patrick Bruenn 

---

v4:
- move alternative UART2 pinmux settings to imx53-pinfunc.h
- fix copyright notice and model name to clearify cx9020 is a
  Beckhoff board and not from Freescale/NXP/Qualcomm
- add "bhf,cx9020" compatible
- remove ccat node and pin configuration as long as the ccat
  driver is not mainlined
- use dvi-connector + ti,tfp410 instead of panel-simple
- add newlines between property list and child nodes
- replace underscores in node names with hypens
- replace magic number 0 with polarity defines from
  include/dt-bindings/gpio/gpio.h
- move rtc node into imx53.dtsi, change it's name into 'srtc',
  to avoid a conflict with 'rtc' node in imx53-m53.dtsi
- rename regulator-3p2v
- drop imx53-qsb container node
- make iomux configuration explicit
- remove unused audmux
- remove unused led_pin_gpio3_23 configuration
- use blue gpio-leds as disk-activity indicators for mmc0 and mmc1
- add mmc indicator leds to sdhc pingroups
- keep node names in alphabetical order
- remove unused sata and ssi2
- remove unused pin configs from hoggrp
- add entry for imx53-cx9020.dts to MAINTAINERS

v3: add missig changelog
v2:
- keep alphabetic order of dts/Makefile
- configure uart2 with 'fsl,dte-mode'
- use display-0 and panel-0 as node names
- remove unnecessary "simple-bus" for fixed regulators

Cc: Andrew Lunn 
---
 MAINTAINERS|   1 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/imx53-cx9020.dts | 295 +
 arch/arm/boot/dts/imx53-pinfunc.h  |   4 +
 arch/arm/boot/dts/imx53.dtsi   |   9 ++
 5 files changed, 310 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx53-cx9020.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index 1bf282843dc2..1bd06328f79b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1176,6 +1176,7 @@ ARM/BECKHOFF SUPPORT
 M: Patrick Bruenn 
 S: Maintained
 F: Documentation/devicetree/bindings/arm/bhf.txt
+F: arch/arm/boot/dts/imx53-cx9020.dts
 
 ARM/CALXEDA HIGHBANK ARCHITECTURE
 M: Rob Herring 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..f0ba9be523e0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -340,6 +340,7 @@ dtb-$(CONFIG_SOC_IMX51) += \
imx51-ts4800.dtb
 dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
+   imx53-cx9020.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-qsb.dtb \
diff --git a/arch/arm/boot/dts/imx53-cx9020.dts 
b/arch/arm/boot/dts/imx53-cx9020.dts
new file mode 100644
index ..c4f9c89668c2
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-cx9020.dts
@@ -0,0 +1,295 @@
+/*
+ * Copyright 2017 Beckhoff Automation GmbH & Co. KG
+ * based on imx53-qsb.dts
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx53.dtsi"
+
+/ {
+   model = "Beckhoff CX9020 Embedded PC";
+   compatible = "bhf,cx9020", "fsl,imx53";
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory {
+   reg = <0x7000 0x2000>,
+ <0xb000 0x2000>;
+   };
+
+   display-0 {
+   #address-cells =<1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx-parallel-display";
+   interface-pix-fmt = "rgb24";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu_disp0>;
+   status = "okay";
+
+   port@0 {
+   reg = <0>;
+
+   display0_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   display0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   dvi-connector {
+   compatible = "dvi-connector";
+   ddc-i2c-bus = <>;
+   digital;
+
+   port {
+   dvi_connector_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   dvi-converter {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "ti,tfp410";
+
+   port@0 {
+   reg = <0>;
+
+   

[PATCH v4 1/2] dt-bindings: arm: Add entry for Beckhoff CX9020

2017-07-20 Thread linux-kernel-dev
From: Patrick Bruenn 

- add vendor prefix bhf for Beckhoff
- add new board binding bhf,cx9020

Signed-off-by: Patrick Bruenn 
---
 Documentation/devicetree/bindings/arm/bhf.txt | 6 ++
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 MAINTAINERS   | 5 +
 3 files changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bhf.txt

diff --git a/Documentation/devicetree/bindings/arm/bhf.txt 
b/Documentation/devicetree/bindings/arm/bhf.txt
new file mode 100644
index ..886b503caf9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bhf.txt
@@ -0,0 +1,6 @@
+Beckhoff Automation Platforms Device Tree Bindings
+--
+
+CX9020 Embedded PC
+Required root node properties:
+- compatible = "bhf,cx9020", "fsl,imx53";
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index daf465bef758..20c2cf57ebc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -47,6 +47,7 @@ avic  Shanghai AVIC Optoelectronics Co., Ltd.
 axentiaAxentia Technologies AB
 axis   Axis Communications AB
 bananapi BIPAI KEJI LIMITED
+bhfBeckhoff Automation GmbH & Co. KG
 boeBOE Technology Group Co., Ltd.
 bosch  Bosch Sensortec GmbH
 boundary   Boundary Devices Inc.
diff --git a/MAINTAINERS b/MAINTAINERS
index 205d3977ac46..1bf282843dc2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1172,6 +1172,11 @@ M:   Boris Brezillon 

 S: Maintained
 F: drivers/clk/at91
 
+ARM/BECKHOFF SUPPORT
+M: Patrick Bruenn 
+S: Maintained
+F: Documentation/devicetree/bindings/arm/bhf.txt
+
 ARM/CALXEDA HIGHBANK ARCHITECTURE
 M: Rob Herring 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
2.11.0




[PATCH 2/3] soc: mediatek: add header files required for MT7622 SCPSYS dt-binding

2017-07-20 Thread sean.wang
From: Chen Zhong 

Add relevant header files required for dt-bindings of SCPSYS power domain
control for all subsystems found on MT7622 SoC.

Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 include/dt-bindings/power/mt7622-power.h | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 include/dt-bindings/power/mt7622-power.h

diff --git a/include/dt-bindings/power/mt7622-power.h 
b/include/dt-bindings/power/mt7622-power.h
new file mode 100644
index 000..1b63926
--- /dev/null
+++ b/include/dt-bindings/power/mt7622-power.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2017 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See http://www.gnu.org/licenses/gpl-2.0.html for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT7622_POWER_H
+#define _DT_BINDINGS_POWER_MT7622_POWER_H
+
+#define MT7622_POWER_DOMAIN_ETHSYS 0
+#define MT7622_POWER_DOMAIN_HIF0   1
+#define MT7622_POWER_DOMAIN_HIF1   2
+#define MT7622_POWER_DOMAIN_WB 3
+
+#endif /* _DT_BINDINGS_POWER_MT7622_POWER_H */
-- 
2.7.4



[PATCH 1/3] dt-bindings: soc: update the binding document for SCPSYS on MediaTek MT7622 SoC

2017-07-20 Thread sean.wang
From: Sean Wang 

Update the binding document for enabling SCPSYS on MediaTek MT7622 SoC.

Signed-off-by: Sean Wang 
Signed-off-by: Chen Zhong 
---
 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index b1d165b..40056f7 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -12,11 +12,13 @@ power/power_domain.txt. It provides the power domains 
defined in
 - include/dt-bindings/power/mt8173-power.h
 - include/dt-bindings/power/mt6797-power.h
 - include/dt-bindings/power/mt2701-power.h
+- include/dt-bindings/power/mt7622-power.h
 
 Required properties:
 - compatible: Should be one of:
- "mediatek,mt2701-scpsys"
- "mediatek,mt6797-scpsys"
+   - "mediatek,mt7622-scpsys"
- "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
@@ -26,6 +28,7 @@ Required properties:
   enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
Required clocks for MT6797: "mm", "mfg", "vdec"
+   Required clocks for MT7622: "hif_sel"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
 
 Optional properties:
-- 
2.7.4



[PATCH 3/3] soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC

2017-07-20 Thread sean.wang
From: Chen Zhong 

Add SCPSYS power domain driver for MT7622 SoC having four power domains
which are respectively ETHSYS for Ethernet including embedded switch,
WBSYS for WIFI and Bluetooth, HIF0SYS for PCI-E and SATA, and HIF1SYS for
USB. Those functions could be selectively powered gated when the
corresponding function is no longer to use in order to reach more minimal
power dissipation.

Signed-off-by: Chen Zhong 
Signed-off-by: Sean Wang 
---
 drivers/soc/mediatek/mtk-scpsys.c | 76 +++
 include/linux/soc/mediatek/infracfg.h |  8 +++-
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index beb7916..8a0ca02 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -38,6 +39,11 @@
 #define SPM_MFG_2D_PWR_CON 0x02c0
 #define SPM_MFG_ASYNC_PWR_CON  0x02c4
 #define SPM_USB_PWR_CON0x02cc
+#define SPM_ETHSYS_PWR_CON 0x02e0  /* MT7622 */
+#define SPM_HIF0_PWR_CON   0x02e4  /* MT7622 */
+#define SPM_HIF1_PWR_CON   0x02e8  /* MT7622 */
+#define SPM_WB_PWR_CON 0x02ec  /* MT7622 */
+
 
 #define SPM_PWR_STATUS 0x060c
 #define SPM_PWR_STATUS_2ND 0x0610
@@ -63,6 +69,10 @@
 #define PWR_STATUS_MFG_ASYNC   BIT(23)
 #define PWR_STATUS_AUDIO   BIT(24)
 #define PWR_STATUS_USB BIT(25)
+#define PWR_STATUS_ETHSYS  BIT(24) /* MT7622 */
+#define PWR_STATUS_HIF0BIT(25) /* MT7622 */
+#define PWR_STATUS_HIF1BIT(26) /* MT7622 */
+#define PWR_STATUS_WB  BIT(27) /* MT7622 */
 
 enum clk_id {
CLK_NONE,
@@ -71,6 +81,7 @@ enum clk_id {
CLK_VENC,
CLK_VENC_LT,
CLK_ETHIF,
+   CLK_HIFSEL,
CLK_MAX,
 };
 
@@ -81,6 +92,7 @@ static const char * const clk_names[] = {
"venc",
"venc_lt",
"ethif",
+   "hif_sel",
NULL,
 };
 
@@ -567,6 +579,67 @@ static int __init scpsys_probe_mt2701(struct 
platform_device *pdev)
 }
 
 /*
+ * MT7622 power domain support
+ */
+static const struct scp_domain_data scp_domain_data_mt7622[] = {
+   [MT7622_POWER_DOMAIN_ETHSYS] = {
+   .name = "ethsys",
+   .sta_mask = PWR_STATUS_ETHSYS,
+   .ctl_offs = SPM_ETHSYS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_NONE},
+   .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_ETHSYS,
+   .active_wakeup = true,
+   },
+   [MT7622_POWER_DOMAIN_HIF0] = {
+   .name = "hif0",
+   .sta_mask = PWR_STATUS_HIF0,
+   .ctl_offs = SPM_HIF0_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_HIFSEL},
+   .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF0,
+   .active_wakeup = true,
+   },
+   [MT7622_POWER_DOMAIN_HIF1] = {
+   .name = "hif1",
+   .sta_mask = PWR_STATUS_HIF1,
+   .ctl_offs = SPM_HIF1_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_HIFSEL},
+   .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_HIF1,
+   .active_wakeup = true,
+   },
+   [MT7622_POWER_DOMAIN_WB] = {
+   .name = "wb",
+   .sta_mask = PWR_STATUS_WB,
+   .ctl_offs = SPM_WB_PWR_CON,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .clk_id = {CLK_NONE},
+   .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
+   .active_wakeup = true,
+   },
+};
+
+#define NUM_DOMAINS_MT7622 ARRAY_SIZE(scp_domain_data_mt7622)
+
+static int __init scpsys_probe_mt7622(struct platform_device *pdev)
+{
+   struct scp *scp;
+
+   scp = init_scp(pdev, scp_domain_data_mt7622, NUM_DOMAINS_MT7622);
+   if (IS_ERR(scp))
+   return PTR_ERR(scp);
+
+   mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT7622);
+
+   return 0;
+}
+
+/*
  * MT8173 power domain support
  */
 
@@ -698,6 +771,9 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
.compatible = "mediatek,mt2701-scpsys",
.data = scpsys_probe_mt2701,
}, {
+   .compatible = "mediatek,mt7622-scpsys",
+   .data = scpsys_probe_mt7622,
+   }, {
.compatible = "mediatek,mt8173-scpsys",
.data = scpsys_probe_mt8173,
}, {
diff --git 

[PATCH 0/3] add support of SCPSYS power domain for MediaTek MT7622

2017-07-20 Thread sean.wang
From: Sean Wang 

There are four power domains on MediaTek MT7622 SoC which are respectively
ETHSYS for Ethernet including extra embedded switch, HIF0SYS for PCI-E and
SATA, HIF1SYS for USB and WBSYS for WIFI and Bluetooth.

Those functions could be selectively powered gated when the corresponding
function is no longer to use in order to reach more minimal power
dissipation through the patch series introduced here.

Chen Zhong (2):
  soc: mediatek: add header files required for MT7622 SCPSYS dt-binding
  soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC

Sean Wang (1):
  dt-bindings: soc: update the binding document for SCPSYS on MediaTek
MT7622 SoC

 .../devicetree/bindings/soc/mediatek/scpsys.txt|  3 +
 drivers/soc/mediatek/mtk-scpsys.c  | 76 ++
 include/dt-bindings/power/mt7622-power.h   | 22 +++
 include/linux/soc/mediatek/infracfg.h  |  8 ++-
 4 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/power/mt7622-power.h

-- 
2.7.4



Re: [PATCH 2/4] gpio: davinci: Handle the return value of davinci_gpio_irq_setup function

2017-07-20 Thread Keerthy


On Friday 21 July 2017 03:04 AM, Grygorii Strashko wrote:
> 
> 
> On 07/20/2017 05:05 AM, Johan Hovold wrote:
>> On Thu, Jul 20, 2017 at 03:32:27PM +0530, Keerthy wrote:
>>> On Thursday 20 July 2017 03:20 PM, Johan Hovold wrote:
 On Thu, Jul 20, 2017 at 02:40:37PM +0530, Keerthy wrote:
> On Thursday 20 July 2017 12:14 PM, Keerthy wrote:
>> On Wednesday 19 July 2017 04:40 PM, Johan Hovold wrote:
>>
>>> There's a separate but related bug here too as the clk_prepare_enable()
>>> in davinci_gpio_irq_setup() is never balanced on driver unbind.
>>
>> Yes Johan. I will send that as a separate patch.
>
> This is already fixed in the latest kernel:
>
> commit 6dc0048cff988858254fcc26becfc1e9753efa79
> Author: Arvind Yadav 
> Date:   Tue May 23 14:48:57 2017 +0530

 That change only handles errors in davinci_gpio_irq_setup() (i.e. during
 probe) and not the imbalance at driver unbind that I was referring to.
>>>
>>> Okay got it. One more clk_unprepare_disable() call needs to be there in
>>> probe err path.
>>
>> No, you need to balance it on driver unbind, that is, in a new remove()
>> callback.
>>
> 
> Sry, but manual driver unbind for this driver is really smth unexpected ;(
> So, I'm not sure if it need to be implemented and even yes - it should not be
> a part of this patch. Probably, smth like "convert driver to be a module".
> 

The GPIO_DAVINCI config is bool. Thanks for checking on that Grygorii.

> By the way, I've tried to unbind gpio-omap, result - failure (expected),
> as unbind does not take into account module refcnt state.

Okay.

> 
> 


Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

2017-07-20 Thread Dan Williams
On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse  wrote:
> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote:
>> On 2017/7/20 23:03, Jerome Glisse wrote:
>> > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote:
>> >> On 2017/7/19 10:25, Jerome Glisse wrote:
>> >>> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote:
>>  On 2017/7/18 23:38, Jerome Glisse wrote:
>> > On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote:
>> >> On 2017/7/14 5:15, Jérôme Glisse wrote:
>
> [...]
>
>> >> Then it's more like replace the numa node solution(CDM) with ZONE_DEVICE
>> >> (type MEMORY_DEVICE_PUBLIC). But the problem is the same, e.g how to make
>> >> sure the device memory say HBM won't be occupied by normal CPU allocation.
>> >> Things will be more complex if there are multi GPU connected by nvlink
>> >> (also cache coherent) in a system, each GPU has their own HBM.
>> >>
>> >> How to decide allocate physical memory from local HBM/DDR or remote HBM/
>> >> DDR?
>> >>
>> >> If using numa(CDM) approach there are NUMA mempolicy and autonuma 
>> >> mechanism
>> >> at least.
>> >
>> > NUMA is not as easy as you think. First like i said we want the device
>> > memory to be isolated from most existing mm mechanism. Because memory
>> > is unreliable and also because device might need to be able to evict
>> > memory to make contiguous physical memory allocation for graphics.
>> >
>>
>> Right, but we need isolation any way.
>> For hmm-cdm, the isolation is not adding device memory to lru list, and many
>> if (is_device_public_page(page)) ...
>>
>> But how to evict device memory?
>
> What you mean by evict ? Device driver can evict whenever they see the need
> to do so. CPU page fault will evict too. Process exit or munmap() will free
> the device memory.
>
> Are you refering to evict in the sense of memory reclaim under pressure ?
>
> So the way it flows for memory pressure is that if device driver want to
> make room it can evict stuff to system memory and if there is not enough
> system memory than thing get reclaim as usual before device driver can
> make progress on device memory reclaim.
>
>
>> > Second device driver are not integrated that closely within mm and the
>> > scheduler kernel code to allow to efficiently plug in device access
>> > notification to page (ie to update struct page so that numa worker
>> > thread can migrate memory base on accurate informations).
>> >
>> > Third it can be hard to decide who win between CPU and device access
>> > when it comes to updating thing like last CPU id.
>> >
>> > Fourth there is no such thing like device id ie equivalent of CPU id.
>> > If we were to add something the CPU id field in flags of struct page
>> > would not be big enough so this can have repercusion on struct page
>> > size. This is not an easy sell.
>> >
>> > They are other issues i can't think of right now. I think for now it
>>
>> My opinion is most of the issues are the same no matter use CDM or HMM-CDM.
>> I just care about a more complete solution no matter CDM,HMM-CDM or other 
>> ways.
>> HMM or HMM-CDM depends on device driver, but haven't see a public/full 
>> driver to
>> demonstrate the whole solution works fine.
>
> I am working with NVidia close source driver team to make sure that it works
> well for them. I am also working on nouveau open source driver for same NVidia
> hardware thought it will be of less use as what is missing there is a solid
> open source userspace to leverage this. Nonetheless open source driver are in
> the work.

Can you point to the nouveau patches? I still find these HMM patches
un-reviewable without an upstream consumer.


Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu

2017-07-20 Thread David Miller
From: Vijay Kumar 
Date: Thu, 20 Jul 2017 22:36:42 -0500

> I can give a try :). But looks to me one thing that will go wrong is
> irq accounting done in __irq_enter() and rcu_irq_enter().

Actually, the bigger problem is that scheduler_ipi() can raise a
software interrupt, and nothing will invoke it.

It's turning quite ugly to avoid the IRQ overhead, I must admit.
So ignore this for now.

In the longer term a probably cleaner way to do this is to have
a special direct version of scheduler_ipi() that invokes all the
necessary work, even the rebalance softirq, directly rather than
indirectly.


[GIT] IDE

2017-07-20 Thread David Miller

Please pull to get this gcc-7 warning fix from Arnd.

Thanks!

The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 
16:33:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide 

for you to fetch changes up to 921edf312a6a20be16cf2b60e0dec3dce35e5cb9:

  ide: avoid warning for timings calculation (2017-07-21 04:37:22 +0100)


Arnd Bergmann (1):
  ide: avoid warning for timings calculation

 drivers/ide/ide-timings.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)


[PATCH] f2fs: let background GC being aware of freezing

2017-07-20 Thread Chao Yu
When ->freeze_fs is called from lvm for doing snapshot, it needs to
make sure there will be no more changes in filesystem's data, however,
previously, background GC wasn't aware of freezing, so in environment
with active background GC thread, data of snapshot becomes unstable.

This patch fixes this issue by adding sb_{start,end}_intwrite in GC
flow.

Signed-off-by: Chao Yu 
---
 fs/f2fs/gc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 76ad2c3d88db..1c0117f60083 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -55,6 +55,8 @@ static int gc_thread_func(void *data)
}
 #endif
 
+   sb_start_intwrite(sbi->sb);
+
/*
 * [GC triggering condition]
 * 0. GC is not conducted currently.
@@ -69,12 +71,12 @@ static int gc_thread_func(void *data)
 * So, I'd like to wait some time to collect dirty segments.
 */
if (!mutex_trylock(>gc_mutex))
-   continue;
+   goto next;
 
if (!is_idle(sbi)) {
increase_sleep_time(gc_th, _ms);
mutex_unlock(>gc_mutex);
-   continue;
+   goto next;
}
 
if (has_enough_invalid_blocks(sbi))
@@ -93,6 +95,8 @@ static int gc_thread_func(void *data)
 
/* balancing f2fs's metadata periodically */
f2fs_balance_fs_bg(sbi);
+next:
+   sb_end_intwrite(sbi->sb);
 
} while (!kthread_should_stop());
return 0;
-- 
2.13.1.388.g69e6b9b4f4a9



Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu

2017-07-20 Thread Vijay Kumar



On 7/20/2017 9:55 PM, David Miller wrote:

From: Vijay Kumar 
Date: Thu, 20 Jul 2017 21:44:24 -0500


I had same thoughts initially but I had to go with this approach as
scheduler_ipi is wrapped with irq_enter() and irq_exit(). Whereas POKE
resumes the cpu in process context.

Comments in scheduler_ipi():

  * Not all reschedule IPI handlers call irq_enter/irq_exit, since
  * traditionally all their work was done from the interrupt return
  * path. Now that we actually do some work, we need to make sure
  * we do call them.
  *
  * Some archs already do call them, luckily irq_enter/exit nest
  * properly.
  *
  * Arguably we should visit all archs and update all handlers,
  * however a fair share of IPIs are still resched only so this would
  * somewhat pessimize the simple resched case.
  */
 irq_enter();


I still think we should be able to fake the state such that this
direct schedule_ipi() call will work.

I could be wrong :)
I can give a try :). But looks to me one thing that will go wrong is irq 
accounting done in __irq_enter() and rcu_irq_enter().


Thanks,
Vijay



Re: [PATCH 19/32] tracing: Add variable reference handling to hist triggers

2017-07-20 Thread Namhyung Kim
On Mon, Jun 26, 2017 at 05:49:20PM -0500, Tom Zanussi wrote:
> Add the necessary infrastructure to allow the variables defined on one
> event to be referenced in another.  This allows variables set by a
> previous event to be referenced and used in expressions combining the
> variable values saved by that previous event and the event fields of
> the current event.  For example, here's how a latency can be
> calculated and saved into yet another variable named 'wakeup_lat':
> 
> # echo 'hist:keys=pid,prio:ts0=common_timestamp ...
> # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...
> 
> In the first event, the event's timetamp is saved into the variable
> ts0.  In the next line, ts0 is subtracted from the second event's
> timestamp to produce the latency.
> 
> Further users of variable references will be described in subsequent
> patches, such as for instance how the 'wakeup_lat' variable above can
> be displayed in a latency histogram.
> 
> Signed-off-by: Tom Zanussi 
> ---

I think it'd be better spliting this into 3 parts: add hist_elt_data,
pass tracing_map_elt to hist field func and add var ref logic.


[SNIP]
> @@ -241,6 +270,324 @@ static u64 hist_field_timestamp(struct hist_field 
> *hist_field, void *event,
>   return ts;
>  }
>  
> +static LIST_HEAD(hist_var_list);
> +
> +struct hist_var_data {
> + struct list_head list;
> + struct hist_trigger_data *hist_data;
> +};

Hmm.. I'm confused whether this list maintains reference of variable
or defintion (or both?).  It seems an entry is added only by
save_hist_vars() which is for definition.  But find_any_var_ref()
looks it up for references..  What am I missing?

Also I think it'd be better keeping this list for each instance rather
than globally.


[SNIP]
> @@ -2186,10 +2613,32 @@ static void hist_unregister_trigger(char *glob, 
> struct event_trigger_ops *ops,
>   tracing_set_time_stamp_abs(file->tr, false);
>  }
>  
> +static bool hist_file_check_refs(struct trace_event_file *file)
> +{
> + struct hist_trigger_data *hist_data;
> + struct event_trigger_data *test;
> +
> + printk("func: %s\n", __func__);

Please remove this.

Thanks,
Namhyung


> +
> + list_for_each_entry_rcu(test, >triggers, list) {
> + if (test->cmd_ops->trigger_type == ETT_EVENT_HIST) {
> + hist_data = test->private_data;
> + if (check_var_refs(hist_data))
> + return true;
> + break;
> + }
> + }
> +
> + return false;
> +}


RE: [PATCH v2 1/2] platform/x86: Add GLK PSS Event Table

2017-07-20 Thread Chakravarty, Souvik K
Reviewed-by: Souvik K Chakravarty 

> -Original Message-
> From: Bhardwaj, Rajneesh
> Sent: Thursday, July 20, 2017 7:51 PM
> To: platform-driver-...@vger.kernel.org
> Cc: dvh...@infradead.org; a...@infradead.org; linux-
> ker...@vger.kernel.org; Murthy, Shanth ;
> Chakravarty, Souvik K ; Bhardwaj,
> Rajneesh 
> Subject: [PATCH v2 1/2] platform/x86: Add GLK PSS Event Table
> 
> Some of the Primary Subsystem events differ on Gemini Lake but the IOSS
> events remain same. This patch adds the updated PSS event table to enable
> Telemetry driver on Gemini Lake.
> 
> Signed-off-by: Shanth Murthy 
> Signed-off-by: Rajneesh Bhardwaj 
> ---
> Changes in v2:
>  * Dropped "Add Audio domain PG status events" from series.
> 
>  drivers/platform/x86/intel_telemetry_debugfs.c |  1 +
> drivers/platform/x86/intel_telemetry_pltdrv.c  | 35
> ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
> b/drivers/platform/x86/intel_telemetry_debugfs.c
> index cd21df982abd..d4fc42b4cbeb 100644
> --- a/drivers/platform/x86/intel_telemetry_debugfs.c
> +++ b/drivers/platform/x86/intel_telemetry_debugfs.c
> @@ -331,6 +331,7 @@ static struct telemetry_debugfs_conf
> telem_apl_debugfs_conf = {
> 
>  static const struct x86_cpu_id telemetry_debugfs_cpu_ids[] = {
>   TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GOLDMONT,
> telem_apl_debugfs_conf),
> + TELEM_DEBUGFS_CPU(INTEL_FAM6_ATOM_GEMINI_LAKE,
> +telem_apl_debugfs_conf),
>   {}
>  };
> 
> diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c
> b/drivers/platform/x86/intel_telemetry_pltdrv.c
> index 6ebdbd2b04fc..6393b3b1d5a6 100644
> --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> @@ -153,6 +153,30 @@ static struct telemetry_evtmap
>   {"PC2_AND_MEM_SHALLOW_IDLE_RES",0x1D40},
>  };
> 
> +static struct telemetry_evtmap
> +
>   telemetry_glk_pss_default_events[TELEM_MAX_OS_ALLOCATED_E
> VENTS] = {
> + {"IA_CORE0_C6_RES", 0x0400},
> + {"IA_CORE0_C6_CTR", 0x},
> + {"IA_MODULE0_C7_RES",   0x0410},
> + {"IA_MODULE0_C7_CTR",   0x000C},
> + {"IA_C0_RES",   0x0805},
> + {"PCS_LTR", 0x2801},
> + {"PSTATES", 0x2802},
> + {"SOC_S0I3_RES",0x0407},
> + {"SOC_S0I3_CTR",0x0008},
> + {"PCS_S0I3_CTR",0x0007},
> + {"PCS_C1E_RES", 0x0414},
> + {"PCS_IDLE_STATUS", 0x2806},
> + {"IA_PERF_LIMITS",  0x280B},
> + {"GT_PERF_LIMITS",  0x280C},
> + {"PCS_WAKEUP_S0IX_CTR", 0x0025},
> + {"PCS_IDLE_BLOCKED",0x2C00},
> + {"PCS_S0IX_BLOCKED",0x2C01},
> + {"PCS_S0IX_WAKE_REASONS",   0x2C02},
> + {"PCS_LTR_BLOCKING",0x2C03},
> + {"PC2_AND_MEM_SHALLOW_IDLE_RES",0x1D40},
> +};
> +
>  /* APL specific Data */
>  static struct telemetry_plt_config telem_apl_config = {
>   .pss_config = {
> @@ -163,8 +187,19 @@ static struct telemetry_plt_config
> telem_apl_config = {
>   },
>  };
> 
> +/* GLK specific Data */
> +static struct telemetry_plt_config telem_glk_config = {
> + .pss_config = {
> + .telem_evts = telemetry_glk_pss_default_events,
> + },
> + .ioss_config = {
> + .telem_evts = telemetry_apl_ioss_default_events,
> + },
> +};
> +
>  static const struct x86_cpu_id telemetry_cpu_ids[] = {
>   TELEM_CPU(INTEL_FAM6_ATOM_GOLDMONT, telem_apl_config),
> + TELEM_CPU(INTEL_FAM6_ATOM_GEMINI_LAKE, telem_glk_config),
>   {}
>  };
> 
> --
> 2.7.4



Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

2017-07-20 Thread Masami Hiramatsu
On Thu, 20 Jul 2017 11:41:38 -0700
Linus Torvalds  wrote:

> On Thu, Jul 20, 2017 at 8:51 AM, Masami Hiramatsu  wrote:
> >
> > Acked-by: Masami Hiramatsu 
> > Tested-by: Masami Hiramatsu 
> 
> Ok, I committed that patch as-is.
> 
> Other architectures may end up with the same issue, unless they really
> happen to have just a single instruction that fits in their
> kprobe_opcode_t type in their templates. But I didn't touch any of
> their (similar) code, since it will need testing.

Similar optprobe code are in arm and powerpc, arm does not support
FORTIFY_SOURCE (yet), and powerpc already fixed that same way.
So I'll make a same fix on arm before traped to the same issue.

Thank you,

-- 
Masami Hiramatsu 


RE: [PATCH v2 2/2] Telemetry: remove redundant macro definition

2017-07-20 Thread Chakravarty, Souvik K
Just missed the email from Darren.

Reviewed-by: Souvik K Chakravarty 

> -Original Message-
> From: Chakravarty, Souvik K
> Sent: Friday, July 21, 2017 8:45 AM
> To: 'Rajneesh Bhardwaj' ; platform-driver-
> x...@vger.kernel.org
> Cc: dvh...@infradead.org; a...@infradead.org; linux-
> ker...@vger.kernel.org; Murthy, Shanth ;
> Bhardwaj, Rajneesh 
> Subject: RE: [PATCH v2 2/2] Telemetry: remove redundant macro definition
> 
> Both set of two looks good. +1.
> 
> > -Original Message-
> > From: platform-driver-x86-ow...@vger.kernel.org
> > [mailto:platform-driver- x86-ow...@vger.kernel.org] On Behalf Of
> > Rajneesh Bhardwaj
> > Sent: Thursday, July 20, 2017 7:51 PM
> > To: platform-driver-...@vger.kernel.org
> > Cc: dvh...@infradead.org; a...@infradead.org; linux-
> > ker...@vger.kernel.org; Murthy, Shanth ;
> > Chakravarty, Souvik K ; Bhardwaj,
> > Rajneesh 
> > Subject: [PATCH v2 2/2] Telemetry: remove redundant macro definition
> >
> > Telemetry driver includes intel_telemetry.h which defines
> > TELEM_MAX_OS_ALLOCATED_EVENTS already.
> >
> > Signed-off-by: Rajneesh Bhardwaj 
> > ---
> >  drivers/platform/x86/intel_telemetry_pltdrv.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c
> > b/drivers/platform/x86/intel_telemetry_pltdrv.c
> > index 6393b3b1d5a6..e0424d5a795a 100644
> > --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> > +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> > @@ -46,7 +46,6 @@
> >  #define TELEM_SAMPLING_DEFAULT_PERIOD  0xD
> >
> >  #define TELEM_MAX_EVENTS_SRAM  28
> > -#define TELEM_MAX_OS_ALLOCATED_EVENTS  20
> >  #define TELEM_SSRAM_STARTTIME_OFFSET   8
> >  #define TELEM_SSRAM_EVTLOG_OFFSET  16
> >
> > --
> > 2.7.4



Re: [PATCH 2/2] dma: Add Spreadtrum DMA controller driver

2017-07-20 Thread Baolin Wang
Hi Chunyan,

On 21 July 2017 at 10:50, Chunyan Zhang  wrote:
> Hi Baolin,
>
> On 18 July 2017 at 15:06, Baolin Wang  wrote:
>> This patch adds the DMA controller driver for Spreadtrum SC9860 platform.
>
> I guess this driver is not only for SC9860, instead it should work for
> all most all Spreadtrum's platforms?

No, now this driver is only for SC9860 platform. If we make this
driver work on other Spreadtrum platform, we should submit new patches
with modifing DT binding files and compatible string.

>
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/dma/Kconfig  |7 +
>>  drivers/dma/Makefile |1 +
>>  drivers/dma/sprd-dma.c   | 1451 
>> ++
>>  include/linux/dma/sprd-dma.h |  270 
>>  4 files changed, 1729 insertions(+)
>>  create mode 100644 drivers/dma/sprd-dma.c
>>  create mode 100644 include/linux/dma/sprd-dma.h
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index fa8f9c0..961f6ea 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -477,6 +477,13 @@ config STM32_DMA
>>   If you have a board based on such a MCU and wish to use DMA say Y
>>   here.
>>
>> +config SPRD_DMA
>> +   bool "Spreadtrum DMA support"
>> +   depends on ARCH_SPRD
>> +   select DMA_ENGINE
>> +   help
>> + Enable support for the on-chip DMA controller on Spreadtrum 
>> platform.
>> +
>>  config S3C24XX_DMAC
>> bool "Samsung S3C24XX DMA support"
>> depends on ARCH_S3C24XX || COMPILE_TEST
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index d12ab29..0fee561 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -58,6 +58,7 @@ obj-$(CONFIG_RENESAS_DMA) += sh/
>>  obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
>>  obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
>>  obj-$(CONFIG_STM32_DMA) += stm32-dma.o
>> +obj-$(CONFIG_SPRD_DMA) += sprd-dma.o
>>  obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
>>  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
>>  obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
>> diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
>> new file mode 100644
>> index 000..64eaef7
>> --- /dev/null
>> +++ b/drivers/dma/sprd-dma.c
>> @@ -0,0 +1,1451 @@
>> +/*
>> + * Copyright (C) 2017 Spreadtrum Communications Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>
> In order to keep consistent with other Spreadtrum's drivers/ DT files
> that had been upstreamed, I suggest to use SPDX-License-Identifier
> tag.

Since I saw other new drivers still use this license and I am not sure
we must change to SPDX-License-Identifier tag. But it is fine for me
to change the license tag.

-- 
Baolin.wang
Best Regards


[PATCH] Documentation: mtk-quadspi: update DT bindings

2017-07-20 Thread Guochun Mao
Add "mediatek,mt2712-nor" and "mediatek,mt7622-nor"
for nor flash node's compatible.

Signed-off-by: Guochun Mao 
---
 .../devicetree/bindings/mtd/mtk-quadspi.txt|2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
index 5ded66a..9845ff4 100644
--- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
@@ -3,6 +3,8 @@
 Required properties:
 - compatible:The possible values are:
  "mediatek,mt2701-nor"
+ "mediatek,mt2712-nor"
+ "mediatek,mt7622-nor"
  "mediatek,mt7623-nor"
  "mediatek,mt8173-nor"
  For mt8173, compatible should be "mediatek,mt8173-nor".
-- 
1.7.9.5



[PATCH v3 1/1] Documentation: mtk-quadspi: update DT bindings

2017-07-20 Thread Guochun Mao
Extra add "mediatek,mt7622-nor" compatible. 

Guochun Mao (1):
  Documentation: mtk-quadspi: update DT bindings

 Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 2 ++
 1 file changed, 2 insertions(+)

-- 
1.9.1



RE: [PATCH 1/3] platform/x86: Add GLK PSS Event Table

2017-07-20 Thread Chakravarty, Souvik K


> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, July 21, 2017 2:36 AM
> To: Chakravarty, Souvik K 
> Cc: Bhardwaj, Rajneesh ; platform-driver-
> x...@vger.kernel.org; a...@infradead.org; linux-kernel@vger.kernel.org;
> Murthy, Shanth 
> Subject: Re: [PATCH 1/3] platform/x86: Add GLK PSS Event Table
> 
> On Mon, Jul 17, 2017 at 05:18:54AM +, Chakravarty, Souvik K wrote:
> > +1 From me.
> 
> Souvik, as the listed maintainer for this driver, what I require from you is a
> complete Acked-by or a Reviewed-by line, preferably the latter, and
> preferably after an actual review with comments. +1 has no semantic
> meaning in the Linux kernel development process, and one line approvals,
> especially from the same company, have little incremental value.
> 
> For details, please see:
> Documentation/process/5.Posting.rst
> Documentation/submitting-patches.rst

Thanks Darren...my mistake :(
Will do.

> 
> Thanks,
> 
> --
> Darren Hart
> VMware Open Source Technology Center


RE: [PATCH v2 2/2] Telemetry: remove redundant macro definition

2017-07-20 Thread Chakravarty, Souvik K
Both set of two looks good. +1.

> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> x86-ow...@vger.kernel.org] On Behalf Of Rajneesh Bhardwaj
> Sent: Thursday, July 20, 2017 7:51 PM
> To: platform-driver-...@vger.kernel.org
> Cc: dvh...@infradead.org; a...@infradead.org; linux-
> ker...@vger.kernel.org; Murthy, Shanth ;
> Chakravarty, Souvik K ; Bhardwaj,
> Rajneesh 
> Subject: [PATCH v2 2/2] Telemetry: remove redundant macro definition
> 
> Telemetry driver includes intel_telemetry.h which defines
> TELEM_MAX_OS_ALLOCATED_EVENTS already.
> 
> Signed-off-by: Rajneesh Bhardwaj 
> ---
>  drivers/platform/x86/intel_telemetry_pltdrv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c
> b/drivers/platform/x86/intel_telemetry_pltdrv.c
> index 6393b3b1d5a6..e0424d5a795a 100644
> --- a/drivers/platform/x86/intel_telemetry_pltdrv.c
> +++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
> @@ -46,7 +46,6 @@
>  #define TELEM_SAMPLING_DEFAULT_PERIOD0xD
> 
>  #define TELEM_MAX_EVENTS_SRAM28
> -#define TELEM_MAX_OS_ALLOCATED_EVENTS20
>  #define TELEM_SSRAM_STARTTIME_OFFSET 8
>  #define TELEM_SSRAM_EVTLOG_OFFSET16
> 
> --
> 2.7.4



Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-20 Thread Theodore Ts'o
On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote:
> I concur with your rationale where de-facto the correlation is effect is 
> diminished and eliminated with the fast_pool and the minimal entropy 
> estimation of interrupts.
> 
> But it does not address my concern. Maybe I was not clear, please allow me to 
> explain it again.
> 
> We have lots of entropy in the system which is discarded by the 
> aforementioned 
> approach (if a high-res timer is present -- without it all bets are off 
> anyway 
> and this should be covered in a separate discussion). At boot time, this 
> issue 
> is fixed by injecting 256 interrupts in the CRNG and consider it seeded.
> 
> But at runtime, were we still need entropy to reseed the CRNG and to supply /
> dev/random. The accounting of entropy at runtime is much too conservative...

Practically no one uses /dev/random.  It's essentially a deprecated
interface; the primary interfaces that have been recommended for well
over a decade is /dev/urandom, and now, getrandom(2).  We only need
384 bits of randomness every 5 minutes to reseed the CRNG, and that's
plenty even given the very conservative entropy estimation currently
being used.

This was deliberate.  I care a lot more that we get the initial
boot-time CRNG initialization right on ARM32 and MIPS embedded
devices, far, far, more than I care about making plenty of
information-theoretic entropy available at /dev/random on an x86
system.  Further, I haven't seen an argument for the use case where
this would be valuable.

If you don't think they count because ARM32 and MIPS don't have a
high-res timer, then you have very different priorities than I do.  I
will point out that numerically there are huge number of these devices
--- and very, very few users of /dev/random.

> You mentioned that you are super conservative for interrupts due to timer 
> interrupts. In all measurements on the different systems I conducted, I have 
> not seen that the timer triggers an interrupt picked up by 
> add_interrupt_randomness.

Um, the timer is the largest number of interrupts on my system.  Compare:

CPU0   CPU1   CPU2   CPU3
 LOC:6396552603886565586466057102   Local timer interrupts

with the number of disk related interrupts:

 120:  21492 139284  405131705886   PCI-MSI 376832-edge  
ahci[:00:17.0]

... and add_interrupt_randomness() gets called for **every**
interrupt.  On an mostly idle machine (I was in meetings most of
today) it's not surprising that time interrupts dominate.  That
doesn't matter for me as much because I don't really care about
/dev/random performance.  What's is **far** more important is that the
entropy estimations behave correctly, across all of Linux's
architectures, while the kernel is going through startup, before CRNG
is declared initialized.

> As we have no formal model about entropy to begin with, we can only assume 
> and 
> hope we underestimate entropy with the entropy heuristic.

Yes, and that's why I use an ultra-conservative estimate.  If we start
using a more aggressive hueristic, we open ourselves up to potentially
very severe security bugs --- and for what?  What's the cost benefit
ratio here which makes this a worthwhile thing to risk?

> Finally, I still think it is helpful to allow (not mandate) to involve the 
> kernel crypto API for the DRNG maintenance (i.e. the supplier for /dev/random 
> and /dev/urandom). The reason is that now more and more DRNG implementations 
> in hardware pop up. Why not allowing them to be used. I.e. random.c would 
> only 
> contain the logic to manage entropy but uses the DRNG requested by a user.

We *do* allow them to be used.  And we support a large number of
hardware random number generators already.  See drivers/char/hw_random.

BTW, I theorize that this is why the companies that could do the
bootloader random seen work haven't bothered.  Most of their products
have a TPM or equivalent, and with modern kernel the hw_random
interface now has a kernel thread that will automatically fill the
/dev/random entropy pool from the hw_random device.  So this all works
already, today, without needing a userspace rngd (which used to be
required).

> In addition allowing a replacement of the DRNG component (at compile time at 
> least) may get us away from having a separate DRNG solution in the kernel 
> crypto API. Some users want their chosen or a standardized DRNG to deliver 
> random numbers. Thus, we have several DRNGs in the kernel crypto API which 
> are 
> seeded by get_random_bytes. Or in user space, many folks need their own DRNG 
> in user space in addition to the kernel. IMHO this is all a waste. If we 
> could 
> use the user-requested DRNG when producing random numbers for 
> get_random_bytes 
> or /dev/urandom or getrandom.

To be honest, I've never understood why that's there in the crypto API
at all.  But adding more ways to switch out the DRNG for /dev/random
doesn't solve that 

Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu

2017-07-20 Thread David Miller
From: Vijay Kumar 
Date: Thu, 20 Jul 2017 21:44:24 -0500

> I had same thoughts initially but I had to go with this approach as
> scheduler_ipi is wrapped with irq_enter() and irq_exit(). Whereas POKE
> resumes the cpu in process context.
> 
> Comments in scheduler_ipi():
> 
>  * Not all reschedule IPI handlers call irq_enter/irq_exit, since
>  * traditionally all their work was done from the interrupt return
>  * path. Now that we actually do some work, we need to make sure
>  * we do call them.
>  *
>  * Some archs already do call them, luckily irq_enter/exit nest
>  * properly.
>  *
>  * Arguably we should visit all archs and update all handlers,
>  * however a fair share of IPIs are still resched only so this would
>  * somewhat pessimize the simple resched case.
>  */
> irq_enter();
> 

I still think we should be able to fake the state such that this
direct schedule_ipi() call will work.

I could be wrong :)


Re: [PATCH 2/2] dma: Add Spreadtrum DMA controller driver

2017-07-20 Thread Chunyan Zhang
Hi Baolin,

On 18 July 2017 at 15:06, Baolin Wang  wrote:
> This patch adds the DMA controller driver for Spreadtrum SC9860 platform.

I guess this driver is not only for SC9860, instead it should work for
all most all Spreadtrum's platforms?

>
> Signed-off-by: Baolin Wang 
> ---
>  drivers/dma/Kconfig  |7 +
>  drivers/dma/Makefile |1 +
>  drivers/dma/sprd-dma.c   | 1451 
> ++
>  include/linux/dma/sprd-dma.h |  270 
>  4 files changed, 1729 insertions(+)
>  create mode 100644 drivers/dma/sprd-dma.c
>  create mode 100644 include/linux/dma/sprd-dma.h
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index fa8f9c0..961f6ea 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -477,6 +477,13 @@ config STM32_DMA
>   If you have a board based on such a MCU and wish to use DMA say Y
>   here.
>
> +config SPRD_DMA
> +   bool "Spreadtrum DMA support"
> +   depends on ARCH_SPRD
> +   select DMA_ENGINE
> +   help
> + Enable support for the on-chip DMA controller on Spreadtrum 
> platform.
> +
>  config S3C24XX_DMAC
> bool "Samsung S3C24XX DMA support"
> depends on ARCH_S3C24XX || COMPILE_TEST
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index d12ab29..0fee561 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_RENESAS_DMA) += sh/
>  obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
>  obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
>  obj-$(CONFIG_STM32_DMA) += stm32-dma.o
> +obj-$(CONFIG_SPRD_DMA) += sprd-dma.o
>  obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
>  obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
>  obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
> diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
> new file mode 100644
> index 000..64eaef7
> --- /dev/null
> +++ b/drivers/dma/sprd-dma.c
> @@ -0,0 +1,1451 @@
> +/*
> + * Copyright (C) 2017 Spreadtrum Communications Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +

In order to keep consistent with other Spreadtrum's drivers/ DT files
that had been upstreamed, I suggest to use SPDX-License-Identifier
tag.

Thanks,
Chunyan

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dmaengine.h"
> +
> +#define SPRD_DMA_DESCRIPTORS   16
> +#define SPRD_DMA_CFG_COUNT 32
> +#define SPRD_DMA_CHN_REG_OFFSET0x1000
> +#define SPRD_DMA_CHN_REG_LENGTH0x40
> +#define SPRD_DMA_MEMCPY_MIN_SIZE   64
> +
> +/* DMA global registers definition */
> +#define DMA_GLB_PAUSE  0x0
> +#define DMA_GLB_FRAG_WAIT  0x4
> +#define DMA_GLB_REQ_PEND0_EN   0x8
> +#define DMA_GLB_REQ_PEND1_EN   0xc
> +#define DMA_GLB_INT_RAW_STS0x10
> +#define DMA_GLB_INT_MSK_STS0x14
> +#define DMA_GLB_REQ_STS0x18
> +#define DMA_GLB_CHN_EN_STS 0x1c
> +#define DMA_GLB_DEBUG_STS  0x20
> +#define DMA_GLB_ARB_SEL_STS0x24
> +#define DMA_GLB_CHN_START_CHN_CFG1 0x28
> +#define DMA_GLB_CHN_START_CHN_CFG2 0x2c
> +#define DMA_CHN_LLIST_OFFSET   0x10
> +#define DMA_GLB_REQ_CID(base, uid) \
> +   ((unsigned long)(base) + 0x2000 + 0x4 * ((uid) - 1))
> +
> +/* DMA_GLB_CHN_START_CHN_CFG register definition */
> +#define SRC_CHN_OFFSET 0
> +#define DST_CHN_OFFSET 8
> +#define START_MODE_OFFSET  16
> +#define CHN_START_CHN  BIT(24)
> +
> +/* DMA channel registers definition */
> +#define DMA_CHN_PAUSE  0x0
> +#define DMA_CHN_REQ0x4
> +#define DMA_CHN_CFG0x8
> +#define DMA_CHN_INTC   0xc
> +#define DMA_CHN_SRC_ADDR   0x10
> +#define DMA_CHN_DES_ADDR   0x14
> +#define DMA_CHN_FRG_LEN0x18
> +#define DMA_CHN_BLK_LEN0x1c
> +#define DMA_CHN_TRSC_LEN   0x20
> +#define DMA_CHN_TRSF_STEP  0x24
> +#define DMA_CHN_WARP_PTR   0x28
> +#define DMA_CHN_WARP_TO0x2c
> +#define DMA_CHN_LLIST_PTR  0x30
> +#define DMA_CHN_FRAG_STEP  0x34
> +#define DMA_CHN_SRC_BLK_STEP   0x38
> +#define 

Re: [PATCH 2/2] sparc64: Use cpu_poke to resume idle cpu

2017-07-20 Thread Vijay Kumar



On 7/20/2017 2:58 PM, David Miller wrote:

From: Vijay Kumar 
Date: Sat,  8 Jul 2017 14:23:44 -0600


diff --git a/arch/sparc/kernel/hvapi.c b/arch/sparc/kernel/hvapi.c
index 2677312..0b070d5 100644
--- a/arch/sparc/kernel/hvapi.c
+++ b/arch/sparc/kernel/hvapi.c
@@ -189,7 +189,7 @@ void __init sun4v_hvapi_init(void)
  
  	group = HV_GRP_CORE;

major = 1;
-   minor = 1;
+   minor = 6; /* CPU POKE */
if (sun4v_hvapi_register(group, major, ))
goto bad;

That CPU POKE comment will not stand the test of time, please remove it.


+   /* Use cpu poke to resume idle cpu if supported*/

Please put a space at the end of the comment and before the "*/"


+   /*cpu poke is registered. */

Please put a space at the beginning of the comment.

And you should decide which way you want to consistently write.
Either capitalize the first word and finish the sentence with
a '.', or don't.  Do it the same way each time.

Thanks.

Sure, I will fix these in v2.

Thanks,
-Vijay



Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu

2017-07-20 Thread Vijay Kumar



On 7/20/2017 2:57 PM, David Miller wrote:

From: Vijay Kumar 
Date: Sat,  8 Jul 2017 14:23:42 -0600


cpu_poke is a low latency path to resume the target cpu if suspended
using cpu_yield. Use cpu poke to resume cpu if supported by hypervisor.

 hackbench results (lower is better):
Number of   
Process:w/o fix with fix
1   0.0120.010
10  0.0210.019
100 0.1510.148

So this only works for a cpu which has yielded.

The kernel sends reschedule events to both idle and non-idle cpus.
That's why you have to have that fallback code to still send the
mondo IPI right?

That is correct.



For the case where POKE works, it seems like completely unnecessary
overhead to set the PIL interrupt.  Just disable local cpu interrupts
and call schedule_ipi() directly.

I bet that improves your benchmark even more.


I had same thoughts initially but I had to go with this approach as 
scheduler_ipi is wrapped with irq_enter() and irq_exit(). Whereas POKE 
resumes the cpu in process context.


Comments in scheduler_ipi():

 * Not all reschedule IPI handlers call irq_enter/irq_exit, since
 * traditionally all their work was done from the interrupt return
 * path. Now that we actually do some work, we need to make sure
 * we do call them.
 *
 * Some archs already do call them, luckily irq_enter/exit nest
 * properly.
 *
 * Arguably we should visit all archs and update all handlers,
 * however a fair share of IPIs are still resched only so this 
would

 * somewhat pessimize the simple resched case.
 */
irq_enter();


-Vijay



Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

2017-07-20 Thread Eric W. Biederman


Oleg Nesterov  writes:

> On 07/18, Eric W. Biederman wrote:
>>
>> -BUG_ON((reason & __SI_MASK) != __SI_POLL);
>> +BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL));
>   ^
> looks obviously wrong? Say, POLL_IN is obviously > NSIGPOLL == 6.

Strictly speaking that code is wrong until the next patch
when I remove __SI_POLL.  That is my mistake.

When the values are not their messed up internal kernel variants
the code works fine and makes sense.

#define POLL_IN 1   /* data input available */
#define POLL_OUT2   /* output buffers available */
#define POLL_MSG3   /* input message available */
#define POLL_ERR4   /* i/o error */
#define POLL_PRI5   /* high priority input available */
#define POLL_HUP6   /* device disconnected */
#define NSIGPOLL6

> Probably you meant
>
>   BUG_ON((reason < POLL_IN) || (reason - POLL_IN > 
> NSIGPOLL)
>
> ?
>
> but this contradicts with the next line:

>>  if (reason - POLL_IN >= NSIGPOLL)
>>  si.si_band  = ~0L;
>
> confused...

I am mystified why we test for a condition that we have been bugging on
for ages.

Eric






[PATCH] qe: fix compile issue for arm64

2017-07-20 Thread Zhao Qiang
Signed-off-by: Zhao Qiang 
---
 drivers/soc/fsl/qe/qe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2ef6fc6..d48fa4a 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -229,7 +229,9 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, 
unsigned int multiplier)
/* Errata QE_General4, which affects some MPC832x and MPC836x SOCs, says
   that the BRG divisor must be even if you're not using divide-by-16
   mode. */
+#ifdef CONFIG_PPC
if (pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x))
+#endif
if (!div16 && (divisor & 1) && (divisor > 3))
divisor++;
 
-- 
2.1.0.27.g96db324



[PATCH 5/5] dt-bindings: PCI: add support for new generation controller

2017-07-20 Thread honghui.zhang
From: Ryder Lee 

Add support for MediaTek new generation controller and update related
properities.

Signed-off-by: Ryder Lee 
Signed-off-by: Honghui Zhang 
---
 .../devicetree/bindings/pci/mediatek-pcie.txt  | 84 --
 1 file changed, 79 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index 294f4a3..a1f3767 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -4,17 +4,27 @@ Required properties:
 - compatible: Should contain one of the following string:
"mediatek,mt7623-pcie"
"mediatek,mt2701-pcie"
+   "mediatek,generic-pcie-v2"
 - device_type: Must be "pci"
-- reg: Base addresses and lengths of the PCIe controller.
+- reg: Base addresses and lengths of the PICe subsys and root ports.
+- reg-names: Names of the above areas to use during resource look-up.
 - #address-cells: Address representation for root ports (must be 3)
 - #size-cells: Size representation for root ports (must be 2)
 - clocks: Must contain an entry for each entry in clock-names.
   See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
   - free_ck :for reference clock of PCIe subsys
-  - sys_ck0 :for clock of Port0
-  - sys_ck1 :for clock of Port1
-  - sys_ck2 :for clock of Port2
+  - sys_ckN :transaction layer and data link layer clock
+  The "sys_ck" might be divided into the following parts in some v2 chips:
+- ahb_ckN :AHB slave interface operating clock for CSR access and RC
+  initiated MMIO access
+- axi_ckN :application layer MMIO channel operating clock
+- aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
+  pcie_mac_ck/pcie_pipe_ck is turned off
+- obff_ckN :OBFF functional block operating clock
+- pipe_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
+   pcie_mac_ck/pcie_pipe_ck is turned off
+  where N starting from 0 to the maximum number of root ports.
 - phys: List of PHY specifiers (used by generic PHY framework).
 - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
   number of PHYs as specified in *phys* property.
@@ -33,6 +43,9 @@ Required properties for MT7623/MT2701:
 - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
   number of root ports.
 
+Required properties for mediatek generic-pcie-v2:
+-interrupts: A list of interrupt outputs of the controller.
+
 In addition, the device tree node must have sub-nodes describing each
 PCIe port interface, having the following mandatory properties:
 
@@ -50,7 +63,7 @@ Required properties:
   property is sufficient.
 - num-lanes: Number of lanes to use for this port.
 
-Examples:
+Examples for mt7623:
 
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
@@ -68,6 +81,7 @@ Examples:
  <0 0x1a142000 0 0x1000>, /* Port0 registers */
  <0 0x1a143000 0 0x1000>, /* Port1 registers */
  <0 0x1a144000 0 0x1000>; /* Port2 registers */
+   reg-names = "subsys", "port0", "port1", "port2";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
@@ -127,3 +141,63 @@ Examples:
num-lanes = <1>;
};
};
+
+Examples for mt2712:
+   pcie: pcie@0x1170 {
+   compatible = "mediatek,generic-pcie-v2";
+   device_type = "pci";
+   reg = <0 0x1170 0 0x1000>,
+ <0 0x112FF000 0 0x1000>;
+   reg-names = "port0", "port1";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   interrupts = ,
+;
+   clocks = < CLK_PERI_PCIE0>,
+< CLK_PERI_PCIE1>,
+< CLK_TOP_PE2_MAC_P0_SEL>,
+< CLK_TOP_PE2_MAC_P1_SEL>;
+   clock-names = "sys_ck0", "sys_ck1", "ahb0", "ahb1";
+   bus-range = <0x00 0xff>;
+   ranges = <0x8200 0 0x2000  0x0 0x2000  0 
0x1000>;
+
+   pcie0: pcie@0,0 {
+   device_type = "pci";
+   reg = <0x 0 0 0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges;
+   num-lanes = <1>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _intc0 0>,
+   <0 0 0 2 _intc0 1>,
+   <0 0 0 3 _intc0 2>,
+   <0 0 0 4 

[PATCH v2 1/1] Documentation: mtk-quadspi: update DT bindings

2017-07-20 Thread Guochun Mao
 Sort compatible strings in alphabetic order.

Guochun Mao (1):
  Documentation: mtk-quadspi: update DT bindings

 Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 1 +
 1 file changed, 1 insertion(+)

-- 
1.9.1



[PATCH] Documentation: mtk-quadspi: update DT bindings

2017-07-20 Thread Guochun Mao
Add "mediatek,mt2712-nor" for nor flash node's compatible.

Signed-off-by: Guochun Mao 
---
 .../devicetree/bindings/mtd/mtk-quadspi.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
index 5ded66a..35974eb 100644
--- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
@@ -3,6 +3,7 @@
 Required properties:
 - compatible:The possible values are:
  "mediatek,mt2701-nor"
+ "mediatek,mt2712-nor"
  "mediatek,mt7623-nor"
  "mediatek,mt8173-nor"
  For mt8173, compatible should be "mediatek,mt8173-nor".
-- 
1.7.9.5



[PATCH 2/5] PCI: mediatek: switch to use platform_get_resource_byname()

2017-07-20 Thread honghui.zhang
From: Ryder Lee 

This is a transitional patch. We currently use platfarm_get_resource() for
retrieving the IOMEM resources, but there might be some chips don't have
subsys/shared registers part, which depends on platform design, and these
will be introduced in further patches.

Switch this function to use the platform_get_resource_byname() so that the
binding can be agnostic of the resource order.

Signed-off-by: Ryder Lee 
---
 drivers/pci/host/pcie-mediatek.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index d6ac342..5e0a2ee2 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -295,7 +295,8 @@ static int mtk_pcie_parse_ports(struct mtk_pcie *pcie,
return err;
}
 
-   regs = platform_get_resource(pdev, IORESOURCE_MEM, index + 1);
+   snprintf(name, sizeof(name), "port%d", index);
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
port->base = devm_ioremap_resource(dev, regs);
if (IS_ERR(port->base)) {
dev_err(dev, "failed to map port%d base\n", index);
@@ -336,12 +337,14 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
struct resource *regs;
int err;
 
-   /* get shared registers */
-   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   pcie->base = devm_ioremap_resource(dev, regs);
-   if (IS_ERR(pcie->base)) {
-   dev_err(dev, "failed to map shared register\n");
-   return PTR_ERR(pcie->base);
+   /* get shared registers, which are optional */
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "subsys");
+   if (regs) {
+   pcie->base = devm_ioremap_resource(dev, regs);
+   if (IS_ERR(pcie->base)) {
+   dev_err(dev, "failed to map shared register\n");
+   return PTR_ERR(pcie->base);
+   }
}
 
pcie->free_ck = devm_clk_get(dev, "free_ck");
-- 
2.6.4



[PATCH 4/5] PCI: mediatek: Add new generation controller support

2017-07-20 Thread honghui.zhang
From: Ryder Lee 

Add support for new Gen2 controller which has two root ports and shares the
probing flow with legacy controller. Currently this IP block can be found
on MT7622/MT2712. More specifically, the newer (future) chips will be
developed based on this generation, thus we use a generic compatible to
avoid having an endless list of compatibles with no differences for the
same hardware.

Signed-off-by: Ryder Lee 
Signed-off-by: Honghui Zhang 
---
 drivers/pci/host/Kconfig |   5 +-
 drivers/pci/host/pcie-mediatek.c | 480 ++-
 2 files changed, 479 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 89d61c2..5b1ae9f 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -182,14 +182,13 @@ config PCIE_ROCKCHIP
 
 config PCIE_MEDIATEK
bool "MediaTek PCIe controller"
-   depends on ARM && (ARCH_MEDIATEK || COMPILE_TEST)
+   depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
depends on OF
depends on PCI
select PCIEPORTBUS
help
  Say Y here if you want to enable PCIe controller support on
- MT7623 series SoCs.  There is one single root complex with 3 root
- ports available.  Each port supports Gen2 lane x1.
+ MediaTek SoCs.
 
 config PCIE_TANGO_SMP8759
bool "Tango SMP8759 PCIe controller (DANGEROUS)"
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 5e0a2ee2..63e117a 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -3,6 +3,7 @@
  *
  * Copyright (c) 2017 MediaTek Inc.
  * Author: Ryder Lee 
+ *   : Honghui Zhang 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -17,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -64,15 +67,79 @@
 #define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
 #define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
 
+/* PCIe V2 share registers */
+#define PCIE_SYS_CFG_V20x0
+#define PCIE_CSR_LTSSM_EN(x)   BIT(0 + (x) * 8)
+#define PCIE_CSR_ASPM_L1_EN(x) BIT(1 + (x) * 8)
+
+/* PCIe V2 per-port registers */
+#define PCIE_INT_MASK  0x420
+#define INTX_MASK  GENMASK(19, 16)
+#define INTX_SHIFT 16
+#define INTX_NUM   4
+#define PCIE_INT_STATUS0x424
+#define AHB2PCIE_BASE0_L   0x438
+#define AHB2PCIE_BASE0_H   0x43c
+#define PCIE2AXI_WIN   0x448
+#define WIN_ENABLE BIT(7)
+#define AHB2PCIE_BASEL(base)   (base & GENMASK(31, 0))
+#define AHB2PCIE_BASEH(base)   (base >> 32)
+#define BASE_SIZE(sz)  (sz & GENMASK(4, 0))
+#define PCIE2AXI_SIZE  0x
+
+#define CFG_HEADER_0   0x460
+#define CFG_HEADER_1   0x464
+#define CFG_HEADER_2   0x468
+#define CFG_RDWR_TYPE_00x4
+#define CFG_RD_FMT 0x0
+#define CFG_WR_FMT 0x2
+
+/* PCIe V2 Configuration Transaction Header */
+#define CFG_DW0_LENGTH(length) (length & GENMASK(9, 0))
+#define CFG_DW0_TYPE(type) ((type << 24) & GENMASK(28, 24))
+#define CFG_DW0_FMT(fmt)   ((fmt << 29) & GENMASK(31, 29))
+#define CFG_DW2_REGN(regn) (regn & GENMASK(11, 2))
+#define CFG_DW2_FUN(fun)   ((fun << 16) & GENMASK(18, 16))
+#define CFG_DW2_DEV(dev)   ((dev << 19) & GENMASK(23, 19))
+#define CFG_DW2_BUS(bus)   ((bus << 24) & GENMASK(31, 24))
+#define CFG_HEADER_DW0(type, fmt) \
+   (CFG_DW0_LENGTH(1) | CFG_DW0_TYPE(type) | CFG_DW0_FMT(fmt))
+#define CFG_HEADER_DW1(where, size)(GENMASK((size - 1), 0) << \
+   ((where) & 0x3))
+#define CFG_HEADER_DW2(regn, fun, dev, bus) \
+   (CFG_DW2_REGN(regn) | CFG_DW2_FUN(fun) | \
+   CFG_DW2_DEV(dev) | CFG_DW2_BUS(bus))
+
+#define PCIE_CFG_WDATA 0x470
+#define APP_TLP_REQ0x488
+#define APP_CFG_REQBIT(0)
+#define APP_CPL_STATUS GENMASK(7, 5)
+#define PCIE_CFG_RDATA 0x48c
+#define PCIE_RSTCR 0x510
+#define PCIE_PHY_RSTB  BIT(0)
+#define PCIE_PIPE_SRSTBBIT(1)
+#define PCIE_MAC_SRSTB BIT(2)
+#define PCIE_CRSTB BIT(3)
+#define PCIE_PERSTBBIT(8)
+#define PCIE_PIPE_RST_EN   BIT(13)
+#define PCIE_MAC_RST_ENBIT(14)
+#define PCIE_CONF_RST_EN   BIT(15)
+#define PCIE_LINKDOWN_RST_EN   (PCIE_PIPE_RST_EN | PCIE_MAC_RST_EN | \
+   PCIE_CONF_RST_EN)
+#define PCIE_LINK_STATUS_V20x804
+#define PCIE_PORT_LINKUP_V2BIT(10)
+
 struct mtk_pcie_port;
 
 /**
  * struct mtk_pcie_soc - differentiate between host generations
  * @ops: pointer to configuration access 

[PATCH 3/5] dt-bindings: PCI: rename and cleanup MediaTek binding text

2017-07-20 Thread honghui.zhang
From: Ryder Lee 

In order to accommodate other SoC generations, this patch updates filename
to make it more generic, regroups specific properties by SoCs, and removes
redundant descriptions.

Signed-off-by: Ryder Lee 
---
 ...{mediatek,mt7623-pcie.txt => mediatek-pcie.txt} | 29 +++---
 1 file changed, 14 insertions(+), 15 deletions(-)
 rename Documentation/devicetree/bindings/pci/{mediatek,mt7623-pcie.txt => 
mediatek-pcie.txt} (91%)

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
similarity index 91%
rename from Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
rename to Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index fe80dda..294f4a3 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -1,18 +1,13 @@
-MediaTek Gen2 PCIe controller which is available on MT7623 series SoCs
-
-PCIe subsys supports single root complex (RC) with 3 Root Ports. Each root
-ports supports a Gen2 1-lane Link and has PIPE interface to PHY.
+MediaTek Gen2 PCIe controller
 
 Required properties:
-- compatible: Should contain "mediatek,mt7623-pcie".
+- compatible: Should contain one of the following string:
+   "mediatek,mt7623-pcie"
+   "mediatek,mt2701-pcie"
 - device_type: Must be "pci"
 - reg: Base addresses and lengths of the PCIe controller.
 - #address-cells: Address representation for root ports (must be 3)
 - #size-cells: Size representation for root ports (must be 2)
-- #interrupt-cells: Size representation for interrupts (must be 1)
-- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
-  Please refer to the standard PCI bus binding document for a more detailed
-  explanation.
 - clocks: Must contain an entry for each entry in clock-names.
   See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
@@ -20,12 +15,6 @@ Required properties:
   - sys_ck0 :for clock of Port0
   - sys_ck1 :for clock of Port1
   - sys_ck2 :for clock of Port2
-- resets: Must contain an entry for each entry in reset-names.
-  See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
-  - pcie-rst0 :port0 reset
-  - pcie-rst1 :port1 reset
-  - pcie-rst2 :port2 reset
 - phys: List of PHY specifiers (used by generic PHY framework).
 - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
   number of PHYs as specified in *phys* property.
@@ -34,6 +23,16 @@ Required properties:
 - bus-range: Range of bus numbers associated with this controller.
 - ranges: Ranges for the PCI memory and I/O regions.
 
+Required properties for MT7623/MT2701:
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
+  number of root ports.
+
 In addition, the device tree node must have sub-nodes describing each
 PCIe port interface, having the following mandatory properties:
 
-- 
2.6.4



[PATCH 1/5] PCI: mediatek: Add a structure to abstract the controller generations

2017-07-20 Thread honghui.zhang
From: Ryder Lee 

Introduce a structure "mtk_pcie_soc" to abstract the differences between
controller generations, and the .startup() hook is used to encapsulate
some SoC-dependent related setting. In doing so, the common code which
will be reused by future chips.

In addition, we change the approaches to waiting Gen2 training by using
readl_poll_timeout() calls.

Signed-off-by: Ryder Lee 
Signed-off-by: Honghui Zhang 
---
 drivers/pci/host/pcie-mediatek.c | 81 +++-
 1 file changed, 47 insertions(+), 34 deletions(-)

diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index 5a9d858..d6ac342 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -63,6 +64,18 @@
 #define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
 #define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
 
+struct mtk_pcie_port;
+
+/**
+ * struct mtk_pcie_soc - differentiate between host generations
+ * @ops: pointer to configuration access functions
+ * @startup: pointer to controller setting functions
+ */
+struct mtk_pcie_soc {
+   struct pci_ops *ops;
+   int (*startup)(struct mtk_pcie_port *port);
+};
+
 /**
  * struct mtk_pcie_port - PCIe port information
  * @base: IO mapped register base
@@ -96,6 +109,7 @@ struct mtk_pcie_port {
  * @busn: bus range
  * @offset: IO / Memory offset
  * @ports: pointer to PCIe port information
+ * @soc: pointer to SoC-dependent operations
  */
 struct mtk_pcie {
struct device *dev;
@@ -111,13 +125,9 @@ struct mtk_pcie {
resource_size_t io;
} offset;
struct list_head ports;
+   const struct mtk_pcie_soc *soc;
 };
 
-static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
-{
-   return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
-}
-
 static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
 {
struct device *dev = pcie->dev;
@@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
.write = pci_generic_config_write,
 };
 
-static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
+static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
 {
struct mtk_pcie *pcie = port->pcie;
u32 func = PCI_FUNC(port->index << 3);
u32 slot = PCI_SLOT(port->index << 3);
u32 val;
+   int err;
+
+   /* assert port PERST_N */
+   val = readl(pcie->base + PCIE_SYS_CFG);
+   val |= PCIE_PORT_PERST(port->index);
+   writel(val, pcie->base + PCIE_SYS_CFG);
+
+   /* de-assert port PERST_N */
+   val = readl(pcie->base + PCIE_SYS_CFG);
+   val &= ~PCIE_PORT_PERST(port->index);
+   writel(val, pcie->base + PCIE_SYS_CFG);
+
+   /* 100ms timeout value should be enough for Gen1/2 training */
+   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
+!!(val & PCIE_PORT_LINKUP), 20,
+100 * USEC_PER_MSEC);
+   if (err)
+   return -ETIMEDOUT;
 
/* enable interrupt */
val = readl(pcie->base + PCIE_INT_ENABLE);
@@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct mtk_pcie_port 
*port)
writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
   pcie->base + PCIE_CFG_ADDR);
writel(val, pcie->base + PCIE_CFG_DATA);
-}
 
-static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
-{
-   struct mtk_pcie *pcie = port->pcie;
-   u32 val;
-
-   /* assert port PERST_N */
-   val = readl(pcie->base + PCIE_SYS_CFG);
-   val |= PCIE_PORT_PERST(port->index);
-   writel(val, pcie->base + PCIE_SYS_CFG);
-
-   /* de-assert port PERST_N */
-   val = readl(pcie->base + PCIE_SYS_CFG);
-   val &= ~PCIE_PORT_PERST(port->index);
-   writel(val, pcie->base + PCIE_SYS_CFG);
-
-   /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
-   msleep(100);
+   return 0;
 }
 
 static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
 {
-   struct device *dev = port->pcie->dev;
+   struct mtk_pcie *pcie = port->pcie;
+   struct device *dev = pcie->dev;
int err;
 
err = clk_prepare_enable(port->sys_ck);
@@ -250,13 +262,8 @@ static void mtk_pcie_enable_ports(struct mtk_pcie_port 
*port)
goto err_phy_on;
}
 
-   mtk_pcie_assert_ports(port);
-
-   /* if link up, then setup root port configuration space */
-   if (mtk_pcie_link_up(port)) {
-   mtk_pcie_configure_rc(port);
+   if (!pcie->soc->startup(port))
return;
-   }
 
dev_info(dev, "Port%d link down\n", port->index);
 
@@ -480,7 +487,7 @@ static int mtk_pcie_register_host(struct pci_host_bridge 
*host)
 
host->busnr = pcie->busn.start;
host->dev.parent = 

[PATCH 0/5] PCI: MediaTek: Add support for new generation host controller

2017-07-20 Thread honghui.zhang
From: Honghui Zhang 

MediaTek's PCIe host controller has two generation HWs, the new
generation HW has two root ports, it shares most probing flow with the
legacy controller. But the read/write config space logical is different
from the lagacy controller.
This patchset abstract the common probing flow, and add support for the
new generation controller.

Ryder Lee (5):
  PCI: mediatek: Add a structure to abstract the controller generations
  PCI: mediatek: switch to use platform_get_resource_byname()
  dt-bindings: PCI: rename and cleanup MediaTek binding text
  PCI: mediatek: Add new generation controller support
  dt-bindings: PCI: add support for new generation controller

 ...{mediatek,mt7623-pcie.txt => mediatek-pcie.txt} | 113 +++-
 drivers/pci/host/Kconfig   |   5 +-
 drivers/pci/host/pcie-mediatek.c   | 578 +++--
 3 files changed, 629 insertions(+), 67 deletions(-)
 rename Documentation/devicetree/bindings/pci/{mediatek,mt7623-pcie.txt => 
mediatek-pcie.txt} (59%)

-- 
2.6.4



Re: Makefile:541: arch/avr32/Makefile: No such file or directory

2017-07-20 Thread Fengguang Wu

Hi Dunlap and Hans,

On Thu, Jul 20, 2017 at 04:22:47PM -0700, Randy Dunlap wrote:

On 07/20/2017 04:18 PM, kbuild test robot wrote:

Hi Hans-Christian,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   beaec533fc2701a28a4d667f67c9f59c6e4e0d13
commit: 26202873bb51fafdaa51be3e8de7aab9beb49f70 avr32: remove support for 
AVR32 architecture


Please read above: 



Ah yes, it looks 0day robot may still pick up obsolete avr32 testing
from old data or git trees based on old kernel releases. I'll add
explicit code to prevent that. Sorry for the noise!

Thanks,
Fengguang


date:   3 months ago
config: avr32-atngw100mkii_defconfig
compiler: avr32-linux-gcc (GCC) 4.2.4-atmel.1.1.3.avr32linux.1
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 26202873bb51fafdaa51be3e8de7aab9beb49f70
make.cross ARCH=avr32  atngw100mkii_defconfig
make.cross ARCH=avr32

All errors (new ones prefixed by >>):


Makefile:541: arch/avr32/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/avr32/Makefile'.

   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [atngw100mkii_defconfig] Error 1
   make[1]: *** [atngw100mkii_defconfig] Error 2
   make: *** [sub-make] Error 2
--
   Makefile:630: arch/avr32/Makefile: No such file or directory

make[1]: *** No rule to make target 'arch/avr32/Makefile'.

   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make: *** [sub-make] Error 2
--

Makefile:541: arch/avr32/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/avr32/Makefile'.

   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [oldconfig] Error 1
   make[1]: *** [oldconfig] Error 2
   make: *** [sub-make] Error 2
--

Makefile:541: arch/avr32/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/avr32/Makefile'.

   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [olddefconfig] Error 1
   make[2]: Target 'oldnoconfig' not remade because of errors.
   make[1]: *** [oldnoconfig] Error 2
   make: *** [sub-make] Error 2

vim +541 Makefile

^1da177e Linus Torvalds  2005-04-16  537
^1da177e Linus Torvalds  2005-04-16  538  # Read arch specific Makefile to set 
KBUILD_DEFCONFIG as needed.
^1da177e Linus Torvalds  2005-04-16  539  # KBUILD_DEFCONFIG may point out an 
alternative default configuration
^1da177e Linus Torvalds  2005-04-16  540  # used for 'make defconfig'
a436bb7b Masahiro Yamada 2015-03-27 @541  include arch/$(SRCARCH)/Makefile
61bee204 Al Viro 2008-08-25  542  export KBUILD_DEFCONFIG KBUILD_KCONFIG
^1da177e Linus Torvalds  2005-04-16  543

:: The code at line 541 was first introduced by commit
:: a436bb7b806383ae0593cab53d17fc9676270cd3 kbuild: use relative path more 
to include Makefile

:: TO: Masahiro Yamada 
:: CC: Michal Marek 

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




--
~Randy


Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

2017-07-20 Thread Bob Liu
On 2017/7/21 9:41, Jerome Glisse wrote:
> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote:
>> On 2017/7/20 23:03, Jerome Glisse wrote:
>>> On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote:
 On 2017/7/19 10:25, Jerome Glisse wrote:
> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote:
>> On 2017/7/18 23:38, Jerome Glisse wrote:
>>> On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote:
 On 2017/7/14 5:15, Jérôme Glisse wrote:
> 
> [...]
> 
 Then it's more like replace the numa node solution(CDM) with ZONE_DEVICE
 (type MEMORY_DEVICE_PUBLIC). But the problem is the same, e.g how to make
 sure the device memory say HBM won't be occupied by normal CPU allocation.
 Things will be more complex if there are multi GPU connected by nvlink
 (also cache coherent) in a system, each GPU has their own HBM.

 How to decide allocate physical memory from local HBM/DDR or remote HBM/
 DDR? 

 If using numa(CDM) approach there are NUMA mempolicy and autonuma mechanism
 at least.
>>>
>>> NUMA is not as easy as you think. First like i said we want the device
>>> memory to be isolated from most existing mm mechanism. Because memory
>>> is unreliable and also because device might need to be able to evict
>>> memory to make contiguous physical memory allocation for graphics.
>>>
>>
>> Right, but we need isolation any way.
>> For hmm-cdm, the isolation is not adding device memory to lru list, and many
>> if (is_device_public_page(page)) ...
>>
>> But how to evict device memory?
> 
> What you mean by evict ? Device driver can evict whenever they see the need
> to do so. CPU page fault will evict too. Process exit or munmap() will free
> the device memory.
> 
> Are you refering to evict in the sense of memory reclaim under pressure ?
> 
> So the way it flows for memory pressure is that if device driver want to
> make room it can evict stuff to system memory and if there is not enough

Yes, I mean this. 
So every driver have to maintain their own LRU-similar list instead of reuse 
what already in linux kernel.

> system memory than thing get reclaim as usual before device driver can
> make progress on device memory reclaim.
> 
> 
>>> Second device driver are not integrated that closely within mm and the
>>> scheduler kernel code to allow to efficiently plug in device access
>>> notification to page (ie to update struct page so that numa worker
>>> thread can migrate memory base on accurate informations).
>>>
>>> Third it can be hard to decide who win between CPU and device access
>>> when it comes to updating thing like last CPU id.
>>>
>>> Fourth there is no such thing like device id ie equivalent of CPU id.
>>> If we were to add something the CPU id field in flags of struct page
>>> would not be big enough so this can have repercusion on struct page
>>> size. This is not an easy sell.
>>>
>>> They are other issues i can't think of right now. I think for now it
>>
>> My opinion is most of the issues are the same no matter use CDM or HMM-CDM.
>> I just care about a more complete solution no matter CDM,HMM-CDM or other 
>> ways.
>> HMM or HMM-CDM depends on device driver, but haven't see a public/full 
>> driver to 
>> demonstrate the whole solution works fine.
> 
> I am working with NVidia close source driver team to make sure that it works
> well for them. I am also working on nouveau open source driver for same NVidia
> hardware thought it will be of less use as what is missing there is a solid
> open source userspace to leverage this. Nonetheless open source driver are in
> the work.
> 

Looking forward to see these drivers be public.

> The way i see it is start with HMM-CDM which isolate most of the changes in
> hmm code. Once we get more experience with real workload and not with device
> driver test suite then we can start revisiting NUMA and deeper integration
> with the linux kernel. I rather grow organicaly toward that than trying to
> design something that would make major changes all over the kernel without
> knowing for sure that we are going in the right direction. I hope that this
> make sense to others too.
> 

Make sense.

Thanks,
Bob Liu




[PATCH] GFS2: fix code parameter error in inode_go_lock

2017-07-20 Thread Wang Xibo
In inode_go_lock() function, the parameter order of list_add() is error.
According to the define of list_add(), the first parameter is new entry
and the second is the list head, so ip->i_trunc_list should be the
first parameter and the sdp->sd_trunc_list should be second.

Signed-off-by: Wang Xibo
Signed-off-by: Xiao Likun
---
 fs/gfs2/glops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index 5e69636..28c203a 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2/glops.c
@@ -470,7 +470,7 @@ static int inode_go_lock(struct gfs2_holder *gh)
(gh->gh_state == LM_ST_EXCLUSIVE)) {
spin_lock(>sd_trunc_lock);
if (list_empty(>i_trunc_list))
-   list_add(>sd_trunc_list, >i_trunc_list);
+   list_add(>i_trunc_list, >sd_trunc_list);
spin_unlock(>sd_trunc_lock);
wake_up(>sd_quota_wait);
return 1;
-- 
1.8.3.1




Re: [PATCH 18/32] tracing: Add simple expression support to hist triggers

2017-07-20 Thread Namhyung Kim
Hi Tom,

On Mon, Jun 26, 2017 at 05:49:19PM -0500, Tom Zanussi wrote:
> Add support for simple addition, subtraction, and unary expressions
> (-(expr) and expr, where expr = b-a, a+b, a+b+c) to hist triggers, in
> order to support a minimal set of useful inter-event calculations.
> 
> These operations are needed for calculating latencies between events
> (timestamp1-timestamp0) and for combined latencies (latencies over 3
> or more events).
> 
> In the process, factor out some common code from key and value
> parsing.
> 
> Signed-off-by: Tom Zanussi 
> ---

[SNIP]
> +static char *expr_str(struct hist_field *field, unsigned int level)
> +{
> + char *expr = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> +
> + if (!expr || level > 1)
> + return NULL;

Looks like a memory leak.


[SNIP]
> +static struct hist_field *parse_expr(struct hist_trigger_data *hist_data,
> +  struct trace_event_file *file,
> +  char *str, unsigned long flags,
> +  char *var_name, unsigned int level)
> +{
> + struct hist_field *operand1 = NULL, *operand2 = NULL, *expr = NULL;
> + unsigned long operand_flags;
> + int field_op, ret = -EINVAL;
> + char *sep, *operand1_str;
> +
> + if (level > 2)
> + return NULL;
> +
> + field_op = contains_operator(str);
> + if (field_op == FIELD_OP_NONE)
> + return NULL;

Why not calling parse_atom() here?  It'd make the code simpler IMHO.

Thanks,
Namhyung


> +
> + if (field_op == FIELD_OP_UNARY_MINUS)
> + return parse_unary(hist_data, file, str, flags, var_name, 
> ++level);
> +
> + switch (field_op) {
> + case FIELD_OP_MINUS:
> + sep = "-";
> + break;
> + case FIELD_OP_PLUS:
> + sep = "+";
> + break;
> + default:
> + goto free;
> + }
> +
> + operand1_str = strsep(, sep);
> + if (!operand1_str || !str)
> + goto free;
> +
> + operand_flags = 0;
> + operand1 = parse_atom(hist_data, file, operand1_str,
> +   _flags, NULL);
> + if (IS_ERR(operand1)) {
> + ret = PTR_ERR(operand1);
> + operand1 = NULL;
> + goto free;
> + }
> +
> + // rest of string could be another expression e.g. b+c in a+b+c
> + operand_flags = 0;
> + operand2 = parse_expr(hist_data, file, str, operand_flags, NULL, 
> ++level);
> + if (IS_ERR(operand2)) {
> + ret = PTR_ERR(operand2);
> + operand2 = NULL;
> + goto free;
> + }
> + if (!operand2) {
> + operand_flags = 0;
> + operand2 = parse_atom(hist_data, file, str,
> +   _flags, NULL);
> + if (IS_ERR(operand2)) {
> + ret = PTR_ERR(operand2);
> + operand2 = NULL;
> + goto free;
> + }
> + }
> +
> + flags |= HIST_FIELD_FL_EXPR;
> + expr = create_hist_field(hist_data, NULL, flags, var_name);
> + if (!expr) {
> + ret = -ENOMEM;
> + goto free;
> + }
> +
> + expr->operands[0] = operand1;
> + expr->operands[1] = operand2;
> + expr->operator = field_op;
> + expr->name = expr_str(expr, 0);
> +
> + switch (field_op) {
> + case FIELD_OP_MINUS:
> + expr->fn = hist_field_minus;
> + break;
> + case FIELD_OP_PLUS:
> + expr->fn = hist_field_plus;
> + break;
> + default:
> + goto free;
> + }
> +
> + return expr;
> + free:
> + destroy_hist_field(operand1, 0);
> + destroy_hist_field(operand2, 0);
> + destroy_hist_field(expr, 0);
> +
> + return ERR_PTR(ret);
> +}


Re: [PATCH 1/2] iommu/rockchip: add multi irqs support

2017-07-20 Thread Shawn Lin

Hi Simon,

On 2017/7/21 9:35, Simon Xue wrote:

From: Simon 

RK3368 vpu mmu have two irqs, this patch support multi irqs

Signed-off-by: Simon 
---
  drivers/iommu/rockchip-iommu.c | 34 --
  1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 4ba48a2..b38283e 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -90,7 +90,8 @@ struct rk_iommu {
struct device *dev;
void __iomem **bases;
int num_mmu;
-   int irq;
+   int *irq > + int num_irq;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
struct iommu_domain *domain; /* domain to which iommu is attached */
@@ -825,10 +826,12 @@ static int rk_iommu_attach_device(struct iommu_domain 
*domain,
  
  	iommu->domain = domain;
  
-	ret = devm_request_irq(iommu->dev, iommu->irq, rk_iommu_irq,

-  IRQF_SHARED, dev_name(dev), iommu);
-   if (ret)
-   return ret;
+   for (i = 0; i < iommu->num_irq; i++) {
+   ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
+  IRQF_SHARED, dev_name(dev), iommu);
+   if (ret)
+   return ret;
+   }
  
  	for (i = 0; i < iommu->num_mmu; i++) {

rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
@@ -878,7 +881,8 @@ static void rk_iommu_detach_device(struct iommu_domain 
*domain,
}
rk_iommu_disable_stall(iommu);
  
-	devm_free_irq(iommu->dev, iommu->irq, iommu);

+   for (i = 0; i < iommu->num_irq; i++)
+   devm_free_irq(iommu->dev, iommu->irq[i], iommu);
  
  	iommu->domain = NULL;
  
@@ -1157,10 +1161,20 @@ static int rk_iommu_probe(struct platform_device *pdev)

if (iommu->num_mmu == 0)
return PTR_ERR(iommu->bases[0]);
  
-	iommu->irq = platform_get_irq(pdev, 0);

-   if (iommu->irq < 0) {
-   dev_err(dev, "Failed to get IRQ, %d\n", iommu->irq);
-   return -ENXIO;
+   while (platform_get_irq(pdev, iommu->num_irq) >= 0)
+   iommu->num_irq++;
+
+   iommu->irq = devm_kzalloc(dev, sizeof(*iommu->irq) * iommu->num_irq,
+ GFP_KERNEL);


Prefer to used devm_kcalloc for array allocation,see
Documentation/process/coding-style.rst +831


+   if (!iommu->irq)
+   return -ENOMEM;
+
+   for (i = 0; i < iommu->num_irq; i++) {
+   iommu->irq[i] = platform_get_irq(pdev, i);
+   if (iommu->irq[i] < 0) {
+   dev_err(dev, "Failed to get IRQ, %d\n", iommu->irq[i]);
+   return -ENXIO;
+   }
}
  
  	err = iommu_device_sysfs_add(>iommu, dev, NULL, dev_name(dev));






[PATCH 1/5] perf script python: Allocate memory only if handler exists

2017-07-20 Thread Arun Kalyanasundaram
Avoid allocating memory if hook handler is not available. This saves
unused memory allocation and simplifies error path.

Let handler in python_process_tracepoint point to either tracepoint
specific or trace_unhandled hook. Use dict to check if handler points to
trace_unhandled.

Remove the exit label in python_process_general_event and return when no
handler is available.

Signed-off-by: Arun Kalyanasundaram 
---
 .../util/scripting-engines/trace-event-python.c| 38 +-
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 57b7a00e6f16..8a8f4829d3e2 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -407,10 +407,7 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
void *data = sample->raw_data;
unsigned long long nsecs = sample->time;
const char *comm = thread__comm_str(al->thread);
-
-   t = PyTuple_New(MAX_FIELDS);
-   if (!t)
-   Py_FatalError("couldn't create Python tuple");
+   const char *default_handler_name = "trace_unhandled";
 
if (!event) {
snprintf(handler_name, sizeof(handler_name),
@@ -427,10 +424,19 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
 
handler = get_handler(handler_name);
if (!handler) {
+   handler = get_handler(default_handler_name);
+   if (!handler)
+   return;
dict = PyDict_New();
if (!dict)
Py_FatalError("couldn't create Python dict");
}
+
+   t = PyTuple_New(MAX_FIELDS);
+   if (!t)
+   Py_FatalError("couldn't create Python tuple");
+
+
s = nsecs / NSEC_PER_SEC;
ns = nsecs - s * NSEC_PER_SEC;
 
@@ -445,7 +451,7 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
/* ip unwinding */
callchain = python_process_callchain(sample, evsel, al);
 
-   if (handler) {
+   if (!dict) {
PyTuple_SetItem(t, n++, PyInt_FromLong(cpu));
PyTuple_SetItem(t, n++, PyInt_FromLong(s));
PyTuple_SetItem(t, n++, PyInt_FromLong(ns));
@@ -484,23 +490,23 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
} else { /* FIELD_IS_NUMERIC */
obj = get_field_numeric_entry(event, field, data);
}
-   if (handler)
+   if (!dict)
PyTuple_SetItem(t, n++, obj);
else
pydict_set_item_string_decref(dict, field->name, obj);
 
}
 
-   if (!handler)
+   if (dict)
PyTuple_SetItem(t, n++, dict);
 
if (_PyTuple_Resize(, n) == -1)
Py_FatalError("error resizing Python tuple");
 
-   if (handler) {
+   if (!dict) {
call_object(handler, t, handler_name);
} else {
-   try_call_object("trace_unhandled", t);
+   call_object(handler, t, default_handler_name);
Py_DECREF(dict);
}
 
@@ -799,6 +805,12 @@ static void python_process_general_event(struct 
perf_sample *sample,
static char handler_name[64];
unsigned n = 0;
 
+   snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
+
+   handler = get_handler(handler_name);
+   if (!handler)
+   return;
+
/*
 * Use the MAX_FIELDS to make the function expandable, though
 * currently there is only one item for the tuple.
@@ -815,12 +827,6 @@ static void python_process_general_event(struct 
perf_sample *sample,
if (!dict_sample)
Py_FatalError("couldn't create Python dictionary");
 
-   snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
-
-   handler = get_handler(handler_name);
-   if (!handler)
-   goto exit;
-
pydict_set_item_string_decref(dict, "ev_name", 
PyString_FromString(perf_evsel__name(evsel)));
pydict_set_item_string_decref(dict, "attr", PyString_FromStringAndSize(
(const char *)>attr, sizeof(evsel->attr)));
@@ -861,7 +867,7 @@ static void python_process_general_event(struct perf_sample 
*sample,
Py_FatalError("error resizing Python tuple");
 
call_object(handler, t, handler_name);
-exit:
+
Py_DECREF(dict);
Py_DECREF(t);
 }
-- 
2.14.0.rc0.284.gd933b75aa4-goog



[PATCH 2/5] perf script python: Refactor creation of perf sample dict

2017-07-20 Thread Arun Kalyanasundaram
Move the creation of the dict containing perf_sample entries into a
helper function to enable its reuse in other sample processing routines.

Signed-off-by: Arun Kalyanasundaram 
---
 .../util/scripting-engines/trace-event-python.c| 94 --
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 8a8f4829d3e2..69d1b6db96f6 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -391,6 +391,57 @@ static PyObject *python_process_callchain(struct 
perf_sample *sample,
return pylist;
 }
 
+static PyObject *get_perf_sample_dict(struct perf_sample *sample,
+struct perf_evsel *evsel,
+struct addr_location *al,
+PyObject *callchain)
+{
+   PyObject *dict, *dict_sample;
+
+   dict = PyDict_New();
+   if (!dict)
+   Py_FatalError("couldn't create Python dictionary");
+
+   dict_sample = PyDict_New();
+   if (!dict_sample)
+   Py_FatalError("couldn't create Python dictionary");
+
+   pydict_set_item_string_decref(dict, "ev_name", 
PyString_FromString(perf_evsel__name(evsel)));
+   pydict_set_item_string_decref(dict, "attr", PyString_FromStringAndSize(
+   (const char *)>attr, sizeof(evsel->attr)));
+
+   pydict_set_item_string_decref(dict_sample, "pid",
+   PyInt_FromLong(sample->pid));
+   pydict_set_item_string_decref(dict_sample, "tid",
+   PyInt_FromLong(sample->tid));
+   pydict_set_item_string_decref(dict_sample, "cpu",
+   PyInt_FromLong(sample->cpu));
+   pydict_set_item_string_decref(dict_sample, "ip",
+   PyLong_FromUnsignedLongLong(sample->ip));
+   pydict_set_item_string_decref(dict_sample, "time",
+   PyLong_FromUnsignedLongLong(sample->time));
+   pydict_set_item_string_decref(dict_sample, "period",
+   PyLong_FromUnsignedLongLong(sample->period));
+   pydict_set_item_string_decref(dict, "sample", dict_sample);
+
+   pydict_set_item_string_decref(dict, "raw_buf", 
PyString_FromStringAndSize(
+   (const char *)sample->raw_data, sample->raw_size));
+   pydict_set_item_string_decref(dict, "comm",
+   PyString_FromString(thread__comm_str(al->thread)));
+   if (al->map) {
+   pydict_set_item_string_decref(dict, "dso",
+   PyString_FromString(al->map->dso->name));
+   }
+   if (al->sym) {
+   pydict_set_item_string_decref(dict, "symbol",
+   PyString_FromString(al->sym->name));
+   }
+
+   pydict_set_item_string_decref(dict, "callchain", callchain);
+
+   return dict;
+}
+
 static void python_process_tracepoint(struct perf_sample *sample,
  struct perf_evsel *evsel,
  struct addr_location *al)
@@ -801,7 +852,7 @@ static void python_process_general_event(struct perf_sample 
*sample,
 struct perf_evsel *evsel,
 struct addr_location *al)
 {
-   PyObject *handler, *t, *dict, *callchain, *dict_sample;
+   PyObject *handler, *t, *dict, *callchain;
static char handler_name[64];
unsigned n = 0;
 
@@ -819,48 +870,9 @@ static void python_process_general_event(struct 
perf_sample *sample,
if (!t)
Py_FatalError("couldn't create Python tuple");
 
-   dict = PyDict_New();
-   if (!dict)
-   Py_FatalError("couldn't create Python dictionary");
-
-   dict_sample = PyDict_New();
-   if (!dict_sample)
-   Py_FatalError("couldn't create Python dictionary");
-
-   pydict_set_item_string_decref(dict, "ev_name", 
PyString_FromString(perf_evsel__name(evsel)));
-   pydict_set_item_string_decref(dict, "attr", PyString_FromStringAndSize(
-   (const char *)>attr, sizeof(evsel->attr)));
-
-   pydict_set_item_string_decref(dict_sample, "pid",
-   PyInt_FromLong(sample->pid));
-   pydict_set_item_string_decref(dict_sample, "tid",
-   PyInt_FromLong(sample->tid));
-   pydict_set_item_string_decref(dict_sample, "cpu",
-   PyInt_FromLong(sample->cpu));
-   pydict_set_item_string_decref(dict_sample, "ip",
-   PyLong_FromUnsignedLongLong(sample->ip));
-   pydict_set_item_string_decref(dict_sample, "time",
-   PyLong_FromUnsignedLongLong(sample->time));
-   pydict_set_item_string_decref(dict_sample, "period",
-   

[PATCH 4/5] perf script python: Add perf_sample dict to tracepoint handlers

2017-07-20 Thread Arun Kalyanasundaram
The process_event python hook receives a dict with all perf_sample
entries, but the tracepoint specific and trace_unhandled hooks predate
the introduction of this dict, and do not receive it.

Add the aforementioned dict as an additional argument to the affected
handlers. To keep backwards compatibility (and avoid unnecessary work),
do not pass the dict if the number of arguments signals that handler
version predates this change.

Signed-off-by: Arun Kalyanasundaram 
---
 .../util/scripting-engines/trace-event-python.c| 41 +-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 55a45784c910..938b39f6ad31 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -116,6 +116,34 @@ static PyObject *get_handler(const char *handler_name)
return handler;
 }
 
+static int get_argument_count(PyObject *handler)
+{
+   int arg_count = 0;
+
+   /*
+* The attribute for the code object is func_code in Python 2,
+* whereas it is __code__ in Python 3.0+.
+*/
+   PyObject *code_obj = PyObject_GetAttrString(handler,
+   "func_code");
+   if (PyErr_Occurred()) {
+   PyErr_Clear();
+   code_obj = PyObject_GetAttrString(handler,
+   "__code__");
+   }
+   PyErr_Clear();
+   if (code_obj) {
+   PyObject *arg_count_obj = PyObject_GetAttrString(code_obj,
+   "co_argcount");
+   if (arg_count_obj) {
+   arg_count = (int) PyInt_AsLong(arg_count_obj);
+   Py_DECREF(arg_count_obj);
+   }
+   Py_DECREF(code_obj);
+   }
+   return arg_count;
+}
+
 static void call_object(PyObject *handler, PyObject *args, const char *die_msg)
 {
PyObject *retval;
@@ -499,7 +527,7 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
 {
struct event_format *event = evsel->tp_format;
PyObject *handler, *context, *t, *obj = NULL, *callchain;
-   PyObject *dict = NULL;
+   PyObject *dict = NULL, *all_entries_dict = NULL;
static char handler_name[256];
struct format_field *field;
unsigned long s, ns;
@@ -552,6 +580,8 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
 
/* ip unwinding */
callchain = python_process_callchain(sample, evsel, al);
+   /* Need an additional reference for the perf_sample dict */
+   Py_INCREF(callchain);
 
if (!dict) {
PyTuple_SetItem(t, n++, PyInt_FromLong(cpu));
@@ -602,6 +632,14 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
if (dict)
PyTuple_SetItem(t, n++, dict);
 
+   if (get_argument_count(handler) == (int) n + 1) {
+   all_entries_dict = get_perf_sample_dict(sample, evsel, al,
+   callchain);
+   PyTuple_SetItem(t, n++, all_entries_dict);
+   } else {
+   Py_DECREF(callchain);
+   }
+
if (_PyTuple_Resize(, n) == -1)
Py_FatalError("error resizing Python tuple");
 
@@ -612,6 +650,7 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
Py_DECREF(dict);
}
 
+   Py_XDECREF(all_entries_dict);
Py_DECREF(t);
 }
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog



[PATCH 5/5] perf script python: Generate hooks with additional argument

2017-07-20 Thread Arun Kalyanasundaram
Modify the signature of tracepoint specific and trace_unhandled hooks to
add the perf_sample dict as a new argument.
Create a python helper function to print a dictionary.

Signed-off-by: Arun Kalyanasundaram 
---
 .../util/scripting-engines/trace-event-python.c| 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 938b39f6ad31..c7187f067d31 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -1367,6 +1367,12 @@ static int python_generate_script(struct pevent *pevent, 
const char *outfile)
 
fprintf(ofp, "%s", f->name);
}
+   if (not_first++)
+   fprintf(ofp, ", ");
+   if (++count % 5 == 0)
+   fprintf(ofp, "\n\t\t");
+   fprintf(ofp, "perf_sample_dict");
+
fprintf(ofp, "):\n");
 
fprintf(ofp, "\t\tprint_header(event_name, common_cpu, "
@@ -1436,6 +1442,9 @@ static int python_generate_script(struct pevent *pevent, 
const char *outfile)
 
fprintf(ofp, ")\n\n");
 
+   fprintf(ofp, "\t\tprint 'Sample: {'+"
+   "get_dict_as_string(perf_sample_dict['sample'], ', 
')+'}'\n\n");
+
fprintf(ofp, "\t\tfor node in common_callchain:");
fprintf(ofp, "\n\t\t\tif 'sym' in node:");
fprintf(ofp, "\n\t\t\t\tprint \"\\t[%%x] %%s\" %% (node['ip'], 
node['sym']['name'])");
@@ -1446,15 +1455,20 @@ static int python_generate_script(struct pevent 
*pevent, const char *outfile)
}
 
fprintf(ofp, "def trace_unhandled(event_name, context, "
-   "event_fields_dict):\n");
+   "event_fields_dict, perf_sample_dict):\n");
 
-   fprintf(ofp, "\t\tprint ' '.join(['%%s=%%s'%%(k,str(v))"
-   "for k,v in sorted(event_fields_dict.items())])\n\n");
+   fprintf(ofp, "\t\tprint get_dict_as_string(event_fields_dict)\n");
+   fprintf(ofp, "\t\tprint 'Sample: {'+"
+   "get_dict_as_string(perf_sample_dict['sample'], ', ')+'}'\n\n");
 
fprintf(ofp, "def print_header("
"event_name, cpu, secs, nsecs, pid, comm):\n"
"\tprint \"%%-20s %%5u %%05u.%%09u %%8u %%-20s \" %% \\\n\t"
-   "(event_name, cpu, secs, nsecs, pid, comm),\n");
+   "(event_name, cpu, secs, nsecs, pid, comm),\n\n");
+
+   fprintf(ofp, "def get_dict_as_string(a_dict, delimiter=' '):\n"
+   "\treturn delimiter.join"
+   "(['%%s=%%s'%%(k,str(v))for k,v in sorted(a_dict.items())])\n");
 
fclose(ofp);
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog



[PATCH 0/5] perf script python: Provide perf_sample dict to all handlers

2017-07-20 Thread Arun Kalyanasundaram
The process_event python hook receives a dict with most perf_sample
entries.

Other handlers (e.g. trace_unhandled, python_process_tracepoint) predate
the introduction of this dict and do not receive it. This patch series
adds the dict to all handlers, aiming to unify the information passed to
them.

This change adds an additional argument to the affected handlers. To
keep backwards compatibility (and avoid unnecessary work), do not pass
the aforementioned dict if the number of arguments signals that handler
version predates this change.

In addition, provide time_enabled, time_running and counter value in the
perf_sample dict.

Initial Discussion: https://lkml.org/lkml/2017/7/1/108

Arun Kalyanasundaram (5):
  perf script python: Allocate memory only if handler exists
  perf script python: Refactor creation of perf sample dict
  perf script python: Add sample_read to dict
  perf script python: Add perf_sample dict to tracepoint handlers
  perf script python: Generate hooks with additional argument

 .../util/scripting-engines/trace-event-python.c| 246 +++--
 1 file changed, 184 insertions(+), 62 deletions(-)

-- 
2.14.0.rc0.284.gd933b75aa4-goog



[PATCH 3/5] perf script python: Add sample_read to dict

2017-07-20 Thread Arun Kalyanasundaram
Provide time_enabled, time_running and counter value in the perf_sample
dict.

Signed-off-by: Arun Kalyanasundaram 
---
 .../util/scripting-engines/trace-event-python.c| 51 ++
 1 file changed, 51 insertions(+)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 69d1b6db96f6..55a45784c910 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -391,6 +391,56 @@ static PyObject *python_process_callchain(struct 
perf_sample *sample,
return pylist;
 }
 
+static PyObject *get_sample_value_as_tuple(struct sample_read_value *value)
+{
+   PyObject *t;
+
+   t = PyTuple_New(2);
+   if (!t)
+   Py_FatalError("couldn't create Python tuple");
+   PyTuple_SetItem(t, 0, PyLong_FromUnsignedLongLong(value->id));
+   PyTuple_SetItem(t, 1, PyLong_FromUnsignedLongLong(value->value));
+   return t;
+}
+
+static void set_sample_read_in_dict(PyObject *dict_sample,
+struct perf_sample *sample,
+struct perf_evsel *evsel)
+{
+   u64 read_format = evsel->attr.read_format;
+   PyObject *values;
+   unsigned int i;
+
+   if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED) {
+   pydict_set_item_string_decref(dict_sample, "time_enabled",
+   PyLong_FromUnsignedLongLong(sample->read.time_enabled));
+   }
+
+   if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING) {
+   pydict_set_item_string_decref(dict_sample, "time_running",
+   PyLong_FromUnsignedLongLong(sample->read.time_running));
+   }
+
+   if (read_format & PERF_FORMAT_GROUP)
+   values = PyList_New(sample->read.group.nr);
+   else
+   values = PyList_New(1);
+
+   if (!values)
+   Py_FatalError("couldn't create Python list");
+
+   if (read_format & PERF_FORMAT_GROUP) {
+   for (i = 0; i < sample->read.group.nr; i++) {
+   PyObject *t = 
get_sample_value_as_tuple(>read.group.values[i]);
+   PyList_SET_ITEM(values, i, t);
+   }
+   } else {
+   PyObject *t = get_sample_value_as_tuple(>read.one);
+   PyList_SET_ITEM(values, 0, t);
+   }
+   pydict_set_item_string_decref(dict_sample, "values", values);
+}
+
 static PyObject *get_perf_sample_dict(struct perf_sample *sample,
 struct perf_evsel *evsel,
 struct addr_location *al,
@@ -422,6 +472,7 @@ static PyObject *get_perf_sample_dict(struct perf_sample 
*sample,
PyLong_FromUnsignedLongLong(sample->time));
pydict_set_item_string_decref(dict_sample, "period",
PyLong_FromUnsignedLongLong(sample->period));
+   set_sample_read_in_dict(dict_sample, sample, evsel);
pydict_set_item_string_decref(dict, "sample", dict_sample);
 
pydict_set_item_string_decref(dict, "raw_buf", 
PyString_FromStringAndSize(
-- 
2.14.0.rc0.284.gd933b75aa4-goog



Re: [PATCH v5] printk: Add pr_info_show_time

2017-07-20 Thread Luis R. Rodriguez
On Thu, Jul 20, 2017 at 11:24:22AM -0700, Mark Salyzyn wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 98fe715522e8..0d63c3fb4e24 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -30,6 +30,58 @@ config CONSOLE_LOGLEVEL_DEFAULT
> usage in the kernel. That is controlled by the 
> MESSAGE_LOGLEVEL_DEFAULT
> option.
>  
> +# set if time is being printed in pr_info_show_time()
> +config PR_INFO_SHOW_TIME
> + bool
> +
> +choice
> + prompt "pr_info_show_time() alternate time message prefix"
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.
> + config PR_INFO_SHOW_TIME_MONOTONIC
> + bool "monotonic"
> + help
> +   Deactivate alternate time prefix in pr_info_show_time.
> +   Doing so because monotonic time is part of the normal
> +   printk time logging.
> +
> +   Print only the supplied message in pr_info_show_time,
> +   indistinguishable from pr_info.
> + config PR_INFO_SHOW_TIME_REALTIME
> + bool "realtime"
> + select PR_INFO_SHOW_TIME
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.  For instance
> +   CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> +   continues, and the timestamps help re-orient post-analysis.
> +
> +   Prefix realtime [.U] timestamp in pr_info_show_time
> + config PR_INFO_SHOW_TIME_BOOTTIME
> + bool "boottime"
> + select PR_INFO_SHOW_TIME
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.  For instance
> +   CLOCK_MONOTONIC stops while suspended, while CLOCK_BOOTTIME
> +   continues, and the timestamps help re-orient post-analysis.
> +
> +   Prefix boottime [.B] timestamp in pr_info_show_time
> +endchoice

There is no depends magic anywhere here, so none of this actually has complex
dependencies, this is just boot time preference setup, and for that I think a
boot param and sysctl value could easily not only enable the same but *also*
enable run time ability to swap between these. Even for the branch performance
consideration can't jump labels be used to address that if there is a concern
for that?

I think that would also make the code easier to read and remove all this kconfig
extra stuff. Then its just a run time thing.

Also, should there be no checks for time being available and ready before this
is used?

  Luis


Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

2017-07-20 Thread Ye Xiaolong
Hi,

On 07/19, Linus Torvalds wrote:
>Hmm. I wonder why the kernel test robot ends up having that annoying
>line doubling for the dmesg.
>

Hmm, this line doubling issue should be caused by we set both
'earlyprintk=ttyS0,115200' and 'console=ttyS0,115200' in cmdline, after I
remove any of it, this issue is gone, is it an inappropriate setting?

FYI, the whole kernel command line is:

ip=vm-lkp-nhm-dp1-yocto-i386-7::dhcp
root=/dev/ram0
user=lkp
job=/lkp/scheduled/vm-lkp-nhm-dp1-yocto-i386-7/boot-1-yocto-tiny-i386-2016-04-22.cgz-6974f0c4555e285ab217cee58b6e874f776ff409-20170717-28286-131pyzw-0.yaml
ARCH=i386
kconfig=i386-randconfig-w0-07171351
branch=linus/master
commit=6974f0c4555e285ab217cee58b6e874f776ff409
BOOT_IMAGE=/pkg/linux/i386-randconfig-w0-07171351/gcc-6/6974f0c4555e285ab217cee58b6e874f776ff409/vmlinuz-4.12.0-10998-g6974f0c
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-lkp-nhm-dp1-yocto-i386/yocto-tiny-i386-2016-04-22.cgz/i386-randconfig-w0-07171351/gcc-6/6974f0c4555e285ab217cee58b6e874f776ff409/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
earlyprintk=ttyS0,115200
console=ttyS0,115200
console=tty0
vga=

Thanks,
Xiaolong


Re: [PATCH v6 08/12] gpio: Add GPIO driver for the RK805 PMIC

2017-07-20 Thread Jianhong Chen



在 2017/6/29 18:29, Heiko Stübner 写道:


Hi,

Am Mittwoch, 14. Juni 2017, 20:11:06 CEST schrieb Jianhong Chen:

在 2017/6/9 20:17, Heiko Stuebner 写道:

Am Freitag, 9. Juni 2017, 13:37:26 CEST schrieb Linus Walleij:

Heiko, can you please look at this patch.

On Thu, Jun 8, 2017 at 9:30 AM, Jianhong Chen 

wrote:

From: chenjh 

Full name please.

git config --global user.name "John Doe"

might do the and make this permanent for all your commits :-)


RK805 has two configurable GPIOs that can be used for several
purposes. These are output only.

This driver is generic for other Rockchip PMICs to be added.

Signed-off-by: chenjh 

Dito.

Your commit message says they are output-only, yet you implement
.direction_input(). So what is is going to be?

So far, I've only seen the rk808 and rk818. Both do not have any
configurable pins.

The rk805 which is a sort of variant of the above, does have the two
pins defined below, but in the manual I could also only find them as
output-only and having no other function than being output-pins.

So I don't really know if all the input- or "gpio-mode"- handling is only
an oversight (copy'n'paste) or if there are yet other rk808 variants
around
that can actually be configured as inputs or even non-gpio modes?

I hope Jianhong will be able to answer that.


Heiko

This driver is not only for rk805, but also intend for rk816 and furtrue
PMICs.
The rk816 has one multi function pin(TS/GPIO), when setting as gpio, it
can be configured as output or input.
Here is simple description from manual: "Thermistor input. Connect a
thermistor from this pin to ground. The thermistor is usually inside the
battery pack. (multi-function for GPIO) ".

As Linus suggested, this sounds like you want a pinctrl driver that
also handles the gpios.

Ideally you might also directly provide support for this rk816 in the
same patch series, so reviewers can see the full extend of what is
supported.


Heiko



Hi, Heiko:

 I have moved gpio-rk805.c to drivers/pinctrl/pinctrl-rk805.c, this 
driver is also designed for rk816 or furture PMICs to extend.
 RK816 is not in our team's plan at this porting, it will be added 
at next time, so I don't directly provide rk816 in this driver. I will 
add more descriptions in commit message to express my design purpose.


 Are you agreed ?  If so, I will send [PATCH v7] today.


--
Best Regards

陈健洪 (Joseph Chen)
E-mail:che...@rock-chips.com
福州瑞芯微电子股份有限公司
Fuzhou Rockchip Electronics Co.Ltd
福建省福州市铜盘路软件大道89号软件园A区21号楼 (350003)
No. 21 Building, A District, No.89,software Boulevard Fuzhou,Fujian,PRC
TEL:0591-83991906/07-8573




Re: [PATCH 2/2] iommu/rockchip: ignore isp mmu reset operation

2017-07-20 Thread Shawn Lin

Hi Simon,

On 2017/7/21 9:35, Simon Xue wrote:

From: Simon 

ISP mmu can't support reset operation, it won't get the
expected result when reset, but rest functions work normally.
Add this patch as a WA for this issue.

Signed-off-by: Simon 
---
  drivers/iommu/rockchip-iommu.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index b38283e..47c00b9 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -92,6 +92,7 @@ struct rk_iommu {
int num_mmu;
int *irq;
int num_irq;
+   bool reset_disabled;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
struct iommu_domain *domain; /* domain to which iommu is attached */
@@ -415,6 +416,9 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
int ret, i;
u32 dte_addr;
  
+	if (iommu->reset_disabled)

+   return 0;
+
/*
 * Check if register DTE_ADDR is working by writing DTE_ADDR_DUMMY
 * and verifying that upper 5 nybbles are read back.
@@ -1177,6 +1181,9 @@ static int rk_iommu_probe(struct platform_device *pdev)
}
}
  
+	iommu->reset_disabled = device_property_read_bool(dev,

+   "rk_iommu,disable_reset_quirk");
+


Please update Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
as well. And please use '-' instead of '_' for DT property.



err = iommu_device_sysfs_add(>iommu, dev, NULL, dev_name(dev));
if (err)
return err;





Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

2017-07-20 Thread Jerome Glisse
On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote:
> On 2017/7/20 23:03, Jerome Glisse wrote:
> > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote:
> >> On 2017/7/19 10:25, Jerome Glisse wrote:
> >>> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote:
>  On 2017/7/18 23:38, Jerome Glisse wrote:
> > On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote:
> >> On 2017/7/14 5:15, Jérôme Glisse wrote:

[...]

> >> Then it's more like replace the numa node solution(CDM) with ZONE_DEVICE
> >> (type MEMORY_DEVICE_PUBLIC). But the problem is the same, e.g how to make
> >> sure the device memory say HBM won't be occupied by normal CPU allocation.
> >> Things will be more complex if there are multi GPU connected by nvlink
> >> (also cache coherent) in a system, each GPU has their own HBM.
> >>
> >> How to decide allocate physical memory from local HBM/DDR or remote HBM/
> >> DDR? 
> >>
> >> If using numa(CDM) approach there are NUMA mempolicy and autonuma mechanism
> >> at least.
> > 
> > NUMA is not as easy as you think. First like i said we want the device
> > memory to be isolated from most existing mm mechanism. Because memory
> > is unreliable and also because device might need to be able to evict
> > memory to make contiguous physical memory allocation for graphics.
> > 
> 
> Right, but we need isolation any way.
> For hmm-cdm, the isolation is not adding device memory to lru list, and many
> if (is_device_public_page(page)) ...
> 
> But how to evict device memory?

What you mean by evict ? Device driver can evict whenever they see the need
to do so. CPU page fault will evict too. Process exit or munmap() will free
the device memory.

Are you refering to evict in the sense of memory reclaim under pressure ?

So the way it flows for memory pressure is that if device driver want to
make room it can evict stuff to system memory and if there is not enough
system memory than thing get reclaim as usual before device driver can
make progress on device memory reclaim.


> > Second device driver are not integrated that closely within mm and the
> > scheduler kernel code to allow to efficiently plug in device access
> > notification to page (ie to update struct page so that numa worker
> > thread can migrate memory base on accurate informations).
> > 
> > Third it can be hard to decide who win between CPU and device access
> > when it comes to updating thing like last CPU id.
> > 
> > Fourth there is no such thing like device id ie equivalent of CPU id.
> > If we were to add something the CPU id field in flags of struct page
> > would not be big enough so this can have repercusion on struct page
> > size. This is not an easy sell.
> > 
> > They are other issues i can't think of right now. I think for now it
> 
> My opinion is most of the issues are the same no matter use CDM or HMM-CDM.
> I just care about a more complete solution no matter CDM,HMM-CDM or other 
> ways.
> HMM or HMM-CDM depends on device driver, but haven't see a public/full driver 
> to 
> demonstrate the whole solution works fine.

I am working with NVidia close source driver team to make sure that it works
well for them. I am also working on nouveau open source driver for same NVidia
hardware thought it will be of less use as what is missing there is a solid
open source userspace to leverage this. Nonetheless open source driver are in
the work.

The way i see it is start with HMM-CDM which isolate most of the changes in
hmm code. Once we get more experience with real workload and not with device
driver test suite then we can start revisiting NUMA and deeper integration
with the linux kernel. I rather grow organicaly toward that than trying to
design something that would make major changes all over the kernel without
knowing for sure that we are going in the right direction. I hope that this
make sense to others too.

Cheers,
Jérôme


[PATCH 2/2] iommu/rockchip: ignore isp mmu reset operation

2017-07-20 Thread Simon Xue
From: Simon 

ISP mmu can't support reset operation, it won't get the
expected result when reset, but rest functions work normally.
Add this patch as a WA for this issue.

Signed-off-by: Simon 
---
 drivers/iommu/rockchip-iommu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index b38283e..47c00b9 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -92,6 +92,7 @@ struct rk_iommu {
int num_mmu;
int *irq;
int num_irq;
+   bool reset_disabled;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
struct iommu_domain *domain; /* domain to which iommu is attached */
@@ -415,6 +416,9 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
int ret, i;
u32 dte_addr;
 
+   if (iommu->reset_disabled)
+   return 0;
+
/*
 * Check if register DTE_ADDR is working by writing DTE_ADDR_DUMMY
 * and verifying that upper 5 nybbles are read back.
@@ -1177,6 +1181,9 @@ static int rk_iommu_probe(struct platform_device *pdev)
}
}
 
+   iommu->reset_disabled = device_property_read_bool(dev,
+   "rk_iommu,disable_reset_quirk");
+
err = iommu_device_sysfs_add(>iommu, dev, NULL, dev_name(dev));
if (err)
return err;
-- 
1.9.1




[PATCH 1/2] iommu/rockchip: add multi irqs support

2017-07-20 Thread Simon Xue
From: Simon 

RK3368 vpu mmu have two irqs, this patch support multi irqs

Signed-off-by: Simon 
---
 drivers/iommu/rockchip-iommu.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 4ba48a2..b38283e 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -90,7 +90,8 @@ struct rk_iommu {
struct device *dev;
void __iomem **bases;
int num_mmu;
-   int irq;
+   int *irq;
+   int num_irq;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
struct iommu_domain *domain; /* domain to which iommu is attached */
@@ -825,10 +826,12 @@ static int rk_iommu_attach_device(struct iommu_domain 
*domain,
 
iommu->domain = domain;
 
-   ret = devm_request_irq(iommu->dev, iommu->irq, rk_iommu_irq,
-  IRQF_SHARED, dev_name(dev), iommu);
-   if (ret)
-   return ret;
+   for (i = 0; i < iommu->num_irq; i++) {
+   ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
+  IRQF_SHARED, dev_name(dev), iommu);
+   if (ret)
+   return ret;
+   }
 
for (i = 0; i < iommu->num_mmu; i++) {
rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
@@ -878,7 +881,8 @@ static void rk_iommu_detach_device(struct iommu_domain 
*domain,
}
rk_iommu_disable_stall(iommu);
 
-   devm_free_irq(iommu->dev, iommu->irq, iommu);
+   for (i = 0; i < iommu->num_irq; i++)
+   devm_free_irq(iommu->dev, iommu->irq[i], iommu);
 
iommu->domain = NULL;
 
@@ -1157,10 +1161,20 @@ static int rk_iommu_probe(struct platform_device *pdev)
if (iommu->num_mmu == 0)
return PTR_ERR(iommu->bases[0]);
 
-   iommu->irq = platform_get_irq(pdev, 0);
-   if (iommu->irq < 0) {
-   dev_err(dev, "Failed to get IRQ, %d\n", iommu->irq);
-   return -ENXIO;
+   while (platform_get_irq(pdev, iommu->num_irq) >= 0)
+   iommu->num_irq++;
+
+   iommu->irq = devm_kzalloc(dev, sizeof(*iommu->irq) * iommu->num_irq,
+ GFP_KERNEL);
+   if (!iommu->irq)
+   return -ENOMEM;
+
+   for (i = 0; i < iommu->num_irq; i++) {
+   iommu->irq[i] = platform_get_irq(pdev, i);
+   if (iommu->irq[i] < 0) {
+   dev_err(dev, "Failed to get IRQ, %d\n", iommu->irq[i]);
+   return -ENXIO;
+   }
}
 
err = iommu_device_sysfs_add(>iommu, dev, NULL, dev_name(dev));
-- 
1.9.1




Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

2017-07-20 Thread Jerome Glisse
On Thu, Jul 20, 2017 at 06:00:08PM -0700, Evgeny Baskakov wrote:
> On 7/14/17 5:55 PM, Jerome Glisse wrote:
> Hi Jerome,
> 
> I think I just found a couple of new issues, now related to fork/execve.
> 
> 1) With a fork() followed by execve(), the child process makes a copy of the
> parent mm_struct object, including the "hmm" pointer. Later on, an execve()
> syscall in the child process frees the old mm_struct, and destroys the "hmm"
> object - which apparently it shouldn't do, because the "hmm" object is
> shared between the parent and child processes:
> 
> (gdb) bt
> #0  hmm_mm_destroy (mm=0x88080757aa40) at mm/hmm.c:134
> #1  0x81058567 in __mmdrop (mm=0x88080757aa40) at
> kernel/fork.c:889
> #2  0x8105904f in mmdrop (mm=) at
> ./include/linux/sched/mm.h:42
> #3  __mmput (mm=) at kernel/fork.c:916
> #4  mmput (mm=0x88080757aa40) at kernel/fork.c:927
> #5  0x811c5a68 in exec_mmap (mm=) at fs/exec.c:1057
> #6  flush_old_exec (bprm=) at fs/exec.c:1284
> #7  0x81214460 in load_elf_binary (bprm=0x8808133b1978) at
> fs/binfmt_elf.c:855
> #8  0x811c4fce in search_binary_handler (bprm=0x88081b40cb78) at
> fs/exec.c:1625
> #9  0x811c6bbf in exec_binprm (bprm=) at
> fs/exec.c:1667
> #10 do_execveat_common (fd=, filename=0x88080a101200,
> flags=0x0, argv=..., envp=...) at fs/exec.c:1789
> #11 0x811c6fda in do_execve (__envp=,
> __argv=, filename=) at fs/exec.c:1833
> #12 SYSC_execve (envp=, argv=,
> filename=) at fs/exec.c:1914
> #13 SyS_execve (filename=, argv=0x7f4e5c2aced0,
> envp=0x7f4e5c2aceb0) at fs/exec.c:1909
> #14 0x810018dd in do_syscall_64 (regs=0x88081b40cb78) at
> arch/x86/entry/common.c:284
> #15 0x819e2c06 in entry_SYSCALL_64 () at
> arch/x86/entry/entry_64.S:245
> 
> This leads to a sporadic memory corruption in the parent process:
> 
> Thread 200 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 3685]
> 0x811a3efe in __mmu_notifier_invalidate_range_start
> (mm=0x880807579000, start=0x7f4e5c62f000, end=0x7f4e5c66f000) at
> mm/mmu_notifier.c:199
> 199if (mn->ops->invalidate_range_start)
> (gdb) bt
> #0  0x811a3efe in __mmu_notifier_invalidate_range_start
> (mm=0x880807579000, start=0x7f4e5c62f000, end=0x7f4e5c66f000) at
> mm/mmu_notifier.c:199
> #1  0x811ae471 in mmu_notifier_invalidate_range_start
> (end=, start=, mm=) at
> ./include/linux/mmu_notifier.h:282
> #2  migrate_vma_collect (migrate=0xc90003ca3940) at mm/migrate.c:2280
> #3  0x811b04a7 in migrate_vma (ops=,
> vma=0x7f4e5c62f000, start=0x7f4e5c62f000, end=0x7f4e5c66f000,
> src=0xc90003ca39d0, dst=0xc90003ca39d0, private=0xc90003ca39c0)
> at mm/migrate.c:2819
> (gdb) p mn->ops
> $2 = (const struct mmu_notifier_ops *) 0x6b6b6b6b6b6b6b6b
> 
> Please see attached a reproducer (sanity_rmem004_fork.tgz). Use "./build.sh;
> sudo ./kload.sh; ./run.sh" to recreate the issue on your end.
> 
> 
> 2) A slight modification of the affected application does not use fork().
> Instead, an execve() call from a parallel thread replaces the original
> process. This is a particularly interesting case, because at that point the
> process is busy migrating pages to/from device.
> 
> Here's what happens:
> 
> 0x811b9879 in commit_charge (page=,
> lrucare=, memcg=) at mm/memcontrol.c:2060
> 2060VM_BUG_ON_PAGE(page->mem_cgroup, page);
> (gdb) bt
> #0  0x811b9879 in commit_charge (page=,
> lrucare=, memcg=) at mm/memcontrol.c:2060
> #1  0x811b93d6 in commit_charge (lrucare=,
> memcg=, page=) at
> ./include/linux/page-flags.h:149
> #2  mem_cgroup_commit_charge (page=0x88081b68cb70,
> memcg=0x88081b051548, lrucare=, compound=)
> at mm/memcontrol.c:5468
> #3  0x811b10d4 in migrate_vma_insert_page (migrate=,
> dst=, src=, page=,
> addr=) at mm/migrate.c:2605
> #4  migrate_vma_pages (migrate=) at mm/migrate.c:2647
> #5  migrate_vma (ops=, vma=, start= out>, end=, src=, dst=,
> private=0xc900037439c0) at mm/migrate.c:2844
> 
> 
> Please find another reproducer attached (sanity_rmem004_execve.tgz) for this
> issue.
> 

So i pushed an updated hmm-next branch it should have all fixes so far, 
including
something that should fix this issue. I still want to go over all emails again
to make sure i am not forgetting anything.

Cheers,
Jérôme


[PATCH] docs: submitting-patches - change non-ascii character to ascii

2017-07-20 Thread frowand . list
From: Frank Rowand 

Documentation/process/submitting-patches.rst contains a non-ascii
character.  Change it to the ascii equivalent.

Signed-off-by: Frank Rowand 
---
 Documentation/process/submitting-patches.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/process/submitting-patches.rst 
b/Documentation/process/submitting-patches.rst
index 3e10719fee35..733478ade91b 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -413,7 +413,7 @@ e-mail discussions.
 
 
 
-11) Sign your work — the Developer's Certificate of Origin
+11) Sign your work - the Developer's Certificate of Origin
 --
 
 To improve tracking of who did what, especially with patches that can
-- 
Frank Rowand 



RE: [BISECTED,REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

2017-07-20 Thread Clayton Craft

Well, I tried that (attached), but it didn't work either. For some
reason the error worker seems to stop after the disable. Possibly the
irq flood keeps it from running, so maybe it should catch all the errors
(I see underflows too).

Sorry, but I can't use more time on this today, and I'm leaving for
vacation today. I hope Laurent can help during my absence.

We could try reverting the patch you mention, but I think it doesn't
cause the problem.

Did you have CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled earlier when
things worked? If you didn't, and the dts did not contain display
aliases, I think the omapdrm may have started without TV. So maybe the
TV side is the culprit, somehow (I couldn't find anything when I looked
at that side either).


Just curious if any progress has been made on this issue. It's still
happening with 4.13-rc1, and it doesn't look like any of the suspect
patches were reverted.


signature.asc
Description: PGP signature


linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2017-07-20 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_pm.c

between commit:

  9cc5bb18bd0a ("drm/i915: Fix bad comparison in skl_compute_plane_wm")

from the drm-intel-fixes tree and commit:

  eac2cb81fb87 ("drm/i915: cleanup fixed-point wrappers naming")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_pm.c
index 40b224b44d1b,ee2a349cfe68..
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@@ -4463,11 -4459,11 +4459,11 @@@ static int skl_compute_plane_wm(const s
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
 -  else if ((ddb_allocation && ddb_allocation /
 -  fixed16_to_u32_round_up(plane_blocks_per_line)) >= 1)
 +  else if (ddb_allocation >=
-fixed_16_16_to_u32_round_up(plane_blocks_per_line))
-   selected_result = min_fixed_16_16(method1, method2);
++   fixed16_to_u32_round_up(plane_blocks_per_line))
+   selected_result = min_fixed16(method1, method2);
else if (latency >= linetime_us)
-   selected_result = min_fixed_16_16(method1, method2);
+   selected_result = min_fixed16(method1, method2);
else
selected_result = method1;
}


[for-next][PATCH 0/3] tracing: Updates for 4.13-rc2

2017-07-20 Thread Steven Rostedt
  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: f86f418059b94aa01f9342611a272ca60c583e89


Chunyan Zhang (1):
  trace: fix the errors caused by incompatible type of RCU variables

Chunyu Hu (1):
  tracing: Fix kmemleak in instance_rmdir

Joel Fernandes (1):
  tracing/ring_buffer: Try harder to allocate


 include/linux/ftrace.h   |  6 +++---
 include/linux/trace_events.h |  2 +-
 kernel/trace/ftrace.c| 41 +++--
 kernel/trace/ring_buffer.c   | 10 +-
 kernel/trace/trace.c |  1 +
 kernel/trace/trace.h |  6 +++---
 6 files changed, 40 insertions(+), 26 deletions(-)


[for-next][PATCH 3/3] trace: fix the errors caused by incompatible type of RCU variables

2017-07-20 Thread Steven Rostedt
From: Chunyan Zhang 

The variables which are processed by RCU functions should be annotated
as RCU, otherwise sparse will report the errors like below:

"error: incompatible types in comparison expression (different
address spaces)"

Link: 
http://lkml.kernel.org/r/1496823171-7758-1-git-send-email-zhang.chun...@linaro.org

Signed-off-by: Chunyan Zhang 
[ Updated to not be 100% 80 column strict ]
Signed-off-by: Steven Rostedt (VMware) 
---
 include/linux/ftrace.h   |  6 +++---
 include/linux/trace_events.h |  2 +-
 kernel/trace/ftrace.c| 41 +++--
 kernel/trace/trace.h |  6 +++---
 4 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 5857390ac35a..6383115e9d2c 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -145,8 +145,8 @@ enum {
 #ifdef CONFIG_DYNAMIC_FTRACE
 /* The hash used to know what functions callbacks trace */
 struct ftrace_ops_hash {
-   struct ftrace_hash  *notrace_hash;
-   struct ftrace_hash  *filter_hash;
+   struct ftrace_hash __rcu*notrace_hash;
+   struct ftrace_hash __rcu*filter_hash;
struct mutexregex_lock;
 };
 
@@ -168,7 +168,7 @@ static inline void ftrace_free_init_mem(void) { }
  */
 struct ftrace_ops {
ftrace_func_t   func;
-   struct ftrace_ops   *next;
+   struct ftrace_ops __rcu *next;
unsigned long   flags;
void*private;
ftrace_func_t   saved_func;
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index f73cedfa2e0b..536c80ff7ad9 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -338,7 +338,7 @@ enum {
 struct trace_event_file {
struct list_headlist;
struct trace_event_call *event_call;
-   struct event_filter *filter;
+   struct event_filter __rcu   *filter;
struct dentry   *dir;
struct trace_array  *tr;
struct trace_subsystem_dir  *system;
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 53f6b6401cf0..02004ae91860 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -113,7 +113,7 @@ static int ftrace_disabled __read_mostly;
 
 static DEFINE_MUTEX(ftrace_lock);
 
-static struct ftrace_ops *ftrace_ops_list __read_mostly = _list_end;
+static struct ftrace_ops __rcu *ftrace_ops_list __read_mostly = 
_list_end;
 ftrace_func_t ftrace_trace_function __read_mostly = ftrace_stub;
 static struct ftrace_ops global_ops;
 
@@ -169,8 +169,11 @@ int ftrace_nr_registered_ops(void)
 
mutex_lock(_lock);
 
-   for (ops = ftrace_ops_list;
-ops != _list_end; ops = ops->next)
+   for (ops = rcu_dereference_protected(ftrace_ops_list,
+lockdep_is_held(_lock));
+ops != _list_end;
+ops = rcu_dereference_protected(ops->next,
+lockdep_is_held(_lock)))
cnt++;
 
mutex_unlock(_lock);
@@ -275,10 +278,11 @@ static void update_ftrace_function(void)
 * If there's only one ftrace_ops registered, the ftrace_ops_list
 * will point to the ops we want.
 */
-   set_function_trace_op = ftrace_ops_list;
+   set_function_trace_op = rcu_dereference_protected(ftrace_ops_list,
+   lockdep_is_held(_lock));
 
/* If there's no ftrace_ops registered, just call the stub function */
-   if (ftrace_ops_list == _list_end) {
+   if (set_function_trace_op == _list_end) {
func = ftrace_stub;
 
/*
@@ -286,7 +290,8 @@ static void update_ftrace_function(void)
 * recursion safe and not dynamic and the arch supports passing ops,
 * then have the mcount trampoline call the function directly.
 */
-   } else if (ftrace_ops_list->next == _list_end) {
+   } else if (rcu_dereference_protected(ftrace_ops_list->next,
+   lockdep_is_held(_lock)) == _list_end) {
func = ftrace_ops_get_list_func(ftrace_ops_list);
 
} else {
@@ -348,9 +353,11 @@ int using_ftrace_ops_list_func(void)
return ftrace_trace_function == ftrace_ops_list_func;
 }
 
-static void add_ftrace_ops(struct ftrace_ops **list, struct ftrace_ops *ops)
+static void add_ftrace_ops(struct ftrace_ops __rcu **list,
+  struct ftrace_ops *ops)
 {
-   ops->next = *list;
+   rcu_assign_pointer(ops->next, *list);
+
/*
 * We are entering ops into the list but another
 * CPU might be walking that list. We need to make sure
@@ -360,7 +367,8 @@ static void 

[for-next][PATCH 1/3] tracing/ring_buffer: Try harder to allocate

2017-07-20 Thread Steven Rostedt
From: Joel Fernandes 

ftrace can fail to allocate per-CPU ring buffer on systems with a large
number of CPUs coupled while large amounts of cache happening in the
page cache. Currently the ring buffer allocation doesn't retry in the VM
implementation even if direct-reclaim made some progress but still
wasn't able to find a free page. On retrying I see that the allocations
almost always succeed. The retry doesn't happen because __GFP_NORETRY is
used in the tracer to prevent the case where we might OOM, however if we
drop __GFP_NORETRY, we risk destabilizing the system if OOM killer is
triggered. To prevent this situation, use the __GFP_RETRY_MAYFAIL flag
introduced recently [1].

Tested the following still succeeds without destabilizing a system with
1GB memory.
echo 30 > /sys/kernel/debug/tracing/buffer_size_kb

[1] https://marc.info/?l=linux-mm=149820805124906=2

Link: http://lkml.kernel.org/r/20170713021416.8897-1-joe...@google.com

Cc: Tim Murray 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Acked-by: Vlastimil Babka 
Acked-by: Johannes Weiner 
Acked-by: Michal Hocko 
Signed-off-by: Joel Fernandes 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/ring_buffer.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 4ae268e687fe..529cc50d7243 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1136,12 +1136,12 @@ static int __rb_allocate_pages(long nr_pages, struct 
list_head *pages, int cpu)
for (i = 0; i < nr_pages; i++) {
struct page *page;
/*
-* __GFP_NORETRY flag makes sure that the allocation fails
-* gracefully without invoking oom-killer and the system is
-* not destabilized.
+* __GFP_RETRY_MAYFAIL flag makes sure that the allocation fails
+* gracefully without invoking oom-killer and the system is not
+* destabilized.
 */
bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
-   GFP_KERNEL | __GFP_NORETRY,
+   GFP_KERNEL | __GFP_RETRY_MAYFAIL,
cpu_to_node(cpu));
if (!bpage)
goto free_pages;
@@ -1149,7 +1149,7 @@ static int __rb_allocate_pages(long nr_pages, struct 
list_head *pages, int cpu)
list_add(>list, pages);
 
page = alloc_pages_node(cpu_to_node(cpu),
-   GFP_KERNEL | __GFP_NORETRY, 0);
+   GFP_KERNEL | __GFP_RETRY_MAYFAIL, 0);
if (!page)
goto free_pages;
bpage->page = page_address(page);
-- 
2.10.2




[for-next][PATCH 2/3] tracing: Fix kmemleak in instance_rmdir

2017-07-20 Thread Steven Rostedt
From: Chunyu Hu 

Hit the kmemleak when executing instance_rmdir, it forgot releasing
mem of tracing_cpumask. With this fix, the warn does not appear any
more.

unreferenced object 0x93a8dfaa7c18 (size 8):
  comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
  hex dump (first 8 bytes):
ff ff ff ff ff ff ff ff  
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] __kmalloc_node+0xf1/0x280
[] alloc_cpumask_var_node+0x23/0x30
[] alloc_cpumask_var+0xe/0x10
[] instance_mkdir+0x90/0x240
[] tracefs_syscall_mkdir+0x40/0x70
[] vfs_mkdir+0x109/0x1b0
[] SyS_mkdir+0xd0/0x100
[] do_syscall_64+0x67/0x150
[] return_from_SYSCALL_64+0x0/0x6a
[] 0x

Link: 
http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-ch...@redhat.com

Cc: sta...@vger.kernel.org
Fixes: ccfe9e42e451 ("tracing: Make tracing_cpumask available for all 
instances")
Signed-off-by: Chunyu Hu 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/trace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2d0ffcc49dba..42b9355033d4 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7774,6 +7774,7 @@ static int instance_rmdir(const char *name)
}
kfree(tr->topts);
 
+   free_cpumask_var(tr->tracing_cpumask);
kfree(tr->name);
kfree(tr);
 
-- 
2.10.2




Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

2017-07-20 Thread Bob Liu
On 2017/7/20 23:03, Jerome Glisse wrote:
> On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote:
>> On 2017/7/19 10:25, Jerome Glisse wrote:
>>> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote:
 On 2017/7/18 23:38, Jerome Glisse wrote:
> On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote:
>> On 2017/7/14 5:15, Jérôme Glisse wrote:
>>> Sorry i made horrible mistake on names in v4, i completly miss-
>>> understood the suggestion. So here i repost with proper naming.
>>> This is the only change since v3. Again sorry about the noise
>>> with v4.
>>>
>>> Changes since v4:
>>>   - s/DEVICE_HOST/DEVICE_PUBLIC
>>>
>>> Git tree:
>>> https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-cdm-v5
>>>
>>>
>>> Cache coherent device memory apply to architecture with system bus
>>> like CAPI or CCIX. Device connected to such system bus can expose
>>> their memory to the system and allow cache coherent access to it
>>> from the CPU.
>>>
>>> Even if for all intent and purposes device memory behave like regular
>>> memory, we still want to manage it in isolation from regular memory.
>>> Several reasons for that, first and foremost this memory is less
>>> reliable than regular memory if the device hangs because of invalid
>>> commands we can loose access to device memory. Second CPU access to
>>> this memory is expected to be slower than to regular memory. Third
>>> having random memory into device means that some of the bus bandwith
>>> wouldn't be available to the device but would be use by CPU access.
>>>
>>> This is why we want to manage such memory in isolation from regular
>>> memory. Kernel should not try to use this memory even as last resort
>>> when running out of memory, at least for now.
>>>
>>
>> I think set a very large node distance for "Cache Coherent Device Memory"
>> may be a easier way to address these concerns.
>
> Such approach was discuss at length in the past see links below. Outcome
> of discussion:
>   - CPU less node are bad
>   - device memory can be unreliable (device hang) no way for application
> to understand that

 Device memory can also be more reliable if using high quality and 
 expensive memory.
>>>
>>> Even ECC memory does not compensate for device hang. When your GPU lockups
>>> you might need to re-init GPU from scratch after which the content of the
>>> device memory is unreliable. During init the device memory might not get
>>> proper clock or proper refresh cycle and thus is susceptible to corruption.
>>>

>   - application and driver NUMA madvise/mbind/mempolicy ... can conflict
> with each other and no way the kernel can figure out which should
> apply
>   - NUMA as it is now would not work as we need further isolation that
> what a large node distance would provide
>

 Agree, that's where we need spend time on.

 One drawback of HMM-CDM I'm worry about is one more extra copy.
 In the cache coherent case, CPU can write data to device memory
 directly then start fpga/GPU/other accelerators.
>>>
>>> There is not necessarily an extra copy. Device driver can pre-allocate
>>> virtual address range of a process with device memory. Device page fault
>>
>> Okay, I get your point. But the typical use case is CPU allocate a memory
>> and prepare/write data then launch GPU "cuda kernel".
> 
> I don't think we should make to many assumption on what is typical case.
> GPU compute is fast evolving and they are new domains where it is apply
> for instance some folks use it to process network stream and the network
> adapter directly write into GPU memory so there is never a CPU copy of
> it. So i rather not make any restrictive assumption on how it will be use.
> 
>> How to control the allocation go to device memory e.g HBM or system
>> DDR at the beginning without user explicit advise? If goes to DDR by
>> default, there is an extra copy. If goes to HBM by default, the HBM
>> may be waste.
> 
> Yes it is a hard problem to solve. We are working with NVidia and IBM
> on this and there are several path. But as first solution we will rely
> on hint/directive given by userspace program through existing GPGPU API
> like CUDA or OpenCL. They are plan to have hardware monitor bus traffic
> to gather statistics and do automatic memory placement from thos.
> 
> 
>>> can directly allocate device memory. Once allocated CPU access will use
>>> the device memory.
>>>
>>
>> Then it's more like replace the numa node solution(CDM) with ZONE_DEVICE
>> (type MEMORY_DEVICE_PUBLIC). But the problem is the same, e.g how to make
>> sure the device memory say HBM won't be occupied by normal CPU allocation.
>> Things will be more complex if there are multi GPU connected by nvlink
>> (also cache coherent) in a system, each GPU has their own HBM.
>>
>> How to 

Re: [PATCH RESEND] ARM64: dts: meson-gxl-s905x-libretech-cc: fixup board definition

2017-07-20 Thread Kevin Hilman
Jerome Brunet  writes:

> The libretech CC derives less from the p212 than initially thought.
> Several voltage regulators are different and the capabilities of the
> sdcard and emmc also differ.
>
> Deriving from the p212 is not convient anymore so the libretech is now
> derived from s905x definition directly.
>
> Fixes: cd84aff1d981 ("ARM64: dts: meson-gxl: Add Libre Technology CC support")
> Signed-off-by: Jerome Brunet 

Applied to v4.13/fixes,

Kevin


Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

2017-07-20 Thread Evgeny Baskakov

On 7/14/17 5:55 PM, Jerome Glisse wrote:


...

Cheers,
Jérôme


Hi Jerome,

I think I just found a couple of new issues, now related to fork/execve.

1) With a fork() followed by execve(), the child process makes a copy of 
the parent mm_struct object, including the "hmm" pointer. Later on, an 
execve() syscall in the child process frees the old mm_struct, and 
destroys the "hmm" object - which apparently it shouldn't do, because 
the "hmm" object is shared between the parent and child processes:


(gdb) bt
#0  hmm_mm_destroy (mm=0x88080757aa40) at mm/hmm.c:134
#1  0x81058567 in __mmdrop (mm=0x88080757aa40) at 
kernel/fork.c:889
#2  0x8105904f in mmdrop (mm=) at 
./include/linux/sched/mm.h:42

#3  __mmput (mm=) at kernel/fork.c:916
#4  mmput (mm=0x88080757aa40) at kernel/fork.c:927
#5  0x811c5a68 in exec_mmap (mm=) at fs/exec.c:1057
#6  flush_old_exec (bprm=) at fs/exec.c:1284
#7  0x81214460 in load_elf_binary (bprm=0x8808133b1978) at 
fs/binfmt_elf.c:855
#8  0x811c4fce in search_binary_handler 
(bprm=0x88081b40cb78) at fs/exec.c:1625
#9  0x811c6bbf in exec_binprm (bprm=) at 
fs/exec.c:1667
#10 do_execveat_common (fd=, filename=0x88080a101200, 
flags=0x0, argv=..., envp=...) at fs/exec.c:1789
#11 0x811c6fda in do_execve (__envp=, 
__argv=, filename=) at fs/exec.c:1833
#12 SYSC_execve (envp=, argv=, 
filename=) at fs/exec.c:1914
#13 SyS_execve (filename=, argv=0x7f4e5c2aced0, 
envp=0x7f4e5c2aceb0) at fs/exec.c:1909
#14 0x810018dd in do_syscall_64 (regs=0x88081b40cb78) at 
arch/x86/entry/common.c:284
#15 0x819e2c06 in entry_SYSCALL_64 () at 
arch/x86/entry/entry_64.S:245


This leads to a sporadic memory corruption in the parent process:

Thread 200 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3685]
0x811a3efe in __mmu_notifier_invalidate_range_start 
(mm=0x880807579000, start=0x7f4e5c62f000, end=0x7f4e5c66f000) at 
mm/mmu_notifier.c:199

199if (mn->ops->invalidate_range_start)
(gdb) bt
#0  0x811a3efe in __mmu_notifier_invalidate_range_start 
(mm=0x880807579000, start=0x7f4e5c62f000, end=0x7f4e5c66f000) at 
mm/mmu_notifier.c:199
#1  0x811ae471 in mmu_notifier_invalidate_range_start 
(end=, start=, mm=) at 
./include/linux/mmu_notifier.h:282

#2  migrate_vma_collect (migrate=0xc90003ca3940) at mm/migrate.c:2280
#3  0x811b04a7 in migrate_vma (ops=, 
vma=0x7f4e5c62f000, start=0x7f4e5c62f000, end=0x7f4e5c66f000, 
src=0xc90003ca39d0, dst=0xc90003ca39d0, 
private=0xc90003ca39c0) at mm/migrate.c:2819

(gdb) p mn->ops
$2 = (const struct mmu_notifier_ops *) 0x6b6b6b6b6b6b6b6b

Please see attached a reproducer (sanity_rmem004_fork.tgz). Use 
"./build.sh; sudo ./kload.sh; ./run.sh" to recreate the issue on your end.



2) A slight modification of the affected application does not use 
fork(). Instead, an execve() call from a parallel thread replaces the 
original process. This is a particularly interesting case, because at 
that point the process is busy migrating pages to/from device.


Here's what happens:

0x811b9879 in commit_charge (page=, 
lrucare=, memcg=) at mm/memcontrol.c:2060

2060VM_BUG_ON_PAGE(page->mem_cgroup, page);
(gdb) bt
#0  0x811b9879 in commit_charge (page=, 
lrucare=, memcg=) at mm/memcontrol.c:2060
#1  0x811b93d6 in commit_charge (lrucare=, 
memcg=, page=) at 
./include/linux/page-flags.h:149
#2  mem_cgroup_commit_charge (page=0x88081b68cb70, 
memcg=0x88081b051548, lrucare=, compound=out>) at mm/memcontrol.c:5468
#3  0x811b10d4 in migrate_vma_insert_page (migrate=out>, dst=, src=, page=, 
addr=) at mm/migrate.c:2605

#4  migrate_vma_pages (migrate=) at mm/migrate.c:2647
#5  migrate_vma (ops=, vma=, 
start=, end=, src=, 
dst=, private=0xc900037439c0) at mm/migrate.c:2844



Please find another reproducer attached (sanity_rmem004_execve.tgz) for 
this issue.


Thanks!

--
Evgeny Baskakov
NVIDIA



sanity_rmem004_execve.tgz
Description: GNU Zip compressed data


sanity_rmem004_fork.tgz
Description: GNU Zip compressed data


RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

2017-07-20 Thread Mani, Rajmohan
Hi Lee,

Thanks for the reviews.

> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: Thursday, July 20, 2017 2:03 AM
> To: Mani, Rajmohan 
> Cc: linux-kernel@vger.kernel.org; linux-g...@vger.kernel.org; linux-
> a...@vger.kernel.org; Linus Walleij ; Alexandre
> Courbot ; Rafael J. Wysocki ; Len
> Brown ; sakari.ai...@linux.intel.com; Andy Shevchenko
> 
> Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470
> 
> On Wed, 19 Jul 2017, Rajmohan Mani wrote:
> 
> > The TPS68470 device is an advanced power management unit that powers
> a
> > Compact Camera Module (CCM), generates clocks for image sensors,
> > drives a dual LED for Flash and incorporates two LED drivers for
> > general purpose indicators.
> >
> > This patch adds support for TPS68470 mfd device.
> >
> > Signed-off-by: Rajmohan Mani 
> > ---
> >  drivers/mfd/Kconfig  |  18 +++
> >  drivers/mfd/Makefile |   1 +
> >  drivers/mfd/tps68470.c   | 110
> +++
> >  include/linux/mfd/tps68470.h |  97
> > ++
> >  4 files changed, 226 insertions(+)
> >  create mode 100644 drivers/mfd/tps68470.c  create mode 100644
> > include/linux/mfd/tps68470.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index
> > 3eb5c93..960be43 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -1311,6 +1311,24 @@ config MFD_TPS65217
> >   This driver can also be built as a module.  If so, the module
> >   will be called tps65217.
> >
> > +config MFD_TPS68470
> > +   bool "TI TPS68470 Power Management / LED chips"
> > +   depends on ACPI && I2C=y
> > +   select MFD_CORE
> > +   select REGMAP_I2C
> > +   select I2C_DESIGNWARE_PLATFORM
> > +   help
> > + If you say yes here you get support for the TPS68470 series of
> > + Power Management / LED chips.
> > +
> > + These include voltage regulators, led and other features
> 
> LED(s)
> 

Ack

> > + that are often used in portable devices.
> > +
> > + This option is a bool as it provides an ACPI operation
> > + region, which must be available before any of the devices
> > + using this, are probed. This option also configures the
> 
> Remove the ','.
> 

Ack

> > + designware-i2c driver to be builtin, for the same reason.
> 
> built-in
> 

Ack

> > +
> >  config MFD_TI_LP873X
> > tristate "TI LP873X Power Management IC"
> > depends on I2C
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> > c16bf1e..6dd2b94 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -82,6 +82,7 @@ obj-$(CONFIG_MFD_TPS65910)+= tps65910.o
> >  obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
> >  obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
> >  obj-$(CONFIG_MFD_TPS65912_SPI)  += tps65912-spi.o
> > +obj-$(CONFIG_MFD_TPS68470) += tps68470.o
> >  obj-$(CONFIG_MFD_TPS80031) += tps80031.o
> >  obj-$(CONFIG_MENELAUS) += menelaus.o
> >
> > diff --git a/drivers/mfd/tps68470.c b/drivers/mfd/tps68470.c new file
> > mode 100644 index 000..a692af7
> > --- /dev/null
> > +++ b/drivers/mfd/tps68470.c
> > @@ -0,0 +1,110 @@
> > +/*
> > + * TPS68470 chip family multi-function driver
> 
> Does it really cover a family?  If so 'TPS68470' seems very specific.
> 
> "Multi-Function Driver" or even better "Core" or "Parent" driver.
> 

No. This is just for TPS68470.
I picked "Parent" driver

> > + * Copyright (C) 2017 Intel Corporation
> 
> '\n' here.
> 

Ack

> > + * Authors:
> > + * Rajmohan Mani 
> > + * Tianshu Qiu 
> > + * Jian Xu Zheng 
> > + * Yuning Pu 
> 
> Tab these out:
> 
>  * Authors:
>  *Rajmohan Mani 
>  *Tianshu Qiu 
>  *Jian Xu Zheng 
>  *Yuning Pu 
> 

Ack

> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied
> > + warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> 
> Can you use the short version?
> 

Ack
I will update the other patches of this series too.

> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const struct mfd_cell tps68470s[] = {
> > +   {
> > +   .name = "tps68470-gpio",
> > +   },
> > +   {
> > +   .name = 

Re: [PATCH RESEND] ARM64: dts: meson-gx: use specific compatible for the AO pwms

2017-07-20 Thread Kevin Hilman
Jerome Brunet  writes:

> Use the specific compatible for AO pwms so the pwms input can
> be correctly set
>
> FDIV4 is not present on the pwm A0, so change kadhas vim input
> clocks to xtal.
>
> Signed-off-by: Jerome Brunet 

Adding this to fixes v4.13-rc since the PWM driver is now merged.

Kevin


[PATCH] driver core: restrict buffer length in online_store()

2017-07-20 Thread Tiezhu Yang
According to Documentation/ABI/testing/sysfs-devices-online, in order to
control CPU N's hotplug state, we should write one of 'Yy1Nn0' to the file
/sys/devices/system/cpu/cpuN/online, other values should be invalid. so the
buffer length should be 2, buf[0] is one of 'Yy1Nn0' and buf[1] is '\n'.

without patch:
[root@localhost home]# echo 0test > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
0
[root@localhost home]# echo 1test > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
1
[root@localhost home]# echo ntest > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
0
[root@localhost home]# echo ytest > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
1
[root@localhost home]# echo Ntest > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
0
[root@localhost home]# echo Ytest > /sys/devices/system/cpu/cpu1/online
[root@localhost home]# cat /sys/devices/system/cpu/cpu1/online
1

with patch:
[root@localhost home]# echo 0test > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
[root@localhost home]# echo 1test > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
[root@localhost home]# echo ntest > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
[root@localhost home]# echo ytest > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
[root@localhost home]# echo Ntest > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument
[root@localhost home]# echo Ytest > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Invalid argument

Signed-off-by: Tiezhu Yang 
---
 drivers/base/core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 755451f..6588ed5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1005,6 +1005,12 @@ static ssize_t online_store(struct device *dev, struct 
device_attribute *attr,
bool val;
int ret;
 
+   /* According to Documentation/ABI/testing/sysfs-devices-online,
+* the buf length should be 2, buf[0]: one of 'Yy1Nn0', buf[1]: '\n'.
+*/
+   if (strlen(buf) != 2)
+   return -EINVAL;
+
ret = strtobool(buf, );
if (ret < 0)
return ret;
-- 
1.8.3.1

Re: cpuidle and cpufreq coupling?

2017-07-20 Thread Florian Fainelli
On 07/20/2017 05:11 PM, Vikram Mulukutla wrote:
> On 7/20/2017 3:56 PM, Florian Fainelli wrote:
>> On 07/20/2017 07:45 AM, Peter Zijlstra wrote:
> 
> 
> 
>>>
>>> Can your ARM part change OPP without scheduling? Because (for obvious
>>> reasons) the idle thread is not supposed to block.
>>
>> I think it should be able to do that, but I am not sure that if I went
>> through the cpufreq API it would be that straight forward so I may have
>> to re-implement some of the frequency scaling logic outside of cpufreq
>> (or rather make the low-level parts some kind of library I guess).
>>
> 
> I think I can safely mention that some of our non-upstream idle drivers
> in the past have invoked low level clock drivers to atomically switch
> CPUs to low frequency OPPs, with no interaction whatsoever with cpufreq.
> It was maintainable since both the idle and clock drivers were
> qcom-specific. However this is no longer necessary in recent designs and
> I really hope we never need to do this again...

Yes same here, this is for a past generation product, current generation
has a smarter design that so far does not require that.

> 
> We didn't have to do a voltage switch and just PLL or mux
> work so this was doable. I'm guessing your atomic switching also allows
> voltage reduction?

Correct there is a voltage reduction occurring which is largely under
control of a separate MCU/firmware.

> 
> If your architecture allows another CPU to change the entering-idle CPU's
> frequency, synchronization will be necessary as well - this is where it
> can get a bit tricky.

That is a very good point, the frequency scaling is not per-CPU but for
the entire CPU complex (up to 4 cores) so that might indeed be a problem.

Thanks!
-- 
Florian


[PATCH] Fix Alps Touchpad two finger scroll does not work on right side

2017-07-20 Thread Masaki Ota
From: Masaki Ota 

Fixed the issue that two finger scroll does not work correctly
on V8 protocol. The cause is that V8 protocol X-coordinate decode
is wrong at SS4 PLUS device. I added SS4 PLUS X decode definition.

Signed-off-by: Masaki Ota 
Tested-by: Takashi Iwai 
---
 drivers/input/mouse/alps.c | 41 +++--
 drivers/input/mouse/alps.h |  8 
 2 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index f210e19ddba6..2627c724bb7c 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -1210,14 +1210,24 @@ static int alps_decode_ss4_v2(struct alps_fields *f,
 
case SS4_PACKET_ID_TWO:
if (priv->flags & ALPS_BUTTONPAD) {
-   f->mt[0].x = SS4_BTL_MF_X_V2(p, 0);
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
+   f->mt[0].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
+   } else {
+   f->mt[0].x = SS4_BTL_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_BTL_MF_X_V2(p, 1);
+   }
f->mt[0].y = SS4_BTL_MF_Y_V2(p, 0);
-   f->mt[1].x = SS4_BTL_MF_X_V2(p, 1);
f->mt[1].y = SS4_BTL_MF_Y_V2(p, 1);
} else {
-   f->mt[0].x = SS4_STD_MF_X_V2(p, 0);
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
+   f->mt[0].x = SS4_PLUS_STD_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_PLUS_STD_MF_X_V2(p, 1);
+   } else {
+   f->mt[0].x = SS4_STD_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_STD_MF_X_V2(p, 1);
+   }
f->mt[0].y = SS4_STD_MF_Y_V2(p, 0);
-   f->mt[1].x = SS4_STD_MF_X_V2(p, 1);
f->mt[1].y = SS4_STD_MF_Y_V2(p, 1);
}
f->pressure = SS4_MF_Z_V2(p, 0) ? 0x30 : 0;
@@ -1234,16 +1244,27 @@ static int alps_decode_ss4_v2(struct alps_fields *f,
 
case SS4_PACKET_ID_MULTI:
if (priv->flags & ALPS_BUTTONPAD) {
-   f->mt[2].x = SS4_BTL_MF_X_V2(p, 0);
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
+   f->mt[0].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
+   } else {
+   f->mt[2].x = SS4_BTL_MF_X_V2(p, 0);
+   f->mt[3].x = SS4_BTL_MF_X_V2(p, 1);
+   }
+
f->mt[2].y = SS4_BTL_MF_Y_V2(p, 0);
-   f->mt[3].x = SS4_BTL_MF_X_V2(p, 1);
f->mt[3].y = SS4_BTL_MF_Y_V2(p, 1);
no_data_x = SS4_MFPACKET_NO_AX_BL;
no_data_y = SS4_MFPACKET_NO_AY_BL;
} else {
-   f->mt[2].x = SS4_STD_MF_X_V2(p, 0);
+   if (IS_SS4PLUS_DEV(priv->dev_id)) {
+   f->mt[0].x = SS4_PLUS_STD_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_PLUS_STD_MF_X_V2(p, 1);
+   } else {
+   f->mt[0].x = SS4_STD_MF_X_V2(p, 0);
+   f->mt[1].x = SS4_STD_MF_X_V2(p, 1);
+   }
f->mt[2].y = SS4_STD_MF_Y_V2(p, 0);
-   f->mt[3].x = SS4_STD_MF_X_V2(p, 1);
f->mt[3].y = SS4_STD_MF_Y_V2(p, 1);
no_data_x = SS4_MFPACKET_NO_AX;
no_data_y = SS4_MFPACKET_NO_AY;
@@ -2536,8 +2557,8 @@ static int alps_set_defaults_ss4_v2(struct psmouse 
*psmouse,
 
memset(otp, 0, sizeof(otp));
 
-   if (alps_get_otp_values_ss4_v2(psmouse, 0, [0][0]) ||
-   alps_get_otp_values_ss4_v2(psmouse, 1, [1][0]))
+   if (alps_get_otp_values_ss4_v2(psmouse, 1, [1][0]) ||
+   alps_get_otp_values_ss4_v2(psmouse, 0, [0][0]))
return -1;
 
alps_update_device_area_ss4_v2(otp, priv);
diff --git a/drivers/input/mouse/alps.h b/drivers/input/mouse/alps.h
index 4334f2805d93..75542199edda 100644
--- a/drivers/input/mouse/alps.h
+++ b/drivers/input/mouse/alps.h
@@ -99,6 +99,10 @@ enum SS4_PACKET_ID {
 ((_b[1 + _i * 3]  << 5) & 0x1F00)  \
)
 
+#define SS4_PLUS_STD_MF_X_V2(_b, _i) (((_b[0 + (_i) * 3] << 4) & 0x0070) | \
+((_b[1 + (_i) * 3]  << 4) & 0x0F80)\
+   )
+
 #define SS4_STD_MF_Y_V2(_b, _i)(((_b[1 + (_i) * 3] << 3) & 0x0010) |   
\
  

Re: [PATCH] documentation: Fix two-CPU control-dependency example

2017-07-20 Thread Boqun Feng
On Thu, Jul 20, 2017 at 04:07:14PM -0700, Paul E. McKenney wrote:
[...]
> > 
> > So if I respin the patch with the extern, would you still feel reluctant?
> 
> Yes, because I am not seeing how this change helps.  What is this telling
> the reader that the original did not, and how does it help the reader
> generate good concurrent code?
> 

One thing I think we probably should do is to make READ_ONCE() semantics
more clear, i.e. call it out that in our conceptual model for kernel
programming we always rely on the compiler to be serious about the
return value of READ_ONCE(). I didn't find the comment before
READ_ONCE() or memory-barriers.txt talking about something similar.

Or am I the only one having this kinda semantics guarantee in mind?

Regards,
Boqun

>   Thanx, Paul
> 


[PATCH 2/4] PM / core: Split dpm_suspend_noirq() and dpm_resume_noirq()

2017-07-20 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Put the device interrupts disabling and enabling as well as
cpuidle_pause() and cpuidle_resume() called during the "noirq"
stages of system suspend into separate functions to allow the
core suspend-to-idle code to be optimized (later).

The only functional difference this makes is that debug facilities
and diagnostic tools will not include the above operations into the
"noirq" device suspend/resume duration measurements.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |   67 +++---
 include/linux/pm.h|4 ++
 2 files changed, 50 insertions(+), 21 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -598,14 +598,7 @@ static void async_resume_noirq(void *dat
put_device(dev);
 }
 
-/**
- * dpm_resume_noirq - Execute "noirq resume" callbacks for all devices.
- * @state: PM transition of the system being carried out.
- *
- * Call the "noirq" resume handlers for all devices in dpm_noirq_list and
- * enable device drivers to receive interrupts.
- */
-void dpm_resume_noirq(pm_message_t state)
+void dpm_noirq_resume_devices(pm_message_t state)
 {
struct device *dev;
ktime_t starttime = ktime_get();
@@ -651,10 +644,27 @@ void dpm_resume_noirq(pm_message_t state
mutex_unlock(_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, "noirq");
+   trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
+}
+
+void dpm_noirq_end(void)
+{
resume_device_irqs();
device_wakeup_disarm_wake_irqs();
cpuidle_resume();
-   trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
+}
+
+/**
+ * dpm_resume_noirq - Execute "noirq resume" callbacks for all devices.
+ * @state: PM transition of the system being carried out.
+ *
+ * Invoke the "noirq" resume callbacks for all devices in dpm_noirq_list and
+ * allow device drivers' interrupt handlers to be called.
+ */
+void dpm_resume_noirq(pm_message_t state)
+{
+   dpm_noirq_resume_devices(state);
+   dpm_noirq_end();
 }
 
 /**
@@ -1154,22 +1164,19 @@ static int device_suspend_noirq(struct d
return __device_suspend_noirq(dev, pm_transition, false);
 }
 
-/**
- * dpm_suspend_noirq - Execute "noirq suspend" callbacks for all devices.
- * @state: PM transition of the system being carried out.
- *
- * Prevent device drivers from receiving interrupts and call the "noirq" 
suspend
- * handlers for all non-sysdev devices.
- */
-int dpm_suspend_noirq(pm_message_t state)
+void dpm_noirq_begin(void)
+{
+   cpuidle_pause();
+   device_wakeup_arm_wake_irqs();
+   suspend_device_irqs();
+}
+
+int dpm_noirq_suspend_devices(pm_message_t state)
 {
ktime_t starttime = ktime_get();
int error = 0;
 
trace_suspend_resume(TPS("dpm_suspend_noirq"), state.event, true);
-   cpuidle_pause();
-   device_wakeup_arm_wake_irqs();
-   suspend_device_irqs();
mutex_lock(_list_mtx);
pm_transition = state;
async_error = 0;
@@ -1204,7 +1211,6 @@ int dpm_suspend_noirq(pm_message_t state
if (error) {
suspend_stats.failed_suspend_noirq++;
dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
-   dpm_resume_noirq(resume_event(state));
} else {
dpm_show_time(starttime, state, "noirq");
}
@@ -1213,6 +1219,25 @@ int dpm_suspend_noirq(pm_message_t state
 }
 
 /**
+ * dpm_suspend_noirq - Execute "noirq suspend" callbacks for all devices.
+ * @state: PM transition of the system being carried out.
+ *
+ * Prevent device drivers' interrupt handlers from being called and invoke
+ * "noirq" suspend callbacks for all non-sysdev devices.
+ */
+int dpm_suspend_noirq(pm_message_t state)
+{
+   int ret;
+
+   dpm_noirq_begin();
+   ret = dpm_noirq_suspend_devices(state);
+   if (ret)
+   dpm_resume_noirq(resume_event(state));
+
+   return ret;
+}
+
+/**
  * device_suspend_late - Execute a "late suspend" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -689,6 +689,8 @@ struct dev_pm_domain {
 extern void device_pm_lock(void);
 extern void dpm_resume_start(pm_message_t state);
 extern void dpm_resume_end(pm_message_t state);
+extern void dpm_noirq_resume_devices(pm_message_t state);
+extern void dpm_noirq_end(void);
 extern void dpm_resume_noirq(pm_message_t state);
 extern void dpm_resume_early(pm_message_t state);
 extern void dpm_resume(pm_message_t state);
@@ -697,6 +699,8 @@ extern void 

[PATCH 0/4] PM / suspend: Suspend-to-idle core optimization

2017-07-20 Thread Rafael J. Wysocki
Hi,

This series is on top of the one I sent a couple of days ago:

http://marc.info/?l=linux-pm=150042550025820=2

but it is mostly independent of that one.

Basically, it restores the pm_wakeup_pending() check in __suspend_device_noirq()
removed recently, which may avoid unnecessary device ping-pong if there's a
wakeup event during "noirq" suspend, and makes suspend-to-idle take that check
into account (it actually matters more for suspend-to-idle, because it may 
carry out
"noirq" phases of device suspend/resume for multiple times in one cycle).

It also makes debug messages from the core device suspend/resume code look
better on failures (or when operations are aborted by pending wakeup events).

Thanks,
Rafael



Re: [PATCH v5] printk: Add pr_info_show_time

2017-07-20 Thread Sergey Senozhatsky
On (07/20/17 11:24), Mark Salyzyn wrote:
> Primary purpose of pr_info_show_time() is to provide a marker used for
> post-mortem Battery and Power analysis.  These markers are to be
> placed at major discontinuities of time and power level.

so shouldn't that just be under CONFIG_PM_DEBUG or even
CONFIG_PM_ADVANCED_DEBUG and, hence, be implemented somewhere
in PM? I just don't see why this needs to be in printk.

without the users or (at least) examples that would demonstrate
why this is more useful than local_clock(), which we already append
to every message, it's rather hard for me to judge.

[..]
> +/*
> + * pr_info_show_time() prefixes an alternate time prefix as selected by
> + * CONFIG_PR_INFO_SHOW_TIME_.  The time is prefixed on the message
> + * as "[.] ".  in the config selection
> + * can be one of the following:
> + *
> + * MONOTONIC - (default) print no alternate time, monotonic is part of dmesg.
> + * BOOTTIME - Adds a message prefix with getboottime64() values.
> + * REALTIME - Adds a message prefix with getnstimeofday64() values.
> + */
> +#if defined(CONFIG_PR_INFO_SHOW_TIME_BOOTTIME)
> +#define pr_info_show_time(fmt, ...) ({   \
> + struct timespec64 ts;   \
> + \
> + getboottime64(); \
> + pr_info("[%5lu.%09luB] " fmt, ts.tv_sec, ts.tv_nsec, ##__VA_ARGS__); })
> +#include 
> +#elif defined(CONFIG_PR_INFO_SHOW_TIME_REALTIME)
> +#define pr_info_show_time(fmt, ...) ({   \
> + struct timespec64 ts;   \
> + \
> + getnstimeofday64();  \
> + pr_info("[%lu.%09luU] " fmt, ts.tv_sec, ts.tv_nsec, ##__VA_ARGS__); })
> +#include 
> +#else
> +#define pr_info_show_time(fmt, ...) \
> + pr_info(fmt, ##__VA_ARGS__)
> +#endif

so why just pr_info()? what about pr_err(), pr_crit() and so on?

>  /*
>   * Like KERN_CONT, pr_cont() should only be used when continuing
>   * a line with no newline ('\n') enclosed. Otherwise it defaults
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 98fe715522e8..0d63c3fb4e24 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -30,6 +30,58 @@ config CONSOLE_LOGLEVEL_DEFAULT
> usage in the kernel. That is controlled by the 
> MESSAGE_LOGLEVEL_DEFAULT
> option.
>  
> +# set if time is being printed in pr_info_show_time()
> +config PR_INFO_SHOW_TIME
> + bool

we all love Kconfig, don't we? ;)


> +choice
> + prompt "pr_info_show_time() alternate time message prefix"
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.
> + config PR_INFO_SHOW_TIME_MONOTONIC
> + bool "monotonic"
> + help
> +   Deactivate alternate time prefix in pr_info_show_time.
> +   Doing so because monotonic time is part of the normal
> +   printk time logging.
> +
> +   Print only the supplied message in pr_info_show_time,
> +   indistinguishable from pr_info.

I think this should not exist. a new Kconfig option to enable
something that is already there?


> + config PR_INFO_SHOW_TIME_REALTIME
> + bool "realtime"
> + select PR_INFO_SHOW_TIME
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.  For instance
> +   CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
> +   continues, and the timestamps help re-orient post-analysis.
> +
> +   Prefix realtime [.U] timestamp in pr_info_show_time
> + config PR_INFO_SHOW_TIME_BOOTTIME
> + bool "boottime"
> + select PR_INFO_SHOW_TIME
> + help
> +   Activate alternate time prefix in pr_info_show_time
> +
> +   The primary use of the instrumentation is to aid field
> +   analysis of Battery and Power usage.  The instrumentation
> +   may also help triage and synchronize kernel logs and user
> +   space activity logs at key displacements.  For instance
> +   CLOCK_MONOTONIC stops while suspended, while CLOCK_BOOTTIME
> +   continues, and the timestamps help re-orient post-analysis.
> +
> +   Prefix boottime [.B] timestamp in pr_info_show_time
> +endchoice


dunno, I'm still not sure I see why this "add a special prefix to some
messages" needs to be part of generic printk(). sorry.

-ss


[PATCH 1/4] PM / s2idle: Rearrange the main suspend-to-idle loop

2017-07-20 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

As a preparation for subsequent changes, rearrange the core
suspend-to-idle code by moving the initial invocation of
dpm_suspend_noirq() into s2idle_loop().

This also causes debug messages from that code to appear in
a less confusing order.

Signed-off-by: Rafael J. Wysocki 
---
 kernel/power/power.h   |4 
 kernel/power/suspend.c |   26 +-
 2 files changed, 17 insertions(+), 13 deletions(-)

Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -106,7 +106,13 @@ static void s2idle_loop(void)
 {
pm_pr_dbg("suspend-to-idle\n");
 
-   do {
+   while (!dpm_suspend_noirq(PMSG_SUSPEND)) {
+   /*
+* Suspend-to-idle equals
+* frozen processes + suspended devices + idle processors.
+* Thus freeze_enter() should be called right after
+* all devices have been suspended.
+*/
freeze_enter();
 
if (freeze_ops && freeze_ops->wake)
@@ -120,7 +126,7 @@ static void s2idle_loop(void)
break;
 
pm_wakeup_clear(false);
-   } while (!dpm_suspend_noirq(PMSG_SUSPEND));
+   }
 
pm_pr_dbg("resume from suspend-to-idle\n");
 }
@@ -377,6 +383,11 @@ static int suspend_enter(suspend_state_t
if (error)
goto Devices_early_resume;
 
+   if (state == PM_SUSPEND_FREEZE && pm_test_level != TEST_PLATFORM) {
+   s2idle_loop();
+   goto Platform_early_resume;
+   }
+
error = dpm_suspend_noirq(PMSG_SUSPEND);
if (error) {
pr_err("PM: noirq suspend of devices failed\n");
@@ -389,17 +400,6 @@ static int suspend_enter(suspend_state_t
if (suspend_test(TEST_PLATFORM))
goto Platform_wake;
 
-   /*
-* PM_SUSPEND_FREEZE equals
-* frozen processes + suspended devices + idle processors.
-* Thus we should invoke freeze_enter() soon after
-* all the devices are suspended.
-*/
-   if (state == PM_SUSPEND_FREEZE) {
-   s2idle_loop();
-   goto Platform_early_resume;
-   }
-
error = disable_nonboot_cpus();
if (error || suspend_test(TEST_CPUS))
goto Enable_cpus;
Index: linux-pm/kernel/power/power.h
===
--- linux-pm.orig/kernel/power/power.h
+++ linux-pm/kernel/power/power.h
@@ -245,7 +245,11 @@ enum {
 #define TEST_FIRST TEST_NONE
 #define TEST_MAX   (__TEST_AFTER_LAST - 1)
 
+#ifdef CONFIG_PM_DEBUG
 extern int pm_test_level;
+#else
+#define pm_test_level  (TEST_NONE)
+#endif
 
 #ifdef CONFIG_SUSPEND_FREEZER
 static inline int suspend_freeze_processes(void)



[PATCH 4/4] PM / sleep: Check pm_wakeup_pending() in __device_suspend_noirq()

2017-07-20 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Restore the pm_wakeup_pending() check in __device_suspend_noirq()
removed by commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI
wakeups from suspend-to-idle) as that allows the function to return
earlier if there's a wakeup event pending already (so that it may
spend less time on carrying out operations that will be reversed
shortly anyway) and rework the main suspend-to-idle loop to take
that optimization into account.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |5 +
 kernel/power/suspend.c|   19 ---
 2 files changed, 21 insertions(+), 3 deletions(-)

Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -106,19 +106,32 @@ static void s2idle_loop(void)
 {
pm_pr_dbg("suspend-to-idle\n");
 
-   while (!dpm_suspend_noirq(PMSG_SUSPEND)) {
+   for (;;) {
+   int error;
+
+   dpm_noirq_begin();
+
/*
 * Suspend-to-idle equals
 * frozen processes + suspended devices + idle processors.
 * Thus freeze_enter() should be called right after
 * all devices have been suspended.
 */
-   freeze_enter();
+   error = dpm_noirq_suspend_devices(PMSG_SUSPEND);
+   if (!error)
+   freeze_enter();
+
+   dpm_noirq_resume_devices(PMSG_RESUME);
+   if (error && (error != -EBUSY || !pm_wakeup_pending())) {
+   dpm_noirq_end();
+   break;
+   }
 
if (freeze_ops && freeze_ops->wake)
freeze_ops->wake();
 
-   dpm_resume_noirq(PMSG_RESUME);
+   dpm_noirq_end();
+
if (freeze_ops && freeze_ops->sync)
freeze_ops->sync();
 
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -1105,6 +1105,11 @@ static int __device_suspend_noirq(struct
if (async_error)
goto Complete;
 
+   if (pm_wakeup_pending()) {
+   async_error = -EBUSY;
+   goto Complete;
+   }
+
if (dev->power.syscore || dev->power.direct_complete)
goto Complete;
 



[PATCH 3/4] PM / core: Add error argument to dpm_show_time()

2017-07-20 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Make the core device suspend/resume code also call dpm_show_time()
on failures and add an error argument to this function so that the
message printed by it can reflect the success or failure condition.

This makes the debug messages in question look less confusing in
the failing cases.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |   21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -418,7 +418,7 @@ static void pm_dev_err(struct device *de
dev_name(dev), pm_verb(state.event), info, error);
 }
 
-static void dpm_show_time(ktime_t starttime, pm_message_t state,
+static void dpm_show_time(ktime_t starttime, pm_message_t state, int error,
  const char *info)
 {
ktime_t calltime;
@@ -432,8 +432,9 @@ static void dpm_show_time(ktime_t startt
if (usecs == 0)
usecs = 1;
 
-   pm_pr_dbg("%s%s%s of devices complete after %ld.%03ld msecs\n",
+   pm_pr_dbg("%s%s%s of devices %s after %ld.%03ld msecs\n",
  info ?: "", info ? " " : "", pm_verb(state.event),
+ error ? "aborted" : "complete",
  usecs / USEC_PER_MSEC, usecs % USEC_PER_MSEC);
 }
 
@@ -643,7 +644,7 @@ void dpm_noirq_resume_devices(pm_message
}
mutex_unlock(_list_mtx);
async_synchronize_full();
-   dpm_show_time(starttime, state, "noirq");
+   dpm_show_time(starttime, state, 0, "noirq");
trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
 }
 
@@ -782,7 +783,7 @@ void dpm_resume_early(pm_message_t state
}
mutex_unlock(_list_mtx);
async_synchronize_full();
-   dpm_show_time(starttime, state, "early");
+   dpm_show_time(starttime, state, 0, "early");
trace_suspend_resume(TPS("dpm_resume_early"), state.event, false);
 }
 
@@ -954,7 +955,7 @@ void dpm_resume(pm_message_t state)
}
mutex_unlock(_list_mtx);
async_synchronize_full();
-   dpm_show_time(starttime, state, NULL);
+   dpm_show_time(starttime, state, 0, NULL);
 
cpufreq_resume();
trace_suspend_resume(TPS("dpm_resume"), state.event, false);
@@ -1211,9 +1212,8 @@ int dpm_noirq_suspend_devices(pm_message
if (error) {
suspend_stats.failed_suspend_noirq++;
dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
-   } else {
-   dpm_show_time(starttime, state, "noirq");
}
+   dpm_show_time(starttime, state, error, "noirq");
trace_suspend_resume(TPS("dpm_suspend_noirq"), state.event, false);
return error;
 }
@@ -1371,9 +1371,8 @@ int dpm_suspend_late(pm_message_t state)
suspend_stats.failed_suspend_late++;
dpm_save_failed_step(SUSPEND_SUSPEND_LATE);
dpm_resume_early(resume_event(state));
-   } else {
-   dpm_show_time(starttime, state, "late");
}
+   dpm_show_time(starttime, state, error, "late");
trace_suspend_resume(TPS("dpm_suspend_late"), state.event, false);
return error;
 }
@@ -1639,8 +1638,8 @@ int dpm_suspend(pm_message_t state)
if (error) {
suspend_stats.failed_suspend++;
dpm_save_failed_step(SUSPEND_SUSPEND);
-   } else
-   dpm_show_time(starttime, state, NULL);
+   }
+   dpm_show_time(starttime, state, error, NULL);
trace_suspend_resume(TPS("dpm_suspend"), state.event, false);
return error;
 }



Re: linux-next: manual merge of the drm-misc tree with the drm-intel tree

2017-07-20 Thread Stephen Rothwell
Hi all,

The following conflict now exists between the drm and drm-intel trees.

On Thu, 20 Jul 2017 11:23:33 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/i915/i915_drv.c
> 
> between commit:
> 
>   99c539bef538 ("drm/i915: unregister interfaces first in unload")
> 
> from the drm-intel tree and commit:
> 
>   baf54385af78 ("drm/i915: Drop drm_vblank_cleanup")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/i915_drv.c
> index f406aec8a499,04d9bd84ee43..
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@@ -1386,8 -1367,8 +1384,6 @@@ void i915_driver_unload(struct drm_devi
>   
>   intel_gvt_cleanup(dev_priv);
>   
> - drm_vblank_cleanup(dev);
>  -i915_driver_unregister(dev_priv);
> --
>   intel_modeset_cleanup(dev);
>   
>   /*

-- 
Cheers,
Stephen Rothwell


Re: cpuidle and cpufreq coupling?

2017-07-20 Thread Vikram Mulukutla

On 7/20/2017 3:56 PM, Florian Fainelli wrote:

On 07/20/2017 07:45 AM, Peter Zijlstra wrote:






Can your ARM part change OPP without scheduling? Because (for obvious
reasons) the idle thread is not supposed to block.


I think it should be able to do that, but I am not sure that if I went
through the cpufreq API it would be that straight forward so I may have
to re-implement some of the frequency scaling logic outside of cpufreq
(or rather make the low-level parts some kind of library I guess).



I think I can safely mention that some of our non-upstream idle drivers
in the past have invoked low level clock drivers to atomically switch
CPUs to low frequency OPPs, with no interaction whatsoever with cpufreq.
It was maintainable since both the idle and clock drivers were
qcom-specific. However this is no longer necessary in recent designs and
I really hope we never need to do this again...

We didn't have to do a voltage switch and just PLL or mux
work so this was doable. I'm guessing your atomic switching also allows
voltage reduction?

If your architecture allows another CPU to change the entering-idle 
CPU's

frequency, synchronization will be necessary as well - this is where it
can get a bit tricky.

Thanks,
Vikram



Re: linux-next: build failure after merge of the drm-misc tree

2017-07-20 Thread Stephen Rothwell
Hi Dave,

The following is now applicable to the drm and staging.current trees ...

On Wed, 19 Jul 2017 11:46:57 +1000 Stephen Rothwell  
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid' 
> specified in initializer
>   .set_busid = drm_pci_set_busid,
>   ^
> drivers/staging/vboxvideo/vbox_drv.c:235:15: error: 'drm_pci_set_busid' 
> undeclared here (not in a function)
>   .set_busid = drm_pci_set_busid,
>^
> drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_init':
> drivers/staging/vboxvideo/vbox_drv.c:273:9: error: implicit declaration of 
> function 'drm_pci_init' [-Werror=implicit-function-declaration]
>   return drm_pci_init(, _pci_driver);
>  ^
> drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_exit':
> drivers/staging/vboxvideo/vbox_drv.c:278:2: error: implicit declaration of 
> function 'drm_pci_exit' [-Werror=implicit-function-declaration]
>   drm_pci_exit(, _pci_driver);
>   ^
> 
> Caused by commits
> 
>   5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
>   10631d724def ("drm/pci: Deprecate drm_pci_init/exit completely")
> 
> interacting with commit
> 
>   dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> 
> from the staging.current tree.
> 
> I have applied the following merge fix patch - please check that it
> is correct.
> 
> From: Stephen Rothwell 
> Date: Wed, 19 Jul 2017 11:41:01 +1000
> Subject: [PATCH] drm: fixes for staging due to API changes in the drm core
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/staging/vboxvideo/vbox_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
> b/drivers/staging/vboxvideo/vbox_drv.c
> index 92ae1560a16d..6d0600c37c0c 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.c
> +++ b/drivers/staging/vboxvideo/vbox_drv.c
> @@ -232,7 +232,6 @@ static struct drm_driver driver = {
>   .lastclose = vbox_driver_lastclose,
>   .master_set = vbox_master_set,
>   .master_drop = vbox_master_drop,
> - .set_busid = drm_pci_set_busid,
>  
>   .fops = _fops,
>   .irq_handler = vbox_irq_handler,
> @@ -270,12 +269,12 @@ static int __init vbox_init(void)
>   if (vbox_modeset == 0)
>   return -EINVAL;
>  
> - return drm_pci_init(, _pci_driver);
> + return pci_register_driver(_pci_driver);
>  }
>  
>  static void __exit vbox_exit(void)
>  {
> - drm_pci_exit(, _pci_driver);
> + pci_unregister_driver(_pci_driver);
>  }
>  
>  module_init(vbox_init);
> -- 
> 2.13.2

-- 
Cheers,
Stephen Rothwell


Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

2017-07-20 Thread Stephen Rothwell
Hi Dave,

The conflict below now exists between the drm-misc-fixes tree and the
drm tree.

On Tue, 18 Jul 2017 11:39:46 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/vc4/vc4_crtc.c
> 
> between commit:
> 
>   1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")
> 
> from the drm-misc-fixes tree and commit:
> 
>   0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper 
> function")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/vc4/vc4_crtc.c
> index a12cc7ea99b6,9e0c1500375c..
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@@ -518,37 -519,23 +519,51 @@@ static void vc4_crtc_atomic_disable(str
>   WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
> (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
>SCALER_DISPSTATX_EMPTY);
> + 
> + /*
> +  * Make sure we issue a vblank event after disabling the CRTC if
> +  * someone was waiting it.
> +  */
> + if (crtc->state->event) {
> + unsigned long flags;
> + 
> + spin_lock_irqsave(>event_lock, flags);
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> + spin_unlock_irqrestore(>event_lock, flags);
> + }
>   }
>   
>  +static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
>  +{
>  +struct drm_device *dev = crtc->dev;
>  +struct vc4_dev *vc4 = to_vc4_dev(dev);
>  +struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>  +struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
>  +
>  +if (crtc->state->event) {
>  +unsigned long flags;
>  +
>  +crtc->state->event->pipe = drm_crtc_index(crtc);
>  +
>  +WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  +
>  +spin_lock_irqsave(>event_lock, flags);
>  +vc4_crtc->event = crtc->state->event;
>  +crtc->state->event = NULL;
>  +
>  +HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +  vc4_state->mm.start);
>  +
>  +spin_unlock_irqrestore(>event_lock, flags);
>  +} else {
>  +HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +  vc4_state->mm.start);
>  +}
>  +}
>  +
> - static void vc4_crtc_enable(struct drm_crtc *crtc)
> + static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> +struct drm_crtc_state *old_state)
>   {
>   struct drm_device *dev = crtc->dev;
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
> @@@ -575,20 -556,22 +590,19 @@@
>   /* Turn on the pixel valve, which will emit the vstart signal. */
>   CRTC_WRITE(PV_V_CONTROL,
>  CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
>  -
>  -/* Enable vblank irq handling after crtc is started. */
>  -drm_crtc_vblank_on(crtc);
>   }
>   
> - static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode 
> *mode)
>   {
>   /* Do not allow doublescan modes from user space */
> - if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> + if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
>   DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
> crtc->base.id);
> - return false;
> + return MODE_NO_DBLESCAN;
>   }
>   
> - return true;
> + return MODE_OK;
>   }
>   
>   static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
> @@@ -650,15 -634,25 +664,15 @@@ static void vc4_crtc_atomic_flush(struc
>   
>   WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
>   
>  -if (crtc->state->event) {
>  -unsigned long flags;
>  -
>  -crtc->state->event->pipe = drm_crtc_index(crtc);
>  -
>  -WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  -
>  -spin_lock_irqsave(>event_lock, flags);
>  -vc4_crtc->event = crtc->state->event;
>  -crtc->state->event = NULL;
>  -
>  -HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  -  vc4_state->mm.start);
>  -
>  -spin_unlock_irqrestore(>event_lock, flags);
>  -} 

Re: [PATCH 1/2] platform/x86: peaq-wmi: select INPUT_POLLDEV

2017-07-20 Thread Darren Hart
On Thu, Jul 20, 2017 at 06:00:50PM +0200, Arnd Bergmann wrote:
> The new driver fails to build without INPUT_POLLDEV
> 
> drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_exit':
> peaq-wmi.c:(.exit.text+0x1c): undefined reference to 
> `input_unregister_polled_device'
> drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_init':
> peaq-wmi.c:(.init.text+0x23): undefined reference to 
> `input_allocate_polled_device'
> peaq-wmi.c:(.init.text+0x18e): undefined reference to 
> `input_register_polled_device'
> 
> For some reason, all other drivers that need this use 'select'
> here rather than 'depends on', so I'm doing the same.
> 
> Fixes: 13bb0fd5519d ("platform/x86: peaq-wmi: Add new peaq-wmi driver")
> Signed-off-by: Arnd Bergmann 

Queued to fixes branch for 4.13-rcX. I'll leave patch 2/2 to andy since you
worked that one together already.

-- 
Darren Hart
VMware Open Source Technology Center


[PATCH] ARM64: dts: marvell: armada-37xx: Enable uSD on ESPRESSObin

2017-07-20 Thread Marcin Wojtas
The ESPRESSObin board exposes one of the SDHCI interfaces
via J1 uSD slot. This patch enables it.

Signed-off-by: Marcin Wojtas 
Signed-off-by: Zbigniew Bodek 
---
 .../boot/dts/marvell/armada-3720-espressobin.dts   | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index b1af3f98..6d0caf1 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -45,6 +45,7 @@
 
 /dts-v1/;
 
+#include 
 #include "armada-372x.dtsi"
 
 / {
@@ -59,6 +60,20 @@
device_type = "memory";
reg = <0x 0x 0x 0x2000>;
};
+
+   vcc_sd_reg1: regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vcc_sd1";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+
+   gpios = < 4 GPIO_ACTIVE_HIGH>;
+   gpios-states = <0>;
+   states = <180 0x1
+ 330 0x0>;
+   enable-active-high;
+   };
 };
 
 /* J9 */
@@ -71,6 +86,17 @@
status = "okay";
 };
 
+/* J1 */
+ {
+   wp-inverted;
+   bus-width = <4>;
+   cd-gpios = < 3 GPIO_ACTIVE_LOW>;
+   no-1-8-v;
+   marvell,pad-type = "sd";
+   vqmmc-supply = <_sd_reg1>;
+   status = "okay";
+};
+
 /* Exported on the micro USB connector J5 through an FTDI */
  {
status = "okay";
-- 
1.8.3.1



Re: [BUG] lockdep splat with cpu_hotplug_lock

2017-07-20 Thread James Bottomley
[redirecting to linux-scsi]
On Thu, 2017-07-20 at 19:35 -0400, Steven Rostedt wrote:
> My tests triggered this splat on 4.13-rc1:
> 
> Loading iSCSI transport class v2.0-870.
> QLogic NetXtreme II iSCSI Driver bnx2i v2.7.10.1 (Jul 16, 2014)
> iscsi: registered transport (bnx2i)
> 
> 
> WARNING: possible recursive locking detected
> 4.13.0-rc1-test+ #2 Not tainted
> 
> swapper/0/1 is trying to acquire lock:
>  (cpu_hotplug_lock.rw_sem){++}, at: []
> __cpuhp_setup_state+0x28/0x59
> 
> but task is already holding lock:
>  (cpu_hotplug_lock.rw_sem){++}, at: []
> bnx2i_mod_init+0x134/0x209
> 
> other info that might help us debug this:
>  Possible unsafe locking scenario:
> 
>    CPU0
>    
>   lock(cpu_hotplug_lock.rw_sem);
>   lock(cpu_hotplug_lock.rw_sem);
> 
>  *** DEADLOCK ***
> 
>  May be due to missing lock nesting notation
> 
> 1 lock held by swapper/0/1:
>  #0:  (cpu_hotplug_lock.rw_sem){++}, at: []
> bnx2i_mod_init+0x134/0x209
> 
> stack backtrace:
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc1-test+ #2
> Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6
> 02/22/2014
> Call Trace:
>  dump_stack+0x68/0x92
>  __lock_acquire+0x84b/0xebb
>  ? __lock_is_held+0x47/0x7a
>  ? mark_held_locks+0x5e/0x74
>  ? _raw_spin_unlock_irqrestore+0x40/0x47
>  lock_acquire+0x108/0x19c
>  ? lock_acquire+0x108/0x19c
>  ? __cpuhp_setup_state+0x28/0x59
>  cpus_read_lock+0x2f/0x5f
>  ? __cpuhp_setup_state+0x28/0x59
>  __cpuhp_setup_state+0x28/0x59
>  ? bnx2i_percpu_thread_create+0x79/0x79
>  bnx2i_mod_init+0x17a/0x209
>  ? iscsi_transport_init+0x1c1/0x1c1
>  ? set_debug_rodata+0x17/0x17
>  do_one_initcall+0x90/0x131
>  ? set_debug_rodata+0x17/0x17
>  kernel_init_freeable+0x1e5/0x26d
>  ? rest_init+0xd8/0xd8
>  kernel_init+0xe/0xfa
>  ret_from_fork+0x27/0x40
> ahci :00:1f.2: version 3.0
> ahci :00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3 impl
> SATA mode
> ahci :00:1f.2: flags: 64bit ncq led clo pio slum part ems apst
> scsi host0: ahci
> 
> I'd let the powers that be figure it out.

It sounds like it's an annotation issue not an actual problem.  I've
added the correct list, so hopefully our usual enthusiasts can take a
look.

James



  1   2   3   4   5   6   7   8   9   10   >