Re: [PATCH] Coccinelle: Script to remove unnecessary static on local variables

[Julia Lawall]

On Thu, 27 Jul 2017, Gustavo A. R. Silva wrote:

> Coccinelle script to remove unnecessary static on local variables when
> the variables are not used before update.
>
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Julia Lawall 

> ---
>  scripts/coccinelle/misc/static_unnecessary.cocci | 89 
> 
>  1 file changed, 89 insertions(+)
>  create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
>
> diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
> b/scripts/coccinelle/misc/static_unnecessary.cocci
> new file mode 100644
> index 000..79fc899
> --- /dev/null
> +++ b/scripts/coccinelle/misc/static_unnecessary.cocci
> @@ -0,0 +1,89 @@
> +/// Drop static on local variable when the variable is not used before 
> update.
> +//# NOTE: Be aware that if a large object is initialized all at once, it 
> might
> +//# not be wise to remove the static because that would increase the risk of 
> a
> +//# stack overflow.
> +///
> +// Confidence: Moderate
> +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
> +// Copyright: (C) 2017 Gustavo A. R. Silva, Core Infrastructure Initiative.
> +// Copyright: (C) 2017 GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Options: --no-includes --include-headers
> +// Keywords: static
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +// 
> +@bad exists@
> +position p;
> +identifier x;
> +expression e;
> +type T;
> +@@
> +
> +static T x@p;
> +... when != x = e
> +x = <+...x...+>
> +
> +@worse exists@
> +position p;
> +identifier x;
> +type T;
> +@@
> +
> +static T x@p;
> +...
> + 
> +
> +@modify depends on patch && !context && !org && !report@
> +identifier x;
> +expression e;
> +type T;
> +position p != {bad.p,worse.p};
> +@@
> +
> +-static
> + T x@p;
> + ... when != x
> + when strict
> +?x = e;
> +// 
> +
> +
> +// 
> 
> +
> +@modify_context depends on !patch && (context || org || report) forall@
> +type T;
> +identifier x;
> +expression e;
> +position p != {bad.p,worse.p};
> +position j0;
> +@@
> +
> +* static
> + T x@j0@p;
> + ... when != x
> + when strict
> +?x = e;
> +
> +// 
> 
> +
> +@script:python modify_org depends on org@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +// 
> 
> +
> +@script:python modify_report depends on report@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.5.0
>
>

Re: [PATCH] Coccinelle: Script to remove unnecessary static on local variables

[Julia Lawall]

On Thu, 27 Jul 2017, Gustavo A. R. Silva wrote:

> Coccinelle script to remove unnecessary static on local variables when
> the variables are not used before update.
>
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Julia Lawall 

> ---
>  scripts/coccinelle/misc/static_unnecessary.cocci | 89 
> 
>  1 file changed, 89 insertions(+)
>  create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
>
> diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
> b/scripts/coccinelle/misc/static_unnecessary.cocci
> new file mode 100644
> index 000..79fc899
> --- /dev/null
> +++ b/scripts/coccinelle/misc/static_unnecessary.cocci
> @@ -0,0 +1,89 @@
> +/// Drop static on local variable when the variable is not used before 
> update.
> +//# NOTE: Be aware that if a large object is initialized all at once, it 
> might
> +//# not be wise to remove the static because that would increase the risk of 
> a
> +//# stack overflow.
> +///
> +// Confidence: Moderate
> +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
> +// Copyright: (C) 2017 Gustavo A. R. Silva, Core Infrastructure Initiative.
> +// Copyright: (C) 2017 GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Options: --no-includes --include-headers
> +// Keywords: static
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +// 
> +@bad exists@
> +position p;
> +identifier x;
> +expression e;
> +type T;
> +@@
> +
> +static T x@p;
> +... when != x = e
> +x = <+...x...+>
> +
> +@worse exists@
> +position p;
> +identifier x;
> +type T;
> +@@
> +
> +static T x@p;
> +...
> + 
> +
> +@modify depends on patch && !context && !org && !report@
> +identifier x;
> +expression e;
> +type T;
> +position p != {bad.p,worse.p};
> +@@
> +
> +-static
> + T x@p;
> + ... when != x
> + when strict
> +?x = e;
> +// 
> +
> +
> +// 
> 
> +
> +@modify_context depends on !patch && (context || org || report) forall@
> +type T;
> +identifier x;
> +expression e;
> +position p != {bad.p,worse.p};
> +position j0;
> +@@
> +
> +* static
> + T x@j0@p;
> + ... when != x
> + when strict
> +?x = e;
> +
> +// 
> 
> +
> +@script:python modify_org depends on org@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +// 
> 
> +
> +@script:python modify_report depends on report@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.5.0
>
>

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

[kbuild test robot]

Hi Dima,

[auto build test WARNING on v4.12]
[cannot apply to cgroup/for-next linus/master v4.13-rc2 v4.13-rc1 next-20170728]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dima-Zavin/cpuset-fix-a-deadlock-due-to-incomplete-patching-of-cpusets_enabled/20170729-123852
config: i386-randconfig-x019-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from kernel/sched/core.c:13:0:
   include/linux/cpuset.h: In function 'read_mems_allowed_begin':
>> include/linux/cpuset.h:261:9: warning: 'return' with a value, in function 
>> returning void
 return 0;
^
   include/linux/cpuset.h:259:20: note: declared here
static inline void read_mems_allowed_begin(struct cpuset_mems_cookie 
*cookie)
   ^~~

vim +/return +261 include/linux/cpuset.h

58568d2a Miao Xie   2009-06-16  258  
6b828cc9 Dima Zavin 2017-07-27  259  static inline void 
read_mems_allowed_begin(struct cpuset_mems_cookie *cookie)
c0ff7453 Miao Xie   2010-05-24  260  {
cc9a6c87 Mel Gorman 2012-03-21 @261 return 0;
c0ff7453 Miao Xie   2010-05-24  262  }
c0ff7453 Miao Xie   2010-05-24  263  

:: The code at line 261 was first introduced by commit
:: cc9a6c8776615f9c194ccf0b63a0aa5628235545 cpuset: mm: reduce large 
amounts of memory barrier related damage v3

:: TO: Mel Gorman <mgor...@suse.de>
:: CC: Linus Torvalds <torva...@linux-foundation.org>

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


.config.gz
Description: application/gzip

Re: [PATCH v2] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

[kbuild test robot]

Hi Dima,

[auto build test WARNING on v4.12]
[cannot apply to cgroup/for-next linus/master v4.13-rc2 v4.13-rc1 next-20170728]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dima-Zavin/cpuset-fix-a-deadlock-due-to-incomplete-patching-of-cpusets_enabled/20170729-123852
config: i386-randconfig-x019-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from kernel/sched/core.c:13:0:
   include/linux/cpuset.h: In function 'read_mems_allowed_begin':
>> include/linux/cpuset.h:261:9: warning: 'return' with a value, in function 
>> returning void
 return 0;
^
   include/linux/cpuset.h:259:20: note: declared here
static inline void read_mems_allowed_begin(struct cpuset_mems_cookie 
*cookie)
   ^~~

vim +/return +261 include/linux/cpuset.h

58568d2a Miao Xie   2009-06-16  258  
6b828cc9 Dima Zavin 2017-07-27  259  static inline void 
read_mems_allowed_begin(struct cpuset_mems_cookie *cookie)
c0ff7453 Miao Xie   2010-05-24  260  {
cc9a6c87 Mel Gorman 2012-03-21 @261 return 0;
c0ff7453 Miao Xie   2010-05-24  262  }
c0ff7453 Miao Xie   2010-05-24  263  

:: The code at line 261 was first introduced by commit
:: cc9a6c8776615f9c194ccf0b63a0aa5628235545 cpuset: mm: reduce large 
amounts of memory barrier related damage v3

:: TO: Mel Gorman 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[PATCH] futex: split PI support to a file of its own

[Nicolas Pitre]

Split out the priority inheritance support to a file of its own
to make futex.c much smaller, easier to understand and, hopefully,
to maintain. This also makes it easy to preserve basic futex support
and compile out the PI support when RT mutexes are not available.

Signed-off-by: Nicolas Pitre 

diff --git a/include/linux/futex.h b/include/linux/futex.h
index 7c5b694864..f36bfd26f9 100644
--- a/include/linux/futex.h
+++ b/include/linux/futex.h
@@ -54,7 +54,6 @@ union futex_key {
 
 #ifdef CONFIG_FUTEX
 extern void exit_robust_list(struct task_struct *curr);
-extern void exit_pi_state_list(struct task_struct *curr);
 #ifdef CONFIG_HAVE_FUTEX_CMPXCHG
 #define futex_cmpxchg_enabled 1
 #else
@@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled;
 static inline void exit_robust_list(struct task_struct *curr)
 {
 }
+#endif
+
+#ifdef CONFIG_FUTEX_PI
+extern void exit_pi_state_list(struct task_struct *curr);
+#else
 static inline void exit_pi_state_list(struct task_struct *curr)
 {
 }
 #endif
+
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db2..5f0ef850e8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1275,12 +1275,17 @@ config BASE_FULL
 config FUTEX
bool "Enable futex support" if EXPERT
default y
-   select RT_MUTEXES
+   imply RT_MUTEXES
help
  Disabling this option will cause the kernel to be built without
  support for "fast userspace mutexes".  The resulting kernel may not
  run glibc-based applications correctly.
 
+config FUTEX_PI
+   bool
+   depends on FUTEX && RT_MUTEXES
+   default y
+
 config HAVE_FUTEX_CMPXCHG
bool
depends on FUTEX
diff --git a/kernel/futex.c b/kernel/futex.c
index 16dbe4c938..6ee59b620a 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -12,17 +12,9 @@
  *  (C) Copyright 2006 Red Hat Inc, All Rights Reserved
  *  Thanks to Thomas Gleixner for suggestions, analysis and fixes.
  *
- *  PI-futex support started by Ingo Molnar and Thomas Gleixner
- *  Copyright (C) 2006 Red Hat, Inc., Ingo Molnar 
- *  Copyright (C) 2006 Timesys Corp., Thomas Gleixner 
- *
  *  PRIVATE futexes by Eric Dumazet
  *  Copyright (C) 2007 Eric Dumazet 
  *
- *  Requeue-PI support by Darren Hart 
- *  Copyright (C) IBM Corporation, 2009
- *  Thanks to Thomas Gleixner for conceptual design and careful reviews.
- *
  *  Thanks to Ben LaHaise for yelling "hashed waitqueues" loudly
  *  enough at me, Linus for the original (flawed) idea, Matthew
  *  Kirkwood for proof-of-concept implementation.
@@ -70,8 +62,6 @@
 
 #include 
 
-#include "locking/rtmutex_common.h"
-
 /*
  * READ this before attempting to hack on futexes!
  *
@@ -193,26 +183,7 @@ int __read_mostly futex_cmpxchg_enabled;
 #define FLAGS_CLOCKRT  0x02
 #define FLAGS_HAS_TIMEOUT  0x04
 
-/*
- * Priority Inheritance state:
- */
-struct futex_pi_state {
-   /*
-* list of 'owned' pi_state instances - these have to be
-* cleaned up in do_exit() if the task exits prematurely:
-*/
-   struct list_head list;
-
-   /*
-* The PI object:
-*/
-   struct rt_mutex pi_mutex;
-
-   struct task_struct *owner;
-   atomic_t refcount;
-
-   union futex_key key;
-} __randomize_layout;
+struct futex_pi_state;
 
 /**
  * struct futex_q - The hashed futex queue entry, one per waiting task
@@ -733,25 +704,6 @@ static int fault_in_user_writeable(u32 __user *uaddr)
return ret < 0 ? ret : 0;
 }
 
-/**
- * futex_top_waiter() - Return the highest priority waiter on a futex
- * @hb:the hash bucket the futex_q's reside in
- * @key:   the futex key (to distinguish it from other futex futex_q's)
- *
- * Must be called with the hb lock held.
- */
-static struct futex_q *futex_top_waiter(struct futex_hash_bucket *hb,
-   union futex_key *key)
-{
-   struct futex_q *this;
-
-   plist_for_each_entry(this, >chain, list) {
-   if (match_futex(>key, key))
-   return this;
-   }
-   return NULL;
-}
-
 static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
  u32 uval, u32 newval)
 {
@@ -779,567 +731,21 @@ static int get_futex_value_locked(u32 *dest, u32 __user 
*from)
 /*
  * PI code:
  */
-static int refill_pi_state_cache(void)
-{
-   struct futex_pi_state *pi_state;
-
-   if (likely(current->pi_state_cache))
-   return 0;
-
-   pi_state = kzalloc(sizeof(*pi_state), GFP_KERNEL);
-
-   if (!pi_state)
-   return -ENOMEM;
-
-   INIT_LIST_HEAD(_state->list);
-   /* pi_mutex gets initialized later */
-   pi_state->owner = NULL;
-   atomic_set(_state->refcount, 1);
-   pi_state->key = FUTEX_KEY_INIT;
-
-   current->pi_state_cache = pi_state;
-
-   return 0;
-}
-
-static struct futex_pi_state 

[PATCH] futex: split PI support to a file of its own

[Nicolas Pitre]

Split out the priority inheritance support to a file of its own
to make futex.c much smaller, easier to understand and, hopefully,
to maintain. This also makes it easy to preserve basic futex support
and compile out the PI support when RT mutexes are not available.

Signed-off-by: Nicolas Pitre 

diff --git a/include/linux/futex.h b/include/linux/futex.h
index 7c5b694864..f36bfd26f9 100644
--- a/include/linux/futex.h
+++ b/include/linux/futex.h
@@ -54,7 +54,6 @@ union futex_key {
 
 #ifdef CONFIG_FUTEX
 extern void exit_robust_list(struct task_struct *curr);
-extern void exit_pi_state_list(struct task_struct *curr);
 #ifdef CONFIG_HAVE_FUTEX_CMPXCHG
 #define futex_cmpxchg_enabled 1
 #else
@@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled;
 static inline void exit_robust_list(struct task_struct *curr)
 {
 }
+#endif
+
+#ifdef CONFIG_FUTEX_PI
+extern void exit_pi_state_list(struct task_struct *curr);
+#else
 static inline void exit_pi_state_list(struct task_struct *curr)
 {
 }
 #endif
+
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db2..5f0ef850e8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1275,12 +1275,17 @@ config BASE_FULL
 config FUTEX
bool "Enable futex support" if EXPERT
default y
-   select RT_MUTEXES
+   imply RT_MUTEXES
help
  Disabling this option will cause the kernel to be built without
  support for "fast userspace mutexes".  The resulting kernel may not
  run glibc-based applications correctly.
 
+config FUTEX_PI
+   bool
+   depends on FUTEX && RT_MUTEXES
+   default y
+
 config HAVE_FUTEX_CMPXCHG
bool
depends on FUTEX
diff --git a/kernel/futex.c b/kernel/futex.c
index 16dbe4c938..6ee59b620a 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -12,17 +12,9 @@
  *  (C) Copyright 2006 Red Hat Inc, All Rights Reserved
  *  Thanks to Thomas Gleixner for suggestions, analysis and fixes.
  *
- *  PI-futex support started by Ingo Molnar and Thomas Gleixner
- *  Copyright (C) 2006 Red Hat, Inc., Ingo Molnar 
- *  Copyright (C) 2006 Timesys Corp., Thomas Gleixner 
- *
  *  PRIVATE futexes by Eric Dumazet
  *  Copyright (C) 2007 Eric Dumazet 
  *
- *  Requeue-PI support by Darren Hart 
- *  Copyright (C) IBM Corporation, 2009
- *  Thanks to Thomas Gleixner for conceptual design and careful reviews.
- *
  *  Thanks to Ben LaHaise for yelling "hashed waitqueues" loudly
  *  enough at me, Linus for the original (flawed) idea, Matthew
  *  Kirkwood for proof-of-concept implementation.
@@ -70,8 +62,6 @@
 
 #include 
 
-#include "locking/rtmutex_common.h"
-
 /*
  * READ this before attempting to hack on futexes!
  *
@@ -193,26 +183,7 @@ int __read_mostly futex_cmpxchg_enabled;
 #define FLAGS_CLOCKRT  0x02
 #define FLAGS_HAS_TIMEOUT  0x04
 
-/*
- * Priority Inheritance state:
- */
-struct futex_pi_state {
-   /*
-* list of 'owned' pi_state instances - these have to be
-* cleaned up in do_exit() if the task exits prematurely:
-*/
-   struct list_head list;
-
-   /*
-* The PI object:
-*/
-   struct rt_mutex pi_mutex;
-
-   struct task_struct *owner;
-   atomic_t refcount;
-
-   union futex_key key;
-} __randomize_layout;
+struct futex_pi_state;
 
 /**
  * struct futex_q - The hashed futex queue entry, one per waiting task
@@ -733,25 +704,6 @@ static int fault_in_user_writeable(u32 __user *uaddr)
return ret < 0 ? ret : 0;
 }
 
-/**
- * futex_top_waiter() - Return the highest priority waiter on a futex
- * @hb:the hash bucket the futex_q's reside in
- * @key:   the futex key (to distinguish it from other futex futex_q's)
- *
- * Must be called with the hb lock held.
- */
-static struct futex_q *futex_top_waiter(struct futex_hash_bucket *hb,
-   union futex_key *key)
-{
-   struct futex_q *this;
-
-   plist_for_each_entry(this, >chain, list) {
-   if (match_futex(>key, key))
-   return this;
-   }
-   return NULL;
-}
-
 static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
  u32 uval, u32 newval)
 {
@@ -779,567 +731,21 @@ static int get_futex_value_locked(u32 *dest, u32 __user 
*from)
 /*
  * PI code:
  */
-static int refill_pi_state_cache(void)
-{
-   struct futex_pi_state *pi_state;
-
-   if (likely(current->pi_state_cache))
-   return 0;
-
-   pi_state = kzalloc(sizeof(*pi_state), GFP_KERNEL);
-
-   if (!pi_state)
-   return -ENOMEM;
-
-   INIT_LIST_HEAD(_state->list);
-   /* pi_mutex gets initialized later */
-   pi_state->owner = NULL;
-   atomic_set(_state->refcount, 1);
-   pi_state->key = FUTEX_KEY_INIT;
-
-   current->pi_state_cache = pi_state;
-
-   return 0;
-}
-
-static struct futex_pi_state *alloc_pi_state(void)
-{
-   struct futex_pi_state *pi_state = current->pi_state_cache;
-
-   

[PATCH 5/7] arm64: dts: Add SATA DT nodes for Stingray SoC

[Abhishek Shah]

From: Srinath Mannam 

Add DT nodes for SATA host controllers and SATA PHYs
on Stingray SoC

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  64 +
 .../boot/dts/broadcom/stingray/stingray-sata.dtsi  | 278 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   2 +
 3 files changed, 344 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..8862ec9 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,6 +72,70 @@
  <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
 };
 
+ {
+   status = "okay";
+};
+
+_phy0{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy1{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy2{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy3{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy4{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy5{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy6{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy7{
+   status = "okay";
+};
+
 _mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
new file mode 100644
index 000..a774709
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -0,0 +1,278 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+   sata {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x67d0 0x0080>;
+
+   sata0: ahci@0021 {
+   compatible = "brcm,iproc-ahci", "generic-ahci";
+   reg = <0x0021 0x1000>;
+   reg-names = "ahci";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata0_port0: sata-port@0 {
+   reg = <0>;
+   phys = <_phy0>;
+   phy-names = "sata-phy";
+   };
+   };
+
+   sata_phy0: sata_phy@00212100 {
+   compatible = "brcm,iproc-sr-sata-phy";
+   reg = <0x00212100 0x1000>;
+   reg-names = "phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata0_phy0: sata-phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+   };
+
+   sata1: ahci@0031 {
+   compatible = 

[PATCH 7/7] arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

[Abhishek Shah]

From: Anup Patel 

This patch adds Broadcom SBA-RAID DT nodes for Stingray SoC.

The Stingray SoC has total 32 SBA-RAID FlexRM rings and it has
8 CPUs so we create 8 SBA-RAID instances (one for each CPU).
This way Linux DMAENGINE will have one SBA-RAID DMA device for
each CPU.

Signed-off-by: Anup Patel 
---
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
index 1f927c4..8bf1dc6 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
@@ -51,4 +51,68 @@
msi-parent = <_its 0x4300>;
#mbox-cells = <3>;
};
+
+   raid0: raid@0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0xff00>,
+<_mbox 1 0x1 0xff00>,
+<_mbox 2 0x1 0xff00>,
+<_mbox 3 0x1 0xff00>;
+   };
+
+   raid1: raid@1 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 4 0x1 0xff00>,
+<_mbox 5 0x1 0xff00>,
+<_mbox 6 0x1 0xff00>,
+<_mbox 7 0x1 0xff00>;
+   };
+
+   raid2: raid@2 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 8 0x1 0xff00>,
+<_mbox 9 0x1 0xff00>,
+<_mbox 10 0x1 0xff00>,
+<_mbox 11 0x1 0xff00>;
+   };
+
+   raid3: raid@3 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 12 0x1 0xff00>,
+<_mbox 13 0x1 0xff00>,
+<_mbox 14 0x1 0xff00>,
+<_mbox 15 0x1 0xff00>;
+   };
+
+   raid4: raid@4 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 16 0x1 0xff00>,
+<_mbox 17 0x1 0xff00>,
+<_mbox 18 0x1 0xff00>,
+<_mbox 19 0x1 0xff00>;
+   };
+
+   raid5: raid@5 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 20 0x1 0xff00>,
+<_mbox 21 0x1 0xff00>,
+<_mbox 22 0x1 0xff00>,
+<_mbox 23 0x1 0xff00>;
+   };
+
+   raid6: raid@6 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 24 0x1 0xff00>,
+<_mbox 25 0x1 0xff00>,
+<_mbox 26 0x1 0xff00>,
+<_mbox 27 0x1 0xff00>;
+   };
+
+   raid7: raid@7 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 28 0x1 0xff00>,
+<_mbox 29 0x1 0xff00>,
+<_mbox 30 0x1 0xff00>,
+<_mbox 31 0x1 0xff00>;
+   };
};
-- 
2.7.4

[PATCH 6/7] arm64: dts: Add FlexRM DT nodes for Stingray

[Abhishek Shah]

From: Anup Patel 

We have two instances of FlexRM on Stingray. One for SBA RAID
offload engine and another for SPU2 Crypto offload engine.

This patch adds FlexRM mailbox controller DT nodes for Stingray.

Signed-off-by: Anup Patel 
Signed-off-by: Raveendra Padasalagi 
---
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 54 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
new file mode 100644
index 000..1f927c4
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
@@ -0,0 +1,54 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+   fs4: fs4 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x6700 0x0080>;
+
+   crypto_mbox: crypto_mbox@ {
+   compatible = "brcm,iproc-flexrm-mbox";
+   reg = <0x 0x20>;
+   msi-parent = <_its 0x4100>;
+   #mbox-cells = <3>;
+   dma-coherent;
+   };
+
+   raid_mbox: raid_mbox@0040 {
+   compatible = "brcm,iproc-flexrm-mbox";
+   reg = <0x0040 0x20>;
+   dma-coherent;
+   msi-parent = <_its 0x4300>;
+   #mbox-cells = <3>;
+   };
+   };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 1700033..e6f75c6 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -267,6 +267,7 @@
};
};
 
+   #include "stingray-fs4.dtsi"
#include "stingray-sata.dtsi"
 
hsls {
-- 
2.7.4

[PATCH 5/7] arm64: dts: Add SATA DT nodes for Stingray SoC

[Abhishek Shah]

From: Srinath Mannam 

Add DT nodes for SATA host controllers and SATA PHYs
on Stingray SoC

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  64 +
 .../boot/dts/broadcom/stingray/stingray-sata.dtsi  | 278 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   2 +
 3 files changed, 344 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..8862ec9 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,6 +72,70 @@
  <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
 };
 
+ {
+   status = "okay";
+};
+
+_phy0{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy1{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy2{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy3{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy4{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy5{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy6{
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy7{
+   status = "okay";
+};
+
 _mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
new file mode 100644
index 000..a774709
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -0,0 +1,278 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+   sata {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x67d0 0x0080>;
+
+   sata0: ahci@0021 {
+   compatible = "brcm,iproc-ahci", "generic-ahci";
+   reg = <0x0021 0x1000>;
+   reg-names = "ahci";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata0_port0: sata-port@0 {
+   reg = <0>;
+   phys = <_phy0>;
+   phy-names = "sata-phy";
+   };
+   };
+
+   sata_phy0: sata_phy@00212100 {
+   compatible = "brcm,iproc-sr-sata-phy";
+   reg = <0x00212100 0x1000>;
+   reg-names = "phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   sata0_phy0: sata-phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+   };
+
+   sata1: ahci@0031 {
+   compatible = "brcm,iproc-ahci", "generic-ahci";
+   reg = <0x0031 0x1000>;
+  

[PATCH 7/7] arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

[Abhishek Shah]

From: Anup Patel 

This patch adds Broadcom SBA-RAID DT nodes for Stingray SoC.

The Stingray SoC has total 32 SBA-RAID FlexRM rings and it has
8 CPUs so we create 8 SBA-RAID instances (one for each CPU).
This way Linux DMAENGINE will have one SBA-RAID DMA device for
each CPU.

Signed-off-by: Anup Patel 
---
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
index 1f927c4..8bf1dc6 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
@@ -51,4 +51,68 @@
msi-parent = <_its 0x4300>;
#mbox-cells = <3>;
};
+
+   raid0: raid@0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0xff00>,
+<_mbox 1 0x1 0xff00>,
+<_mbox 2 0x1 0xff00>,
+<_mbox 3 0x1 0xff00>;
+   };
+
+   raid1: raid@1 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 4 0x1 0xff00>,
+<_mbox 5 0x1 0xff00>,
+<_mbox 6 0x1 0xff00>,
+<_mbox 7 0x1 0xff00>;
+   };
+
+   raid2: raid@2 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 8 0x1 0xff00>,
+<_mbox 9 0x1 0xff00>,
+<_mbox 10 0x1 0xff00>,
+<_mbox 11 0x1 0xff00>;
+   };
+
+   raid3: raid@3 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 12 0x1 0xff00>,
+<_mbox 13 0x1 0xff00>,
+<_mbox 14 0x1 0xff00>,
+<_mbox 15 0x1 0xff00>;
+   };
+
+   raid4: raid@4 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 16 0x1 0xff00>,
+<_mbox 17 0x1 0xff00>,
+<_mbox 18 0x1 0xff00>,
+<_mbox 19 0x1 0xff00>;
+   };
+
+   raid5: raid@5 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 20 0x1 0xff00>,
+<_mbox 21 0x1 0xff00>,
+<_mbox 22 0x1 0xff00>,
+<_mbox 23 0x1 0xff00>;
+   };
+
+   raid6: raid@6 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 24 0x1 0xff00>,
+<_mbox 25 0x1 0xff00>,
+<_mbox 26 0x1 0xff00>,
+<_mbox 27 0x1 0xff00>;
+   };
+
+   raid7: raid@7 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 28 0x1 0xff00>,
+<_mbox 29 0x1 0xff00>,
+<_mbox 30 0x1 0xff00>,
+<_mbox 31 0x1 0xff00>;
+   };
};
-- 
2.7.4

[PATCH 6/7] arm64: dts: Add FlexRM DT nodes for Stingray

[Abhishek Shah]

From: Anup Patel 

We have two instances of FlexRM on Stingray. One for SBA RAID
offload engine and another for SPU2 Crypto offload engine.

This patch adds FlexRM mailbox controller DT nodes for Stingray.

Signed-off-by: Anup Patel 
Signed-off-by: Raveendra Padasalagi 
---
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 54 ++
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
new file mode 100644
index 000..1f927c4
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
@@ -0,0 +1,54 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2016-2017 Broadcom.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+   fs4: fs4 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x6700 0x0080>;
+
+   crypto_mbox: crypto_mbox@ {
+   compatible = "brcm,iproc-flexrm-mbox";
+   reg = <0x 0x20>;
+   msi-parent = <_its 0x4100>;
+   #mbox-cells = <3>;
+   dma-coherent;
+   };
+
+   raid_mbox: raid_mbox@0040 {
+   compatible = "brcm,iproc-flexrm-mbox";
+   reg = <0x0040 0x20>;
+   dma-coherent;
+   msi-parent = <_its 0x4300>;
+   #mbox-cells = <3>;
+   };
+   };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 1700033..e6f75c6 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -267,6 +267,7 @@
};
};
 
+   #include "stingray-fs4.dtsi"
#include "stingray-sata.dtsi"
 
hsls {
-- 
2.7.4

[PATCH 3/7] arm64: dts: Add sp804 DT nodes for Stingray SoC

[Abhishek Shah]

From: Anup Patel 

We have 8 instances of sp804 in Stingray SoC. Let's enable
it in Stingray DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 87 ++
 1 file changed, 87 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 697401d..19ad887 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -314,6 +314,93 @@
status = "disabled";
};
 
+   timer0: timer@0003 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0003 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer1: timer@0004 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0004 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   };
+
+   timer2: timer@0005 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0005 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer3: timer@0006 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0006 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer4: timer@0007 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0007 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer5: timer@0008 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0008 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer6: timer@0009 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0009 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer7: timer@000a {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x000a 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
i2c0: i2c@000b {
compatible = "brcm,iproc-i2c";
reg = <0x000b 0x100>;
-- 
2.7.4

[PATCH 4/7] arm64: dts: Add DT node to enable BGMAC driver on Stingray

[Abhishek Shah]

This patch adds DT node to enable BGMAC driver on Stingray

Signed-off-by: Abhishek Shah 
Reviewed-by: Ray Jui 
Reviewed-by: Oza Oza 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi | 14 ++
 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts  |  4 
 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts  |  4 
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi   |  9 +
 4 files changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 5dca7d1..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,6 +72,14 @@
  <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
 };
 
+_mux_iproc {
+   mdio@10 {
+   gphy0: eth-phy@10 {
+   reg = <0x10>;
+   };
+   };
+};
+
  {
status = "okay";
 };
@@ -102,6 +110,12 @@
};
 };
 
+ {
+   phy-mode = "rgmii-id";
+   phy-handle = <>;
+   status = "okay";
+};
+
  {
status = "ok";
nandcs@0 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 5671669..eb6f08c 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -39,6 +39,10 @@
model = "Stingray Combo SVK (BCM958742K)";
 };
 
+ {
+   enet-phy-lane-swap;
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 6ebe399..5084b03 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -38,3 +38,7 @@
compatible = "brcm,bcm958742t", "brcm,stingray";
model = "Stingray SST100 (BCM958742T)";
 };
+
+ {
+   enet-phy-lane-swap;
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 19ad887..1c6cc2d 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -548,6 +548,15 @@
iommus = < 0x6000 0x>;
};
 
+   enet: ethernet@0034{
+   compatible = "brcm,amac";
+   reg = <0x0034 0x1000>;
+   reg-names = "amac_base";
+   dma-coherent;
+   interrupts = ;
+   status= "disabled";
+   };
+
nand: nand@0036 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x0036 0x600>,
-- 
2.7.4

[PATCH 3/7] arm64: dts: Add sp804 DT nodes for Stingray SoC

[Abhishek Shah]

From: Anup Patel 

We have 8 instances of sp804 in Stingray SoC. Let's enable
it in Stingray DT.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 87 ++
 1 file changed, 87 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 697401d..19ad887 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -314,6 +314,93 @@
status = "disabled";
};
 
+   timer0: timer@0003 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0003 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer1: timer@0004 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0004 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   };
+
+   timer2: timer@0005 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0005 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer3: timer@0006 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0006 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer4: timer@0007 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0007 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer5: timer@0008 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0008 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer6: timer@0009 {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x0009 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
+   timer7: timer@000a {
+   compatible = "arm,sp804", "arm,primecell";
+   reg = <0x000a 0x1000>;
+   interrupts = ;
+   clocks = <_25m_div2_clk>,
+<_25m_div2_clk>,
+<_div4_clk>;
+   clock-names = "timer1", "timer2", "apb_pclk";
+   status = "disabled";
+   };
+
i2c0: i2c@000b {
compatible = "brcm,iproc-i2c";
reg = <0x000b 0x100>;
-- 
2.7.4

[PATCH 4/7] arm64: dts: Add DT node to enable BGMAC driver on Stingray

[Abhishek Shah]

This patch adds DT node to enable BGMAC driver on Stingray

Signed-off-by: Abhishek Shah 
Reviewed-by: Ray Jui 
Reviewed-by: Oza Oza 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi | 14 ++
 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts  |  4 
 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts  |  4 
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi   |  9 +
 4 files changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 5dca7d1..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,6 +72,14 @@
  <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
 };
 
+_mux_iproc {
+   mdio@10 {
+   gphy0: eth-phy@10 {
+   reg = <0x10>;
+   };
+   };
+};
+
  {
status = "okay";
 };
@@ -102,6 +110,12 @@
};
 };
 
+ {
+   phy-mode = "rgmii-id";
+   phy-handle = <>;
+   status = "okay";
+};
+
  {
status = "ok";
nandcs@0 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 5671669..eb6f08c 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -39,6 +39,10 @@
model = "Stingray Combo SVK (BCM958742K)";
 };
 
+ {
+   enet-phy-lane-swap;
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 6ebe399..5084b03 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -38,3 +38,7 @@
compatible = "brcm,bcm958742t", "brcm,stingray";
model = "Stingray SST100 (BCM958742T)";
 };
+
+ {
+   enet-phy-lane-swap;
+};
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 19ad887..1c6cc2d 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -548,6 +548,15 @@
iommus = < 0x6000 0x>;
};
 
+   enet: ethernet@0034{
+   compatible = "brcm,amac";
+   reg = <0x0034 0x1000>;
+   reg-names = "amac_base";
+   dma-coherent;
+   interrupts = ;
+   status= "disabled";
+   };
+
nand: nand@0036 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x0036 0x600>,
-- 
2.7.4

[PATCH 2/7] arm64: dts: Add MDIO multiplexer DT node for Stingray

[Abhishek Shah]

From: Srinath Mannam 

Added MDIO multiplexer iproc DT node for Stingray, which contains
the child nodes of PCIe serdes, RGMII, SATA and USB phy MDIO slaves.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index a63c465..697401d 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -275,6 +275,37 @@
 
#include "stingray-pinctrl.dtsi"
 
+   mdio_mux_iproc: mdio-mux@0002023c {
+   compatible = "brcm,mdio-mux-iproc";
+   reg = <0x0002023c 0x14>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@0 { /* PCIe serdes */
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@2 { /* SATA */
+   reg = <0x2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@3 { /* USB */
+   reg = <0x3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@10 { /* RGMII */
+   reg = <0x10>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
pwm: pwm@0001 {
compatible = "brcm,iproc-pwm";
reg = <0x0001 0x1000>;
-- 
2.7.4

[PATCH 0/7] Add more DT nodes for Stingray SoC

[Abhishek Shah]

This is round two of adding DT nodes for Stingray SoC.
Corresponding drivers and dt binding documents are already
checked in the kernel and will be present in v4.14.

Abhishek Shah (1):
  arm64: dts: Add DT node to enable BGMAC driver on Stingray

Anup Patel (3):
  arm64: dts: Add sp804 DT nodes for Stingray SoC
  arm64: dts: Add FlexRM DT nodes for Stingray
  arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

Srinath Mannam (2):
  arm64: dts: Add MDIO multiplexer DT node for Stingray
  arm64: dts: Add SATA DT nodes for Stingray SoC

Velibor Markovski (1):
  arm64: dts: Enable stats for CCN-502 interconnect on Stingray

 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  78 ++
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |   4 +
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |   4 +
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 118 +
 .../boot/dts/broadcom/stingray/stingray-sata.dtsi  | 278 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 136 ++
 6 files changed, 618 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi

-- 
2.7.4

[PATCH 1/7] arm64: dts: Enable stats for CCN-502 interconnect on Stingray

[Abhishek Shah]

From: Velibor Markovski 

This patch enables stats for CCN-502 interconnect on Stingray.

Signed-off-by: Velibor Markovski 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 49933cf..a63c465 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -152,6 +152,12 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x6100 0x0500>;
 
+   ccn: ccn@ {
+   compatible = "arm,ccn-502";
+   reg = <0x 0x90>;
+   interrupts = ;
+   };
+
gic: interrupt-controller@02c0 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
2.7.4

[PATCH 2/7] arm64: dts: Add MDIO multiplexer DT node for Stingray

[Abhishek Shah]

From: Srinath Mannam 

Added MDIO multiplexer iproc DT node for Stingray, which contains
the child nodes of PCIe serdes, RGMII, SATA and USB phy MDIO slaves.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index a63c465..697401d 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -275,6 +275,37 @@
 
#include "stingray-pinctrl.dtsi"
 
+   mdio_mux_iproc: mdio-mux@0002023c {
+   compatible = "brcm,mdio-mux-iproc";
+   reg = <0x0002023c 0x14>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@0 { /* PCIe serdes */
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@2 { /* SATA */
+   reg = <0x2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@3 { /* USB */
+   reg = <0x3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mdio@10 { /* RGMII */
+   reg = <0x10>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
pwm: pwm@0001 {
compatible = "brcm,iproc-pwm";
reg = <0x0001 0x1000>;
-- 
2.7.4

[PATCH 0/7] Add more DT nodes for Stingray SoC

[Abhishek Shah]

This is round two of adding DT nodes for Stingray SoC.
Corresponding drivers and dt binding documents are already
checked in the kernel and will be present in v4.14.

Abhishek Shah (1):
  arm64: dts: Add DT node to enable BGMAC driver on Stingray

Anup Patel (3):
  arm64: dts: Add sp804 DT nodes for Stingray SoC
  arm64: dts: Add FlexRM DT nodes for Stingray
  arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

Srinath Mannam (2):
  arm64: dts: Add MDIO multiplexer DT node for Stingray
  arm64: dts: Add SATA DT nodes for Stingray SoC

Velibor Markovski (1):
  arm64: dts: Enable stats for CCN-502 interconnect on Stingray

 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi |  78 ++
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |   4 +
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |   4 +
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 118 +
 .../boot/dts/broadcom/stingray/stingray-sata.dtsi  | 278 +
 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 136 ++
 6 files changed, 618 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi

-- 
2.7.4

[PATCH 1/7] arm64: dts: Enable stats for CCN-502 interconnect on Stingray

[Abhishek Shah]

From: Velibor Markovski 

This patch enables stats for CCN-502 interconnect on Stingray.

Signed-off-by: Velibor Markovski 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 49933cf..a63c465 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -152,6 +152,12 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x6100 0x0500>;
 
+   ccn: ccn@ {
+   compatible = "arm,ccn-502";
+   reg = <0x 0x90>;
+   interrupts = ;
+   };
+
gic: interrupt-controller@02c0 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
2.7.4

Re: Possible race condition in oom-killer

[Tetsuo Handa]

Michal Hocko wrote:
> On Fri 28-07-17 22:55:51, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Fri 28-07-17 22:15:01, Tetsuo Handa wrote:
> > > > task_will_free_mem(current) in out_of_memory() returning false due to
> > > > MMF_OOM_SKIP already set allowed each thread sharing that mm to select 
> > > > a new
> > > > OOM victim. If task_will_free_mem(current) in out_of_memory() did not 
> > > > return
> > > > false, threads sharing MMF_OOM_SKIP mm would not have selected new 
> > > > victims
> > > > to the level where all OOM killable processes are killed and calls 
> > > > panic().
> > > 
> > > I am not sure I understand. Do you mean this?
> > 
> > Yes.
> > 
> > > ---
> > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > > index 9e8b4f030c1c..671e4a4107d0 100644
> > > --- a/mm/oom_kill.c
> > > +++ b/mm/oom_kill.c
> > > @@ -779,13 +779,6 @@ static bool task_will_free_mem(struct task_struct 
> > > *task)
> > >   if (!__task_will_free_mem(task))
> > >   return false;
> > >  
> > > - /*
> > > -  * This task has already been drained by the oom reaper so there are
> > > -  * only small chances it will free some more
> > > -  */
> > > - if (test_bit(MMF_OOM_SKIP, >flags))
> > > - return false;
> > > -
> > >   if (atomic_read(>mm_users) <= 1)
> > >   return true;
> > >  
> > > If yes I would have to think about this some more because that might
> > > have weird side effects (e.g. oom_victims counting after threads passed
> > > exit_oom_victim).
> > 
> > But this check should not be removed unconditionally. We should still return
> > false if returning true was not sufficient to solve the OOM situation, for
> > we need to select next OOM victim in that case.
> > 

I think that below one can manage this race condition.

---
 include/linux/sched.h |  1 +
 mm/oom_kill.c | 21 ++---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0db4870..3fccf72 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -652,6 +652,7 @@ struct task_struct {
/* disallow userland-initiated cgroup migration */
unsignedno_cgroup_migration:1;
 #endif
+   unsignedoom_kill_free_check_raced:1;
 
unsigned long   atomic_flags; /* Flags requiring atomic 
access. */
 
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 9e8b4f0..a093193 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -779,13 +779,6 @@ static bool task_will_free_mem(struct task_struct *task)
if (!__task_will_free_mem(task))
return false;
 
-   /*
-* This task has already been drained by the oom reaper so there are
-* only small chances it will free some more
-*/
-   if (test_bit(MMF_OOM_SKIP, >flags))
-   return false;
-
if (atomic_read(>mm_users) <= 1)
return true;
 
@@ -806,6 +799,20 @@ static bool task_will_free_mem(struct task_struct *task)
}
rcu_read_unlock();
 
+   /*
+* It is possible that current thread fails to try allocation from
+* memory reserves if the OOM reaper set MMF_OOM_SKIP on this mm before
+* current thread calls out_of_memory() in order to get TIF_MEMDIE.
+* In that case, allow current thread to try TIF_MEMDIE allocation
+* before start selecting next OOM victims.
+*/
+   if (ret && test_bit(MMF_OOM_SKIP, >flags)) {
+   if (task == current && !task->oom_kill_free_check_raced)
+   task->oom_kill_free_check_raced = true;
+   else
+   ret = false;
+   }
+
return ret;
 }
 
-- 
1.8.3.1

What is "oom_victims counting after threads passed exit_oom_victim" ?

Re: Possible race condition in oom-killer

[Tetsuo Handa]

Michal Hocko wrote:
> On Fri 28-07-17 22:55:51, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Fri 28-07-17 22:15:01, Tetsuo Handa wrote:
> > > > task_will_free_mem(current) in out_of_memory() returning false due to
> > > > MMF_OOM_SKIP already set allowed each thread sharing that mm to select 
> > > > a new
> > > > OOM victim. If task_will_free_mem(current) in out_of_memory() did not 
> > > > return
> > > > false, threads sharing MMF_OOM_SKIP mm would not have selected new 
> > > > victims
> > > > to the level where all OOM killable processes are killed and calls 
> > > > panic().
> > > 
> > > I am not sure I understand. Do you mean this?
> > 
> > Yes.
> > 
> > > ---
> > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > > index 9e8b4f030c1c..671e4a4107d0 100644
> > > --- a/mm/oom_kill.c
> > > +++ b/mm/oom_kill.c
> > > @@ -779,13 +779,6 @@ static bool task_will_free_mem(struct task_struct 
> > > *task)
> > >   if (!__task_will_free_mem(task))
> > >   return false;
> > >  
> > > - /*
> > > -  * This task has already been drained by the oom reaper so there are
> > > -  * only small chances it will free some more
> > > -  */
> > > - if (test_bit(MMF_OOM_SKIP, >flags))
> > > - return false;
> > > -
> > >   if (atomic_read(>mm_users) <= 1)
> > >   return true;
> > >  
> > > If yes I would have to think about this some more because that might
> > > have weird side effects (e.g. oom_victims counting after threads passed
> > > exit_oom_victim).
> > 
> > But this check should not be removed unconditionally. We should still return
> > false if returning true was not sufficient to solve the OOM situation, for
> > we need to select next OOM victim in that case.
> > 

I think that below one can manage this race condition.

---
 include/linux/sched.h |  1 +
 mm/oom_kill.c | 21 ++---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0db4870..3fccf72 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -652,6 +652,7 @@ struct task_struct {
/* disallow userland-initiated cgroup migration */
unsignedno_cgroup_migration:1;
 #endif
+   unsignedoom_kill_free_check_raced:1;
 
unsigned long   atomic_flags; /* Flags requiring atomic 
access. */
 
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 9e8b4f0..a093193 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -779,13 +779,6 @@ static bool task_will_free_mem(struct task_struct *task)
if (!__task_will_free_mem(task))
return false;
 
-   /*
-* This task has already been drained by the oom reaper so there are
-* only small chances it will free some more
-*/
-   if (test_bit(MMF_OOM_SKIP, >flags))
-   return false;
-
if (atomic_read(>mm_users) <= 1)
return true;
 
@@ -806,6 +799,20 @@ static bool task_will_free_mem(struct task_struct *task)
}
rcu_read_unlock();
 
+   /*
+* It is possible that current thread fails to try allocation from
+* memory reserves if the OOM reaper set MMF_OOM_SKIP on this mm before
+* current thread calls out_of_memory() in order to get TIF_MEMDIE.
+* In that case, allow current thread to try TIF_MEMDIE allocation
+* before start selecting next OOM victims.
+*/
+   if (ret && test_bit(MMF_OOM_SKIP, >flags)) {
+   if (task == current && !task->oom_kill_free_check_raced)
+   task->oom_kill_free_check_raced = true;
+   else
+   ret = false;
+   }
+
return ret;
 }
 
-- 
1.8.3.1

What is "oom_victims counting after threads passed exit_oom_victim" ?

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

[Nate Watterson]

Hi Robin,
I am seeing a crash when performing very basic testing on this series
with a Mellanox CX4 NIC. I dug into the crash a bit, and think this
patch is the culprit, but this rcache business is still mostly
witchcraft to me.

# ifconfig eth5 up
# ifconfig eth5 down
Unable to handle kernel NULL pointer dereference at virtual address 0020
user pgtable: 64k pages, 48-bit VAs, pgd = 8007dbf47c00
[0020] *pgd=0006efab0003, *pud=0006efab0003, 
*pmd=0007d8720003, *pte=
Internal error: Oops: 9607 [#1] SMP
Modules linked in:
CPU: 47 PID: 5082 Comm: ifconfig Not tainted 4.13.0-rtp-enablement+ #3
task: 8007da1e5780 task.stack: 8007ddcb8000
PC is at __cached_rbnode_delete_update+0x2c/0x58
LR is at private_free_iova+0x2c/0x60
pc : [] lr : [] pstate: 204001c5
sp : 8007ddcbba00
x29: 8007ddcbba00 x28: 8007c8350210
x27: 8007d1a8 x26: 8007dcc20800
x25: 0140 x24: 8007c98f0008
x23: fe4e x22: 0140
x21: 8007c98f0008 x20: 8007c9adb240
x19: 8007c98f0018 x18: 0010
x17:  x16: 
x15: 4000 x14: 
x13:  x12: 0001
x11: dead0200 x10: 
x9 :  x8 : 8007c9adb1c0
x7 : 40002000 x6 : 00210d00
x5 :  x4 : c57e
x3 : ffcf x2 : ffcf
x1 : 8007c9adb240 x0 : 
[...]
[] __cached_rbnode_delete_update+0x2c/0x58
[] private_free_iova+0x2c/0x60
[] iova_magazine_free_pfns+0x4c/0xa0
[] free_iova_fast+0x1b0/0x230
[] iommu_dma_free_iova+0x5c/0x80
[] __iommu_dma_unmap+0x5c/0x98
[] iommu_dma_unmap_resource+0x24/0x30
[] iommu_dma_unmap_page+0xc/0x18
[] __iommu_unmap_page+0x40/0x60
[] mlx5e_page_release+0xbc/0x128
[] mlx5e_dealloc_rx_wqe+0x30/0x40
[] mlx5e_close_channel+0x70/0x1f8
[] mlx5e_close_channels+0x2c/0x50
[] mlx5e_close_locked+0x54/0x68
[] mlx5e_close+0x30/0x58
[...]

** Disassembly for __cached_rbnode_delete_update() near the fault **
  92|if (free->pfn_hi < iovad->dma_32bit_pfn)
0852C6C4|ldr x3,[x1,#0x18]; x3,[free,#24]
0852C6C8|ldr x2,[x0,#0x30]; x2,[iovad,#48]
0852C6CC|cmp x3,x2
0852C6D0|b.cs0x0852C708
|curr = >cached32_node;
  94|if (!curr)
0852C6D4|addsx19,x0,#0x18 ; x19,iovad,#24
0852C6D8|b.eq0x0852C708
|
|cached_iova = rb_entry(*curr, struct iova, node);
|
  99|if (free->pfn_lo >= cached_iova->pfn_lo)
0852C6DC|ldr x0,[x19] ; xiovad,[curr]
0852C6E0|ldr x2,[x1,#0x20]; x2,[free,#32]
0852C6E4|ldr x0,[x0,#0x20]; x0,[x0,#32]
Apparently cached_iova was NULL so the pfn_lo access faulted.

0852C6E8|cmp x2,x0
0852C6EC|b.cc0x0852C6FC
0852C6F0|mov x0,x1; x0,free
 100|*curr = rb_next(>node);
After instrumenting the code a bit, this seems to be the culprit. In the
previous call, free->pfn_lo was 0x_ which is actually the
dma_limit for the domain so rb_next() returns NULL.

Let me know if you have any questions or would like additional tests
run. I also applied your "DMA domain debug info" patches and dumped the
contents of the domain at each of the steps above in case that would be
useful. If nothing else, they reinforce how thirsty the CX4 NIC is
especially when using 64k pages and many CPUs.

-Nate

On 7/21/2017 7:42 AM, Robin Murphy wrote:

The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems there can be many thousands of entries in
the tree, such that traversing to the end then walking all the way down
to find free space every time becomes increasingly awful.

Maintain a similar cached node for the whole IOVA space as a superset of
the 32-bit space so that performance can remain much more consistent.

Inspired by work by Zhen Lei .

Tested-by: Ard Biesheuvel 
Tested-by: Zhen Lei 
Signed-off-by: Robin Murphy 
---

v2: No change

  drivers/iommu/iova.c | 59 +---
  include/linux/iova.h |  3 ++-
  2 files changed, 30 insertions(+), 32 deletions(-)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

[Nate Watterson]

Hi Robin,
I am seeing a crash when performing very basic testing on this series
with a Mellanox CX4 NIC. I dug into the crash a bit, and think this
patch is the culprit, but this rcache business is still mostly
witchcraft to me.

# ifconfig eth5 up
# ifconfig eth5 down
Unable to handle kernel NULL pointer dereference at virtual address 0020
user pgtable: 64k pages, 48-bit VAs, pgd = 8007dbf47c00
[0020] *pgd=0006efab0003, *pud=0006efab0003, 
*pmd=0007d8720003, *pte=
Internal error: Oops: 9607 [#1] SMP
Modules linked in:
CPU: 47 PID: 5082 Comm: ifconfig Not tainted 4.13.0-rtp-enablement+ #3
task: 8007da1e5780 task.stack: 8007ddcb8000
PC is at __cached_rbnode_delete_update+0x2c/0x58
LR is at private_free_iova+0x2c/0x60
pc : [] lr : [] pstate: 204001c5
sp : 8007ddcbba00
x29: 8007ddcbba00 x28: 8007c8350210
x27: 8007d1a8 x26: 8007dcc20800
x25: 0140 x24: 8007c98f0008
x23: fe4e x22: 0140
x21: 8007c98f0008 x20: 8007c9adb240
x19: 8007c98f0018 x18: 0010
x17:  x16: 
x15: 4000 x14: 
x13:  x12: 0001
x11: dead0200 x10: 
x9 :  x8 : 8007c9adb1c0
x7 : 40002000 x6 : 00210d00
x5 :  x4 : c57e
x3 : ffcf x2 : ffcf
x1 : 8007c9adb240 x0 : 
[...]
[] __cached_rbnode_delete_update+0x2c/0x58
[] private_free_iova+0x2c/0x60
[] iova_magazine_free_pfns+0x4c/0xa0
[] free_iova_fast+0x1b0/0x230
[] iommu_dma_free_iova+0x5c/0x80
[] __iommu_dma_unmap+0x5c/0x98
[] iommu_dma_unmap_resource+0x24/0x30
[] iommu_dma_unmap_page+0xc/0x18
[] __iommu_unmap_page+0x40/0x60
[] mlx5e_page_release+0xbc/0x128
[] mlx5e_dealloc_rx_wqe+0x30/0x40
[] mlx5e_close_channel+0x70/0x1f8
[] mlx5e_close_channels+0x2c/0x50
[] mlx5e_close_locked+0x54/0x68
[] mlx5e_close+0x30/0x58
[...]

** Disassembly for __cached_rbnode_delete_update() near the fault **
  92|if (free->pfn_hi < iovad->dma_32bit_pfn)
0852C6C4|ldr x3,[x1,#0x18]; x3,[free,#24]
0852C6C8|ldr x2,[x0,#0x30]; x2,[iovad,#48]
0852C6CC|cmp x3,x2
0852C6D0|b.cs0x0852C708
|curr = >cached32_node;
  94|if (!curr)
0852C6D4|addsx19,x0,#0x18 ; x19,iovad,#24
0852C6D8|b.eq0x0852C708
|
|cached_iova = rb_entry(*curr, struct iova, node);
|
  99|if (free->pfn_lo >= cached_iova->pfn_lo)
0852C6DC|ldr x0,[x19] ; xiovad,[curr]
0852C6E0|ldr x2,[x1,#0x20]; x2,[free,#32]
0852C6E4|ldr x0,[x0,#0x20]; x0,[x0,#32]
Apparently cached_iova was NULL so the pfn_lo access faulted.

0852C6E8|cmp x2,x0
0852C6EC|b.cc0x0852C6FC
0852C6F0|mov x0,x1; x0,free
 100|*curr = rb_next(>node);
After instrumenting the code a bit, this seems to be the culprit. In the
previous call, free->pfn_lo was 0x_ which is actually the
dma_limit for the domain so rb_next() returns NULL.

Let me know if you have any questions or would like additional tests
run. I also applied your "DMA domain debug info" patches and dumped the
contents of the domain at each of the steps above in case that would be
useful. If nothing else, they reinforce how thirsty the CX4 NIC is
especially when using 64k pages and many CPUs.

-Nate

On 7/21/2017 7:42 AM, Robin Murphy wrote:

The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems there can be many thousands of entries in
the tree, such that traversing to the end then walking all the way down
to find free space every time becomes increasingly awful.

Maintain a similar cached node for the whole IOVA space as a superset of
the 32-bit space so that performance can remain much more consistent.

Inspired by work by Zhen Lei .

Tested-by: Ard Biesheuvel 
Tested-by: Zhen Lei 
Signed-off-by: Robin Murphy 
---

v2: No change

  drivers/iommu/iova.c | 59 +---
  include/linux/iova.h |  3 ++-
  2 files changed, 30 insertions(+), 32 deletions(-)

diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index d094d1ca8f23..f5809a2ee6c2 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -46,6 +46,7 @@ 

Business Proposal

[Adrien Saif]

Dear Friend,I would like to discuss a very important issue with you. I am 
writing to find out if this is your valid email. Please let me know if this 
email is valid Regards
Adrien Saif
Attorney to Quatif Group of Companies

Business Proposal

[Adrien Saif]

Dear Friend,I would like to discuss a very important issue with you. I am 
writing to find out if this is your valid email. Please let me know if this 
email is valid Regards
Adrien Saif
Attorney to Quatif Group of Companies

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 07:59:12PM +, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Jul 28, 2017 at 01:57:20PM -0500, Josh Poimboeuf wrote:
> >Thanks, that's much better.  I'm relieved the unwinder didn't screw that
> >up, at least.
> >
> >This looks like a tricky one.  Is it easily recreatable?
> 
> Yeah, I just hit it again with slightly different initial calls:

Sasha sent me some data privately.  As I suspected, the cause is some
bad ORC data.  Objtool incorrectly assumes that once the frame pointer
is set up, it no longer gets touched.

For example:

  81820680 :
  81820680:   41 56   push   %r14
  81820682:   41 55   push   %r13
  81820684:   41 54   push   %r12
  81820686:   49 89 fcmov%rdi,%r12
  81820689:   55  push   %rbp
  8182068a:   53  push   %rbx
  8182068b:   48 bb 00 00 00 00 00movabs 
$0xdc00,%rbx
  81820692:   fc ff df
  81820695:   48 83 c4 80 add
$0xff80,%rsp
  81820699:   48 89 e5mov%rsp,%rbp
  8182069c:   48 c7 04 24 b3 8a b5movq   $0x41b58ab3,(%rsp)
  818206a3:   41
  818206a4:   48 c7 44 24 08 07 a5movq   
$0x8621a507,0x8(%rsp)
  818206ab:   21 86
  818206a9: R_X86_64_32S  .rodata+0xa1a507
  818206ad:   48 c1 ed 03 shr$0x3,%rbp

In this case, rbp was pushed ("push %rbp") and then replaced with rsp
("mov %rsp, %rbp"), which is the normal frame pointer setup.  But then
rbp was modified ("shr 0x3, %rbp"), which objtool didn't expect.

Objtool will need to be made smarter here somehow.  I'll be on vacation
next week so it might be a week or so before I can come up with the fix.

Despite the scary KASAN warning, this is only a minor bug.  The ORC data
isn't perfect yet, so these types of issues will happen until we get the
kinks worked out.  The good news is the unwinder recovered from the bad
ORC data gracefully, and the oops dump still showed the rest of the
addresses (with question marks).

-- 
Josh

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 07:59:12PM +, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Jul 28, 2017 at 01:57:20PM -0500, Josh Poimboeuf wrote:
> >Thanks, that's much better.  I'm relieved the unwinder didn't screw that
> >up, at least.
> >
> >This looks like a tricky one.  Is it easily recreatable?
> 
> Yeah, I just hit it again with slightly different initial calls:

Sasha sent me some data privately.  As I suspected, the cause is some
bad ORC data.  Objtool incorrectly assumes that once the frame pointer
is set up, it no longer gets touched.

For example:

  81820680 :
  81820680:   41 56   push   %r14
  81820682:   41 55   push   %r13
  81820684:   41 54   push   %r12
  81820686:   49 89 fcmov%rdi,%r12
  81820689:   55  push   %rbp
  8182068a:   53  push   %rbx
  8182068b:   48 bb 00 00 00 00 00movabs 
$0xdc00,%rbx
  81820692:   fc ff df
  81820695:   48 83 c4 80 add
$0xff80,%rsp
  81820699:   48 89 e5mov%rsp,%rbp
  8182069c:   48 c7 04 24 b3 8a b5movq   $0x41b58ab3,(%rsp)
  818206a3:   41
  818206a4:   48 c7 44 24 08 07 a5movq   
$0x8621a507,0x8(%rsp)
  818206ab:   21 86
  818206a9: R_X86_64_32S  .rodata+0xa1a507
  818206ad:   48 c1 ed 03 shr$0x3,%rbp

In this case, rbp was pushed ("push %rbp") and then replaced with rsp
("mov %rsp, %rbp"), which is the normal frame pointer setup.  But then
rbp was modified ("shr 0x3, %rbp"), which objtool didn't expect.

Objtool will need to be made smarter here somehow.  I'll be on vacation
next week so it might be a week or so before I can come up with the fix.

Despite the scary KASAN warning, this is only a minor bug.  The ORC data
isn't perfect yet, so these types of issues will happen until we get the
kinks worked out.  The good news is the unwinder recovered from the bad
ORC data gracefully, and the oops dump still showed the rest of the
addresses (with question marks).

-- 
Josh

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

[Joel Fernandes]

On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar  wrote:
> On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU
> from policy-A can change frequency of CPUs belonging to policy-B.
>
> This is quite common in case of ARM platforms where we don't
> configure any per-cpu register.
>
> Add a flag to identify such platforms and update
> cpufreq_can_do_remote_dvfs() to allow remote callbacks if this flag is
> set.
>
> Also enable the flag for cpufreq-dt driver which is used only on ARM
> platforms currently.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/cpufreq-dt.c |  1 +
>  include/linux/cpufreq.h  | 18 --
>  2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index fef3c2160691..d83ab94d041a 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -274,6 +274,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> transition_latency = CPUFREQ_ETERNAL;
>
> policy->cpuinfo.transition_latency = transition_latency;
> +   policy->dvfs_possible_from_any_cpu = true;
>

Are there also ARM hardware that may not support it? If yes, wouldn't
a saner thing to do be to keep default as false and read the property
from DT for hardware that does support it and then set to true?

thanks,

-Joel

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

[Joel Fernandes]

On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar  wrote:
> On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU
> from policy-A can change frequency of CPUs belonging to policy-B.
>
> This is quite common in case of ARM platforms where we don't
> configure any per-cpu register.
>
> Add a flag to identify such platforms and update
> cpufreq_can_do_remote_dvfs() to allow remote callbacks if this flag is
> set.
>
> Also enable the flag for cpufreq-dt driver which is used only on ARM
> platforms currently.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/cpufreq-dt.c |  1 +
>  include/linux/cpufreq.h  | 18 --
>  2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index fef3c2160691..d83ab94d041a 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -274,6 +274,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> transition_latency = CPUFREQ_ETERNAL;
>
> policy->cpuinfo.transition_latency = transition_latency;
> +   policy->dvfs_possible_from_any_cpu = true;
>

Are there also ARM hardware that may not support it? If yes, wouldn't
a saner thing to do be to keep default as false and read the property
from DT for hardware that does support it and then set to true?

thanks,

-Joel

Re: [PATCH 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

[Ryder Lee]

On Fri, 2017-07-28 at 12:20 +0300, Sergei Shtylyov wrote:
> > +Required properties:
> > + - compatible : Must be "mediatek,ahci".
> > + - reg: Physical base addresses and length of register 
> > sets.
> > + - interrupts : Interrupt associated with the SATA device.
> > + - interrupt-names : Associated name must be: "hostc".
> > + - clocks : The phandle for the clock.
> 
> Your example shows that you need both phandle and specifier (afetr 
> phandle).
> 
> > + - clock-names: Associated name must be: "ahb", "axi", "asic", 
> > "rbc", "pm"
> > + - phys   : The phandle for the PHY port.
> 
>  Likewise.

Oh yeah, I forgot about that.

> > + - phy-names  : Associated name must be: "sata-phy".
> > + - ports-implemented : Mask that indicates which ports that the HBA 
> > supports
> > +  are available for software to use. Useful if PORTS_IMPL
> > +  is not programmed by the BIOS, which is true with some
> > +  embedded SOC's.
> 
> An empty line wouldn't hurt here...

Okay.

> > +Optional properties:
> > + - power-domains   : A phandle and power domain specifier pair to the power
> > +domain which is responsible for collapsing and restoring
> > +power to the peripheral.
> > + - resets : Must contain an entry for each entry in reset-names.
> > +See ../reset/reset.txt for details.
> > + - reset-names: Associated names must be: "axi-rst", "sw-rst", 
> > "reg-rst".
> > + - mediatek,phy-mode : A phandle to the system controller, used to enable
> > +  SATA function.

Thanks!
Ryder.

Re: [PATCH 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller

[Ryder Lee]

On Fri, 2017-07-28 at 12:20 +0300, Sergei Shtylyov wrote:
> > +Required properties:
> > + - compatible : Must be "mediatek,ahci".
> > + - reg: Physical base addresses and length of register 
> > sets.
> > + - interrupts : Interrupt associated with the SATA device.
> > + - interrupt-names : Associated name must be: "hostc".
> > + - clocks : The phandle for the clock.
> 
> Your example shows that you need both phandle and specifier (afetr 
> phandle).
> 
> > + - clock-names: Associated name must be: "ahb", "axi", "asic", 
> > "rbc", "pm"
> > + - phys   : The phandle for the PHY port.
> 
>  Likewise.

Oh yeah, I forgot about that.

> > + - phy-names  : Associated name must be: "sata-phy".
> > + - ports-implemented : Mask that indicates which ports that the HBA 
> > supports
> > +  are available for software to use. Useful if PORTS_IMPL
> > +  is not programmed by the BIOS, which is true with some
> > +  embedded SOC's.
> 
> An empty line wouldn't hurt here...

Okay.

> > +Optional properties:
> > + - power-domains   : A phandle and power domain specifier pair to the power
> > +domain which is responsible for collapsing and restoring
> > +power to the peripheral.
> > + - resets : Must contain an entry for each entry in reset-names.
> > +See ../reset/reset.txt for details.
> > + - reset-names: Associated names must be: "axi-rst", "sw-rst", 
> > "reg-rst".
> > + - mediatek,phy-mode : A phandle to the system controller, used to enable
> > +  SATA function.

Thanks!
Ryder.

Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86: ORC unwinder)

[Andy Lutomirski]

> On Jul 25, 2017, at 7:55 AM, Peter Zijlstra  wrote:
>
>> On Thu, Jul 13, 2017 at 11:19:11AM +0200, Ingo Molnar wrote:
>>
>> * Peter Zijlstra  wrote:
>>
 One gloriously ugly hack would be to delay the userspace unwind to
 return-to-userspace, at which point we have a schedulable context and can 
 take
 faults.
>>
>> I don't think it's ugly, and it has various advantages:
>>
 Of course, then you have to somehow identify this later unwind sample with 
 all
 relevant prior samples and stitch the whole thing back together, but that
 should be doable.

 In fact, it would not be at all hard to do, just queue a task_work from the
 NMI and have that do the EH based unwind.
>>

I haven't checked task_work specifically, but a bunch of the exit work
is permitted to sleep, which is potentially useful.

If this becomes successful enough that we could eventually deprecate
the old code, I wonder if copy_from_user_nmi() could go away? :)

>
> ---
> include/linux/perf_event.h  |  1 +
> include/uapi/linux/perf_event.h | 14 ++-
> kernel/events/callchain.c   | 86 ++---
> kernel/events/core.c| 18 +++--
> 4 files changed, 100 insertions(+), 19 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index a3b873fc59e4..241251533e39 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -682,6 +682,7 @@ struct perf_event {
>intpending_disable;
>struct irq_workpending;
>
> +struct callback_headpending_callchain;
>atomic_tevent_limit;
>
>/* address range filters */
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 642db5fa3286..342def57ef34 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -368,7 +368,8 @@ struct perf_event_attr {
>context_switch :  1, /* context switch data */
>write_backward :  1, /* Write ring buffer from end to 
> beginning */
>namespaces :  1, /* include namespaces data */
> -__reserved_1   : 35;
> +delayed_user_callchain   : 1, /* ... */
> +__reserved_1   : 34;
>
>union {
>__u32wakeup_events;  /* wakeup every n events */
> @@ -915,6 +916,17 @@ enum perf_event_type {
> */
>PERF_RECORD_NAMESPACES= 16,
>
> +/*
> + * struct {
> + *struct perf_event_headerheader;
> + *{ u64nr,
> + *  u64ips[nr];  } && PERF_SAMPLE_CALLCHAIN
> + *struct sample_idsample_id;
> + * };
> + *
> + */
> +PERF_RECORD_CALLCHAIN= 17,
> +
>PERF_RECORD_MAX,/* non-ABI */
> };
>
> diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
> index 1b2be63c8528..c98a12f3592c 100644
> --- a/kernel/events/callchain.c
> +++ b/kernel/events/callchain.c
> @@ -12,6 +12,7 @@
> #include 
> #include 
> #include 
> +#include 
>
> #include "internal.h"
>
> @@ -178,19 +179,94 @@ put_callchain_entry(int rctx)
>put_recursion_context(this_cpu_ptr(callchain_recursion), rctx);
> }
>
> +static struct perf_callchain_entry __empty = { .nr = 0, };
> +
> +static void perf_callchain_work(struct callback_head *work)
> +{
> +struct perf_event *event = container_of(work, struct perf_event, 
> pending_callchain);
> +struct perf_output_handle handle;
> +struct perf_sample_data sample;
> +size_t size;
> +int ret;
> +
> +struct {
> +struct perf_event_headerheader;
> +} callchain_event = {
> +.header = {
> +.type = PERF_RECORD_CALLCHAIN,
> +.misc = 0,
> +.size = sizeof(callchain_event),
> +},
> +};
> +
> +perf_event_header__init_id(_event.header, , event);
> +
> +sample.callchain = get_perf_callchain(task_pt_regs(current),
> +  /* init_nr   */ 0,
> +  /* kernel*/ false,
> +  /* user  */ true,
> +  event->attr.sample_max_stack,
> +  /* crosstask */ false,
> +  /* add_mark  */ true);
> +
> +if (!sample.callchain)
> +sample.callchain = &__empty;
> +
> +size = sizeof(u64) * (1 + sample.callchain->nr);
> +callchain_event.header.size += size;
> +
> +ret = perf_output_begin(, event, callchain_event.header.size);
> +if (ret)
> +return;
> +
> +perf_output_put(, callchain_event);
> +__output_copy(, sample.callchain, size);
> +perf_event__output_id_sample(event, , );
> +perf_output_end();
> +
> +barrier();
> +work->func = NULL; /* done */
> +}
> +
> struct perf_callchain_entry *
> perf_callchain(struct perf_event *event, struct pt_regs *regs)
> {
> -

Re: [RFC] perf: Delayed userspace unwind (Was: [PATCH v3 00/10] x86: ORC unwinder)

[Andy Lutomirski]

> On Jul 25, 2017, at 7:55 AM, Peter Zijlstra  wrote:
>
>> On Thu, Jul 13, 2017 at 11:19:11AM +0200, Ingo Molnar wrote:
>>
>> * Peter Zijlstra  wrote:
>>
 One gloriously ugly hack would be to delay the userspace unwind to
 return-to-userspace, at which point we have a schedulable context and can 
 take
 faults.
>>
>> I don't think it's ugly, and it has various advantages:
>>
 Of course, then you have to somehow identify this later unwind sample with 
 all
 relevant prior samples and stitch the whole thing back together, but that
 should be doable.

 In fact, it would not be at all hard to do, just queue a task_work from the
 NMI and have that do the EH based unwind.
>>

I haven't checked task_work specifically, but a bunch of the exit work
is permitted to sleep, which is potentially useful.

If this becomes successful enough that we could eventually deprecate
the old code, I wonder if copy_from_user_nmi() could go away? :)

>
> ---
> include/linux/perf_event.h  |  1 +
> include/uapi/linux/perf_event.h | 14 ++-
> kernel/events/callchain.c   | 86 ++---
> kernel/events/core.c| 18 +++--
> 4 files changed, 100 insertions(+), 19 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index a3b873fc59e4..241251533e39 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -682,6 +682,7 @@ struct perf_event {
>intpending_disable;
>struct irq_workpending;
>
> +struct callback_headpending_callchain;
>atomic_tevent_limit;
>
>/* address range filters */
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 642db5fa3286..342def57ef34 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -368,7 +368,8 @@ struct perf_event_attr {
>context_switch :  1, /* context switch data */
>write_backward :  1, /* Write ring buffer from end to 
> beginning */
>namespaces :  1, /* include namespaces data */
> -__reserved_1   : 35;
> +delayed_user_callchain   : 1, /* ... */
> +__reserved_1   : 34;
>
>union {
>__u32wakeup_events;  /* wakeup every n events */
> @@ -915,6 +916,17 @@ enum perf_event_type {
> */
>PERF_RECORD_NAMESPACES= 16,
>
> +/*
> + * struct {
> + *struct perf_event_headerheader;
> + *{ u64nr,
> + *  u64ips[nr];  } && PERF_SAMPLE_CALLCHAIN
> + *struct sample_idsample_id;
> + * };
> + *
> + */
> +PERF_RECORD_CALLCHAIN= 17,
> +
>PERF_RECORD_MAX,/* non-ABI */
> };
>
> diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
> index 1b2be63c8528..c98a12f3592c 100644
> --- a/kernel/events/callchain.c
> +++ b/kernel/events/callchain.c
> @@ -12,6 +12,7 @@
> #include 
> #include 
> #include 
> +#include 
>
> #include "internal.h"
>
> @@ -178,19 +179,94 @@ put_callchain_entry(int rctx)
>put_recursion_context(this_cpu_ptr(callchain_recursion), rctx);
> }
>
> +static struct perf_callchain_entry __empty = { .nr = 0, };
> +
> +static void perf_callchain_work(struct callback_head *work)
> +{
> +struct perf_event *event = container_of(work, struct perf_event, 
> pending_callchain);
> +struct perf_output_handle handle;
> +struct perf_sample_data sample;
> +size_t size;
> +int ret;
> +
> +struct {
> +struct perf_event_headerheader;
> +} callchain_event = {
> +.header = {
> +.type = PERF_RECORD_CALLCHAIN,
> +.misc = 0,
> +.size = sizeof(callchain_event),
> +},
> +};
> +
> +perf_event_header__init_id(_event.header, , event);
> +
> +sample.callchain = get_perf_callchain(task_pt_regs(current),
> +  /* init_nr   */ 0,
> +  /* kernel*/ false,
> +  /* user  */ true,
> +  event->attr.sample_max_stack,
> +  /* crosstask */ false,
> +  /* add_mark  */ true);
> +
> +if (!sample.callchain)
> +sample.callchain = &__empty;
> +
> +size = sizeof(u64) * (1 + sample.callchain->nr);
> +callchain_event.header.size += size;
> +
> +ret = perf_output_begin(, event, callchain_event.header.size);
> +if (ret)
> +return;
> +
> +perf_output_put(, callchain_event);
> +__output_copy(, sample.callchain, size);
> +perf_event__output_id_sample(event, , );
> +perf_output_end();
> +
> +barrier();
> +work->func = NULL; /* done */
> +}
> +
> struct perf_callchain_entry *
> perf_callchain(struct perf_event *event, struct pt_regs *regs)
> {
> -bool kernel = 

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

[Mike Galbraith]

On Sat, 2017-07-29 at 04:48 +0200, Mike Galbraith wrote:
> On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote:
> > 
> > Structure
> > 
> > The first patch cleans up the different loadavg callsites and macros
> > as the memdelay averages are going to be tracked using these.
> > 
> > The second patch adds a distinction between page cache transitions
> > (inactive list refaults) and page cache thrashing (active list
> > refaults), since only the latter are unproductive refaults.
> > 
> > The third patch finally adds the memdelay accounting and interface:
> > its scheduler side identifies productive and unproductive task states,
> > and the VM side aggregates them into system and cgroup domain states
> > and calculates moving averages of the time spent in each state.
> 
> What tree is this against?  ttwu asm delta says "measure me".

(mm/master.. gee)

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

[Mike Galbraith]

On Sat, 2017-07-29 at 04:48 +0200, Mike Galbraith wrote:
> On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote:
> > 
> > Structure
> > 
> > The first patch cleans up the different loadavg callsites and macros
> > as the memdelay averages are going to be tracked using these.
> > 
> > The second patch adds a distinction between page cache transitions
> > (inactive list refaults) and page cache thrashing (active list
> > refaults), since only the latter are unproductive refaults.
> > 
> > The third patch finally adds the memdelay accounting and interface:
> > its scheduler side identifies productive and unproductive task states,
> > and the VM side aggregates them into system and cgroup domain states
> > and calculates moving averages of the time spent in each state.
> 
> What tree is this against?  ttwu asm delta says "measure me".

(mm/master.. gee)

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

[Mike Galbraith]

On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote:
> 
> Structure
> 
> The first patch cleans up the different loadavg callsites and macros
> as the memdelay averages are going to be tracked using these.
> 
> The second patch adds a distinction between page cache transitions
> (inactive list refaults) and page cache thrashing (active list
> refaults), since only the latter are unproductive refaults.
> 
> The third patch finally adds the memdelay accounting and interface:
> its scheduler side identifies productive and unproductive task states,
> and the VM side aggregates them into system and cgroup domain states
> and calculates moving averages of the time spent in each state.

What tree is this against?  ttwu asm delta says "measure me".

-Mike

Re: [PATCH 0/3] memdelay: memory health metric for systems and workloads

[Mike Galbraith]

On Thu, 2017-07-27 at 11:30 -0400, Johannes Weiner wrote:
> 
> Structure
> 
> The first patch cleans up the different loadavg callsites and macros
> as the memdelay averages are going to be tracked using these.
> 
> The second patch adds a distinction between page cache transitions
> (inactive list refaults) and page cache thrashing (active list
> refaults), since only the latter are unproductive refaults.
> 
> The third patch finally adds the memdelay accounting and interface:
> its scheduler side identifies productive and unproductive task states,
> and the VM side aggregates them into system and cgroup domain states
> and calculates moving averages of the time spent in each state.

What tree is this against?  ttwu asm delta says "measure me".

-Mike

[PATCH] ipmi: fix unsigned long overflow

[Weilong Chen]

When I set the timeout to a specific value such as 500ms, the timeout
event will not happen in time due to the overflow in function
check_msg_timeout:
...
ent->timeout -= timeout_period;
if (ent->timeout > 0)
return;
...

The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.

Signed-off-by: Weilong Chen 
---
 drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 810b138..4c806e9 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -135,8 +135,8 @@ struct seq_table {
unsigned int inuse : 1;
unsigned int broadcast : 1;
 
-   unsigned longtimeout;
-   unsigned longorig_timeout;
+   longtimeout;
+   longorig_timeout;
unsigned int retries_left;
 
/*
-- 
1.8.3.1

[PATCH] ipmi: fix unsigned long overflow

[Weilong Chen]

When I set the timeout to a specific value such as 500ms, the timeout
event will not happen in time due to the overflow in function
check_msg_timeout:
...
ent->timeout -= timeout_period;
if (ent->timeout > 0)
return;
...

The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.

Signed-off-by: Weilong Chen 
---
 drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 810b138..4c806e9 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -135,8 +135,8 @@ struct seq_table {
unsigned int inuse : 1;
unsigned int broadcast : 1;
 
-   unsigned longtimeout;
-   unsigned longorig_timeout;
+   longtimeout;
+   longorig_timeout;
unsigned int retries_left;
 
/*
-- 
1.8.3.1

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

[Alan Stern]

On Fri, 28 Jul 2017, Zdenek Kabelac wrote:

> Dne 28.7.2017 v 20:33 Alan Stern napsal(a):
> > On Thu, 27 Jul 2017, Zdenek Kabelac wrote:
> > 
> >>> Zdenek, you check this explanation by commenting out these last two
> >>> lines at the end of hub_port_connect() in drivers/usb/core/hub.c:
> >>>
> >>>   if (hcd->driver->relinquish_port && !hub->hdev->parent)
> >>>   hcd->driver->relinquish_port(hcd, port1);
> >>>
> >>> That should prevent the connection from being handed over to the UHCI
> >>> companion, allowing the device to operate at high speed.
> >>>
> >>
> >> Hi
> >>
> >> Yep - seems this helped - I've dropped revert and commented those 2 lines
> >> and I've used the very same kernel - and speed was all good:
> >>
> >> usb 2-2: new high-speed USB device number 2 using ehci-pci
> >> usb 2-2: new high-speed USB device number 3 using ehci-pci
> >> usb 2-2: New USB device found, idVendor=1058, idProduct=10a8
> >> usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >>
> >>
> >> So while I'm not sure if this is final fix for USB - this solution surely
> >> solved my WD Element disk attachment issue.
> > 
> > Great!  Here's a real patch to test; I think this will be acceptable if
> > it fixes your problem.
> > 
> > Alan Stern
> > 
> > 
> > 
> > Index: usb-4.x/drivers/usb/core/hub.c
> > ===
> > --- usb-4.x.orig/drivers/usb/core/hub.c
> > +++ usb-4.x/drivers/usb/core/hub.c
> > @@ -4934,9 +4934,10 @@ loop:
> >   
> >   done:
> > hub_port_disable(hub, port1, 1);
> > -   if (hcd->driver->relinquish_port && !hub->hdev->parent)
> > -   hcd->driver->relinquish_port(hcd, port1);
> > -
> > +   if (hcd->driver->relinquish_port && !hub->hdev->parent) {
> > +   if (status != -ENOTCONN && status != -ENODEV)
> > +   hcd->driver->relinquish_port(hcd, port1);
> > +   }
> >   }
> >   
> >   /* Handle physical or logical connection change events.
> > 
> 
> 
> Hi
> 
> Yep - still good speed - however compilation reported this Warning:
> 
> drivers/usb/core/hub.c:4933:37: warning: ‘status’ may be used uninitialized 
> in 
> this function [-Wmaybe-uninitialized]
> if (status != -ENOTCONN && status != -ENODEV)
> drivers/usb/core/hub.c:4728:6: note: ‘status’ was declared here
>int status, i;
> 
> 
> So I've just made assignment of 'status = 0' at declaration place -
> but then you have some other unneeded assigns of =0 left around...
> so possibly worth some minor cleanup...

The initialization actually should be -ENODEV.  I have changed the 
patch and will submit it after the weekend.

Alan Stern

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

[Alan Stern]

On Fri, 28 Jul 2017, Zdenek Kabelac wrote:

> Dne 28.7.2017 v 20:33 Alan Stern napsal(a):
> > On Thu, 27 Jul 2017, Zdenek Kabelac wrote:
> > 
> >>> Zdenek, you check this explanation by commenting out these last two
> >>> lines at the end of hub_port_connect() in drivers/usb/core/hub.c:
> >>>
> >>>   if (hcd->driver->relinquish_port && !hub->hdev->parent)
> >>>   hcd->driver->relinquish_port(hcd, port1);
> >>>
> >>> That should prevent the connection from being handed over to the UHCI
> >>> companion, allowing the device to operate at high speed.
> >>>
> >>
> >> Hi
> >>
> >> Yep - seems this helped - I've dropped revert and commented those 2 lines
> >> and I've used the very same kernel - and speed was all good:
> >>
> >> usb 2-2: new high-speed USB device number 2 using ehci-pci
> >> usb 2-2: new high-speed USB device number 3 using ehci-pci
> >> usb 2-2: New USB device found, idVendor=1058, idProduct=10a8
> >> usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >>
> >>
> >> So while I'm not sure if this is final fix for USB - this solution surely
> >> solved my WD Element disk attachment issue.
> > 
> > Great!  Here's a real patch to test; I think this will be acceptable if
> > it fixes your problem.
> > 
> > Alan Stern
> > 
> > 
> > 
> > Index: usb-4.x/drivers/usb/core/hub.c
> > ===
> > --- usb-4.x.orig/drivers/usb/core/hub.c
> > +++ usb-4.x/drivers/usb/core/hub.c
> > @@ -4934,9 +4934,10 @@ loop:
> >   
> >   done:
> > hub_port_disable(hub, port1, 1);
> > -   if (hcd->driver->relinquish_port && !hub->hdev->parent)
> > -   hcd->driver->relinquish_port(hcd, port1);
> > -
> > +   if (hcd->driver->relinquish_port && !hub->hdev->parent) {
> > +   if (status != -ENOTCONN && status != -ENODEV)
> > +   hcd->driver->relinquish_port(hcd, port1);
> > +   }
> >   }
> >   
> >   /* Handle physical or logical connection change events.
> > 
> 
> 
> Hi
> 
> Yep - still good speed - however compilation reported this Warning:
> 
> drivers/usb/core/hub.c:4933:37: warning: ‘status’ may be used uninitialized 
> in 
> this function [-Wmaybe-uninitialized]
> if (status != -ENOTCONN && status != -ENODEV)
> drivers/usb/core/hub.c:4728:6: note: ‘status’ was declared here
>int status, i;
> 
> 
> So I've just made assignment of 'status = 0' at declaration place -
> but then you have some other unneeded assigns of =0 left around...
> so possibly worth some minor cleanup...

The initialization actually should be -ENODEV.  I have changed the 
patch and will submit it after the weekend.

Alan Stern

Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

[David Miller]

From: Alexandru Gagniuc 
Date: Fri, 28 Jul 2017 15:07:03 -0700

> Before the GMAC on the Anarion chip can be used, the PHY interface
> selection must be configured with the DWMAC block in reset.
> 
> This layer covers a block containing only two registers. Although it
> is possible to model this as a reset controller and use the "resets"
> property of stmmac, it's much more intuitive to include this in the
> glue layer instead.
> 
> At this time only RGMII is supported, because it is the only mode
> which has been validated hardware-wise.
> 
> Signed-off-by: Alexandru Gagniuc 

I don't see how this fits into any patch series at all.  If this is
part of a series you posted elsewhere, you should keep netdev@ on
all such postings so people there can review the change in-context.

Thanks.

Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

[David Miller]

From: Alexandru Gagniuc 
Date: Fri, 28 Jul 2017 15:07:03 -0700

> Before the GMAC on the Anarion chip can be used, the PHY interface
> selection must be configured with the DWMAC block in reset.
> 
> This layer covers a block containing only two registers. Although it
> is possible to model this as a reset controller and use the "resets"
> property of stmmac, it's much more intuitive to include this in the
> glue layer instead.
> 
> At this time only RGMII is supported, because it is the only mode
> which has been validated hardware-wise.
> 
> Signed-off-by: Alexandru Gagniuc 

I don't see how this fits into any patch series at all.  If this is
part of a series you posted elsewhere, you should keep netdev@ on
all such postings so people there can review the change in-context.

Thanks.

Re: [RFC PATCH v2] membarrier: expedited private command

[Nicholas Piggin]

On Fri, 28 Jul 2017 17:06:53 + (UTC)
Mathieu Desnoyers  wrote:

> - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote:
> 
> > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote:  
> >> > Which only leaves PPC stranded.. but the 'good' news is that mpe says
> >> > they'll probably need a barrier in switch_mm() in any case.  
> >> 
> >> As I pointed out in my other email, I plan to do this:
> >> 
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -2636,6 +2636,11 @@ static struct rq *finish_task_switch(struct 
> >> task_struct
> >> *prev)
> >> vtime_task_switch(prev);
> >> perf_event_task_sched_in(prev, current);  
> > 
> > Here would place it _inside_ the rq->lock, which seems to make more
> > sense given the purpose of the barrier, but either way works given its
> > definition.  
> 
> Given its naming "...after_unlock_lock", I thought it would be clearer to put
> it after the unlock. Anyway, this barrier does not seem to be used to ensure
> the release barrier per se (unlock already has release semantic), but rather
> ensures a full memory barrier wrt memory accesses that are synchronized by
> means other than this this lock.
> 
> >   
> >> finish_lock_switch(rq, prev);  
> > 
> > You could put the whole thing inside IS_ENABLED(CONFIG_SYSMEMBARRIER) or
> > something.  
> 
> I'm tempted to wait until we hear from powerpc maintainers, so we learn
> whether they deeply care about this extra barrier in finish_task_switch()
> before making it conditional on CONFIG_MEMBARRIER.
> 
> Having a guaranteed barrier after context switch on all architectures may
> have other uses.

I haven't had time to read the thread and understand exactly why you need
this extra barrier, I'll do it next week. Thanks for cc'ing us on it.

A smp_mb is pretty expensive on powerpc CPUs. Removing the sync from
switch_to increased thread switch performance by 2-3%. Putting it in
switch_mm may be a little less painful, but still we have to weigh it
against the benefit of this new functionality. Would that be a net win
for the average end-user? Seems unlikely.

But we also don't want to lose sys_membarrier completely. Would it be too
painful to make  MEMBARRIER_CMD_PRIVATE_EXPEDITED return error, or make it
fall back to a slower case if we decide not to implement it?

Thanks,
Nick

Re: [RFC PATCH v2] membarrier: expedited private command

[Nicholas Piggin]

On Fri, 28 Jul 2017 17:06:53 + (UTC)
Mathieu Desnoyers  wrote:

> - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote:
> 
> > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote:  
> >> > Which only leaves PPC stranded.. but the 'good' news is that mpe says
> >> > they'll probably need a barrier in switch_mm() in any case.  
> >> 
> >> As I pointed out in my other email, I plan to do this:
> >> 
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -2636,6 +2636,11 @@ static struct rq *finish_task_switch(struct 
> >> task_struct
> >> *prev)
> >> vtime_task_switch(prev);
> >> perf_event_task_sched_in(prev, current);  
> > 
> > Here would place it _inside_ the rq->lock, which seems to make more
> > sense given the purpose of the barrier, but either way works given its
> > definition.  
> 
> Given its naming "...after_unlock_lock", I thought it would be clearer to put
> it after the unlock. Anyway, this barrier does not seem to be used to ensure
> the release barrier per se (unlock already has release semantic), but rather
> ensures a full memory barrier wrt memory accesses that are synchronized by
> means other than this this lock.
> 
> >   
> >> finish_lock_switch(rq, prev);  
> > 
> > You could put the whole thing inside IS_ENABLED(CONFIG_SYSMEMBARRIER) or
> > something.  
> 
> I'm tempted to wait until we hear from powerpc maintainers, so we learn
> whether they deeply care about this extra barrier in finish_task_switch()
> before making it conditional on CONFIG_MEMBARRIER.
> 
> Having a guaranteed barrier after context switch on all architectures may
> have other uses.

I haven't had time to read the thread and understand exactly why you need
this extra barrier, I'll do it next week. Thanks for cc'ing us on it.

A smp_mb is pretty expensive on powerpc CPUs. Removing the sync from
switch_to increased thread switch performance by 2-3%. Putting it in
switch_mm may be a little less painful, but still we have to weigh it
against the benefit of this new functionality. Would that be a net win
for the average end-user? Seems unlikely.

But we also don't want to lose sys_membarrier completely. Would it be too
painful to make  MEMBARRIER_CMD_PRIVATE_EXPEDITED return error, or make it
fall back to a slower case if we decide not to implement it?

Thanks,
Nick

Re: [PATCH 0/2] constify inet6_protocol structures

[David Miller]

From: Julia Lawall 
Date: Fri, 28 Jul 2017 22:18:56 +0200

> The inet6_protocol structure is only passed as the first argument to
> inet6_add_protocol or inet6_del_protocol, both of which are declared as
> const.  Thus the inet6_protocol structure itself can be const.
> 
> Done with the help of Coccinelle.
 ...

Series applied, thanks Julia.

Re: [PATCH 0/2] constify inet6_protocol structures

[David Miller]

From: Julia Lawall 
Date: Fri, 28 Jul 2017 22:18:56 +0200

> The inet6_protocol structure is only passed as the first argument to
> inet6_add_protocol or inet6_del_protocol, both of which are declared as
> const.  Thus the inet6_protocol structure itself can be const.
> 
> Done with the help of Coccinelle.
 ...

Series applied, thanks Julia.

drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0a07b238e5f488b459b6113a62e06b6aab017f71
commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add 
the option of fortified string.h functions
date:   2 weeks ago
config: x86_64-randconfig-a0-07290908 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 6974f0c4555e285ab217cee58b6e874f776ff409
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: 
>> xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

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


.config.gz
Description: application/gzip

drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0a07b238e5f488b459b6113a62e06b6aab017f71
commit: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add 
the option of fortified string.h functions
date:   2 weeks ago
config: x86_64-randconfig-a0-07290908 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 6974f0c4555e285ab217cee58b6e874f776ff409
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.o: warning: objtool: 
>> xgbe_phy_sfp_eeprom_info()+0xc: return with modified stack frame

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


.config.gz
Description: application/gzip

Re: [PATCH] irqchip: brcmstb-l2: Define an irq_pm_shutdown function

[Gregory Fong]

On Thu, Jul 27, 2017 at 3:38 PM, Florian Fainelli  wrote:
> The Broadcom STB platforms support S5 and we allow specific hardware
> wake-up events to take us out of this state. Because we were not
> defining an irq_pm_shutdown() function pointer, we would not be
> correctly masking non-wakeup events, which would result in spurious
> wake-ups from sources that were not explicitly configured for wake-up.
>
> Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 
> interrupt controller")
> Signed-off-by: Florian Fainelli 

Acked-by: Gregory Fong 

Re: [PATCH] irqchip: brcmstb-l2: Define an irq_pm_shutdown function

[Gregory Fong]

On Thu, Jul 27, 2017 at 3:38 PM, Florian Fainelli  wrote:
> The Broadcom STB platforms support S5 and we allow specific hardware
> wake-up events to take us out of this state. Because we were not
> defining an irq_pm_shutdown() function pointer, we would not be
> correctly masking non-wakeup events, which would result in spurious
> wake-ups from sources that were not explicitly configured for wake-up.
>
> Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 
> interrupt controller")
> Signed-off-by: Florian Fainelli 

Acked-by: Gregory Fong 

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

[Joe Perches]

On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
> "wireless" etc, all of which sound sane.
[]
> it looks like a promising approach to me, and I like how
> the names seem to end up all fairly sane.
> 
> Comments?

Seems somewhat reasonable as a starting point.

There are many entries that have multiple mailing lists
that complicate the ability to script the idea though.

And perhaps more descriptive names than pm and mm
would also be more useful.

ACPI COMPONENT ARCHITECTURE (ACPICA)
L:  linux-a...@vger.kernel.org
L:  de...@acpica.org
ALTERA TRIPLE SPEED ETHERNET DRIVER
L:  net...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ALTERA UART/JTAG UART SERIAL DRIVERS
L:  linux-ser...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ANALOG DEVICES INC ASOC DRIVERS
L:  adi-buildroot-de...@lists.sourceforge.net (moderated for 
non-subscribers)
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
AOA (Apple Onboard Audio) ALSA DRIVER
L:  linuxppc-...@lists.ozlabs.org
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
ARM/Amlogic Meson SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-amlo...@lists.infradead.org
ARM/ASPEED I2C DRIVER
L:  linux-...@vger.kernel.org
L:  open...@lists.ozlabs.org
ARM/IGEP MACHINE SUPPORT
L:  linux-o...@vger.kernel.org
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek RTC DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek USB3 PHY DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/OXNAS platform support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-ox...@lists.tuxfamily.org (moderated for non-subscribers)
ARM/QUALCOMM SUPPORT
L:  linux-arm-...@vger.kernel.org
L:  linux-...@vger.kernel.org
ARM/Rockchip SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-rockc...@lists.infradead.org
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/TEXAS INSTRUMENT KEYSTONE ClOCKSOURCE
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-kernel@vger.kernel.org
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
L:  acpi4asus-u...@lists.sourceforge.net
L:  platform-driver-...@vger.kernel.org
ATM
L:  linux-atm-gene...@lists.sourceforge.net (moderated for non-subscribers)
L:  net...@vger.kernel.org
ATMEL XDMA DRIVER
L:  linux-arm-ker...@lists.infradead.org
L:  dmaeng...@vger.kernel.org
B43 WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
B43LEGACY WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
BPF (Safe dynamic programs and tools)
L:  net...@vger.kernel.org
L:  linux-kernel@vger.kernel.org
BROADCOM B53 ETHERNET SWITCH DRIVER
L:  net...@vger.kernel.org
L:  openwrt-de...@lists.openwrt.org (subscribers-only)
BROADCOM BCM2835 ARM ARCHITECTURE
L:  linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  brcm80211-dev-list@broadcom.com
BROADCOM STB NAND FLASH DRIVER
L:  linux-...@lists.infradead.org
L:  bcm-kernel-feedback-l...@broadcom.com
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
L:  linux...@vger.kernel.org
L:  linux-samsung-...@vger.kernel.org
CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
L:  linux-cry...@vger.kernel.org
L:  driverdev-de...@linuxdriverproject.org
CHINESE DOCUMENTATION
L:  xiyoulinuxkernelgr...@googlegroups.com 

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

[Joe Perches]

On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
> "wireless" etc, all of which sound sane.
[]
> it looks like a promising approach to me, and I like how
> the names seem to end up all fairly sane.
> 
> Comments?

Seems somewhat reasonable as a starting point.

There are many entries that have multiple mailing lists
that complicate the ability to script the idea though.

And perhaps more descriptive names than pm and mm
would also be more useful.

ACPI COMPONENT ARCHITECTURE (ACPICA)
L:  linux-a...@vger.kernel.org
L:  de...@acpica.org
ALTERA TRIPLE SPEED ETHERNET DRIVER
L:  net...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ALTERA UART/JTAG UART SERIAL DRIVERS
L:  linux-ser...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ANALOG DEVICES INC ASOC DRIVERS
L:  adi-buildroot-de...@lists.sourceforge.net (moderated for 
non-subscribers)
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
AOA (Apple Onboard Audio) ALSA DRIVER
L:  linuxppc-...@lists.ozlabs.org
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
ARM/Amlogic Meson SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-amlo...@lists.infradead.org
ARM/ASPEED I2C DRIVER
L:  linux-...@vger.kernel.org
L:  open...@lists.ozlabs.org
ARM/IGEP MACHINE SUPPORT
L:  linux-o...@vger.kernel.org
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek RTC DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek USB3 PHY DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/OXNAS platform support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-ox...@lists.tuxfamily.org (moderated for non-subscribers)
ARM/QUALCOMM SUPPORT
L:  linux-arm-...@vger.kernel.org
L:  linux-...@vger.kernel.org
ARM/Rockchip SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-rockc...@lists.infradead.org
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/TEXAS INSTRUMENT KEYSTONE ClOCKSOURCE
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-kernel@vger.kernel.org
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
L:  acpi4asus-u...@lists.sourceforge.net
L:  platform-driver-...@vger.kernel.org
ATM
L:  linux-atm-gene...@lists.sourceforge.net (moderated for non-subscribers)
L:  net...@vger.kernel.org
ATMEL XDMA DRIVER
L:  linux-arm-ker...@lists.infradead.org
L:  dmaeng...@vger.kernel.org
B43 WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
B43LEGACY WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
BPF (Safe dynamic programs and tools)
L:  net...@vger.kernel.org
L:  linux-kernel@vger.kernel.org
BROADCOM B53 ETHERNET SWITCH DRIVER
L:  net...@vger.kernel.org
L:  openwrt-de...@lists.openwrt.org (subscribers-only)
BROADCOM BCM2835 ARM ARCHITECTURE
L:  linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  brcm80211-dev-list@broadcom.com
BROADCOM STB NAND FLASH DRIVER
L:  linux-...@lists.infradead.org
L:  bcm-kernel-feedback-l...@broadcom.com
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
L:  linux...@vger.kernel.org
L:  linux-samsung-...@vger.kernel.org
CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
L:  linux-cry...@vger.kernel.org
L:  driverdev-de...@linuxdriverproject.org
CHINESE DOCUMENTATION
L:  xiyoulinuxkernelgr...@googlegroups.com 

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Matthias Kaehlcke]

El Fri, Jul 28, 2017 at 07:55:21PM -0500 Josh Poimboeuf ha dit:

> On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote:
> > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:
> > 
> > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > > > FWIW bellow is my understanding of what's going on.
> > > > 
> > > > It seems clang treats local named register almost the same as ordinary
> > > > local variables.
> > > > The only difference is that before reading the register variable clang
> > > > puts variable's value into the specified register.
> > > > 
> > > > So clang just assigns stack slot for the variable __sp where it's
> > > > going to keep variable's value.
> > > > But since __sp is unitialized (we haven't assign anything to it), the
> > > > value of the __sp is some garbage from stack.
> > > > inline asm specifies __sp as input, so clang assumes that it have to
> > > > load __sp into 'rsp' because inline asm is going to use
> > > > it. And it just loads garbage from stack into 'rsp'
> > > > 
> > > > In fact, such behavior (I mean storing the value on stack and loading
> > > > into reg before the use) is very useful.
> > > > Clang's behavior allows to keep the value assigned to the
> > > > call-clobbered register across the function calls.
> > > > 
> > > > Unlike clang, gcc assigns value to the register right away and doesn't
> > > > store the value anywhere else. So if the reg is
> > > > call clobbered register you have to be absolutely sure that there is
> > > > no subsequent function call that might clobber the register.
> > > > 
> > > > E.g. see some real examples
> > > > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > > > Fix improper register assignment").
> > > > These bugs shouldn't happen with clang.
> > > > 
> > > > But the global named register works slightly differently in clang. For
> > > > the global, the value is just the value of the register itself,
> > > > whatever it is. Read/write from global named register is just like
> > > > direct read/write to the register
> > > 
> > > Thanks, that clears up a lot of the confusion for me.
> > > 
> > > Still, unfortunately, I don't think that's going to work for GCC.
> > > Changing the '__sp' register variable to global in the header file
> > > causes it to make a *bunch* of changes across the kernel, even in
> > > functions which don't do inline asm.  It seems to be disabling some
> > > optimizations across the board.
> > > 
> > > I do have another idea, which is to replace all uses of
> > > 
> > >   asm(" ... call foo ... " : outputs : inputs : clobbers);
> > > 
> > > with a new ASM_CALL macro:
> > > 
> > >   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> > > 
> > > Then the compiler differences can be abstracted out, with GCC adding
> > > "sp" as an output constraint and clang doing nothing (for now).
> > 
> > The idea sounds interesting, however I see two issues with ASM_CALL():
> > 
> > Inline assembly expects the individual elements of outputs, inputs and
> > clobbers to be comma separated, and so does the macro for it's
> > parameters.
> 
> I think this isn't a problem, see the (untested and unfinished) patch
> below for an idea of how the arguments can be handled.

Good point!

> > The assembler template can refer to the position of output and input
> > operands, adding "sp" as output changes the positions of the inputs
> > wrt to the clang version.
> 
> True, though I think we could convert all ASM_CALL users to use named
> operands instead of the (bug-prone) numbered ones.  It would be an
> improvement regardless.

Agreed, that sounds like a good solution and a desirable improvement.

> > Not sure how to move forward from here. Not even using an ugly #ifdef
> > seems to be a halfway reasonable solution, since get_user() isn't the
> > only place using this construct and #ifdefs would result in highly
> > redundant macros in multiple places.
> 
> I still think ASM_CALL might work.  The below patch is what I came up
> with last week before I got pulled into some other work.  I'll be out on
> vacation next week but I hope to finish the patch after that.

Thanks for working on this.

Enjoy your vacation!

Matthias

> diff --git a/arch/x86/include/asm/alternative.h 
> b/arch/x86/include/asm/alternative.h
> index 1b020381ab38..5da4bcbeebab 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -216,14 +216,14 @@ static inline int alternatives_text_reserved(void 
> *start, void *end)
>   * Otherwise, old function is used.
>   */
>  #define alternative_call_2(oldfunc, newfunc1, feature1, newfunc2, feature2,  
>  \
> -output, input...)  \
> +output, input, clobbers...)\
>  {  \
> - register void *__sp asm(_ASM_SP);   

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Matthias Kaehlcke]

El Fri, Jul 28, 2017 at 07:55:21PM -0500 Josh Poimboeuf ha dit:

> On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote:
> > El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:
> > 
> > > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > > > FWIW bellow is my understanding of what's going on.
> > > > 
> > > > It seems clang treats local named register almost the same as ordinary
> > > > local variables.
> > > > The only difference is that before reading the register variable clang
> > > > puts variable's value into the specified register.
> > > > 
> > > > So clang just assigns stack slot for the variable __sp where it's
> > > > going to keep variable's value.
> > > > But since __sp is unitialized (we haven't assign anything to it), the
> > > > value of the __sp is some garbage from stack.
> > > > inline asm specifies __sp as input, so clang assumes that it have to
> > > > load __sp into 'rsp' because inline asm is going to use
> > > > it. And it just loads garbage from stack into 'rsp'
> > > > 
> > > > In fact, such behavior (I mean storing the value on stack and loading
> > > > into reg before the use) is very useful.
> > > > Clang's behavior allows to keep the value assigned to the
> > > > call-clobbered register across the function calls.
> > > > 
> > > > Unlike clang, gcc assigns value to the register right away and doesn't
> > > > store the value anywhere else. So if the reg is
> > > > call clobbered register you have to be absolutely sure that there is
> > > > no subsequent function call that might clobber the register.
> > > > 
> > > > E.g. see some real examples
> > > > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > > > Fix improper register assignment").
> > > > These bugs shouldn't happen with clang.
> > > > 
> > > > But the global named register works slightly differently in clang. For
> > > > the global, the value is just the value of the register itself,
> > > > whatever it is. Read/write from global named register is just like
> > > > direct read/write to the register
> > > 
> > > Thanks, that clears up a lot of the confusion for me.
> > > 
> > > Still, unfortunately, I don't think that's going to work for GCC.
> > > Changing the '__sp' register variable to global in the header file
> > > causes it to make a *bunch* of changes across the kernel, even in
> > > functions which don't do inline asm.  It seems to be disabling some
> > > optimizations across the board.
> > > 
> > > I do have another idea, which is to replace all uses of
> > > 
> > >   asm(" ... call foo ... " : outputs : inputs : clobbers);
> > > 
> > > with a new ASM_CALL macro:
> > > 
> > >   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> > > 
> > > Then the compiler differences can be abstracted out, with GCC adding
> > > "sp" as an output constraint and clang doing nothing (for now).
> > 
> > The idea sounds interesting, however I see two issues with ASM_CALL():
> > 
> > Inline assembly expects the individual elements of outputs, inputs and
> > clobbers to be comma separated, and so does the macro for it's
> > parameters.
> 
> I think this isn't a problem, see the (untested and unfinished) patch
> below for an idea of how the arguments can be handled.

Good point!

> > The assembler template can refer to the position of output and input
> > operands, adding "sp" as output changes the positions of the inputs
> > wrt to the clang version.
> 
> True, though I think we could convert all ASM_CALL users to use named
> operands instead of the (bug-prone) numbered ones.  It would be an
> improvement regardless.

Agreed, that sounds like a good solution and a desirable improvement.

> > Not sure how to move forward from here. Not even using an ugly #ifdef
> > seems to be a halfway reasonable solution, since get_user() isn't the
> > only place using this construct and #ifdefs would result in highly
> > redundant macros in multiple places.
> 
> I still think ASM_CALL might work.  The below patch is what I came up
> with last week before I got pulled into some other work.  I'll be out on
> vacation next week but I hope to finish the patch after that.

Thanks for working on this.

Enjoy your vacation!

Matthias

> diff --git a/arch/x86/include/asm/alternative.h 
> b/arch/x86/include/asm/alternative.h
> index 1b020381ab38..5da4bcbeebab 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -216,14 +216,14 @@ static inline int alternatives_text_reserved(void 
> *start, void *end)
>   * Otherwise, old function is used.
>   */
>  #define alternative_call_2(oldfunc, newfunc1, feature1, newfunc2, feature2,  
>  \
> -output, input...)  \
> +output, input, clobbers...)\
>  {  \
> - register void *__sp asm(_ASM_SP);   

[PATCH v1] i2c: aspeed: fixed potential null pointer dereference

[Brendan Higgins]

Before I skipped null checks when the master is in the STOP state; this
fixes that.

Signed-off-by: Brendan Higgins 
---
 drivers/i2c/busses/i2c-aspeed.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index f19348328a71..6fdf9231c23c 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -410,10 +410,11 @@ static bool aspeed_i2c_master_irq(struct aspeed_i2c_bus 
*bus)
}
 
/* We are in an invalid state; reset bus to a known state. */
-   if (!bus->msgs && bus->master_state != ASPEED_I2C_MASTER_STOP) {
+   if (!bus->msgs) {
dev_err(bus->dev, "bus in unknown state");
bus->cmd_err = -EIO;
-   aspeed_i2c_do_stop(bus);
+   if (bus->master_state != ASPEED_I2C_MASTER_STOP)
+   aspeed_i2c_do_stop(bus);
goto out_no_complete;
}
msg = >msgs[bus->msgs_index];
-- 
2.14.0.rc0.400.g1c36432dff-goog

[PATCH v1] i2c: aspeed: fixed potential null pointer dereference

[Brendan Higgins]

Before I skipped null checks when the master is in the STOP state; this
fixes that.

Signed-off-by: Brendan Higgins 
---
 drivers/i2c/busses/i2c-aspeed.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index f19348328a71..6fdf9231c23c 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -410,10 +410,11 @@ static bool aspeed_i2c_master_irq(struct aspeed_i2c_bus 
*bus)
}
 
/* We are in an invalid state; reset bus to a known state. */
-   if (!bus->msgs && bus->master_state != ASPEED_I2C_MASTER_STOP) {
+   if (!bus->msgs) {
dev_err(bus->dev, "bus in unknown state");
bus->cmd_err = -EIO;
-   aspeed_i2c_do_stop(bus);
+   if (bus->master_state != ASPEED_I2C_MASTER_STOP)
+   aspeed_i2c_do_stop(bus);
goto out_no_complete;
}
msg = >msgs[bus->msgs_index];
-- 
2.14.0.rc0.400.g1c36432dff-goog

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 07:55:21PM -0500, Josh Poimboeuf wrote:
> +#define ASM_CALL(str, outputs, inputs, clobbers...) \
> + asm volatile(str : outputs : inputs : "sp", ## clobbers)

And note this part isn't right, the sp should be in the output operands.

-- 
Josh

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 07:55:21PM -0500, Josh Poimboeuf wrote:
> +#define ASM_CALL(str, outputs, inputs, clobbers...) \
> + asm volatile(str : outputs : inputs : "sp", ## clobbers)

And note this part isn't right, the sp should be in the output operands.

-- 
Josh

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote:
> El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:
> 
> > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > > FWIW bellow is my understanding of what's going on.
> > > 
> > > It seems clang treats local named register almost the same as ordinary
> > > local variables.
> > > The only difference is that before reading the register variable clang
> > > puts variable's value into the specified register.
> > > 
> > > So clang just assigns stack slot for the variable __sp where it's
> > > going to keep variable's value.
> > > But since __sp is unitialized (we haven't assign anything to it), the
> > > value of the __sp is some garbage from stack.
> > > inline asm specifies __sp as input, so clang assumes that it have to
> > > load __sp into 'rsp' because inline asm is going to use
> > > it. And it just loads garbage from stack into 'rsp'
> > > 
> > > In fact, such behavior (I mean storing the value on stack and loading
> > > into reg before the use) is very useful.
> > > Clang's behavior allows to keep the value assigned to the
> > > call-clobbered register across the function calls.
> > > 
> > > Unlike clang, gcc assigns value to the register right away and doesn't
> > > store the value anywhere else. So if the reg is
> > > call clobbered register you have to be absolutely sure that there is
> > > no subsequent function call that might clobber the register.
> > > 
> > > E.g. see some real examples
> > > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > > Fix improper register assignment").
> > > These bugs shouldn't happen with clang.
> > > 
> > > But the global named register works slightly differently in clang. For
> > > the global, the value is just the value of the register itself,
> > > whatever it is. Read/write from global named register is just like
> > > direct read/write to the register
> > 
> > Thanks, that clears up a lot of the confusion for me.
> > 
> > Still, unfortunately, I don't think that's going to work for GCC.
> > Changing the '__sp' register variable to global in the header file
> > causes it to make a *bunch* of changes across the kernel, even in
> > functions which don't do inline asm.  It seems to be disabling some
> > optimizations across the board.
> > 
> > I do have another idea, which is to replace all uses of
> > 
> >   asm(" ... call foo ... " : outputs : inputs : clobbers);
> > 
> > with a new ASM_CALL macro:
> > 
> >   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> > 
> > Then the compiler differences can be abstracted out, with GCC adding
> > "sp" as an output constraint and clang doing nothing (for now).
> 
> The idea sounds interesting, however I see two issues with ASM_CALL():
> 
> Inline assembly expects the individual elements of outputs, inputs and
> clobbers to be comma separated, and so does the macro for it's
> parameters.

I think this isn't a problem, see the (untested and unfinished) patch
below for an idea of how the arguments can be handled.

> The assembler template can refer to the position of output and input
> operands, adding "sp" as output changes the positions of the inputs
> wrt to the clang version.

True, though I think we could convert all ASM_CALL users to use named
operands instead of the (bug-prone) numbered ones.  It would be an
improvement regardless.

> Not sure how to move forward from here. Not even using an ugly #ifdef
> seems to be a halfway reasonable solution, since get_user() isn't the
> only place using this construct and #ifdefs would result in highly
> redundant macros in multiple places.

I still think ASM_CALL might work.  The below patch is what I came up
with last week before I got pulled into some other work.  I'll be out on
vacation next week but I hope to finish the patch after that.


diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 1b020381ab38..5da4bcbeebab 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -216,14 +216,14 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
  * Otherwise, old function is used.
  */
 #define alternative_call_2(oldfunc, newfunc1, feature1, newfunc2, feature2,   \
-  output, input...)  \
+  output, input, clobbers...)\
 {\
-   register void *__sp asm(_ASM_SP); \
-   asm volatile (ALTERNATIVE_2("call %P[old]", "call %P[new1]", feature1,\
-   "call %P[new2]", feature2)\
-   : output, "+r" (__sp) \
-   : [old] "i" (oldfunc), [new1] "i" (newfunc1), \
- [new2] "i" (newfunc2), ## input);   

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Josh Poimboeuf]

On Fri, Jul 28, 2017 at 05:38:52PM -0700, Matthias Kaehlcke wrote:
> El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:
> 
> > On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > > FWIW bellow is my understanding of what's going on.
> > > 
> > > It seems clang treats local named register almost the same as ordinary
> > > local variables.
> > > The only difference is that before reading the register variable clang
> > > puts variable's value into the specified register.
> > > 
> > > So clang just assigns stack slot for the variable __sp where it's
> > > going to keep variable's value.
> > > But since __sp is unitialized (we haven't assign anything to it), the
> > > value of the __sp is some garbage from stack.
> > > inline asm specifies __sp as input, so clang assumes that it have to
> > > load __sp into 'rsp' because inline asm is going to use
> > > it. And it just loads garbage from stack into 'rsp'
> > > 
> > > In fact, such behavior (I mean storing the value on stack and loading
> > > into reg before the use) is very useful.
> > > Clang's behavior allows to keep the value assigned to the
> > > call-clobbered register across the function calls.
> > > 
> > > Unlike clang, gcc assigns value to the register right away and doesn't
> > > store the value anywhere else. So if the reg is
> > > call clobbered register you have to be absolutely sure that there is
> > > no subsequent function call that might clobber the register.
> > > 
> > > E.g. see some real examples
> > > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > > Fix improper register assignment").
> > > These bugs shouldn't happen with clang.
> > > 
> > > But the global named register works slightly differently in clang. For
> > > the global, the value is just the value of the register itself,
> > > whatever it is. Read/write from global named register is just like
> > > direct read/write to the register
> > 
> > Thanks, that clears up a lot of the confusion for me.
> > 
> > Still, unfortunately, I don't think that's going to work for GCC.
> > Changing the '__sp' register variable to global in the header file
> > causes it to make a *bunch* of changes across the kernel, even in
> > functions which don't do inline asm.  It seems to be disabling some
> > optimizations across the board.
> > 
> > I do have another idea, which is to replace all uses of
> > 
> >   asm(" ... call foo ... " : outputs : inputs : clobbers);
> > 
> > with a new ASM_CALL macro:
> > 
> >   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> > 
> > Then the compiler differences can be abstracted out, with GCC adding
> > "sp" as an output constraint and clang doing nothing (for now).
> 
> The idea sounds interesting, however I see two issues with ASM_CALL():
> 
> Inline assembly expects the individual elements of outputs, inputs and
> clobbers to be comma separated, and so does the macro for it's
> parameters.

I think this isn't a problem, see the (untested and unfinished) patch
below for an idea of how the arguments can be handled.

> The assembler template can refer to the position of output and input
> operands, adding "sp" as output changes the positions of the inputs
> wrt to the clang version.

True, though I think we could convert all ASM_CALL users to use named
operands instead of the (bug-prone) numbered ones.  It would be an
improvement regardless.

> Not sure how to move forward from here. Not even using an ugly #ifdef
> seems to be a halfway reasonable solution, since get_user() isn't the
> only place using this construct and #ifdefs would result in highly
> redundant macros in multiple places.

I still think ASM_CALL might work.  The below patch is what I came up
with last week before I got pulled into some other work.  I'll be out on
vacation next week but I hope to finish the patch after that.


diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 1b020381ab38..5da4bcbeebab 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -216,14 +216,14 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
  * Otherwise, old function is used.
  */
 #define alternative_call_2(oldfunc, newfunc1, feature1, newfunc2, feature2,   \
-  output, input...)  \
+  output, input, clobbers...)\
 {\
-   register void *__sp asm(_ASM_SP); \
-   asm volatile (ALTERNATIVE_2("call %P[old]", "call %P[new1]", feature1,\
-   "call %P[new2]", feature2)\
-   : output, "+r" (__sp) \
-   : [old] "i" (oldfunc), [new1] "i" (newfunc1), \
- [new2] "i" (newfunc2), ## input);   

Re: [PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.

[Eric Anholt]

Daniel Vetter  writes:

> On Tue, Jul 25, 2017 at 11:27:16AM -0700, Eric Anholt wrote:
>> Chris Wilson pointed out this little cleanup in a review of new code,
>> so let's fix up the code I was copying from.
>> 
>> Signed-off-by: Eric Anholt 
>
> Reviewed-by: Daniel Vetter 

Thanks!  With Chris's review of 2/3, I've pushed to drm-misc-next.


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.

[Eric Anholt]

Daniel Vetter  writes:

> On Tue, Jul 25, 2017 at 11:27:16AM -0700, Eric Anholt wrote:
>> Chris Wilson pointed out this little cleanup in a review of new code,
>> so let's fix up the code I was copying from.
>> 
>> Signed-off-by: Eric Anholt 
>
> Reviewed-by: Daniel Vetter 

Thanks!  With Chris's review of 2/3, I've pushed to drm-misc-next.


signature.asc
Description: PGP signature

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Matthias Kaehlcke]

El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:

> On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > FWIW bellow is my understanding of what's going on.
> > 
> > It seems clang treats local named register almost the same as ordinary
> > local variables.
> > The only difference is that before reading the register variable clang
> > puts variable's value into the specified register.
> > 
> > So clang just assigns stack slot for the variable __sp where it's
> > going to keep variable's value.
> > But since __sp is unitialized (we haven't assign anything to it), the
> > value of the __sp is some garbage from stack.
> > inline asm specifies __sp as input, so clang assumes that it have to
> > load __sp into 'rsp' because inline asm is going to use
> > it. And it just loads garbage from stack into 'rsp'
> > 
> > In fact, such behavior (I mean storing the value on stack and loading
> > into reg before the use) is very useful.
> > Clang's behavior allows to keep the value assigned to the
> > call-clobbered register across the function calls.
> > 
> > Unlike clang, gcc assigns value to the register right away and doesn't
> > store the value anywhere else. So if the reg is
> > call clobbered register you have to be absolutely sure that there is
> > no subsequent function call that might clobber the register.
> > 
> > E.g. see some real examples
> > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > Fix improper register assignment").
> > These bugs shouldn't happen with clang.
> > 
> > But the global named register works slightly differently in clang. For
> > the global, the value is just the value of the register itself,
> > whatever it is. Read/write from global named register is just like
> > direct read/write to the register
> 
> Thanks, that clears up a lot of the confusion for me.
> 
> Still, unfortunately, I don't think that's going to work for GCC.
> Changing the '__sp' register variable to global in the header file
> causes it to make a *bunch* of changes across the kernel, even in
> functions which don't do inline asm.  It seems to be disabling some
> optimizations across the board.
> 
> I do have another idea, which is to replace all uses of
> 
>   asm(" ... call foo ... " : outputs : inputs : clobbers);
> 
> with a new ASM_CALL macro:
> 
>   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> 
> Then the compiler differences can be abstracted out, with GCC adding
> "sp" as an output constraint and clang doing nothing (for now).

The idea sounds interesting, however I see two issues with ASM_CALL():

Inline assembly expects the individual elements of outputs, inputs and
clobbers to be comma separated, and so does the macro for it's
parameters.

The assembler template can refer to the position of output and input
operands, adding "sp" as output changes the positions of the inputs
wrt to the clang version.

Not sure how to move forward from here. Not even using an ugly #ifdef
seems to be a halfway reasonable solution, since get_user() isn't the
only place using this construct and #ifdefs would result in highly
redundant macros in multiple places.

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Matthias Kaehlcke]

El Thu, Jul 20, 2017 at 03:56:52PM -0500 Josh Poimboeuf ha dit:

> On Thu, Jul 20, 2017 at 06:30:24PM +0300, Andrey Ryabinin wrote:
> > FWIW bellow is my understanding of what's going on.
> > 
> > It seems clang treats local named register almost the same as ordinary
> > local variables.
> > The only difference is that before reading the register variable clang
> > puts variable's value into the specified register.
> > 
> > So clang just assigns stack slot for the variable __sp where it's
> > going to keep variable's value.
> > But since __sp is unitialized (we haven't assign anything to it), the
> > value of the __sp is some garbage from stack.
> > inline asm specifies __sp as input, so clang assumes that it have to
> > load __sp into 'rsp' because inline asm is going to use
> > it. And it just loads garbage from stack into 'rsp'
> > 
> > In fact, such behavior (I mean storing the value on stack and loading
> > into reg before the use) is very useful.
> > Clang's behavior allows to keep the value assigned to the
> > call-clobbered register across the function calls.
> > 
> > Unlike clang, gcc assigns value to the register right away and doesn't
> > store the value anywhere else. So if the reg is
> > call clobbered register you have to be absolutely sure that there is
> > no subsequent function call that might clobber the register.
> > 
> > E.g. see some real examples
> > https://patchwork.kernel.org/patch/4111971/ or 98d4ded60bda("msm: scm:
> > Fix improper register assignment").
> > These bugs shouldn't happen with clang.
> > 
> > But the global named register works slightly differently in clang. For
> > the global, the value is just the value of the register itself,
> > whatever it is. Read/write from global named register is just like
> > direct read/write to the register
> 
> Thanks, that clears up a lot of the confusion for me.
> 
> Still, unfortunately, I don't think that's going to work for GCC.
> Changing the '__sp' register variable to global in the header file
> causes it to make a *bunch* of changes across the kernel, even in
> functions which don't do inline asm.  It seems to be disabling some
> optimizations across the board.
> 
> I do have another idea, which is to replace all uses of
> 
>   asm(" ... call foo ... " : outputs : inputs : clobbers);
> 
> with a new ASM_CALL macro:
> 
>   ASM_CALL(" ... call foo ... ", outputs, inputs, clobbers);
> 
> Then the compiler differences can be abstracted out, with GCC adding
> "sp" as an output constraint and clang doing nothing (for now).

The idea sounds interesting, however I see two issues with ASM_CALL():

Inline assembly expects the individual elements of outputs, inputs and
clobbers to be comma separated, and so does the macro for it's
parameters.

The assembler template can refer to the position of output and input
operands, adding "sp" as output changes the positions of the inputs
wrt to the clang version.

Not sure how to move forward from here. Not even using an ugly #ifdef
seems to be a halfway reasonable solution, since get_user() isn't the
only place using this construct and #ifdefs would result in highly
redundant macros in multiple places.

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

[Rajmohan Mani]

The TPS68470 device is an advanced power management
unit that powers a Compact Camera Module (CCM),
generates clocks for image sensors, drives a dual
LED for Flash and incorporates two LED drivers for
general purpose indicators.

This patch adds support for TPS68470 mfd device.

Signed-off-by: Rajmohan Mani 
---
 drivers/mfd/Kconfig  |  18 
 drivers/mfd/Makefile |   1 +
 drivers/mfd/tps68470.c   | 106 +++
 include/linux/mfd/tps68470.h |  97 +++
 4 files changed, 222 insertions(+)
 create mode 100644 drivers/mfd/tps68470.c
 create mode 100644 include/linux/mfd/tps68470.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1..74f41a1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1337,6 +1337,24 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.
 
+config MFD_TPS68470
+   bool "TI TPS68470 Power Management / LED chips"
+   depends on ACPI && I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select I2C_DESIGNWARE_PLATFORM
+   help
+ If you say yes here you get support for the TPS68470 series of
+ Power Management / LED chips.
+
+ These include voltage regulators, LEDs and other features
+ that are often used in portable devices.
+
+ This option is a bool as it provides an ACPI operation
+ region, which must be available before any of the devices
+ using this are probed. This option also configures the
+ designware-i2c driver to be built-in, for the same reason.
+
 config MFD_TI_LP873X
tristate "TI LP873X Power Management IC"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b..0b1fd82 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_MFD_TPS65910)+= tps65910.o
 obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
 obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
 obj-$(CONFIG_MFD_TPS65912_SPI)  += tps65912-spi.o
+obj-$(CONFIG_MFD_TPS68470) += tps68470.o
 obj-$(CONFIG_MFD_TPS80031) += tps80031.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
diff --git a/drivers/mfd/tps68470.c b/drivers/mfd/tps68470.c
new file mode 100644
index 000..189efae
--- /dev/null
+++ b/drivers/mfd/tps68470.c
@@ -0,0 +1,106 @@
+/*
+ * TPS68470 chip Parent driver
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Authors:
+ * Rajmohan Mani 
+ * Tianshu Qiu 
+ * Jian Xu Zheng 
+ * Yuning Pu 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell tps68470s[] = {
+   { .name = "tps68470-gpio" },
+   { .name = "tps68470_pmic_opregion" },
+};
+
+static const struct regmap_config tps68470_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = TPS68470_REG_MAX,
+};
+
+static int tps68470_chip_init(struct device *dev, struct regmap *regmap)
+{
+   unsigned int version;
+   int ret;
+
+   /* Force software reset */
+   ret = regmap_write(regmap, TPS68470_REG_RESET, TPS68470_REG_RESET_MASK);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(regmap, TPS68470_REG_REVID, );
+   if (ret) {
+   dev_err(dev, "Failed to read revision register: %d\n", ret);
+   return ret;
+   }
+
+   dev_info(dev, "TPS68470 REVID: 0x%x\n", version);
+
+   return 0;
+}
+
+static int tps68470_probe(struct i2c_client *client)
+{
+   struct device *dev = >dev;
+   struct regmap *regmap;
+   int ret;
+
+   regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "devm_regmap_init_i2c Error %ld\n",
+   PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   i2c_set_clientdata(client, regmap);
+
+   ret = tps68470_chip_init(dev, regmap);
+   if (ret < 0) {
+   dev_err(dev, "TPS68470 Init Error %d\n", ret);
+   return ret;
+   }
+
+   ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, tps68470s,
+ ARRAY_SIZE(tps68470s), NULL, 0, NULL);
+   if (ret < 0) {
+   dev_err(dev, "devm_mfd_add_devices failed: %d\n", ret);
+

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

[Rajmohan Mani]

The TPS68470 device is an advanced power management
unit that powers a Compact Camera Module (CCM),
generates clocks for image sensors, drives a dual
LED for Flash and incorporates two LED drivers for
general purpose indicators.

This patch adds support for TPS68470 mfd device.

Signed-off-by: Rajmohan Mani 
---
 drivers/mfd/Kconfig  |  18 
 drivers/mfd/Makefile |   1 +
 drivers/mfd/tps68470.c   | 106 +++
 include/linux/mfd/tps68470.h |  97 +++
 4 files changed, 222 insertions(+)
 create mode 100644 drivers/mfd/tps68470.c
 create mode 100644 include/linux/mfd/tps68470.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1..74f41a1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1337,6 +1337,24 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.
 
+config MFD_TPS68470
+   bool "TI TPS68470 Power Management / LED chips"
+   depends on ACPI && I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select I2C_DESIGNWARE_PLATFORM
+   help
+ If you say yes here you get support for the TPS68470 series of
+ Power Management / LED chips.
+
+ These include voltage regulators, LEDs and other features
+ that are often used in portable devices.
+
+ This option is a bool as it provides an ACPI operation
+ region, which must be available before any of the devices
+ using this are probed. This option also configures the
+ designware-i2c driver to be built-in, for the same reason.
+
 config MFD_TI_LP873X
tristate "TI LP873X Power Management IC"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b..0b1fd82 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_MFD_TPS65910)+= tps65910.o
 obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
 obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
 obj-$(CONFIG_MFD_TPS65912_SPI)  += tps65912-spi.o
+obj-$(CONFIG_MFD_TPS68470) += tps68470.o
 obj-$(CONFIG_MFD_TPS80031) += tps80031.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
diff --git a/drivers/mfd/tps68470.c b/drivers/mfd/tps68470.c
new file mode 100644
index 000..189efae
--- /dev/null
+++ b/drivers/mfd/tps68470.c
@@ -0,0 +1,106 @@
+/*
+ * TPS68470 chip Parent driver
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Authors:
+ * Rajmohan Mani 
+ * Tianshu Qiu 
+ * Jian Xu Zheng 
+ * Yuning Pu 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell tps68470s[] = {
+   { .name = "tps68470-gpio" },
+   { .name = "tps68470_pmic_opregion" },
+};
+
+static const struct regmap_config tps68470_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = TPS68470_REG_MAX,
+};
+
+static int tps68470_chip_init(struct device *dev, struct regmap *regmap)
+{
+   unsigned int version;
+   int ret;
+
+   /* Force software reset */
+   ret = regmap_write(regmap, TPS68470_REG_RESET, TPS68470_REG_RESET_MASK);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(regmap, TPS68470_REG_REVID, );
+   if (ret) {
+   dev_err(dev, "Failed to read revision register: %d\n", ret);
+   return ret;
+   }
+
+   dev_info(dev, "TPS68470 REVID: 0x%x\n", version);
+
+   return 0;
+}
+
+static int tps68470_probe(struct i2c_client *client)
+{
+   struct device *dev = >dev;
+   struct regmap *regmap;
+   int ret;
+
+   regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "devm_regmap_init_i2c Error %ld\n",
+   PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   i2c_set_clientdata(client, regmap);
+
+   ret = tps68470_chip_init(dev, regmap);
+   if (ret < 0) {
+   dev_err(dev, "TPS68470 Init Error %d\n", ret);
+   return ret;
+   }
+
+   ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, tps68470s,
+ ARRAY_SIZE(tps68470s), NULL, 0, NULL);
+   if (ret < 0) {
+   dev_err(dev, "devm_mfd_add_devices failed: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct acpi_device_id tps68470_acpi_ids[] = {
+ 

[PATCH v6 0/3] TPS68470 PMIC drivers

[Rajmohan Mani]

This is the patch series for TPS68470 PMIC that works as a camera PMIC.

The patch series provide the following 3 drivers, to help configure the voltage 
regulators, clocks and GPIOs provided by the TPS68470 PMIC, to be able to use 
the camera sensors connected to this PMIC.

TPS68470 MFD driver:
This is the multi function driver that initializes the TPS68470 PMIC and 
supports the GPIO and Op Region functions.

TPS68470 GPIO driver:
This is the PMIC GPIO driver that will be used by the OS GPIO layer, when the 
BIOS / firmware triggered GPIO access is done.

TPS68470 Op Region driver:
This is the driver that will be invoked, when the BIOS / firmware configures 
the voltage / clock for the sensors / vcm devices connected to the PMIC.

---

Update on 2 GPIO chips implementation over 1:
- Attempted to implement 2 GPIO chips, but ran into couple of
  issues in the kernel, so we couldn't get it to work.
- It was decided to postpone this change, since it is not
  critical

Changes in v6:
- MFD driver:
- Used non-zero return values from regmap_write/read() calls
  to detect error conditions

Changes in v5:
- MFD driver:
- Fixed Kconfig description text
- Addressed other comments from Lee, related to formatting

- GPIO driver:
- Formatted the file header text

- Opregion driver:
- Formatted the file header text

Changes in v4:
- MFD driver:
- Removed board specific code and FIXME comment
- Moved i2c.h include from tps68470.h to tps68470.c
- Moved the TPS68470 REVID read code after PMIC reset
- Fixed typo in debug error message (on failure of
  devm_mfd_add_devices() )
- Enhanced dependency on I2C by changing it to I2C=y
  (to fix build errors if I2C is built as module
   e.g tps68470.c:71: undefined reference to `__devm_regmap_init_i2c'
   tps68470.c:117: undefined reference to `i2c_register_driver')
- Removed most of the unused header file definitions
- Moved devm_mfd_add_devices() after PMIC resett
- Used probe_new() and removed i2c_device_id table
  
  The following patch from Andy is needed for the driver to be
  probed.
  http://marc.info/?l=linux-acpi=150030081523885=2  
  
- GPIO driver:
- Added newline at the end of Kconfig description
- Updated commit message about the descriptive
  names for the GPIOs and the typical usage model
  of the GPIO driver

- Opregion driver:
- Added dependency on MFD_TPS68470
- Converted 2 liner into one line code

Changes in v3:
- MFD driver:
- Removed GPIO lookup table
- Reverted to probe() for consistency
- Addressed other comments from Andy

- GPIO driver:
- Removed the code that initializes the default values
  of GPIOs to zeros
- Used gpiochip_get_data() to access data inside the gpio_chip
 
Changes in v2:
- MFD driver:
- Removed tps68470_* wrappers around regmap_* calls
- Removed "struct tps68470"
- used devm_mfd_add_devices and removed mutex in mfd driver
- Added reasoning about the need of having mfd driver
  as bool/builtin

- Opregion driver:
- renamed opregion driver file / internal symbol names
  with tps68470_pmic*
- Made opregion driver tables as const
- Removed unused *handler_context in common handler
- Replaced "int" with "unsigned int"
- Changed to WARN macro to dev_warn()
- Destroyed mutex on error
- Added reasoning about the need of having Opregion driver
  as bool/builtin

- GPIO driver:
- Implemented get_direction() in the GPIO driver
- Setup gpio_chip.names
- Moved the GPIO lookup table code inside mfd driver
- Added reasoning about the need of having GPIO driver
  as bool/builtin

---

Rajmohan Mani (3):
  mfd: Add new mfd device TPS68470
  gpio: Add support for TPS68470 GPIOs
  ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

 drivers/acpi/Kconfig  |  16 ++
 drivers/acpi/Makefile |   2 +
 drivers/acpi/pmic/tps68470_pmic.c | 455 ++
 drivers/gpio/Kconfig  |  15 ++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-tps68470.c  | 176 +++
 drivers/mfd/Kconfig   |  18 ++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/tps68470.c| 106 +
 include/linux/mfd/tps68470.h  |  97 
 10 files changed, 887 insertions(+)
 create mode 100644 drivers/acpi/pmic/tps68470_pmic.c
 create mode 100644 drivers/gpio/gpio-tps68470.c
 create mode 100644 drivers/mfd/tps68470.c
 create mode 100644 include/linux/mfd/tps68470.h

-- 
1.9.1

[PATCH v6 0/3] TPS68470 PMIC drivers

[Rajmohan Mani]

This is the patch series for TPS68470 PMIC that works as a camera PMIC.

The patch series provide the following 3 drivers, to help configure the voltage 
regulators, clocks and GPIOs provided by the TPS68470 PMIC, to be able to use 
the camera sensors connected to this PMIC.

TPS68470 MFD driver:
This is the multi function driver that initializes the TPS68470 PMIC and 
supports the GPIO and Op Region functions.

TPS68470 GPIO driver:
This is the PMIC GPIO driver that will be used by the OS GPIO layer, when the 
BIOS / firmware triggered GPIO access is done.

TPS68470 Op Region driver:
This is the driver that will be invoked, when the BIOS / firmware configures 
the voltage / clock for the sensors / vcm devices connected to the PMIC.

---

Update on 2 GPIO chips implementation over 1:
- Attempted to implement 2 GPIO chips, but ran into couple of
  issues in the kernel, so we couldn't get it to work.
- It was decided to postpone this change, since it is not
  critical

Changes in v6:
- MFD driver:
- Used non-zero return values from regmap_write/read() calls
  to detect error conditions

Changes in v5:
- MFD driver:
- Fixed Kconfig description text
- Addressed other comments from Lee, related to formatting

- GPIO driver:
- Formatted the file header text

- Opregion driver:
- Formatted the file header text

Changes in v4:
- MFD driver:
- Removed board specific code and FIXME comment
- Moved i2c.h include from tps68470.h to tps68470.c
- Moved the TPS68470 REVID read code after PMIC reset
- Fixed typo in debug error message (on failure of
  devm_mfd_add_devices() )
- Enhanced dependency on I2C by changing it to I2C=y
  (to fix build errors if I2C is built as module
   e.g tps68470.c:71: undefined reference to `__devm_regmap_init_i2c'
   tps68470.c:117: undefined reference to `i2c_register_driver')
- Removed most of the unused header file definitions
- Moved devm_mfd_add_devices() after PMIC resett
- Used probe_new() and removed i2c_device_id table
  
  The following patch from Andy is needed for the driver to be
  probed.
  http://marc.info/?l=linux-acpi=150030081523885=2  
  
- GPIO driver:
- Added newline at the end of Kconfig description
- Updated commit message about the descriptive
  names for the GPIOs and the typical usage model
  of the GPIO driver

- Opregion driver:
- Added dependency on MFD_TPS68470
- Converted 2 liner into one line code

Changes in v3:
- MFD driver:
- Removed GPIO lookup table
- Reverted to probe() for consistency
- Addressed other comments from Andy

- GPIO driver:
- Removed the code that initializes the default values
  of GPIOs to zeros
- Used gpiochip_get_data() to access data inside the gpio_chip
 
Changes in v2:
- MFD driver:
- Removed tps68470_* wrappers around regmap_* calls
- Removed "struct tps68470"
- used devm_mfd_add_devices and removed mutex in mfd driver
- Added reasoning about the need of having mfd driver
  as bool/builtin

- Opregion driver:
- renamed opregion driver file / internal symbol names
  with tps68470_pmic*
- Made opregion driver tables as const
- Removed unused *handler_context in common handler
- Replaced "int" with "unsigned int"
- Changed to WARN macro to dev_warn()
- Destroyed mutex on error
- Added reasoning about the need of having Opregion driver
  as bool/builtin

- GPIO driver:
- Implemented get_direction() in the GPIO driver
- Setup gpio_chip.names
- Moved the GPIO lookup table code inside mfd driver
- Added reasoning about the need of having GPIO driver
  as bool/builtin

---

Rajmohan Mani (3):
  mfd: Add new mfd device TPS68470
  gpio: Add support for TPS68470 GPIOs
  ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

 drivers/acpi/Kconfig  |  16 ++
 drivers/acpi/Makefile |   2 +
 drivers/acpi/pmic/tps68470_pmic.c | 455 ++
 drivers/gpio/Kconfig  |  15 ++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-tps68470.c  | 176 +++
 drivers/mfd/Kconfig   |  18 ++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/tps68470.c| 106 +
 include/linux/mfd/tps68470.h  |  97 
 10 files changed, 887 insertions(+)
 create mode 100644 drivers/acpi/pmic/tps68470_pmic.c
 create mode 100644 drivers/gpio/gpio-tps68470.c
 create mode 100644 drivers/mfd/tps68470.c
 create mode 100644 include/linux/mfd/tps68470.h

-- 
1.9.1

[PATCH v6 3/3] ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

[Rajmohan Mani]

The Kabylake platform coreboot (Chrome OS equivalent of
BIOS) has defined 4 operation regions for the TI TPS68470 PMIC.
These operation regions are to enable/disable voltage
regulators, configure voltage regulators, enable/disable
clocks and to configure clocks.

This config adds ACPI operation region support for TI TPS68470 PMIC.
TPS68470 device is an advanced power management unit that powers
a Compact Camera Module (CCM), generates clocks for image sensors,
drives a dual LED for flash and incorporates two LED drivers for
general purpose indicators.
This driver enables ACPI operation region support to control voltage
regulators and clocks for the TPS68470 PMIC.

Signed-off-by: Rajmohan Mani 
---
 drivers/acpi/Kconfig  |  16 ++
 drivers/acpi/Makefile |   2 +
 drivers/acpi/pmic/tps68470_pmic.c | 455 ++
 3 files changed, 473 insertions(+)
 create mode 100644 drivers/acpi/pmic/tps68470_pmic.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f8..e124a82d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -535,4 +535,20 @@ if ARM64
 source "drivers/acpi/arm64/Kconfig"
 endif
 
+config TPS68470_PMIC_OPREGION
+   bool "ACPI operation region support for TPS68470 PMIC"
+   depends on MFD_TPS68470
+   help
+ This config adds ACPI operation region support for TI TPS68470 PMIC.
+ TPS68470 device is an advanced power management unit that powers
+ a Compact Camera Module (CCM), generates clocks for image sensors,
+ drives a dual LED for flash and incorporates two LED drivers for
+ general purpose indicators.
+ This driver enables ACPI operation region support control voltage
+ regulators and clocks.
+
+ This option is a bool as it provides an ACPI operation
+ region, which must be available before any of the devices
+ using this, are probed.
+
 endif  # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc..2d70a7f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -106,6 +106,8 @@ obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += 
pmic/intel_pmic_chtwc.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
+obj-$(CONFIG_TPS68470_PMIC_OPREGION)   += pmic/tps68470_pmic.o
+
 video-objs += acpi_video.o video_detect.o
 obj-y  += dptf/
 
diff --git a/drivers/acpi/pmic/tps68470_pmic.c 
b/drivers/acpi/pmic/tps68470_pmic.c
new file mode 100644
index 000..7f3c567
--- /dev/null
+++ b/drivers/acpi/pmic/tps68470_pmic.c
@@ -0,0 +1,455 @@
+/*
+ * TI TPS68470 PMIC operation region driver
+ *
+ * Copyright (C) 2017 Intel Corporation. All rights reserved.
+ *
+ * Author: Rajmohan Mani 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Based on drivers/acpi/pmic/intel_pmic* drivers
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct tps68470_pmic_table {
+   u32 address;/* operation region address */
+   u32 reg;/* corresponding register */
+   u32 bitmask;/* bit mask for power, clock */
+};
+
+#define TI_PMIC_POWER_OPREGION_ID  0xB0
+#define TI_PMIC_VR_VAL_OPREGION_ID 0xB1
+#define TI_PMIC_CLOCK_OPREGION_ID  0xB2
+#define TI_PMIC_CLKFREQ_OPREGION_ID0xB3
+
+struct tps68470_pmic_opregion {
+   struct mutex lock;
+   struct regmap *regmap;
+};
+
+#define S_IO_I2C_EN(BIT(0) | BIT(1))
+
+static const struct tps68470_pmic_table power_table[] = {
+   {
+   .address = 0x00,
+   .reg = TPS68470_REG_S_I2C_CTL,
+   .bitmask = S_IO_I2C_EN,
+   /* S_I2C_CTL */
+   },
+   {
+   .address = 0x04,
+   .reg = TPS68470_REG_VCMCTL,
+   .bitmask = BIT(0),
+   /* VCMCTL */
+   },
+   {
+   .address = 0x08,
+   .reg = TPS68470_REG_VAUX1CTL,
+   .bitmask = BIT(0),
+   /* VAUX1_CTL */
+   },
+   {
+   .address = 0x0C,
+   .reg = TPS68470_REG_VAUX2CTL,
+   .bitmask = BIT(0),
+   /* VAUX2CTL */
+   },
+   {
+   .address = 0x10,
+   .reg = TPS68470_REG_VACTL,
+   .bitmask = BIT(0),
+   /* VACTL */
+   },
+   {
+   .address = 0x14,
+   .reg = TPS68470_REG_VDCTL,
+   .bitmask = BIT(0),
+   /* 

[PATCH v6 3/3] ACPI / PMIC: Add TI PMIC TPS68470 operation region driver

[Rajmohan Mani]

The Kabylake platform coreboot (Chrome OS equivalent of
BIOS) has defined 4 operation regions for the TI TPS68470 PMIC.
These operation regions are to enable/disable voltage
regulators, configure voltage regulators, enable/disable
clocks and to configure clocks.

This config adds ACPI operation region support for TI TPS68470 PMIC.
TPS68470 device is an advanced power management unit that powers
a Compact Camera Module (CCM), generates clocks for image sensors,
drives a dual LED for flash and incorporates two LED drivers for
general purpose indicators.
This driver enables ACPI operation region support to control voltage
regulators and clocks for the TPS68470 PMIC.

Signed-off-by: Rajmohan Mani 
---
 drivers/acpi/Kconfig  |  16 ++
 drivers/acpi/Makefile |   2 +
 drivers/acpi/pmic/tps68470_pmic.c | 455 ++
 3 files changed, 473 insertions(+)
 create mode 100644 drivers/acpi/pmic/tps68470_pmic.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f8..e124a82d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -535,4 +535,20 @@ if ARM64
 source "drivers/acpi/arm64/Kconfig"
 endif
 
+config TPS68470_PMIC_OPREGION
+   bool "ACPI operation region support for TPS68470 PMIC"
+   depends on MFD_TPS68470
+   help
+ This config adds ACPI operation region support for TI TPS68470 PMIC.
+ TPS68470 device is an advanced power management unit that powers
+ a Compact Camera Module (CCM), generates clocks for image sensors,
+ drives a dual LED for flash and incorporates two LED drivers for
+ general purpose indicators.
+ This driver enables ACPI operation region support control voltage
+ regulators and clocks.
+
+ This option is a bool as it provides an ACPI operation
+ region, which must be available before any of the devices
+ using this, are probed.
+
 endif  # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc..2d70a7f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -106,6 +106,8 @@ obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += 
pmic/intel_pmic_chtwc.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
+obj-$(CONFIG_TPS68470_PMIC_OPREGION)   += pmic/tps68470_pmic.o
+
 video-objs += acpi_video.o video_detect.o
 obj-y  += dptf/
 
diff --git a/drivers/acpi/pmic/tps68470_pmic.c 
b/drivers/acpi/pmic/tps68470_pmic.c
new file mode 100644
index 000..7f3c567
--- /dev/null
+++ b/drivers/acpi/pmic/tps68470_pmic.c
@@ -0,0 +1,455 @@
+/*
+ * TI TPS68470 PMIC operation region driver
+ *
+ * Copyright (C) 2017 Intel Corporation. All rights reserved.
+ *
+ * Author: Rajmohan Mani 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Based on drivers/acpi/pmic/intel_pmic* drivers
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct tps68470_pmic_table {
+   u32 address;/* operation region address */
+   u32 reg;/* corresponding register */
+   u32 bitmask;/* bit mask for power, clock */
+};
+
+#define TI_PMIC_POWER_OPREGION_ID  0xB0
+#define TI_PMIC_VR_VAL_OPREGION_ID 0xB1
+#define TI_PMIC_CLOCK_OPREGION_ID  0xB2
+#define TI_PMIC_CLKFREQ_OPREGION_ID0xB3
+
+struct tps68470_pmic_opregion {
+   struct mutex lock;
+   struct regmap *regmap;
+};
+
+#define S_IO_I2C_EN(BIT(0) | BIT(1))
+
+static const struct tps68470_pmic_table power_table[] = {
+   {
+   .address = 0x00,
+   .reg = TPS68470_REG_S_I2C_CTL,
+   .bitmask = S_IO_I2C_EN,
+   /* S_I2C_CTL */
+   },
+   {
+   .address = 0x04,
+   .reg = TPS68470_REG_VCMCTL,
+   .bitmask = BIT(0),
+   /* VCMCTL */
+   },
+   {
+   .address = 0x08,
+   .reg = TPS68470_REG_VAUX1CTL,
+   .bitmask = BIT(0),
+   /* VAUX1_CTL */
+   },
+   {
+   .address = 0x0C,
+   .reg = TPS68470_REG_VAUX2CTL,
+   .bitmask = BIT(0),
+   /* VAUX2CTL */
+   },
+   {
+   .address = 0x10,
+   .reg = TPS68470_REG_VACTL,
+   .bitmask = BIT(0),
+   /* VACTL */
+   },
+   {
+   .address = 0x14,
+   .reg = TPS68470_REG_VDCTL,
+   .bitmask = BIT(0),
+   /* VDCTL */
+   },
+};
+
+/* Table to set voltage 

[PATCH v6 2/3] gpio: Add support for TPS68470 GPIOs

[Rajmohan Mani]

This patch adds support for TPS68470 GPIOs.
There are 7 GPIOs and a few sensor related GPIOs.
These GPIOs can be requested and configured as
appropriate.

The GPIOs are also provided with descriptive names.
However, the typical use case is that the OS GPIO
driver will interact with TPS68470 GPIO driver
to configure these GPIOs, as requested by the
platform firmware.

Signed-off-by: Rajmohan Mani 
Reviewed-by: Linus Walleij 
---
 drivers/gpio/Kconfig |  15 
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-tps68470.c | 176 +++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps68470.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f235eae..45a58ae 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1064,6 +1064,21 @@ config GPIO_TPS65912
help
  This driver supports TPS65912 gpio chip
 
+config GPIO_TPS68470
+   bool "TPS68470 GPIO"
+   depends on MFD_TPS68470
+   help
+ Select this option to enable GPIO driver for the TPS68470
+ chip family.
+ There are 7 GPIOs and few sensor related GPIOs supported
+ by the TPS68470. While the 7 GPIOs can be configured as
+ input or output as appropriate, the sensor related GPIOs
+ are "output only" GPIOs.
+
+ This driver config is bool, as the GPIO functionality
+ of the TPS68470 must be available before dependent
+ drivers are loaded.
+
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a9fda6c..37f2029 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_GPIO_TPS65218) += gpio-tps65218.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
 obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
+obj-$(CONFIG_GPIO_TPS68470)+= gpio-tps68470.o
 obj-$(CONFIG_GPIO_TS4800)  += gpio-ts4800.o
 obj-$(CONFIG_GPIO_TS4900)  += gpio-ts4900.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c
new file mode 100644
index 000..fa2662f
--- /dev/null
+++ b/drivers/gpio/gpio-tps68470.c
@@ -0,0 +1,176 @@
+/*
+ * GPIO driver for TPS68470 PMIC
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Authors:
+ * Antti Laakso 
+ * Tianshu Qiu 
+ * Jian Xu Zheng 
+ * Yuning Pu 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TPS68470_N_LOGIC_OUTPUT3
+#define TPS68470_N_REGULAR_GPIO7
+#define TPS68470_N_GPIO(TPS68470_N_LOGIC_OUTPUT + 
TPS68470_N_REGULAR_GPIO)
+
+struct tps68470_gpio_data {
+   struct regmap *tps68470_regmap;
+   struct gpio_chip gc;
+};
+
+static int tps68470_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+   struct tps68470_gpio_data *tps68470_gpio = gpiochip_get_data(gc);
+   struct regmap *regmap = tps68470_gpio->tps68470_regmap;
+   unsigned int reg = TPS68470_REG_GPDO;
+   int val, ret;
+
+   if (offset >= TPS68470_N_REGULAR_GPIO) {
+   offset -= TPS68470_N_REGULAR_GPIO;
+   reg = TPS68470_REG_SGPO;
+   }
+
+   ret = regmap_read(regmap, reg, );
+   if (ret) {
+   dev_err(tps68470_gpio->gc.parent, "reg 0x%x read failed\n",
+   TPS68470_REG_SGPO);
+   return ret;
+   }
+   return !!(val & BIT(offset));
+}
+
+/* Return 0 if output, 1 if input */
+static int tps68470_gpio_get_direction(struct gpio_chip *gc,
+  unsigned int offset)
+{
+   struct tps68470_gpio_data *tps68470_gpio = gpiochip_get_data(gc);
+   struct regmap *regmap = tps68470_gpio->tps68470_regmap;
+   int val, ret;
+
+   /* rest are always outputs */
+   if (offset >= TPS68470_N_REGULAR_GPIO)
+   return 0;
+
+   ret = regmap_read(regmap, TPS68470_GPIO_CTL_REG_A(offset), );
+   if (ret) {
+   dev_err(tps68470_gpio->gc.parent, "reg 0x%x read failed\n",
+   TPS68470_GPIO_CTL_REG_A(offset));
+   return ret;
+   }
+
+   val &= TPS68470_GPIO_MODE_MASK;
+   return val >= TPS68470_GPIO_MODE_OUT_CMOS ? 0 : 1;
+}
+

[PATCH v6 2/3] gpio: Add support for TPS68470 GPIOs

[Rajmohan Mani]

This patch adds support for TPS68470 GPIOs.
There are 7 GPIOs and a few sensor related GPIOs.
These GPIOs can be requested and configured as
appropriate.

The GPIOs are also provided with descriptive names.
However, the typical use case is that the OS GPIO
driver will interact with TPS68470 GPIO driver
to configure these GPIOs, as requested by the
platform firmware.

Signed-off-by: Rajmohan Mani 
Reviewed-by: Linus Walleij 
---
 drivers/gpio/Kconfig |  15 
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-tps68470.c | 176 +++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps68470.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f235eae..45a58ae 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1064,6 +1064,21 @@ config GPIO_TPS65912
help
  This driver supports TPS65912 gpio chip
 
+config GPIO_TPS68470
+   bool "TPS68470 GPIO"
+   depends on MFD_TPS68470
+   help
+ Select this option to enable GPIO driver for the TPS68470
+ chip family.
+ There are 7 GPIOs and few sensor related GPIOs supported
+ by the TPS68470. While the 7 GPIOs can be configured as
+ input or output as appropriate, the sensor related GPIOs
+ are "output only" GPIOs.
+
+ This driver config is bool, as the GPIO functionality
+ of the TPS68470 must be available before dependent
+ drivers are loaded.
+
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a9fda6c..37f2029 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_GPIO_TPS65218) += gpio-tps65218.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
 obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
+obj-$(CONFIG_GPIO_TPS68470)+= gpio-tps68470.o
 obj-$(CONFIG_GPIO_TS4800)  += gpio-ts4800.o
 obj-$(CONFIG_GPIO_TS4900)  += gpio-ts4900.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c
new file mode 100644
index 000..fa2662f
--- /dev/null
+++ b/drivers/gpio/gpio-tps68470.c
@@ -0,0 +1,176 @@
+/*
+ * GPIO driver for TPS68470 PMIC
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Authors:
+ * Antti Laakso 
+ * Tianshu Qiu 
+ * Jian Xu Zheng 
+ * Yuning Pu 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TPS68470_N_LOGIC_OUTPUT3
+#define TPS68470_N_REGULAR_GPIO7
+#define TPS68470_N_GPIO(TPS68470_N_LOGIC_OUTPUT + 
TPS68470_N_REGULAR_GPIO)
+
+struct tps68470_gpio_data {
+   struct regmap *tps68470_regmap;
+   struct gpio_chip gc;
+};
+
+static int tps68470_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+   struct tps68470_gpio_data *tps68470_gpio = gpiochip_get_data(gc);
+   struct regmap *regmap = tps68470_gpio->tps68470_regmap;
+   unsigned int reg = TPS68470_REG_GPDO;
+   int val, ret;
+
+   if (offset >= TPS68470_N_REGULAR_GPIO) {
+   offset -= TPS68470_N_REGULAR_GPIO;
+   reg = TPS68470_REG_SGPO;
+   }
+
+   ret = regmap_read(regmap, reg, );
+   if (ret) {
+   dev_err(tps68470_gpio->gc.parent, "reg 0x%x read failed\n",
+   TPS68470_REG_SGPO);
+   return ret;
+   }
+   return !!(val & BIT(offset));
+}
+
+/* Return 0 if output, 1 if input */
+static int tps68470_gpio_get_direction(struct gpio_chip *gc,
+  unsigned int offset)
+{
+   struct tps68470_gpio_data *tps68470_gpio = gpiochip_get_data(gc);
+   struct regmap *regmap = tps68470_gpio->tps68470_regmap;
+   int val, ret;
+
+   /* rest are always outputs */
+   if (offset >= TPS68470_N_REGULAR_GPIO)
+   return 0;
+
+   ret = regmap_read(regmap, TPS68470_GPIO_CTL_REG_A(offset), );
+   if (ret) {
+   dev_err(tps68470_gpio->gc.parent, "reg 0x%x read failed\n",
+   TPS68470_GPIO_CTL_REG_A(offset));
+   return ret;
+   }
+
+   val &= TPS68470_GPIO_MODE_MASK;
+   return val >= TPS68470_GPIO_MODE_OUT_CMOS ? 0 : 1;
+}
+
+static void tps68470_gpio_set(struct gpio_chip *gc, unsigned int offset,
+   int value)
+{
+   struct 

Re: [RFC PATCH] f2fs: obsolete FI_ACL_MODE

[Chao Yu]

Hi Jaegeuk,

Could you take time to have a look at this? Is this change reasonable?

Thanks,

On 2017/7/26 22:33, Chao Yu wrote:
> From: Chao Yu 
> 
> Previously, in order to avoid losing important inode metadata after
> checkpoint & sudden power-off, f2fs uses synchronous approach for
> updating inode metadata, so attribute in inode cache will be updated
> to node page cache, after flushing dirty node pages in checkpoint,
> these attribute in node page can be persisted.
> 
> However, f2fs has changed to use asynchronous inode metadata update
> approach in commit 0f18b462b2e5 ("flush inode metadata when checkpoint
> is doing"), with this change, we can obsolete synchrounous metadata
> update approach including old acl updating method.>
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/acl.c   |  8 +++-
>  fs/f2fs/f2fs.h  | 13 -
>  fs/f2fs/file.c  | 43 ---
>  fs/f2fs/xattr.c |  6 +-
>  4 files changed, 8 insertions(+), 62 deletions(-)
> 
> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
> index b4b8438c42ef..25eaf243ee2e 100644
> --- a/fs/f2fs/acl.c
> +++ b/fs/f2fs/acl.c
> @@ -215,7 +215,8 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>   error = posix_acl_update_mode(inode, >i_mode, 
> );
>   if (error)
>   return error;
> - set_acl_inode(inode, inode->i_mode);
> + inode->i_ctime = current_time(inode);
> + f2fs_mark_inode_dirty_sync(inode, true);
>   }
>   break;
>  
> @@ -231,10 +232,8 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>  
>   if (acl) {
>   value = f2fs_acl_to_disk(F2FS_I_SB(inode), acl, );
> - if (IS_ERR(value)) {
> - clear_inode_flag(inode, FI_ACL_MODE);
> + if (IS_ERR(value))
>   return PTR_ERR(value);
> - }
>   }
>  
>   error = f2fs_setxattr(inode, name_index, "", value, size, ipage, 0);
> @@ -243,7 +242,6 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>   if (!error)
>   set_cached_acl(inode, type, acl);
>  
> - clear_inode_flag(inode, FI_ACL_MODE);
>   return error;
>  }
>  
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 5cfffd6f0209..07a6697a0589 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -561,7 +561,6 @@ struct f2fs_inode_info {
>   unsigned char i_dir_level;  /* use for dentry level for large dir */
>   unsigned int i_current_depth;   /* use only in directory structure */
>   unsigned int i_pino;/* parent inode number */
> - umode_t i_acl_mode; /* keep file acl mode temporarily */
>  
>   /* Use below internally in f2fs*/
>   unsigned long flags;/* use to pass per-file flags */
> @@ -1957,7 +1956,6 @@ enum {
>   FI_AUTO_RECOVER,/* indicate inode is recoverable */
>   FI_DIRTY_DIR,   /* indicate directory has dirty pages */
>   FI_INC_LINK,/* need to increment i_nlink */
> - FI_ACL_MODE,/* indicate acl mode */
>   FI_NO_ALLOC,/* should not allocate any blocks */
>   FI_FREE_NID,/* free allocated nide */
>   FI_NO_EXTENT,   /* not to use the extent cache */
> @@ -2016,13 +2014,6 @@ static inline void clear_inode_flag(struct inode 
> *inode, int flag)
>   __mark_inode_dirty_flag(inode, flag, false);
>  }
>  
> -static inline void set_acl_inode(struct inode *inode, umode_t mode)
> -{
> - F2FS_I(inode)->i_acl_mode = mode;
> - set_inode_flag(inode, FI_ACL_MODE);
> - f2fs_mark_inode_dirty_sync(inode, false);
> -}
> -
>  static inline void f2fs_i_links_write(struct inode *inode, bool inc)
>  {
>   if (inc)
> @@ -2295,10 +2286,6 @@ static inline int get_extra_isize(struct inode *inode)
>   return F2FS_I(inode)->i_extra_isize / sizeof(__le32);
>  }
>  
> -#define get_inode_mode(i) \
> - ((is_inode_flag_set(i, FI_ACL_MODE)) ? \
> -  (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
> -
>  #define F2FS_TOTAL_EXTRA_ATTR_SIZE   \
>   (offsetof(struct f2fs_inode, i_extra_end) - \
>   offsetof(struct f2fs_inode, i_extra_isize)) \
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index e13f0ada1110..f8d3f4f928e7 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -763,36 +763,6 @@ int f2fs_getattr(const struct path *path, struct kstat 
> *stat,
>   return 0;
>  }
>  
> -#ifdef CONFIG_F2FS_FS_POSIX_ACL
> -static void __setattr_copy(struct inode *inode, const struct iattr *attr)
> -{
> - unsigned int ia_valid = attr->ia_valid;
> -
> - if (ia_valid & ATTR_UID)
> - inode->i_uid = attr->ia_uid;
> - if (ia_valid & ATTR_GID)
> - inode->i_gid = attr->ia_gid;
> - if (ia_valid & ATTR_ATIME)
> - inode->i_atime = 

Re: [RFC PATCH] f2fs: obsolete FI_ACL_MODE

[Chao Yu]

Hi Jaegeuk,

Could you take time to have a look at this? Is this change reasonable?

Thanks,

On 2017/7/26 22:33, Chao Yu wrote:
> From: Chao Yu 
> 
> Previously, in order to avoid losing important inode metadata after
> checkpoint & sudden power-off, f2fs uses synchronous approach for
> updating inode metadata, so attribute in inode cache will be updated
> to node page cache, after flushing dirty node pages in checkpoint,
> these attribute in node page can be persisted.
> 
> However, f2fs has changed to use asynchronous inode metadata update
> approach in commit 0f18b462b2e5 ("flush inode metadata when checkpoint
> is doing"), with this change, we can obsolete synchrounous metadata
> update approach including old acl updating method.>
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/acl.c   |  8 +++-
>  fs/f2fs/f2fs.h  | 13 -
>  fs/f2fs/file.c  | 43 ---
>  fs/f2fs/xattr.c |  6 +-
>  4 files changed, 8 insertions(+), 62 deletions(-)
> 
> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
> index b4b8438c42ef..25eaf243ee2e 100644
> --- a/fs/f2fs/acl.c
> +++ b/fs/f2fs/acl.c
> @@ -215,7 +215,8 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>   error = posix_acl_update_mode(inode, >i_mode, 
> );
>   if (error)
>   return error;
> - set_acl_inode(inode, inode->i_mode);
> + inode->i_ctime = current_time(inode);
> + f2fs_mark_inode_dirty_sync(inode, true);
>   }
>   break;
>  
> @@ -231,10 +232,8 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>  
>   if (acl) {
>   value = f2fs_acl_to_disk(F2FS_I_SB(inode), acl, );
> - if (IS_ERR(value)) {
> - clear_inode_flag(inode, FI_ACL_MODE);
> + if (IS_ERR(value))
>   return PTR_ERR(value);
> - }
>   }
>  
>   error = f2fs_setxattr(inode, name_index, "", value, size, ipage, 0);
> @@ -243,7 +242,6 @@ static int __f2fs_set_acl(struct inode *inode, int type,
>   if (!error)
>   set_cached_acl(inode, type, acl);
>  
> - clear_inode_flag(inode, FI_ACL_MODE);
>   return error;
>  }
>  
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 5cfffd6f0209..07a6697a0589 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -561,7 +561,6 @@ struct f2fs_inode_info {
>   unsigned char i_dir_level;  /* use for dentry level for large dir */
>   unsigned int i_current_depth;   /* use only in directory structure */
>   unsigned int i_pino;/* parent inode number */
> - umode_t i_acl_mode; /* keep file acl mode temporarily */
>  
>   /* Use below internally in f2fs*/
>   unsigned long flags;/* use to pass per-file flags */
> @@ -1957,7 +1956,6 @@ enum {
>   FI_AUTO_RECOVER,/* indicate inode is recoverable */
>   FI_DIRTY_DIR,   /* indicate directory has dirty pages */
>   FI_INC_LINK,/* need to increment i_nlink */
> - FI_ACL_MODE,/* indicate acl mode */
>   FI_NO_ALLOC,/* should not allocate any blocks */
>   FI_FREE_NID,/* free allocated nide */
>   FI_NO_EXTENT,   /* not to use the extent cache */
> @@ -2016,13 +2014,6 @@ static inline void clear_inode_flag(struct inode 
> *inode, int flag)
>   __mark_inode_dirty_flag(inode, flag, false);
>  }
>  
> -static inline void set_acl_inode(struct inode *inode, umode_t mode)
> -{
> - F2FS_I(inode)->i_acl_mode = mode;
> - set_inode_flag(inode, FI_ACL_MODE);
> - f2fs_mark_inode_dirty_sync(inode, false);
> -}
> -
>  static inline void f2fs_i_links_write(struct inode *inode, bool inc)
>  {
>   if (inc)
> @@ -2295,10 +2286,6 @@ static inline int get_extra_isize(struct inode *inode)
>   return F2FS_I(inode)->i_extra_isize / sizeof(__le32);
>  }
>  
> -#define get_inode_mode(i) \
> - ((is_inode_flag_set(i, FI_ACL_MODE)) ? \
> -  (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
> -
>  #define F2FS_TOTAL_EXTRA_ATTR_SIZE   \
>   (offsetof(struct f2fs_inode, i_extra_end) - \
>   offsetof(struct f2fs_inode, i_extra_isize)) \
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index e13f0ada1110..f8d3f4f928e7 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -763,36 +763,6 @@ int f2fs_getattr(const struct path *path, struct kstat 
> *stat,
>   return 0;
>  }
>  
> -#ifdef CONFIG_F2FS_FS_POSIX_ACL
> -static void __setattr_copy(struct inode *inode, const struct iattr *attr)
> -{
> - unsigned int ia_valid = attr->ia_valid;
> -
> - if (ia_valid & ATTR_UID)
> - inode->i_uid = attr->ia_uid;
> - if (ia_valid & ATTR_GID)
> - inode->i_gid = attr->ia_gid;
> - if (ia_valid & ATTR_ATIME)
> - inode->i_atime = timespec_trunc(attr->ia_atime,
> - 

Re: [f2fs-dev] [PATCH 1/2 v3] f2fs: expose /sys/fs/f2fs/features

[Chao Yu]

On 2017/7/29 3:41, Jaegeuk Kim wrote:
>  Change log from v2:
>   - add missing new features
>   - fix print out features
> 
>  Change log from v1:
>   - add /sys/fs/f2fs/dev/features
> 
>>From cf512bfeed89d760138ade12014f17fc5779ca04 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Fri, 21 Jul 2017 17:14:09 -0700
> Subject: [PATCH] f2fs: expose features to sysfs entry
> 
> This patch exposes what features are supported by current f2fs build to sysfs
> entry via:
> 
> /sys/fs/f2fs/features/
> /sys/fs/f2fs/dev/features
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

Re: [f2fs-dev] [PATCH 1/2 v3] f2fs: expose /sys/fs/f2fs/features

[Chao Yu]

On 2017/7/29 3:41, Jaegeuk Kim wrote:
>  Change log from v2:
>   - add missing new features
>   - fix print out features
> 
>  Change log from v1:
>   - add /sys/fs/f2fs/dev/features
> 
>>From cf512bfeed89d760138ade12014f17fc5779ca04 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Fri, 21 Jul 2017 17:14:09 -0700
> Subject: [PATCH] f2fs: expose features to sysfs entry
> 
> This patch exposes what features are supported by current f2fs build to sysfs
> entry via:
> 
> /sys/fs/f2fs/features/
> /sys/fs/f2fs/dev/features
> 
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

Re: [PATCH v2] f2fs: provide f2fs_balance_fs to __write_node_page

[Chao Yu]

Hi Yunlong,

On 2017/7/27 20:13, Yunlong Song wrote:
> v1->v2, fix some dead lock problems under some heavy load test
> 
> On 2017/7/27 20:11, Yunlong Song wrote:
>> Let node writeback also do f2fs_balance_fs to ensure there are always enough 
>> free
>> segments.

Could we cover __write_data_page of directory inode with this logic?

Thanks,

>>
>> Signed-off-by: Yunlong Song 
>> ---
>>   fs/f2fs/checkpoint.c |  2 +-
>>   fs/f2fs/f2fs.h   |  2 +-
>>   fs/f2fs/node.c   | 14 --
>>   3 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index 5b876f6..3c84a25 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -1017,7 +1017,7 @@ static int block_operations(struct f2fs_sb_info *sbi)
>>   
>>  if (get_pages(sbi, F2FS_DIRTY_NODES)) {
>>  up_write(>node_write);
>> -err = sync_node_pages(sbi, );
>> +err = sync_node_pages(sbi, , false);
>>  if (err) {
>>  up_write(>node_change);
>>  f2fs_unlock_all(sbi);
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index 94a88b2..f69051b 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -2293,7 +2293,7 @@ struct page *new_node_page(struct dnode_of_data *dn,
>>   void move_node_page(struct page *node_page, int gc_type);
>>   int fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
>>  struct writeback_control *wbc, bool atomic);
>> -int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc);
>> +int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc, bool need);
>>   void build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount);
>>   bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid);
>>   void alloc_nid_done(struct f2fs_sb_info *sbi, nid_t nid);
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index d53fe62..210ec25 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1326,7 +1326,7 @@ static struct page *last_fsync_dnode(struct 
>> f2fs_sb_info *sbi, nid_t ino)
>>   }
>>   
>>   static int __write_node_page(struct page *page, bool atomic, bool 
>> *submitted,
>> -struct writeback_control *wbc)
>> +struct writeback_control *wbc, bool need)
>>   {
>>  struct f2fs_sb_info *sbi = F2FS_P_SB(page);
>>  nid_t nid;
>> @@ -1387,6 +1387,8 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>  }
>>   
>>  unlock_page(page);
>> +if (need)
>> +f2fs_balance_fs(sbi, false);
>>   
>>  if (unlikely(f2fs_cp_error(sbi))) {
>>  f2fs_submit_merged_write(sbi, NODE);
>> @@ -1405,7 +1407,7 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>   static int f2fs_write_node_page(struct page *page,
>>  struct writeback_control *wbc)
>>   {
>> -return __write_node_page(page, false, NULL, wbc);
>> +return __write_node_page(page, false, NULL, wbc, false);
>>   }
>>   
>>   int fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
>> @@ -1493,7 +1495,7 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
>> inode *inode,
>>   
>>  ret = __write_node_page(page, atomic &&
>>  page == last_page,
>> -, wbc);
>> +, wbc, true);
>>  if (ret) {
>>  unlock_page(page);
>>  f2fs_put_page(last_page, 0);
>> @@ -1530,7 +1532,7 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
>> inode *inode,
>>  return ret ? -EIO: 0;
>>   }
>>   
>> -int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control *wbc)
>> +int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc, bool need)
>>   {
>>  pgoff_t index, end;
>>  struct pagevec pvec;
>> @@ -1608,7 +1610,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct 
>> writeback_control *wbc)
>>  set_fsync_mark(page, 0);
>>  set_dentry_mark(page, 0);
>>   
>> -ret = __write_node_page(page, false, , wbc);
>> +ret = __write_node_page(page, false, , wbc, 
>> need);
>>  if (ret)
>>  unlock_page(page);
>>  else if (submitted)
>> @@ -1697,7 +1699,7 @@ static int f2fs_write_node_pages(struct address_space 
>> *mapping,
>>  diff = nr_pages_to_write(sbi, NODE, wbc);
>>  wbc->sync_mode = WB_SYNC_NONE;
>>  blk_start_plug();
>> -sync_node_pages(sbi, wbc);
>> +sync_node_pages(sbi, wbc, true);
>>  blk_finish_plug();
>>  wbc->nr_to_write = max((long)0, wbc->nr_to_write - diff);
>>  return 0;
> 

Re: [PATCH v2] f2fs: provide f2fs_balance_fs to __write_node_page

[Chao Yu]

Hi Yunlong,

On 2017/7/27 20:13, Yunlong Song wrote:
> v1->v2, fix some dead lock problems under some heavy load test
> 
> On 2017/7/27 20:11, Yunlong Song wrote:
>> Let node writeback also do f2fs_balance_fs to ensure there are always enough 
>> free
>> segments.

Could we cover __write_data_page of directory inode with this logic?

Thanks,

>>
>> Signed-off-by: Yunlong Song 
>> ---
>>   fs/f2fs/checkpoint.c |  2 +-
>>   fs/f2fs/f2fs.h   |  2 +-
>>   fs/f2fs/node.c   | 14 --
>>   3 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index 5b876f6..3c84a25 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -1017,7 +1017,7 @@ static int block_operations(struct f2fs_sb_info *sbi)
>>   
>>  if (get_pages(sbi, F2FS_DIRTY_NODES)) {
>>  up_write(>node_write);
>> -err = sync_node_pages(sbi, );
>> +err = sync_node_pages(sbi, , false);
>>  if (err) {
>>  up_write(>node_change);
>>  f2fs_unlock_all(sbi);
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index 94a88b2..f69051b 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -2293,7 +2293,7 @@ struct page *new_node_page(struct dnode_of_data *dn,
>>   void move_node_page(struct page *node_page, int gc_type);
>>   int fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
>>  struct writeback_control *wbc, bool atomic);
>> -int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc);
>> +int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc, bool need);
>>   void build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount);
>>   bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid);
>>   void alloc_nid_done(struct f2fs_sb_info *sbi, nid_t nid);
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index d53fe62..210ec25 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1326,7 +1326,7 @@ static struct page *last_fsync_dnode(struct 
>> f2fs_sb_info *sbi, nid_t ino)
>>   }
>>   
>>   static int __write_node_page(struct page *page, bool atomic, bool 
>> *submitted,
>> -struct writeback_control *wbc)
>> +struct writeback_control *wbc, bool need)
>>   {
>>  struct f2fs_sb_info *sbi = F2FS_P_SB(page);
>>  nid_t nid;
>> @@ -1387,6 +1387,8 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>  }
>>   
>>  unlock_page(page);
>> +if (need)
>> +f2fs_balance_fs(sbi, false);
>>   
>>  if (unlikely(f2fs_cp_error(sbi))) {
>>  f2fs_submit_merged_write(sbi, NODE);
>> @@ -1405,7 +1407,7 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>   static int f2fs_write_node_page(struct page *page,
>>  struct writeback_control *wbc)
>>   {
>> -return __write_node_page(page, false, NULL, wbc);
>> +return __write_node_page(page, false, NULL, wbc, false);
>>   }
>>   
>>   int fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
>> @@ -1493,7 +1495,7 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
>> inode *inode,
>>   
>>  ret = __write_node_page(page, atomic &&
>>  page == last_page,
>> -, wbc);
>> +, wbc, true);
>>  if (ret) {
>>  unlock_page(page);
>>  f2fs_put_page(last_page, 0);
>> @@ -1530,7 +1532,7 @@ int fsync_node_pages(struct f2fs_sb_info *sbi, struct 
>> inode *inode,
>>  return ret ? -EIO: 0;
>>   }
>>   
>> -int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control *wbc)
>> +int sync_node_pages(struct f2fs_sb_info *sbi, struct writeback_control 
>> *wbc, bool need)
>>   {
>>  pgoff_t index, end;
>>  struct pagevec pvec;
>> @@ -1608,7 +1610,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct 
>> writeback_control *wbc)
>>  set_fsync_mark(page, 0);
>>  set_dentry_mark(page, 0);
>>   
>> -ret = __write_node_page(page, false, , wbc);
>> +ret = __write_node_page(page, false, , wbc, 
>> need);
>>  if (ret)
>>  unlock_page(page);
>>  else if (submitted)
>> @@ -1697,7 +1699,7 @@ static int f2fs_write_node_pages(struct address_space 
>> *mapping,
>>  diff = nr_pages_to_write(sbi, NODE, wbc);
>>  wbc->sync_mode = WB_SYNC_NONE;
>>  blk_start_plug();
>> -sync_node_pages(sbi, wbc);
>> +sync_node_pages(sbi, wbc, true);
>>  blk_finish_plug();
>>  wbc->nr_to_write = max((long)0, wbc->nr_to_write - diff);
>>  return 0;
> 

[PATCH] staging: lustre: lov: remove dead code

[Dmitriy Cherkasov]

This #if 0 block has been commented out for years. Assume it is not
needed and remove it.

Signed-off-by: Dmitriy Cherkasov 
---
 drivers/staging/lustre/lustre/lov/lov_io.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_io.c 
b/drivers/staging/lustre/lustre/lov/lov_io.c
index babf39a..0fb5723 100644
--- a/drivers/staging/lustre/lustre/lov/lov_io.c
+++ b/drivers/staging/lustre/lustre/lov/lov_io.c
@@ -939,12 +939,6 @@ static void lov_empty_impossible(const struct lu_env *env,
.op = {
[CIT_READ] = {
.cio_fini   = lov_empty_io_fini,
-#if 0
-   .cio_iter_init  = LOV_EMPTY_IMPOSSIBLE,
-   .cio_lock   = LOV_EMPTY_IMPOSSIBLE,
-   .cio_start  = LOV_EMPTY_IMPOSSIBLE,
-   .cio_end= LOV_EMPTY_IMPOSSIBLE
-#endif
},
[CIT_WRITE] = {
.cio_fini  = lov_empty_io_fini,
-- 
1.9.1

[PATCH] staging: lustre: lov: remove dead code

[Dmitriy Cherkasov]

This #if 0 block has been commented out for years. Assume it is not
needed and remove it.

Signed-off-by: Dmitriy Cherkasov 
---
 drivers/staging/lustre/lustre/lov/lov_io.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_io.c 
b/drivers/staging/lustre/lustre/lov/lov_io.c
index babf39a..0fb5723 100644
--- a/drivers/staging/lustre/lustre/lov/lov_io.c
+++ b/drivers/staging/lustre/lustre/lov/lov_io.c
@@ -939,12 +939,6 @@ static void lov_empty_impossible(const struct lu_env *env,
.op = {
[CIT_READ] = {
.cio_fini   = lov_empty_io_fini,
-#if 0
-   .cio_iter_init  = LOV_EMPTY_IMPOSSIBLE,
-   .cio_lock   = LOV_EMPTY_IMPOSSIBLE,
-   .cio_start  = LOV_EMPTY_IMPOSSIBLE,
-   .cio_end= LOV_EMPTY_IMPOSSIBLE
-#endif
},
[CIT_WRITE] = {
.cio_fini  = lov_empty_io_fini,
-- 
1.9.1

Re: [PATCH v5 0/2] ZII RAVE platform driver

[Andrey Smirnov]

On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman
 wrote:
> On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote:
>> Greg,
>>
>> I am not sure if you are the right person to send these to, if you are
>> not, please let me know who would be the appropriate recepient and sorry for 
>> the noise.
>
> Why not the platform driver maintainer(s)?  Doesn't
> scripts/get_maintainer.pl give you an idea for who to send them to?

Unfortunately I wasn't able to find anyone in MAINTAINERS and running
scripts/get_maintainer.pl on the patch returns only:

scripts/get_maintainer.pl
v5-0001-platform-Add-driver-for-RAVE-Supervisory-Processo.patch
Andrey Smirnov 
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,added_lines:1/1=100%,added_lines:26/26=100%,added_lines:1127/1127=100%,added_lines:54/54=100%)
Andy Shevchenko  (commit_signer:1/1=100%)
linux-kernel@vger.kernel.org (open list)

hence me reaching out to you.

Thanks,
Andrey Smirnov

Re: [PATCH v5 0/2] ZII RAVE platform driver

[Andrey Smirnov]

On Fri, Jul 28, 2017 at 4:30 PM, Greg Kroah-Hartman
 wrote:
> On Fri, Jul 28, 2017 at 07:27:02AM -0700, Andrey Smirnov wrote:
>> Greg,
>>
>> I am not sure if you are the right person to send these to, if you are
>> not, please let me know who would be the appropriate recepient and sorry for 
>> the noise.
>
> Why not the platform driver maintainer(s)?  Doesn't
> scripts/get_maintainer.pl give you an idea for who to send them to?

Unfortunately I wasn't able to find anyone in MAINTAINERS and running
scripts/get_maintainer.pl on the patch returns only:

scripts/get_maintainer.pl
v5-0001-platform-Add-driver-for-RAVE-Supervisory-Processo.patch
Andrey Smirnov 
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,added_lines:1/1=100%,added_lines:26/26=100%,added_lines:1127/1127=100%,added_lines:54/54=100%)
Andy Shevchenko  (commit_signer:1/1=100%)
linux-kernel@vger.kernel.org (open list)

hence me reaching out to you.

Thanks,
Andrey Smirnov

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

[Brendan Higgins]

On Fri, Jul 28, 2017 at 2:00 PM, Rick Altherr  wrote:
> Is clk_fractional_divider from include/linux/clk-provider.h appropriate here?
>

Alas, no. clk_fractional_divider is not flexible enough to specify the
divider the
way that it is represented in the Aspeed 24xx/25xx parts which have the divider
expressed as a "base clock" which is always a power of 2 along with the time
where SCL is high and the time that the SCL is low in units of base clock.
Thus, there are two separate "numerator" values and the denominator is
represented as the ilog2 of the actual value.

That being said, I could implement this as a custom clock subclass, which
would probably be cleaner that what I have done.

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

[Brendan Higgins]

On Fri, Jul 28, 2017 at 2:00 PM, Rick Altherr  wrote:
> Is clk_fractional_divider from include/linux/clk-provider.h appropriate here?
>

Alas, no. clk_fractional_divider is not flexible enough to specify the
divider the
way that it is represented in the Aspeed 24xx/25xx parts which have the divider
expressed as a "base clock" which is always a power of 2 along with the time
where SCL is high and the time that the SCL is low in units of base clock.
Thus, there are two separate "numerator" values and the denominator is
represented as the ilog2 of the actual value.

That being said, I could implement this as a custom clock subclass, which
would probably be cleaner that what I have done.

Re: [PATCH] staging: vboxvideo: select CONFIG_GENERIC_ALLOCATOR

[Greg Kroah-Hartman]

On Fri, Jul 28, 2017 at 03:21:01PM +0200, Arnd Bergmann wrote:
> vboxvideo fails to link without genalloc:
> 
> drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_alloc':
> vbox_hgsmi.c:(.text+0x1e): undefined reference to `gen_pool_dma_alloc'
> drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_free':
> vbox_hgsmi.c:(.text+0xf2): undefined reference to `gen_pool_free'
> 
> This adds a Kconfig select statement, mirroring what all the other
> users have.
> 
> Fixes: dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/vboxvideo/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Hans sent this same patch 2 days ago, sorry, just applied it now.

greg k-h

Re: [PATCH] staging: vboxvideo: select CONFIG_GENERIC_ALLOCATOR

[Greg Kroah-Hartman]

On Fri, Jul 28, 2017 at 03:21:01PM +0200, Arnd Bergmann wrote:
> vboxvideo fails to link without genalloc:
> 
> drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_alloc':
> vbox_hgsmi.c:(.text+0x1e): undefined reference to `gen_pool_dma_alloc'
> drivers/staging/vboxvideo/vbox_hgsmi.o: In function `hgsmi_buffer_free':
> vbox_hgsmi.c:(.text+0xf2): undefined reference to `gen_pool_free'
> 
> This adds a Kconfig select statement, mirroring what all the other
> users have.
> 
> Fixes: dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/staging/vboxvideo/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Hans sent this same patch 2 days ago, sorry, just applied it now.

greg k-h

Re: [PATCH 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

[Florian Fainelli]

On 07/25/2017 03:06 PM, Jon Mason wrote:
> Cache related issues with DMA rings and performance issues related to
> caching are being caused by not properly setting the "dma-coherent" flag
> in the device tree entries.  Adding it here to correct the issue.
> 
> Signed-off-by: Jon Mason 
> Fixes: 5fa1026a3e4d ("ARM: dts: NSP: Add PL330 support")
> Fixes: 3107fa5bcfb2 ("ARM: dts: NSP: Add SD/MMC support")
> Fixes: 13d04f20935c ("ARM: dts: NSP: Add AMAC entries")
> Fixes: 5aeda7bf8a1e ("ARM: dts: NSP: Add and enable amac2")
> Fixes: 17d517172300 ("ARM: dts: NSP: Add mailbox (PDC) to NSP")
> Fixes: 1d8ece6639e1 ("ARM: dts: NSP: Add EHCI/OHCI USB nodes to device tree")
> Fixes: bf2289bedef4 ("ARM: dts: NSP: Add Switch Register Access Block node")

The SRAB block is not DMA capable, so this seems a bit superfluous here.

Do you want to submit a patch that omits PL330 for now and adds it
eventually later so I can proceed with applying patches 2 & 3 for this
cycle?


> Fixes: 0f9f27a36d09 ("ARM: dts: NSP: Add I2C support to the DT")
> Fixes: 8dbcad020f2e ("ARM: dts: nsp: Add sata device tree entry")
> Fixes: 522199029fdc ("ARM: dts: NSP: Fix PCIE DT issue")
> ---
>  arch/arm/boot/dts/bcm-nsp.dtsi | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index 7204d1def23d..c8d734d9f5fc 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -207,6 +207,7 @@
>   clocks = <>;
>   clock-names = "apb_pclk";
>   #dma-cells = <1>;
> + dma-coherent;
>   };
>  
>   sdio: sdhci@21000 {
> @@ -215,6 +216,7 @@
>   interrupts = ;
>   sdhci,auto-cmd12;
>   clocks = < BCM_NSP_LCPLL0_SDIO_CLK>;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -224,6 +226,7 @@
> <0x11 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -233,6 +236,7 @@
> <0x111000 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -242,6 +246,7 @@
> <0x112000 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -252,6 +257,7 @@
>   #mbox-cells = <1>;
>   brcm,rx-status-len = <32>;
>   brcm,use-bcm-hdr;
> + dma-coherent;
>   };
>  
>   nand: nand@26000 {
> @@ -325,6 +331,7 @@
>   compatible = "generic-ehci";
>   reg = <0x2a000 0x100>;
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -332,6 +339,7 @@
>   compatible = "generic-ohci";
>   reg = <0x2b000 0x100>;
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -364,6 +372,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   /* ports are defined in board DTS */
> @@ -376,6 +385,7 @@
>   #size-cells = <0>;
>   interrupts = ;
>   clock-frequency = <10>;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -446,6 +456,7 @@
>   interrupts = ;
>   #address-cells = <1>;
>   #size-cells = <0>;
> + dma-coherent;
>   status = "disabled";
>  
>   sata0: sata-port@0 {
> @@ -483,6 +494,7 @@
>*/
>   ranges = <0x8200 0 0x0800 0x0800 0 0x800>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   msi-parent = <>;
> @@ -519,6 +531,7 @@
>*/
>   ranges = <0x8200 0 0x4000 0x4000 0 0x800>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   msi-parent = <>;
> @@ -555,6 +568,7 @@
>*/
>   ranges = <0x8200 0 0x4800 0x4800 0 

Re: [PATCH 1/3] ARM: dts: NSP: Add dma-coherent to relevant DT entries

[Florian Fainelli]

On 07/25/2017 03:06 PM, Jon Mason wrote:
> Cache related issues with DMA rings and performance issues related to
> caching are being caused by not properly setting the "dma-coherent" flag
> in the device tree entries.  Adding it here to correct the issue.
> 
> Signed-off-by: Jon Mason 
> Fixes: 5fa1026a3e4d ("ARM: dts: NSP: Add PL330 support")
> Fixes: 3107fa5bcfb2 ("ARM: dts: NSP: Add SD/MMC support")
> Fixes: 13d04f20935c ("ARM: dts: NSP: Add AMAC entries")
> Fixes: 5aeda7bf8a1e ("ARM: dts: NSP: Add and enable amac2")
> Fixes: 17d517172300 ("ARM: dts: NSP: Add mailbox (PDC) to NSP")
> Fixes: 1d8ece6639e1 ("ARM: dts: NSP: Add EHCI/OHCI USB nodes to device tree")
> Fixes: bf2289bedef4 ("ARM: dts: NSP: Add Switch Register Access Block node")

The SRAB block is not DMA capable, so this seems a bit superfluous here.

Do you want to submit a patch that omits PL330 for now and adds it
eventually later so I can proceed with applying patches 2 & 3 for this
cycle?


> Fixes: 0f9f27a36d09 ("ARM: dts: NSP: Add I2C support to the DT")
> Fixes: 8dbcad020f2e ("ARM: dts: nsp: Add sata device tree entry")
> Fixes: 522199029fdc ("ARM: dts: NSP: Fix PCIE DT issue")
> ---
>  arch/arm/boot/dts/bcm-nsp.dtsi | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index 7204d1def23d..c8d734d9f5fc 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -207,6 +207,7 @@
>   clocks = <>;
>   clock-names = "apb_pclk";
>   #dma-cells = <1>;
> + dma-coherent;
>   };
>  
>   sdio: sdhci@21000 {
> @@ -215,6 +216,7 @@
>   interrupts = ;
>   sdhci,auto-cmd12;
>   clocks = < BCM_NSP_LCPLL0_SDIO_CLK>;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -224,6 +226,7 @@
> <0x11 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -233,6 +236,7 @@
> <0x111000 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -242,6 +246,7 @@
> <0x112000 0x1000>;
>   reg-names = "amac_base", "idm_base";
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -252,6 +257,7 @@
>   #mbox-cells = <1>;
>   brcm,rx-status-len = <32>;
>   brcm,use-bcm-hdr;
> + dma-coherent;
>   };
>  
>   nand: nand@26000 {
> @@ -325,6 +331,7 @@
>   compatible = "generic-ehci";
>   reg = <0x2a000 0x100>;
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -332,6 +339,7 @@
>   compatible = "generic-ohci";
>   reg = <0x2b000 0x100>;
>   interrupts = ;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -364,6 +372,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   /* ports are defined in board DTS */
> @@ -376,6 +385,7 @@
>   #size-cells = <0>;
>   interrupts = ;
>   clock-frequency = <10>;
> + dma-coherent;
>   status = "disabled";
>   };
>  
> @@ -446,6 +456,7 @@
>   interrupts = ;
>   #address-cells = <1>;
>   #size-cells = <0>;
> + dma-coherent;
>   status = "disabled";
>  
>   sata0: sata-port@0 {
> @@ -483,6 +494,7 @@
>*/
>   ranges = <0x8200 0 0x0800 0x0800 0 0x800>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   msi-parent = <>;
> @@ -519,6 +531,7 @@
>*/
>   ranges = <0x8200 0 0x4000 0x4000 0 0x800>;
>  
> + dma-coherent;
>   status = "disabled";
>  
>   msi-parent = <>;
> @@ -555,6 +568,7 @@
>*/
>   ranges = <0x8200 0 0x4800 0x4800 0 0x800>;
>  
> + 

Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static

[Greg Kroah-Hartman]

On Thu, Jul 20, 2017 at 01:01:46PM +0200, Wolf Entwicklungen wrote:
> Declare rf69_set_dc_cut_off_frequency_intern as static since it
> is used internaly only
> 
> Fixes: 874bcba65f9a ("staging: pi433: New driver")
> Signed-off-by: Marcus Wolf 
> 
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -433,7 +433,7 @@
>   return rf69_set_dc_cut_off_frequency_intern(spi, REG_AFCBW, dccPercent);
>  }
> 
> -int rf69_set_bandwidth_intern(struct spi_device *spi, u8 reg, enum mantisse 
> mantisse, u8 exponent)
> +static int rf69_set_bandwidth_intern(struct spi_device *spi, u8 reg, enum 
> mantisse mantisse, u8 exponent)
>  {
>   u8 newValue;
> diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
> --- a/drivers/staging/pi433/rf69.h
> +++ b/drivers/staging/pi433/rf69.h
> @@ -41,7 +41,6 @@
>  int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance 
> antennaImpedance);
>  int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain);
>  enum lnaGain rf69_get_lna_gain(struct spi_device *spi);
> -int rf69_set_dc_cut_off_frequency_intern(struct spi_device *spi, u8 reg, 
> enum dccPercent dccPercent);
>  int rf69_set_dc_cut_off_frequency(struct spi_device *spi, enum dccPercent 
> dccPercent);
>  int rf69_set_dc_cut_off_frequency_during_afc(struct spi_device *spi, enum 
> dccPercent dccPercent);
>  int rf69_set_bandwidth(struct spi_device *spi, enum mantisse mantisse, u8 
> exponent);
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Patch does not apply :(

Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation

[Greg KH]

On Thu, Jul 20, 2017 at 05:56:36PM +0200, Marcus Wolf wrote:
> Fixes problem with division in rf69_set_deviation
> 
> Fixes: 874bcba65f9a ("staging: pi433: New driver")
> Signed-off-by: Marcus Wolf 
> 
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -221,7 +221,7 @@ int rf69_set_frequency(struct spi_device *spi, u32
> frequency)

Patch is line-wrapped and does not apply :(

Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation

[Greg KH]

On Thu, Jul 20, 2017 at 05:56:36PM +0200, Marcus Wolf wrote:
> Fixes problem with division in rf69_set_deviation
> 
> Fixes: 874bcba65f9a ("staging: pi433: New driver")
> Signed-off-by: Marcus Wolf 
> 
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -221,7 +221,7 @@ int rf69_set_frequency(struct spi_device *spi, u32
> frequency)

Patch is line-wrapped and does not apply :(

Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static

[Greg Kroah-Hartman]

On Thu, Jul 20, 2017 at 01:01:46PM +0200, Wolf Entwicklungen wrote:
> Declare rf69_set_dc_cut_off_frequency_intern as static since it
> is used internaly only
> 
> Fixes: 874bcba65f9a ("staging: pi433: New driver")
> Signed-off-by: Marcus Wolf 
> 
> diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> --- a/drivers/staging/pi433/rf69.c
> +++ b/drivers/staging/pi433/rf69.c
> @@ -433,7 +433,7 @@
>   return rf69_set_dc_cut_off_frequency_intern(spi, REG_AFCBW, dccPercent);
>  }
> 
> -int rf69_set_bandwidth_intern(struct spi_device *spi, u8 reg, enum mantisse 
> mantisse, u8 exponent)
> +static int rf69_set_bandwidth_intern(struct spi_device *spi, u8 reg, enum 
> mantisse mantisse, u8 exponent)
>  {
>   u8 newValue;
> diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
> --- a/drivers/staging/pi433/rf69.h
> +++ b/drivers/staging/pi433/rf69.h
> @@ -41,7 +41,6 @@
>  int rf69_set_antenna_impedance(struct spi_device *spi, enum antennaImpedance 
> antennaImpedance);
>  int rf69_set_lna_gain(struct spi_device *spi, enum lnaGain lnaGain);
>  enum lnaGain rf69_get_lna_gain(struct spi_device *spi);
> -int rf69_set_dc_cut_off_frequency_intern(struct spi_device *spi, u8 reg, 
> enum dccPercent dccPercent);
>  int rf69_set_dc_cut_off_frequency(struct spi_device *spi, enum dccPercent 
> dccPercent);
>  int rf69_set_dc_cut_off_frequency_during_afc(struct spi_device *spi, enum 
> dccPercent dccPercent);
>  int rf69_set_bandwidth(struct spi_device *spi, enum mantisse mantisse, u8 
> exponent);
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Patch does not apply :(

Re: [PATCH v3 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

[Florian Fainelli]

On 07/18/2017 12:52 PM, Florian Fainelli wrote:
> On 07/06/2017 03:22 PM, Florian Fainelli wrote:
>> Hi,
>>
>> This patch series adds support for S2/S3/S5 suspend/resume states on
>> ARM and MIPS based Broadcom STB SoCs.
>>
>> This was submitted a long time ago by Brian, and I am now picking this
>> up and trying to get this included with support for our latest chips.
>>
>> Provided that I can collect the necessary Acks from Rob (DT) and other
>> people (Rafael?) I would probably take this via the Broadcom ARM SoC
>> pull requests.
> 
> Rafael, any feedback on this?

Applied these 4 patches to drivers/next now.
-- 
Florian

Re: [PATCH v3 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

[Florian Fainelli]

On 07/18/2017 12:52 PM, Florian Fainelli wrote:
> On 07/06/2017 03:22 PM, Florian Fainelli wrote:
>> Hi,
>>
>> This patch series adds support for S2/S3/S5 suspend/resume states on
>> ARM and MIPS based Broadcom STB SoCs.
>>
>> This was submitted a long time ago by Brian, and I am now picking this
>> up and trying to get this included with support for our latest chips.
>>
>> Provided that I can collect the necessary Acks from Rob (DT) and other
>> people (Rafael?) I would probably take this via the Broadcom ARM SoC
>> pull requests.
> 
> Rafael, any feedback on this?

Applied these 4 patches to drivers/next now.
-- 
Florian

Re: [PATCH 1/3][staging-next] staging: pi433: Make a couple of functions static

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 02:03:58PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The functions pi433_receive and pi433_tx_thread are local to the source
> and do not need to be in global scope, so make them static
> 
> Cleans up sparse warnings:
> symbol 'pi433_receive' was not declared. Should it be static?
> symbol 'pi433_tx_thread' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Marcus Wolf 

Only one of the patches in this series applied :(

Re: [PATCH 1/3][staging-next] staging: pi433: Make a couple of functions static

[Greg Kroah-Hartman]

On Tue, Jul 18, 2017 at 02:03:58PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The functions pi433_receive and pi433_tx_thread are local to the source
> and do not need to be in global scope, so make them static
> 
> Cleans up sparse warnings:
> symbol 'pi433_receive' was not declared. Should it be static?
> symbol 'pi433_tx_thread' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Marcus Wolf 

Only one of the patches in this series applied :(