Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Philipp Zabel
Hi Neil,

Am Freitag, den 20.05.2016, 14:21 +0200 schrieb Neil Armstrong:
> Use the brand new devm_reset_controller_register() API to get rid of
> the platform driver remove callback.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/reset/reset-oxnas.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> Hi Philip,
> 
> This patch is based on your reset/next tree after the new
> devm_reset_controller_register() was merged.

Applied, thank you.

> I hope it could be merged for 4.7.

I'll submit the branch for 4.8 after 4.7-rc1 is released.

regards
Philipp



Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Neil Armstrong
On 05/20/2016 03:02 PM, Philipp Zabel wrote:
> Hi Neil,
> 
> Am Freitag, den 20.05.2016, 14:21 +0200 schrieb Neil Armstrong:
>> Use the brand new devm_reset_controller_register() API to get rid of
>> the platform driver remove callback.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/reset/reset-oxnas.c | 12 +---
>>  1 file changed, 1 insertion(+), 11 deletions(-)
>>
>> Hi Philip,
>>
>> This patch is based on your reset/next tree after the new
>> devm_reset_controller_register() was merged.
> 
> Applied, thank you.
> 
>> I hope it could be merged for 4.7.
> 
> I'll submit the branch for 4.8 after 4.7-rc1 is released.
> 
> regards
> Philipp
> 

Thanks Philipp,

Sorry I missed the 4.6 release...

Neil


Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Philipp Zabel
Hi Neil,

Am Freitag, den 20.05.2016, 14:21 +0200 schrieb Neil Armstrong:
> Use the brand new devm_reset_controller_register() API to get rid of
> the platform driver remove callback.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/reset/reset-oxnas.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> Hi Philip,
> 
> This patch is based on your reset/next tree after the new
> devm_reset_controller_register() was merged.

Applied, thank you.

> I hope it could be merged for 4.7.

I'll submit the branch for 4.8 after 4.7-rc1 is released.

regards
Philipp



Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Neil Armstrong
On 05/20/2016 03:02 PM, Philipp Zabel wrote:
> Hi Neil,
> 
> Am Freitag, den 20.05.2016, 14:21 +0200 schrieb Neil Armstrong:
>> Use the brand new devm_reset_controller_register() API to get rid of
>> the platform driver remove callback.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/reset/reset-oxnas.c | 12 +---
>>  1 file changed, 1 insertion(+), 11 deletions(-)
>>
>> Hi Philip,
>>
>> This patch is based on your reset/next tree after the new
>> devm_reset_controller_register() was merged.
> 
> Applied, thank you.
> 
>> I hope it could be merged for 4.7.
> 
> I'll submit the branch for 4.8 after 4.7-rc1 is released.
> 
> regards
> Philipp
> 

Thanks Philipp,

Sorry I missed the 4.6 release...

Neil


Re: [PATCH] ks390/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
On Fri, May 20, 2016 at 03:03:25PM +0200, Heiko Carstens wrote:
> On Fri, May 20, 2016 at 05:52:16PM +0530, Muhammad Falak R Wani wrote:
> > Use memdup_user to duplicate a memory region from user-space to
> > kernel-space, instead of open coding using kmalloc & copy_from_user.
> > 
> > Signed-off-by: Muhammad Falak R Wani 
> > +   p = memdup_user(u_kbs->kb_string, len);
> > +   if (IS_ERR(p))
> > +   return PTR_ERR(p);
> > /*
> >  * Make sure the string is terminated by 0. User could have
> >  * modified it between us running strnlen_user() and copying it.
> 
> Hi Muhammad, thanks for this patch. However could you change this to use
> memdup_user_nul() instead, so we can get rid of even more code?
> 
Should I send V2 with the suggested changes ?


Re: [PATCH] ks390/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
On Fri, May 20, 2016 at 03:03:25PM +0200, Heiko Carstens wrote:
> On Fri, May 20, 2016 at 05:52:16PM +0530, Muhammad Falak R Wani wrote:
> > Use memdup_user to duplicate a memory region from user-space to
> > kernel-space, instead of open coding using kmalloc & copy_from_user.
> > 
> > Signed-off-by: Muhammad Falak R Wani 
> > +   p = memdup_user(u_kbs->kb_string, len);
> > +   if (IS_ERR(p))
> > +   return PTR_ERR(p);
> > /*
> >  * Make sure the string is terminated by 0. User could have
> >  * modified it between us running strnlen_user() and copying it.
> 
> Hi Muhammad, thanks for this patch. However could you change this to use
> memdup_user_nul() instead, so we can get rid of even more code?
> 
Should I send V2 with the suggested changes ?


[PATCH v8 1/4] of/serial: move earlycon early_param handling to serial

2016-05-20 Thread Aleksey Makarov
From: Leif Lindholm 

We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one.  It's a cleanup that also will be useful
to defer setting up DT console until ACPI/DT decision is made.

Rename the exported function to avoid clashing with the function from
arch/microblaze/kernel/prom.c

Signed-off-by: Leif Lindholm 
Signed-off-by: Aleksey Makarov 
Acked-by: Rob Herring 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Peter Hurley 
Tested-by: Kefeng Wang 
---
 drivers/of/fdt.c  | 11 +--
 drivers/tty/serial/earlycon.c |  2 +-
 include/linux/of_fdt.h|  2 ++
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e7a8caa..56da2a9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -906,7 +906,7 @@ static inline void early_init_dt_check_for_initrd(unsigned 
long node)
 
 #ifdef CONFIG_SERIAL_EARLYCON
 
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_stdout(void)
 {
int offset;
const char *p, *q, *options = NULL;
@@ -950,15 +950,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
}
return -ENODEV;
 }
-
-static int __init setup_of_earlycon(char *buf)
-{
-   if (buf)
-   return 0;
-
-   return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
 #endif
 
 /**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..7aae655 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -209,7 +209,7 @@ static int __init param_setup_earlycon(char *buf)
 * don't generate a warning from parse_early_params() in that case
 */
if (!buf || !buf[0])
-   return 0;
+   return early_init_dt_scan_chosen_stdout();
 
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 26c3302..2f69d4c 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -66,6 +66,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 int depth, void *data);
 extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 int depth, void *data);
+extern int early_init_dt_scan_chosen_stdout(void);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -94,6 +95,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t 
*);
 extern u64 of_flat_dt_translate_address(unsigned long node);
 extern void of_fdt_limit_memory(int limit);
 #else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_stdout(void) { return -ENODEV; }
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline void early_init_fdt_reserve_self(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
2.8.2



[PATCH v8 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE

2016-05-20 Thread Aleksey Makarov
SBBR mentions SPCR as a mandatory ACPI table.  So enable it for ARM64

Earlycon should be set up as early as possible.  ACPI boot tables are
mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
is called from setup_arch() and that's where we parse SPCR.
So it has to be opted-in per-arch.

When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
deferred until the DT/ACPI decision is done.  Initialize DT earlycon
if ACPI is disabled.

Signed-off-by: Aleksey Makarov 
Tested-by: Kefeng Wang 
---
 arch/arm64/Kconfig   |  1 +
 arch/arm64/kernel/acpi.c | 11 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5d30abf..80c0816 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -4,6 +4,7 @@ config ARM64
select ACPI_GENERIC_GSI if ACPI
select ACPI_PCI_HOST_GENERIC if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+   select ACPI_SPCR_TABLE if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3e4f1a4..252a6d9 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -206,7 +207,7 @@ void __init acpi_boot_table_init(void)
if (param_acpi_off ||
(!param_acpi_on && !param_acpi_force &&
 of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
-   return;
+   goto done;
 
/*
 * ACPI is disabled at this point. Enable it in order to parse
@@ -226,6 +227,14 @@ void __init acpi_boot_table_init(void)
if (!param_acpi_force)
disable_acpi();
}
+
+done:
+   if (acpi_disabled) {
+   if (earlycon_init_is_deferred)
+   early_init_dt_scan_chosen_stdout();
+   } else {
+   parse_spcr(earlycon_init_is_deferred);
+   }
 }
 
 #ifdef CONFIG_ACPI_APEI
-- 
2.8.2



[PATCH v8 0/4] ACPI: parse the SPCR table

2016-05-20 Thread Aleksey Makarov
'ARM Server Base Boot Requirements' [1] mentions SPCR (Serial Port Console
Redirection Table) [2] as a mandatory ACPI table that specifies the
configuration of serial console.

Move "earlycon" early_param handling to earlycon.c to parse this option once

Parse SPCR table, setup earlycon and register specified console.

Enable parsing this table on ARM64.  Earlycon should be set up as early as
possible.  ACPI boot tables are mapped in
arch/arm64/kernel/acpi.c:acpi_boot_table_init() called from setup_arch() and
that's where we parse spcr.  So it has to be opted-in per-arch. When
ACPI_SPCR_TABLE is defined initialization of DT earlycon is deferred until the
DT/ACPI decision is done.

Implement console_match() for pl011.

Based on the work by Leif Lindholm [3]
Thanks to Peter Hurley for explaining how this should work.

Should be applied to next-20160520
Tested on QEMU and ThunderX.
SPCR support is included in QEMU's ARM64 mach-virt since 2.4 release.

v8:
- rebase to next-20160520
- remove the patch "ACPICA: Headers: Add new constants for the DBG2 ACPI table"
  as it have got to linux-next
- add Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>, Reviewed-by:
  Peter Hurley <pe...@hurleysoftware.com> (but see below)
- fix the patch "serial: pl011: add console matching function".  The patch by
  Christopher Covington [4] specifies that SBSA uart does 32-bit access to
  registers and this breaks the match function.  In this series the function
  was changed to match when SPCR specifies both mmio32 and mmio access.
  I removed Acked-by: Greg from this patch because of these changes.

v7:
https://lkml.kernel.org/g/1459431629-27934-1-git-send-email-aleksey.maka...@linaro.org
- add Acked-by: Rob Herring for "of/serial: move earlycon early_param handling
  to serial"
- call DT earlycon initialization from the arch ACPI code, not from parse_spcr()
  (Rafael J. Wysocki)
- fix a few minor issues (Rafael J. Wysocki)

v6:
https://lkml.kernel.org/g/1458823925-19560-1-git-send-email-aleksey.maka...@linaro.org
- add documentation for parse_spcr() functioin (Yury Norov)
- don't initialize err variable (Yury Norov)
- add __initdata for the earlycon_init_is_deferred flag variable
- rename the function exported in "of/serial: move earlycon early_param handling
  to serial" to avoid clash with the function from arch/microblaze/kernel/prom.c
- defer initialization of DT earlycon until DT/ACPI decision is made
  (Rob Herring, Peter Hurley)
- use snprintf instead of sprintf (Andy Shevchenko)
- drop patch that adds EARLYCON_DECLARE for pl011 as EARLYCON_DECLARE is
  equivalent to OF_EARLYCON_DECLARE for 4.6+ (Peter Hurley).  This means that
  SPCR earlycon will not work on the kernels before 4.6

v5:
https://lkml.kernel.org/g/1458643595-14719-1-git-send-email-aleksey.maka...@linaro.org
- drop patch "serial: pl011: use ACPI SPCR to setup 32-bit access" because
  it is ugly. Also because Christopher Covington came with a better solution [4]
- remove error message when the table is not provided by ACPI (Andy Shevchenko)
- rewrite spcr.c following the suggestions by Peter Hurley
- add console_match() for pl011 in a separate patch
- add EARLYCON_DECLARE for pl011 in a separate patch
- add patch "of/serial: move earlycon early_param handling to serial" from
  the GDB2 series

v4:
https://lkml.kernel.org/g/1456747355-15692-1-git-send-email-aleksey.maka...@linaro.org
- drop patch "ACPI: change __init to __ref for early_acpi_os_unmap_memory()"
  ACPI developers work on a new API and asked not to do that.
  Instead, use acpi_get_table_with_size()/early_acpi_os_unmap_memory() once
  and cache the result. (Lv Zheng)
- fix some style issues (Yury Norov)

v3:
https://lkml.kernel.org/g/149532-8305-1-git-send-email-aleksey.maka...@linaro.org

Greg Kroah-Hartman did not like v2 so I have rewritten this patchset:

- drop acpi_match() member of struct console
- drop implementations of this member for pl011 and 8250
- drop the patch that renames some vars in printk.c as it is not needed anymore
- drop patch that introduces system wide acpi_table_parse2().
  Instead introduce a custom acpi_table_parse_spcr() in spcr.c

Instead of introducing a new match_acpi() member of struct console,
this patchset introduces a new function acpi_console_check().
This function is called when a new uart is registered at serial_core.c
the same way OF code checks for console.  If the registered uart is the
console specified by SPCR table, this function calls add_preferred_console()

The restrictions of this approach are:

- only serial consoles can be set up
- only consoles specified by the memory/io address can be set up
  (SPCR can specify devices by PCI id/PCI address)

v2:
https://lkml.kernel.org/g/1455299022-11641-1-git-send-email-aleksey.maka...@linaro.org
- don't use SPCR if user specified console in command line
- fix initialization order of newcon->ind

[PATCH v8 1/4] of/serial: move earlycon early_param handling to serial

2016-05-20 Thread Aleksey Makarov
From: Leif Lindholm 

We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one.  It's a cleanup that also will be useful
to defer setting up DT console until ACPI/DT decision is made.

Rename the exported function to avoid clashing with the function from
arch/microblaze/kernel/prom.c

Signed-off-by: Leif Lindholm 
Signed-off-by: Aleksey Makarov 
Acked-by: Rob Herring 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Peter Hurley 
Tested-by: Kefeng Wang 
---
 drivers/of/fdt.c  | 11 +--
 drivers/tty/serial/earlycon.c |  2 +-
 include/linux/of_fdt.h|  2 ++
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e7a8caa..56da2a9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -906,7 +906,7 @@ static inline void early_init_dt_check_for_initrd(unsigned 
long node)
 
 #ifdef CONFIG_SERIAL_EARLYCON
 
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_stdout(void)
 {
int offset;
const char *p, *q, *options = NULL;
@@ -950,15 +950,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
}
return -ENODEV;
 }
-
-static int __init setup_of_earlycon(char *buf)
-{
-   if (buf)
-   return 0;
-
-   return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
 #endif
 
 /**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..7aae655 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -209,7 +209,7 @@ static int __init param_setup_earlycon(char *buf)
 * don't generate a warning from parse_early_params() in that case
 */
if (!buf || !buf[0])
-   return 0;
+   return early_init_dt_scan_chosen_stdout();
 
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 26c3302..2f69d4c 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -66,6 +66,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 int depth, void *data);
 extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 int depth, void *data);
+extern int early_init_dt_scan_chosen_stdout(void);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -94,6 +95,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t 
*);
 extern u64 of_flat_dt_translate_address(unsigned long node);
 extern void of_fdt_limit_memory(int limit);
 #else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_stdout(void) { return -ENODEV; }
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline void early_init_fdt_reserve_self(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
2.8.2



[PATCH v8 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE

2016-05-20 Thread Aleksey Makarov
SBBR mentions SPCR as a mandatory ACPI table.  So enable it for ARM64

Earlycon should be set up as early as possible.  ACPI boot tables are
mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
is called from setup_arch() and that's where we parse SPCR.
So it has to be opted-in per-arch.

When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
deferred until the DT/ACPI decision is done.  Initialize DT earlycon
if ACPI is disabled.

Signed-off-by: Aleksey Makarov 
Tested-by: Kefeng Wang 
---
 arch/arm64/Kconfig   |  1 +
 arch/arm64/kernel/acpi.c | 11 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5d30abf..80c0816 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -4,6 +4,7 @@ config ARM64
select ACPI_GENERIC_GSI if ACPI
select ACPI_PCI_HOST_GENERIC if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+   select ACPI_SPCR_TABLE if ACPI
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3e4f1a4..252a6d9 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -206,7 +207,7 @@ void __init acpi_boot_table_init(void)
if (param_acpi_off ||
(!param_acpi_on && !param_acpi_force &&
 of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
-   return;
+   goto done;
 
/*
 * ACPI is disabled at this point. Enable it in order to parse
@@ -226,6 +227,14 @@ void __init acpi_boot_table_init(void)
if (!param_acpi_force)
disable_acpi();
}
+
+done:
+   if (acpi_disabled) {
+   if (earlycon_init_is_deferred)
+   early_init_dt_scan_chosen_stdout();
+   } else {
+   parse_spcr(earlycon_init_is_deferred);
+   }
 }
 
 #ifdef CONFIG_ACPI_APEI
-- 
2.8.2



[PATCH v8 0/4] ACPI: parse the SPCR table

2016-05-20 Thread Aleksey Makarov
'ARM Server Base Boot Requirements' [1] mentions SPCR (Serial Port Console
Redirection Table) [2] as a mandatory ACPI table that specifies the
configuration of serial console.

Move "earlycon" early_param handling to earlycon.c to parse this option once

Parse SPCR table, setup earlycon and register specified console.

Enable parsing this table on ARM64.  Earlycon should be set up as early as
possible.  ACPI boot tables are mapped in
arch/arm64/kernel/acpi.c:acpi_boot_table_init() called from setup_arch() and
that's where we parse spcr.  So it has to be opted-in per-arch. When
ACPI_SPCR_TABLE is defined initialization of DT earlycon is deferred until the
DT/ACPI decision is done.

Implement console_match() for pl011.

Based on the work by Leif Lindholm [3]
Thanks to Peter Hurley for explaining how this should work.

Should be applied to next-20160520
Tested on QEMU and ThunderX.
SPCR support is included in QEMU's ARM64 mach-virt since 2.4 release.

v8:
- rebase to next-20160520
- remove the patch "ACPICA: Headers: Add new constants for the DBG2 ACPI table"
  as it have got to linux-next
- add Acked-by: Greg Kroah-Hartman , Reviewed-by:
  Peter Hurley  (but see below)
- fix the patch "serial: pl011: add console matching function".  The patch by
  Christopher Covington [4] specifies that SBSA uart does 32-bit access to
  registers and this breaks the match function.  In this series the function
  was changed to match when SPCR specifies both mmio32 and mmio access.
  I removed Acked-by: Greg from this patch because of these changes.

v7:
https://lkml.kernel.org/g/1459431629-27934-1-git-send-email-aleksey.maka...@linaro.org
- add Acked-by: Rob Herring for "of/serial: move earlycon early_param handling
  to serial"
- call DT earlycon initialization from the arch ACPI code, not from parse_spcr()
  (Rafael J. Wysocki)
- fix a few minor issues (Rafael J. Wysocki)

v6:
https://lkml.kernel.org/g/1458823925-19560-1-git-send-email-aleksey.maka...@linaro.org
- add documentation for parse_spcr() functioin (Yury Norov)
- don't initialize err variable (Yury Norov)
- add __initdata for the earlycon_init_is_deferred flag variable
- rename the function exported in "of/serial: move earlycon early_param handling
  to serial" to avoid clash with the function from arch/microblaze/kernel/prom.c
- defer initialization of DT earlycon until DT/ACPI decision is made
  (Rob Herring, Peter Hurley)
- use snprintf instead of sprintf (Andy Shevchenko)
- drop patch that adds EARLYCON_DECLARE for pl011 as EARLYCON_DECLARE is
  equivalent to OF_EARLYCON_DECLARE for 4.6+ (Peter Hurley).  This means that
  SPCR earlycon will not work on the kernels before 4.6

v5:
https://lkml.kernel.org/g/1458643595-14719-1-git-send-email-aleksey.maka...@linaro.org
- drop patch "serial: pl011: use ACPI SPCR to setup 32-bit access" because
  it is ugly. Also because Christopher Covington came with a better solution [4]
- remove error message when the table is not provided by ACPI (Andy Shevchenko)
- rewrite spcr.c following the suggestions by Peter Hurley
- add console_match() for pl011 in a separate patch
- add EARLYCON_DECLARE for pl011 in a separate patch
- add patch "of/serial: move earlycon early_param handling to serial" from
  the GDB2 series

v4:
https://lkml.kernel.org/g/1456747355-15692-1-git-send-email-aleksey.maka...@linaro.org
- drop patch "ACPI: change __init to __ref for early_acpi_os_unmap_memory()"
  ACPI developers work on a new API and asked not to do that.
  Instead, use acpi_get_table_with_size()/early_acpi_os_unmap_memory() once
  and cache the result. (Lv Zheng)
- fix some style issues (Yury Norov)

v3:
https://lkml.kernel.org/g/149532-8305-1-git-send-email-aleksey.maka...@linaro.org

Greg Kroah-Hartman did not like v2 so I have rewritten this patchset:

- drop acpi_match() member of struct console
- drop implementations of this member for pl011 and 8250
- drop the patch that renames some vars in printk.c as it is not needed anymore
- drop patch that introduces system wide acpi_table_parse2().
  Instead introduce a custom acpi_table_parse_spcr() in spcr.c

Instead of introducing a new match_acpi() member of struct console,
this patchset introduces a new function acpi_console_check().
This function is called when a new uart is registered at serial_core.c
the same way OF code checks for console.  If the registered uart is the
console specified by SPCR table, this function calls add_preferred_console()

The restrictions of this approach are:

- only serial consoles can be set up
- only consoles specified by the memory/io address can be set up
  (SPCR can specify devices by PCI id/PCI address)

v2:
https://lkml.kernel.org/g/1455299022-11641-1-git-send-email-aleksey.maka...@linaro.org
- don't use SPCR if user specified console in command line
- fix initialization order of newcon->index = 0
- rename some variables at printk.c (Joe Perches, Peter Hurley

Re: [patch] mm, migrate: increment fail count on ENOMEM

2016-05-20 Thread Michal Hocko
On Thu 19-05-16 15:11:23, David Rientjes wrote:
> If page migration fails due to -ENOMEM, nr_failed should still be
> incremented for proper statistics.
> 
> This was encountered recently when all page migration vmstats showed 0,
> and inferred that migrate_pages() was never called, although in reality
> the first page migration failed because compaction_alloc() failed to find
> a migration target.
> 
> This patch increments nr_failed so the vmstat is properly accounted on
> ENOMEM.
> 
> Signed-off-by: David Rientjes 

Acked-by: Michal Hocko 

One question though

> ---
>  mm/migrate.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1171,6 +1171,7 @@ int migrate_pages(struct list_head *from, new_page_t 
> get_new_page,
>  
>   switch(rc) {
>   case -ENOMEM:
> + nr_failed++;
>   goto out;
>   case -EAGAIN:
>   retry++;

Why don't we need also to count also retries?
---
diff --git a/mm/migrate.c b/mm/migrate.c
index 53ab6398e7a2..ef9c5211ae3c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1190,9 +1190,9 @@ int migrate_pages(struct list_head *from, new_page_t 
get_new_page,
}
}
}
+out:
nr_failed += retry;
rc = nr_failed;
-out:
if (nr_succeeded)
count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
if (nr_failed)
-- 
Michal Hocko
SUSE Labs


Re: [patch] mm, migrate: increment fail count on ENOMEM

2016-05-20 Thread Michal Hocko
On Thu 19-05-16 15:11:23, David Rientjes wrote:
> If page migration fails due to -ENOMEM, nr_failed should still be
> incremented for proper statistics.
> 
> This was encountered recently when all page migration vmstats showed 0,
> and inferred that migrate_pages() was never called, although in reality
> the first page migration failed because compaction_alloc() failed to find
> a migration target.
> 
> This patch increments nr_failed so the vmstat is properly accounted on
> ENOMEM.
> 
> Signed-off-by: David Rientjes 

Acked-by: Michal Hocko 

One question though

> ---
>  mm/migrate.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1171,6 +1171,7 @@ int migrate_pages(struct list_head *from, new_page_t 
> get_new_page,
>  
>   switch(rc) {
>   case -ENOMEM:
> + nr_failed++;
>   goto out;
>   case -EAGAIN:
>   retry++;

Why don't we need also to count also retries?
---
diff --git a/mm/migrate.c b/mm/migrate.c
index 53ab6398e7a2..ef9c5211ae3c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1190,9 +1190,9 @@ int migrate_pages(struct list_head *from, new_page_t 
get_new_page,
}
}
}
+out:
nr_failed += retry;
rc = nr_failed;
-out:
if (nr_succeeded)
count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
if (nr_failed)
-- 
Michal Hocko
SUSE Labs


[PATCH v8 4/4] serial: pl011: add console matching function

2016-05-20 Thread Aleksey Makarov
This patch adds function pl011_console_match() that implements
method match of struct console.  It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.

Signed-off-by: Aleksey Makarov 
Reviewed-by: Peter Hurley 
---
 drivers/tty/serial/amba-pl011.c | 56 +
 1 file changed, 56 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index a2aa655..388edc8 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2288,12 +2288,68 @@ static int __init pl011_console_setup(struct console 
*co, char *options)
return uart_set_options(>port, co, baud, parity, bits, flow);
 }
 
+/**
+ * pl011_console_match - non-standard console matching
+ * @co:  registering console
+ * @name:name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=pl011,mmio|mmio32,[,]
+ * console=pl011,0x[,]
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the amba_console at pl011 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ * If no  are specified, then assume the h/w is already setup.
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int __init pl011_console_match(struct console *co, char *name, int idx,
+ char *options)
+{
+   char match[] = "pl011"; /* pl011-specific earlycon name */
+   unsigned char iotype;
+   unsigned long addr;
+   int i;
+
+   if (strncmp(name, match, 5) != 0)
+   return -ENODEV;
+
+   if (uart_parse_earlycon(options, , , ))
+   return -ENODEV;
+
+   /* try to match the port specified on the command line */
+   for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
+   struct uart_port *port;
+
+   if (!amba_ports[i])
+   continue;
+
+   port = _ports[i]->port;
+
+   if (iotype != UPIO_MEM && iotype != UPIO_MEM32)
+   continue;
+
+   if (port->mapbase != addr)
+   continue;
+
+   co->index = i;
+   port->cons = co;
+   return pl011_console_setup(co, options);
+   }
+
+   return -ENODEV;
+}
+
 static struct uart_driver amba_reg;
 static struct console amba_console = {
.name   = "ttyAMA",
.write  = pl011_console_write,
.device = uart_console_device,
.setup  = pl011_console_setup,
+   .match  = pl011_console_match,
.flags  = CON_PRINTBUFFER,
.index  = -1,
.data   = _reg,
-- 
2.8.2



[PATCH v8 2/4] ACPI: parse SPCR and enable matching console

2016-05-20 Thread Aleksey Makarov
'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.

Defer initialization of DT earlycon until ACPI/DT decision is made.

Parse the ACPI SPCR table, setup earlycon if required,
enable specified console.

Thanks to Peter Hurley for explaining how this should work.

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] 
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov 
Reviewed-by: Peter Hurley 
Tested-by: Kefeng Wang 
---
 drivers/acpi/Kconfig  |   3 ++
 drivers/acpi/Makefile |   1 +
 drivers/acpi/spcr.c   | 111 ++
 drivers/tty/serial/earlycon.c |  19 +++-
 include/linux/acpi.h  |   6 +++
 include/linux/serial_core.h   |   6 +++
 6 files changed, 144 insertions(+), 2 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c204344..c8c02f1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
 
 endif
 
+config ACPI_SPCR_TABLE
+   bool
+
 config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 8b08e20..d0dc940 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
 obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)+= cppc_acpi.o
+obj-$(CONFIG_ACPI_SPCR_TABLE)  += spcr.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
 
 # processor has its own "processor." module_param namespace
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
new file mode 100644
index 000..f4cfc5c
--- /dev/null
+++ b/drivers/acpi/spcr.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, Red Hat, Inc.
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: SPCR: " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * parse_spcr() - parse ACPI SPCR table and add preferred console
+ *
+ * @earlycon: set up earlycon for the console specified by the table
+ *
+ * For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE may be
+ * defined to parse ACPI SPCR table.  As a result of the parsing preferred
+ * console is registered and if @earlycon is true, earlycon is set up.
+ *
+ * When CONFIG_ACPI_SPCR_TABLE is defined, this function should be called
+ * from arch inintialization code as soon as the DT/ACPI decision is made.
+ *
+ */
+int __init parse_spcr(bool earlycon)
+{
+   static char opts[64];
+   struct acpi_table_spcr *table;
+   acpi_size table_size;
+   acpi_status status;
+   char *uart;
+   char *iotype;
+   int baud_rate;
+   int err;
+
+   if (acpi_disabled)
+   return -ENODEV;
+
+   status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **),
+ _size);
+
+   if (ACPI_FAILURE(status))
+   return -ENOENT;
+
+   if (table->header.revision < 2) {
+   err = -ENOENT;
+   pr_err("wrong table version\n");
+   goto done;
+   }
+
+   iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
+   "mmio" : "io";
+
+   switch (table->interface_type) {
+   case ACPI_DBG2_ARM_SBSA_32BIT:
+   iotype = "mmio32";
+   /* fall through */
+   case ACPI_DBG2_ARM_PL011:
+   case ACPI_DBG2_ARM_SBSA_GENERIC:
+   case ACPI_DBG2_BCM2835:
+   uart = "pl011";
+   break;
+   case ACPI_DBG2_16550_COMPATIBLE:
+   case ACPI_DBG2_16550_SUBSET:
+   uart = "uart";
+   break;
+   default:
+   err = -ENOENT;
+   goto done;
+   }
+
+   switch (table->baud_rate) {
+   case 3:
+   baud_rate = 9600;
+   break;
+   case 4:
+   baud_rate = 19200;
+   break;
+   case 6:
+   baud_rate = 57600;
+   break;
+   case 7:
+   baud_rate = 115200;
+   break;
+   default:
+   err = -ENOENT;
+   goto done;
+   }
+
+   snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
+table->serial_port.address, baud_rate);
+
+   pr_info("console: %s", 

Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Shawn Lin

在 2016/5/20 20:57, Caesar Wang 写道:


于 2016年05月20日 20:35, Shawn Lin 写道:

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


The rk3036 shouldn't work if you read the driver/spi/spi-rockchip.c.
since the "rockchip,rockchip-spi" is *not* exist in linux kernel.



okay, so that means we take "rockchip,rockchip-spi" from local branch
by mistake?


..
 static const struct of_device_id rockchip_spi_dt_match[] = {
{ .compatible = "rockchip,rk3066-spi", },
{ .compatible = "rockchip,rk3188-spi", },
{ .compatible = "rockchip,rk3288-spi", },
{ .compatible = "rockchip,rk3399-spi", },
{ },
}
..


-Caesar




Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi
b/arch/arm/boot/dts/rk3036.dtsi
index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
 };

 spi: spi@20074000 {
-compatible = "rockchip,rockchip-spi";
+compatible = "rockchip,rk3036-spi";
 reg = <0x20074000 0x1000>;
 interrupts = ;
 clocks =< PCLK_SPI>, < SCLK_SPI>;











--
Best Regards
Shawn Lin



[PATCH v8 4/4] serial: pl011: add console matching function

2016-05-20 Thread Aleksey Makarov
This patch adds function pl011_console_match() that implements
method match of struct console.  It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.

Signed-off-by: Aleksey Makarov 
Reviewed-by: Peter Hurley 
---
 drivers/tty/serial/amba-pl011.c | 56 +
 1 file changed, 56 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index a2aa655..388edc8 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2288,12 +2288,68 @@ static int __init pl011_console_setup(struct console 
*co, char *options)
return uart_set_options(>port, co, baud, parity, bits, flow);
 }
 
+/**
+ * pl011_console_match - non-standard console matching
+ * @co:  registering console
+ * @name:name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=pl011,mmio|mmio32,[,]
+ * console=pl011,0x[,]
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the amba_console at pl011 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ * If no  are specified, then assume the h/w is already setup.
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int __init pl011_console_match(struct console *co, char *name, int idx,
+ char *options)
+{
+   char match[] = "pl011"; /* pl011-specific earlycon name */
+   unsigned char iotype;
+   unsigned long addr;
+   int i;
+
+   if (strncmp(name, match, 5) != 0)
+   return -ENODEV;
+
+   if (uart_parse_earlycon(options, , , ))
+   return -ENODEV;
+
+   /* try to match the port specified on the command line */
+   for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
+   struct uart_port *port;
+
+   if (!amba_ports[i])
+   continue;
+
+   port = _ports[i]->port;
+
+   if (iotype != UPIO_MEM && iotype != UPIO_MEM32)
+   continue;
+
+   if (port->mapbase != addr)
+   continue;
+
+   co->index = i;
+   port->cons = co;
+   return pl011_console_setup(co, options);
+   }
+
+   return -ENODEV;
+}
+
 static struct uart_driver amba_reg;
 static struct console amba_console = {
.name   = "ttyAMA",
.write  = pl011_console_write,
.device = uart_console_device,
.setup  = pl011_console_setup,
+   .match  = pl011_console_match,
.flags  = CON_PRINTBUFFER,
.index  = -1,
.data   = _reg,
-- 
2.8.2



[PATCH v8 2/4] ACPI: parse SPCR and enable matching console

2016-05-20 Thread Aleksey Makarov
'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.

Defer initialization of DT earlycon until ACPI/DT decision is made.

Parse the ACPI SPCR table, setup earlycon if required,
enable specified console.

Thanks to Peter Hurley for explaining how this should work.

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] 
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov 
Reviewed-by: Peter Hurley 
Tested-by: Kefeng Wang 
---
 drivers/acpi/Kconfig  |   3 ++
 drivers/acpi/Makefile |   1 +
 drivers/acpi/spcr.c   | 111 ++
 drivers/tty/serial/earlycon.c |  19 +++-
 include/linux/acpi.h  |   6 +++
 include/linux/serial_core.h   |   6 +++
 6 files changed, 144 insertions(+), 2 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c204344..c8c02f1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
 
 endif
 
+config ACPI_SPCR_TABLE
+   bool
+
 config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 8b08e20..d0dc940 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
 obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)+= cppc_acpi.o
+obj-$(CONFIG_ACPI_SPCR_TABLE)  += spcr.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
 
 # processor has its own "processor." module_param namespace
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
new file mode 100644
index 000..f4cfc5c
--- /dev/null
+++ b/drivers/acpi/spcr.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, Red Hat, Inc.
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: SPCR: " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * parse_spcr() - parse ACPI SPCR table and add preferred console
+ *
+ * @earlycon: set up earlycon for the console specified by the table
+ *
+ * For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE may be
+ * defined to parse ACPI SPCR table.  As a result of the parsing preferred
+ * console is registered and if @earlycon is true, earlycon is set up.
+ *
+ * When CONFIG_ACPI_SPCR_TABLE is defined, this function should be called
+ * from arch inintialization code as soon as the DT/ACPI decision is made.
+ *
+ */
+int __init parse_spcr(bool earlycon)
+{
+   static char opts[64];
+   struct acpi_table_spcr *table;
+   acpi_size table_size;
+   acpi_status status;
+   char *uart;
+   char *iotype;
+   int baud_rate;
+   int err;
+
+   if (acpi_disabled)
+   return -ENODEV;
+
+   status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **),
+ _size);
+
+   if (ACPI_FAILURE(status))
+   return -ENOENT;
+
+   if (table->header.revision < 2) {
+   err = -ENOENT;
+   pr_err("wrong table version\n");
+   goto done;
+   }
+
+   iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
+   "mmio" : "io";
+
+   switch (table->interface_type) {
+   case ACPI_DBG2_ARM_SBSA_32BIT:
+   iotype = "mmio32";
+   /* fall through */
+   case ACPI_DBG2_ARM_PL011:
+   case ACPI_DBG2_ARM_SBSA_GENERIC:
+   case ACPI_DBG2_BCM2835:
+   uart = "pl011";
+   break;
+   case ACPI_DBG2_16550_COMPATIBLE:
+   case ACPI_DBG2_16550_SUBSET:
+   uart = "uart";
+   break;
+   default:
+   err = -ENOENT;
+   goto done;
+   }
+
+   switch (table->baud_rate) {
+   case 3:
+   baud_rate = 9600;
+   break;
+   case 4:
+   baud_rate = 19200;
+   break;
+   case 6:
+   baud_rate = 57600;
+   break;
+   case 7:
+   baud_rate = 115200;
+   break;
+   default:
+   err = -ENOENT;
+   goto done;
+   }
+
+   snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
+table->serial_port.address, baud_rate);
+
+   pr_info("console: %s", opts);
+
+   if (earlycon)
+   setup_earlycon(opts);
+
+   err 

Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Shawn Lin

在 2016/5/20 20:57, Caesar Wang 写道:


于 2016年05月20日 20:35, Shawn Lin 写道:

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


The rk3036 shouldn't work if you read the driver/spi/spi-rockchip.c.
since the "rockchip,rockchip-spi" is *not* exist in linux kernel.



okay, so that means we take "rockchip,rockchip-spi" from local branch
by mistake?


..
 static const struct of_device_id rockchip_spi_dt_match[] = {
{ .compatible = "rockchip,rk3066-spi", },
{ .compatible = "rockchip,rk3188-spi", },
{ .compatible = "rockchip,rk3288-spi", },
{ .compatible = "rockchip,rk3399-spi", },
{ },
}
..


-Caesar




Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi
b/arch/arm/boot/dts/rk3036.dtsi
index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
 };

 spi: spi@20074000 {
-compatible = "rockchip,rockchip-spi";
+compatible = "rockchip,rk3036-spi";
 reg = <0x20074000 0x1000>;
 interrupts = ;
 clocks =< PCLK_SPI>, < SCLK_SPI>;











--
Best Regards
Shawn Lin



[PATCH] overlayfs: Do d_type check only if work dir creation was successful

2016-05-20 Thread Vivek Goyal
d_type check requires successful creation of workdir as iterates
through work dir and expects work dir to be present in it. If that's
not the case, this check will always return d_type not supported even
if underlying filesystem might be supporting it.

So don't do this check if work dir creation failed in previous step.

Signed-off-by: Vivek Goyal 
---
 fs/overlayfs/super.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 791235e..48234425 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -1064,16 +1064,19 @@ static int ovl_fill_super(struct super_block *sb, void 
*data, int silent)
/*
 * Upper should support d_type, else whiteouts are visible.
 * Given workdir and upper are on same fs, we can do
-* iterate_dir() on workdir.
+* iterate_dir() on workdir. This check requires successful
+* creation of workdir in previous step.
 */
-   err = ovl_check_d_type_supported();
-   if (err < 0)
-   goto out_put_workdir;
+   if (ufs->workdir) {
+   err = ovl_check_d_type_supported();
+   if (err < 0)
+   goto out_put_workdir;
 
-   if (!err) {
-   pr_err("overlayfs: upper fs needs to support 
d_type.\n");
-   err = -EINVAL;
-   goto out_put_workdir;
+   if (!err) {
+   pr_err("overlayfs: upper fs needs to support 
d_type.\n");
+   err = -EINVAL;
+   goto out_put_workdir;
+   }
}
}
 
-- 
2.7.4



Re: [RFC PATCH] Increase in idle power with schedutil

2016-05-20 Thread Shilpasri G Bhat
Hi,

On 05/19/2016 05:10 PM, Peter Zijlstra wrote:
> On Wed, May 18, 2016 at 11:11:51PM +0200, Rafael J. Wysocki wrote:
>> On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat
>>  wrote:
>>> This patch adds driver callback for fast_switch and below observations
>>> on schedutil governor are done with this patch.
>>>
>>> In POWER8 there is a regression observed with schedutil compared to
>>> ondemand. With schedutil the frequency is not ramping down and is
>>> mostly stuck at max frequency during idle . This is because of the
>>> watchdog timer, an RT task which is fired every 4 seconds which
>>> results in requesting max frequency.
>>
>> Well, yes, that would be problematic.
>>
> 
> Right; we need to come up with something for RT tasks; but what happens
> if you disable the watchdog? This should be entirely doable and might
> give a better comparison.
> 

Below are the comparisons by disabling watchdog.
Both schedutil and ondemand have a similar ramp-down trend. And in both the
cases I can see that frequency of the cpu is not reduced in deterministic
fashion. In a observation window of 30 seconds after running a workload I can
see that the frequency is not ramped down on some cpus in the system and are
idling at max frequency.

Below are the sample trace showcasing the frequency request when the cpu enters
idle with schedutil.
<...>-3528  7650.011010: cpu_frequency: state=4322000 cpu_id=120
<...>-3528  7650.027540: sched_switch: prev_comm=ppc64_cpu prev_state=x ==>
next_comm=swapper/120
-07650.035017: cpu_frequency: state=4322000 cpu_id=120
-07729.683536: cpu_frequency: state=4322000 cpu_id=120
-07729.683552: sched_switch: prev_comm=swapper/120 prev_state=R ==>
next_comm=kworker/120:1
kworker/120  7729.683565: sched_switch: prev_comm=kworker/120:1 prev_state=S ==>
 next_comm=swapper/120

However ondemand governor(with watchdog enabled) benefits from the noise created
by watchdog timer and is able to brig down the frequency.

Thanks and Regards,
Shilpa



[PATCH] overlayfs: Do d_type check only if work dir creation was successful

2016-05-20 Thread Vivek Goyal
d_type check requires successful creation of workdir as iterates
through work dir and expects work dir to be present in it. If that's
not the case, this check will always return d_type not supported even
if underlying filesystem might be supporting it.

So don't do this check if work dir creation failed in previous step.

Signed-off-by: Vivek Goyal 
---
 fs/overlayfs/super.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 791235e..48234425 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -1064,16 +1064,19 @@ static int ovl_fill_super(struct super_block *sb, void 
*data, int silent)
/*
 * Upper should support d_type, else whiteouts are visible.
 * Given workdir and upper are on same fs, we can do
-* iterate_dir() on workdir.
+* iterate_dir() on workdir. This check requires successful
+* creation of workdir in previous step.
 */
-   err = ovl_check_d_type_supported();
-   if (err < 0)
-   goto out_put_workdir;
+   if (ufs->workdir) {
+   err = ovl_check_d_type_supported();
+   if (err < 0)
+   goto out_put_workdir;
 
-   if (!err) {
-   pr_err("overlayfs: upper fs needs to support 
d_type.\n");
-   err = -EINVAL;
-   goto out_put_workdir;
+   if (!err) {
+   pr_err("overlayfs: upper fs needs to support 
d_type.\n");
+   err = -EINVAL;
+   goto out_put_workdir;
+   }
}
}
 
-- 
2.7.4



Re: [RFC PATCH] Increase in idle power with schedutil

2016-05-20 Thread Shilpasri G Bhat
Hi,

On 05/19/2016 05:10 PM, Peter Zijlstra wrote:
> On Wed, May 18, 2016 at 11:11:51PM +0200, Rafael J. Wysocki wrote:
>> On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat
>>  wrote:
>>> This patch adds driver callback for fast_switch and below observations
>>> on schedutil governor are done with this patch.
>>>
>>> In POWER8 there is a regression observed with schedutil compared to
>>> ondemand. With schedutil the frequency is not ramping down and is
>>> mostly stuck at max frequency during idle . This is because of the
>>> watchdog timer, an RT task which is fired every 4 seconds which
>>> results in requesting max frequency.
>>
>> Well, yes, that would be problematic.
>>
> 
> Right; we need to come up with something for RT tasks; but what happens
> if you disable the watchdog? This should be entirely doable and might
> give a better comparison.
> 

Below are the comparisons by disabling watchdog.
Both schedutil and ondemand have a similar ramp-down trend. And in both the
cases I can see that frequency of the cpu is not reduced in deterministic
fashion. In a observation window of 30 seconds after running a workload I can
see that the frequency is not ramped down on some cpus in the system and are
idling at max frequency.

Below are the sample trace showcasing the frequency request when the cpu enters
idle with schedutil.
<...>-3528  7650.011010: cpu_frequency: state=4322000 cpu_id=120
<...>-3528  7650.027540: sched_switch: prev_comm=ppc64_cpu prev_state=x ==>
next_comm=swapper/120
-07650.035017: cpu_frequency: state=4322000 cpu_id=120
-07729.683536: cpu_frequency: state=4322000 cpu_id=120
-07729.683552: sched_switch: prev_comm=swapper/120 prev_state=R ==>
next_comm=kworker/120:1
kworker/120  7729.683565: sched_switch: prev_comm=kworker/120:1 prev_state=S ==>
 next_comm=swapper/120

However ondemand governor(with watchdog enabled) benefits from the noise created
by watchdog timer and is able to brig down the frequency.

Thanks and Regards,
Shilpa



Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Heiko Stuebner
Am Freitag, 20. Mai 2016, 20:35:53 schrieb Shawn Lin:
> 在 2016/5/20 7:56, Caesar Wang 写道:
> > That's seem the incorrect string to match the spi driver.
> 
> Will it break the backward compatibility for some dtb if not
> falling back to "rockchip,rockchip-spi" ?

in what dtb did you see "rockchip,rockchip-spi"?
I.e. it isn't part of any current _mainline_ devicetree files.


Heiko

> 
> > Fixes commit f629fcfab2cd
> > ("ARM: dts: rockchip: support the spi for rk3036")
> > 
> > Signed-off-by: Caesar Wang 
> > Cc: Heiko Stuebner 
> > Cc: linux-rockc...@lists.infradead.org
> > 
> > ---
> > 
> > Changes in v2: None
> > 
> >  arch/arm/boot/dts/rk3036.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/rk3036.dtsi
> > b/arch/arm/boot/dts/rk3036.dtsi index d0f4bb7..a30700a 100644
> > --- a/arch/arm/boot/dts/rk3036.dtsi
> > +++ b/arch/arm/boot/dts/rk3036.dtsi
> > @@ -431,7 +431,7 @@
> > 
> > };
> > 
> > spi: spi@20074000 {
> > 
> > -   compatible = "rockchip,rockchip-spi";
> > +   compatible = "rockchip,rk3036-spi";
> > 
> > reg = <0x20074000 0x1000>;
> > interrupts = ;
> > clocks =< PCLK_SPI>, < SCLK_SPI>;



Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Heiko Stuebner
Am Freitag, 20. Mai 2016, 20:35:53 schrieb Shawn Lin:
> 在 2016/5/20 7:56, Caesar Wang 写道:
> > That's seem the incorrect string to match the spi driver.
> 
> Will it break the backward compatibility for some dtb if not
> falling back to "rockchip,rockchip-spi" ?

in what dtb did you see "rockchip,rockchip-spi"?
I.e. it isn't part of any current _mainline_ devicetree files.


Heiko

> 
> > Fixes commit f629fcfab2cd
> > ("ARM: dts: rockchip: support the spi for rk3036")
> > 
> > Signed-off-by: Caesar Wang 
> > Cc: Heiko Stuebner 
> > Cc: linux-rockc...@lists.infradead.org
> > 
> > ---
> > 
> > Changes in v2: None
> > 
> >  arch/arm/boot/dts/rk3036.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/rk3036.dtsi
> > b/arch/arm/boot/dts/rk3036.dtsi index d0f4bb7..a30700a 100644
> > --- a/arch/arm/boot/dts/rk3036.dtsi
> > +++ b/arch/arm/boot/dts/rk3036.dtsi
> > @@ -431,7 +431,7 @@
> > 
> > };
> > 
> > spi: spi@20074000 {
> > 
> > -   compatible = "rockchip,rockchip-spi";
> > +   compatible = "rockchip,rk3036-spi";
> > 
> > reg = <0x20074000 0x1000>;
> > interrupts = ;
> > clocks =< PCLK_SPI>, < SCLK_SPI>;



Re: [PATCH 1/2 V3] dt: add Atmel Captouch bindings

2016-05-20 Thread Rob Herring
On Wed, May 18, 2016 at 4:59 PM, Dmitry Torokhov
 wrote:
> On Wed, May 18, 2016 at 11:44:04AM -0500, Rob Herring wrote:
>> On Mon, May 16, 2016 at 01:54:53PM -0700, Grant Grundler wrote:
>> > From: Daniel Hung-yu Wu 
>> >
>> > Add binding for Atmel Capacitive Touch Button device.
>> >
>> > Signed-off-by: Daniel Hung-yu Wu 
>> > Signed-off-by: Grant Grundler 
>> > ---
>> >  .../devicetree/bindings/input/atmel,captouch.txt   | 36 
>> > ++
>> >  1 file changed, 34 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/input/atmel,captouch.txt
>>
>> Acked-by: Rob Herring 
>
> Folded into the driver patch and applied.

Folded why? Please don't do that. You should be committing what is
posted as is for the most part. We specifically ask that binding
changes are kept separate commits. It also messes up the ability to
correlate git commits to patchworks or mail searches.

Rob


Re: [PATCH 1/2 V3] dt: add Atmel Captouch bindings

2016-05-20 Thread Rob Herring
On Wed, May 18, 2016 at 4:59 PM, Dmitry Torokhov
 wrote:
> On Wed, May 18, 2016 at 11:44:04AM -0500, Rob Herring wrote:
>> On Mon, May 16, 2016 at 01:54:53PM -0700, Grant Grundler wrote:
>> > From: Daniel Hung-yu Wu 
>> >
>> > Add binding for Atmel Capacitive Touch Button device.
>> >
>> > Signed-off-by: Daniel Hung-yu Wu 
>> > Signed-off-by: Grant Grundler 
>> > ---
>> >  .../devicetree/bindings/input/atmel,captouch.txt   | 36 
>> > ++
>> >  1 file changed, 34 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/input/atmel,captouch.txt
>>
>> Acked-by: Rob Herring 
>
> Folded into the driver patch and applied.

Folded why? Please don't do that. You should be committing what is
posted as is for the most part. We specifically ask that binding
changes are kept separate commits. It also messes up the ability to
correlate git commits to patchworks or mail searches.

Rob


Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Caesar Wang


于 2016年05月20日 20:35, Shawn Lin 写道:

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


The rk3036 shouldn't work if you read the driver/spi/spi-rockchip.c.
since the "rockchip,rockchip-spi" is *not* exist in linux kernel.

..
 static const struct of_device_id rockchip_spi_dt_match[] = {
{ .compatible = "rockchip,rk3066-spi", },
{ .compatible = "rockchip,rk3188-spi", },
{ .compatible = "rockchip,rk3288-spi", },
{ .compatible = "rockchip,rk3399-spi", },
{ },
}
..


-Caesar




Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi 
b/arch/arm/boot/dts/rk3036.dtsi

index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
 };

 spi: spi@20074000 {
-compatible = "rockchip,rockchip-spi";
+compatible = "rockchip,rk3036-spi";
 reg = <0x20074000 0x1000>;
 interrupts = ;
 clocks =< PCLK_SPI>, < SCLK_SPI>;








--
caesar wang | software engineer | w...@rock-chip.com




Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Caesar Wang


于 2016年05月20日 20:35, Shawn Lin 写道:

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


The rk3036 shouldn't work if you read the driver/spi/spi-rockchip.c.
since the "rockchip,rockchip-spi" is *not* exist in linux kernel.

..
 static const struct of_device_id rockchip_spi_dt_match[] = {
{ .compatible = "rockchip,rk3066-spi", },
{ .compatible = "rockchip,rk3188-spi", },
{ .compatible = "rockchip,rk3288-spi", },
{ .compatible = "rockchip,rk3399-spi", },
{ },
}
..


-Caesar




Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi 
b/arch/arm/boot/dts/rk3036.dtsi

index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
 };

 spi: spi@20074000 {
-compatible = "rockchip,rockchip-spi";
+compatible = "rockchip,rk3036-spi";
 reg = <0x20074000 0x1000>;
 interrupts = ;
 clocks =< PCLK_SPI>, < SCLK_SPI>;








--
caesar wang | software engineer | w...@rock-chip.com




Re: [PATCH] arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368

2016-05-20 Thread Shawn Lin

在 2016/5/18 22:41, Caesar Wang 写道:

The 2nd additional region is the GIC virtual cpu interface register
base and size.

As the gic400 of rk3368 says, the cpu interface register map as below

:

-0x GICC_CTRL
.
.
.
-0x00fc GICC_IIDR
-0x1000 GICC_IDR

Obviously, the region size should be greater than 0x1000.
So we should make sure to include the GICC_IDR since the kernel will access
it in some cases.



yes, address range for GICC_* should be from 0x2000 to 0x3fff according
to gic400 memory map Table 3-1.

Reviewed-by: Shawn Lin 


Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org

---

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 8b4a7c9..080203e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -670,7 +670,7 @@
#address-cells = <0>;

reg = <0x0 0xffb71000 0x0 0x1000>,
- <0x0 0xffb72000 0x0 0x1000>,
+ <0x0 0xffb72000 0x0 0x2000>,
  <0x0 0xffb74000 0x0 0x2000>,
  <0x0 0xffb76000 0x0 0x2000>;
interrupts = 


--
Best Regards
Shawn Lin



Re: [PATCH] arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368

2016-05-20 Thread Shawn Lin

在 2016/5/18 22:41, Caesar Wang 写道:

The 2nd additional region is the GIC virtual cpu interface register
base and size.

As the gic400 of rk3368 says, the cpu interface register map as below

:

-0x GICC_CTRL
.
.
.
-0x00fc GICC_IIDR
-0x1000 GICC_IDR

Obviously, the region size should be greater than 0x1000.
So we should make sure to include the GICC_IDR since the kernel will access
it in some cases.



yes, address range for GICC_* should be from 0x2000 to 0x3fff according
to gic400 memory map Table 3-1.

Reviewed-by: Shawn Lin 


Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org

---

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 8b4a7c9..080203e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -670,7 +670,7 @@
#address-cells = <0>;

reg = <0x0 0xffb71000 0x0 0x1000>,
- <0x0 0xffb72000 0x0 0x1000>,
+ <0x0 0xffb72000 0x0 0x2000>,
  <0x0 0xffb74000 0x0 0x2000>,
  <0x0 0xffb76000 0x0 0x2000>;
interrupts = 


--
Best Regards
Shawn Lin



Re: [PATCH] ptp: use memdup_user().

2016-05-20 Thread Richard Cochran
On Fri, May 20, 2016 at 05:51:02PM +0530, Muhammad Falak R Wani wrote:
> Use memdup_user to duplicate a memory region from user-space to
> kernel-space, instead of open coding using kmalloc & copy_from_user.
> 
> Signed-off-by: Muhammad Falak R Wani 

Acked-by: Richard Cochran 


Re: [PATCH] ptp: use memdup_user().

2016-05-20 Thread Richard Cochran
On Fri, May 20, 2016 at 05:51:02PM +0530, Muhammad Falak R Wani wrote:
> Use memdup_user to duplicate a memory region from user-space to
> kernel-space, instead of open coding using kmalloc & copy_from_user.
> 
> Signed-off-by: Muhammad Falak R Wani 

Acked-by: Richard Cochran 


Re: [RFC 4/8] usb: phy: move TCSR driver into new file

2016-05-20 Thread Mark Brown
On Fri, May 20, 2016 at 02:24:14PM +0200, Arnd Bergmann wrote:
> On Thursday 19 May 2016 14:08:43 Andy Gross wrote:

> > I'd rather do something like what we did for the GSBI.  It needed to
> > change some phy related bits in the TCSR as well.  We defined the TCSR
> > as a syscon, with binding documentation under mfd.  If we add a syscon
> > entry and use it if it is present, we can deal with that pretty
> > easily.  The offsets change for each soc, and this would also fix that
> > issue because we can change offset based on tcsr compat.

> Works for me, but be aware that this will break the server chips,
> as ACPI has no support for regmap devices.

Just to be clear there's nothing precluding the use of regmap on ACPI
devices, it's syscon it doesn't have anything for.


signature.asc
Description: PGP signature


Re: [RFC 4/8] usb: phy: move TCSR driver into new file

2016-05-20 Thread Mark Brown
On Fri, May 20, 2016 at 02:24:14PM +0200, Arnd Bergmann wrote:
> On Thursday 19 May 2016 14:08:43 Andy Gross wrote:

> > I'd rather do something like what we did for the GSBI.  It needed to
> > change some phy related bits in the TCSR as well.  We defined the TCSR
> > as a syscon, with binding documentation under mfd.  If we add a syscon
> > entry and use it if it is present, we can deal with that pretty
> > easily.  The offsets change for each soc, and this would also fix that
> > issue because we can change offset based on tcsr compat.

> Works for me, but be aware that this will break the server chips,
> as ACPI has no support for regmap devices.

Just to be clear there's nothing precluding the use of regmap on ACPI
devices, it's syscon it doesn't have anything for.


signature.asc
Description: PGP signature


Re: [PATCH v4] z3fold: the 3-fold allocator for compressed pages

2016-05-20 Thread Dan Streetman
On Mon, May 9, 2016 at 9:17 AM, Vitaly Wool  wrote:
> This patch introduces z3fold, a special purpose allocator for storing
> compressed pages. It is designed to store up to three compressed pages per
> physical page. It is a ZBUD derivative which allows for higher compression
> ratio keeping the simplicity and determinism of its predecessor.
>
> This patch comes as a follow-up to the discussions at the Embedded Linux
> Conference in San-Diego related to the talk [1]. The outcome of these
> discussions was that it would be good to have a compressed page allocator
> as stable and deterministic as zbud with with higher compression ratio.
>
> To keep the determinism and simplicity, z3fold, just like zbud, always
> stores an integral number of compressed pages per page, but it can store
> up to 3 pages unlike zbud which can store at most 2. Therefore the
> compression ratio goes to around 2.6x while zbud's one is around 1.7x.
>
> The patch is based on the latest linux.git tree.
>
> This version has been updated after testing on various simulators (e. g.
> ARM Versatile Express, MIPS Malta, x86_64/Haswell) and basing on comments
> from Dan Streetman [3].
>
> The changes since v3 are:
> * added handle_to_buddy() helper
> * All z3fold functions were made static, and ZPOOL #ifdefs were removed
> * z3fold_compact_page() streamlined to only handle middle object compaction
> * z3fold_alloc() optimized for speed
> * Fixed bugs in z3fold_reclaim_page() and added page compaction there.
>
> The changes since v2 are:
> * addressed checkpatch rants
> * incorporated fixes basing on feedback from akpm in [2]
> * added Documentation/vm/z3fold.txt
> * improved free space accounting for a page, allowing for better object
>   packing within a page.
>
> The changes since v1 are:
> * various concurrency fixes made after intensive testing on SMP/HMP
>   platforms.
>
> [1] 
> https://openiotelc2016.sched.org/event/6DAC/swapping-and-embedded-compression-relieves-the-pressure-vitaly-wool-softprise-consulting-ou
> [2] https://lkml.org/lkml/2016/4/21/799
> [3] https://lkml.org/lkml/2016/5/4/852
>
> Signed-off-by: Vitaly Wool 
> ---
>  Documentation/vm/z3fold.txt |  27 ++
>  mm/Kconfig  |  12 +-
>  mm/Makefile |   1 +
>  mm/z3fold.c | 792 
> 
>  4 files changed, 831 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/vm/z3fold.txt
>  create mode 100644 mm/z3fold.c
>
> diff --git a/Documentation/vm/z3fold.txt b/Documentation/vm/z3fold.txt
> new file mode 100644
> index 000..3afff6e
> --- /dev/null
> +++ b/Documentation/vm/z3fold.txt
> @@ -0,0 +1,27 @@
> +z3fold
> +--
> +
> +z3fold is a special purpose allocator for storing compressed pages.
> +It is designed to store up to three compressed pages per physical page.
> +It is a zbud derivative which allows for higher compression
> +ratio keeping the simplicity and determinism of its predecessor.
> +
> +The main differences between z3fold and zbud are:
> +* unlike zbud, z3fold allows for up to PAGE_SIZE allocations
> +* z3fold can hold up to 3 compressed pages in its page
> +* z3fold doesn't export any API itself and is thus intended to be used
> +  via the zpool API.
> +
> +To keep the determinism and simplicity, z3fold, just like zbud, always
> +stores an integral number of compressed pages per page, but it can store
> +up to 3 pages unlike zbud which can store at most 2. Therefore the
> +compression ratio goes to around 2.7x while zbud's one is around 1.7x.
> +
> +Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not
> +return a dereferenceable pointer. Instead, it returns an unsigned long
> +handle which encodes actual location of the allocated object.
> +
> +Keeping effective compression ratio close to zsmalloc's, z3fold doesn't
> +depend on MMU enabled and provides more predictable reclaim behavior
> +which makes it a better fit for small and response-critical systems.
> +
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 989f8f3..27cbb39 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -556,7 +556,7 @@ config ZPOOL
>   zsmalloc.
>
>  config ZBUD
> -   tristate "Low density storage for compressed pages"
> +   tristate "Low (Up to 2x) density storage for compressed pages"
> default n
> help
>   A special purpose allocator for storing compressed pages.
> @@ -565,6 +565,16 @@ config ZBUD
>   deterministic reclaim properties that make it preferable to a higher
>   density approach when reclaim will be used.
>
> +config Z3FOLD
> +   tristate "Up to 3x density storage for compressed pages"
> +   depends on ZPOOL
> +   default n
> +   help
> + A special purpose allocator for storing compressed pages.
> + It is designed to store up to three compressed pages per physical
> + page. It is a ZBUD derivative so the simplicity and 

Re: [PATCH v4] z3fold: the 3-fold allocator for compressed pages

2016-05-20 Thread Dan Streetman
On Mon, May 9, 2016 at 9:17 AM, Vitaly Wool  wrote:
> This patch introduces z3fold, a special purpose allocator for storing
> compressed pages. It is designed to store up to three compressed pages per
> physical page. It is a ZBUD derivative which allows for higher compression
> ratio keeping the simplicity and determinism of its predecessor.
>
> This patch comes as a follow-up to the discussions at the Embedded Linux
> Conference in San-Diego related to the talk [1]. The outcome of these
> discussions was that it would be good to have a compressed page allocator
> as stable and deterministic as zbud with with higher compression ratio.
>
> To keep the determinism and simplicity, z3fold, just like zbud, always
> stores an integral number of compressed pages per page, but it can store
> up to 3 pages unlike zbud which can store at most 2. Therefore the
> compression ratio goes to around 2.6x while zbud's one is around 1.7x.
>
> The patch is based on the latest linux.git tree.
>
> This version has been updated after testing on various simulators (e. g.
> ARM Versatile Express, MIPS Malta, x86_64/Haswell) and basing on comments
> from Dan Streetman [3].
>
> The changes since v3 are:
> * added handle_to_buddy() helper
> * All z3fold functions were made static, and ZPOOL #ifdefs were removed
> * z3fold_compact_page() streamlined to only handle middle object compaction
> * z3fold_alloc() optimized for speed
> * Fixed bugs in z3fold_reclaim_page() and added page compaction there.
>
> The changes since v2 are:
> * addressed checkpatch rants
> * incorporated fixes basing on feedback from akpm in [2]
> * added Documentation/vm/z3fold.txt
> * improved free space accounting for a page, allowing for better object
>   packing within a page.
>
> The changes since v1 are:
> * various concurrency fixes made after intensive testing on SMP/HMP
>   platforms.
>
> [1] 
> https://openiotelc2016.sched.org/event/6DAC/swapping-and-embedded-compression-relieves-the-pressure-vitaly-wool-softprise-consulting-ou
> [2] https://lkml.org/lkml/2016/4/21/799
> [3] https://lkml.org/lkml/2016/5/4/852
>
> Signed-off-by: Vitaly Wool 
> ---
>  Documentation/vm/z3fold.txt |  27 ++
>  mm/Kconfig  |  12 +-
>  mm/Makefile |   1 +
>  mm/z3fold.c | 792 
> 
>  4 files changed, 831 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/vm/z3fold.txt
>  create mode 100644 mm/z3fold.c
>
> diff --git a/Documentation/vm/z3fold.txt b/Documentation/vm/z3fold.txt
> new file mode 100644
> index 000..3afff6e
> --- /dev/null
> +++ b/Documentation/vm/z3fold.txt
> @@ -0,0 +1,27 @@
> +z3fold
> +--
> +
> +z3fold is a special purpose allocator for storing compressed pages.
> +It is designed to store up to three compressed pages per physical page.
> +It is a zbud derivative which allows for higher compression
> +ratio keeping the simplicity and determinism of its predecessor.
> +
> +The main differences between z3fold and zbud are:
> +* unlike zbud, z3fold allows for up to PAGE_SIZE allocations
> +* z3fold can hold up to 3 compressed pages in its page
> +* z3fold doesn't export any API itself and is thus intended to be used
> +  via the zpool API.
> +
> +To keep the determinism and simplicity, z3fold, just like zbud, always
> +stores an integral number of compressed pages per page, but it can store
> +up to 3 pages unlike zbud which can store at most 2. Therefore the
> +compression ratio goes to around 2.7x while zbud's one is around 1.7x.
> +
> +Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not
> +return a dereferenceable pointer. Instead, it returns an unsigned long
> +handle which encodes actual location of the allocated object.
> +
> +Keeping effective compression ratio close to zsmalloc's, z3fold doesn't
> +depend on MMU enabled and provides more predictable reclaim behavior
> +which makes it a better fit for small and response-critical systems.
> +
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 989f8f3..27cbb39 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -556,7 +556,7 @@ config ZPOOL
>   zsmalloc.
>
>  config ZBUD
> -   tristate "Low density storage for compressed pages"
> +   tristate "Low (Up to 2x) density storage for compressed pages"
> default n
> help
>   A special purpose allocator for storing compressed pages.
> @@ -565,6 +565,16 @@ config ZBUD
>   deterministic reclaim properties that make it preferable to a higher
>   density approach when reclaim will be used.
>
> +config Z3FOLD
> +   tristate "Up to 3x density storage for compressed pages"
> +   depends on ZPOOL
> +   default n
> +   help
> + A special purpose allocator for storing compressed pages.
> + It is designed to store up to three compressed pages per physical
> + page. It is a ZBUD derivative so the simplicity and determinism are
> + still there.
> +
>  

Re: [PATCH 2/2] serial: 8250_mid: Read RX buffer on RX DMA timeout for DNV

2016-05-20 Thread Andy Shevchenko
On Mon, 2016-05-16 at 05:29 +, Chuah, Kim Tatt wrote:
> > On Fri, 2016-05-13 at 18:15 +0800, kbuild test robot wrote:

> > Peter, what happened to your DMA series in the linux-next? Did I
> > miss any
> > discussion related?
> > 
> Hi Andy,
> The error occurs when CONFIG_8250_MID is set to "m", because
> serial8250_rx_dma_flush() was not exported. Please advise.

Peter, this is a problem ^^^.

Kim, I suggest you to add an additional patch that exports a symbol and
send a new version of the patchset with Cc to Peter and linux-serial@
(besides the list of recipients you already have).

> > > > > ERROR: "serial8250_rx_dma_flush"
> > > > > [drivers/tty/serial/8250/8250_mid.ko] undefined!

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [PATCH 2/2] serial: 8250_mid: Read RX buffer on RX DMA timeout for DNV

2016-05-20 Thread Andy Shevchenko
On Mon, 2016-05-16 at 05:29 +, Chuah, Kim Tatt wrote:
> > On Fri, 2016-05-13 at 18:15 +0800, kbuild test robot wrote:

> > Peter, what happened to your DMA series in the linux-next? Did I
> > miss any
> > discussion related?
> > 
> Hi Andy,
> The error occurs when CONFIG_8250_MID is set to "m", because
> serial8250_rx_dma_flush() was not exported. Please advise.

Peter, this is a problem ^^^.

Kim, I suggest you to add an additional patch that exports a symbol and
send a new version of the patchset with Cc to Peter and linux-serial@
(besides the list of recipients you already have).

> > > > > ERROR: "serial8250_rx_dma_flush"
> > > > > [drivers/tty/serial/8250/8250_mid.ko] undefined!

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [RFC PATCH v2 2/3] arch/powerpc : optprobes for powerpc core

2016-05-20 Thread Masami Hiramatsu
Hi Anju,

Please see my comments below,

On Thu, 19 May 2016 20:40:39 +0530
Anju T  wrote:

> ppc_get_optinsn_slot() and ppc_free_optinsn_slot() are
> geared towards the allocation and freeing of memory from 
> the area reserved for detour buffer.
> 
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/kernel/optprobes.c | 480 
> 
>  1 file changed, 480 insertions(+)
>  create mode 100644 arch/powerpc/kernel/optprobes.c
> 
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> new file mode 100644
> index 000..bb61e18
> --- /dev/null
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -0,0 +1,480 @@
> +/*
> + * Code for Kernel probes Jump optimization.
> + *
> + * Copyright 2016, Anju T, IBM Corp.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SLOT_SIZE 65536
> +#define TMPL_CALL_HDLR_IDX   \
> + (optprobe_template_call_handler - optprobe_template_entry)
> +#define TMPL_EMULATE_IDX \
> + (optprobe_template_call_emulate - optprobe_template_entry)
> +#define TMPL_RET_BRANCH_IDX  \
> + (optprobe_template_ret_branch - optprobe_template_entry)
> +#define TMPL_RET_IDX \
> + (optprobe_template_ret - optprobe_template_entry)
> +#define TMPL_OP1_IDX \
> + (optprobe_template_op_address1 - optprobe_template_entry)
> +#define TMPL_OP2_IDX \
> + (optprobe_template_op_address2 - optprobe_template_entry)
> +#define TMPL_INSN_IDX\
> + (optprobe_template_insn - optprobe_template_entry)
> +#define TMPL_END_IDX \
> + (optprobe_template_end - optprobe_template_entry)
> +
> +struct kprobe_ppc_insn_page {
> + struct list_head list;
> + kprobe_opcode_t *insns; /* Page of instruction slots */
> + struct kprobe_insn_cache *cache;
> + int nused;
> + int ngarbage;
> + char slot_used[];
> +};
> +
> +#define PPC_KPROBE_INSN_PAGE_SIZE(slots) \
> + (offsetof(struct kprobe_ppc_insn_page, slot_used) + \
> + (sizeof(char) * (slots)))
> +
> +enum ppc_kprobe_slot_state {
> + SLOT_CLEAN = 0,
> + SLOT_DIRTY = 1,
> + SLOT_USED = 2,
> +};
> +
> +static struct kprobe_insn_cache kprobe_ppc_optinsn_slots = {
> + .mutex = __MUTEX_INITIALIZER(kprobe_ppc_optinsn_slots.mutex),
> + .pages = LIST_HEAD_INIT(kprobe_ppc_optinsn_slots.pages),
> + /* .insn_size is initialized later */
> + .nr_garbage = 0,
> +};
> +
> +static int ppc_slots_per_page(struct kprobe_insn_cache *c)
> +{
> + /*
> +  * Here the #slots per page differs from x86 as we have
> +  * only 64KB reserved.
> +  */
> + return SLOT_SIZE / (c->insn_size * sizeof(kprobe_opcode_t));
> +}
> +
> +/* Return 1 if all garbages are collected, otherwise 0. */
> +static int collect_one_slot(struct kprobe_ppc_insn_page *kip, int idx)
> +{
> + kip->slot_used[idx] = SLOT_CLEAN;
> + kip->nused--;
> + return 0;
> +}
> +
> +static int collect_garbage_slots(struct kprobe_insn_cache *c)
> +{
> + struct kprobe_ppc_insn_page *kip, *next;
> +
> + /* Ensure no-one is interrupted on the garbages */
> + synchronize_sched();
> +
> + list_for_each_entry_safe(kip, next, >pages, list) {
> + int i;
> +
> + if (kip->ngarbage == 0)
> + continue;
> + kip->ngarbage = 0;  /* we will collect all garbages */
> + for (i = 0; i < ppc_slots_per_page(c); i++) {
> + if (kip->slot_used[i] == SLOT_DIRTY &&
> + collect_one_slot(kip, i))
> + break;
> + }
> + }
> + c->nr_garbage = 0;
> + return 0;
> +}
> +
> +kprobe_opcode_t  *__ppc_get_optinsn_slot(struct kprobe_insn_cache *c)
> +{
> + struct kprobe_ppc_insn_page *kip;
> + kprobe_opcode_t *slot = NULL;
> +
> + mutex_lock(>mutex);
> + list_for_each_entry(kip, >pages, list) {
> + if (kip->nused < ppc_slots_per_page(c)) {
> + int i;
> +
> + for (i = 0; i < ppc_slots_per_page(c); i++) {
> + if (kip->slot_used[i] == SLOT_CLEAN) {
> + kip->slot_used[i] = SLOT_USED;
> + kip->nused++;
> + slot = kip->insns + (i * c->insn_size);
> + goto out;
> + }
> + }
> + /* kip->nused reached max value. */
> + kip->nused = ppc_slots_per_page(c);
> + WARN_ON(1);
> + 

Re: [RFC PATCH v2 2/3] arch/powerpc : optprobes for powerpc core

2016-05-20 Thread Masami Hiramatsu
Hi Anju,

Please see my comments below,

On Thu, 19 May 2016 20:40:39 +0530
Anju T  wrote:

> ppc_get_optinsn_slot() and ppc_free_optinsn_slot() are
> geared towards the allocation and freeing of memory from 
> the area reserved for detour buffer.
> 
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/kernel/optprobes.c | 480 
> 
>  1 file changed, 480 insertions(+)
>  create mode 100644 arch/powerpc/kernel/optprobes.c
> 
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> new file mode 100644
> index 000..bb61e18
> --- /dev/null
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -0,0 +1,480 @@
> +/*
> + * Code for Kernel probes Jump optimization.
> + *
> + * Copyright 2016, Anju T, IBM Corp.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SLOT_SIZE 65536
> +#define TMPL_CALL_HDLR_IDX   \
> + (optprobe_template_call_handler - optprobe_template_entry)
> +#define TMPL_EMULATE_IDX \
> + (optprobe_template_call_emulate - optprobe_template_entry)
> +#define TMPL_RET_BRANCH_IDX  \
> + (optprobe_template_ret_branch - optprobe_template_entry)
> +#define TMPL_RET_IDX \
> + (optprobe_template_ret - optprobe_template_entry)
> +#define TMPL_OP1_IDX \
> + (optprobe_template_op_address1 - optprobe_template_entry)
> +#define TMPL_OP2_IDX \
> + (optprobe_template_op_address2 - optprobe_template_entry)
> +#define TMPL_INSN_IDX\
> + (optprobe_template_insn - optprobe_template_entry)
> +#define TMPL_END_IDX \
> + (optprobe_template_end - optprobe_template_entry)
> +
> +struct kprobe_ppc_insn_page {
> + struct list_head list;
> + kprobe_opcode_t *insns; /* Page of instruction slots */
> + struct kprobe_insn_cache *cache;
> + int nused;
> + int ngarbage;
> + char slot_used[];
> +};
> +
> +#define PPC_KPROBE_INSN_PAGE_SIZE(slots) \
> + (offsetof(struct kprobe_ppc_insn_page, slot_used) + \
> + (sizeof(char) * (slots)))
> +
> +enum ppc_kprobe_slot_state {
> + SLOT_CLEAN = 0,
> + SLOT_DIRTY = 1,
> + SLOT_USED = 2,
> +};
> +
> +static struct kprobe_insn_cache kprobe_ppc_optinsn_slots = {
> + .mutex = __MUTEX_INITIALIZER(kprobe_ppc_optinsn_slots.mutex),
> + .pages = LIST_HEAD_INIT(kprobe_ppc_optinsn_slots.pages),
> + /* .insn_size is initialized later */
> + .nr_garbage = 0,
> +};
> +
> +static int ppc_slots_per_page(struct kprobe_insn_cache *c)
> +{
> + /*
> +  * Here the #slots per page differs from x86 as we have
> +  * only 64KB reserved.
> +  */
> + return SLOT_SIZE / (c->insn_size * sizeof(kprobe_opcode_t));
> +}
> +
> +/* Return 1 if all garbages are collected, otherwise 0. */
> +static int collect_one_slot(struct kprobe_ppc_insn_page *kip, int idx)
> +{
> + kip->slot_used[idx] = SLOT_CLEAN;
> + kip->nused--;
> + return 0;
> +}
> +
> +static int collect_garbage_slots(struct kprobe_insn_cache *c)
> +{
> + struct kprobe_ppc_insn_page *kip, *next;
> +
> + /* Ensure no-one is interrupted on the garbages */
> + synchronize_sched();
> +
> + list_for_each_entry_safe(kip, next, >pages, list) {
> + int i;
> +
> + if (kip->ngarbage == 0)
> + continue;
> + kip->ngarbage = 0;  /* we will collect all garbages */
> + for (i = 0; i < ppc_slots_per_page(c); i++) {
> + if (kip->slot_used[i] == SLOT_DIRTY &&
> + collect_one_slot(kip, i))
> + break;
> + }
> + }
> + c->nr_garbage = 0;
> + return 0;
> +}
> +
> +kprobe_opcode_t  *__ppc_get_optinsn_slot(struct kprobe_insn_cache *c)
> +{
> + struct kprobe_ppc_insn_page *kip;
> + kprobe_opcode_t *slot = NULL;
> +
> + mutex_lock(>mutex);
> + list_for_each_entry(kip, >pages, list) {
> + if (kip->nused < ppc_slots_per_page(c)) {
> + int i;
> +
> + for (i = 0; i < ppc_slots_per_page(c); i++) {
> + if (kip->slot_used[i] == SLOT_CLEAN) {
> + kip->slot_used[i] = SLOT_USED;
> + kip->nused++;
> + slot = kip->insns + (i * c->insn_size);
> + goto out;
> + }
> + }
> + /* kip->nused reached max value. */
> + kip->nused = ppc_slots_per_page(c);
> + WARN_ON(1);
> + }
> + if 

rxrpc: Simplify connect() implementation and simplify sendmsg() op

2016-05-20 Thread David Howells
Hi Dave,

Are you okay with taking this into net-next?

I no longer take away the ability to do connect(), but now it does nothing
more than specify a default address and mark the socket as being client
only.  As before, the default address is overridden if sendmsg() is given
an address.

The other significant UAPI change is that I deal better with a race between
two threads trying to register calls with the same user ID (one of them
will get an error).

David
---
rxrpc: Simplify connect() implementation and simplify sendmsg() op

Simplify the RxRPC connect() implementation.  It will just note the
destination address it is given, and if a sendmsg() comes along with no
address, this will be assigned as the address.  No transport struct will be
held internally, which will allow us to remove this later.

Simplify sendmsg() also.  Whilst a call is active, userspace refers to it
by a private unique user ID specified in a control message.  When sendmsg()
sees a user ID that doesn't map to an extant call, it creates a new call
for that user ID and attempts to add it.  If, when we try to add it, the
user ID is now registered, we now reject the message with -EEXIST.  We
should never see this situation unless two threads are racing, trying to
create a call with the same ID - which would be an error.

It also isn't required to provide sendmsg() with an address - provided the
control message data holds a user ID that maps to a currently active call.

Signed-off-by: David Howells 
---
 include/linux/rxrpc.h |   18 ++--
 net/rxrpc/af_rxrpc.c  |  177 +++
 net/rxrpc/ar-call.c   |  158 +++
 net/rxrpc/ar-connection.c |   17 
 net/rxrpc/ar-internal.h   |   22 ++---
 net/rxrpc/ar-output.c |  186 +-
 6 files changed, 234 insertions(+), 344 deletions(-)

diff --git a/include/linux/rxrpc.h b/include/linux/rxrpc.h
index a53915cd5581..1e8f216e2cf1 100644
--- a/include/linux/rxrpc.h
+++ b/include/linux/rxrpc.h
@@ -40,16 +40,18 @@ struct sockaddr_rxrpc {
 
 /*
  * RxRPC control messages
+ * - If neither abort or accept are specified, the message is a data message.
  * - terminal messages mean that a user call ID tag can be recycled
+ * - s/r/- indicate whether these are applicable to sendmsg() and/or recvmsg()
  */
-#define RXRPC_USER_CALL_ID 1   /* user call ID specifier */
-#define RXRPC_ABORT2   /* abort request / notification 
[terminal] */
-#define RXRPC_ACK  3   /* [Server] RPC op final ACK received 
[terminal] */
-#define RXRPC_NET_ERROR5   /* network error received 
[terminal] */
-#define RXRPC_BUSY 6   /* server busy received [terminal] */
-#define RXRPC_LOCAL_ERROR  7   /* local error generated [terminal] */
-#define RXRPC_NEW_CALL 8   /* [Server] new incoming call 
notification */
-#define RXRPC_ACCEPT   9   /* [Server] accept request */
+#define RXRPC_USER_CALL_ID 1   /* sr: user call ID specifier */
+#define RXRPC_ABORT2   /* sr: abort request / notification 
[terminal] */
+#define RXRPC_ACK  3   /* -r: [Service] RPC op final ACK 
received [terminal] */
+#define RXRPC_NET_ERROR5   /* -r: network error received 
[terminal] */
+#define RXRPC_BUSY 6   /* -r: server busy received [terminal] 
*/
+#define RXRPC_LOCAL_ERROR  7   /* -r: local error generated [terminal] 
*/
+#define RXRPC_NEW_CALL 8   /* -r: [Service] new incoming call 
notification */
+#define RXRPC_ACCEPT   9   /* s-: [Service] accept request */
 
 /*
  * RxRPC security levels
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index e45e94ca030f..484b5ee16a50 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -137,33 +137,33 @@ static int rxrpc_bind(struct socket *sock, struct 
sockaddr *saddr, int len)
 
lock_sock(>sk);
 
-   if (rx->sk.sk_state != RXRPC_UNCONNECTED) {
+   if (rx->sk.sk_state != RXRPC_UNBOUND) {
ret = -EINVAL;
goto error_unlock;
}
 
memcpy(>srx, srx, sizeof(rx->srx));
 
-   /* Find or create a local transport endpoint to use */
local = rxrpc_lookup_local(>srx);
if (IS_ERR(local)) {
ret = PTR_ERR(local);
goto error_unlock;
}
 
-   rx->local = local;
-   if (srx->srx_service) {
+   if (rx->srx.srx_service) {
write_lock_bh(>services_lock);
list_for_each_entry(prx, >services, listen_link) {
-   if (prx->srx.srx_service == srx->srx_service)
+   if (prx->srx.srx_service == rx->srx.srx_service)
goto service_in_use;
}
 
+   rx->local = local;
list_add_tail(>listen_link, >services);
 

rxrpc: Simplify connect() implementation and simplify sendmsg() op

2016-05-20 Thread David Howells
Hi Dave,

Are you okay with taking this into net-next?

I no longer take away the ability to do connect(), but now it does nothing
more than specify a default address and mark the socket as being client
only.  As before, the default address is overridden if sendmsg() is given
an address.

The other significant UAPI change is that I deal better with a race between
two threads trying to register calls with the same user ID (one of them
will get an error).

David
---
rxrpc: Simplify connect() implementation and simplify sendmsg() op

Simplify the RxRPC connect() implementation.  It will just note the
destination address it is given, and if a sendmsg() comes along with no
address, this will be assigned as the address.  No transport struct will be
held internally, which will allow us to remove this later.

Simplify sendmsg() also.  Whilst a call is active, userspace refers to it
by a private unique user ID specified in a control message.  When sendmsg()
sees a user ID that doesn't map to an extant call, it creates a new call
for that user ID and attempts to add it.  If, when we try to add it, the
user ID is now registered, we now reject the message with -EEXIST.  We
should never see this situation unless two threads are racing, trying to
create a call with the same ID - which would be an error.

It also isn't required to provide sendmsg() with an address - provided the
control message data holds a user ID that maps to a currently active call.

Signed-off-by: David Howells 
---
 include/linux/rxrpc.h |   18 ++--
 net/rxrpc/af_rxrpc.c  |  177 +++
 net/rxrpc/ar-call.c   |  158 +++
 net/rxrpc/ar-connection.c |   17 
 net/rxrpc/ar-internal.h   |   22 ++---
 net/rxrpc/ar-output.c |  186 +-
 6 files changed, 234 insertions(+), 344 deletions(-)

diff --git a/include/linux/rxrpc.h b/include/linux/rxrpc.h
index a53915cd5581..1e8f216e2cf1 100644
--- a/include/linux/rxrpc.h
+++ b/include/linux/rxrpc.h
@@ -40,16 +40,18 @@ struct sockaddr_rxrpc {
 
 /*
  * RxRPC control messages
+ * - If neither abort or accept are specified, the message is a data message.
  * - terminal messages mean that a user call ID tag can be recycled
+ * - s/r/- indicate whether these are applicable to sendmsg() and/or recvmsg()
  */
-#define RXRPC_USER_CALL_ID 1   /* user call ID specifier */
-#define RXRPC_ABORT2   /* abort request / notification 
[terminal] */
-#define RXRPC_ACK  3   /* [Server] RPC op final ACK received 
[terminal] */
-#define RXRPC_NET_ERROR5   /* network error received 
[terminal] */
-#define RXRPC_BUSY 6   /* server busy received [terminal] */
-#define RXRPC_LOCAL_ERROR  7   /* local error generated [terminal] */
-#define RXRPC_NEW_CALL 8   /* [Server] new incoming call 
notification */
-#define RXRPC_ACCEPT   9   /* [Server] accept request */
+#define RXRPC_USER_CALL_ID 1   /* sr: user call ID specifier */
+#define RXRPC_ABORT2   /* sr: abort request / notification 
[terminal] */
+#define RXRPC_ACK  3   /* -r: [Service] RPC op final ACK 
received [terminal] */
+#define RXRPC_NET_ERROR5   /* -r: network error received 
[terminal] */
+#define RXRPC_BUSY 6   /* -r: server busy received [terminal] 
*/
+#define RXRPC_LOCAL_ERROR  7   /* -r: local error generated [terminal] 
*/
+#define RXRPC_NEW_CALL 8   /* -r: [Service] new incoming call 
notification */
+#define RXRPC_ACCEPT   9   /* s-: [Service] accept request */
 
 /*
  * RxRPC security levels
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index e45e94ca030f..484b5ee16a50 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -137,33 +137,33 @@ static int rxrpc_bind(struct socket *sock, struct 
sockaddr *saddr, int len)
 
lock_sock(>sk);
 
-   if (rx->sk.sk_state != RXRPC_UNCONNECTED) {
+   if (rx->sk.sk_state != RXRPC_UNBOUND) {
ret = -EINVAL;
goto error_unlock;
}
 
memcpy(>srx, srx, sizeof(rx->srx));
 
-   /* Find or create a local transport endpoint to use */
local = rxrpc_lookup_local(>srx);
if (IS_ERR(local)) {
ret = PTR_ERR(local);
goto error_unlock;
}
 
-   rx->local = local;
-   if (srx->srx_service) {
+   if (rx->srx.srx_service) {
write_lock_bh(>services_lock);
list_for_each_entry(prx, >services, listen_link) {
-   if (prx->srx.srx_service == srx->srx_service)
+   if (prx->srx.srx_service == rx->srx.srx_service)
goto service_in_use;
}
 
+   rx->local = local;
list_add_tail(>listen_link, >services);

Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Shawn Lin

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
};

spi: spi@20074000 {
-   compatible = "rockchip,rockchip-spi";
+   compatible = "rockchip,rk3036-spi";
reg = <0x20074000 0x1000>;
interrupts = ;
clocks =< PCLK_SPI>, < SCLK_SPI>;





Re: [PATCH v2 3/3] ARM: dts: rockchip: fixes the spi compatible for rk3036

2016-05-20 Thread Shawn Lin

在 2016/5/20 7:56, Caesar Wang 写道:

That's seem the incorrect string to match the spi driver.



Will it break the backward compatibility for some dtb if not
falling back to "rockchip,rockchip-spi" ?


Fixes commit f629fcfab2cd
("ARM: dts: rockchip: support the spi for rk3036")

Signed-off-by: Caesar Wang 
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org

---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index d0f4bb7..a30700a 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -431,7 +431,7 @@
};

spi: spi@20074000 {
-   compatible = "rockchip,rockchip-spi";
+   compatible = "rockchip,rk3036-spi";
reg = <0x20074000 0x1000>;
interrupts = ;
clocks =< PCLK_SPI>, < SCLK_SPI>;





[PATCH] drm: hdlcd: Revamp runtime power management

2016-05-20 Thread Liviu Dudau
Because the HDLCD driver acts as a component master it can end
up enabling the runtime PM functionality before the encoders
are initialised. This can cause crashes if the component slave
never probes (missing module) or if the PM operations kick in
before the probe finishes.

Move the enabling of the runtime PM after the component master
has finished collecting the slave components and use the DRM
atomic helpers to suspend and resume the device.

Tested-by: Robin Murphy 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 23 +--
 drivers/gpu/drm/arm/hdlcd_drv.c  | 48 ++--
 drivers/gpu/drm/arm/hdlcd_drv.h  |  3 +--
 3 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index fef1b04..d1e8d31 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -33,8 +33,17 @@
  *
  */
 
+static void hdlcd_crtc_cleanup(struct drm_crtc *crtc)
+{
+   struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+
+   /* stop the controller on cleanup */
+   hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+   drm_crtc_cleanup(crtc);
+}
+
 static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
-   .destroy = drm_crtc_cleanup,
+   .destroy = hdlcd_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
@@ -155,8 +164,8 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
if (!crtc->primary->fb)
return;
 
-   clk_disable_unprepare(hdlcd->clk);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+   clk_disable_unprepare(hdlcd->clk);
drm_crtc_vblank_off(crtc);
 }
 
@@ -294,16 +303,6 @@ static struct drm_plane *hdlcd_plane_init(struct 
drm_device *drm)
return plane;
 }
 
-void hdlcd_crtc_suspend(struct drm_crtc *crtc)
-{
-   hdlcd_crtc_disable(crtc);
-}
-
-void hdlcd_crtc_resume(struct drm_crtc *crtc)
-{
-   hdlcd_crtc_enable(crtc);
-}
-
 int hdlcd_setup_crtc(struct drm_device *drm)
 {
struct hdlcd_drm_private *hdlcd = drm->dev_private;
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 734899c..ea928e7 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -84,11 +84,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned long 
flags)
goto setup_fail;
}
 
-   pm_runtime_enable(drm->dev);
-
-   pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
-   pm_runtime_put_sync(drm->dev);
if (ret < 0) {
DRM_ERROR("failed to install IRQ handler\n");
goto irq_fail;
@@ -357,6 +353,8 @@ static int hdlcd_drm_bind(struct device *dev)
return -ENOMEM;
 
drm->dev_private = hdlcd;
+   dev_set_drvdata(dev, drm);
+
hdlcd_setup_mode_config(drm);
ret = hdlcd_load(drm, 0);
if (ret)
@@ -366,14 +364,18 @@ static int hdlcd_drm_bind(struct device *dev)
if (ret)
goto err_unload;
 
-   dev_set_drvdata(dev, drm);
-
ret = component_bind_all(dev, drm);
if (ret) {
DRM_ERROR("Failed to bind all components\n");
goto err_unregister;
}
 
+   ret = pm_runtime_set_active(dev);
+   if (ret)
+   goto err_pm_active;
+
+   pm_runtime_enable(dev);
+
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
@@ -400,16 +402,16 @@ err_fbdev:
drm_mode_config_cleanup(drm);
drm_vblank_cleanup(drm);
 err_vblank:
+   pm_runtime_disable(drm->dev);
+err_pm_active:
component_unbind_all(dev, drm);
 err_unregister:
drm_dev_unregister(drm);
 err_unload:
-   pm_runtime_get_sync(drm->dev);
drm_irq_uninstall(drm);
-   pm_runtime_put_sync(drm->dev);
-   pm_runtime_disable(drm->dev);
of_reserved_mem_device_release(drm->dev);
 err_free:
+   dev_set_drvdata(dev, NULL);
drm_dev_unref(drm);
 
return ret;
@@ -496,30 +498,34 @@ MODULE_DEVICE_TABLE(of, hdlcd_of_match);
 static int __maybe_unused hdlcd_pm_suspend(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);
-   struct drm_crtc *crtc;
+   struct hdlcd_drm_private *hdlcd = drm ? drm->dev_private : NULL;
 
-   if (pm_runtime_suspended(dev))
+   if (!hdlcd)
return 0;
 
-   drm_modeset_lock_all(drm);
-   list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   hdlcd_crtc_suspend(crtc);
-   drm_modeset_unlock_all(drm);
+   drm_kms_helper_poll_disable(drm);
+
+   hdlcd->state = drm_atomic_helper_suspend(drm);
+   if (IS_ERR(hdlcd->state)) {

[PATCH] drm: hdlcd: Revamp runtime power management

2016-05-20 Thread Liviu Dudau
Because the HDLCD driver acts as a component master it can end
up enabling the runtime PM functionality before the encoders
are initialised. This can cause crashes if the component slave
never probes (missing module) or if the PM operations kick in
before the probe finishes.

Move the enabling of the runtime PM after the component master
has finished collecting the slave components and use the DRM
atomic helpers to suspend and resume the device.

Tested-by: Robin Murphy 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 23 +--
 drivers/gpu/drm/arm/hdlcd_drv.c  | 48 ++--
 drivers/gpu/drm/arm/hdlcd_drv.h  |  3 +--
 3 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index fef1b04..d1e8d31 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -33,8 +33,17 @@
  *
  */
 
+static void hdlcd_crtc_cleanup(struct drm_crtc *crtc)
+{
+   struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+
+   /* stop the controller on cleanup */
+   hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+   drm_crtc_cleanup(crtc);
+}
+
 static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
-   .destroy = drm_crtc_cleanup,
+   .destroy = hdlcd_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
@@ -155,8 +164,8 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
if (!crtc->primary->fb)
return;
 
-   clk_disable_unprepare(hdlcd->clk);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+   clk_disable_unprepare(hdlcd->clk);
drm_crtc_vblank_off(crtc);
 }
 
@@ -294,16 +303,6 @@ static struct drm_plane *hdlcd_plane_init(struct 
drm_device *drm)
return plane;
 }
 
-void hdlcd_crtc_suspend(struct drm_crtc *crtc)
-{
-   hdlcd_crtc_disable(crtc);
-}
-
-void hdlcd_crtc_resume(struct drm_crtc *crtc)
-{
-   hdlcd_crtc_enable(crtc);
-}
-
 int hdlcd_setup_crtc(struct drm_device *drm)
 {
struct hdlcd_drm_private *hdlcd = drm->dev_private;
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 734899c..ea928e7 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -84,11 +84,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned long 
flags)
goto setup_fail;
}
 
-   pm_runtime_enable(drm->dev);
-
-   pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
-   pm_runtime_put_sync(drm->dev);
if (ret < 0) {
DRM_ERROR("failed to install IRQ handler\n");
goto irq_fail;
@@ -357,6 +353,8 @@ static int hdlcd_drm_bind(struct device *dev)
return -ENOMEM;
 
drm->dev_private = hdlcd;
+   dev_set_drvdata(dev, drm);
+
hdlcd_setup_mode_config(drm);
ret = hdlcd_load(drm, 0);
if (ret)
@@ -366,14 +364,18 @@ static int hdlcd_drm_bind(struct device *dev)
if (ret)
goto err_unload;
 
-   dev_set_drvdata(dev, drm);
-
ret = component_bind_all(dev, drm);
if (ret) {
DRM_ERROR("Failed to bind all components\n");
goto err_unregister;
}
 
+   ret = pm_runtime_set_active(dev);
+   if (ret)
+   goto err_pm_active;
+
+   pm_runtime_enable(dev);
+
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
@@ -400,16 +402,16 @@ err_fbdev:
drm_mode_config_cleanup(drm);
drm_vblank_cleanup(drm);
 err_vblank:
+   pm_runtime_disable(drm->dev);
+err_pm_active:
component_unbind_all(dev, drm);
 err_unregister:
drm_dev_unregister(drm);
 err_unload:
-   pm_runtime_get_sync(drm->dev);
drm_irq_uninstall(drm);
-   pm_runtime_put_sync(drm->dev);
-   pm_runtime_disable(drm->dev);
of_reserved_mem_device_release(drm->dev);
 err_free:
+   dev_set_drvdata(dev, NULL);
drm_dev_unref(drm);
 
return ret;
@@ -496,30 +498,34 @@ MODULE_DEVICE_TABLE(of, hdlcd_of_match);
 static int __maybe_unused hdlcd_pm_suspend(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);
-   struct drm_crtc *crtc;
+   struct hdlcd_drm_private *hdlcd = drm ? drm->dev_private : NULL;
 
-   if (pm_runtime_suspended(dev))
+   if (!hdlcd)
return 0;
 
-   drm_modeset_lock_all(drm);
-   list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   hdlcd_crtc_suspend(crtc);
-   drm_modeset_unlock_all(drm);
+   drm_kms_helper_poll_disable(drm);
+
+   hdlcd->state = drm_atomic_helper_suspend(drm);
+   if (IS_ERR(hdlcd->state)) {
+   

Re: [PATCH] tty/vt/keyboard: use memdup_user().

2016-05-20 Thread Samuel Thibault
Muhammad Falak R Wani, on Fri 20 May 2016 17:53:28 +0530, wrote:
> Use memdup_user to duplicate a memory region from user-space to
> kernel-space, instead of open coding using kmalloc & copy_from_user.
> 
> Signed-off-by: Muhammad Falak R Wani 

Reviewed-by: Samuel Thibault 

> ---
>  drivers/tty/vt/keyboard.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f973bfc..698ea43 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -1745,16 +1745,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
> int perm)
>   return -EINVAL;
>  
>   if (ct) {
> - buf = kmalloc(ct * sizeof(struct kbdiacruc),
> - GFP_KERNEL);
> - if (buf == NULL)
> - return -ENOMEM;
> -
> - if (copy_from_user(buf, a->kbdiacruc,
> - ct * sizeof(struct kbdiacruc))) {
> - kfree(buf);
> - return -EFAULT;
> - }
> + buf = memdup_user(a->kbdiacruc,
> +   ct * sizeof(struct kbdiacruc));
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
>   } 
>   spin_lock_irqsave(_event_lock, flags);
>   if (ct)
> -- 
> 1.9.1
> 

-- 
Samuel
(03:13:14)  bon
(03:13:19)  il est tard :p
(03:13:25)  c'est l'heure de manger
(03:13:38)  hm j'ai mangé à 1h moi, j'ai des horaires raisonnables


Re: [PATCH] tty/vt/keyboard: use memdup_user().

2016-05-20 Thread Samuel Thibault
Muhammad Falak R Wani, on Fri 20 May 2016 17:53:28 +0530, wrote:
> Use memdup_user to duplicate a memory region from user-space to
> kernel-space, instead of open coding using kmalloc & copy_from_user.
> 
> Signed-off-by: Muhammad Falak R Wani 

Reviewed-by: Samuel Thibault 

> ---
>  drivers/tty/vt/keyboard.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f973bfc..698ea43 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -1745,16 +1745,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
> int perm)
>   return -EINVAL;
>  
>   if (ct) {
> - buf = kmalloc(ct * sizeof(struct kbdiacruc),
> - GFP_KERNEL);
> - if (buf == NULL)
> - return -ENOMEM;
> -
> - if (copy_from_user(buf, a->kbdiacruc,
> - ct * sizeof(struct kbdiacruc))) {
> - kfree(buf);
> - return -EFAULT;
> - }
> + buf = memdup_user(a->kbdiacruc,
> +   ct * sizeof(struct kbdiacruc));
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
>   } 
>   spin_lock_irqsave(_event_lock, flags);
>   if (ct)
> -- 
> 1.9.1
> 

-- 
Samuel
(03:13:14)  bon
(03:13:19)  il est tard :p
(03:13:25)  c'est l'heure de manger
(03:13:38)  hm j'ai mangé à 1h moi, j'ai des horaires raisonnables


Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Arnd Bergmann
On Friday 20 May 2016 14:21:37 Neil Armstrong wrote:
> Use the brand new devm_reset_controller_register() API to get rid of
> the platform driver remove callback.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/reset/reset-oxnas.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> Hi Philip,
> 
> This patch is based on your reset/next tree after the new
> devm_reset_controller_register() was merged.
> 
> I hope it could be merged for 4.7.
> 
> 

It's too late for that now, as it looks like a cleanup patch that
can wait until 4.8. If the patch fixes a bug that prevents it from
working correctly, please clarify that in the changelog text.

Arnd


Re: [PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Arnd Bergmann
On Friday 20 May 2016 14:21:37 Neil Armstrong wrote:
> Use the brand new devm_reset_controller_register() API to get rid of
> the platform driver remove callback.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/reset/reset-oxnas.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> Hi Philip,
> 
> This patch is based on your reset/next tree after the new
> devm_reset_controller_register() was merged.
> 
> I hope it could be merged for 4.7.
> 
> 

It's too late for that now, as it looks like a cleanup patch that
can wait until 4.8. If the patch fixes a bug that prevents it from
working correctly, please clarify that in the changelog text.

Arnd


Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Carlo Caione
On 20/05/16 14:20, Neil Armstrong wrote:
> On 05/20/2016 12:04 PM, Carlo Caione wrote:
> > On 20/05/16 11:10, Neil Armstrong wrote:
> >> On 05/20/2016 11:04 AM, Carlo Caione wrote:
> >>> On 20/05/16 10:27, Neil Armstrong wrote:
>  This patch adds the platform driver for the Amlogic Meson GXBB Reset
>  Controller.
> 
>  Signed-off-by: Neil Armstrong 
>  ---
>   drivers/reset/Kconfig|   6 ++
>   drivers/reset/Makefile   |   1 +
>   drivers/reset/reset-meson-gxbb.c | 129 
>  +++
>   3 files changed, 136 insertions(+)
>   create mode 100644 drivers/reset/reset-meson-gxbb.c
> >>>
> >>> Do we really need to be that specific (-gxbb)? This driver looks generic
> >>> and simple enough to be used for several Amlogic families. You are
> >>> already differentiating between them with the include file defining the
> >>> reset indexes for the SoC.
> >>
> >> This is a good question, do the S805 have similar registers ? Same count 
> >> and width ?
> >> I no, it should need a rework to add a data structure per-SoC.
> > 
> > According to the datasheet on S805 we have 7 registers with 16 reset
> > bits per register.
> 
> It will fit, I made the change to be generic. Do you know if the meson8 and 
> previous meson6 has these registers ?

No idea. No datasheet for those.

Cheers,

-- 
Carlo Caione


Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Carlo Caione
On 20/05/16 14:20, Neil Armstrong wrote:
> On 05/20/2016 12:04 PM, Carlo Caione wrote:
> > On 20/05/16 11:10, Neil Armstrong wrote:
> >> On 05/20/2016 11:04 AM, Carlo Caione wrote:
> >>> On 20/05/16 10:27, Neil Armstrong wrote:
>  This patch adds the platform driver for the Amlogic Meson GXBB Reset
>  Controller.
> 
>  Signed-off-by: Neil Armstrong 
>  ---
>   drivers/reset/Kconfig|   6 ++
>   drivers/reset/Makefile   |   1 +
>   drivers/reset/reset-meson-gxbb.c | 129 
>  +++
>   3 files changed, 136 insertions(+)
>   create mode 100644 drivers/reset/reset-meson-gxbb.c
> >>>
> >>> Do we really need to be that specific (-gxbb)? This driver looks generic
> >>> and simple enough to be used for several Amlogic families. You are
> >>> already differentiating between them with the include file defining the
> >>> reset indexes for the SoC.
> >>
> >> This is a good question, do the S805 have similar registers ? Same count 
> >> and width ?
> >> I no, it should need a rework to add a data structure per-SoC.
> > 
> > According to the datasheet on S805 we have 7 registers with 16 reset
> > bits per register.
> 
> It will fit, I made the change to be generic. Do you know if the meson8 and 
> previous meson6 has these registers ?

No idea. No datasheet for those.

Cheers,

-- 
Carlo Caione


Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Neil Armstrong
On 05/20/2016 02:22 PM, Carlo Caione wrote:
> On 20/05/16 14:19, Neil Armstrong wrote:
> 
> [...]
> Missing #include  ?
>
> Thanks,
>

 Shouldn't we wait until the reset bindings are actually used in the dtsi ?
 I'm quite sure kevin will post it with the Ethernet nodes.
>>>
>>> Why? The header file is related to the reset controller. Better add it
>>> now with this patchset.
>>>
>>> Cheers,
>>>
>>
>> OK, I will add it in gxbb and meson8b dtsi files.
> 
> Why also meson8b DTSI?
> 

Sorry, I'll add the meson8b specific header of course.

Neil


Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Neil Armstrong
On 05/20/2016 02:22 PM, Carlo Caione wrote:
> On 20/05/16 14:19, Neil Armstrong wrote:
> 
> [...]
> Missing #include  ?
>
> Thanks,
>

 Shouldn't we wait until the reset bindings are actually used in the dtsi ?
 I'm quite sure kevin will post it with the Ethernet nodes.
>>>
>>> Why? The header file is related to the reset controller. Better add it
>>> now with this patchset.
>>>
>>> Cheers,
>>>
>>
>> OK, I will add it in gxbb and meson8b dtsi files.
> 
> Why also meson8b DTSI?
> 

Sorry, I'll add the meson8b specific header of course.

Neil


Re: [RFC 4/8] usb: phy: move TCSR driver into new file

2016-05-20 Thread Arnd Bergmann
On Thursday 19 May 2016 14:08:43 Andy Gross wrote:
> > + * - Tim
> > + */
> > +int qcom_tcsr_phy_sel(u32 val)
> > +{
> > +   void __iomem *phy_select;
> > +   int ret;
> > +
> > +   phy_select = ioremap(USB2_PHY_SEL, 4);
> > +
> > +   if (!phy_select) {
> > +   ret = -ENOMEM;
> > +   goto out;
> > +   }
> > +   /* Enable second PHY with the OTG port */
> > +   writel(0x1, phy_select);
> > +   ret = 0;
> > +out:
> > +   iounmap(phy_select);
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_tcsr_phy_sel);
> 
> I'd rather do something like what we did for the GSBI.  It needed to
> change some phy related bits in the TCSR as well.  We defined the TCSR
> as a syscon, with binding documentation under mfd.  If we add a syscon
> entry and use it if it is present, we can deal with that pretty
> easily.  The offsets change for each soc, and this would also fix that
> issue because we can change offset based on tcsr compat.

Works for me, but be aware that this will break the server chips,
as ACPI has no support for regmap devices.

I think that's fine, they should really handle this register access
in the firmware anyway rather than relying on a hardcoded MMIO
location.

Arnd


Re: [RFC 4/8] usb: phy: move TCSR driver into new file

2016-05-20 Thread Arnd Bergmann
On Thursday 19 May 2016 14:08:43 Andy Gross wrote:
> > + * - Tim
> > + */
> > +int qcom_tcsr_phy_sel(u32 val)
> > +{
> > +   void __iomem *phy_select;
> > +   int ret;
> > +
> > +   phy_select = ioremap(USB2_PHY_SEL, 4);
> > +
> > +   if (!phy_select) {
> > +   ret = -ENOMEM;
> > +   goto out;
> > +   }
> > +   /* Enable second PHY with the OTG port */
> > +   writel(0x1, phy_select);
> > +   ret = 0;
> > +out:
> > +   iounmap(phy_select);
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_tcsr_phy_sel);
> 
> I'd rather do something like what we did for the GSBI.  It needed to
> change some phy related bits in the TCSR as well.  We defined the TCSR
> as a syscon, with binding documentation under mfd.  If we add a syscon
> entry and use it if it is present, we can deal with that pretty
> easily.  The offsets change for each soc, and this would also fix that
> issue because we can change offset based on tcsr compat.

Works for me, but be aware that this will break the server chips,
as ACPI has no support for regmap devices.

I think that's fine, they should really handle this register access
in the firmware anyway rather than relying on a hardcoded MMIO
location.

Arnd


[PATCH] tty/vt/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/tty/vt/keyboard.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f973bfc..698ea43 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1745,16 +1745,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
int perm)
return -EINVAL;
 
if (ct) {
-   buf = kmalloc(ct * sizeof(struct kbdiacruc),
-   GFP_KERNEL);
-   if (buf == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(buf, a->kbdiacruc,
-   ct * sizeof(struct kbdiacruc))) {
-   kfree(buf);
-   return -EFAULT;
-   }
+   buf = memdup_user(a->kbdiacruc,
+ ct * sizeof(struct kbdiacruc));
+   if (IS_ERR(buf))
+   return PTR_ERR(buf);
} 
spin_lock_irqsave(_event_lock, flags);
if (ct)
-- 
1.9.1



[PATCH] tty/vt/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/tty/vt/keyboard.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f973bfc..698ea43 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1745,16 +1745,10 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp, 
int perm)
return -EINVAL;
 
if (ct) {
-   buf = kmalloc(ct * sizeof(struct kbdiacruc),
-   GFP_KERNEL);
-   if (buf == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(buf, a->kbdiacruc,
-   ct * sizeof(struct kbdiacruc))) {
-   kfree(buf);
-   return -EFAULT;
-   }
+   buf = memdup_user(a->kbdiacruc,
+ ct * sizeof(struct kbdiacruc));
+   if (IS_ERR(buf))
+   return PTR_ERR(buf);
} 
spin_lock_irqsave(_event_lock, flags);
if (ct)
-- 
1.9.1



Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Carlo Caione
On 20/05/16 14:19, Neil Armstrong wrote:

[...]
> >>> Missing #include  ?
> >>>
> >>> Thanks,
> >>>
> >>
> >> Shouldn't we wait until the reset bindings are actually used in the dtsi ?
> >> I'm quite sure kevin will post it with the Ethernet nodes.
> > 
> > Why? The header file is related to the reset controller. Better add it
> > now with this patchset.
> > 
> > Cheers,
> > 
> 
> OK, I will add it in gxbb and meson8b dtsi files.

Why also meson8b DTSI?

-- 
Carlo Caione


Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Carlo Caione
On 20/05/16 14:19, Neil Armstrong wrote:

[...]
> >>> Missing #include  ?
> >>>
> >>> Thanks,
> >>>
> >>
> >> Shouldn't we wait until the reset bindings are actually used in the dtsi ?
> >> I'm quite sure kevin will post it with the Ethernet nodes.
> > 
> > Why? The header file is related to the reset controller. Better add it
> > now with this patchset.
> > 
> > Cheers,
> > 
> 
> OK, I will add it in gxbb and meson8b dtsi files.

Why also meson8b DTSI?

-- 
Carlo Caione


[PATCH] ks390/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/s390/char/keyboard.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/s390/char/keyboard.c b/drivers/s390/char/keyboard.c
index ef04a9f..2955983 100644
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -438,13 +438,9 @@ do_kdgkb_ioctl(struct kbd_data *kbd, struct kbsentry 
__user *u_kbs,
return -EFAULT;
if (len > sizeof(u_kbs->kb_string))
return -EINVAL;
-   p = kmalloc(len, GFP_KERNEL);
-   if (!p)
-   return -ENOMEM;
-   if (copy_from_user(p, u_kbs->kb_string, len)) {
-   kfree(p);
-   return -EFAULT;
-   }
+   p = memdup_user(u_kbs->kb_string, len);
+   if (IS_ERR(p))
+   return PTR_ERR(p);
/*
 * Make sure the string is terminated by 0. User could have
 * modified it between us running strnlen_user() and copying it.
-- 
1.9.1



[PATCH] ks390/keyboard: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/s390/char/keyboard.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/s390/char/keyboard.c b/drivers/s390/char/keyboard.c
index ef04a9f..2955983 100644
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -438,13 +438,9 @@ do_kdgkb_ioctl(struct kbd_data *kbd, struct kbsentry 
__user *u_kbs,
return -EFAULT;
if (len > sizeof(u_kbs->kb_string))
return -EINVAL;
-   p = kmalloc(len, GFP_KERNEL);
-   if (!p)
-   return -ENOMEM;
-   if (copy_from_user(p, u_kbs->kb_string, len)) {
-   kfree(p);
-   return -EFAULT;
-   }
+   p = memdup_user(u_kbs->kb_string, len);
+   if (IS_ERR(p))
+   return PTR_ERR(p);
/*
 * Make sure the string is terminated by 0. User could have
 * modified it between us running strnlen_user() and copying it.
-- 
1.9.1



[PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Neil Armstrong
Use the brand new devm_reset_controller_register() API to get rid of
the platform driver remove callback.

Signed-off-by: Neil Armstrong 
---
 drivers/reset/reset-oxnas.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

Hi Philip,

This patch is based on your reset/next tree after the new
devm_reset_controller_register() was merged.

I hope it could be merged for 4.7.

Thanks,
Neil

diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
index c60fb2d..9449805 100644
--- a/drivers/reset/reset-oxnas.c
+++ b/drivers/reset/reset-oxnas.c
@@ -112,21 +112,11 @@ static int oxnas_reset_probe(struct platform_device *pdev)
data->rcdev.ops = _reset_ops;
data->rcdev.of_node = pdev->dev.of_node;
 
-   return reset_controller_register(>rcdev);
-}
-
-static int oxnas_reset_remove(struct platform_device *pdev)
-{
-   struct oxnas_reset *data = platform_get_drvdata(pdev);
-
-   reset_controller_unregister(>rcdev);
-
-   return 0;
+   return devm_reset_controller_register(>dev, >rcdev);
 }
 
 static struct platform_driver oxnas_reset_driver = {
.probe  = oxnas_reset_probe,
-   .remove = oxnas_reset_remove,
.driver = {
.name   = "oxnas-reset",
.of_match_table = oxnas_reset_dt_ids,
-- 
1.9.1



[PATCH] reset: oxnas: Use devm register API and get rid of platform remove

2016-05-20 Thread Neil Armstrong
Use the brand new devm_reset_controller_register() API to get rid of
the platform driver remove callback.

Signed-off-by: Neil Armstrong 
---
 drivers/reset/reset-oxnas.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

Hi Philip,

This patch is based on your reset/next tree after the new
devm_reset_controller_register() was merged.

I hope it could be merged for 4.7.

Thanks,
Neil

diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
index c60fb2d..9449805 100644
--- a/drivers/reset/reset-oxnas.c
+++ b/drivers/reset/reset-oxnas.c
@@ -112,21 +112,11 @@ static int oxnas_reset_probe(struct platform_device *pdev)
data->rcdev.ops = _reset_ops;
data->rcdev.of_node = pdev->dev.of_node;
 
-   return reset_controller_register(>rcdev);
-}
-
-static int oxnas_reset_remove(struct platform_device *pdev)
-{
-   struct oxnas_reset *data = platform_get_drvdata(pdev);
-
-   reset_controller_unregister(>rcdev);
-
-   return 0;
+   return devm_reset_controller_register(>dev, >rcdev);
 }
 
 static struct platform_driver oxnas_reset_driver = {
.probe  = oxnas_reset_probe,
-   .remove = oxnas_reset_remove,
.driver = {
.name   = "oxnas-reset",
.of_match_table = oxnas_reset_dt_ids,
-- 
1.9.1



[PATCH] ptp: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/ptp/ptp_chardev.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 579fd65..0b1ac6b 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -208,14 +208,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, 
unsigned long arg)
break;
 
case PTP_SYS_OFFSET:
-   sysoff = kmalloc(sizeof(*sysoff), GFP_KERNEL);
-   if (!sysoff) {
-   err = -ENOMEM;
-   break;
-   }
-   if (copy_from_user(sysoff, (void __user *)arg,
-  sizeof(*sysoff))) {
-   err = -EFAULT;
+   sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
+   if (IS_ERR(sysoff)) {
+   err = PTR_ERR(sysoff);
break;
}
if (sysoff->n_samples > PTP_MAX_SAMPLES) {
-- 
1.9.1



[PATCH] ptp: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/ptp/ptp_chardev.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 579fd65..0b1ac6b 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -208,14 +208,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, 
unsigned long arg)
break;
 
case PTP_SYS_OFFSET:
-   sysoff = kmalloc(sizeof(*sysoff), GFP_KERNEL);
-   if (!sysoff) {
-   err = -ENOMEM;
-   break;
-   }
-   if (copy_from_user(sysoff, (void __user *)arg,
-  sizeof(*sysoff))) {
-   err = -EFAULT;
+   sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
+   if (IS_ERR(sysoff)) {
+   err = PTR_ERR(sysoff);
break;
}
if (sysoff->n_samples > PTP_MAX_SAMPLES) {
-- 
1.9.1



[PATCH] wan: cosa: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/net/wan/cosa.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index b87fe0a..fb37439 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -876,15 +876,10 @@ static ssize_t cosa_write(struct file *file,
count = COSA_MTU;

/* Allocate the buffer */
-   kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
-   if (kbuf == NULL) {
+   kbuf = memdup_user(buf, count);
+   if (IS_ERR(kbuf)) {
up(>wsem);
-   return -ENOMEM;
-   }
-   if (copy_from_user(kbuf, buf, count)) {
-   up(>wsem);
-   kfree(kbuf);
-   return -EFAULT;
+   return PTR_ERR(kbuf);
}
chan->tx_status=0;
cosa_start_tx(chan, kbuf, count);
-- 
1.9.1



Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
On 05/20/2016 12:04 PM, Carlo Caione wrote:
> On 20/05/16 11:10, Neil Armstrong wrote:
>> On 05/20/2016 11:04 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 This patch adds the platform driver for the Amlogic Meson GXBB Reset
 Controller.

 Signed-off-by: Neil Armstrong 
 ---
  drivers/reset/Kconfig|   6 ++
  drivers/reset/Makefile   |   1 +
  drivers/reset/reset-meson-gxbb.c | 129 
 +++
  3 files changed, 136 insertions(+)
  create mode 100644 drivers/reset/reset-meson-gxbb.c
>>>
>>> Do we really need to be that specific (-gxbb)? This driver looks generic
>>> and simple enough to be used for several Amlogic families. You are
>>> already differentiating between them with the include file defining the
>>> reset indexes for the SoC.
>>
>> This is a good question, do the S805 have similar registers ? Same count and 
>> width ?
>> I no, it should need a rework to add a data structure per-SoC.
> 
> According to the datasheet on S805 we have 7 registers with 16 reset
> bits per register.

It will fit, I made the change to be generic. Do you know if the meson8 and 
previous meson6 has these registers ?

Neil



[PATCH] wan: cosa: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/net/wan/cosa.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index b87fe0a..fb37439 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -876,15 +876,10 @@ static ssize_t cosa_write(struct file *file,
count = COSA_MTU;

/* Allocate the buffer */
-   kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
-   if (kbuf == NULL) {
+   kbuf = memdup_user(buf, count);
+   if (IS_ERR(kbuf)) {
up(>wsem);
-   return -ENOMEM;
-   }
-   if (copy_from_user(kbuf, buf, count)) {
-   up(>wsem);
-   kfree(kbuf);
-   return -EFAULT;
+   return PTR_ERR(kbuf);
}
chan->tx_status=0;
cosa_start_tx(chan, kbuf, count);
-- 
1.9.1



Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
On 05/20/2016 12:04 PM, Carlo Caione wrote:
> On 20/05/16 11:10, Neil Armstrong wrote:
>> On 05/20/2016 11:04 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 This patch adds the platform driver for the Amlogic Meson GXBB Reset
 Controller.

 Signed-off-by: Neil Armstrong 
 ---
  drivers/reset/Kconfig|   6 ++
  drivers/reset/Makefile   |   1 +
  drivers/reset/reset-meson-gxbb.c | 129 
 +++
  3 files changed, 136 insertions(+)
  create mode 100644 drivers/reset/reset-meson-gxbb.c
>>>
>>> Do we really need to be that specific (-gxbb)? This driver looks generic
>>> and simple enough to be used for several Amlogic families. You are
>>> already differentiating between them with the include file defining the
>>> reset indexes for the SoC.
>>
>> This is a good question, do the S805 have similar registers ? Same count and 
>> width ?
>> I no, it should need a rework to add a data structure per-SoC.
> 
> According to the datasheet on S805 we have 7 registers with 16 reset
> bits per register.

It will fit, I made the change to be generic. Do you know if the meson8 and 
previous meson6 has these registers ?

Neil



[PATCH] VMCI: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/misc/vmw_vmci/vmci_host.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/vmw_vmci/vmci_host.c 
b/drivers/misc/vmw_vmci/vmci_host.c
index 9ec262a..ec09010 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -381,18 +381,12 @@ static int vmci_host_do_send_datagram(struct 
vmci_host_dev *vmci_host_dev,
return -EINVAL;
}
 
-   dg = kmalloc(send_info.len, GFP_KERNEL);
-   if (!dg) {
+   dg = memdup_user((void __user *)(uintptr_t)send_info.addr,
+send_info.len);
+   if (IS_ERR(dg)) {
vmci_ioctl_err(
"cannot allocate memory to dispatch datagram\n");
-   return -ENOMEM;
-   }
-
-   if (copy_from_user(dg, (void __user *)(uintptr_t)send_info.addr,
-  send_info.len)) {
-   vmci_ioctl_err("error getting datagram\n");
-   kfree(dg);
-   return -EFAULT;
+   return PTR_ERR(dg);
}
 
if (VMCI_DG_SIZE(dg) != send_info.len) {
-- 
1.9.1



Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Neil Armstrong
On 05/20/2016 11:10 AM, Carlo Caione wrote:
> On 20/05/16 10:53, Neil Armstrong wrote:
>> On 05/20/2016 10:47 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 Update DTSI file to add the reset controller node.

 Signed-off-by: Neil Armstrong 
 ---
  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
 b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 index 832815d..2463e04 100644
 --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 @@ -129,6 +129,12 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc110 0x0 0x10>;
  
 +  reset: reset-controller@4404 {
 +  compatible = "amlogic,meson-gxbb-reset";
 +  reg = <0x0 0x04404 0x0 0x20>;
 +  #reset-cells = <1>;
 +  };
 +
uart_A: serial@84c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x084c0 0x0 0x14>;
>>>
>>> Missing #include  ?
>>>
>>> Thanks,
>>>
>>
>> Shouldn't we wait until the reset bindings are actually used in the dtsi ?
>> I'm quite sure kevin will post it with the Ethernet nodes.
> 
> Why? The header file is related to the reset controller. Better add it
> now with this patchset.
> 
> Cheers,
> 

OK, I will add it in gxbb and meson8b dtsi files.

Neil


[PATCH] VMCI: use memdup_user().

2016-05-20 Thread Muhammad Falak R Wani
Use memdup_user to duplicate a memory region from user-space to
kernel-space, instead of open coding using kmalloc & copy_from_user.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/misc/vmw_vmci/vmci_host.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/vmw_vmci/vmci_host.c 
b/drivers/misc/vmw_vmci/vmci_host.c
index 9ec262a..ec09010 100644
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -381,18 +381,12 @@ static int vmci_host_do_send_datagram(struct 
vmci_host_dev *vmci_host_dev,
return -EINVAL;
}
 
-   dg = kmalloc(send_info.len, GFP_KERNEL);
-   if (!dg) {
+   dg = memdup_user((void __user *)(uintptr_t)send_info.addr,
+send_info.len);
+   if (IS_ERR(dg)) {
vmci_ioctl_err(
"cannot allocate memory to dispatch datagram\n");
-   return -ENOMEM;
-   }
-
-   if (copy_from_user(dg, (void __user *)(uintptr_t)send_info.addr,
-  send_info.len)) {
-   vmci_ioctl_err("error getting datagram\n");
-   kfree(dg);
-   return -EFAULT;
+   return PTR_ERR(dg);
}
 
if (VMCI_DG_SIZE(dg) != send_info.len) {
-- 
1.9.1



Re: [PATCH 3/3] ARM64: dts: amlogic: Enable Reset Controller on GXBB-based platforms

2016-05-20 Thread Neil Armstrong
On 05/20/2016 11:10 AM, Carlo Caione wrote:
> On 20/05/16 10:53, Neil Armstrong wrote:
>> On 05/20/2016 10:47 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 Update DTSI file to add the reset controller node.

 Signed-off-by: Neil Armstrong 
 ---
  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
 b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 index 832815d..2463e04 100644
 --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
 @@ -129,6 +129,12 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc110 0x0 0x10>;
  
 +  reset: reset-controller@4404 {
 +  compatible = "amlogic,meson-gxbb-reset";
 +  reg = <0x0 0x04404 0x0 0x20>;
 +  #reset-cells = <1>;
 +  };
 +
uart_A: serial@84c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x084c0 0x0 0x14>;
>>>
>>> Missing #include  ?
>>>
>>> Thanks,
>>>
>>
>> Shouldn't we wait until the reset bindings are actually used in the dtsi ?
>> I'm quite sure kevin will post it with the Ethernet nodes.
> 
> Why? The header file is related to the reset controller. Better add it
> now with this patchset.
> 
> Cheers,
> 

OK, I will add it in gxbb and meson8b dtsi files.

Neil


Re: [PATCH 2/3] dt-bindings: reset: Add bindings for the Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
On 05/20/2016 11:08 AM, Carlo Caione wrote:
> On 20/05/16 10:51, Neil Armstrong wrote:
>> On 05/20/2016 10:46 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 Add DT bindings for the Meson GXBB SoC Reset Controller documentation and 
 the
 associated include file.
>>>
>>> [...]
>>>
 +#define RESET_I2C_MASTER_2142
 +#define RESET_I2C_MASTER_1143
 +/*144-159 */
 +/*RESET5  */
 +/*160-191 */
 +/*RESET6  */
 +#define RESET_PERIPHS_GENERAL 192
 +#define RESET_PERIPHS_SPICC   193
 +#define RESET_PERIPHS_SMART_CARD  194
 +#define RESET_PERIPHS_SAR_ADC 195
 +#define RESET_PERIPHS_I2C_MASTER_0196
 +#define RESET_SANA197
 +/*198 */
 +#define RESET_PERIPHS_STREAM_INTERFACE199
 +#define RESET_PERIPHS_SDIO200
 +#define RESET_PERIPHS_UART_0  201
 +#define RESET_PERIPHS_UART_1_2202
 +#define RESET_PERIPHS_ASYNC_0 203
 +#define RESET_PERIPHS_ASYNC_1 204
 +#define RESET_PERIPHS_SPI_0   205
 +#define RESET_PERIPHS_SDHC206
 +#define RESET_UART_SLIP   207
 +/*208-223 */
 +/*RESET7  */
 +#define RESET_USB_DDR_0   224
 +#define RESET_USB_DDR_1   225
 +#define RESET_USB_DDR_2   226
 +#define RESET_USB_DDR_3   227
 +/*228 */
 +#define RESET_DEVICE_MMC_ARB  229
 +/*230 */
 +#define RESET_VID_LOCK231
 +#define RESET_A9_DMC_PIPEL232
 +/*233-255 */
 +
 +#endif
>>>
>>> Indentation looks really messy. Can you just shift the numbers to the
>>> right so that they are on the same column?
>>>
>> Hi Carlo,
>>
>> The patch format makes it very messy, not as in the original format :
>> https://github.com/superna/linux/blob/6163f8742454bb7ff962956b4e286d110ec0fb79/include/dt-bindings/reset/amlogic%2Cmeson-gxbb-reset.h
> 
> https://raw.githubusercontent.com/superna/linux/6163f8742454bb7ff962956b4e286d110ec0fb79/include/dt-bindings/reset/amlogic%2Cmeson-gxbb-reset.h
> 
> yes, but 192 -> 200 are not nicely indented to me :)
> 

Aw, you got me !

I will add a shift and add a separate meson8b version of this file.

Neil


Re: [PATCH 2/3] dt-bindings: reset: Add bindings for the Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
On 05/20/2016 11:08 AM, Carlo Caione wrote:
> On 20/05/16 10:51, Neil Armstrong wrote:
>> On 05/20/2016 10:46 AM, Carlo Caione wrote:
>>> On 20/05/16 10:27, Neil Armstrong wrote:
 Add DT bindings for the Meson GXBB SoC Reset Controller documentation and 
 the
 associated include file.
>>>
>>> [...]
>>>
 +#define RESET_I2C_MASTER_2142
 +#define RESET_I2C_MASTER_1143
 +/*144-159 */
 +/*RESET5  */
 +/*160-191 */
 +/*RESET6  */
 +#define RESET_PERIPHS_GENERAL 192
 +#define RESET_PERIPHS_SPICC   193
 +#define RESET_PERIPHS_SMART_CARD  194
 +#define RESET_PERIPHS_SAR_ADC 195
 +#define RESET_PERIPHS_I2C_MASTER_0196
 +#define RESET_SANA197
 +/*198 */
 +#define RESET_PERIPHS_STREAM_INTERFACE199
 +#define RESET_PERIPHS_SDIO200
 +#define RESET_PERIPHS_UART_0  201
 +#define RESET_PERIPHS_UART_1_2202
 +#define RESET_PERIPHS_ASYNC_0 203
 +#define RESET_PERIPHS_ASYNC_1 204
 +#define RESET_PERIPHS_SPI_0   205
 +#define RESET_PERIPHS_SDHC206
 +#define RESET_UART_SLIP   207
 +/*208-223 */
 +/*RESET7  */
 +#define RESET_USB_DDR_0   224
 +#define RESET_USB_DDR_1   225
 +#define RESET_USB_DDR_2   226
 +#define RESET_USB_DDR_3   227
 +/*228 */
 +#define RESET_DEVICE_MMC_ARB  229
 +/*230 */
 +#define RESET_VID_LOCK231
 +#define RESET_A9_DMC_PIPEL232
 +/*233-255 */
 +
 +#endif
>>>
>>> Indentation looks really messy. Can you just shift the numbers to the
>>> right so that they are on the same column?
>>>
>> Hi Carlo,
>>
>> The patch format makes it very messy, not as in the original format :
>> https://github.com/superna/linux/blob/6163f8742454bb7ff962956b4e286d110ec0fb79/include/dt-bindings/reset/amlogic%2Cmeson-gxbb-reset.h
> 
> https://raw.githubusercontent.com/superna/linux/6163f8742454bb7ff962956b4e286d110ec0fb79/include/dt-bindings/reset/amlogic%2Cmeson-gxbb-reset.h
> 
> yes, but 192 -> 200 are not nicely indented to me :)
> 

Aw, you got me !

I will add a shift and add a separate meson8b version of this file.

Neil


Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
Hi Philipp,

On 05/20/2016 11:27 AM, Philipp Zabel wrote:
> Hi Neil,
> 
> Am Freitag, den 20.05.2016, 10:27 +0200 schrieb Neil Armstrong:
>> +config MESON_GXBB_RESET
>> +tristate "Amlogic Meson GXBB Reset Driver"
>> +depends on (ARCH_MESON && RESET_CONTROLLER)
> 
> With the "reset: fix Kconfig menu to include reset drivers in sub-menu"
> patch [1] applied this is wrapped in "if RESET_CONTROLLER ... endif", so
> no need to depend on RESET_CONTROLLER.
> Is there a reason to have this configurable at all, though?
> 
> [1] https://patchwork.kernel.org/patch/9000591/
> 
> Or drop CONFIG_MESON_GXBB_RESET and use CONFIG_ARCH_MESON directly.

No strong reason, I will switch to CONFIG_ARCH_MESON.

> [...]
> 
> With the "reset: add devm_reset_controller_register API" patch [2]
> applied you can use devm_reset_controller_register() here and remove the
> meson_gxbb_reset_remove() function below.
> 
> [2] https://patchwork.kernel.org/patch/8988471/
> 
>> +}
>> +
>> +static int meson_gxbb_reset_remove(struct platform_device *pdev)
>> +{
>> +struct meson_gxbb_reset *data = platform_get_drvdata(pdev);
>> +
>> +reset_controller_unregister(>rcdev);
>> +
>> +return 0;
>> +}
> 
> Could be removed, then.
> 
> regards
> Philipp

It will be for sure !

Neil



Re: [PATCH 1/3] reset: Add support for the Amlogic Meson GXBB Reset Controller

2016-05-20 Thread Neil Armstrong
Hi Philipp,

On 05/20/2016 11:27 AM, Philipp Zabel wrote:
> Hi Neil,
> 
> Am Freitag, den 20.05.2016, 10:27 +0200 schrieb Neil Armstrong:
>> +config MESON_GXBB_RESET
>> +tristate "Amlogic Meson GXBB Reset Driver"
>> +depends on (ARCH_MESON && RESET_CONTROLLER)
> 
> With the "reset: fix Kconfig menu to include reset drivers in sub-menu"
> patch [1] applied this is wrapped in "if RESET_CONTROLLER ... endif", so
> no need to depend on RESET_CONTROLLER.
> Is there a reason to have this configurable at all, though?
> 
> [1] https://patchwork.kernel.org/patch/9000591/
> 
> Or drop CONFIG_MESON_GXBB_RESET and use CONFIG_ARCH_MESON directly.

No strong reason, I will switch to CONFIG_ARCH_MESON.

> [...]
> 
> With the "reset: add devm_reset_controller_register API" patch [2]
> applied you can use devm_reset_controller_register() here and remove the
> meson_gxbb_reset_remove() function below.
> 
> [2] https://patchwork.kernel.org/patch/8988471/
> 
>> +}
>> +
>> +static int meson_gxbb_reset_remove(struct platform_device *pdev)
>> +{
>> +struct meson_gxbb_reset *data = platform_get_drvdata(pdev);
>> +
>> +reset_controller_unregister(>rcdev);
>> +
>> +return 0;
>> +}
> 
> Could be removed, then.
> 
> regards
> Philipp

It will be for sure !

Neil



Re: [PATCH] PM / sleep: fix unbalanced pm runtime disable in __device_suspend_late()

2016-05-20 Thread Rafael J. Wysocki
On Thursday, May 19, 2016 08:11:34 PM Grygorii Strashko wrote:
> On 05/19/2016 04:38 PM, Rafael J. Wysocki wrote:
> > On Fri, May 13, 2016 at 8:03 PM, Grygorii Strashko
> >  wrote:
> >> The PM runtime will be left disabled for the device if its .suspend_late()
> >> callback fails and async suspend is not allowed for this device. In
> >> this case device will not be added in dpm_late_early_list and
> >> dpm_resume_early() will ignore this device, as result PM runtime will
> >> be disabled for it forever (side effect: after 8 subsequent failures
> >> for the same device the PM runtime will be reenabled due to
> >> disable_depth overflow).
> >>
> >> Hence, re-enable PM runtime in __device_suspend_late() if
> >> .suspend_late() callback fails and async suspend is not allowed for
> >> this device.
> >>
> >> Signed-off-by: Grygorii Strashko 
> >> ---
> >>   drivers/base/power/main.c | 7 +--
> >>   1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> index 6e7c3cc..9b266e5 100644
> >> --- a/drivers/base/power/main.c
> >> +++ b/drivers/base/power/main.c
> >> @@ -1207,10 +1207,13 @@ static int __device_suspend_late(struct device 
> >> *dev, pm_message_t state, bool as
> >>  }
> >>
> >>  error = dpm_run_callback(callback, dev, state, info);
> >> -   if (!error)
> >> +   if (!error) {
> >>  dev->power.is_late_suspended = true;
> >> -   else
> >> +   } else {
>   Point [1]
> >>  async_error = error;
> >> +   if (!is_async(dev))
> > 
> > Why is the is_async() check necessary here?
>   
> A: deviceX is suspended *async* and reached point [1], in this case:
> - deviceX has been added in dpm_late_early_list already
> - dpm_suspend_late() will detect async_error and call dpm_resume_early()
> - dpm_resume_early() will call device_resume_early() for deviceX
> - device_resume_early() will re-enable PM runtime
> {
> ...
>   if (!dev->power.is_late_suspended)
>   goto Out;
> 
>   ...
>  Out:
>   TRACE_RESUME(error);
> 
>   pm_runtime_enable(dev);
> 
>   complete_all(>power.completion);
>   return error;
> } 
>   
> 
> B: deviceX is suspended *sync* and reached point [1], in this case:
> - deviceX has not been added in dpm_late_early_list yet
> - dpm_suspend_late() will detect sync_error and call dpm_resume_early()
> - dpm_resume_early() will ignore deviceX
> 
> if i'll not check for !is_async(dev) then pm_runtime_enable(dev)
> will be called twice for deviceX with this patch.

OK, thanks!

So to me, the problem is that we handle failures in that code inconsistently
depending on whether or not async suspend/resume is enabled for the device.

I'd rather make it consistent than add extra checks to it, so the patch below
is how I would fix this.

---
From: Rafael J. Wysocki 
Subject: [PATCH] PM / sleep: Handle failures in device_suspend_late() 
consistently

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -1267,14 +1267,15 @@ int dpm_suspend_late(pm_message_t state)
error = device_suspend_late(dev);
 
mutex_lock(_list_mtx);
+   if (!list_empty(>power.entry))
+   list_move(>power.entry, _late_early_list);
+
if (error) {
pm_dev_err(dev, state, " late", error);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
}
-   if (!list_empty(>power.entry))
-   list_move(>power.entry, _late_early_list);
put_device(dev);
 
if (async_error)



Re: [PATCH] PM / sleep: fix unbalanced pm runtime disable in __device_suspend_late()

2016-05-20 Thread Rafael J. Wysocki
On Thursday, May 19, 2016 08:11:34 PM Grygorii Strashko wrote:
> On 05/19/2016 04:38 PM, Rafael J. Wysocki wrote:
> > On Fri, May 13, 2016 at 8:03 PM, Grygorii Strashko
> >  wrote:
> >> The PM runtime will be left disabled for the device if its .suspend_late()
> >> callback fails and async suspend is not allowed for this device. In
> >> this case device will not be added in dpm_late_early_list and
> >> dpm_resume_early() will ignore this device, as result PM runtime will
> >> be disabled for it forever (side effect: after 8 subsequent failures
> >> for the same device the PM runtime will be reenabled due to
> >> disable_depth overflow).
> >>
> >> Hence, re-enable PM runtime in __device_suspend_late() if
> >> .suspend_late() callback fails and async suspend is not allowed for
> >> this device.
> >>
> >> Signed-off-by: Grygorii Strashko 
> >> ---
> >>   drivers/base/power/main.c | 7 +--
> >>   1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> index 6e7c3cc..9b266e5 100644
> >> --- a/drivers/base/power/main.c
> >> +++ b/drivers/base/power/main.c
> >> @@ -1207,10 +1207,13 @@ static int __device_suspend_late(struct device 
> >> *dev, pm_message_t state, bool as
> >>  }
> >>
> >>  error = dpm_run_callback(callback, dev, state, info);
> >> -   if (!error)
> >> +   if (!error) {
> >>  dev->power.is_late_suspended = true;
> >> -   else
> >> +   } else {
>   Point [1]
> >>  async_error = error;
> >> +   if (!is_async(dev))
> > 
> > Why is the is_async() check necessary here?
>   
> A: deviceX is suspended *async* and reached point [1], in this case:
> - deviceX has been added in dpm_late_early_list already
> - dpm_suspend_late() will detect async_error and call dpm_resume_early()
> - dpm_resume_early() will call device_resume_early() for deviceX
> - device_resume_early() will re-enable PM runtime
> {
> ...
>   if (!dev->power.is_late_suspended)
>   goto Out;
> 
>   ...
>  Out:
>   TRACE_RESUME(error);
> 
>   pm_runtime_enable(dev);
> 
>   complete_all(>power.completion);
>   return error;
> } 
>   
> 
> B: deviceX is suspended *sync* and reached point [1], in this case:
> - deviceX has not been added in dpm_late_early_list yet
> - dpm_suspend_late() will detect sync_error and call dpm_resume_early()
> - dpm_resume_early() will ignore deviceX
> 
> if i'll not check for !is_async(dev) then pm_runtime_enable(dev)
> will be called twice for deviceX with this patch.

OK, thanks!

So to me, the problem is that we handle failures in that code inconsistently
depending on whether or not async suspend/resume is enabled for the device.

I'd rather make it consistent than add extra checks to it, so the patch below
is how I would fix this.

---
From: Rafael J. Wysocki 
Subject: [PATCH] PM / sleep: Handle failures in device_suspend_late() 
consistently

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/main.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -1267,14 +1267,15 @@ int dpm_suspend_late(pm_message_t state)
error = device_suspend_late(dev);
 
mutex_lock(_list_mtx);
+   if (!list_empty(>power.entry))
+   list_move(>power.entry, _late_early_list);
+
if (error) {
pm_dev_err(dev, state, " late", error);
dpm_save_failed_dev(dev_name(dev));
put_device(dev);
break;
}
-   if (!list_empty(>power.entry))
-   list_move(>power.entry, _late_early_list);
put_device(dev);
 
if (async_error)



[PATCH V6 2/3] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()

2016-05-20 Thread Laxman Dewangan
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Jon Hunter 

---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.

Changes from V2:
- Make unsigned long to u32 for some missed variable from V1.

Changes from V3:
- Revert back the value to ulong where time calcualtion is done.

Changes from V4:
- Collected RB from Jon.

Changes from V4:
- None
---
 drivers/soc/tegra/pmc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 2c3f1f9..09c2b97 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -875,10 +875,10 @@ static int tegra_io_rail_prepare(unsigned int id, 
unsigned long *request,
return 0;
 }
 
-static int tegra_io_rail_poll(unsigned long offset, unsigned long mask,
- unsigned long val, unsigned long timeout)
+static int tegra_io_rail_poll(unsigned long offset, u32 mask,
+ u32 val, unsigned long timeout)
 {
-   unsigned long value;
+   u32 value;
 
timeout = jiffies + msecs_to_jiffies(timeout);
 
@@ -900,8 +900,9 @@ static void tegra_io_rail_unprepare(void)
 
 int tegra_io_rail_power_on(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;
 
mutex_lock(>powergates_lock);
@@ -935,8 +936,9 @@ EXPORT_SYMBOL(tegra_io_rail_power_on);
 
 int tegra_io_rail_power_off(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;
 
mutex_lock(>powergates_lock);
-- 
2.1.4



[PATCH V6 2/3] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()

2016-05-20 Thread Laxman Dewangan
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Jon Hunter 

---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.

Changes from V2:
- Make unsigned long to u32 for some missed variable from V1.

Changes from V3:
- Revert back the value to ulong where time calcualtion is done.

Changes from V4:
- Collected RB from Jon.

Changes from V4:
- None
---
 drivers/soc/tegra/pmc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 2c3f1f9..09c2b97 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -875,10 +875,10 @@ static int tegra_io_rail_prepare(unsigned int id, 
unsigned long *request,
return 0;
 }
 
-static int tegra_io_rail_poll(unsigned long offset, unsigned long mask,
- unsigned long val, unsigned long timeout)
+static int tegra_io_rail_poll(unsigned long offset, u32 mask,
+ u32 val, unsigned long timeout)
 {
-   unsigned long value;
+   u32 value;
 
timeout = jiffies + msecs_to_jiffies(timeout);
 
@@ -900,8 +900,9 @@ static void tegra_io_rail_unprepare(void)
 
 int tegra_io_rail_power_on(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;
 
mutex_lock(>powergates_lock);
@@ -935,8 +936,9 @@ EXPORT_SYMBOL(tegra_io_rail_power_on);
 
 int tegra_io_rail_power_off(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;
 
mutex_lock(>powergates_lock);
-- 
2.1.4



[PATCH V6 0/3] soc/tegra: Add support for IO pads power and voltage control

2016-05-20 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO interface
like setting voltage signal levels and power state of the interface. The 
group is generally referred as IO pads. The power state and voltage control
of IO pins can be done at IO pads level.

Tegra124 onwards IO pads support the power down state when system is
active. The voltage levels on IO pads are auto detected on Tegra124/
Tegra132 but it is not in Tegra210. For Tegra210, the SW need to
explicitly configure the voltage levels of IO pads

This series add the interface for the IO pad power state and voltage
configurations. Modifies the client to use new APIs.
Register the child devices to provide the client interface to configure
IO pads power state and voltage from Device tree.

---
Changes from V2: 
- Drop the pinctrl driver from series till pmc interfce is finalise.
- Move client to use the new APIs.
- Remove older APIs to configure IO rail and related macros.

Changes from V3: 
- keep value  to be unsigned long in the dpd_prepare.
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.
- Drop patch of adding sub devs

Changes from V4:
- Change IO_PAD to IO_PADS.
- Change enum for voltage config 

Changes from V5:
- FIx multiline comment.
- Use -EINVAL instead of -1 for nonsupported case and refactor APIs to
  convert io-pads to bit.

Laxman Dewangan (3):
  soc/tegra: pmc: Use BIT macro for register field definition
  soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
  soc/tegra: pmc: Add support for IO pads power state and voltage

 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 273 +++-
 include/soc/tegra/pmc.h | 132 +++--
 3 files changed, 321 insertions(+), 92 deletions(-)

-- 
2.1.4



[PATCH V6 0/3] soc/tegra: Add support for IO pads power and voltage control

2016-05-20 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO interface
like setting voltage signal levels and power state of the interface. The 
group is generally referred as IO pads. The power state and voltage control
of IO pins can be done at IO pads level.

Tegra124 onwards IO pads support the power down state when system is
active. The voltage levels on IO pads are auto detected on Tegra124/
Tegra132 but it is not in Tegra210. For Tegra210, the SW need to
explicitly configure the voltage levels of IO pads

This series add the interface for the IO pad power state and voltage
configurations. Modifies the client to use new APIs.
Register the child devices to provide the client interface to configure
IO pads power state and voltage from Device tree.

---
Changes from V2: 
- Drop the pinctrl driver from series till pmc interfce is finalise.
- Move client to use the new APIs.
- Remove older APIs to configure IO rail and related macros.

Changes from V3: 
- keep value  to be unsigned long in the dpd_prepare.
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.
- Drop patch of adding sub devs

Changes from V4:
- Change IO_PAD to IO_PADS.
- Change enum for voltage config 

Changes from V5:
- FIx multiline comment.
- Use -EINVAL instead of -1 for nonsupported case and refactor APIs to
  convert io-pads to bit.

Laxman Dewangan (3):
  soc/tegra: pmc: Use BIT macro for register field definition
  soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
  soc/tegra: pmc: Add support for IO pads power state and voltage

 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 273 +++-
 include/soc/tegra/pmc.h | 132 +++--
 3 files changed, 321 insertions(+), 92 deletions(-)

-- 
2.1.4



[PATCH V6 1/3] soc/tegra: pmc: Use BIT macro for register field definition

2016-05-20 Thread Laxman Dewangan
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)

Signed-off-by: Laxman Dewangan 
Acked-by: Jon Hunter 

---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None

Changes from V3:
- None

Changes from V4:
- Collected ack from Jon.

Changes from V3:
- None
---
 drivers/soc/tegra/pmc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb17345..2c3f1f9 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -45,28 +45,28 @@
 #include 
 
 #define PMC_CNTRL  0x0
-#define  PMC_CNTRL_SYSCLK_POLARITY (1 << 10)  /* sys clk polarity */
-#define  PMC_CNTRL_SYSCLK_OE   (1 << 11)  /* system clock enable */
-#define  PMC_CNTRL_SIDE_EFFECT_LP0 (1 << 14)  /* LP0 when CPU pwr gated */
-#define  PMC_CNTRL_CPU_PWRREQ_POLARITY (1 << 15)  /* CPU pwr req polarity */
-#define  PMC_CNTRL_CPU_PWRREQ_OE   (1 << 16)  /* CPU pwr req enable */
-#define  PMC_CNTRL_INTR_POLARITY   (1 << 17)  /* inverts INTR polarity */
+#define PMC_CNTRL_SYSCLK_POLARITY  BIT(10) /* sys clk polarity */
+#define PMC_CNTRL_SYSCLK_OEBIT(11) /* system clock enable */
+#define PMC_CNTRL_SIDE_EFFECT_LP0  BIT(14) /* LP0 when CPU pwr gated */
+#define PMC_CNTRL_CPU_PWRREQ_POLARITY  BIT(15) /* CPU pwr req polarity */
+#define PMC_CNTRL_CPU_PWRREQ_OEBIT(16) /* CPU pwr req enable */
+#define PMC_CNTRL_INTR_POLARITYBIT(17)/* inverts INTR polarity 
*/
 
 #define DPD_SAMPLE 0x020
-#define  DPD_SAMPLE_ENABLE (1 << 0)
-#define  DPD_SAMPLE_DISABLE(0 << 0)
+#define DPD_SAMPLE_ENABLE  BIT(0)
+#define DPD_SAMPLE_DISABLE (0 << 0)
 
 #define PWRGATE_TOGGLE 0x30
-#define  PWRGATE_TOGGLE_START  (1 << 8)
+#define PWRGATE_TOGGLE_START   BIT(8)
 
 #define REMOVE_CLAMPING0x34
 
 #define PWRGATE_STATUS 0x38
 
 #define PMC_SCRATCH0   0x50
-#define  PMC_SCRATCH0_MODE_RECOVERY(1 << 31)
-#define  PMC_SCRATCH0_MODE_BOOTLOADER  (1 << 30)
-#define  PMC_SCRATCH0_MODE_RCM (1 << 1)
+#define PMC_SCRATCH0_MODE_RECOVERY BIT(31)
+#define PMC_SCRATCH0_MODE_BOOTLOADER   BIT(30)
+#define PMC_SCRATCH0_MODE_RCM  BIT(1)
 #define  PMC_SCRATCH0_MODE_MASK(PMC_SCRATCH0_MODE_RECOVERY | \
 PMC_SCRATCH0_MODE_BOOTLOADER | \
 PMC_SCRATCH0_MODE_RCM)
@@ -77,14 +77,14 @@
 #define PMC_SCRATCH41  0x140
 
 #define PMC_SENSOR_CTRL0x1b0
-#define PMC_SENSOR_CTRL_SCRATCH_WRITE  (1 << 2)
-#define PMC_SENSOR_CTRL_ENABLE_RST (1 << 1)
+#define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
+#define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
 
 #define IO_DPD_REQ 0x1b8
-#define  IO_DPD_REQ_CODE_IDLE  (0 << 30)
-#define  IO_DPD_REQ_CODE_OFF   (1 << 30)
-#define  IO_DPD_REQ_CODE_ON(2 << 30)
-#define  IO_DPD_REQ_CODE_MASK  (3 << 30)
+#define IO_DPD_REQ_CODE_IDLE   (0 << 30)
+#define IO_DPD_REQ_CODE_OFF(1U << 30)
+#define IO_DPD_REQ_CODE_ON (2U << 30)
+#define IO_DPD_REQ_CODE_MASK   (3U << 30)
 
 #define IO_DPD_STATUS  0x1bc
 #define IO_DPD2_REQ0x1c0
@@ -96,10 +96,10 @@
 #define PMC_SCRATCH54_ADDR_SHIFT   0
 
 #define PMC_SCRATCH55  0x25c
-#define PMC_SCRATCH55_RESET_TEGRA  (1 << 31)
+#define PMC_SCRATCH55_RESET_TEGRA  BIT(31)
 #define PMC_SCRATCH55_CNTRL_ID_SHIFT   27
 #define PMC_SCRATCH55_PINMUX_SHIFT 24
-#define PMC_SCRATCH55_16BITOP  (1 << 15)
+#define PMC_SCRATCH55_16BITOP  BIT(15)
 #define PMC_SCRATCH55_CHECKSUM_SHIFT   16
 #define PMC_SCRATCH55_I2CSLV1_SHIFT0
 
-- 
2.1.4



[PATCH V6 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

2016-05-20 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO
interface like setting voltage signal levels and power state of
the interface. The group is generally referred as IO pads. The
power state and voltage control of IO pins can be done at IO pads
level.

Tegra generation SoC supports the power down of IO pads when it
is not used even in the active state of system. This saves power
from that IO interface. Also it supports multiple voltage level
in IO pins for interfacing on some of pads. The IO pad voltage is
automatically detected till T124, hence SW need not to configure
this. But from T210, the automatically detection logic has been
removed, hence SW need to explicitly set the IO pad voltage into
IO pad configuration registers.

Add support to set the power states and voltage level of the IO pads
from client driver. The implementation for the APIs are in generic
which is applicable for all generation os Tegra SoC.

IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
driver is modified to use the new APIs.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage control APIs in single call.

Changes from V2:
- Remove the tegra_io_rail_power_off/on() apis and change client (sor) driver
to use the new APIs for IO pad power.
- Remove the TEGRA_IO_RAIL_ macros.

Changes from V3:
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.

Changes from V4:
- IO_PAD->IO_PADS
- TEGRA_IO_PADS_POWER_SOURCE_ -> TEGRA_IO_PADS_VCONF_

Changes from V5:
- Fix comment style to multi-line format.
- Use -EINVAL instead of -1 to refactor some of function as suggested by Jon.
---
 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 221 ++--
 include/soc/tegra/pmc.h | 133 ++
 3 files changed, 295 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 757c6e8..3ce547a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1134,7 +1134,7 @@ static void tegra_sor_edp_disable(struct drm_encoder 
*encoder)
dev_err(sor->dev, "failed to disable DP: %d\n", err);
}
 
-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power off I/O rail: %d\n", err);
 
@@ -1296,7 +1296,7 @@ static void tegra_sor_edp_enable(struct drm_encoder 
*encoder)
tegra_sor_writel(sor, value, SOR_DP_PADCTL0);
 
/* step 2 */
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power on I/O rail: %d\n", err);
 
@@ -1748,7 +1748,7 @@ static void tegra_sor_hdmi_disable(struct drm_encoder 
*encoder)
if (err < 0)
dev_err(sor->dev, "failed to power down SOR: %d\n", err);
 
-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power off HDMI rail: %d\n", err);
 
@@ -1787,7 +1787,7 @@ static void tegra_sor_hdmi_enable(struct drm_encoder 
*encoder)
 
div = clk_get_rate(sor->clk) / 100 * 4;
 
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power on HDMI rail: %d\n", err);
 
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 09c2b97..eb51a09 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -76,6 +76,10 @@
 
 #define PMC_SCRATCH41  0x140
 
+/* Power detect for pad voltage */
+#define PMC_PWR_DET0x48
+#define PMC_PWR_DET_VAL0xe4
+
 #define PMC_SENSOR_CTRL0x1b0
 #define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
 #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
@@ -105,6 +109,15 @@
 
 #define GPU_RG_CNTRL   0x2d4
 
+/*
+ * Define the IO_PADS SOC for SOC mask to find out that IO pads supported
+ * or not in given SoC.
+ */
+#define TEGRA_IO_PADS_T124 0x1
+#define TEGRA_IO_PADS_T210 0x2
+#define TEGRA_IO_PADS_T124_T210(TEGRA_IO_PADS_T124 |   \
+   TEGRA_IO_PADS_T210)
+
 struct tegra_powergate {
struct generic_pm_domain genpd;
struct tegra_pmc *pmc;
@@ -115,12 

[PATCH V6 1/3] soc/tegra: pmc: Use BIT macro for register field definition

2016-05-20 Thread Laxman Dewangan
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)

Signed-off-by: Laxman Dewangan 
Acked-by: Jon Hunter 

---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None

Changes from V3:
- None

Changes from V4:
- Collected ack from Jon.

Changes from V3:
- None
---
 drivers/soc/tegra/pmc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb17345..2c3f1f9 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -45,28 +45,28 @@
 #include 
 
 #define PMC_CNTRL  0x0
-#define  PMC_CNTRL_SYSCLK_POLARITY (1 << 10)  /* sys clk polarity */
-#define  PMC_CNTRL_SYSCLK_OE   (1 << 11)  /* system clock enable */
-#define  PMC_CNTRL_SIDE_EFFECT_LP0 (1 << 14)  /* LP0 when CPU pwr gated */
-#define  PMC_CNTRL_CPU_PWRREQ_POLARITY (1 << 15)  /* CPU pwr req polarity */
-#define  PMC_CNTRL_CPU_PWRREQ_OE   (1 << 16)  /* CPU pwr req enable */
-#define  PMC_CNTRL_INTR_POLARITY   (1 << 17)  /* inverts INTR polarity */
+#define PMC_CNTRL_SYSCLK_POLARITY  BIT(10) /* sys clk polarity */
+#define PMC_CNTRL_SYSCLK_OEBIT(11) /* system clock enable */
+#define PMC_CNTRL_SIDE_EFFECT_LP0  BIT(14) /* LP0 when CPU pwr gated */
+#define PMC_CNTRL_CPU_PWRREQ_POLARITY  BIT(15) /* CPU pwr req polarity */
+#define PMC_CNTRL_CPU_PWRREQ_OEBIT(16) /* CPU pwr req enable */
+#define PMC_CNTRL_INTR_POLARITYBIT(17)/* inverts INTR polarity 
*/
 
 #define DPD_SAMPLE 0x020
-#define  DPD_SAMPLE_ENABLE (1 << 0)
-#define  DPD_SAMPLE_DISABLE(0 << 0)
+#define DPD_SAMPLE_ENABLE  BIT(0)
+#define DPD_SAMPLE_DISABLE (0 << 0)
 
 #define PWRGATE_TOGGLE 0x30
-#define  PWRGATE_TOGGLE_START  (1 << 8)
+#define PWRGATE_TOGGLE_START   BIT(8)
 
 #define REMOVE_CLAMPING0x34
 
 #define PWRGATE_STATUS 0x38
 
 #define PMC_SCRATCH0   0x50
-#define  PMC_SCRATCH0_MODE_RECOVERY(1 << 31)
-#define  PMC_SCRATCH0_MODE_BOOTLOADER  (1 << 30)
-#define  PMC_SCRATCH0_MODE_RCM (1 << 1)
+#define PMC_SCRATCH0_MODE_RECOVERY BIT(31)
+#define PMC_SCRATCH0_MODE_BOOTLOADER   BIT(30)
+#define PMC_SCRATCH0_MODE_RCM  BIT(1)
 #define  PMC_SCRATCH0_MODE_MASK(PMC_SCRATCH0_MODE_RECOVERY | \
 PMC_SCRATCH0_MODE_BOOTLOADER | \
 PMC_SCRATCH0_MODE_RCM)
@@ -77,14 +77,14 @@
 #define PMC_SCRATCH41  0x140
 
 #define PMC_SENSOR_CTRL0x1b0
-#define PMC_SENSOR_CTRL_SCRATCH_WRITE  (1 << 2)
-#define PMC_SENSOR_CTRL_ENABLE_RST (1 << 1)
+#define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
+#define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
 
 #define IO_DPD_REQ 0x1b8
-#define  IO_DPD_REQ_CODE_IDLE  (0 << 30)
-#define  IO_DPD_REQ_CODE_OFF   (1 << 30)
-#define  IO_DPD_REQ_CODE_ON(2 << 30)
-#define  IO_DPD_REQ_CODE_MASK  (3 << 30)
+#define IO_DPD_REQ_CODE_IDLE   (0 << 30)
+#define IO_DPD_REQ_CODE_OFF(1U << 30)
+#define IO_DPD_REQ_CODE_ON (2U << 30)
+#define IO_DPD_REQ_CODE_MASK   (3U << 30)
 
 #define IO_DPD_STATUS  0x1bc
 #define IO_DPD2_REQ0x1c0
@@ -96,10 +96,10 @@
 #define PMC_SCRATCH54_ADDR_SHIFT   0
 
 #define PMC_SCRATCH55  0x25c
-#define PMC_SCRATCH55_RESET_TEGRA  (1 << 31)
+#define PMC_SCRATCH55_RESET_TEGRA  BIT(31)
 #define PMC_SCRATCH55_CNTRL_ID_SHIFT   27
 #define PMC_SCRATCH55_PINMUX_SHIFT 24
-#define PMC_SCRATCH55_16BITOP  (1 << 15)
+#define PMC_SCRATCH55_16BITOP  BIT(15)
 #define PMC_SCRATCH55_CHECKSUM_SHIFT   16
 #define PMC_SCRATCH55_I2CSLV1_SHIFT0
 
-- 
2.1.4



[PATCH V6 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

2016-05-20 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO
interface like setting voltage signal levels and power state of
the interface. The group is generally referred as IO pads. The
power state and voltage control of IO pins can be done at IO pads
level.

Tegra generation SoC supports the power down of IO pads when it
is not used even in the active state of system. This saves power
from that IO interface. Also it supports multiple voltage level
in IO pins for interfacing on some of pads. The IO pad voltage is
automatically detected till T124, hence SW need not to configure
this. But from T210, the automatically detection logic has been
removed, hence SW need to explicitly set the IO pad voltage into
IO pad configuration registers.

Add support to set the power states and voltage level of the IO pads
from client driver. The implementation for the APIs are in generic
which is applicable for all generation os Tegra SoC.

IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
driver is modified to use the new APIs.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage control APIs in single call.

Changes from V2:
- Remove the tegra_io_rail_power_off/on() apis and change client (sor) driver
to use the new APIs for IO pad power.
- Remove the TEGRA_IO_RAIL_ macros.

Changes from V3:
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.

Changes from V4:
- IO_PAD->IO_PADS
- TEGRA_IO_PADS_POWER_SOURCE_ -> TEGRA_IO_PADS_VCONF_

Changes from V5:
- Fix comment style to multi-line format.
- Use -EINVAL instead of -1 to refactor some of function as suggested by Jon.
---
 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 221 ++--
 include/soc/tegra/pmc.h | 133 ++
 3 files changed, 295 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 757c6e8..3ce547a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1134,7 +1134,7 @@ static void tegra_sor_edp_disable(struct drm_encoder 
*encoder)
dev_err(sor->dev, "failed to disable DP: %d\n", err);
}
 
-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power off I/O rail: %d\n", err);
 
@@ -1296,7 +1296,7 @@ static void tegra_sor_edp_enable(struct drm_encoder 
*encoder)
tegra_sor_writel(sor, value, SOR_DP_PADCTL0);
 
/* step 2 */
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power on I/O rail: %d\n", err);
 
@@ -1748,7 +1748,7 @@ static void tegra_sor_hdmi_disable(struct drm_encoder 
*encoder)
if (err < 0)
dev_err(sor->dev, "failed to power down SOR: %d\n", err);
 
-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power off HDMI rail: %d\n", err);
 
@@ -1787,7 +1787,7 @@ static void tegra_sor_hdmi_enable(struct drm_encoder 
*encoder)
 
div = clk_get_rate(sor->clk) / 100 * 4;
 
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power on HDMI rail: %d\n", err);
 
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 09c2b97..eb51a09 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -76,6 +76,10 @@
 
 #define PMC_SCRATCH41  0x140
 
+/* Power detect for pad voltage */
+#define PMC_PWR_DET0x48
+#define PMC_PWR_DET_VAL0xe4
+
 #define PMC_SENSOR_CTRL0x1b0
 #define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
 #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
@@ -105,6 +109,15 @@
 
 #define GPU_RG_CNTRL   0x2d4
 
+/*
+ * Define the IO_PADS SOC for SOC mask to find out that IO pads supported
+ * or not in given SoC.
+ */
+#define TEGRA_IO_PADS_T124 0x1
+#define TEGRA_IO_PADS_T210 0x2
+#define TEGRA_IO_PADS_T124_T210(TEGRA_IO_PADS_T124 |   \
+   TEGRA_IO_PADS_T210)
+
 struct tegra_powergate {
struct generic_pm_domain genpd;
struct tegra_pmc *pmc;
@@ -115,12 +128,23 @@ struct 

Re: [PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

2016-05-20 Thread Heiko Schocher

Hello Fabio,

Am 20.05.2016 um 13:40 schrieb Fabio Estevam:

Hi Heiko,

On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher  wrote:

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher 

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.


Philipp sent the following patch that fixes the issue:
http://www.spinics.net/lists/dri-devel/msg107524.html


Thanks for the hint! This patch fixes the issue see log:
http://xeidos.ddns.net/buildbot/builders/ari_lx/builds/0/steps/shell/logs/tbotlog

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

2016-05-20 Thread Heiko Schocher

Hello Fabio,

Am 20.05.2016 um 13:40 schrieb Fabio Estevam:

Hi Heiko,

On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher  wrote:

commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
breaks the aristainetos2 board with the "lg,lg4573" panel.

This reverts the above commit.

Signed-off-by: Heiko Schocher 

---
Any hint, how to bring back the display on the aristainetos2
board without reverting this commit would be appreciated.


Philipp sent the following patch that fixes the issue:
http://www.spinics.net/lists/dri-devel/msg107524.html


Thanks for the hint! This patch fixes the issue see log:
http://xeidos.ddns.net/buildbot/builders/ari_lx/builds/0/steps/shell/logs/tbotlog

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH v2] cpufreq: stats: Walk online CPUs with CPU offline/online locked

2016-05-20 Thread Rafael J. Wysocki
On Friday, May 20, 2016 07:52:47 AM Viresh Kumar wrote:
> On 20-05-16, 03:41, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Loops over online CPUs in cpufreq_stats_init() and cpufreq_stats_exit()
> > should be carried out with CPU offline/online locked or races are
> > possible otherwise, so make that happen.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > v1 -> v2: On a second thought, add the policy notifier in 
> > cpufreq_stats_init()
> >   with CPU offline/online locked too.
> > 
> > ---
> >  drivers/cpufreq/cpufreq_stats.c |   16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> > 
> > Index: linux-pm/drivers/cpufreq/cpufreq_stats.c
> > ===
> > --- linux-pm.orig/drivers/cpufreq/cpufreq_stats.c
> > +++ linux-pm/drivers/cpufreq/cpufreq_stats.c
> > @@ -317,10 +317,13 @@ static int __init cpufreq_stats_init(voi
> > unsigned int cpu;
> >  
> > spin_lock_init(_stats_lock);
> > +
> > +   get_online_cpus();
> > +
> > ret = cpufreq_register_notifier(_policy_block,
> > CPUFREQ_POLICY_NOTIFIER);
> 
> Why is this required to be protected ?

Last night I thought I saw a scenario in which that notifier could run
in parallel with the loop below even with get_online_cpus() between them,
but I don't see it right now.

Maybe I should not look at stuff late in the night ...

> > if (ret)
> > -   return ret;
> > +   goto out;
> >  
> > for_each_online_cpu(cpu)
> > cpufreq_stats_create_table(cpu);
> > @@ -332,21 +335,28 @@ static int __init cpufreq_stats_init(voi
> > CPUFREQ_POLICY_NOTIFIER);
> > for_each_online_cpu(cpu)
> > cpufreq_stats_free_table(cpu);
> 
> Maybe we can make this for_each_possible_cpu() then, and so getting a
> policy will fail for CPUs which aren't online.
> 
> And we wouldn't need to use get_online_cpus() then ?

That could be done, but then there would be nothing to prevent the
policy notifier from running in parallel with the loop.

Something like the patch below should do the trick, though.

---
From: Rafael J. Wysocki 
Subject: [PATCH] cpufreq: stats: Fix race conditions on init and cleanup

Loops over online CPUs in cpufreq_stats_init() and cpufreq_stats_exit()
are not carried out with CPU offline/online locked, so races are
possible with respect to policy initialization and cleanup.

To prevent that from happening, change the loops to walk all possible
CPUs, as cpufreq_stats_create_table() and cpufreq_stats_free_table()
handle the case when there's no policy for the given CPU cleanly,
but also use policy->rwsem in there to prevent those routines
from racing with the policy notifier.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_stats.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_stats.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_stats.c
+++ linux-pm/drivers/cpufreq/cpufreq_stats.c
@@ -154,7 +154,9 @@ static void cpufreq_stats_free_table(uns
if (!policy)
return;
 
+   down_write(>rwsem);
__cpufreq_stats_free_table(policy);
+   up_write(>rwsem);
 
cpufreq_cpu_put(policy);
 }
@@ -238,7 +240,9 @@ static void cpufreq_stats_create_table(u
if (likely(!policy))
return;
 
+   down_write(>rwsem);
__cpufreq_stats_create_table(policy);
+   up_write(>rwsem);
 
cpufreq_cpu_put(policy);
 }
@@ -322,7 +326,7 @@ static int __init cpufreq_stats_init(voi
if (ret)
return ret;
 
-   for_each_online_cpu(cpu)
+   for_each_possible_cpu(cpu)
cpufreq_stats_create_table(cpu);
 
ret = cpufreq_register_notifier(_trans_block,
@@ -330,12 +334,11 @@ static int __init cpufreq_stats_init(voi
if (ret) {
cpufreq_unregister_notifier(_policy_block,
CPUFREQ_POLICY_NOTIFIER);
-   for_each_online_cpu(cpu)
+   for_each_possible_cpu(cpu)
cpufreq_stats_free_table(cpu);
-   return ret;
}
 
-   return 0;
+   return ret;
 }
 static void __exit cpufreq_stats_exit(void)
 {
@@ -345,7 +348,8 @@ static void __exit cpufreq_stats_exit(vo
CPUFREQ_POLICY_NOTIFIER);
cpufreq_unregister_notifier(_trans_block,
CPUFREQ_TRANSITION_NOTIFIER);
-   for_each_online_cpu(cpu)
+
+   for_each_possible_cpu(cpu)
cpufreq_stats_free_table(cpu);
 }
 



Re: [PATCH v2] cpufreq: stats: Walk online CPUs with CPU offline/online locked

2016-05-20 Thread Rafael J. Wysocki
On Friday, May 20, 2016 07:52:47 AM Viresh Kumar wrote:
> On 20-05-16, 03:41, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Loops over online CPUs in cpufreq_stats_init() and cpufreq_stats_exit()
> > should be carried out with CPU offline/online locked or races are
> > possible otherwise, so make that happen.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > v1 -> v2: On a second thought, add the policy notifier in 
> > cpufreq_stats_init()
> >   with CPU offline/online locked too.
> > 
> > ---
> >  drivers/cpufreq/cpufreq_stats.c |   16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> > 
> > Index: linux-pm/drivers/cpufreq/cpufreq_stats.c
> > ===
> > --- linux-pm.orig/drivers/cpufreq/cpufreq_stats.c
> > +++ linux-pm/drivers/cpufreq/cpufreq_stats.c
> > @@ -317,10 +317,13 @@ static int __init cpufreq_stats_init(voi
> > unsigned int cpu;
> >  
> > spin_lock_init(_stats_lock);
> > +
> > +   get_online_cpus();
> > +
> > ret = cpufreq_register_notifier(_policy_block,
> > CPUFREQ_POLICY_NOTIFIER);
> 
> Why is this required to be protected ?

Last night I thought I saw a scenario in which that notifier could run
in parallel with the loop below even with get_online_cpus() between them,
but I don't see it right now.

Maybe I should not look at stuff late in the night ...

> > if (ret)
> > -   return ret;
> > +   goto out;
> >  
> > for_each_online_cpu(cpu)
> > cpufreq_stats_create_table(cpu);
> > @@ -332,21 +335,28 @@ static int __init cpufreq_stats_init(voi
> > CPUFREQ_POLICY_NOTIFIER);
> > for_each_online_cpu(cpu)
> > cpufreq_stats_free_table(cpu);
> 
> Maybe we can make this for_each_possible_cpu() then, and so getting a
> policy will fail for CPUs which aren't online.
> 
> And we wouldn't need to use get_online_cpus() then ?

That could be done, but then there would be nothing to prevent the
policy notifier from running in parallel with the loop.

Something like the patch below should do the trick, though.

---
From: Rafael J. Wysocki 
Subject: [PATCH] cpufreq: stats: Fix race conditions on init and cleanup

Loops over online CPUs in cpufreq_stats_init() and cpufreq_stats_exit()
are not carried out with CPU offline/online locked, so races are
possible with respect to policy initialization and cleanup.

To prevent that from happening, change the loops to walk all possible
CPUs, as cpufreq_stats_create_table() and cpufreq_stats_free_table()
handle the case when there's no policy for the given CPU cleanly,
but also use policy->rwsem in there to prevent those routines
from racing with the policy notifier.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_stats.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_stats.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_stats.c
+++ linux-pm/drivers/cpufreq/cpufreq_stats.c
@@ -154,7 +154,9 @@ static void cpufreq_stats_free_table(uns
if (!policy)
return;
 
+   down_write(>rwsem);
__cpufreq_stats_free_table(policy);
+   up_write(>rwsem);
 
cpufreq_cpu_put(policy);
 }
@@ -238,7 +240,9 @@ static void cpufreq_stats_create_table(u
if (likely(!policy))
return;
 
+   down_write(>rwsem);
__cpufreq_stats_create_table(policy);
+   up_write(>rwsem);
 
cpufreq_cpu_put(policy);
 }
@@ -322,7 +326,7 @@ static int __init cpufreq_stats_init(voi
if (ret)
return ret;
 
-   for_each_online_cpu(cpu)
+   for_each_possible_cpu(cpu)
cpufreq_stats_create_table(cpu);
 
ret = cpufreq_register_notifier(_trans_block,
@@ -330,12 +334,11 @@ static int __init cpufreq_stats_init(voi
if (ret) {
cpufreq_unregister_notifier(_policy_block,
CPUFREQ_POLICY_NOTIFIER);
-   for_each_online_cpu(cpu)
+   for_each_possible_cpu(cpu)
cpufreq_stats_free_table(cpu);
-   return ret;
}
 
-   return 0;
+   return ret;
 }
 static void __exit cpufreq_stats_exit(void)
 {
@@ -345,7 +348,8 @@ static void __exit cpufreq_stats_exit(vo
CPUFREQ_POLICY_NOTIFIER);
cpufreq_unregister_notifier(_trans_block,
CPUFREQ_TRANSITION_NOTIFIER);
-   for_each_online_cpu(cpu)
+
+   for_each_possible_cpu(cpu)
cpufreq_stats_free_table(cpu);
 }
 



[PATCH v3] i2c: at91: change log when dma configuration fails

2016-05-20 Thread Ludovic Desroches
When the DMA configuration fails, there is a log reporting that we can't
use DMA and indicating the error number. When booting the kernel, it is
annoying to see this error number. Moreover, people can think something
is going wrong. It is not the case, it means that DMA can't be used but
it doesn't prevent to use i2c.

Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/i2c-at91.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Douglas, sorry but I can't answer you directly, your email address is
blacklisted on our server.

Changes:
- v3:
  - s/request/get (comment done in private)
- v2:
  - remove ret parameter

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 921d32b..f233726 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1013,7 +1013,7 @@ static int at91_twi_configure_dma(struct at91_twi_dev 
*dev, u32 phy_addr)
 
 error:
if (ret != -EPROBE_DEFER)
-   dev_info(dev->dev, "can't use DMA, error %d\n", ret);
+   dev_info(dev->dev, "can't get DMA channel, continue without DMA 
support\n");
if (dma->chan_rx)
dma_release_channel(dma->chan_rx);
if (dma->chan_tx)
-- 
2.5.0



[PATCH v3] i2c: at91: change log when dma configuration fails

2016-05-20 Thread Ludovic Desroches
When the DMA configuration fails, there is a log reporting that we can't
use DMA and indicating the error number. When booting the kernel, it is
annoying to see this error number. Moreover, people can think something
is going wrong. It is not the case, it means that DMA can't be used but
it doesn't prevent to use i2c.

Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/i2c-at91.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Douglas, sorry but I can't answer you directly, your email address is
blacklisted on our server.

Changes:
- v3:
  - s/request/get (comment done in private)
- v2:
  - remove ret parameter

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 921d32b..f233726 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1013,7 +1013,7 @@ static int at91_twi_configure_dma(struct at91_twi_dev 
*dev, u32 phy_addr)
 
 error:
if (ret != -EPROBE_DEFER)
-   dev_info(dev->dev, "can't use DMA, error %d\n", ret);
+   dev_info(dev->dev, "can't get DMA channel, continue without DMA 
support\n");
if (dma->chan_rx)
dma_release_channel(dma->chan_rx);
if (dma->chan_tx)
-- 
2.5.0



Re: [GIT PULL 0/7] ARM: SoC changes for 4.7

2016-05-20 Thread Arnd Bergmann
On Thursday 19 May 2016 11:02:56 Rob Herring wrote:
> I happen have a script... (I run it every time people complain about DT).
> 
> Here's the diffstat of mach-* and plat-* since merging DT support:
> 
> v3.0: 833 files changed, 10945 insertions(+), 37476 deletions(-)
> v3.1: 955 files changed, 17796 insertions(+), 20300 deletions(-)
> v3.2: 1507 files changed, 32960 insertions(+), 33392 deletions(-)
> v3.3: 1301 files changed, 27725 insertions(+), 18941 deletions(-)
> v3.4: 1324 files changed, 27079 insertions(+), 21500 deletions(-)
> v3.5: 975 files changed, 32340 insertions(+), 46663 deletions(-)
> v3.6: 648 files changed, 16121 insertions(+), 13161 deletions(-)
> v3.7: 1389 files changed, 23739 insertions(+), 61097 deletions(-)
> v3.8: 1066 files changed, 32812 insertions(+), 40821 deletions(-)
> v3.9: 1031 files changed, 10051 insertions(+), 33399 deletions(-)
> v3.10: 831 files changed, 15049 insertions(+), 27333 deletions(-)
> v3.11: 675 files changed, 18519 insertions(+), 30012 deletions(-)
> v3.12: 474 files changed, 12575 insertions(+), 25120 deletions(-)
> v3.13: 491 files changed, 11088 insertions(+), 13375 deletions(-)
> v3.14: 408 files changed, 5586 insertions(+), 12691 deletions(-)
> v3.15: 538 files changed, 7809 insertions(+), 9337 deletions(-)
> v3.16: 499 files changed, 6528 insertions(+), 10252 deletions(-)
> v3.17: 596 files changed, 6274 insertions(+), 36824 deletions(-)
> v3.18: 333 files changed, 3111 insertions(+), 6905 deletions(-)
> v3.19: 435 files changed, 6180 insertions(+), 32402 deletions(-)
> v4.0: 265 files changed, 4081 insertions(+), 14119 deletions(-)
> v4.1: 362 files changed, 4286 insertions(+), 24876 deletions(-)
> v4.2: 292 files changed, 3115 insertions(+), 11567 deletions(-)
> v4.3: 306 files changed, 3223 insertions(+), 14510 deletions(-)
> v4.4: 160 files changed, 2014 insertions(+), 4893 deletions(-)
> v4.5: 531 files changed, 3839 insertions(+), 4398 deletions(-)
> v4.6: 211 files changed, 1417 insertions(+), 4320 deletions(-)
> 
> Once this goes to 0, we can move the dts files out of the kernel and
> make you maintainer. 
> 
> The dts files' numbers do look pretty constant.

Ah nice. I've done the statistics before (last time for ELC 2015 when
I did a presentation on this), but the last few lines look particularly
nice.

It's also worth comparing this to the earlier times, as by 2.6.39 we
had already started some large-scale cleanups:

This is v2.6.32..v2.6.39:
 3215 files changed, 345665 insertions(+), 100550 deletions(-)

Arnd


Re: [GIT PULL 0/7] ARM: SoC changes for 4.7

2016-05-20 Thread Arnd Bergmann
On Thursday 19 May 2016 11:02:56 Rob Herring wrote:
> I happen have a script... (I run it every time people complain about DT).
> 
> Here's the diffstat of mach-* and plat-* since merging DT support:
> 
> v3.0: 833 files changed, 10945 insertions(+), 37476 deletions(-)
> v3.1: 955 files changed, 17796 insertions(+), 20300 deletions(-)
> v3.2: 1507 files changed, 32960 insertions(+), 33392 deletions(-)
> v3.3: 1301 files changed, 27725 insertions(+), 18941 deletions(-)
> v3.4: 1324 files changed, 27079 insertions(+), 21500 deletions(-)
> v3.5: 975 files changed, 32340 insertions(+), 46663 deletions(-)
> v3.6: 648 files changed, 16121 insertions(+), 13161 deletions(-)
> v3.7: 1389 files changed, 23739 insertions(+), 61097 deletions(-)
> v3.8: 1066 files changed, 32812 insertions(+), 40821 deletions(-)
> v3.9: 1031 files changed, 10051 insertions(+), 33399 deletions(-)
> v3.10: 831 files changed, 15049 insertions(+), 27333 deletions(-)
> v3.11: 675 files changed, 18519 insertions(+), 30012 deletions(-)
> v3.12: 474 files changed, 12575 insertions(+), 25120 deletions(-)
> v3.13: 491 files changed, 11088 insertions(+), 13375 deletions(-)
> v3.14: 408 files changed, 5586 insertions(+), 12691 deletions(-)
> v3.15: 538 files changed, 7809 insertions(+), 9337 deletions(-)
> v3.16: 499 files changed, 6528 insertions(+), 10252 deletions(-)
> v3.17: 596 files changed, 6274 insertions(+), 36824 deletions(-)
> v3.18: 333 files changed, 3111 insertions(+), 6905 deletions(-)
> v3.19: 435 files changed, 6180 insertions(+), 32402 deletions(-)
> v4.0: 265 files changed, 4081 insertions(+), 14119 deletions(-)
> v4.1: 362 files changed, 4286 insertions(+), 24876 deletions(-)
> v4.2: 292 files changed, 3115 insertions(+), 11567 deletions(-)
> v4.3: 306 files changed, 3223 insertions(+), 14510 deletions(-)
> v4.4: 160 files changed, 2014 insertions(+), 4893 deletions(-)
> v4.5: 531 files changed, 3839 insertions(+), 4398 deletions(-)
> v4.6: 211 files changed, 1417 insertions(+), 4320 deletions(-)
> 
> Once this goes to 0, we can move the dts files out of the kernel and
> make you maintainer. 
> 
> The dts files' numbers do look pretty constant.

Ah nice. I've done the statistics before (last time for ELC 2015 when
I did a presentation on this), but the last few lines look particularly
nice.

It's also worth comparing this to the earlier times, as by 2.6.39 we
had already started some large-scale cleanups:

This is v2.6.32..v2.6.39:
 3215 files changed, 345665 insertions(+), 100550 deletions(-)

Arnd


Re: [PATCH 3.12 69/76] net: fix infoleak in rtnetlink

2016-05-20 Thread Vegard Nossum
On 19 May 2016 at 11:08, Jiri Slaby  wrote:
> From: Kangjie Lu 
>
> 3.12-stable review patch.  If anyone has any objections, please let me know.
>
> ===
>
> [ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]
>
> The stack object “map” has a total size of 32 bytes. Its last 4
> bytes are padding generated by compiler. These padding bytes are
> not initialized and sent out via “nla_put”.
>
> Signed-off-by: Kangjie Lu 
> Signed-off-by: David S. Miller 
> Signed-off-by: Jiri Slaby 
> ---
>  net/core/rtnetlink.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index fd3a16e45dd9..5093f42d7afc 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -950,14 +950,16 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct 
> net_device *dev,
> goto nla_put_failure;
>
> if (1) {
> -   struct rtnl_link_ifmap map = {
> -   .mem_start   = dev->mem_start,
> -   .mem_end = dev->mem_end,
> -   .base_addr   = dev->base_addr,
> -   .irq = dev->irq,
> -   .dma = dev->dma,
> -   .port= dev->if_port,
> -   };
> +   struct rtnl_link_ifmap map;
> +
> +   memset(, 0, sizeof(map));
> +   map.mem_start   = dev->mem_start;
> +   map.mem_end = dev->mem_end;
> +   map.base_addr   = dev->base_addr;
> +   map.irq = dev->irq;
> +   map.dma = dev->dma;
> +   map.port= dev->if_port;
> +
> if (nla_put(skb, IFLA_MAP, sizeof(map), ))
> goto nla_put_failure;
> }
> --
> 2.8.2
>

Just out of curiosity, was this observed in practice? I could be
wrong, but I was under the impression that using designated
initializers would zero the rest of the struct, including padding.
This seems to back that up:

http://stackoverflow.com/a/3374468/1697183

If this is indeed a real info leak, then I would assume we have much
bigger problems around the kernel.


Vegard


Re: [PATCH 3.12 69/76] net: fix infoleak in rtnetlink

2016-05-20 Thread Vegard Nossum
On 19 May 2016 at 11:08, Jiri Slaby  wrote:
> From: Kangjie Lu 
>
> 3.12-stable review patch.  If anyone has any objections, please let me know.
>
> ===
>
> [ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]
>
> The stack object “map” has a total size of 32 bytes. Its last 4
> bytes are padding generated by compiler. These padding bytes are
> not initialized and sent out via “nla_put”.
>
> Signed-off-by: Kangjie Lu 
> Signed-off-by: David S. Miller 
> Signed-off-by: Jiri Slaby 
> ---
>  net/core/rtnetlink.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index fd3a16e45dd9..5093f42d7afc 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -950,14 +950,16 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct 
> net_device *dev,
> goto nla_put_failure;
>
> if (1) {
> -   struct rtnl_link_ifmap map = {
> -   .mem_start   = dev->mem_start,
> -   .mem_end = dev->mem_end,
> -   .base_addr   = dev->base_addr,
> -   .irq = dev->irq,
> -   .dma = dev->dma,
> -   .port= dev->if_port,
> -   };
> +   struct rtnl_link_ifmap map;
> +
> +   memset(, 0, sizeof(map));
> +   map.mem_start   = dev->mem_start;
> +   map.mem_end = dev->mem_end;
> +   map.base_addr   = dev->base_addr;
> +   map.irq = dev->irq;
> +   map.dma = dev->dma;
> +   map.port= dev->if_port;
> +
> if (nla_put(skb, IFLA_MAP, sizeof(map), ))
> goto nla_put_failure;
> }
> --
> 2.8.2
>

Just out of curiosity, was this observed in practice? I could be
wrong, but I was under the impression that using designated
initializers would zero the rest of the struct, including padding.
This seems to back that up:

http://stackoverflow.com/a/3374468/1697183

If this is indeed a real info leak, then I would assume we have much
bigger problems around the kernel.


Vegard


<    4   5   6   7   8   9   10   11   12   13   >