device tree file

2017-05-16 Thread Karthik BalaGuru T
Hi,

Can someone point me to a specific device tree file for Intel Atom processor 
for reference ?

Thanks in advance,
Karthik Balaguru
Disclaimer : 
This email communication may contain privileged and confidential information 
and is intended for the use of the addressee only. If you are not an intended 
recipient you are requested not to reproduce, copy disseminate or in any manner 
distribute this email communication as the same is strictly prohibited. If you 
have received this email in error, please notify the sender immediately by 
return e-mail and delete the communication sent in error. Email communications 
cannot be guaranteed to be secure & error free and Incedo Inc. is not liable 
for any errors in the email communication or for the proper, timely and 
complete transmission thereof.



device tree file

2017-05-16 Thread Karthik BalaGuru T
Hi,

Can someone point me to a specific device tree file for Intel Atom processor 
for reference ?

Thanks in advance,
Karthik Balaguru
Disclaimer : 
This email communication may contain privileged and confidential information 
and is intended for the use of the addressee only. If you are not an intended 
recipient you are requested not to reproduce, copy disseminate or in any manner 
distribute this email communication as the same is strictly prohibited. If you 
have received this email in error, please notify the sender immediately by 
return e-mail and delete the communication sent in error. Email communications 
cannot be guaranteed to be secure & error free and Incedo Inc. is not liable 
for any errors in the email communication or for the proper, timely and 
complete transmission thereof.



Re: [PATCH v1] cpufreq: kirkwood-cpufreq:- Handle return value of clk_prepare_enable

2017-05-16 Thread Arvind Yadav

Yes, I will add check for powersave clk.

Thanks
- Arvind

On Wednesday 17 May 2017 10:04 AM, Viresh Kumar wrote:

On 16-05-17, 12:41, Arvind Yadav wrote:

Here, Clock enable can failed. So adding an error check for
clk_prepare_enable.

Rewrite it as:

clk_prepare_enable() can fail here and we must check its return value.


Signed-off-by: Arvind Yadav 
---
  drivers/cpufreq/kirkwood-cpufreq.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
b/drivers/cpufreq/kirkwood-cpufreq.c
index 1b9bcd7..4c30103 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -127,7 +127,12 @@ static int kirkwood_cpufreq_probe(struct platform_device 
*pdev)
return PTR_ERR(priv.cpu_clk);
}
  
-	clk_prepare_enable(priv.cpu_clk);

+   err = clk_prepare_enable(priv.cpu_clk);
+   if (err) {
+   dev_err(priv.dev, "Unable to prepare cpuclk\n");
+   return err;
+   }
+
kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
  
  	priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");

@@ -137,7 +142,11 @@ static int kirkwood_cpufreq_probe(struct platform_device 
*pdev)
goto out_cpu;
}
  
-	clk_prepare_enable(priv.ddr_clk);

+   err = clk_prepare_enable(priv.ddr_clk);
+   if (err) {
+   dev_err(priv.dev, "Unable to prepare ddrclk\n");
+   goto out_cpu;
+   }
kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
  
  	priv.powersave_clk = of_clk_get_by_name(np, "powersave");

There is one more prepare-enable after this. Why not fix that as well
?





Re: [PATCH v1] cpufreq: kirkwood-cpufreq:- Handle return value of clk_prepare_enable

2017-05-16 Thread Arvind Yadav

Yes, I will add check for powersave clk.

Thanks
- Arvind

On Wednesday 17 May 2017 10:04 AM, Viresh Kumar wrote:

On 16-05-17, 12:41, Arvind Yadav wrote:

Here, Clock enable can failed. So adding an error check for
clk_prepare_enable.

Rewrite it as:

clk_prepare_enable() can fail here and we must check its return value.


Signed-off-by: Arvind Yadav 
---
  drivers/cpufreq/kirkwood-cpufreq.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
b/drivers/cpufreq/kirkwood-cpufreq.c
index 1b9bcd7..4c30103 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -127,7 +127,12 @@ static int kirkwood_cpufreq_probe(struct platform_device 
*pdev)
return PTR_ERR(priv.cpu_clk);
}
  
-	clk_prepare_enable(priv.cpu_clk);

+   err = clk_prepare_enable(priv.cpu_clk);
+   if (err) {
+   dev_err(priv.dev, "Unable to prepare cpuclk\n");
+   return err;
+   }
+
kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
  
  	priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");

@@ -137,7 +142,11 @@ static int kirkwood_cpufreq_probe(struct platform_device 
*pdev)
goto out_cpu;
}
  
-	clk_prepare_enable(priv.ddr_clk);

+   err = clk_prepare_enable(priv.ddr_clk);
+   if (err) {
+   dev_err(priv.dev, "Unable to prepare ddrclk\n");
+   goto out_cpu;
+   }
kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
  
  	priv.powersave_clk = of_clk_get_by_name(np, "powersave");

There is one more prepare-enable after this. Why not fix that as well
?





Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko
>  static u32 lpuart32_read(void __iomem *addr)
>  {
> - return ioread32be(addr);
> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
>  }
>  
>  static void lpuart32_write(u32 val, void __iomem *addr)
>  {
> - iowrite32be(val, addr);
> + if (lpuart_is_be)
> + iowrite32be(val, addr);
> + else
> + writel(val, addr);
>  }

 What if this is ever executed on big endian system?

>>>
>>> Sorry, not catching the point...
>>>
>>> What issues will meet?
>>
>> Isn't writel() in host endian?
> 
> On big endian systems, it is supposed to run iowrite32be.

Your code states, "force BE if lpuart_is_be, don't care otherwise".
This semantics looks questionable for code reviewer.
If driver handles endian, should't it be explicit in both cases?
And if indeed driver means handling BE explicitly, but don't caring
otherwise, maybe variable name should suggest that (i.e. "force_be")?

Although driver maintainer could think differently. I won't insist on this.

Nikita


Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko
>  static u32 lpuart32_read(void __iomem *addr)
>  {
> - return ioread32be(addr);
> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
>  }
>  
>  static void lpuart32_write(u32 val, void __iomem *addr)
>  {
> - iowrite32be(val, addr);
> + if (lpuart_is_be)
> + iowrite32be(val, addr);
> + else
> + writel(val, addr);
>  }

 What if this is ever executed on big endian system?

>>>
>>> Sorry, not catching the point...
>>>
>>> What issues will meet?
>>
>> Isn't writel() in host endian?
> 
> On big endian systems, it is supposed to run iowrite32be.

Your code states, "force BE if lpuart_is_be, don't care otherwise".
This semantics looks questionable for code reviewer.
If driver handles endian, should't it be explicit in both cases?
And if indeed driver means handling BE explicitly, but don't caring
otherwise, maybe variable name should suggest that (i.e. "force_be")?

Although driver maintainer could think differently. I won't insist on this.

Nikita


rcu: NO_HZ_FULL_SYSIDLE leftovers

2017-05-16 Thread Valentin Rothberg
Hi Paul,

I stumbled upon your commit 1cb830954ef9 ("rcu: Remove nohz_full
full-system-idle state machine") as ./scripts/checkkconfigsymbols.py
reported that there are some remaining references on the removed
Kconfig symbol 'NO_HZ_FULL_SYSIDLE'. I couldn't find any commit
removing them on LKML, and as I am unsure if you like to keep the
affected code, I want to report it to you.

To get the report in linux-next:
$ checkkconfigsymbols.py --diff next-20170516..next-20170517 --find

Kind regards,
 Valentin


rcu: NO_HZ_FULL_SYSIDLE leftovers

2017-05-16 Thread Valentin Rothberg
Hi Paul,

I stumbled upon your commit 1cb830954ef9 ("rcu: Remove nohz_full
full-system-idle state machine") as ./scripts/checkkconfigsymbols.py
reported that there are some remaining references on the removed
Kconfig symbol 'NO_HZ_FULL_SYSIDLE'. I couldn't find any commit
removing them on LKML, and as I am unsure if you like to keep the
affected code, I want to report it to you.

To get the report in linux-next:
$ checkkconfigsymbols.py --diff next-20170516..next-20170517 --find

Kind regards,
 Valentin


[PATCH] dlm: Make dismatch error message more clear

2017-05-16 Thread Gang He
This change will try to make this error message more clear,
since the upper applications (e.g. ocfs2) invoke dlm_new_lockspace
to create a new lockspace with passing a cluster name. Sometimes,
dlm_new_lockspace return failure while two cluster names dismatch,
the user is a little confused since this line error message is not
enough obvious.

Signed-off-by: Gang He 
---
 fs/dlm/lockspace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c
index 91592b7..b03d808 100644
--- a/fs/dlm/lockspace.c
+++ b/fs/dlm/lockspace.c
@@ -455,7 +455,8 @@ static int new_lockspace(const char *name, const char 
*cluster,
 
if (dlm_config.ci_recover_callbacks && cluster &&
strncmp(cluster, dlm_config.ci_cluster_name, DLM_LOCKSPACE_LEN)) {
-   log_print("dlm cluster name %s mismatch %s",
+   log_print("dlm configured cluster name '%s' does not match "
+ "the passed cluster name '%s'",
  dlm_config.ci_cluster_name, cluster);
error = -EBADR;
goto out;
-- 
1.8.5.6



[PATCH] dlm: Make dismatch error message more clear

2017-05-16 Thread Gang He
This change will try to make this error message more clear,
since the upper applications (e.g. ocfs2) invoke dlm_new_lockspace
to create a new lockspace with passing a cluster name. Sometimes,
dlm_new_lockspace return failure while two cluster names dismatch,
the user is a little confused since this line error message is not
enough obvious.

Signed-off-by: Gang He 
---
 fs/dlm/lockspace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c
index 91592b7..b03d808 100644
--- a/fs/dlm/lockspace.c
+++ b/fs/dlm/lockspace.c
@@ -455,7 +455,8 @@ static int new_lockspace(const char *name, const char 
*cluster,
 
if (dlm_config.ci_recover_callbacks && cluster &&
strncmp(cluster, dlm_config.ci_cluster_name, DLM_LOCKSPACE_LEN)) {
-   log_print("dlm cluster name %s mismatch %s",
+   log_print("dlm configured cluster name '%s' does not match "
+ "the passed cluster name '%s'",
  dlm_config.ci_cluster_name, cluster);
error = -EBADR;
goto out;
-- 
1.8.5.6



Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

2017-05-16 Thread Alberto Ladron
On Tue, May 16, 2017 at 01:44:47PM +0800, kbuild test robot wrote:
Hi,

   Here is the fix.  Or I have to resubmit the whole patch?

Signed-off-by: Alberto Ladron 
---
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index b1879ff..c335878 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1018,7 +1018,7 @@ static int usblp_submit_read(struct usblp *usblp)
usblp->rcomplete = 0;
spin_unlock_irqrestore(>lock, flags);
rc = usb_submit_urb(urb, GFP_KERNEL);
-   if (rv < 0) {
+   if (rc < 0) {
dev_dbg(>intf->dev, "error submitting urb (%d)\n", rc);
spin_lock_irqsave(>lock, flags);
usblp->rstatus = rc;



> Hi Alberto,
> 
> [auto build test ERROR on usb/usb-testing]
> [also build test ERROR on v4.12-rc1 next-20170515]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed-assignments-inside-if-conditions/20170513-140010
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> usb-testing
> config: x86_64-rhel (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers//usb/class/usblp.c: In function 'usblp_submit_read':
> >> drivers//usb/class/usblp.c:1021:6: error: 'rv' undeclared (first use in 
> >> this function)
>  if (rv < 0) {
>  ^~
>drivers//usb/class/usblp.c:1021:6: note: each undeclared identifier is 
> reported only once for each function it appears in
> 
> vim +/rv +1021 drivers//usb/class/usblp.c
> 
>   1005urb = usb_alloc_urb(0, GFP_KERNEL);
>   1006if (urb == NULL)
>   1007goto raise_urb;
>   1008
>   1009usb_fill_bulk_urb(urb, usblp->dev,
>   1010usb_rcvbulkpipe(usblp->dev,
>   1011  
> usblp->protocol[usblp->current_protocol].epread->bEndpointAddress),
>   1012usblp->readbuf, USBLP_BUF_SIZE_IN,
>   1013usblp_bulk_read, usblp);
>   1014usb_anchor_urb(urb, >urbs);
>   1015
>   1016spin_lock_irqsave(>lock, flags);
>   1017usblp->readcount = 0; /* XXX Why here? */
>   1018usblp->rcomplete = 0;
>   1019spin_unlock_irqrestore(>lock, flags);
>   1020rc = usb_submit_urb(urb, GFP_KERNEL);
> > 1021if (rv < 0) {
>   1022dev_dbg(>intf->dev, "error submitting 
> urb (%d)\n", rc);
>   1023spin_lock_irqsave(>lock, flags);
>   1024usblp->rstatus = rc;
>   1025usblp->rcomplete = 1;
>   1026spin_unlock_irqrestore(>lock, flags);
>   1027goto raise_submit;
>   1028}
>   1029
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

2017-05-16 Thread Alberto Ladron
On Tue, May 16, 2017 at 01:44:47PM +0800, kbuild test robot wrote:
Hi,

   Here is the fix.  Or I have to resubmit the whole patch?

Signed-off-by: Alberto Ladron 
---
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index b1879ff..c335878 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1018,7 +1018,7 @@ static int usblp_submit_read(struct usblp *usblp)
usblp->rcomplete = 0;
spin_unlock_irqrestore(>lock, flags);
rc = usb_submit_urb(urb, GFP_KERNEL);
-   if (rv < 0) {
+   if (rc < 0) {
dev_dbg(>intf->dev, "error submitting urb (%d)\n", rc);
spin_lock_irqsave(>lock, flags);
usblp->rstatus = rc;



> Hi Alberto,
> 
> [auto build test ERROR on usb/usb-testing]
> [also build test ERROR on v4.12-rc1 next-20170515]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed-assignments-inside-if-conditions/20170513-140010
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> usb-testing
> config: x86_64-rhel (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers//usb/class/usblp.c: In function 'usblp_submit_read':
> >> drivers//usb/class/usblp.c:1021:6: error: 'rv' undeclared (first use in 
> >> this function)
>  if (rv < 0) {
>  ^~
>drivers//usb/class/usblp.c:1021:6: note: each undeclared identifier is 
> reported only once for each function it appears in
> 
> vim +/rv +1021 drivers//usb/class/usblp.c
> 
>   1005urb = usb_alloc_urb(0, GFP_KERNEL);
>   1006if (urb == NULL)
>   1007goto raise_urb;
>   1008
>   1009usb_fill_bulk_urb(urb, usblp->dev,
>   1010usb_rcvbulkpipe(usblp->dev,
>   1011  
> usblp->protocol[usblp->current_protocol].epread->bEndpointAddress),
>   1012usblp->readbuf, USBLP_BUF_SIZE_IN,
>   1013usblp_bulk_read, usblp);
>   1014usb_anchor_urb(urb, >urbs);
>   1015
>   1016spin_lock_irqsave(>lock, flags);
>   1017usblp->readcount = 0; /* XXX Why here? */
>   1018usblp->rcomplete = 0;
>   1019spin_unlock_irqrestore(>lock, flags);
>   1020rc = usb_submit_urb(urb, GFP_KERNEL);
> > 1021if (rv < 0) {
>   1022dev_dbg(>intf->dev, "error submitting 
> urb (%d)\n", rc);
>   1023spin_lock_irqsave(>lock, flags);
>   1024usblp->rstatus = rc;
>   1025usblp->rcomplete = 1;
>   1026spin_unlock_irqrestore(>lock, flags);
>   1027goto raise_submit;
>   1028}
>   1029
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko
>>> @@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
>>> }
>>> sport->port.line = ret;
>>> sport->lpuart32 = sdata->is_32;
>>> +   lpuart_is_be = sdata->is_be;
>>
>> Setting a global variable in per-device routine is quite bad design.
>>
> 
> There is a reason for that we don't want to change the exist 
> lpuart32_read[write] API which is widely used in driver.
> Making a global lpuart_is_be is the simplest way to do it.
> 
> Any strong blocking reason?

Code should be consistent.

There is no good reason to have sport->lpuart32 inside sport, but
lpuart_is_be outside of it. Both these values describe properties of
particular device, and thus should be in per-device structure.

If that implies adding sport arg to lpuart32_(read|write), just do that.


Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko
>>> @@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
>>> }
>>> sport->port.line = ret;
>>> sport->lpuart32 = sdata->is_32;
>>> +   lpuart_is_be = sdata->is_be;
>>
>> Setting a global variable in per-device routine is quite bad design.
>>
> 
> There is a reason for that we don't want to change the exist 
> lpuart32_read[write] API which is widely used in driver.
> Making a global lpuart_is_be is the simplest way to do it.
> 
> Any strong blocking reason?

Code should be consistent.

There is no good reason to have sport->lpuart32 inside sport, but
lpuart_is_be outside of it. Both these values describe properties of
particular device, and thus should be in per-device structure.

If that implies adding sport arg to lpuart32_(read|write), just do that.


Re: [PATCH-RFT 2/2] pinctrl: samsung: Split Exynos drivers per ARMv7 and ARMv8

2017-05-16 Thread Marek Szyprowski

Hi Krzysztof,

On 2017-05-16 22:06, Krzysztof Kozlowski wrote:

Exynos pinctrl drivers contain pretty big per-SoC data structures.  The
pinctrl-exynos object file contained code and data for both ARMv7 and
ARMv8 SoCs thus it grew big.  There will not be a shared image between
ARMv7 and ARMv8 so there is no need to combine all of this into one
driver.

Splitting the data allows to make it more granular (e.g. code related to
ARMv8 Exynos is self-contained), slightly speed up the compilation and
reduce the effective size of compiled kernel.

The common data structures and functions reside still in existing
pinctrl-exynos.c.  Only the SoC-specific parts were moved out to new
files.  Except marking few functions non-static and adding them to
header, there were no functional changes in the code.

Signed-off-by: Krzysztof Kozlowski 
---

Not tested on ARMv8 (Exynos5433, Exynos7).


Works fine on TM2 (Exynos5433).

Tested-by: Marek Szyprowski 


---
  drivers/pinctrl/samsung/Kconfig|   10 +
  drivers/pinctrl/samsung/Makefile   |2 +
  drivers/pinctrl/samsung/pinctrl-exynos-arm.c   |  815 +
  drivers/pinctrl/samsung/pinctrl-exynos-arm64.c |  399 
  drivers/pinctrl/samsung/pinctrl-exynos.c   | 1163 +---
  drivers/pinctrl/samsung/pinctrl-exynos.h   |8 +
  drivers/pinctrl/samsung/pinctrl-samsung.c  |8 +-
  7 files changed, 1245 insertions(+), 1160 deletions(-)
  create mode 100644 drivers/pinctrl/samsung/pinctrl-exynos-arm.c
  create mode 100644 drivers/pinctrl/samsung/pinctrl-exynos-arm64.c

diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index d0461cd5d707..c33ee6293c30 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -10,6 +10,16 @@ config PINCTRL_EXYNOS
bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
depends on OF && GPIOLIB && (ARCH_EXYNOS || ARCH_S5PV210)
select PINCTRL_SAMSUNG
+   select PINCTRL_EXYNOS_ARM if ARM && ARCH_EXYNOS
+   select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
+
+config PINCTRL_EXYNOS_ARM
+   bool "ARMv7-specific pinctrl driver data for Exynos (except 
Exynos5440)" if COMPILE_TEST
+   depends on PINCTRL_EXYNOS
+
+config PINCTRL_EXYNOS_ARM64
+   bool "ARMv8-specific pinctrl driver data for Exynos" if COMPILE_TEST
+   depends on PINCTRL_EXYNOS
  
  config PINCTRL_EXYNOS5440

bool "Samsung EXYNOS5440 SoC pinctrl driver"
diff --git a/drivers/pinctrl/samsung/Makefile b/drivers/pinctrl/samsung/Makefile
index 70160c059edd..595995851ea5 100644
--- a/drivers/pinctrl/samsung/Makefile
+++ b/drivers/pinctrl/samsung/Makefile
@@ -2,6 +2,8 @@
  
  obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o

  obj-$(CONFIG_PINCTRL_EXYNOS)  += pinctrl-exynos.o
+obj-$(CONFIG_PINCTRL_EXYNOS_ARM)   += pinctrl-exynos-arm.o
+obj-$(CONFIG_PINCTRL_EXYNOS_ARM64) += pinctrl-exynos-arm64.o
  obj-$(CONFIG_PINCTRL_EXYNOS5440)  += pinctrl-exynos5440.o
  obj-$(CONFIG_PINCTRL_S3C24XX) += pinctrl-s3c24xx.o
  obj-$(CONFIG_PINCTRL_S3C64XX) += pinctrl-s3c64xx.o
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c 
b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
new file mode 100644
index ..62e1cc376e2e
--- /dev/null
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
@@ -0,0 +1,815 @@
+/*
+ * Exynos specific support for Samsung pinctrl/gpiolib driver with eint 
support.
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2012 Linaro Ltd
+ * http://www.linaro.org
+ *
+ * Author: Thomas Abraham 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This file contains the Samsung Exynos specific information required by the
+ * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-samsung.h"
+#include "pinctrl-exynos.h"
+
+static const struct samsung_pin_bank_type bank_type_off = {
+   .fld_width = { 4, 1, 2, 2, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+static const struct samsung_pin_bank_type bank_type_alive = {
+   .fld_width = { 4, 1, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+/* Retention control for S5PV210 are located at the end of clock controller */
+#define S5P_OTHERS 0xE000
+
+#define S5P_OTHERS_RET_IO  (1 << 31)
+#define S5P_OTHERS_RET_CF  (1 << 30)
+#define S5P_OTHERS_RET_MMC (1 << 29)
+#define S5P_OTHERS_RET_UART(1 << 28)
+
+static void 

Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Dong Aisheng
On Wed, May 17, 2017 at 08:37:41AM +0300, Nikita Yushchenko wrote:
> 
> 
> 17.05.2017 06:39, Dong Aisheng wrote:
> > On Tue, May 16, 2017 at 02:15:08PM +0300, Nikita Yushchenko wrote:
> >>>  static u32 lpuart32_read(void __iomem *addr)
> >>>  {
> >>> - return ioread32be(addr);
> >>> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
> >>>  }
> >>>  
> >>>  static void lpuart32_write(u32 val, void __iomem *addr)
> >>>  {
> >>> - iowrite32be(val, addr);
> >>> + if (lpuart_is_be)
> >>> + iowrite32be(val, addr);
> >>> + else
> >>> + writel(val, addr);
> >>>  }
> >>
> >> What if this is ever executed on big endian system?
> >>
> > 
> > Sorry, not catching the point...
> > 
> > What issues will meet?
> 
> Isn't writel() in host endian?

On big endian systems, it is supposed to run iowrite32be.

Regards
Dong Aisheng


Re: [PATCH-RFT 2/2] pinctrl: samsung: Split Exynos drivers per ARMv7 and ARMv8

2017-05-16 Thread Marek Szyprowski

Hi Krzysztof,

On 2017-05-16 22:06, Krzysztof Kozlowski wrote:

Exynos pinctrl drivers contain pretty big per-SoC data structures.  The
pinctrl-exynos object file contained code and data for both ARMv7 and
ARMv8 SoCs thus it grew big.  There will not be a shared image between
ARMv7 and ARMv8 so there is no need to combine all of this into one
driver.

Splitting the data allows to make it more granular (e.g. code related to
ARMv8 Exynos is self-contained), slightly speed up the compilation and
reduce the effective size of compiled kernel.

The common data structures and functions reside still in existing
pinctrl-exynos.c.  Only the SoC-specific parts were moved out to new
files.  Except marking few functions non-static and adding them to
header, there were no functional changes in the code.

Signed-off-by: Krzysztof Kozlowski 
---

Not tested on ARMv8 (Exynos5433, Exynos7).


Works fine on TM2 (Exynos5433).

Tested-by: Marek Szyprowski 


---
  drivers/pinctrl/samsung/Kconfig|   10 +
  drivers/pinctrl/samsung/Makefile   |2 +
  drivers/pinctrl/samsung/pinctrl-exynos-arm.c   |  815 +
  drivers/pinctrl/samsung/pinctrl-exynos-arm64.c |  399 
  drivers/pinctrl/samsung/pinctrl-exynos.c   | 1163 +---
  drivers/pinctrl/samsung/pinctrl-exynos.h   |8 +
  drivers/pinctrl/samsung/pinctrl-samsung.c  |8 +-
  7 files changed, 1245 insertions(+), 1160 deletions(-)
  create mode 100644 drivers/pinctrl/samsung/pinctrl-exynos-arm.c
  create mode 100644 drivers/pinctrl/samsung/pinctrl-exynos-arm64.c

diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index d0461cd5d707..c33ee6293c30 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -10,6 +10,16 @@ config PINCTRL_EXYNOS
bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
depends on OF && GPIOLIB && (ARCH_EXYNOS || ARCH_S5PV210)
select PINCTRL_SAMSUNG
+   select PINCTRL_EXYNOS_ARM if ARM && ARCH_EXYNOS
+   select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
+
+config PINCTRL_EXYNOS_ARM
+   bool "ARMv7-specific pinctrl driver data for Exynos (except 
Exynos5440)" if COMPILE_TEST
+   depends on PINCTRL_EXYNOS
+
+config PINCTRL_EXYNOS_ARM64
+   bool "ARMv8-specific pinctrl driver data for Exynos" if COMPILE_TEST
+   depends on PINCTRL_EXYNOS
  
  config PINCTRL_EXYNOS5440

bool "Samsung EXYNOS5440 SoC pinctrl driver"
diff --git a/drivers/pinctrl/samsung/Makefile b/drivers/pinctrl/samsung/Makefile
index 70160c059edd..595995851ea5 100644
--- a/drivers/pinctrl/samsung/Makefile
+++ b/drivers/pinctrl/samsung/Makefile
@@ -2,6 +2,8 @@
  
  obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o

  obj-$(CONFIG_PINCTRL_EXYNOS)  += pinctrl-exynos.o
+obj-$(CONFIG_PINCTRL_EXYNOS_ARM)   += pinctrl-exynos-arm.o
+obj-$(CONFIG_PINCTRL_EXYNOS_ARM64) += pinctrl-exynos-arm64.o
  obj-$(CONFIG_PINCTRL_EXYNOS5440)  += pinctrl-exynos5440.o
  obj-$(CONFIG_PINCTRL_S3C24XX) += pinctrl-s3c24xx.o
  obj-$(CONFIG_PINCTRL_S3C64XX) += pinctrl-s3c64xx.o
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c 
b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
new file mode 100644
index ..62e1cc376e2e
--- /dev/null
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
@@ -0,0 +1,815 @@
+/*
+ * Exynos specific support for Samsung pinctrl/gpiolib driver with eint 
support.
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2012 Linaro Ltd
+ * http://www.linaro.org
+ *
+ * Author: Thomas Abraham 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This file contains the Samsung Exynos specific information required by the
+ * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+ * external gpio and wakeup interrupt support.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-samsung.h"
+#include "pinctrl-exynos.h"
+
+static const struct samsung_pin_bank_type bank_type_off = {
+   .fld_width = { 4, 1, 2, 2, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+static const struct samsung_pin_bank_type bank_type_alive = {
+   .fld_width = { 4, 1, 2, 2, },
+   .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+/* Retention control for S5PV210 are located at the end of clock controller */
+#define S5P_OTHERS 0xE000
+
+#define S5P_OTHERS_RET_IO  (1 << 31)
+#define S5P_OTHERS_RET_CF  (1 << 30)
+#define S5P_OTHERS_RET_MMC (1 << 29)
+#define S5P_OTHERS_RET_UART(1 << 28)
+
+static void s5pv210_retention_disable(struct samsung_pinctrl_drv_data *drvdata)
+{
+   

Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Dong Aisheng
On Wed, May 17, 2017 at 08:37:41AM +0300, Nikita Yushchenko wrote:
> 
> 
> 17.05.2017 06:39, Dong Aisheng wrote:
> > On Tue, May 16, 2017 at 02:15:08PM +0300, Nikita Yushchenko wrote:
> >>>  static u32 lpuart32_read(void __iomem *addr)
> >>>  {
> >>> - return ioread32be(addr);
> >>> + return lpuart_is_be ? ioread32be(addr) : readl(addr);
> >>>  }
> >>>  
> >>>  static void lpuart32_write(u32 val, void __iomem *addr)
> >>>  {
> >>> - iowrite32be(val, addr);
> >>> + if (lpuart_is_be)
> >>> + iowrite32be(val, addr);
> >>> + else
> >>> + writel(val, addr);
> >>>  }
> >>
> >> What if this is ever executed on big endian system?
> >>
> > 
> > Sorry, not catching the point...
> > 
> > What issues will meet?
> 
> Isn't writel() in host endian?

On big endian systems, it is supposed to run iowrite32be.

Regards
Dong Aisheng


[PATCH 3/4] mtd: mchp23k256: add partitioning support

2017-05-16 Thread Chris Packham
Setting the of_node for the mtd device allows the generic mtd code to
setup the partitions. Additionally we must specify a non-zero erasesize
for the partitions to be writeable.

Signed-off-by: Chris Packham 
---
 drivers/mtd/devices/mchp23k256.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 2542f5b8b63f..02c6b9dcbd3e 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -143,6 +143,7 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
@@ -151,6 +152,10 @@ static int mchp23k256_probe(struct spi_device *spi)
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
+   flash->mtd.erasesize = PAGE_SIZE;
+   while (flash->mtd.size & (flash->mtd.erasesize - 1))
+   flash->mtd.erasesize >>= 1;
+
err = mtd_device_register(>mtd, data ? data->parts : NULL,
  data ? data->nr_parts : 0);
if (err)
-- 
2.11.0.24.ge6920cf



[PATCH 2/4] mtd: mchp23k256: switch to mtd_device_register()

2017-05-16 Thread Chris Packham
Use mtd_device_register() instead of mtd_device_parse_register() to
eliminate two unused parameters.

Signed-off-by: Chris Packham 
---
 drivers/mtd/devices/mchp23k256.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 9d8306a15833..2542f5b8b63f 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -151,9 +151,8 @@ static int mchp23k256_probe(struct spi_device *spi)
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
-   err = mtd_device_parse_register(>mtd, NULL, NULL,
-   data ? data->parts : NULL,
-   data ? data->nr_parts : 0);
+   err = mtd_device_register(>mtd, data ? data->parts : NULL,
+ data ? data->nr_parts : 0);
if (err)
return err;
 
-- 
2.11.0.24.ge6920cf



[PATCH 2/4] mtd: mchp23k256: switch to mtd_device_register()

2017-05-16 Thread Chris Packham
Use mtd_device_register() instead of mtd_device_parse_register() to
eliminate two unused parameters.

Signed-off-by: Chris Packham 
---
 drivers/mtd/devices/mchp23k256.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 9d8306a15833..2542f5b8b63f 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -151,9 +151,8 @@ static int mchp23k256_probe(struct spi_device *spi)
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
-   err = mtd_device_parse_register(>mtd, NULL, NULL,
-   data ? data->parts : NULL,
-   data ? data->nr_parts : 0);
+   err = mtd_device_register(>mtd, data ? data->parts : NULL,
+ data ? data->nr_parts : 0);
if (err)
return err;
 
-- 
2.11.0.24.ge6920cf



[PATCH 3/4] mtd: mchp23k256: add partitioning support

2017-05-16 Thread Chris Packham
Setting the of_node for the mtd device allows the generic mtd code to
setup the partitions. Additionally we must specify a non-zero erasesize
for the partitions to be writeable.

Signed-off-by: Chris Packham 
---
 drivers/mtd/devices/mchp23k256.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 2542f5b8b63f..02c6b9dcbd3e 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -143,6 +143,7 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
@@ -151,6 +152,10 @@ static int mchp23k256_probe(struct spi_device *spi)
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
+   flash->mtd.erasesize = PAGE_SIZE;
+   while (flash->mtd.size & (flash->mtd.erasesize - 1))
+   flash->mtd.erasesize >>= 1;
+
err = mtd_device_register(>mtd, data ? data->parts : NULL,
  data ? data->nr_parts : 0);
if (err)
-- 
2.11.0.24.ge6920cf



[PATCH 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

2017-05-16 Thread Chris Packham
The mchp23lcv1024 is software compatible with the mchp23k256, the
only difference (from a software point of view) is the size. There
is no way to detect the size so we must be told via a Device Tree.

Signed-off-by: Chris Packham 
---
 .../bindings/mtd/microchip,mchp23k256.txt   |  2 +-
 drivers/mtd/devices/mchp23k256.c| 21 +++--
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
index 25e5ad38b0f0..7328eb92a03c 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -3,7 +3,7 @@
 Required properties:
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
-- compatible : Must be "microchip,mchp23k256"
+- compatible : Must be one of "microchip,mchp23k256" or 
"microchip,mchp23lcv1024"
 - reg : Chip-Select number
 - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
 
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 02c6b9dcbd3e..d1eba587633c 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+enum chips { mchp23k256, mchp23lcv1024 };
+
 struct mchp23k256_flash {
struct spi_device   *spi;
struct mutexlock;
@@ -128,6 +130,7 @@ static int mchp23k256_probe(struct spi_device *spi)
struct mchp23k256_flash *flash;
struct flash_platform_data *data;
int err;
+   enum chips chip;
 
flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
if (!flash)
@@ -143,15 +146,28 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   if (spi->dev.of_node)
+   chip = (enum chips)of_device_get_match_data(>dev);
+   else
+   chip = mchp23k256;
+
mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
flash->mtd.writesize= 1;
-   flash->mtd.size = SZ_32K;
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
+   switch (chip){
+   case mchp23lcv1024:
+   flash->mtd.size = SZ_128K;
+   break;
+   default:
+   flash->mtd.size = SZ_32K;
+   break;
+   }
+
flash->mtd.erasesize = PAGE_SIZE;
while (flash->mtd.size & (flash->mtd.erasesize - 1))
flash->mtd.erasesize >>= 1;
@@ -172,7 +188,8 @@ static int mchp23k256_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id mchp23k256_of_table[] = {
-   { .compatible = "microchip,mchp23k256" },
+   { .compatible = "microchip,mchp23k256", .data = (void *)mchp23k256 },
+   { .compatible = "microchip,mchp23lcv1024", .data = (void 
*)mchp23lcv1024 },
{}
 };
 MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
-- 
2.11.0.24.ge6920cf



[PATCH 1/4] mtd: mchp23k256: Add OF device ID table

2017-05-16 Thread Chris Packham
This allows registering of this device via a Device Tree.

Signed-off-by: Chris Packham 
---
 .../devicetree/bindings/mtd/microchip,mchp23k256.txt   | 18 ++
 drivers/mtd/devices/mchp23k256.c   |  8 
 2 files changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt

diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
new file mode 100644
index ..25e5ad38b0f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -0,0 +1,18 @@
+* MTD SPI driver for Microchip 23K256 (and similar) serial SRAM
+
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+- compatible : Must be "microchip,mchp23k256"
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+
+Example:
+
+   spi-sram@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "microchip,mchp23k256";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index e237db9f1bdb..9d8306a15833 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct mchp23k256_flash {
struct spi_device   *spi;
@@ -166,9 +167,16 @@ static int mchp23k256_remove(struct spi_device *spi)
return mtd_device_unregister(>mtd);
 }
 
+static const struct of_device_id mchp23k256_of_table[] = {
+   { .compatible = "microchip,mchp23k256" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
+
 static struct spi_driver mchp23k256_driver = {
.driver = {
.name   = "mchp23k256",
+   .of_match_table = of_match_ptr(mchp23k256_of_table),
},
.probe  = mchp23k256_probe,
.remove = mchp23k256_remove,
-- 
2.11.0.24.ge6920cf



[PATCH 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

2017-05-16 Thread Chris Packham
The mchp23lcv1024 is software compatible with the mchp23k256, the
only difference (from a software point of view) is the size. There
is no way to detect the size so we must be told via a Device Tree.

Signed-off-by: Chris Packham 
---
 .../bindings/mtd/microchip,mchp23k256.txt   |  2 +-
 drivers/mtd/devices/mchp23k256.c| 21 +++--
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
index 25e5ad38b0f0..7328eb92a03c 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -3,7 +3,7 @@
 Required properties:
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
-- compatible : Must be "microchip,mchp23k256"
+- compatible : Must be one of "microchip,mchp23k256" or 
"microchip,mchp23lcv1024"
 - reg : Chip-Select number
 - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
 
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index 02c6b9dcbd3e..d1eba587633c 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+enum chips { mchp23k256, mchp23lcv1024 };
+
 struct mchp23k256_flash {
struct spi_device   *spi;
struct mutexlock;
@@ -128,6 +130,7 @@ static int mchp23k256_probe(struct spi_device *spi)
struct mchp23k256_flash *flash;
struct flash_platform_data *data;
int err;
+   enum chips chip;
 
flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
if (!flash)
@@ -143,15 +146,28 @@ static int mchp23k256_probe(struct spi_device *spi)
 
data = dev_get_platdata(>dev);
 
+   if (spi->dev.of_node)
+   chip = (enum chips)of_device_get_match_data(>dev);
+   else
+   chip = mchp23k256;
+
mtd_set_of_node(>mtd, spi->dev.of_node);
flash->mtd.dev.parent   = >dev;
flash->mtd.type = MTD_RAM;
flash->mtd.flags= MTD_CAP_RAM;
flash->mtd.writesize= 1;
-   flash->mtd.size = SZ_32K;
flash->mtd._read= mchp23k256_read;
flash->mtd._write   = mchp23k256_write;
 
+   switch (chip){
+   case mchp23lcv1024:
+   flash->mtd.size = SZ_128K;
+   break;
+   default:
+   flash->mtd.size = SZ_32K;
+   break;
+   }
+
flash->mtd.erasesize = PAGE_SIZE;
while (flash->mtd.size & (flash->mtd.erasesize - 1))
flash->mtd.erasesize >>= 1;
@@ -172,7 +188,8 @@ static int mchp23k256_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id mchp23k256_of_table[] = {
-   { .compatible = "microchip,mchp23k256" },
+   { .compatible = "microchip,mchp23k256", .data = (void *)mchp23k256 },
+   { .compatible = "microchip,mchp23lcv1024", .data = (void 
*)mchp23lcv1024 },
{}
 };
 MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
-- 
2.11.0.24.ge6920cf



[PATCH 1/4] mtd: mchp23k256: Add OF device ID table

2017-05-16 Thread Chris Packham
This allows registering of this device via a Device Tree.

Signed-off-by: Chris Packham 
---
 .../devicetree/bindings/mtd/microchip,mchp23k256.txt   | 18 ++
 drivers/mtd/devices/mchp23k256.c   |  8 
 2 files changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt

diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
new file mode 100644
index ..25e5ad38b0f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
@@ -0,0 +1,18 @@
+* MTD SPI driver for Microchip 23K256 (and similar) serial SRAM
+
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+- compatible : Must be "microchip,mchp23k256"
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+
+Example:
+
+   spi-sram@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "microchip,mchp23k256";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   };
diff --git a/drivers/mtd/devices/mchp23k256.c b/drivers/mtd/devices/mchp23k256.c
index e237db9f1bdb..9d8306a15833 100644
--- a/drivers/mtd/devices/mchp23k256.c
+++ b/drivers/mtd/devices/mchp23k256.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct mchp23k256_flash {
struct spi_device   *spi;
@@ -166,9 +167,16 @@ static int mchp23k256_remove(struct spi_device *spi)
return mtd_device_unregister(>mtd);
 }
 
+static const struct of_device_id mchp23k256_of_table[] = {
+   { .compatible = "microchip,mchp23k256" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
+
 static struct spi_driver mchp23k256_driver = {
.driver = {
.name   = "mchp23k256",
+   .of_match_table = of_match_ptr(mchp23k256_of_table),
},
.probe  = mchp23k256_probe,
.remove = mchp23k256_remove,
-- 
2.11.0.24.ge6920cf



[PATCH 0/4] mtd: mchp23k256: device tree and mchp23lcv1024

2017-05-16 Thread Chris Packham
This series adds device tree support to the mchp23k256 driver and
support for the mchp23lcv1024 chip. I suspect there are more compatible
variants that we could now enumerate if desired.

Chris Packham (4):
  mtd: mchp23k256: Add OF device ID table
  mtd: mchp23k256: switch to mtd_device_register()
  mtd: mchp23k256: add partitioning support
  mtd: mchp23k256: Add support for mchp23lcv1024

 .../bindings/mtd/microchip,mchp23k256.txt  | 18 +++
 drivers/mtd/devices/mchp23k256.c   | 37 +++---
 2 files changed, 51 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt

-- 
2.11.0.24.ge6920cf



[PATCH 0/4] mtd: mchp23k256: device tree and mchp23lcv1024

2017-05-16 Thread Chris Packham
This series adds device tree support to the mchp23k256 driver and
support for the mchp23lcv1024 chip. I suspect there are more compatible
variants that we could now enumerate if desired.

Chris Packham (4):
  mtd: mchp23k256: Add OF device ID table
  mtd: mchp23k256: switch to mtd_device_register()
  mtd: mchp23k256: add partitioning support
  mtd: mchp23k256: Add support for mchp23lcv1024

 .../bindings/mtd/microchip,mchp23k256.txt  | 18 +++
 drivers/mtd/devices/mchp23k256.c   | 37 +++---
 2 files changed, 51 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt

-- 
2.11.0.24.ge6920cf



Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko


17.05.2017 06:39, Dong Aisheng wrote:
> On Tue, May 16, 2017 at 02:15:08PM +0300, Nikita Yushchenko wrote:
>>>  static u32 lpuart32_read(void __iomem *addr)
>>>  {
>>> -   return ioread32be(addr);
>>> +   return lpuart_is_be ? ioread32be(addr) : readl(addr);
>>>  }
>>>  
>>>  static void lpuart32_write(u32 val, void __iomem *addr)
>>>  {
>>> -   iowrite32be(val, addr);
>>> +   if (lpuart_is_be)
>>> +   iowrite32be(val, addr);
>>> +   else
>>> +   writel(val, addr);
>>>  }
>>
>> What if this is ever executed on big endian system?
>>
> 
> Sorry, not catching the point...
> 
> What issues will meet?

Isn't writel() in host endian?


Re: [V2, 2/6] tty: serial: lpuart: add little endian 32 bit register support

2017-05-16 Thread Nikita Yushchenko


17.05.2017 06:39, Dong Aisheng wrote:
> On Tue, May 16, 2017 at 02:15:08PM +0300, Nikita Yushchenko wrote:
>>>  static u32 lpuart32_read(void __iomem *addr)
>>>  {
>>> -   return ioread32be(addr);
>>> +   return lpuart_is_be ? ioread32be(addr) : readl(addr);
>>>  }
>>>  
>>>  static void lpuart32_write(u32 val, void __iomem *addr)
>>>  {
>>> -   iowrite32be(val, addr);
>>> +   if (lpuart_is_be)
>>> +   iowrite32be(val, addr);
>>> +   else
>>> +   writel(val, addr);
>>>  }
>>
>> What if this is ever executed on big endian system?
>>
> 
> Sorry, not catching the point...
> 
> What issues will meet?

Isn't writel() in host endian?


Re: [PATCH 2/4] arm: dts: rk322x: add operating-points-v2 property for cpu

2017-05-16 Thread Viresh Kumar
On 17-05-17, 12:45, Frank Wang wrote:
> From: Finley Xiao 
> 
> This patch adds a new opp table for cpu on rk322x SoC.
> 
> Signed-off-by: Frank Wang 
> ---
>  arch/arm/boot/dts/rk322x.dtsi | 36 
>  1 file changed, 32 insertions(+), 4 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 2/4] arm: dts: rk322x: add operating-points-v2 property for cpu

2017-05-16 Thread Viresh Kumar
On 17-05-17, 12:45, Frank Wang wrote:
> From: Finley Xiao 
> 
> This patch adds a new opp table for cpu on rk322x SoC.
> 
> Signed-off-by: Frank Wang 
> ---
>  arch/arm/boot/dts/rk322x.dtsi | 36 
>  1 file changed, 32 insertions(+), 4 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh


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

2017-05-16 Thread Takashi Iwai
On Wed, 17 May 2017 03:29:21 +0200,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> After merging the sound tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/delay.h:21:0,
>  from sound/pcmcia/vx/vxp_ops.c:23:
> sound/pcmcia/vx/vxp_ops.c: In function 'vxp_dma_read':
> sound/pcmcia/vx/vxp_ops.c:406:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:406:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c:406:43: note: each undeclared identifier is 
> reported only once for each function it appears in
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:406:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c: In function 'vx_set_mic_boost':
> sound/pcmcia/vx/vxp_ops.c:470:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:470:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c: In function 'vx_set_mic_level':
> sound/pcmcia/vx/vxp_ops.c:512:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:512:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> 
> Caused by commit
> 
>   7c46696e8fef ("ALSA: vxpocket: Use container_of()")
> 
> I have used the sound tree from next-20170516 for today.

My bad, I applied the wrong version of the patch.
Now fixed and pushed out.


thanks,

Takashi


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

2017-05-16 Thread Takashi Iwai
On Wed, 17 May 2017 03:29:21 +0200,
Stephen Rothwell wrote:
> 
> Hi Takashi,
> 
> After merging the sound tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/delay.h:21:0,
>  from sound/pcmcia/vx/vxp_ops.c:23:
> sound/pcmcia/vx/vxp_ops.c: In function 'vxp_dma_read':
> sound/pcmcia/vx/vxp_ops.c:406:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:406:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c:406:43: note: each undeclared identifier is 
> reported only once for each function it appears in
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:406:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c: In function 'vx_set_mic_boost':
> sound/pcmcia/vx/vxp_ops.c:470:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:470:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> sound/pcmcia/vx/vxp_ops.c: In function 'vx_set_mic_level':
> sound/pcmcia/vx/vxp_ops.c:512:43: error: '_chip' undeclared (first use in 
> this function)
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> include/linux/kernel.h:854:49: note: in definition of macro 'container_of'
>   const typeof( ((type *)0)->member ) *__mptr = (ptr); \
>  ^
> sound/pcmcia/vx/vxp_ops.c:512:31: note: in expansion of macro 'to_vxpocket'
>   struct snd_vxpocket *pchip = to_vxpocket(_chip);
>^
> 
> Caused by commit
> 
>   7c46696e8fef ("ALSA: vxpocket: Use container_of()")
> 
> I have used the sound tree from next-20170516 for today.

My bad, I applied the wrong version of the patch.
Now fixed and pushed out.


thanks,

Takashi


Re: [PATCH 3/4] arm: dts: rk3229: add a new cpu opp table

2017-05-16 Thread Viresh Kumar
On 17-05-17, 12:45, Frank Wang wrote:
> From: Finley Xiao 
> 
> This patch adds some new frequencies for rk3229 board.
> 
> Signed-off-by: Frank Wang 
> ---
>  arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 
> +++
>  1 file changed, 85 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 3/4] arm: dts: rk3229: add a new cpu opp table

2017-05-16 Thread Viresh Kumar
On 17-05-17, 12:45, Frank Wang wrote:
> From: Finley Xiao 
> 
> This patch adds some new frequencies for rk3229 board.
> 
> Signed-off-by: Frank Wang 
> ---
>  arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 
> +++
>  1 file changed, 85 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

Acked-by: Viresh Kumar 

-- 
viresh


Re: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

2017-05-16 Thread Guenter Roeck

On 05/16/2017 09:39 PM, Ye Xiaolong wrote:

On 05/17, Chris Packham wrote:

On 17/05/17 15:09, Ye Xiaolong wrote:

On 05/16, Chris Packham wrote:

On 16/05/17 20:23, kbuild test robot wrote:

Hi Chris,

[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Packham/hwmon-adt7475-fan-stall-prevention/20170515-093530
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

   drivers/hwmon/adt7475.c: In function 'set_temp_st':

drivers/hwmon/adt7475.c:622:9: error: implicit declaration of function 
'find_closest_descending' [-Werror=implicit-function-declaration]

  val = find_closest_descending(val, ad7475_st_map,
^~~
   cc1: some warnings being treated as errors

vim +/find_closest_descending +622 drivers/hwmon/adt7475.c

   616  shift = 4;
   617  idx = 1;
   618  break;
   619  }
   620  
   621  if (val > 0) {
 > 622   val = find_closest_descending(val, ad7475_st_map,
   623
ARRAY_SIZE(ad7475_st_map));
   624  val |= 0x8;
   625  }

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



I'm not sure how this is failing. find_closest_descending() is a macro
defined in linux/util_macros.h which is explicitly included in
drivers/hwmon/adt7475.c. Aside from the include guards there's nothing
conditional about it.


Hi,

0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add client 
driver for IR35221"),
is it wrong or you have some prerequisite patches?


Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.



No worries. I don't mind the occasional false positive. Better a false positive 
than a missed bug.

Guenter


Thanks,
Xiaolong




Looks like it's missing
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=hwmon-next=bbb4dd0ff
which was part of the series but was applied after v3 so I didn't send
it out with v4.






Re: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

2017-05-16 Thread Guenter Roeck

On 05/16/2017 09:39 PM, Ye Xiaolong wrote:

On 05/17, Chris Packham wrote:

On 17/05/17 15:09, Ye Xiaolong wrote:

On 05/16, Chris Packham wrote:

On 16/05/17 20:23, kbuild test robot wrote:

Hi Chris,

[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Packham/hwmon-adt7475-fan-stall-prevention/20170515-093530
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

   drivers/hwmon/adt7475.c: In function 'set_temp_st':

drivers/hwmon/adt7475.c:622:9: error: implicit declaration of function 
'find_closest_descending' [-Werror=implicit-function-declaration]

  val = find_closest_descending(val, ad7475_st_map,
^~~
   cc1: some warnings being treated as errors

vim +/find_closest_descending +622 drivers/hwmon/adt7475.c

   616  shift = 4;
   617  idx = 1;
   618  break;
   619  }
   620  
   621  if (val > 0) {
 > 622   val = find_closest_descending(val, ad7475_st_map,
   623
ARRAY_SIZE(ad7475_st_map));
   624  val |= 0x8;
   625  }

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



I'm not sure how this is failing. find_closest_descending() is a macro
defined in linux/util_macros.h which is explicitly included in
drivers/hwmon/adt7475.c. Aside from the include guards there's nothing
conditional about it.


Hi,

0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add client 
driver for IR35221"),
is it wrong or you have some prerequisite patches?


Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.



No worries. I don't mind the occasional false positive. Better a false positive 
than a missed bug.

Guenter


Thanks,
Xiaolong




Looks like it's missing
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=hwmon-next=bbb4dd0ff
which was part of the series but was applied after v3 so I didn't send
it out with v4.






Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Juergen Gross
On 16/05/17 21:58, Stefano Stabellini wrote:
> On Tue, 16 May 2017, Juergen Gross wrote:
>> On 15/05/17 22:35, Stefano Stabellini wrote:
>>> The pvcalls backend has one ioworker per cpu: the ioworkers are
>>> implemented as a cpu bound workqueue, and will deal with the actual
>>> socket and data ring reads/writes.
>>>
>>> ioworkers are global: we only have one set for all the frontends. They
>>> process requests on their wqs list in order, once they are done with a
>>> request, they'll remove it from the list. A spinlock is used for
>>> protecting the list. Each ioworker is bound to a different cpu to
>>> maximize throughput.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> ---
>>>  drivers/xen/pvcalls-back.c | 64 
>>> ++
>>>  1 file changed, 64 insertions(+)
>>>
>>> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
>>> index 2dbf7d8..46a889a 100644
>>> --- a/drivers/xen/pvcalls-back.c
>>> +++ b/drivers/xen/pvcalls-back.c
>>> @@ -25,6 +25,26 @@
>>>  #include 
>>>  #include 
>>>  
>>> +struct pvcalls_ioworker {
>>> +   struct work_struct register_work;
>>> +   atomic_t io;
>>> +   struct list_head wqs;
>>> +   spinlock_t lock;
>>> +   int num;
>>> +};
>>> +
>>> +struct pvcalls_back_global {
>>> +   struct pvcalls_ioworker *ioworkers;
>>> +   int nr_ioworkers;
>>> +   struct workqueue_struct *wq;
>>> +   struct list_head privs;
>>> +   struct rw_semaphore privs_lock;
>>> +} pvcalls_back_global;
>>> +
>>> +static void pvcalls_back_ioworker(struct work_struct *work)
>>> +{
>>> +}
>>> +
>>>  static int pvcalls_back_probe(struct xenbus_device *dev,
>>>   const struct xenbus_device_id *id)
>>>  {
>>> @@ -59,3 +79,47 @@ static int pvcalls_back_uevent(struct xenbus_device 
>>> *xdev,
>>> .uevent = pvcalls_back_uevent,
>>> .otherend_changed = pvcalls_back_changed,
>>>  };
>>> +
>>> +static int __init pvcalls_back_init(void)
>>> +{
>>> +   int ret, i, cpu;
>>> +
>>> +   if (!xen_domain())
>>> +   return -ENODEV;
>>> +
>>> +   ret = xenbus_register_backend(_back_driver);
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   init_rwsem(_back_global.privs_lock);
>>> +   INIT_LIST_HEAD(_back_global.privs);
>>> +   pvcalls_back_global.wq = alloc_workqueue("pvcalls_io", 0, 0);
>>> +   if (!pvcalls_back_global.wq)
>>> +   goto error;
>>> +   pvcalls_back_global.nr_ioworkers = num_online_cpus();
>>
>> Really? Recently I cam across a system with 640 dom0 cpus. I don't think
>> we want 640 workers initialized when loading the backend module. I'd
>> prefer one or a few workers per connected frontend.
> 
> I think we want to keep the ioworker allocation to be based on the
> number of vcpus: we do not want more ioworkers than vcpus because it is
> a waste of resources and leads to worse performance.  Also, given that
> they do memcpy's, I also think it is a good idea to bind them to vcpus
> (and pin vcpus to pcpus) to get best performance.

This will cause a lot of pain for the cpu offline case. Please don't try
to work against the hypervisor scheduler by designing a backend based on
a vcpu pin policy. This might result in best performance for your
special workload, but generally it is a bad idea!

> However, you have a point there: we need to handle systems with an
> extremely large number of Dom0 vcpus. I suggest we introduce an
> upper limit for the number of ioworkers. Something like:
> 
> #define MAX_IOWORKERS 64
> nr_ioworkers = min(MAX_IOWORKERS, num_online_cpus())
> 
> MAX_IOWORKERS could be configurable via a command line option.

Later you are assigning each active socket to exactly one ioworker.
Wouldn't it make more sense to allocate the ioworker when doing
the connect? This would avoid the problem of having only a statistical
distribution, possibly with all sockets on the same ioworker.

Basically you are re-inventing the wheel by using an own workqueue
implementation in each ioworker looping through all assigned sockets.


Juergen


Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Juergen Gross
On 16/05/17 21:58, Stefano Stabellini wrote:
> On Tue, 16 May 2017, Juergen Gross wrote:
>> On 15/05/17 22:35, Stefano Stabellini wrote:
>>> The pvcalls backend has one ioworker per cpu: the ioworkers are
>>> implemented as a cpu bound workqueue, and will deal with the actual
>>> socket and data ring reads/writes.
>>>
>>> ioworkers are global: we only have one set for all the frontends. They
>>> process requests on their wqs list in order, once they are done with a
>>> request, they'll remove it from the list. A spinlock is used for
>>> protecting the list. Each ioworker is bound to a different cpu to
>>> maximize throughput.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> ---
>>>  drivers/xen/pvcalls-back.c | 64 
>>> ++
>>>  1 file changed, 64 insertions(+)
>>>
>>> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
>>> index 2dbf7d8..46a889a 100644
>>> --- a/drivers/xen/pvcalls-back.c
>>> +++ b/drivers/xen/pvcalls-back.c
>>> @@ -25,6 +25,26 @@
>>>  #include 
>>>  #include 
>>>  
>>> +struct pvcalls_ioworker {
>>> +   struct work_struct register_work;
>>> +   atomic_t io;
>>> +   struct list_head wqs;
>>> +   spinlock_t lock;
>>> +   int num;
>>> +};
>>> +
>>> +struct pvcalls_back_global {
>>> +   struct pvcalls_ioworker *ioworkers;
>>> +   int nr_ioworkers;
>>> +   struct workqueue_struct *wq;
>>> +   struct list_head privs;
>>> +   struct rw_semaphore privs_lock;
>>> +} pvcalls_back_global;
>>> +
>>> +static void pvcalls_back_ioworker(struct work_struct *work)
>>> +{
>>> +}
>>> +
>>>  static int pvcalls_back_probe(struct xenbus_device *dev,
>>>   const struct xenbus_device_id *id)
>>>  {
>>> @@ -59,3 +79,47 @@ static int pvcalls_back_uevent(struct xenbus_device 
>>> *xdev,
>>> .uevent = pvcalls_back_uevent,
>>> .otherend_changed = pvcalls_back_changed,
>>>  };
>>> +
>>> +static int __init pvcalls_back_init(void)
>>> +{
>>> +   int ret, i, cpu;
>>> +
>>> +   if (!xen_domain())
>>> +   return -ENODEV;
>>> +
>>> +   ret = xenbus_register_backend(_back_driver);
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   init_rwsem(_back_global.privs_lock);
>>> +   INIT_LIST_HEAD(_back_global.privs);
>>> +   pvcalls_back_global.wq = alloc_workqueue("pvcalls_io", 0, 0);
>>> +   if (!pvcalls_back_global.wq)
>>> +   goto error;
>>> +   pvcalls_back_global.nr_ioworkers = num_online_cpus();
>>
>> Really? Recently I cam across a system with 640 dom0 cpus. I don't think
>> we want 640 workers initialized when loading the backend module. I'd
>> prefer one or a few workers per connected frontend.
> 
> I think we want to keep the ioworker allocation to be based on the
> number of vcpus: we do not want more ioworkers than vcpus because it is
> a waste of resources and leads to worse performance.  Also, given that
> they do memcpy's, I also think it is a good idea to bind them to vcpus
> (and pin vcpus to pcpus) to get best performance.

This will cause a lot of pain for the cpu offline case. Please don't try
to work against the hypervisor scheduler by designing a backend based on
a vcpu pin policy. This might result in best performance for your
special workload, but generally it is a bad idea!

> However, you have a point there: we need to handle systems with an
> extremely large number of Dom0 vcpus. I suggest we introduce an
> upper limit for the number of ioworkers. Something like:
> 
> #define MAX_IOWORKERS 64
> nr_ioworkers = min(MAX_IOWORKERS, num_online_cpus())
> 
> MAX_IOWORKERS could be configurable via a command line option.

Later you are assigning each active socket to exactly one ioworker.
Wouldn't it make more sense to allocate the ioworker when doing
the connect? This would avoid the problem of having only a statistical
distribution, possibly with all sockets on the same ioworker.

Basically you are re-inventing the wheel by using an own workqueue
implementation in each ioworker looping through all assigned sockets.


Juergen


Re: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER

2017-05-16 Thread Sricharan R
Hi,

On 5/16/2017 7:39 PM, Jonathan Neuschäfer wrote:
> Hi, I have a few suggestions on how to make this commit message more
> readable:
> 
> On Tue, May 16, 2017 at 10:54:13AM +0530, Sricharan R wrote:
>> While returning EPROBE_DEFER for iommu masters
> 
> Add a comma at the end of this line
> 
>> take in to account of iommu nodes that could be
> 
> s/in to/into/
> s/of iommu/of_iommu/
> 

ok, will correct the above.

Regards,
 Sricharan

>> marked in DT as 'status=disabled', in which case
>> simply return NULL and let the master's probe
>> continue rather than deferring.
>>
>> Signed-off-by: Sricharan R 
>> Tested-by: Will Deacon 
>> Acked-by: Will Deacon 
> 
> 
> Thanks,
> Jonathan Neuschäfer
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation


Re: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER

2017-05-16 Thread Sricharan R
Hi,

On 5/16/2017 7:39 PM, Jonathan Neuschäfer wrote:
> Hi, I have a few suggestions on how to make this commit message more
> readable:
> 
> On Tue, May 16, 2017 at 10:54:13AM +0530, Sricharan R wrote:
>> While returning EPROBE_DEFER for iommu masters
> 
> Add a comma at the end of this line
> 
>> take in to account of iommu nodes that could be
> 
> s/in to/into/
> s/of iommu/of_iommu/
> 

ok, will correct the above.

Regards,
 Sricharan

>> marked in DT as 'status=disabled', in which case
>> simply return NULL and let the master's probe
>> continue rather than deferring.
>>
>> Signed-off-by: Sricharan R 
>> Tested-by: Will Deacon 
>> Acked-by: Will Deacon 
> 
> 
> Thanks,
> Jonathan Neuschäfer
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation


Re: [PATCH v2] perf report: fix off-by-one for non-activation frames

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 06:26:47PM +0200, Milian Wolff wrote:
> On Dienstag, 16. Mai 2017 18:17:26 CEST Milian Wolff wrote:
> > On Dienstag, 16. Mai 2017 16:38:29 CEST Namhyung Kim wrote:
> > > On Tue, May 16, 2017 at 10:59:51AM +0200, Milian Wolff wrote:
> > > > As the documentation for dwfl_frame_pc says, frames that
> > > > are no activation frames need to have their program counter
> > > > decremented by one to properly find the function of the caller.
> > > > 
> > > > This fixes many cases where perf report currently attributes
> > > > the cost to the next line. I.e. I have code like this:
> > > > 
> > > > ~~~
> > > > 
> > > >   #include 
> > > >   #include 
> > > >   
> > > >   using namespace std;
> > > >   
> > > >   int main()
> > > >   {
> > > >   
> > > > this_thread::sleep_for(chrono::milliseconds(1000));
> > > > this_thread::sleep_for(chrono::milliseconds(100));
> > > > this_thread::sleep_for(chrono::milliseconds(10));
> > > > 
> > > > return 0;
> > > >   
> > > >   }
> > > > 
> > > > ~~~
> > > 
> > > It'd be nice if the test program has a signal frame for verification.
> > 
> > I have pretty much zero experience about signals. Would it be enough to add
> > a signal handler for, say, SIGUSR1 to my test application and then trigger
> > a sleep when that signal is delivered? If that should be enough, I'll write
> > and test it out.
> 
> ~~~
> #include 
> #include 
> #include 
> 
> using namespace std;
> 
> volatile bool run_loop = true;
> 
> void my_handler(int signum)
> {
> this_thread::sleep_for(chrono::milliseconds(1000));
> this_thread::sleep_for(chrono::milliseconds(100));
> this_thread::sleep_for(chrono::milliseconds(10));
> run_loop = false;
> }
> 
> int main()
> {
> signal(SIGUSR1, my_handler);
> 
> while (run_loop) {}
> 
> return 0;
> }
> ~~~
> 
> This does not properly unwind neither before nor after this patch. I only 
> ever 
> get:
> 
>100.00%  core.c:0
> |
> ---__schedule core.c:0
>schedule
>do_nanosleep hrtimer.c:0
>hrtimer_nanosleep
>sys_nanosleep
>entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
>__nanosleep_nocancel .:0
>std::this_thread::sleep_for > 
> thread:323
> 
> So... should this work? Please tell me how to test this properly.

How did you send the SIGUSR1 to the process?

Anyway it does nothing to do with inlining, right?  I just wrote a
test code below to burn a cpu with or without a signal frame.

  $ nl -ba frame-addr.c
 1  #include 
 2  #include 
 3  #include 
 4  
 5  #define __noinline  __attribute__((noinline))
 6  
 7  __noinline void bar(void)
 8  {
 9volatile long cnt = 0;
10  
11for (cnt = 0; cnt < 1; cnt++);
12  }
13  
14  __noinline void foo(void)
15  {
16bar();
17  }
18  
19  void sig_handler(int sig)
20  {
21foo();
22  }
23  
24  int main(void)
25  {
26signal(SIGUSR1, sig_handler);
27raise(SIGUSR1);
28  
29foo();
30return 0;
31  }

  $ gcc -O2 -g -fno-optimize-sibling-calls -o frame-addr frame-addr.c

  $ perf record --call-graph dwarf ./frame-addr

  $ perf report -q -g srcline | head -15
  99.88%  frame-addr  frame-addr[.] bar
  |
  ---bar frame-addr.c:11
 foo frame-addr.c:16
 |  
 |--51.12%--main frame-addr.c:29
 |  __libc_start_main
 |  _start
 |  
  --48.76%--sig_handler frame-addr.c:21
0x33a8f
raise .:0
main frame-addr.c:29   <--- bad
__libc_start_main
_start

Note that 'raise' was called at line 27.  It seems that simply
checking current frame fixes it.

Thanks,
Namhyung



Re: [PATCH v2] perf report: fix off-by-one for non-activation frames

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 06:26:47PM +0200, Milian Wolff wrote:
> On Dienstag, 16. Mai 2017 18:17:26 CEST Milian Wolff wrote:
> > On Dienstag, 16. Mai 2017 16:38:29 CEST Namhyung Kim wrote:
> > > On Tue, May 16, 2017 at 10:59:51AM +0200, Milian Wolff wrote:
> > > > As the documentation for dwfl_frame_pc says, frames that
> > > > are no activation frames need to have their program counter
> > > > decremented by one to properly find the function of the caller.
> > > > 
> > > > This fixes many cases where perf report currently attributes
> > > > the cost to the next line. I.e. I have code like this:
> > > > 
> > > > ~~~
> > > > 
> > > >   #include 
> > > >   #include 
> > > >   
> > > >   using namespace std;
> > > >   
> > > >   int main()
> > > >   {
> > > >   
> > > > this_thread::sleep_for(chrono::milliseconds(1000));
> > > > this_thread::sleep_for(chrono::milliseconds(100));
> > > > this_thread::sleep_for(chrono::milliseconds(10));
> > > > 
> > > > return 0;
> > > >   
> > > >   }
> > > > 
> > > > ~~~
> > > 
> > > It'd be nice if the test program has a signal frame for verification.
> > 
> > I have pretty much zero experience about signals. Would it be enough to add
> > a signal handler for, say, SIGUSR1 to my test application and then trigger
> > a sleep when that signal is delivered? If that should be enough, I'll write
> > and test it out.
> 
> ~~~
> #include 
> #include 
> #include 
> 
> using namespace std;
> 
> volatile bool run_loop = true;
> 
> void my_handler(int signum)
> {
> this_thread::sleep_for(chrono::milliseconds(1000));
> this_thread::sleep_for(chrono::milliseconds(100));
> this_thread::sleep_for(chrono::milliseconds(10));
> run_loop = false;
> }
> 
> int main()
> {
> signal(SIGUSR1, my_handler);
> 
> while (run_loop) {}
> 
> return 0;
> }
> ~~~
> 
> This does not properly unwind neither before nor after this patch. I only 
> ever 
> get:
> 
>100.00%  core.c:0
> |
> ---__schedule core.c:0
>schedule
>do_nanosleep hrtimer.c:0
>hrtimer_nanosleep
>sys_nanosleep
>entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
>__nanosleep_nocancel .:0
>std::this_thread::sleep_for > 
> thread:323
> 
> So... should this work? Please tell me how to test this properly.

How did you send the SIGUSR1 to the process?

Anyway it does nothing to do with inlining, right?  I just wrote a
test code below to burn a cpu with or without a signal frame.

  $ nl -ba frame-addr.c
 1  #include 
 2  #include 
 3  #include 
 4  
 5  #define __noinline  __attribute__((noinline))
 6  
 7  __noinline void bar(void)
 8  {
 9volatile long cnt = 0;
10  
11for (cnt = 0; cnt < 1; cnt++);
12  }
13  
14  __noinline void foo(void)
15  {
16bar();
17  }
18  
19  void sig_handler(int sig)
20  {
21foo();
22  }
23  
24  int main(void)
25  {
26signal(SIGUSR1, sig_handler);
27raise(SIGUSR1);
28  
29foo();
30return 0;
31  }

  $ gcc -O2 -g -fno-optimize-sibling-calls -o frame-addr frame-addr.c

  $ perf record --call-graph dwarf ./frame-addr

  $ perf report -q -g srcline | head -15
  99.88%  frame-addr  frame-addr[.] bar
  |
  ---bar frame-addr.c:11
 foo frame-addr.c:16
 |  
 |--51.12%--main frame-addr.c:29
 |  __libc_start_main
 |  _start
 |  
  --48.76%--sig_handler frame-addr.c:21
0x33a8f
raise .:0
main frame-addr.c:29   <--- bad
__libc_start_main
_start

Note that 'raise' was called at line 27.  It seems that simply
checking current frame fixes it.

Thanks,
Namhyung



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

2017-05-16 Thread Willem de Bruijn
On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell  
wrote:
> Hi all,
>
> After merging the netfilter tree, today's linux-next build (i386
> defconfig) failed like this:
>
> net/netfilter/x_tables.c: In function 'xt_match_to_user':
> net/netfilter/x_tables.c:303:13: error: implicit declaration of function 
> 'COMPAT_XT_ALIGN' [-Werror=implicit-function-declaration]
> C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
>  ^
> net/netfilter/x_tables.c:310:9: note: in expansion of macro 'XT_DATA_TO_USER'
>  XT_DATA_TO_USER(u, m, match, 0);
>  ^
>
> Caused by commit
>
>   324318f0248c ("netfilter: xtables: zero padding in data_to_user")
>
> In the !CONFIG_COMPAT case C_SIZE will always be zero, but the compiler
> is still looking for the macro :-(

Apologies for the breakage.

> I added this cludge patch (I am sure it can be done better):
>
> From: Stephen Rothwell 
> Date: Wed, 17 May 2017 13:36:26 +1000
> Subject: [PATCH] netfilter: xtables: fix for zero padding in data_to_user
>
> Signed-off-by: Stephen Rothwell 
> ---
>  net/netfilter/x_tables.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index d17769599c10..2b1785993a92 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -296,12 +296,20 @@ int xt_data_to_user(void __user *dst, const void *src,
>  }
>  EXPORT_SYMBOL_GPL(xt_data_to_user);
>
> +#ifdef CONFIG_COMPAT
>  #define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
> xt_data_to_user(U->data, K->data,   \
> K->u.kernel.TYPE->usersize, \
> C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
> C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
>  XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
> +#else
> +#define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
> +   xt_data_to_user(U->data, K->data,   \
> +   K->u.kernel.TYPE->usersize, \
> +   C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
> +   C_SIZE ? : XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
> +#endif
>

I will send a patch to the netfilter to define a separate
COMPAT_XT_DATA_TO_USER inside the CONFIG_COMPAT region further down
the file. This also allows simplifying XT_DATA_TO_USER by removing
those ternary statements.

-#define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
+#define XT_DATA_TO_USER(U, K, TYPE)\
xt_data_to_user(U->data, K->data,   \
K->u.kernel.TYPE->usersize, \
-   C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
-   C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
-XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
+   K->u.kernel.TYPE->TYPE##size,   \
+   XT_ALIGN(K->u.kernel.TYPE->TYPE##size))

and

+#define COMPAT_XT_DATA_TO_USER(U, K, TYPE, C_SIZE) \
+   xt_data_to_user(U->data, K->data,   \
+   K->u.kernel.TYPE->usersize, \
+   C_SIZE, \
+   COMPAT_XT_ALIGN(C_SIZE))
+


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

2017-05-16 Thread Willem de Bruijn
On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell  
wrote:
> Hi all,
>
> After merging the netfilter tree, today's linux-next build (i386
> defconfig) failed like this:
>
> net/netfilter/x_tables.c: In function 'xt_match_to_user':
> net/netfilter/x_tables.c:303:13: error: implicit declaration of function 
> 'COMPAT_XT_ALIGN' [-Werror=implicit-function-declaration]
> C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
>  ^
> net/netfilter/x_tables.c:310:9: note: in expansion of macro 'XT_DATA_TO_USER'
>  XT_DATA_TO_USER(u, m, match, 0);
>  ^
>
> Caused by commit
>
>   324318f0248c ("netfilter: xtables: zero padding in data_to_user")
>
> In the !CONFIG_COMPAT case C_SIZE will always be zero, but the compiler
> is still looking for the macro :-(

Apologies for the breakage.

> I added this cludge patch (I am sure it can be done better):
>
> From: Stephen Rothwell 
> Date: Wed, 17 May 2017 13:36:26 +1000
> Subject: [PATCH] netfilter: xtables: fix for zero padding in data_to_user
>
> Signed-off-by: Stephen Rothwell 
> ---
>  net/netfilter/x_tables.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index d17769599c10..2b1785993a92 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -296,12 +296,20 @@ int xt_data_to_user(void __user *dst, const void *src,
>  }
>  EXPORT_SYMBOL_GPL(xt_data_to_user);
>
> +#ifdef CONFIG_COMPAT
>  #define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
> xt_data_to_user(U->data, K->data,   \
> K->u.kernel.TYPE->usersize, \
> C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
> C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
>  XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
> +#else
> +#define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
> +   xt_data_to_user(U->data, K->data,   \
> +   K->u.kernel.TYPE->usersize, \
> +   C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
> +   C_SIZE ? : XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
> +#endif
>

I will send a patch to the netfilter to define a separate
COMPAT_XT_DATA_TO_USER inside the CONFIG_COMPAT region further down
the file. This also allows simplifying XT_DATA_TO_USER by removing
those ternary statements.

-#define XT_DATA_TO_USER(U, K, TYPE, C_SIZE)\
+#define XT_DATA_TO_USER(U, K, TYPE)\
xt_data_to_user(U->data, K->data,   \
K->u.kernel.TYPE->usersize, \
-   C_SIZE ? : K->u.kernel.TYPE->TYPE##size,\
-   C_SIZE ? COMPAT_XT_ALIGN(C_SIZE) :  \
-XT_ALIGN(K->u.kernel.TYPE->TYPE##size))
+   K->u.kernel.TYPE->TYPE##size,   \
+   XT_ALIGN(K->u.kernel.TYPE->TYPE##size))

and

+#define COMPAT_XT_DATA_TO_USER(U, K, TYPE, C_SIZE) \
+   xt_data_to_user(U->data, K->data,   \
+   K->u.kernel.TYPE->usersize, \
+   C_SIZE, \
+   COMPAT_XT_ALIGN(C_SIZE))
+


Re: linux-next: build warning after merge of the overlayfs tree

2017-05-16 Thread Amir Goldstein
On Wed, May 17, 2017 at 3:19 AM, Stephen Rothwell  wrote:
> Hi Miklos,
>
> After merging the overlayfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/overlayfs/dir.c: In function 'ovl_rename':
> fs/overlayfs/dir.c:1060:2: warning: 'newdentry' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   dput(newdentry);
>   ^
> fs/overlayfs/dir.c:1062:2: warning: 'olddentry' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   dput(olddentry);
>   ^
>
> Introduced by commit
>
>   02cac3227a28 ("ovl: mark upper dir with type origin entries "impure"")
>

Posted a fix for that ("ovl: fix wrong error handling of ovl_set_impure()")

Thanks!


Re: linux-next: build warning after merge of the overlayfs tree

2017-05-16 Thread Amir Goldstein
On Wed, May 17, 2017 at 3:19 AM, Stephen Rothwell  wrote:
> Hi Miklos,
>
> After merging the overlayfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/overlayfs/dir.c: In function 'ovl_rename':
> fs/overlayfs/dir.c:1060:2: warning: 'newdentry' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   dput(newdentry);
>   ^
> fs/overlayfs/dir.c:1062:2: warning: 'olddentry' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   dput(olddentry);
>   ^
>
> Introduced by commit
>
>   02cac3227a28 ("ovl: mark upper dir with type origin entries "impure"")
>

Posted a fix for that ("ovl: fix wrong error handling of ovl_set_impure()")

Thanks!


[PATCH 3/4] arm: dts: rk3229: add a new cpu opp table

2017-05-16 Thread Frank Wang
From: Finley Xiao 

This patch adds some new frequencies for rk3229 board.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 +++
 1 file changed, 85 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

diff --git a/arch/arm/boot/dts/rk3229-cpu-opp.dtsi 
b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
new file mode 100644
index 000..89e8413
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+   /delete-node/ opp-table0;
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <975000>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <100>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1175000>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1275000>;
+   };
+   opp-129600 {
+   opp-hz = /bits/ 64 <129600>;
+   opp-microvolt = <1325000>;
+   };
+   opp-139200 {
+   opp-hz = /bits/ 64 <139200>;
+   opp-microvolt = <1375000>;
+   };
+   opp-146400 {
+   opp-hz = /bits/ 64 <146400>;
+   opp-microvolt = <140>;
+   };
+   };
+};
-- 
2.0.0




[PATCH 3/4] arm: dts: rk3229: add a new cpu opp table

2017-05-16 Thread Frank Wang
From: Finley Xiao 

This patch adds some new frequencies for rk3229 board.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 +++
 1 file changed, 85 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

diff --git a/arch/arm/boot/dts/rk3229-cpu-opp.dtsi 
b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
new file mode 100644
index 000..89e8413
--- /dev/null
+++ b/arch/arm/boot/dts/rk3229-cpu-opp.dtsi
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+   /delete-node/ opp-table0;
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <975000>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <100>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1175000>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1275000>;
+   };
+   opp-129600 {
+   opp-hz = /bits/ 64 <129600>;
+   opp-microvolt = <1325000>;
+   };
+   opp-139200 {
+   opp-hz = /bits/ 64 <139200>;
+   opp-microvolt = <1375000>;
+   };
+   opp-146400 {
+   opp-hz = /bits/ 64 <146400>;
+   opp-microvolt = <140>;
+   };
+   };
+};
-- 
2.0.0




[PATCH 2/4] arm: dts: rk322x: add operating-points-v2 property for cpu

2017-05-16 Thread Frank Wang
From: Finley Xiao 

This patch adds a new opp table for cpu on rk322x SoC.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 40044e8..7809e56 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -66,10 +66,7 @@
compatible = "arm,cortex-a7";
reg = <0xf00>;
resets = < SRST_CORE0>;
-   operating-points = <
-   /* KHzuV */
-816000 100
-   >;
+   operating-points-v2 = <_opp_table>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
@@ -80,6 +77,7 @@
compatible = "arm,cortex-a7";
reg = <0xf01>;
resets = < SRST_CORE1>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu2: cpu@f02 {
@@ -87,6 +85,7 @@
compatible = "arm,cortex-a7";
reg = <0xf02>;
resets = < SRST_CORE2>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu3: cpu@f03 {
@@ -94,6 +93,35 @@
compatible = "arm,cortex-a7";
reg = <0xf03>;
resets = < SRST_CORE3>;
+   operating-points-v2 = <_opp_table>;
+   };
+   };
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <975000>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <100>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1175000>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1275000>;
};
};
 
-- 
2.0.0




[PATCH 2/4] arm: dts: rk322x: add operating-points-v2 property for cpu

2017-05-16 Thread Frank Wang
From: Finley Xiao 

This patch adds a new opp table for cpu on rk322x SoC.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 40044e8..7809e56 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -66,10 +66,7 @@
compatible = "arm,cortex-a7";
reg = <0xf00>;
resets = < SRST_CORE0>;
-   operating-points = <
-   /* KHzuV */
-816000 100
-   >;
+   operating-points-v2 = <_opp_table>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
@@ -80,6 +77,7 @@
compatible = "arm,cortex-a7";
reg = <0xf01>;
resets = < SRST_CORE1>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu2: cpu@f02 {
@@ -87,6 +85,7 @@
compatible = "arm,cortex-a7";
reg = <0xf02>;
resets = < SRST_CORE2>;
+   operating-points-v2 = <_opp_table>;
};
 
cpu3: cpu@f03 {
@@ -94,6 +93,35 @@
compatible = "arm,cortex-a7";
reg = <0xf03>;
resets = < SRST_CORE3>;
+   operating-points-v2 = <_opp_table>;
+   };
+   };
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <975000>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <100>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1175000>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1275000>;
};
};
 
-- 
2.0.0




[PATCH 0/4] amend some properties related clk and cpu for rk322x

2017-05-16 Thread Frank Wang
These series of patches amend some assigned-clocks and add cpu opp table
for rk322x SoCs.

the following patches on patchwork are required for this changes.
https://patchwork.kernel.org/patch/9627639/
https://patchwork.kernel.org/patch/9703945/
https://patchwork.kernel.org/patch/9703939/
https://patchwork.kernel.org/patch/9707517/

Elaine Zhang (1):
  arm: dts: rk322x: add some assigned-clocks

Finley Xiao (2):
  arm: dts: rk322x: add operating-points-v2 property for cpu
  arm: dts: rk3229: add a new cpu opp table

Rocky Hao (1):
  arm: dts: rk322x: update tsadc's frequence setting

 arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 +++
 arch/arm/boot/dts/rk322x.dtsi | 52 ++---
 2 files changed, 131 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

-- 
2.0.0




[PATCH 0/4] amend some properties related clk and cpu for rk322x

2017-05-16 Thread Frank Wang
These series of patches amend some assigned-clocks and add cpu opp table
for rk322x SoCs.

the following patches on patchwork are required for this changes.
https://patchwork.kernel.org/patch/9627639/
https://patchwork.kernel.org/patch/9703945/
https://patchwork.kernel.org/patch/9703939/
https://patchwork.kernel.org/patch/9707517/

Elaine Zhang (1):
  arm: dts: rk322x: add some assigned-clocks

Finley Xiao (2):
  arm: dts: rk322x: add operating-points-v2 property for cpu
  arm: dts: rk3229: add a new cpu opp table

Rocky Hao (1):
  arm: dts: rk322x: update tsadc's frequence setting

 arch/arm/boot/dts/rk3229-cpu-opp.dtsi | 85 +++
 arch/arm/boot/dts/rk322x.dtsi | 52 ++---
 2 files changed, 131 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/rk3229-cpu-opp.dtsi

-- 
2.0.0




[PATCH 1/4] arm: dts: rk322x: add some assigned-clocks

2017-05-16 Thread Frank Wang
From: Elaine Zhang 

Add CPLL, GPLL and some other assigned-clocks for rk322x SoC.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 221251a..40044e8 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -346,8 +346,18 @@
rockchip,grf = <>;
#clock-cells = <1>;
#reset-cells = <1>;
-   assigned-clocks = < PLL_GPLL>;
-   assigned-clock-rates = <59400>;
+   assigned-clocks =
+   < PLL_GPLL>, < ARMCLK>,
+   < PLL_CPLL>, < ACLK_PERI>,
+   < HCLK_PERI>, < PCLK_PERI>,
+   < ACLK_CPU>, < HCLK_CPU>,
+   < PCLK_CPU>;
+   assigned-clock-rates =
+   <59400>, <81600>,
+   <5>, <15000>,
+   <15000>, <7500>,
+   <15000>, <15000>,
+   <7500>;
};
 
thermal-zones {
-- 
2.0.0




[PATCH 4/4] arm: dts: rk322x: update tsadc's frequence setting

2017-05-16 Thread Frank Wang
From: Rocky Hao 

Update freq of tsadc's working clock as 32768 hz, if not set, tsadc
will work at a default frequence.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 7809e56..d2e9641 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -434,6 +434,8 @@
interrupts = ;
clocks = < SCLK_TSADC>, < PCLK_TSADC>;
clock-names = "tsadc", "apb_pclk";
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <32768>;
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
pinctrl-names = "init", "default", "sleep";
-- 
2.0.0




[PATCH 1/4] arm: dts: rk322x: add some assigned-clocks

2017-05-16 Thread Frank Wang
From: Elaine Zhang 

Add CPLL, GPLL and some other assigned-clocks for rk322x SoC.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 221251a..40044e8 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -346,8 +346,18 @@
rockchip,grf = <>;
#clock-cells = <1>;
#reset-cells = <1>;
-   assigned-clocks = < PLL_GPLL>;
-   assigned-clock-rates = <59400>;
+   assigned-clocks =
+   < PLL_GPLL>, < ARMCLK>,
+   < PLL_CPLL>, < ACLK_PERI>,
+   < HCLK_PERI>, < PCLK_PERI>,
+   < ACLK_CPU>, < HCLK_CPU>,
+   < PCLK_CPU>;
+   assigned-clock-rates =
+   <59400>, <81600>,
+   <5>, <15000>,
+   <15000>, <7500>,
+   <15000>, <15000>,
+   <7500>;
};
 
thermal-zones {
-- 
2.0.0




[PATCH 4/4] arm: dts: rk322x: update tsadc's frequence setting

2017-05-16 Thread Frank Wang
From: Rocky Hao 

Update freq of tsadc's working clock as 32768 hz, if not set, tsadc
will work at a default frequence.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk322x.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 7809e56..d2e9641 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -434,6 +434,8 @@
interrupts = ;
clocks = < SCLK_TSADC>, < PCLK_TSADC>;
clock-names = "tsadc", "apb_pclk";
+   assigned-clocks = < SCLK_TSADC>;
+   assigned-clock-rates = <32768>;
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
pinctrl-names = "init", "default", "sleep";
-- 
2.0.0




[PATCH 2/4] PM / OPP: Don't create copy of regulators unnecessarily

2017-05-16 Thread Viresh Kumar
This code was required while the OPP core was managed with help of RCUs,
but not anymore. Get rid of unnecessary alloc/memcpy operations.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/core.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 402b9e86d77c..898f19ea0f60 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -180,7 +180,7 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device 
*dev)
 {
struct opp_table *opp_table;
struct dev_pm_opp *opp;
-   struct regulator *reg, **regulators;
+   struct regulator *reg;
unsigned long latency_ns = 0;
int ret, i, count;
struct {
@@ -198,15 +198,9 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct 
device *dev)
if (!count)
goto put_opp_table;
 
-   regulators = kmalloc_array(count, sizeof(*regulators), GFP_KERNEL);
-   if (!regulators)
-   goto put_opp_table;
-
uV = kmalloc_array(count, sizeof(*uV), GFP_KERNEL);
if (!uV)
-   goto free_regulators;
-
-   memcpy(regulators, opp_table->regulators, count * sizeof(*regulators));
+   goto put_opp_table;
 
mutex_lock(_table->lock);
 
@@ -232,15 +226,13 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct 
device *dev)
 * isn't freed, while we are executing this routine.
 */
for (i = 0; i < count; i++) {
-   reg = regulators[i];
+   reg = opp_table->regulators[i];
ret = regulator_set_voltage_time(reg, uV[i].min, uV[i].max);
if (ret > 0)
latency_ns += ret * 1000;
}
 
kfree(uV);
-free_regulators:
-   kfree(regulators);
 put_opp_table:
dev_pm_opp_put_opp_table(opp_table);
 
-- 
2.13.0.303.g4ebf3021692d



[PATCH 2/4] PM / OPP: Don't create copy of regulators unnecessarily

2017-05-16 Thread Viresh Kumar
This code was required while the OPP core was managed with help of RCUs,
but not anymore. Get rid of unnecessary alloc/memcpy operations.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/core.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 402b9e86d77c..898f19ea0f60 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -180,7 +180,7 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device 
*dev)
 {
struct opp_table *opp_table;
struct dev_pm_opp *opp;
-   struct regulator *reg, **regulators;
+   struct regulator *reg;
unsigned long latency_ns = 0;
int ret, i, count;
struct {
@@ -198,15 +198,9 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct 
device *dev)
if (!count)
goto put_opp_table;
 
-   regulators = kmalloc_array(count, sizeof(*regulators), GFP_KERNEL);
-   if (!regulators)
-   goto put_opp_table;
-
uV = kmalloc_array(count, sizeof(*uV), GFP_KERNEL);
if (!uV)
-   goto free_regulators;
-
-   memcpy(regulators, opp_table->regulators, count * sizeof(*regulators));
+   goto put_opp_table;
 
mutex_lock(_table->lock);
 
@@ -232,15 +226,13 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct 
device *dev)
 * isn't freed, while we are executing this routine.
 */
for (i = 0; i < count; i++) {
-   reg = regulators[i];
+   reg = opp_table->regulators[i];
ret = regulator_set_voltage_time(reg, uV[i].min, uV[i].max);
if (ret > 0)
latency_ns += ret * 1000;
}
 
kfree(uV);
-free_regulators:
-   kfree(regulators);
 put_opp_table:
dev_pm_opp_put_opp_table(opp_table);
 
-- 
2.13.0.303.g4ebf3021692d



Re: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

2017-05-16 Thread Ye Xiaolong
On 05/17, Chris Packham wrote:
>On 17/05/17 15:09, Ye Xiaolong wrote:
>> On 05/16, Chris Packham wrote:
>>> On 16/05/17 20:23, kbuild test robot wrote:
>>>> Hi Chris,
>>>>
>>>> [auto build test ERROR on hwmon/hwmon-next]
>>>> [also build test ERROR on v4.12-rc1 next-20170516]
>>>> [if your patch is applied to the wrong git tree, please drop us a note to 
>>>> help improve the system]
>>>>
>>>> url:
>>>> https://github.com/0day-ci/linux/commits/Chris-Packham/hwmon-adt7475-fan-stall-prevention/20170515-093530
>>>> base:   
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
>>>> hwmon-next
>>>> config: x86_64-rhel (attached as .config)
>>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>>> reproduce:
>>>> # save the attached .config to linux build tree
>>>> make ARCH=x86_64
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>drivers/hwmon/adt7475.c: In function 'set_temp_st':
>>>>>> drivers/hwmon/adt7475.c:622:9: error: implicit declaration of function 
>>>>>> 'find_closest_descending' [-Werror=implicit-function-declaration]
>>>>   val = find_closest_descending(val, ad7475_st_map,
>>>> ^~~
>>>>cc1: some warnings being treated as errors
>>>>
>>>> vim +/find_closest_descending +622 drivers/hwmon/adt7475.c
>>>>
>>>>616 shift = 4;
>>>>617 idx = 1;
>>>>618 break;
>>>>619 }
>>>>620 
>>>>621 if (val > 0) {
>>>>  > 622 val = find_closest_descending(val, 
>>>> ad7475_st_map,
>>>>623   
>>>> ARRAY_SIZE(ad7475_st_map));
>>>>624 val |= 0x8;
>>>>625 }
>>>>
>>>> ---
>>>> 0-DAY kernel test infrastructureOpen Source Technology 
>>>> Center
>>>> https://lists.01.org/pipermail/kbuild-all   Intel 
>>>> Corporation
>>>>
>>>
>>> I'm not sure how this is failing. find_closest_descending() is a macro
>>> defined in linux/util_macros.h which is explicitly included in
>>> drivers/hwmon/adt7475.c. Aside from the include guards there's nothing
>>> conditional about it.
>>
>> Hi,
>>
>> 0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add 
>> client driver for IR35221"),
>> is it wrong or you have some prerequisite patches?

Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.

Thanks,
Xiaolong
>>
>
>Looks like it's missing 
>https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=hwmon-next=bbb4dd0ff
> 
>which was part of the series but was applied after v3 so I didn't send 
>it out with v4.


Re: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

2017-05-16 Thread Ye Xiaolong
On 05/17, Chris Packham wrote:
>On 17/05/17 15:09, Ye Xiaolong wrote:
>> On 05/16, Chris Packham wrote:
>>> On 16/05/17 20:23, kbuild test robot wrote:
>>>> Hi Chris,
>>>>
>>>> [auto build test ERROR on hwmon/hwmon-next]
>>>> [also build test ERROR on v4.12-rc1 next-20170516]
>>>> [if your patch is applied to the wrong git tree, please drop us a note to 
>>>> help improve the system]
>>>>
>>>> url:
>>>> https://github.com/0day-ci/linux/commits/Chris-Packham/hwmon-adt7475-fan-stall-prevention/20170515-093530
>>>> base:   
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
>>>> hwmon-next
>>>> config: x86_64-rhel (attached as .config)
>>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>>> reproduce:
>>>> # save the attached .config to linux build tree
>>>> make ARCH=x86_64
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>>drivers/hwmon/adt7475.c: In function 'set_temp_st':
>>>>>> drivers/hwmon/adt7475.c:622:9: error: implicit declaration of function 
>>>>>> 'find_closest_descending' [-Werror=implicit-function-declaration]
>>>>   val = find_closest_descending(val, ad7475_st_map,
>>>> ^~~
>>>>cc1: some warnings being treated as errors
>>>>
>>>> vim +/find_closest_descending +622 drivers/hwmon/adt7475.c
>>>>
>>>>616 shift = 4;
>>>>617 idx = 1;
>>>>618 break;
>>>>619 }
>>>>620 
>>>>621 if (val > 0) {
>>>>  > 622 val = find_closest_descending(val, 
>>>> ad7475_st_map,
>>>>623   
>>>> ARRAY_SIZE(ad7475_st_map));
>>>>624 val |= 0x8;
>>>>625 }
>>>>
>>>> ---
>>>> 0-DAY kernel test infrastructureOpen Source Technology 
>>>> Center
>>>> https://lists.01.org/pipermail/kbuild-all   Intel 
>>>> Corporation
>>>>
>>>
>>> I'm not sure how this is failing. find_closest_descending() is a macro
>>> defined in linux/util_macros.h which is explicitly included in
>>> drivers/hwmon/adt7475.c. Aside from the include guards there's nothing
>>> conditional about it.
>>
>> Hi,
>>
>> 0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add 
>> client driver for IR35221"),
>> is it wrong or you have some prerequisite patches?

Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.

Thanks,
Xiaolong
>>
>
>Looks like it's missing 
>https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=hwmon-next=bbb4dd0ff
> 
>which was part of the series but was applied after v3 so I didn't send 
>it out with v4.


[PATCH 3/4] PM / OPP: opp-microvolt is not optional if regulators are set

2017-05-16 Thread Viresh Kumar
If dev_pm_opp_set_regulators() is called for a device and its regulators
are set in the OPP core, the OPP nodes for the device must contain the
"opp-microvolt" property, otherwise there is something wrong and we
better error out.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/of.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 779428676f63..c6fc8cbad10d 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -131,8 +131,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, 
struct device *dev,
prop = of_find_property(opp->np, name, NULL);
 
/* Missing property isn't a problem, but an invalid entry is */
-   if (!prop)
-   return 0;
+   if (!prop) {
+   /* The regulator-count must be zero here */
+   if (!opp_table->regulator_count)
+   return 0;
+
+   dev_err(dev, "%s: opp-microvolt missing even if 
regulators are available\n",
+   __func__);
+   return -EINVAL;
+   }
}
 
vcount = of_property_count_u32_elems(opp->np, name);
-- 
2.13.0.303.g4ebf3021692d



[PATCH 4/4] PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

2017-05-16 Thread Viresh Kumar
We create "supply-0" debugfs directory even if the device doesn't do
voltage scaling. That looks confusing, as if the regulator is found but
we never managed to get voltage levels for it.

Avoid creating such a directory unnecessarily.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/debugfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp/debugfs.c b/drivers/base/power/opp/debugfs.c
index 95f433db4ac7..ce6f4832946b 100644
--- a/drivers/base/power/opp/debugfs.c
+++ b/drivers/base/power/opp/debugfs.c
@@ -40,11 +40,11 @@ static bool opp_debug_create_supplies(struct dev_pm_opp 
*opp,
  struct dentry *pdentry)
 {
struct dentry *d;
-   int i = 0;
+   int i = -1;
char *name;
 
/* Always create at least supply-0 directory */
-   do {
+   while (++i < opp_table->regulator_count) {
name = kasprintf(GFP_KERNEL, "supply-%d", i);
 
/* Create per-opp directory */
@@ -70,7 +70,7 @@ static bool opp_debug_create_supplies(struct dev_pm_opp *opp,
if (!debugfs_create_ulong("u_amp", S_IRUGO, d,
  >supplies[i].u_amp))
return false;
-   } while (++i < opp_table->regulator_count);
+   }
 
return true;
 }
-- 
2.13.0.303.g4ebf3021692d



[PATCH 3/4] PM / OPP: opp-microvolt is not optional if regulators are set

2017-05-16 Thread Viresh Kumar
If dev_pm_opp_set_regulators() is called for a device and its regulators
are set in the OPP core, the OPP nodes for the device must contain the
"opp-microvolt" property, otherwise there is something wrong and we
better error out.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/of.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 779428676f63..c6fc8cbad10d 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -131,8 +131,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, 
struct device *dev,
prop = of_find_property(opp->np, name, NULL);
 
/* Missing property isn't a problem, but an invalid entry is */
-   if (!prop)
-   return 0;
+   if (!prop) {
+   /* The regulator-count must be zero here */
+   if (!opp_table->regulator_count)
+   return 0;
+
+   dev_err(dev, "%s: opp-microvolt missing even if 
regulators are available\n",
+   __func__);
+   return -EINVAL;
+   }
}
 
vcount = of_property_count_u32_elems(opp->np, name);
-- 
2.13.0.303.g4ebf3021692d



[PATCH 4/4] PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

2017-05-16 Thread Viresh Kumar
We create "supply-0" debugfs directory even if the device doesn't do
voltage scaling. That looks confusing, as if the regulator is found but
we never managed to get voltage levels for it.

Avoid creating such a directory unnecessarily.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/debugfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/opp/debugfs.c b/drivers/base/power/opp/debugfs.c
index 95f433db4ac7..ce6f4832946b 100644
--- a/drivers/base/power/opp/debugfs.c
+++ b/drivers/base/power/opp/debugfs.c
@@ -40,11 +40,11 @@ static bool opp_debug_create_supplies(struct dev_pm_opp 
*opp,
  struct dentry *pdentry)
 {
struct dentry *d;
-   int i = 0;
+   int i = -1;
char *name;
 
/* Always create at least supply-0 directory */
-   do {
+   while (++i < opp_table->regulator_count) {
name = kasprintf(GFP_KERNEL, "supply-%d", i);
 
/* Create per-opp directory */
@@ -70,7 +70,7 @@ static bool opp_debug_create_supplies(struct dev_pm_opp *opp,
if (!debugfs_create_ulong("u_amp", S_IRUGO, d,
  >supplies[i].u_amp))
return false;
-   } while (++i < opp_table->regulator_count);
+   }
 
return true;
 }
-- 
2.13.0.303.g4ebf3021692d



[PATCH 1/4] PM / OPP: Reorganize _generic_set_opp_regulator()

2017-05-16 Thread Viresh Kumar
The code was overly complicated here because of the limitations that we
had with RCUs (Couldn't use opp-table and OPPs outside RCU protected
section and can't call sleep-able routines from within that). But that
is long gone now.

Reorganize _generic_set_opp_regulator() in order to avoid using "struct
dev_pm_set_opp_data" and copying data into it for the case where
opp_table->set_opp is not set.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/core.c | 73 ---
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index dae61720b314..402b9e86d77c 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -543,17 +543,18 @@ _generic_set_opp_clk_only(struct device *dev, struct clk 
*clk,
return ret;
 }
 
-static int _generic_set_opp(struct dev_pm_set_opp_data *data)
+static int _generic_set_opp_regulator(struct opp_table *opp_table,
+ struct device *dev,
+ unsigned long old_freq,
+ unsigned long freq,
+ struct dev_pm_opp_supply *old_supply,
+ struct dev_pm_opp_supply *new_supply)
 {
-   struct dev_pm_opp_supply *old_supply = data->old_opp.supplies;
-   struct dev_pm_opp_supply *new_supply = data->new_opp.supplies;
-   unsigned long old_freq = data->old_opp.rate, freq = data->new_opp.rate;
-   struct regulator *reg = data->regulators[0];
-   struct device *dev= data->dev;
+   struct regulator *reg = opp_table->regulators[0];
int ret;
 
/* This function only supports single regulator per device */
-   if (WARN_ON(data->regulator_count > 1)) {
+   if (WARN_ON(opp_table->regulator_count > 1)) {
dev_err(dev, "multiple regulators are not supported\n");
return -EINVAL;
}
@@ -566,7 +567,7 @@ static int _generic_set_opp(struct dev_pm_set_opp_data 
*data)
}
 
/* Change frequency */
-   ret = _generic_set_opp_clk_only(dev, data->clk, old_freq, freq);
+   ret = _generic_set_opp_clk_only(dev, opp_table->clk, old_freq, freq);
if (ret)
goto restore_voltage;
 
@@ -580,12 +581,12 @@ static int _generic_set_opp(struct dev_pm_set_opp_data 
*data)
return 0;
 
 restore_freq:
-   if (_generic_set_opp_clk_only(dev, data->clk, freq, old_freq))
+   if (_generic_set_opp_clk_only(dev, opp_table->clk, freq, old_freq))
dev_err(dev, "%s: failed to restore old-freq (%lu Hz)\n",
__func__, old_freq);
 restore_voltage:
/* This shouldn't harm even if the voltages weren't updated earlier */
-   if (old_supply->u_volt)
+   if (old_supply)
_set_opp_voltage(dev, reg, old_supply);
 
return ret;
@@ -603,10 +604,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 {
struct opp_table *opp_table;
unsigned long freq, old_freq;
-   int (*set_opp)(struct dev_pm_set_opp_data *data);
struct dev_pm_opp *old_opp, *opp;
-   struct regulator **regulators;
-   struct dev_pm_set_opp_data *data;
struct clk *clk;
int ret, size;
 
@@ -661,38 +659,35 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
dev_dbg(dev, "%s: switching OPP: %lu Hz --> %lu Hz\n", __func__,
old_freq, freq);
 
-   regulators = opp_table->regulators;
-
/* Only frequency scaling */
-   if (!regulators) {
+   if (!opp_table->regulators) {
ret = _generic_set_opp_clk_only(dev, clk, old_freq, freq);
-   goto put_opps;
-   }
+   } else if (!opp_table->set_opp) {
+   ret = _generic_set_opp_regulator(opp_table, dev, old_freq, freq,
+IS_ERR(old_opp) ? NULL : 
old_opp->supplies,
+opp->supplies);
+   } else {
+   struct dev_pm_set_opp_data *data;
 
-   if (opp_table->set_opp)
-   set_opp = opp_table->set_opp;
-   else
-   set_opp = _generic_set_opp;
-
-   data = opp_table->set_opp_data;
-   data->regulators = regulators;
-   data->regulator_count = opp_table->regulator_count;
-   data->clk = clk;
-   data->dev = dev;
-
-   data->old_opp.rate = old_freq;
-   size = sizeof(*opp->supplies) * opp_table->regulator_count;
-   if (IS_ERR(old_opp))
-   memset(data->old_opp.supplies, 0, size);
-   else
-   memcpy(data->old_opp.supplies, old_opp->supplies, size);
+   data = opp_table->set_opp_data;
+   data->regulators = opp_table->regulators;
+   data->regulator_count = opp_table->regulator_count;
+  

[PATCH 1/4] PM / OPP: Reorganize _generic_set_opp_regulator()

2017-05-16 Thread Viresh Kumar
The code was overly complicated here because of the limitations that we
had with RCUs (Couldn't use opp-table and OPPs outside RCU protected
section and can't call sleep-able routines from within that). But that
is long gone now.

Reorganize _generic_set_opp_regulator() in order to avoid using "struct
dev_pm_set_opp_data" and copying data into it for the case where
opp_table->set_opp is not set.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/core.c | 73 ---
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index dae61720b314..402b9e86d77c 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -543,17 +543,18 @@ _generic_set_opp_clk_only(struct device *dev, struct clk 
*clk,
return ret;
 }
 
-static int _generic_set_opp(struct dev_pm_set_opp_data *data)
+static int _generic_set_opp_regulator(struct opp_table *opp_table,
+ struct device *dev,
+ unsigned long old_freq,
+ unsigned long freq,
+ struct dev_pm_opp_supply *old_supply,
+ struct dev_pm_opp_supply *new_supply)
 {
-   struct dev_pm_opp_supply *old_supply = data->old_opp.supplies;
-   struct dev_pm_opp_supply *new_supply = data->new_opp.supplies;
-   unsigned long old_freq = data->old_opp.rate, freq = data->new_opp.rate;
-   struct regulator *reg = data->regulators[0];
-   struct device *dev= data->dev;
+   struct regulator *reg = opp_table->regulators[0];
int ret;
 
/* This function only supports single regulator per device */
-   if (WARN_ON(data->regulator_count > 1)) {
+   if (WARN_ON(opp_table->regulator_count > 1)) {
dev_err(dev, "multiple regulators are not supported\n");
return -EINVAL;
}
@@ -566,7 +567,7 @@ static int _generic_set_opp(struct dev_pm_set_opp_data 
*data)
}
 
/* Change frequency */
-   ret = _generic_set_opp_clk_only(dev, data->clk, old_freq, freq);
+   ret = _generic_set_opp_clk_only(dev, opp_table->clk, old_freq, freq);
if (ret)
goto restore_voltage;
 
@@ -580,12 +581,12 @@ static int _generic_set_opp(struct dev_pm_set_opp_data 
*data)
return 0;
 
 restore_freq:
-   if (_generic_set_opp_clk_only(dev, data->clk, freq, old_freq))
+   if (_generic_set_opp_clk_only(dev, opp_table->clk, freq, old_freq))
dev_err(dev, "%s: failed to restore old-freq (%lu Hz)\n",
__func__, old_freq);
 restore_voltage:
/* This shouldn't harm even if the voltages weren't updated earlier */
-   if (old_supply->u_volt)
+   if (old_supply)
_set_opp_voltage(dev, reg, old_supply);
 
return ret;
@@ -603,10 +604,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 {
struct opp_table *opp_table;
unsigned long freq, old_freq;
-   int (*set_opp)(struct dev_pm_set_opp_data *data);
struct dev_pm_opp *old_opp, *opp;
-   struct regulator **regulators;
-   struct dev_pm_set_opp_data *data;
struct clk *clk;
int ret, size;
 
@@ -661,38 +659,35 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
dev_dbg(dev, "%s: switching OPP: %lu Hz --> %lu Hz\n", __func__,
old_freq, freq);
 
-   regulators = opp_table->regulators;
-
/* Only frequency scaling */
-   if (!regulators) {
+   if (!opp_table->regulators) {
ret = _generic_set_opp_clk_only(dev, clk, old_freq, freq);
-   goto put_opps;
-   }
+   } else if (!opp_table->set_opp) {
+   ret = _generic_set_opp_regulator(opp_table, dev, old_freq, freq,
+IS_ERR(old_opp) ? NULL : 
old_opp->supplies,
+opp->supplies);
+   } else {
+   struct dev_pm_set_opp_data *data;
 
-   if (opp_table->set_opp)
-   set_opp = opp_table->set_opp;
-   else
-   set_opp = _generic_set_opp;
-
-   data = opp_table->set_opp_data;
-   data->regulators = regulators;
-   data->regulator_count = opp_table->regulator_count;
-   data->clk = clk;
-   data->dev = dev;
-
-   data->old_opp.rate = old_freq;
-   size = sizeof(*opp->supplies) * opp_table->regulator_count;
-   if (IS_ERR(old_opp))
-   memset(data->old_opp.supplies, 0, size);
-   else
-   memcpy(data->old_opp.supplies, old_opp->supplies, size);
+   data = opp_table->set_opp_data;
+   data->regulators = opp_table->regulators;
+   data->regulator_count = opp_table->regulator_count;
+   data->clk = clk;
+  

[PATCH 0/4] PM / OPP: Minor cleanups

2017-05-16 Thread Viresh Kumar
Hi,

Here are few cleanup patches for the OPP core. The first two simplify
the code that was written specifically due to the limitations that we
had because of RCUs. We don't RCUs anymore and this can be simplified.

The last two take care of specific corner cases.

Rebased over pm/linux-next and tested on Exynos dual core board.

Viresh Kumar (4):
  PM / OPP: Reorganize _generic_set_opp_regulator()
  PM / OPP: Don't create copy of regulators unnecessarily
  PM / OPP: opp-microvolt is not optional if regulators are set
  PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

 drivers/base/power/opp/core.c| 87 +---
 drivers/base/power/opp/debugfs.c |  6 +--
 drivers/base/power/opp/of.c  | 11 -
 3 files changed, 49 insertions(+), 55 deletions(-)

-- 
2.13.0.303.g4ebf3021692d



[PATCH 0/4] PM / OPP: Minor cleanups

2017-05-16 Thread Viresh Kumar
Hi,

Here are few cleanup patches for the OPP core. The first two simplify
the code that was written specifically due to the limitations that we
had because of RCUs. We don't RCUs anymore and this can be simplified.

The last two take care of specific corner cases.

Rebased over pm/linux-next and tested on Exynos dual core board.

Viresh Kumar (4):
  PM / OPP: Reorganize _generic_set_opp_regulator()
  PM / OPP: Don't create copy of regulators unnecessarily
  PM / OPP: opp-microvolt is not optional if regulators are set
  PM / OPP: Don't create debugfs "supply-0" directory unnecessarily

 drivers/base/power/opp/core.c| 87 +---
 drivers/base/power/opp/debugfs.c |  6 +--
 drivers/base/power/opp/of.c  | 11 -
 3 files changed, 49 insertions(+), 55 deletions(-)

-- 
2.13.0.303.g4ebf3021692d



Re: [PATCH v1] cpufreq: kirkwood-cpufreq:- Handle return value of clk_prepare_enable

2017-05-16 Thread Viresh Kumar
On 16-05-17, 12:41, Arvind Yadav wrote:
> Here, Clock enable can failed. So adding an error check for
> clk_prepare_enable.

Rewrite it as:

clk_prepare_enable() can fail here and we must check its return value.

> Signed-off-by: Arvind Yadav 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index 1b9bcd7..4c30103 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -127,7 +127,12 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(priv.cpu_clk);
>   }
>  
> - clk_prepare_enable(priv.cpu_clk);
> + err = clk_prepare_enable(priv.cpu_clk);
> + if (err) {
> + dev_err(priv.dev, "Unable to prepare cpuclk\n");
> + return err;
> + }
> +
>   kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
>  
>   priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");
> @@ -137,7 +142,11 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   goto out_cpu;
>   }
>  
> - clk_prepare_enable(priv.ddr_clk);
> + err = clk_prepare_enable(priv.ddr_clk);
> + if (err) {
> + dev_err(priv.dev, "Unable to prepare ddrclk\n");
> + goto out_cpu;
> + }
>   kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
>  
>   priv.powersave_clk = of_clk_get_by_name(np, "powersave");

There is one more prepare-enable after this. Why not fix that as well
?

-- 
viresh


Re: [PATCH v1] cpufreq: kirkwood-cpufreq:- Handle return value of clk_prepare_enable

2017-05-16 Thread Viresh Kumar
On 16-05-17, 12:41, Arvind Yadav wrote:
> Here, Clock enable can failed. So adding an error check for
> clk_prepare_enable.

Rewrite it as:

clk_prepare_enable() can fail here and we must check its return value.

> Signed-off-by: Arvind Yadav 
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c 
> b/drivers/cpufreq/kirkwood-cpufreq.c
> index 1b9bcd7..4c30103 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -127,7 +127,12 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(priv.cpu_clk);
>   }
>  
> - clk_prepare_enable(priv.cpu_clk);
> + err = clk_prepare_enable(priv.cpu_clk);
> + if (err) {
> + dev_err(priv.dev, "Unable to prepare cpuclk\n");
> + return err;
> + }
> +
>   kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
>  
>   priv.ddr_clk = of_clk_get_by_name(np, "ddrclk");
> @@ -137,7 +142,11 @@ static int kirkwood_cpufreq_probe(struct platform_device 
> *pdev)
>   goto out_cpu;
>   }
>  
> - clk_prepare_enable(priv.ddr_clk);
> + err = clk_prepare_enable(priv.ddr_clk);
> + if (err) {
> + dev_err(priv.dev, "Unable to prepare ddrclk\n");
> + goto out_cpu;
> + }
>   kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
>  
>   priv.powersave_clk = of_clk_get_by_name(np, "powersave");

There is one more prepare-enable after this. Why not fix that as well
?

-- 
viresh


[PATCH v3 2/2] powerpc/mm/hugetlb: Add support for 1G huge pages

2017-05-16 Thread Aneesh Kumar K.V
POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch
enables the usage of 1G page size for hugetlbfs. This also update the helper
such we can do 1G page allocation at runtime.

We still don't enable 1G page size on DD1 version. This is to avoid doing
workaround mentioned in commit: 6d3a0379ebdc8 (powerpc/mm: Add
radix__tlb_flush_pte_p9_dd1()

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/hugetlb.h | 10 ++
 arch/powerpc/mm/hugetlbpage.c|  7 +--
 arch/powerpc/platforms/Kconfig.cputype   |  1 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index cd366596..5c28bd6f2ae1 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -50,4 +50,14 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct 
vm_area_struct *vma,
else
return entry;
 }
+
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void)
+{
+   if (radix_enabled())
+   return true;
+   return false;
+}
+#endif
+
 #endif
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index a4f33de4008e..80f6d2ed551a 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -763,8 +763,11 @@ static int __init add_huge_page_size(unsigned long long 
size)
 * Hash: 16M and 16G
 */
if (radix_enabled()) {
-   if (mmu_psize != MMU_PAGE_2M)
-   return -EINVAL;
+   if (mmu_psize != MMU_PAGE_2M) {
+   if (cpu_has_feature(CPU_FTR_POWER9_DD1) ||
+   (mmu_psize != MMU_PAGE_1G))
+   return -EINVAL;
+   }
} else {
if (mmu_psize != MMU_PAGE_16M && mmu_psize != MMU_PAGE_16G)
return -EINVAL;
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 684e886eaae4..b76ef6637016 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -344,6 +344,7 @@ config PPC_STD_MMU_64
 config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
default y
help
  Enable support for the Power ISA 3.0 Radix style MMU. Currently this
-- 
2.7.4



[PATCH v3 2/2] powerpc/mm/hugetlb: Add support for 1G huge pages

2017-05-16 Thread Aneesh Kumar K.V
POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch
enables the usage of 1G page size for hugetlbfs. This also update the helper
such we can do 1G page allocation at runtime.

We still don't enable 1G page size on DD1 version. This is to avoid doing
workaround mentioned in commit: 6d3a0379ebdc8 (powerpc/mm: Add
radix__tlb_flush_pte_p9_dd1()

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/hugetlb.h | 10 ++
 arch/powerpc/mm/hugetlbpage.c|  7 +--
 arch/powerpc/platforms/Kconfig.cputype   |  1 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index cd366596..5c28bd6f2ae1 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -50,4 +50,14 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct 
vm_area_struct *vma,
else
return entry;
 }
+
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void)
+{
+   if (radix_enabled())
+   return true;
+   return false;
+}
+#endif
+
 #endif
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index a4f33de4008e..80f6d2ed551a 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -763,8 +763,11 @@ static int __init add_huge_page_size(unsigned long long 
size)
 * Hash: 16M and 16G
 */
if (radix_enabled()) {
-   if (mmu_psize != MMU_PAGE_2M)
-   return -EINVAL;
+   if (mmu_psize != MMU_PAGE_2M) {
+   if (cpu_has_feature(CPU_FTR_POWER9_DD1) ||
+   (mmu_psize != MMU_PAGE_1G))
+   return -EINVAL;
+   }
} else {
if (mmu_psize != MMU_PAGE_16M && mmu_psize != MMU_PAGE_16G)
return -EINVAL;
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 684e886eaae4..b76ef6637016 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -344,6 +344,7 @@ config PPC_STD_MMU_64
 config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
default y
help
  Enable support for the Power ISA 3.0 Radix style MMU. Currently this
-- 
2.7.4



[PATCH v3 1/2] mm/hugetlb: Cleanup ARCH_HAS_GIGANTIC_PAGE

2017-05-16 Thread Aneesh Kumar K.V
This moves the #ifdef in C code to a Kconfig dependency. Also we move the
gigantic_page_supported() function to be arch specific. This gives arch to
conditionally enable runtime allocation of gigantic huge page. Architectures
like ppc64 supports different gigantic huge page size (16G and 1G) based on the
translation mode selected. This provides an opportunity for ppc64 to enable
runtime allocation only w.r.t 1G hugepage.

No functional change in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
Changes from V2:
* Fix build error with x86
* Update the Kconfig change to match the C #ifdef

 arch/arm64/Kconfig   | 2 +-
 arch/arm64/include/asm/hugetlb.h | 4 
 arch/s390/Kconfig| 2 +-
 arch/s390/include/asm/hugetlb.h  | 3 +++
 arch/x86/Kconfig | 2 +-
 arch/x86/include/asm/hugetlb.h   | 4 
 mm/hugetlb.c | 7 ++-
 7 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3741859765cf..87240dcb6a07 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,7 +11,7 @@ config ARM64
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index bbc1e35aa601..793bd73b0d07 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -83,4 +83,8 @@ extern void huge_ptep_set_wrprotect(struct mm_struct *mm,
 extern void huge_ptep_clear_flush(struct vm_area_struct *vma,
  unsigned long addr, pte_t *ptep);
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
+
 #endif /* __ASM_HUGETLB_H */
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index a2dcef0aacc7..f3637b641d7e 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,7 @@ config S390
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
diff --git a/arch/s390/include/asm/hugetlb.h b/arch/s390/include/asm/hugetlb.h
index cd546a245c68..89057b2cc8fe 100644
--- a/arch/s390/include/asm/hugetlb.h
+++ b/arch/s390/include/asm/hugetlb.h
@@ -112,4 +112,7 @@ static inline pte_t huge_pte_modify(pte_t pte, pgprot_t 
newprot)
return pte_modify(pte, newprot);
 }
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
 #endif /* _ASM_S390_HUGETLB_H */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a294ee..e39b3b6b7d16 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -22,7 +22,7 @@ config X86_64
def_bool y
depends on 64BIT
# Options that are inherently 64-bit kernel only:
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_SUPPORTS_INT128
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_SOFT_DIRTY
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 3a106165e03a..535af0f2d8ac 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -85,4 +85,8 @@ static inline void arch_clear_hugepage_flags(struct page 
*page)
 {
 }
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
+
 #endif /* _ASM_X86_HUGETLB_H */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3d0aab9ee80d..ce090186b992 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1024,9 +1024,7 @@ static int hstate_next_node_to_free(struct hstate *h, 
nodemask_t *nodes_allowed)
((node = hstate_next_node_to_free(hs, mask)) || 1); \
nr_nodes--)
 
-#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
-   ((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
-   defined(CONFIG_CMA))
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
 static void destroy_compound_gigantic_page(struct page *page,
unsigned int order)
 {
@@ -1158,8 +1156,7 @@ static int alloc_fresh_gigantic_page(struct hstate *h,
return 0;
 }
 
-static inline bool gigantic_page_supported(void) { return true; }
-#else
+#else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE */
 static inline bool gigantic_page_supported(void) { return false; }
 static inline void free_gigantic_page(struct page *page, unsigned int order) { 
}
 static inline void 

[PATCH v3 1/2] mm/hugetlb: Cleanup ARCH_HAS_GIGANTIC_PAGE

2017-05-16 Thread Aneesh Kumar K.V
This moves the #ifdef in C code to a Kconfig dependency. Also we move the
gigantic_page_supported() function to be arch specific. This gives arch to
conditionally enable runtime allocation of gigantic huge page. Architectures
like ppc64 supports different gigantic huge page size (16G and 1G) based on the
translation mode selected. This provides an opportunity for ppc64 to enable
runtime allocation only w.r.t 1G hugepage.

No functional change in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
Changes from V2:
* Fix build error with x86
* Update the Kconfig change to match the C #ifdef

 arch/arm64/Kconfig   | 2 +-
 arch/arm64/include/asm/hugetlb.h | 4 
 arch/s390/Kconfig| 2 +-
 arch/s390/include/asm/hugetlb.h  | 3 +++
 arch/x86/Kconfig | 2 +-
 arch/x86/include/asm/hugetlb.h   | 4 
 mm/hugetlb.c | 7 ++-
 7 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3741859765cf..87240dcb6a07 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,7 +11,7 @@ config ARM64
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index bbc1e35aa601..793bd73b0d07 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -83,4 +83,8 @@ extern void huge_ptep_set_wrprotect(struct mm_struct *mm,
 extern void huge_ptep_clear_flush(struct vm_area_struct *vma,
  unsigned long addr, pte_t *ptep);
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
+
 #endif /* __ASM_HUGETLB_H */
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index a2dcef0aacc7..f3637b641d7e 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,7 @@ config S390
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_HAS_KCOV
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_SG_CHAIN
diff --git a/arch/s390/include/asm/hugetlb.h b/arch/s390/include/asm/hugetlb.h
index cd546a245c68..89057b2cc8fe 100644
--- a/arch/s390/include/asm/hugetlb.h
+++ b/arch/s390/include/asm/hugetlb.h
@@ -112,4 +112,7 @@ static inline pte_t huge_pte_modify(pte_t pte, pgprot_t 
newprot)
return pte_modify(pte, newprot);
 }
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
 #endif /* _ASM_S390_HUGETLB_H */
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a294ee..e39b3b6b7d16 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -22,7 +22,7 @@ config X86_64
def_bool y
depends on 64BIT
# Options that are inherently 64-bit kernel only:
-   select ARCH_HAS_GIGANTIC_PAGE
+   select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
select ARCH_SUPPORTS_INT128
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_SOFT_DIRTY
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 3a106165e03a..535af0f2d8ac 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -85,4 +85,8 @@ static inline void arch_clear_hugepage_flags(struct page 
*page)
 {
 }
 
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
+static inline bool gigantic_page_supported(void) { return true; }
+#endif
+
 #endif /* _ASM_X86_HUGETLB_H */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3d0aab9ee80d..ce090186b992 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1024,9 +1024,7 @@ static int hstate_next_node_to_free(struct hstate *h, 
nodemask_t *nodes_allowed)
((node = hstate_next_node_to_free(hs, mask)) || 1); \
nr_nodes--)
 
-#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
-   ((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
-   defined(CONFIG_CMA))
+#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
 static void destroy_compound_gigantic_page(struct page *page,
unsigned int order)
 {
@@ -1158,8 +1156,7 @@ static int alloc_fresh_gigantic_page(struct hstate *h,
return 0;
 }
 
-static inline bool gigantic_page_supported(void) { return true; }
-#else
+#else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE */
 static inline bool gigantic_page_supported(void) { return false; }
 static inline void free_gigantic_page(struct page *page, unsigned int order) { 
}
 static inline void 

Re: [PATCH] perf report: do not drop last inlined frame

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:54:33PM +0200, Milian Wolff wrote:
> The very last inlined frame, i.e. the one furthest away from the
> non-inlined frame, was silently dropped. This is apparent when
> comparing the output of `perf script` and `addr2line`:
> 
> ~~
> $ perf script --inline
> ...
> a.out 26722 80836.309329:  72425 cycles:
>21493 __hypot_finite (/usr/lib/libm-2.25.so)
>  a4a std::abs (inline) (/tmp/a.out)
>  a4a std::_Norm_helper::_S_do_it (inline) 
> (/tmp/a.out)
>  a4a std::norm (inline) (/tmp/a.out)
>  a4a main (/tmp/a.out)
>20510 __libc_start_main (/usr/lib/libc-2.25.so)
>  bd9 _start (/tmp/a.out)
> 
> $ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
> 0x0a4a
> std::__complex_abs(doublecomplex )
> /usr/include/c++/6.3.1/complex:589
> double std::abs(std::complex const&)
> /usr/include/c++/6.3.1/complex:597
> double std::_Norm_helper::_S_do_it(std::complex const&)
> /usr/include/c++/6.3.1/complex:654
> double std::norm(std::complex const&)
> /usr/include/c++/6.3.1/complex:664
> main
> /tmp/inlining.cpp:14
> ~
> 
> Note how `std::__complex_abs` is missing from the `perf script`
> output. This is similarly showing up in `perf report`. The patch
> here fixes this issue, and the output becomes:
> 
> ~
> a.out 26722 80836.309329:  72425 cycles:
>21493 __hypot_finite (/usr/lib/libm-2.25.so)
> ace3 hypot (/usr/lib/libm-2.25.so)
>  a4a std::__complex_abs (inline) (/tmp/a.out)
>  a4a std::abs (inline) (/tmp/a.out)
>  a4a std::_Norm_helper::_S_do_it (inline) 
> (/tmp/a.out)
>  a4a std::norm (inline) (/tmp/a.out)
>  a4a main (/tmp/a.out)
>20510 __libc_start_main (/usr/lib/libc-2.25.so)
>  bd9 _start (/tmp/a.out)
> ~
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 

I also noticed this and thank you for fixing it.

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/srcline.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index 8df6b29bf984..160999c51fb0 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -208,6 +208,16 @@ static void addr2line_cleanup(struct a2l_data *a2l)
>  
>  #define MAX_INLINE_NEST 1024
>  
> +static int inline_list__append_dso_a2l(struct dso *dso,
> +struct inline_node *node)
> +{
> + struct a2l_data *a2l = dso->a2l;
> + char *funcname = a2l->funcname ? strdup(a2l->funcname) : NULL;
> + char *filename = a2l->filename ? strdup(a2l->filename) : NULL;
> +
> + return inline_list__append(filename, funcname, a2l->line, node, dso);
> +}
> +
>  static int addr2line(const char *dso_name, u64 addr,
>char **file, unsigned int *line, struct dso *dso,
>bool unwind_inlines, struct inline_node *node)
> @@ -233,17 +243,15 @@ static int addr2line(const char *dso_name, u64 addr,
>   if (a2l->found && unwind_inlines) {
>   int cnt = 0;
>  
> + if (node && inline_list__append_dso_a2l(dso, node))
> + return 0;
> +
>   while (bfd_find_inliner_info(a2l->abfd, >filename,
>>funcname, >line) &&
>  cnt++ < MAX_INLINE_NEST) {
>  
> - if (node != NULL) {
> - if (inline_list__append(strdup(a2l->filename),
> - strdup(a2l->funcname),
> - a2l->line, node,
> - dso) != 0)
> - return 0;
> - }
> + if (node && inline_list__append_dso_a2l(dso, node))
> + return 0;
>   }
>   }
>  
> -- 
> 2.13.0
> 


Re: [PATCH] perf report: do not drop last inlined frame

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:54:33PM +0200, Milian Wolff wrote:
> The very last inlined frame, i.e. the one furthest away from the
> non-inlined frame, was silently dropped. This is apparent when
> comparing the output of `perf script` and `addr2line`:
> 
> ~~
> $ perf script --inline
> ...
> a.out 26722 80836.309329:  72425 cycles:
>21493 __hypot_finite (/usr/lib/libm-2.25.so)
>  a4a std::abs (inline) (/tmp/a.out)
>  a4a std::_Norm_helper::_S_do_it (inline) 
> (/tmp/a.out)
>  a4a std::norm (inline) (/tmp/a.out)
>  a4a main (/tmp/a.out)
>20510 __libc_start_main (/usr/lib/libc-2.25.so)
>  bd9 _start (/tmp/a.out)
> 
> $ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
> 0x0a4a
> std::__complex_abs(doublecomplex )
> /usr/include/c++/6.3.1/complex:589
> double std::abs(std::complex const&)
> /usr/include/c++/6.3.1/complex:597
> double std::_Norm_helper::_S_do_it(std::complex const&)
> /usr/include/c++/6.3.1/complex:654
> double std::norm(std::complex const&)
> /usr/include/c++/6.3.1/complex:664
> main
> /tmp/inlining.cpp:14
> ~
> 
> Note how `std::__complex_abs` is missing from the `perf script`
> output. This is similarly showing up in `perf report`. The patch
> here fixes this issue, and the output becomes:
> 
> ~
> a.out 26722 80836.309329:  72425 cycles:
>21493 __hypot_finite (/usr/lib/libm-2.25.so)
> ace3 hypot (/usr/lib/libm-2.25.so)
>  a4a std::__complex_abs (inline) (/tmp/a.out)
>  a4a std::abs (inline) (/tmp/a.out)
>  a4a std::_Norm_helper::_S_do_it (inline) 
> (/tmp/a.out)
>  a4a std::norm (inline) (/tmp/a.out)
>  a4a main (/tmp/a.out)
>20510 __libc_start_main (/usr/lib/libc-2.25.so)
>  bd9 _start (/tmp/a.out)
> ~
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 

I also noticed this and thank you for fixing it.

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/srcline.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index 8df6b29bf984..160999c51fb0 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -208,6 +208,16 @@ static void addr2line_cleanup(struct a2l_data *a2l)
>  
>  #define MAX_INLINE_NEST 1024
>  
> +static int inline_list__append_dso_a2l(struct dso *dso,
> +struct inline_node *node)
> +{
> + struct a2l_data *a2l = dso->a2l;
> + char *funcname = a2l->funcname ? strdup(a2l->funcname) : NULL;
> + char *filename = a2l->filename ? strdup(a2l->filename) : NULL;
> +
> + return inline_list__append(filename, funcname, a2l->line, node, dso);
> +}
> +
>  static int addr2line(const char *dso_name, u64 addr,
>char **file, unsigned int *line, struct dso *dso,
>bool unwind_inlines, struct inline_node *node)
> @@ -233,17 +243,15 @@ static int addr2line(const char *dso_name, u64 addr,
>   if (a2l->found && unwind_inlines) {
>   int cnt = 0;
>  
> + if (node && inline_list__append_dso_a2l(dso, node))
> + return 0;
> +
>   while (bfd_find_inliner_info(a2l->abfd, >filename,
>>funcname, >line) &&
>  cnt++ < MAX_INLINE_NEST) {
>  
> - if (node != NULL) {
> - if (inline_list__append(strdup(a2l->filename),
> - strdup(a2l->funcname),
> - a2l->line, node,
> - dso) != 0)
> - return 0;
> - }
> + if (node && inline_list__append_dso_a2l(dso, node))
> + return 0;
>   }
>   }
>  
> -- 
> 2.13.0
> 


Re: [PATCH] perf report: always honor callchain order for inlined nodes

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:54:22PM +0200, Milian Wolff wrote:
> So far, the inlined nodes where only reversed when we built perf
> against libbfd. If that was not available, the addr2line fallback
> code path was missing the inline_list__reverse call.
> 
> Now this is done at the central place inside dso__parse_addr_inlines.

What about changing inline_list__append() instead to honor callchain
order?

if (ORDER_CALLEE)
list_add_tail(...);
else
list_add(...);

Thanks,
Namhyung


> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 
> ---
>  tools/perf/util/srcline.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index 62cf42c36955..8df6b29bf984 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -61,6 +61,14 @@ static int inline_list__append(char *filename, char 
> *funcname, int line_nr,
>   return 0;
>  }
>  
> +static void inline_list__reverse(struct inline_node *node)
> +{
> + struct inline_list *ilist, *n;
> +
> + list_for_each_entry_safe_reverse(ilist, n, >val, list)
> + list_move_tail(>list, >val);
> +}
> +
>  #ifdef HAVE_LIBBFD_SUPPORT
>  
>  /*
> @@ -200,14 +208,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
>  
>  #define MAX_INLINE_NEST 1024
>  
> -static void inline_list__reverse(struct inline_node *node)
> -{
> - struct inline_list *ilist, *n;
> -
> - list_for_each_entry_safe_reverse(ilist, n, >val, list)
> - list_move_tail(>list, >val);
> -}
> -
>  static int addr2line(const char *dso_name, u64 addr,
>char **file, unsigned int *line, struct dso *dso,
>bool unwind_inlines, struct inline_node *node)
> @@ -245,11 +245,6 @@ static int addr2line(const char *dso_name, u64 addr,
>   return 0;
>   }
>   }
> -
> - if ((node != NULL) &&
> - (callchain_param.order != ORDER_CALLEE)) {
> - inline_list__reverse(node);
> - }
>   }
>  
>   if (a2l->found && a2l->filename) {
> @@ -493,12 +488,17 @@ char *get_srcline(struct dso *dso, u64 addr, struct 
> symbol *sym,
>  struct inline_node *dso__parse_addr_inlines(struct dso *dso, u64 addr)
>  {
>   const char *dso_name;
> + struct inline_node *node;
>  
>   dso_name = dso__name(dso);
>   if (dso_name == NULL)
>   return NULL;
>  
> - return addr2inlines(dso_name, addr, dso);
> + node = addr2inlines(dso_name, addr, dso);
> + if (node && callchain_param.order != ORDER_CALLEE)
> + inline_list__reverse(node);
> +
> + return node;
>  }
>  
>  void inline_node__delete(struct inline_node *node)
> -- 
> 2.13.0
> 


Re: [PATCH] perf report: always honor callchain order for inlined nodes

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:54:22PM +0200, Milian Wolff wrote:
> So far, the inlined nodes where only reversed when we built perf
> against libbfd. If that was not available, the addr2line fallback
> code path was missing the inline_list__reverse call.
> 
> Now this is done at the central place inside dso__parse_addr_inlines.

What about changing inline_list__append() instead to honor callchain
order?

if (ORDER_CALLEE)
list_add_tail(...);
else
list_add(...);

Thanks,
Namhyung


> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 
> ---
>  tools/perf/util/srcline.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index 62cf42c36955..8df6b29bf984 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -61,6 +61,14 @@ static int inline_list__append(char *filename, char 
> *funcname, int line_nr,
>   return 0;
>  }
>  
> +static void inline_list__reverse(struct inline_node *node)
> +{
> + struct inline_list *ilist, *n;
> +
> + list_for_each_entry_safe_reverse(ilist, n, >val, list)
> + list_move_tail(>list, >val);
> +}
> +
>  #ifdef HAVE_LIBBFD_SUPPORT
>  
>  /*
> @@ -200,14 +208,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
>  
>  #define MAX_INLINE_NEST 1024
>  
> -static void inline_list__reverse(struct inline_node *node)
> -{
> - struct inline_list *ilist, *n;
> -
> - list_for_each_entry_safe_reverse(ilist, n, >val, list)
> - list_move_tail(>list, >val);
> -}
> -
>  static int addr2line(const char *dso_name, u64 addr,
>char **file, unsigned int *line, struct dso *dso,
>bool unwind_inlines, struct inline_node *node)
> @@ -245,11 +245,6 @@ static int addr2line(const char *dso_name, u64 addr,
>   return 0;
>   }
>   }
> -
> - if ((node != NULL) &&
> - (callchain_param.order != ORDER_CALLEE)) {
> - inline_list__reverse(node);
> - }
>   }
>  
>   if (a2l->found && a2l->filename) {
> @@ -493,12 +488,17 @@ char *get_srcline(struct dso *dso, u64 addr, struct 
> symbol *sym,
>  struct inline_node *dso__parse_addr_inlines(struct dso *dso, u64 addr)
>  {
>   const char *dso_name;
> + struct inline_node *node;
>  
>   dso_name = dso__name(dso);
>   if (dso_name == NULL)
>   return NULL;
>  
> - return addr2inlines(dso_name, addr, dso);
> + node = addr2inlines(dso_name, addr, dso);
> + if (node && callchain_param.order != ORDER_CALLEE)
> + inline_list__reverse(node);
> +
> + return node;
>  }
>  
>  void inline_node__delete(struct inline_node *node)
> -- 
> 2.13.0
> 


[PATCH V2] i2c: xgene: Set ACPI_COMPANION_I2C

2017-05-16 Thread Tin Huynh
With ACPI, i2c-core requires ACPI companion to be set in order for it
to create slave device.
This patch sets the ACPI companion accordingly.

Signed-off-by: Tin Huynh 

---
 drivers/i2c/busses/i2c-xgene-slimpro.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Change from V1: 
 - Add Signed-off and full name to the mail header.

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index dbe7e44..6ba6c83 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -416,6 +416,7 @@ static int xgene_slimpro_i2c_probe(struct platform_device 
*pdev)
adapter->class = I2C_CLASS_HWMON;
adapter->dev.parent = >dev;
adapter->dev.of_node = pdev->dev.of_node;
+   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
i2c_set_adapdata(adapter, ctx);
rc = i2c_add_adapter(adapter);
if (rc) {
-- 
1.7.1



[PATCH V2] i2c: xgene: Set ACPI_COMPANION_I2C

2017-05-16 Thread Tin Huynh
With ACPI, i2c-core requires ACPI companion to be set in order for it
to create slave device.
This patch sets the ACPI companion accordingly.

Signed-off-by: Tin Huynh 

---
 drivers/i2c/busses/i2c-xgene-slimpro.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Change from V1: 
 - Add Signed-off and full name to the mail header.

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index dbe7e44..6ba6c83 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -416,6 +416,7 @@ static int xgene_slimpro_i2c_probe(struct platform_device 
*pdev)
adapter->class = I2C_CLASS_HWMON;
adapter->dev.parent = >dev;
adapter->dev.of_node = pdev->dev.of_node;
+   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
i2c_set_adapdata(adapter, ctx);
rc = i2c_add_adapter(adapter);
if (rc) {
-- 
1.7.1



Re: [PATCH v3 00/11] Broadcom Stingray SOC Initial Support

2017-05-16 Thread Anup Patel
On Wed, May 17, 2017 at 12:23 AM, Olof Johansson  wrote:
> Hi,
>
>
>
> On Tue, May 16, 2017 at 4:30 AM, Anup Patel  wrote:
>> This patchset adds initial support of Broadcom Stingray SOC
>> by reusing existing Broadcom iProc device drivers.
>>
>> Most of the patches in this patchset are DT patches except
>> the Stingray clock tree support which just one patch.
>>
>> This patchset is based on Linux-4.12-rc1 and it is also available
>> at stingray-v3 branch of https://github.com/Broadcom/arm64-linux.git
>>
>> Changes since v2:
>>  - Remove default bootargs from chosen DT node
>>  - Remove "linux" prefix from stdout DT attribute of chosen DT node
>>  - Remove use of GIC_CPU_MASK_xxx() for PPIs
>>
>> Changes since v1:
>>  - Rebased patches for Linux-4.12-rc1
>>  - Removed unwanted /memreserve/ from bcm958742-base.dtsi
>>  - Use ranges DT property to clear view of memory-layout
>>  - Make bcm-sr.h part of clock DT bindings patch
>>
>> Anup Patel (3):
>>   dt-bindings: bcm: Add Broadcom Stingray bindings document
>>   arm64: dts: Initial DTS files for Broadcom Stingray SOC
>>   arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray
>>
>> Oza Pawandeep (1):
>>   arm64: dts: Add I2C DT nodes for Stingray SoC
>>
>> Pramod Kumar (3):
>>   arm64: dts: Add NAND DT nodes for Stingray SOC
>>   arm64: dts: Add pinctrl DT nodes for Stingray SOC
>>   arm64: dts: Add GPIO DT nodes for Stingray SOC
>>
>> Sandeep Tripathy (3):
>>   dt-bindings: clk: Extend binding doc for Stingray SOC
>>   clk: bcm: Add clocks for Stingray SOC
>>   arm64: dts: Add clock DT nodes for Stingray SOC
>>
>> Srinath Mannam (1):
>>   arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC
>>
>>  .../devicetree/bindings/arm/bcm/brcm,stingray.txt  |  12 +
>>  .../bindings/clock/brcm,iproc-clocks.txt   |  76 
>>  arch/arm64/boot/dts/broadcom/Makefile  |   1 +
>>  arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
>>  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 131 ++
>>  .../boot/dts/broadcom/stingray/bcm958742k.dts  |  78 
>>  .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 ++
>>  .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 
>>  .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 
>>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 460 
>> +
>>  drivers/clk/bcm/Kconfig|   8 +
>>  drivers/clk/bcm/Makefile   |   1 +
>>  drivers/clk/bcm/clk-sr.c   | 300 ++
>>  include/dt-bindings/clock/bcm-sr.h | 101 +
>>  .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 +++
>>  15 files changed, 1797 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
>>  create mode 100644 
>> arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
>>  create mode 100644 drivers/clk/bcm/clk-sr.c
>>  create mode 100644 include/dt-bindings/clock/bcm-sr.h
>>  create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h
>
> Grouping as one patchset for review is fine, but when you submit this
> for merge you need to split it up:
>
> - Documentation/devicetree can go with the driver pieces or with the
> DT changes, your choice
> - DTS/DTSI changes should go through the Broadcom maintainers to arm-soc
> - clk changes should go to clk maintainers.

Only PATCH3 needs to go through clk maintainers rest all patches
are DT bindings document and DTS changes which can go through
Broadcom tree. Right ??

>
> Also, there's usually no need to split up a DT introduction and having
> separate pieces for NAND/pinctrl/GPIO/etc: They can all go in the main
> DT submission patch.

Yes, we have already squashed DTS patches from same author into
one DTS patch except NAND, PINCTRL and GPIO patches.

The NAND, PINCTRL, and GPIO patches were not squashed into
one patch for easy review but since you suggest I will squash these
three DTS patches into one DTS patch.

Regards,
Anup


Re: [PATCH v3 00/11] Broadcom Stingray SOC Initial Support

2017-05-16 Thread Anup Patel
On Wed, May 17, 2017 at 12:23 AM, Olof Johansson  wrote:
> Hi,
>
>
>
> On Tue, May 16, 2017 at 4:30 AM, Anup Patel  wrote:
>> This patchset adds initial support of Broadcom Stingray SOC
>> by reusing existing Broadcom iProc device drivers.
>>
>> Most of the patches in this patchset are DT patches except
>> the Stingray clock tree support which just one patch.
>>
>> This patchset is based on Linux-4.12-rc1 and it is also available
>> at stingray-v3 branch of https://github.com/Broadcom/arm64-linux.git
>>
>> Changes since v2:
>>  - Remove default bootargs from chosen DT node
>>  - Remove "linux" prefix from stdout DT attribute of chosen DT node
>>  - Remove use of GIC_CPU_MASK_xxx() for PPIs
>>
>> Changes since v1:
>>  - Rebased patches for Linux-4.12-rc1
>>  - Removed unwanted /memreserve/ from bcm958742-base.dtsi
>>  - Use ranges DT property to clear view of memory-layout
>>  - Make bcm-sr.h part of clock DT bindings patch
>>
>> Anup Patel (3):
>>   dt-bindings: bcm: Add Broadcom Stingray bindings document
>>   arm64: dts: Initial DTS files for Broadcom Stingray SOC
>>   arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray
>>
>> Oza Pawandeep (1):
>>   arm64: dts: Add I2C DT nodes for Stingray SoC
>>
>> Pramod Kumar (3):
>>   arm64: dts: Add NAND DT nodes for Stingray SOC
>>   arm64: dts: Add pinctrl DT nodes for Stingray SOC
>>   arm64: dts: Add GPIO DT nodes for Stingray SOC
>>
>> Sandeep Tripathy (3):
>>   dt-bindings: clk: Extend binding doc for Stingray SOC
>>   clk: bcm: Add clocks for Stingray SOC
>>   arm64: dts: Add clock DT nodes for Stingray SOC
>>
>> Srinath Mannam (1):
>>   arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC
>>
>>  .../devicetree/bindings/arm/bcm/brcm,stingray.txt  |  12 +
>>  .../bindings/clock/brcm,iproc-clocks.txt   |  76 
>>  arch/arm64/boot/dts/broadcom/Makefile  |   1 +
>>  arch/arm64/boot/dts/broadcom/stingray/Makefile |   6 +
>>  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 131 ++
>>  .../boot/dts/broadcom/stingray/bcm958742k.dts  |  78 
>>  .../boot/dts/broadcom/stingray/bcm958742t.dts  |  40 ++
>>  .../boot/dts/broadcom/stingray/stingray-clock.dtsi | 170 
>>  .../dts/broadcom/stingray/stingray-pinctrl.dtsi| 345 
>>  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 460 
>> +
>>  drivers/clk/bcm/Kconfig|   8 +
>>  drivers/clk/bcm/Makefile   |   1 +
>>  drivers/clk/bcm/clk-sr.c   | 300 ++
>>  include/dt-bindings/clock/bcm-sr.h | 101 +
>>  .../dt-bindings/pinctrl/brcm,pinctrl-stingray.h|  68 +++
>>  15 files changed, 1797 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/Makefile
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
>>  create mode 100644 
>> arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi
>>  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
>>  create mode 100644 drivers/clk/bcm/clk-sr.c
>>  create mode 100644 include/dt-bindings/clock/bcm-sr.h
>>  create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-stingray.h
>
> Grouping as one patchset for review is fine, but when you submit this
> for merge you need to split it up:
>
> - Documentation/devicetree can go with the driver pieces or with the
> DT changes, your choice
> - DTS/DTSI changes should go through the Broadcom maintainers to arm-soc
> - clk changes should go to clk maintainers.

Only PATCH3 needs to go through clk maintainers rest all patches
are DT bindings document and DTS changes which can go through
Broadcom tree. Right ??

>
> Also, there's usually no need to split up a DT introduction and having
> separate pieces for NAND/pinctrl/GPIO/etc: They can all go in the main
> DT submission patch.

Yes, we have already squashed DTS patches from same author into
one DTS patch except NAND, PINCTRL and GPIO patches.

The NAND, PINCTRL, and GPIO patches were not squashed into
one patch for easy review but since you suggest I will squash these
three DTS patches into one DTS patch.

Regards,
Anup


Re: [PATCH] perf report: fix memory leak in addr2line when called by addr2inlines

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:53:59PM +0200, Milian Wolff wrote:
> When a filename was found in addr2line it was duplicated via strdup
> but never freed. Now we pass NULL and handle this gracefully in
> addr2line.
> 
> Detected by Valgrind:
> 
> ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 
> 220
> ==16331==at 0x4C2AF1F: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==16331==by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
> ==16331==by 0x52769F: addr2line (srcline.c:256)
> ==16331==by 0x52769F: addr2inlines (srcline.c:294)
> ==16331==by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
> ==16331==by 0x574D7A: inline__fprintf (hist.c:41)
> ==16331==by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
> ==16331==by 0x57518A: __callchain__fprintf_graph (hist.c:212)
> ==16331==by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
> ==16331==by 0x57738E: hist_entry__fprintf (hist.c:628)
> ==16331==by 0x57738E: hists__fprintf (hist.c:882)
> ==16331==by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
> ==16331==by 0x44A20F: report__browse_hists (builtin-report.c:491)
> ==16331==by 0x44A20F: __cmd_report (builtin-report.c:624)
> ==16331==by 0x44A20F: cmd_report (builtin-report.c:1054)
> ==16331==by 0x4A49CE: run_builtin (perf.c:296)
> ==16331==by 0x4A4CC0: handle_internal_command (perf.c:348)
> ==16331==by 0x434371: run_argv (perf.c:392)
> ==16331==by 0x434371: main (perf.c:530)
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 
> ---
>  tools/perf/util/srcline.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index df051a52393c..62cf42c36955 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -253,10 +253,11 @@ static int addr2line(const char *dso_name, u64 addr,
>   }
>  
>   if (a2l->found && a2l->filename) {

Not related, but I think it'd be better checking "a2l->found" after
bfd_map_over_sections() and bail out if not.


> - *file = strdup(a2l->filename);
> - *line = a2l->line;
> -
> - if (*file)
> + if (file)
> + *file = strdup(a2l->filename);
> + if (line)
> + *line = a2l->line;
> + if (*a2l->filename)

Didn't you want to check a2l->filename being non-NULL instead?  And if
so, this can be :

if (!file || *file)
>   ret = 1;
>   }

Thanks,
Namhyung


>  
> @@ -278,8 +279,6 @@ void dso__free_a2l(struct dso *dso)
>  static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
>   struct dso *dso)
>  {
> - char *file = NULL;
> - unsigned int line = 0;
>   struct inline_node *node;
>  
>   node = zalloc(sizeof(*node));
> @@ -291,7 +290,7 @@ static struct inline_node *addr2inlines(const char 
> *dso_name, u64 addr,
>   INIT_LIST_HEAD(>val);
>   node->addr = addr;
>  
> - if (!addr2line(dso_name, addr, , , dso, TRUE, node))
> + if (!addr2line(dso_name, addr, NULL, NULL, dso, TRUE, node))
>   goto out_free_inline_node;
>  
>   if (list_empty(>val))
> -- 
> 2.13.0
> 


Re: [PATCH] perf report: fix memory leak in addr2line when called by addr2inlines

2017-05-16 Thread Namhyung Kim
On Tue, May 16, 2017 at 11:53:59PM +0200, Milian Wolff wrote:
> When a filename was found in addr2line it was duplicated via strdup
> but never freed. Now we pass NULL and handle this gracefully in
> addr2line.
> 
> Detected by Valgrind:
> 
> ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 
> 220
> ==16331==at 0x4C2AF1F: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==16331==by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
> ==16331==by 0x52769F: addr2line (srcline.c:256)
> ==16331==by 0x52769F: addr2inlines (srcline.c:294)
> ==16331==by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
> ==16331==by 0x574D7A: inline__fprintf (hist.c:41)
> ==16331==by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
> ==16331==by 0x57518A: __callchain__fprintf_graph (hist.c:212)
> ==16331==by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
> ==16331==by 0x57738E: hist_entry__fprintf (hist.c:628)
> ==16331==by 0x57738E: hists__fprintf (hist.c:882)
> ==16331==by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
> ==16331==by 0x44A20F: report__browse_hists (builtin-report.c:491)
> ==16331==by 0x44A20F: __cmd_report (builtin-report.c:624)
> ==16331==by 0x44A20F: cmd_report (builtin-report.c:1054)
> ==16331==by 0x4A49CE: run_builtin (perf.c:296)
> ==16331==by 0x4A4CC0: handle_internal_command (perf.c:348)
> ==16331==by 0x434371: run_argv (perf.c:392)
> ==16331==by 0x434371: main (perf.c:530)
> 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Yao Jin 
> Signed-off-by: Milian Wolff 
> ---
>  tools/perf/util/srcline.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index df051a52393c..62cf42c36955 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -253,10 +253,11 @@ static int addr2line(const char *dso_name, u64 addr,
>   }
>  
>   if (a2l->found && a2l->filename) {

Not related, but I think it'd be better checking "a2l->found" after
bfd_map_over_sections() and bail out if not.


> - *file = strdup(a2l->filename);
> - *line = a2l->line;
> -
> - if (*file)
> + if (file)
> + *file = strdup(a2l->filename);
> + if (line)
> + *line = a2l->line;
> + if (*a2l->filename)

Didn't you want to check a2l->filename being non-NULL instead?  And if
so, this can be :

if (!file || *file)
>   ret = 1;
>   }

Thanks,
Namhyung


>  
> @@ -278,8 +279,6 @@ void dso__free_a2l(struct dso *dso)
>  static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
>   struct dso *dso)
>  {
> - char *file = NULL;
> - unsigned int line = 0;
>   struct inline_node *node;
>  
>   node = zalloc(sizeof(*node));
> @@ -291,7 +290,7 @@ static struct inline_node *addr2inlines(const char 
> *dso_name, u64 addr,
>   INIT_LIST_HEAD(>val);
>   node->addr = addr;
>  
> - if (!addr2line(dso_name, addr, , , dso, TRUE, node))
> + if (!addr2line(dso_name, addr, NULL, NULL, dso, TRUE, node))
>   goto out_free_inline_node;
>  
>   if (list_empty(>val))
> -- 
> 2.13.0
> 


linux-next: Tree for May 17

2017-05-16 Thread Stephen Rothwell
Hi all,

Changes since 20170516:

New trees: nand-fixes (yesterday)
spi-nor-fixes

The file-locks tree gained a build failure so I used the version from
next-20170516.

The netfilter tree gained a build failure for which I applied a fix patch.

The sound tree gained a build failure so I used the version from
next-20170516.

The scsi-mkp tree gained a build failure so I used the version from
next-20170516.

Non-merge commits (relative to Linus' tree): 1206
 1254 files changed, 34634 insertions(+), 21339 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.

Below is a summary of the state of the merge.

I am currently merging 260 trees (counting Linus' and 40 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 (b23afd384801 Merge tag 'pstore-v4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (3c7f62212018 sparc64: fix fault handling in NGbzero.S and 
GENbzero.S)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (2432a3fb5cff mlx5e: add CONFIG_INET dependency)
Merging ipsec/master (2c1497bbc8fd xfrm: Fix NETDEV_DOWN with IPSec offload)
Merging netfilter/master (c953d6354820 ebtables: arpreply: Add the standard 
target sanity check)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (29cee56c0be4 Merge tag 'mac80211-for-davem-2017-05-08' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (fa16b69f1299 ALSA: hda - No loopback on ALC299 
codec)
Merging pci-current/for-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging driver-core.current/driver-core-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging tty.current/tty-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging usb.current/usb-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (b004ee894f53 USB: serial: ftdi_sio: add 
Olimex ARM-USB-TINY(H) PIDs)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (3f34d7fc76fa phy: Group vendor specific phy drivers)
Merging staging.current/staging-linus (b72d7451209a staging: fsl-dpaa2/eth: add 
ETHERNET dependency)
Merging char-misc.current/char-misc-linus (0d83539092dd uio: fix incorrect 
memory leak cleanup)
Merging input-current/for-linus (3af9256150b3 Input: cros_ec_keyb - remove 
extraneous 'const')
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Lin

linux-next: Tree for May 17

2017-05-16 Thread Stephen Rothwell
Hi all,

Changes since 20170516:

New trees: nand-fixes (yesterday)
spi-nor-fixes

The file-locks tree gained a build failure so I used the version from
next-20170516.

The netfilter tree gained a build failure for which I applied a fix patch.

The sound tree gained a build failure so I used the version from
next-20170516.

The scsi-mkp tree gained a build failure so I used the version from
next-20170516.

Non-merge commits (relative to Linus' tree): 1206
 1254 files changed, 34634 insertions(+), 21339 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.

Below is a summary of the state of the merge.

I am currently merging 260 trees (counting Linus' and 40 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 (b23afd384801 Merge tag 'pstore-v4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (3c7f62212018 sparc64: fix fault handling in NGbzero.S and 
GENbzero.S)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (2432a3fb5cff mlx5e: add CONFIG_INET dependency)
Merging ipsec/master (2c1497bbc8fd xfrm: Fix NETDEV_DOWN with IPSec offload)
Merging netfilter/master (c953d6354820 ebtables: arpreply: Add the standard 
target sanity check)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (29cee56c0be4 Merge tag 'mac80211-for-davem-2017-05-08' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (fa16b69f1299 ALSA: hda - No loopback on ALC299 
codec)
Merging pci-current/for-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging driver-core.current/driver-core-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging tty.current/tty-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging usb.current/usb-linus (2ea659a9ef48 Linux 4.12-rc1)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (b004ee894f53 USB: serial: ftdi_sio: add 
Olimex ARM-USB-TINY(H) PIDs)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (3f34d7fc76fa phy: Group vendor specific phy drivers)
Merging staging.current/staging-linus (b72d7451209a staging: fsl-dpaa2/eth: add 
ETHERNET dependency)
Merging char-misc.current/char-misc-linus (0d83539092dd uio: fix incorrect 
memory leak cleanup)
Merging input-current/for-linus (3af9256150b3 Input: cros_ec_keyb - remove 
extraneous 'const')
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9ef48 Lin

[PATCH net-next V5 1/9] ptr_ring: add ptr_ring_unconsume

2017-05-16 Thread Jason Wang
From: "Michael S. Tsirkin" 

Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally can't do this and have to drop entries, but this implies ring
is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 include/linux/ptr_ring.h | 55 
 1 file changed, 55 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 6b2e0dd..796b90f 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -403,6 +403,61 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
 }
 
+/*
+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   spin_lock(>producer_lock);
+
+   if (!r->size)
+   goto done;
+
+   /*
+* Clean out buffered entries (for simplicity). This way following code
+* can test entries for NULL and if not assume they are valid.
+*/
+   head = r->consumer_head - 1;
+   while (likely(head >= r->consumer_tail))
+   r->queue[head--] = NULL;
+   r->consumer_tail = r->consumer_head;
+
+   /*
+* Go over entries in batch, start moving head back and copy entries.
+* Stop when we run into previously unconsumed entries.
+*/
+   while (n) {
+   head = r->consumer_head - 1;
+   if (head < 0)
+   head = r->size - 1;
+   if (r->queue[head]) {
+   /* This batch entry will have to be destroyed. */
+   goto done;
+   }
+   r->queue[head] = batch[--n];
+   r->consumer_tail = r->consumer_head = head;
+   }
+
+done:
+   /* Destroy all entries left in the batch. */
+   while (n)
+   destroy(batch[--n]);
+   spin_unlock(>producer_lock);
+   spin_unlock_irqrestore(>consumer_lock, flags);
+}
+
 static inline void **__ptr_ring_swap_queue(struct ptr_ring *r, void **queue,
   int size, gfp_t gfp,
   void (*destroy)(void *))
-- 
2.7.4



[PATCH net-next V5 0/9] vhost_net rx batch dequeuing

2017-05-16 Thread Jason Wang
This series tries to implement rx batching for vhost-net. This is done
by batching the dequeuing from skb_array which was exported by
underlayer socket and pass the sbk back through msg_control to finish
userspace copying. This is also the requirement for more batching
implemention on rx path.

Tests shows at most 7.56% improvment bon rx pps on top of batch
zeroing and no obvious changes for TCP_STREAM/TCP_RR result.

Please review.

Thanks

Changes from V4:
- drop batch zeroing patch
- renew the performance numbers
- move skb pointer array out of vhost_net structure

Changes from V3:
- add batch zeroing patch to fix the build warnings

Changes from V2:
- rebase to net-next HEAD
- use unconsume helpers to put skb back on releasing
- introduce and use vhost_net internal buffer helpers
- renew performance numbers on top of batch zeroing

Changes from V1:
- switch to use for() in __ptr_ring_consume_batched()
- rename peek_head_len_batched() to fetch_skbs()
- use skb_array_consume_batched() instead of
  skb_array_consume_batched_bh() since no consumer run in bh
- drop the lockless peeking patch since skb_array could be resized, so
  it's not safe to call lockless one

Jason Wang (8):
  skb_array: introduce skb_array_unconsume
  ptr_ring: introduce batch dequeuing
  skb_array: introduce batch dequeuing
  tun: export skb_array
  tap: export skb_array
  tun: support receiving skb through msg_control
  tap: support receiving skb from msg_control
  vhost_net: try batch dequing from skb array

Michael S. Tsirkin (1):
  ptr_ring: add ptr_ring_unconsume

 drivers/net/tap.c |  25 +++--
 drivers/net/tun.c |  31 ---
 drivers/vhost/net.c   | 128 +++---
 include/linux/if_tap.h|   5 ++
 include/linux/if_tun.h|   5 ++
 include/linux/ptr_ring.h  | 120 +++
 include/linux/skb_array.h |  31 +++
 7 files changed, 327 insertions(+), 18 deletions(-)

-- 
2.7.4



[PATCH net-next V5 1/9] ptr_ring: add ptr_ring_unconsume

2017-05-16 Thread Jason Wang
From: "Michael S. Tsirkin" 

Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.

Add an API for that - assuming there's space. If there's no space
naturally can't do this and have to drop entries, but this implies ring
is full so we'd likely drop some anyway.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 include/linux/ptr_ring.h | 55 
 1 file changed, 55 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 6b2e0dd..796b90f 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -403,6 +403,61 @@ static inline int ptr_ring_init(struct ptr_ring *r, int 
size, gfp_t gfp)
return 0;
 }
 
+/*
+ * Return entries into ring. Destroy entries that don't fit.
+ *
+ * Note: this is expected to be a rare slow path operation.
+ *
+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
+static inline void ptr_ring_unconsume(struct ptr_ring *r, void **batch, int n,
+ void (*destroy)(void *))
+{
+   unsigned long flags;
+   int head;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   spin_lock(>producer_lock);
+
+   if (!r->size)
+   goto done;
+
+   /*
+* Clean out buffered entries (for simplicity). This way following code
+* can test entries for NULL and if not assume they are valid.
+*/
+   head = r->consumer_head - 1;
+   while (likely(head >= r->consumer_tail))
+   r->queue[head--] = NULL;
+   r->consumer_tail = r->consumer_head;
+
+   /*
+* Go over entries in batch, start moving head back and copy entries.
+* Stop when we run into previously unconsumed entries.
+*/
+   while (n) {
+   head = r->consumer_head - 1;
+   if (head < 0)
+   head = r->size - 1;
+   if (r->queue[head]) {
+   /* This batch entry will have to be destroyed. */
+   goto done;
+   }
+   r->queue[head] = batch[--n];
+   r->consumer_tail = r->consumer_head = head;
+   }
+
+done:
+   /* Destroy all entries left in the batch. */
+   while (n)
+   destroy(batch[--n]);
+   spin_unlock(>producer_lock);
+   spin_unlock_irqrestore(>consumer_lock, flags);
+}
+
 static inline void **__ptr_ring_swap_queue(struct ptr_ring *r, void **queue,
   int size, gfp_t gfp,
   void (*destroy)(void *))
-- 
2.7.4



[PATCH net-next V5 0/9] vhost_net rx batch dequeuing

2017-05-16 Thread Jason Wang
This series tries to implement rx batching for vhost-net. This is done
by batching the dequeuing from skb_array which was exported by
underlayer socket and pass the sbk back through msg_control to finish
userspace copying. This is also the requirement for more batching
implemention on rx path.

Tests shows at most 7.56% improvment bon rx pps on top of batch
zeroing and no obvious changes for TCP_STREAM/TCP_RR result.

Please review.

Thanks

Changes from V4:
- drop batch zeroing patch
- renew the performance numbers
- move skb pointer array out of vhost_net structure

Changes from V3:
- add batch zeroing patch to fix the build warnings

Changes from V2:
- rebase to net-next HEAD
- use unconsume helpers to put skb back on releasing
- introduce and use vhost_net internal buffer helpers
- renew performance numbers on top of batch zeroing

Changes from V1:
- switch to use for() in __ptr_ring_consume_batched()
- rename peek_head_len_batched() to fetch_skbs()
- use skb_array_consume_batched() instead of
  skb_array_consume_batched_bh() since no consumer run in bh
- drop the lockless peeking patch since skb_array could be resized, so
  it's not safe to call lockless one

Jason Wang (8):
  skb_array: introduce skb_array_unconsume
  ptr_ring: introduce batch dequeuing
  skb_array: introduce batch dequeuing
  tun: export skb_array
  tap: export skb_array
  tun: support receiving skb through msg_control
  tap: support receiving skb from msg_control
  vhost_net: try batch dequing from skb array

Michael S. Tsirkin (1):
  ptr_ring: add ptr_ring_unconsume

 drivers/net/tap.c |  25 +++--
 drivers/net/tun.c |  31 ---
 drivers/vhost/net.c   | 128 +++---
 include/linux/if_tap.h|   5 ++
 include/linux/if_tun.h|   5 ++
 include/linux/ptr_ring.h  | 120 +++
 include/linux/skb_array.h |  31 +++
 7 files changed, 327 insertions(+), 18 deletions(-)

-- 
2.7.4



[PATCH net-next V5 4/9] skb_array: introduce batch dequeuing

2017-05-16 Thread Jason Wang
Signed-off-by: Jason Wang 
---
 include/linux/skb_array.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index 79850b6..35226cd 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -97,21 +97,46 @@ static inline struct sk_buff *skb_array_consume(struct 
skb_array *a)
return ptr_ring_consume(>ring);
 }
 
+static inline int skb_array_consume_batched(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched(>ring, (void **)array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_irq(struct skb_array *a)
 {
return ptr_ring_consume_irq(>ring);
 }
 
+static inline int skb_array_consume_batched_irq(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_irq(>ring, (void **)array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_any(struct skb_array *a)
 {
return ptr_ring_consume_any(>ring);
 }
 
+static inline int skb_array_consume_batched_any(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_any(>ring, (void **)array, n);
+}
+
+
 static inline struct sk_buff *skb_array_consume_bh(struct skb_array *a)
 {
return ptr_ring_consume_bh(>ring);
 }
 
+static inline int skb_array_consume_batched_bh(struct skb_array *a,
+  struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_bh(>ring, (void **)array, n);
+}
+
 static inline int __skb_array_len_with_tag(struct sk_buff *skb)
 {
if (likely(skb)) {
-- 
2.7.4



[PATCH net-next V5 4/9] skb_array: introduce batch dequeuing

2017-05-16 Thread Jason Wang
Signed-off-by: Jason Wang 
---
 include/linux/skb_array.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index 79850b6..35226cd 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -97,21 +97,46 @@ static inline struct sk_buff *skb_array_consume(struct 
skb_array *a)
return ptr_ring_consume(>ring);
 }
 
+static inline int skb_array_consume_batched(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched(>ring, (void **)array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_irq(struct skb_array *a)
 {
return ptr_ring_consume_irq(>ring);
 }
 
+static inline int skb_array_consume_batched_irq(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_irq(>ring, (void **)array, n);
+}
+
 static inline struct sk_buff *skb_array_consume_any(struct skb_array *a)
 {
return ptr_ring_consume_any(>ring);
 }
 
+static inline int skb_array_consume_batched_any(struct skb_array *a,
+   struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_any(>ring, (void **)array, n);
+}
+
+
 static inline struct sk_buff *skb_array_consume_bh(struct skb_array *a)
 {
return ptr_ring_consume_bh(>ring);
 }
 
+static inline int skb_array_consume_batched_bh(struct skb_array *a,
+  struct sk_buff **array, int n)
+{
+   return ptr_ring_consume_batched_bh(>ring, (void **)array, n);
+}
+
 static inline int __skb_array_len_with_tag(struct sk_buff *skb)
 {
if (likely(skb)) {
-- 
2.7.4



[PATCH net-next V5 9/9] vhost_net: try batch dequing from skb array

2017-05-16 Thread Jason Wang
We used to dequeue one skb during recvmsg() from skb_array, this could
be inefficient because of the bad cache utilization and spinlock
touching for each packet. This patch tries to batch them by calling
batch dequeuing helpers explicitly on the exported skb array and pass
the skb back through msg_control for underlayer socket to finish the
userspace copying. Batch dequeuing is also the requirement for more
batching improvement on receive path.

Tests were done by pktgen on tap with XDP1 in guest. Host is Intel(R)
Xeon(R) CPU E5-2650 0 @ 2.00GHz.

rx batch | pps

0   2.25Mpps
1   2.33Mpps (+3.56%)
4   2.33Mpps (+3.56%)
16  2.35Mpps (+4.44%)
64  2.42Mpps (+7.56%) <- Default rx batching
128 2.40Mpps (+6.67%)
256 2.38Mpps (+5.78%)

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 128 +---
 1 file changed, 122 insertions(+), 6 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f61f852..e3d7ea1 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -85,6 +87,13 @@ struct vhost_net_ubuf_ref {
struct vhost_virtqueue *vq;
 };
 
+#define VHOST_RX_BATCH 64
+struct vhost_net_buf {
+   struct sk_buff **queue;
+   int tail;
+   int head;
+};
+
 struct vhost_net_virtqueue {
struct vhost_virtqueue vq;
size_t vhost_hlen;
@@ -99,6 +108,8 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
 * Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+   struct skb_array *rx_array;
+   struct vhost_net_buf rxq;
 };
 
 struct vhost_net {
@@ -117,6 +128,71 @@ struct vhost_net {
 
 static unsigned vhost_net_zcopy_mask __read_mostly;
 
+static void *vhost_net_buf_get_ptr(struct vhost_net_buf *rxq)
+{
+   if (rxq->tail != rxq->head)
+   return rxq->queue[rxq->head];
+   else
+   return NULL;
+}
+
+static int vhost_net_buf_get_size(struct vhost_net_buf *rxq)
+{
+   return rxq->tail - rxq->head;
+}
+
+static int vhost_net_buf_is_empty(struct vhost_net_buf *rxq)
+{
+   return rxq->tail == rxq->head;
+}
+
+static void *vhost_net_buf_consume(struct vhost_net_buf *rxq)
+{
+   void *ret = vhost_net_buf_get_ptr(rxq);
+   ++rxq->head;
+   return ret;
+}
+
+static int vhost_net_buf_produce(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   rxq->head = 0;
+   rxq->tail = skb_array_consume_batched(nvq->rx_array, rxq->queue,
+ VHOST_RX_BATCH);
+   return rxq->tail;
+}
+
+static void vhost_net_buf_unproduce(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   if (nvq->rx_array && !vhost_net_buf_is_empty(rxq)) {
+   skb_array_unconsume(nvq->rx_array, rxq->queue + rxq->head,
+   vhost_net_buf_get_size(rxq));
+   rxq->head = rxq->tail = 0;
+   }
+}
+
+static int vhost_net_buf_peek(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   if (!vhost_net_buf_is_empty(rxq))
+   goto out;
+
+   if (!vhost_net_buf_produce(nvq))
+   return 0;
+
+out:
+   return __skb_array_len_with_tag(vhost_net_buf_get_ptr(rxq));
+}
+
+static void vhost_net_buf_init(struct vhost_net_buf *rxq)
+{
+   rxq->head = rxq->tail = 0;
+}
+
 static void vhost_net_enable_zcopy(int vq)
 {
vhost_net_zcopy_mask |= 0x1 << vq;
@@ -201,6 +277,7 @@ static void vhost_net_vq_reset(struct vhost_net *n)
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   vhost_net_buf_init(>vqs[i].rxq);
}
 
 }
@@ -503,15 +580,14 @@ static void handle_tx(struct vhost_net *net)
mutex_unlock(>mutex);
 }
 
-static int peek_head_len(struct sock *sk)
+static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
-   struct socket *sock = sk->sk_socket;
struct sk_buff *head;
int len = 0;
unsigned long flags;
 
-   if (sock->ops->peek_len)
-   return sock->ops->peek_len(sock);
+   if (rvq->rx_array)
+   return vhost_net_buf_peek(rvq);
 
spin_lock_irqsave(>sk_receive_queue.lock, flags);
head = skb_peek(>sk_receive_queue);
@@ -537,10 +613,11 @@ static int sk_has_rx_data(struct sock *sk)
 
 static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
 {
+   struct vhost_net_virtqueue *rvq = >vqs[VHOST_NET_VQ_RX];
struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = >vq;
unsigned long uninitialized_var(endtime);
-   int len = peek_head_len(sk);
+   int len = peek_head_len(rvq, sk);
 
if (!len && 

[PATCH net-next V5 9/9] vhost_net: try batch dequing from skb array

2017-05-16 Thread Jason Wang
We used to dequeue one skb during recvmsg() from skb_array, this could
be inefficient because of the bad cache utilization and spinlock
touching for each packet. This patch tries to batch them by calling
batch dequeuing helpers explicitly on the exported skb array and pass
the skb back through msg_control for underlayer socket to finish the
userspace copying. Batch dequeuing is also the requirement for more
batching improvement on receive path.

Tests were done by pktgen on tap with XDP1 in guest. Host is Intel(R)
Xeon(R) CPU E5-2650 0 @ 2.00GHz.

rx batch | pps

0   2.25Mpps
1   2.33Mpps (+3.56%)
4   2.33Mpps (+3.56%)
16  2.35Mpps (+4.44%)
64  2.42Mpps (+7.56%) <- Default rx batching
128 2.40Mpps (+6.67%)
256 2.38Mpps (+5.78%)

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 128 +---
 1 file changed, 122 insertions(+), 6 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f61f852..e3d7ea1 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -85,6 +87,13 @@ struct vhost_net_ubuf_ref {
struct vhost_virtqueue *vq;
 };
 
+#define VHOST_RX_BATCH 64
+struct vhost_net_buf {
+   struct sk_buff **queue;
+   int tail;
+   int head;
+};
+
 struct vhost_net_virtqueue {
struct vhost_virtqueue vq;
size_t vhost_hlen;
@@ -99,6 +108,8 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
 * Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+   struct skb_array *rx_array;
+   struct vhost_net_buf rxq;
 };
 
 struct vhost_net {
@@ -117,6 +128,71 @@ struct vhost_net {
 
 static unsigned vhost_net_zcopy_mask __read_mostly;
 
+static void *vhost_net_buf_get_ptr(struct vhost_net_buf *rxq)
+{
+   if (rxq->tail != rxq->head)
+   return rxq->queue[rxq->head];
+   else
+   return NULL;
+}
+
+static int vhost_net_buf_get_size(struct vhost_net_buf *rxq)
+{
+   return rxq->tail - rxq->head;
+}
+
+static int vhost_net_buf_is_empty(struct vhost_net_buf *rxq)
+{
+   return rxq->tail == rxq->head;
+}
+
+static void *vhost_net_buf_consume(struct vhost_net_buf *rxq)
+{
+   void *ret = vhost_net_buf_get_ptr(rxq);
+   ++rxq->head;
+   return ret;
+}
+
+static int vhost_net_buf_produce(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   rxq->head = 0;
+   rxq->tail = skb_array_consume_batched(nvq->rx_array, rxq->queue,
+ VHOST_RX_BATCH);
+   return rxq->tail;
+}
+
+static void vhost_net_buf_unproduce(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   if (nvq->rx_array && !vhost_net_buf_is_empty(rxq)) {
+   skb_array_unconsume(nvq->rx_array, rxq->queue + rxq->head,
+   vhost_net_buf_get_size(rxq));
+   rxq->head = rxq->tail = 0;
+   }
+}
+
+static int vhost_net_buf_peek(struct vhost_net_virtqueue *nvq)
+{
+   struct vhost_net_buf *rxq = >rxq;
+
+   if (!vhost_net_buf_is_empty(rxq))
+   goto out;
+
+   if (!vhost_net_buf_produce(nvq))
+   return 0;
+
+out:
+   return __skb_array_len_with_tag(vhost_net_buf_get_ptr(rxq));
+}
+
+static void vhost_net_buf_init(struct vhost_net_buf *rxq)
+{
+   rxq->head = rxq->tail = 0;
+}
+
 static void vhost_net_enable_zcopy(int vq)
 {
vhost_net_zcopy_mask |= 0x1 << vq;
@@ -201,6 +277,7 @@ static void vhost_net_vq_reset(struct vhost_net *n)
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+   vhost_net_buf_init(>vqs[i].rxq);
}
 
 }
@@ -503,15 +580,14 @@ static void handle_tx(struct vhost_net *net)
mutex_unlock(>mutex);
 }
 
-static int peek_head_len(struct sock *sk)
+static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
 {
-   struct socket *sock = sk->sk_socket;
struct sk_buff *head;
int len = 0;
unsigned long flags;
 
-   if (sock->ops->peek_len)
-   return sock->ops->peek_len(sock);
+   if (rvq->rx_array)
+   return vhost_net_buf_peek(rvq);
 
spin_lock_irqsave(>sk_receive_queue.lock, flags);
head = skb_peek(>sk_receive_queue);
@@ -537,10 +613,11 @@ static int sk_has_rx_data(struct sock *sk)
 
 static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
 {
+   struct vhost_net_virtqueue *rvq = >vqs[VHOST_NET_VQ_RX];
struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = >vq;
unsigned long uninitialized_var(endtime);
-   int len = peek_head_len(sk);
+   int len = peek_head_len(rvq, sk);
 
if (!len && vq->busyloop_timeout) {
 

[PATCH net-next V5 7/9] tun: support receiving skb through msg_control

2017-05-16 Thread Jason Wang
This patch makes tun_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3cbfc5c..f8041f9c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1510,9 +1510,8 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 
 static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
-   struct sk_buff *skb;
ssize_t ret;
int err;
 
@@ -1521,10 +1520,12 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
struct tun_file *tfile,
if (!iov_iter_count(to))
return 0;
 
-   /* Read frames from ring */
-   skb = tun_ring_recv(tfile, noblock, );
-   if (!skb)
-   return err;
+   if (!skb) {
+   /* Read frames from ring */
+   skb = tun_ring_recv(tfile, noblock, );
+   if (!skb)
+   return err;
+   }
 
ret = tun_put_user(tun, tfile, skb, to);
if (unlikely(ret < 0))
@@ -1544,7 +1545,7 @@ static ssize_t tun_chr_read_iter(struct kiocb *iocb, 
struct iov_iter *to)
 
if (!tun)
return -EBADFD;
-   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK);
+   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1646,7 +1647,8 @@ static int tun_recvmsg(struct socket *sock, struct msghdr 
*m, size_t total_len,
 SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
-   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > (ssize_t)total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4



[PATCH net-next V5 7/9] tun: support receiving skb through msg_control

2017-05-16 Thread Jason Wang
This patch makes tun_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3cbfc5c..f8041f9c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1510,9 +1510,8 @@ static struct sk_buff *tun_ring_recv(struct tun_file 
*tfile, int noblock,
 
 static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
   struct iov_iter *to,
-  int noblock)
+  int noblock, struct sk_buff *skb)
 {
-   struct sk_buff *skb;
ssize_t ret;
int err;
 
@@ -1521,10 +1520,12 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
struct tun_file *tfile,
if (!iov_iter_count(to))
return 0;
 
-   /* Read frames from ring */
-   skb = tun_ring_recv(tfile, noblock, );
-   if (!skb)
-   return err;
+   if (!skb) {
+   /* Read frames from ring */
+   skb = tun_ring_recv(tfile, noblock, );
+   if (!skb)
+   return err;
+   }
 
ret = tun_put_user(tun, tfile, skb, to);
if (unlikely(ret < 0))
@@ -1544,7 +1545,7 @@ static ssize_t tun_chr_read_iter(struct kiocb *iocb, 
struct iov_iter *to)
 
if (!tun)
return -EBADFD;
-   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK);
+   ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1646,7 +1647,8 @@ static int tun_recvmsg(struct socket *sock, struct msghdr 
*m, size_t total_len,
 SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
-   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT);
+   ret = tun_do_read(tun, tfile, >msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > (ssize_t)total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
-- 
2.7.4



[PATCH net-next V5 5/9] tun: export skb_array

2017-05-16 Thread Jason Wang
This patch exports skb_array through tun_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c  | 13 +
 include/linux/if_tun.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bbd707b..3cbfc5c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2626,6 +2626,19 @@ struct socket *tun_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tun_get_socket);
 
+struct skb_array *tun_get_skb_array(struct file *file)
+{
+   struct tun_file *tfile;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   tfile = file->private_data;
+   if (!tfile)
+   return ERR_PTR(-EBADFD);
+   return >tx_array;
+}
+EXPORT_SYMBOL_GPL(tun_get_skb_array);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index ed6da2e..bf9bdf4 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -19,6 +19,7 @@
 
 #if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
 struct socket *tun_get_socket(struct file *);
+struct skb_array *tun_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -28,5 +29,9 @@ static inline struct socket *tun_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tun_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TUN */
 #endif /* __IF_TUN_H */
-- 
2.7.4



[PATCH net-next V5 5/9] tun: export skb_array

2017-05-16 Thread Jason Wang
This patch exports skb_array through tun_get_skb_array(). Caller can
then manipulate skb array directly.

Signed-off-by: Jason Wang 
---
 drivers/net/tun.c  | 13 +
 include/linux/if_tun.h |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bbd707b..3cbfc5c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2626,6 +2626,19 @@ struct socket *tun_get_socket(struct file *file)
 }
 EXPORT_SYMBOL_GPL(tun_get_socket);
 
+struct skb_array *tun_get_skb_array(struct file *file)
+{
+   struct tun_file *tfile;
+
+   if (file->f_op != _fops)
+   return ERR_PTR(-EINVAL);
+   tfile = file->private_data;
+   if (!tfile)
+   return ERR_PTR(-EBADFD);
+   return >tx_array;
+}
+EXPORT_SYMBOL_GPL(tun_get_skb_array);
+
 module_init(tun_init);
 module_exit(tun_cleanup);
 MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index ed6da2e..bf9bdf4 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -19,6 +19,7 @@
 
 #if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
 struct socket *tun_get_socket(struct file *);
+struct skb_array *tun_get_skb_array(struct file *file);
 #else
 #include 
 #include 
@@ -28,5 +29,9 @@ static inline struct socket *tun_get_socket(struct file *f)
 {
return ERR_PTR(-EINVAL);
 }
+static inline struct skb_array *tun_get_skb_array(struct file *f)
+{
+   return ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_TUN */
 #endif /* __IF_TUN_H */
-- 
2.7.4



  1   2   3   4   5   6   7   8   9   10   >