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

[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

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

[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.

[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 v1] crypto: brcm - Support more FlexRM rings than SPU engines.

[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 != matched_spu_type->type) ||
-   (spu->spu_subtype != matched_spu_type->subtype)) {
-  

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

[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 2/3] staging: lustre: ldlm: constify attribute_group structures.

[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.

[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 0/3] Constify lustre attribute_group structures.

[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.

[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.

[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 

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

[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.

[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 = osc_attrs,
 };
 
-- 

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

[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

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

[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

[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

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

[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

[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] zsmalloc: zs_page_migrate: not check inuse if migrate_mode is not MIGRATE_ASYNC

[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

[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.

> 

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

[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

[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(-)

[git pull] drm fixes for 4.13-rc2

[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.

[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] efifb: allow user to disable write combined mapping.

[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

[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 0/2] sparc64: Use low latency path to resume idle cpu

[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

[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

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

[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

[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

linux-next: Tree for Jul 21

[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]

[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.

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

[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

[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 2/2] ARM: dts: imx: add CX9020 Embedded PC device tree

[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>;
+
+   tfp410_in: endpoint {
+   remote-endpoint = <_out>;
+ 

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

[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 v4 1/2] dt-bindings: arm: Add entry for Beckhoff CX9020

[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

[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

[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 2/3] soc: mediatek: add header files required for MT7622 SCPSYS dt-binding

[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

[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

[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 3/3] soc: mediatek: add SCPSYS power domain driver for MediaTek MT7622 SoC

[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 a/include/linux/soc/mediatek/infracfg.h 
b/include/linux/soc/mediatek/infracfg.h

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

[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

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

[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

[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 2/4] gpio: davinci: Handle the return value of davinci_gpio_irq_setup function

[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

[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/6] Cache coherent device memory (CDM) with HMM v5

[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

[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.

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

[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

[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(-)

[GIT] IDE

[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

[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

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

[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

[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 0/2] sparc64: Use low latency path to resume idle cpu

[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

[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 19/32] tracing: Add variable reference handling to hist triggers

[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

[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: [PATCH v2 1/2] platform/x86: Add GLK PSS Event Table

[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

[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: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

[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

[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 v2 2/2] Telemetry: remove redundant macro definition

[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

[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

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

[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

[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] Documentation: mtk-quadspi: update DT bindings

[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

[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

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

[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

[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 1/3] platform/x86: Add GLK PSS Event Table

[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

[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: [PATCH v2 2/2] Telemetry: remove redundant macro definition

[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

[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: [RFC PATCH v12 3/4] Linux Random Number Generator

[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

[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 0/2] sparc64: Use low latency path to resume idle cpu

[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

[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] dma: Add Spreadtrum DMA controller driver

[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 DMA_CHN_DES_BLK_STEP   0x3c
> +
> +/* DMA_CHN_INTC 

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

[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 2/2] sparc64: Use cpu_poke to resume idle cpu

[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

[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 0/2] sparc64: Use low latency path to resume idle cpu

[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

[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

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

[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

[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] qe: fix compile issue for arm64

[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

[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 5/5] dt-bindings: PCI: add support for new generation controller

[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 _intc0 3>;
+   pcie_intc0: interrupt-controller {
+   

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

[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

[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 v2 1/1] Documentation: mtk-quadspi: update DT bindings

[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

[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()

[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 2/5] PCI: mediatek: switch to use platform_get_resource_byname()

[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

[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 4/5] PCI: mediatek: Add new generation controller support

[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 functions
+ * @setup_irq: pointer to initialize irq functions
  * @startup: pointer to controller setting functions
  */
 

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

[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

[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 =