Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

[Minchan Kim]

On Fri, Jul 01, 2016 at 09:01:16PM +0100, Mel Gorman wrote:
> kswapd goes through some complex steps trying to figure out if it should
> stay awake based on the classzone_idx and the requested order.  It is
> unnecessarily complex and passes in an invalid classzone_idx to
> balance_pgdat().  What matters most of all is whether a larger order has
> been requsted and whether kswapd successfully reclaimed at the previous
> order.  This patch irons out the logic to check just that and the end
> result is less headache inducing.
> 
> Signed-off-by: Mel Gorman 
> Acked-by: Johannes Weiner 
> Acked-by: Vlastimil Babka 
> ---
>  include/linux/mmzone.h |   5 ++-
>  mm/memory_hotplug.c|   5 ++-
>  mm/page_alloc.c|   2 +-
>  mm/vmscan.c| 102 
> ++---
>  4 files changed, 62 insertions(+), 52 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 258c20758e80..eb74e63df5cf 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -667,8 +667,9 @@ typedef struct pglist_data {
>   wait_queue_head_t pfmemalloc_wait;
>   struct task_struct *kswapd; /* Protected by
>  mem_hotplug_begin/end() */
> - int kswapd_max_order;
> - enum zone_type classzone_idx;
> + int kswapd_order;
> + enum zone_type kswapd_classzone_idx;
> +
>  #ifdef CONFIG_COMPACTION
>   int kcompactd_max_order;
>   enum zone_type kcompactd_classzone_idx;
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c5278360ca66..065140ecd081 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1209,9 +1209,10 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 
> start)
>  
>   arch_refresh_nodedata(nid, pgdat);
>   } else {
> - /* Reset the nr_zones and classzone_idx to 0 before reuse */
> + /* Reset the nr_zones, order and classzone_idx before reuse */
>   pgdat->nr_zones = 0;
> - pgdat->classzone_idx = 0;
> + pgdat->kswapd_order = 0;
> + pgdat->kswapd_classzone_idx = 0;
>   }
>  
>   /* we can use NODE_DATA(nid) from here */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 59e4463e5dce..f58548139bf2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6084,7 +6084,7 @@ void __paginginit free_area_init_node(int nid, unsigned 
> long *zones_size,
>   unsigned long end_pfn = 0;
>  
>   /* pg_data_t should be reset to zero when it's allocated */
> - WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
> + WARN_ON(pgdat->nr_zones || pgdat->kswapd_classzone_idx);
>  
>   reset_deferred_meminit(pgdat);
>   pgdat->node_id = nid;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a52167eabc96..b524d3b72527 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2762,7 +2762,7 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
>  
>   /* kswapd must be awake if processes are being throttled */
>   if (!wmark_ok && waitqueue_active(>kswapd_wait)) {
> - pgdat->classzone_idx = min(pgdat->classzone_idx,
> + pgdat->kswapd_classzone_idx = min(pgdat->kswapd_classzone_idx,
>   (enum zone_type)ZONE_NORMAL);
>   wake_up_interruptible(>kswapd_wait);
>   }
> @@ -3238,8 +3238,8 @@ static int balance_pgdat(pg_data_t *pgdat, int order, 
> int classzone_idx)
>   return sc.order;
>  }
>  
> -static void kswapd_try_to_sleep(pg_data_t *pgdat, int order,
> - int classzone_idx, int balanced_classzone_idx)
> +static void kswapd_try_to_sleep(pg_data_t *pgdat, int alloc_order, int 
> reclaim_order,
> + int classzone_idx)
>  {
>   long remaining = 0;
>   DEFINE_WAIT(wait);
> @@ -3249,9 +3249,19 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, int 
> order,
>  
>   prepare_to_wait(>kswapd_wait, , TASK_INTERRUPTIBLE);
>  
> + /*
> +  * If kswapd has not been woken recently, then kswapd goes fully
> +  * to sleep. kcompactd may still need to wake if the original
> +  * request was high-order.
> +  */
> + if (classzone_idx == -1) {
> + wakeup_kcompactd(pgdat, alloc_order, classzone_idx);
> + classzone_idx = MAX_NR_ZONES - 1;
> + goto full_sleep;
> + }
> +
>   /* Try to sleep for a short interval */
> - if (prepare_kswapd_sleep(pgdat, order, remaining,
> - balanced_classzone_idx)) {
> + if (prepare_kswapd_sleep(pgdat, reclaim_order, remaining, 
> classzone_idx)) {


Just trivial but this is clean up patch so I suggest one.
If it doesn't help readability, just ignore, please.

This(ie, first prepare_kswapd_sleep always get 0 remaining value so
it's pointless argument for the function. We could remove it and

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

[Minchan Kim]

On Fri, Jul 01, 2016 at 09:01:16PM +0100, Mel Gorman wrote:
> kswapd goes through some complex steps trying to figure out if it should
> stay awake based on the classzone_idx and the requested order.  It is
> unnecessarily complex and passes in an invalid classzone_idx to
> balance_pgdat().  What matters most of all is whether a larger order has
> been requsted and whether kswapd successfully reclaimed at the previous
> order.  This patch irons out the logic to check just that and the end
> result is less headache inducing.
> 
> Signed-off-by: Mel Gorman 
> Acked-by: Johannes Weiner 
> Acked-by: Vlastimil Babka 
> ---
>  include/linux/mmzone.h |   5 ++-
>  mm/memory_hotplug.c|   5 ++-
>  mm/page_alloc.c|   2 +-
>  mm/vmscan.c| 102 
> ++---
>  4 files changed, 62 insertions(+), 52 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 258c20758e80..eb74e63df5cf 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -667,8 +667,9 @@ typedef struct pglist_data {
>   wait_queue_head_t pfmemalloc_wait;
>   struct task_struct *kswapd; /* Protected by
>  mem_hotplug_begin/end() */
> - int kswapd_max_order;
> - enum zone_type classzone_idx;
> + int kswapd_order;
> + enum zone_type kswapd_classzone_idx;
> +
>  #ifdef CONFIG_COMPACTION
>   int kcompactd_max_order;
>   enum zone_type kcompactd_classzone_idx;
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c5278360ca66..065140ecd081 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1209,9 +1209,10 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 
> start)
>  
>   arch_refresh_nodedata(nid, pgdat);
>   } else {
> - /* Reset the nr_zones and classzone_idx to 0 before reuse */
> + /* Reset the nr_zones, order and classzone_idx before reuse */
>   pgdat->nr_zones = 0;
> - pgdat->classzone_idx = 0;
> + pgdat->kswapd_order = 0;
> + pgdat->kswapd_classzone_idx = 0;
>   }
>  
>   /* we can use NODE_DATA(nid) from here */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 59e4463e5dce..f58548139bf2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6084,7 +6084,7 @@ void __paginginit free_area_init_node(int nid, unsigned 
> long *zones_size,
>   unsigned long end_pfn = 0;
>  
>   /* pg_data_t should be reset to zero when it's allocated */
> - WARN_ON(pgdat->nr_zones || pgdat->classzone_idx);
> + WARN_ON(pgdat->nr_zones || pgdat->kswapd_classzone_idx);
>  
>   reset_deferred_meminit(pgdat);
>   pgdat->node_id = nid;
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a52167eabc96..b524d3b72527 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2762,7 +2762,7 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
>  
>   /* kswapd must be awake if processes are being throttled */
>   if (!wmark_ok && waitqueue_active(>kswapd_wait)) {
> - pgdat->classzone_idx = min(pgdat->classzone_idx,
> + pgdat->kswapd_classzone_idx = min(pgdat->kswapd_classzone_idx,
>   (enum zone_type)ZONE_NORMAL);
>   wake_up_interruptible(>kswapd_wait);
>   }
> @@ -3238,8 +3238,8 @@ static int balance_pgdat(pg_data_t *pgdat, int order, 
> int classzone_idx)
>   return sc.order;
>  }
>  
> -static void kswapd_try_to_sleep(pg_data_t *pgdat, int order,
> - int classzone_idx, int balanced_classzone_idx)
> +static void kswapd_try_to_sleep(pg_data_t *pgdat, int alloc_order, int 
> reclaim_order,
> + int classzone_idx)
>  {
>   long remaining = 0;
>   DEFINE_WAIT(wait);
> @@ -3249,9 +3249,19 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, int 
> order,
>  
>   prepare_to_wait(>kswapd_wait, , TASK_INTERRUPTIBLE);
>  
> + /*
> +  * If kswapd has not been woken recently, then kswapd goes fully
> +  * to sleep. kcompactd may still need to wake if the original
> +  * request was high-order.
> +  */
> + if (classzone_idx == -1) {
> + wakeup_kcompactd(pgdat, alloc_order, classzone_idx);
> + classzone_idx = MAX_NR_ZONES - 1;
> + goto full_sleep;
> + }
> +
>   /* Try to sleep for a short interval */
> - if (prepare_kswapd_sleep(pgdat, order, remaining,
> - balanced_classzone_idx)) {
> + if (prepare_kswapd_sleep(pgdat, reclaim_order, remaining, 
> classzone_idx)) {


Just trivial but this is clean up patch so I suggest one.
If it doesn't help readability, just ignore, please.

This(ie, first prepare_kswapd_sleep always get 0 remaining value so
it's pointless argument for the function. We could remove it and
check it before second prepare_kswapd_sleep call.

full_sleep:

Re: [RFC RESEND PATCH] swap: choose swap device according to numa node

[Yu Chen]

On Tue, Jul 5, 2016 at 11:19 AM, Aaron Lu  wrote:
> Resend:
> This is a resend, the original patch doesn't catch much attention.
> It may not be a big deal for swap devices that used to be hosted on
> HDD but with devices like 3D Xpoint to be used as swap device, it could
> make a real difference if we consider NUMA information when doing IO.
> Comments are appreciated, thanks for your time.
>
-%<-
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 71b1c29948db..dd7e44a315b0 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3659,9 +3659,11 @@ void kswapd_stop(int nid)
>
>  static int __init kswapd_init(void)
>  {
> -   int nid;
> +   int nid, err;
>
> -   swap_setup();
> +   err = swap_setup();
> +   if (err)
> +   return err;
> for_each_node_state(nid, N_MEMORY)
> kswapd_run(nid);
> hotcpu_notifier(cpu_callback, 0);
In original implementation, although swap_setup failed,
the swapd would also be created, since swapd is
not only  used for swap out but also for other page reclaim,
so this change above might modify its semantic? Sorry if
I understand incorrectly.

Re: [RFC RESEND PATCH] swap: choose swap device according to numa node

[Yu Chen]

On Tue, Jul 5, 2016 at 11:19 AM, Aaron Lu  wrote:
> Resend:
> This is a resend, the original patch doesn't catch much attention.
> It may not be a big deal for swap devices that used to be hosted on
> HDD but with devices like 3D Xpoint to be used as swap device, it could
> make a real difference if we consider NUMA information when doing IO.
> Comments are appreciated, thanks for your time.
>
-%<-
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 71b1c29948db..dd7e44a315b0 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3659,9 +3659,11 @@ void kswapd_stop(int nid)
>
>  static int __init kswapd_init(void)
>  {
> -   int nid;
> +   int nid, err;
>
> -   swap_setup();
> +   err = swap_setup();
> +   if (err)
> +   return err;
> for_each_node_state(nid, N_MEMORY)
> kswapd_run(nid);
> hotcpu_notifier(cpu_callback, 0);
In original implementation, although swap_setup failed,
the swapd would also be created, since swapd is
not only  used for swap out but also for other page reclaim,
so this change above might modify its semantic? Sorry if
I understand incorrectly.

[PATCH 2/2] ACPICA: Namespace: Fix lock order issue for namespace/interpreter

[Lv Zheng]

There is a lock order issue in acpi_load_tables(). The namespace lock is held
before holding the interpreter lock.
With ACPI_MUTEX_DEBUG enabled in kernel, we can reproduce this during boot:
  [0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns 
[ACPI_MTX_Namespace], wants [ACPI_MTX_Interpreter] (20160422/utmutex-263)
  [0.885881] ACPI Error: Could not acquire AML Interpreter mutex 
(20160422/exutils-95)
  [0.893846] ACPI Error: Mutex [0x0] is not acquired, cannot release 
(20160422/utmutex-326)
  [0.894019] ACPI Error: Could not release AML Interpreter mutex 
(20160422/exutils-133)

The issue is introduced by the following commit:
  Commit: 2f38b1b16d9280689e5cfa47a4c50956bf437f0d
  ACPICA Commit: bfe03ffcde8ed56a7eae38ea0b188aeb12f9c52e
  Subject: ACPICA: Namespace: Fix a regression that MLC support triggers
   dead lock in dynamic table loading
Which fixes a dead lock issue for acpi_ns_load_table() in
acpi_ex_add_table() but doesn't take care of the lock order in
acpi_ns_load_table().

Originally (before applying the wrong fix), ACPICA uses the
namespace/interpreter locks in the following 2 key code paths:
1. Table loading (before applying 2f38b1b):
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
2. Object evaluation:
acpi_ns_evaluate
L(Interpreter)
acpi_ps_execute_method
U(Interpreter)
acpi_ns_load_table
L(Namespace)
U(Namespace)
acpi_ev_initialize_region
L(Namespace)
U(Namespace)
address_space.setup
L(Namespace)
U(Namespace)
address_space.handler
L(Namespace)
U(Namespace)
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
L(Interpreter)
U(Interpreter)
During runtime, while acpi_ns_evaluate is called, lock order is always
Interpreter -> Namespace.

While the wrong fix holds the lock in the following order:
3. Table loading (after applying 2f38b1b):
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
L(Interpreter)
acpi_ns_one_complete_parse
U(Interpreter)
U(Namespace)

This patch further fixes the lock order issue by moving interpreter lock
to acpi_ns_load_table() to ensure the lock order correctness:
4. Table loading:
acpi_ns_load_table
L(Interpreter)
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
U(Interpreter)

However, this fix is just a workaround which is compliant to the current
design but doesn't fix the current design issues related to the namespace
lock. For example, we can notice that in acpi_ns_evaluate(), outside of
acpi_ns_load_table(), the namespace objects may be created by the named
object creation control methods. And the creations of the method owned
namespace objects are not locked by the namespace lock. This patch doesn't
try to fix such kind of existing issues. Lv Zheng.

Fixes: 2f38b1b16d92 ("ACPICA: Namespace: Fix a regression that MLC support 
triggers dead lock in dynamic table loading")
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/nsload.c  |7 ++-
 drivers/acpi/acpica/nsparse.c |9 ++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index b5e2b0a..297f6aa 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -46,6 +46,7 @@
 #include "acnamesp.h"
 #include "acdispat.h"
 #include "actables.h"
+#include "acinterp.h"
 
 #define _COMPONENT  ACPI_NAMESPACE
 ACPI_MODULE_NAME("nsload")
@@ -78,6 +79,8 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 
ACPI_FUNCTION_TRACE(ns_load_table);
 
+   acpi_ex_enter_interpreter();
+
/*
 * Parse the table and load the namespace with all named
 * objects found within. Control methods are NOT parsed
@@ -89,7 +92,7 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 */
status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
if (ACPI_FAILURE(status)) {
-   return_ACPI_STATUS(status);
+   goto unlock_interp;
}
 
/* If table already loaded into namespace, just return */
@@ -130,6 +133,8 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 
 unlock:
(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+unlock_interp:
+   (void)acpi_ex_exit_interpreter();
 
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
diff --git 

[PATCH 1/2] ACPICA: Linux: Enable ACPI_MUTEX_DEBUG for Linux kernel

[Lv Zheng]

This patch enables ACPI_MUTEX_DEBUG for Linux kernel so that the ACPICA
lock order issues can be captured by ACPICA itself.

Signed-off-by: Lv Zheng 
---
 include/acpi/platform/aclinux.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index 45c2d65..93b61b1 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -73,6 +73,10 @@
 #define ACPI_DEBUGGER
 #endif
 
+#ifdef CONFIG_ACPI_DEBUG
+#define ACPI_MUTEX_DEBUG
+#endif
+
 #include 
 #include 
 #include 
-- 
1.7.10

[PATCH 2/2] ACPICA: Namespace: Fix lock order issue for namespace/interpreter

[Lv Zheng]

There is a lock order issue in acpi_load_tables(). The namespace lock is held
before holding the interpreter lock.
With ACPI_MUTEX_DEBUG enabled in kernel, we can reproduce this during boot:
  [0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns 
[ACPI_MTX_Namespace], wants [ACPI_MTX_Interpreter] (20160422/utmutex-263)
  [0.885881] ACPI Error: Could not acquire AML Interpreter mutex 
(20160422/exutils-95)
  [0.893846] ACPI Error: Mutex [0x0] is not acquired, cannot release 
(20160422/utmutex-326)
  [0.894019] ACPI Error: Could not release AML Interpreter mutex 
(20160422/exutils-133)

The issue is introduced by the following commit:
  Commit: 2f38b1b16d9280689e5cfa47a4c50956bf437f0d
  ACPICA Commit: bfe03ffcde8ed56a7eae38ea0b188aeb12f9c52e
  Subject: ACPICA: Namespace: Fix a regression that MLC support triggers
   dead lock in dynamic table loading
Which fixes a dead lock issue for acpi_ns_load_table() in
acpi_ex_add_table() but doesn't take care of the lock order in
acpi_ns_load_table().

Originally (before applying the wrong fix), ACPICA uses the
namespace/interpreter locks in the following 2 key code paths:
1. Table loading (before applying 2f38b1b):
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
2. Object evaluation:
acpi_ns_evaluate
L(Interpreter)
acpi_ps_execute_method
U(Interpreter)
acpi_ns_load_table
L(Namespace)
U(Namespace)
acpi_ev_initialize_region
L(Namespace)
U(Namespace)
address_space.setup
L(Namespace)
U(Namespace)
address_space.handler
L(Namespace)
U(Namespace)
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
L(Interpreter)
U(Interpreter)
During runtime, while acpi_ns_evaluate is called, lock order is always
Interpreter -> Namespace.

While the wrong fix holds the lock in the following order:
3. Table loading (after applying 2f38b1b):
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
L(Interpreter)
acpi_ns_one_complete_parse
U(Interpreter)
U(Namespace)

This patch further fixes the lock order issue by moving interpreter lock
to acpi_ns_load_table() to ensure the lock order correctness:
4. Table loading:
acpi_ns_load_table
L(Interpreter)
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
U(Interpreter)

However, this fix is just a workaround which is compliant to the current
design but doesn't fix the current design issues related to the namespace
lock. For example, we can notice that in acpi_ns_evaluate(), outside of
acpi_ns_load_table(), the namespace objects may be created by the named
object creation control methods. And the creations of the method owned
namespace objects are not locked by the namespace lock. This patch doesn't
try to fix such kind of existing issues. Lv Zheng.

Fixes: 2f38b1b16d92 ("ACPICA: Namespace: Fix a regression that MLC support 
triggers dead lock in dynamic table loading")
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/nsload.c  |7 ++-
 drivers/acpi/acpica/nsparse.c |9 ++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index b5e2b0a..297f6aa 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -46,6 +46,7 @@
 #include "acnamesp.h"
 #include "acdispat.h"
 #include "actables.h"
+#include "acinterp.h"
 
 #define _COMPONENT  ACPI_NAMESPACE
 ACPI_MODULE_NAME("nsload")
@@ -78,6 +79,8 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 
ACPI_FUNCTION_TRACE(ns_load_table);
 
+   acpi_ex_enter_interpreter();
+
/*
 * Parse the table and load the namespace with all named
 * objects found within. Control methods are NOT parsed
@@ -89,7 +92,7 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 */
status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
if (ACPI_FAILURE(status)) {
-   return_ACPI_STATUS(status);
+   goto unlock_interp;
}
 
/* If table already loaded into namespace, just return */
@@ -130,6 +133,8 @@ acpi_ns_load_table(u32 table_index, struct 
acpi_namespace_node *node)
 
 unlock:
(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+unlock_interp:
+   (void)acpi_ex_exit_interpreter();
 
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
diff --git 

[PATCH 1/2] ACPICA: Linux: Enable ACPI_MUTEX_DEBUG for Linux kernel

[Lv Zheng]

This patch enables ACPI_MUTEX_DEBUG for Linux kernel so that the ACPICA
lock order issues can be captured by ACPICA itself.

Signed-off-by: Lv Zheng 
---
 include/acpi/platform/aclinux.h |4 
 1 file changed, 4 insertions(+)

diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index 45c2d65..93b61b1 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -73,6 +73,10 @@
 #define ACPI_DEBUGGER
 #endif
 
+#ifdef CONFIG_ACPI_DEBUG
+#define ACPI_MUTEX_DEBUG
+#endif
+
 #include 
 #include 
 #include 
-- 
1.7.10

Re: [PATCH 3/5] mmu: don't set the present bit unconditionally

[Wanpeng Li]

2016-06-28 16:57 GMT+08:00 Paolo Bonzini :
>
>
> On 28/06/2016 06:32, Bandan Das wrote:
>> + bool execonly = !(context->guest_rsvd_check.bad_mt_xwr &
>> +   (1ull << VMX_EPT_EXECUTABLE_MASK));
>>
>>   if (set_mmio_spte(vcpu, sptep, gfn, pfn, pte_access))
>>   return 0;
>>
>> - spte = PT_PRESENT_MASK;
>> + if (!execonly)
>> + spte |= PT_PRESENT_MASK;
>
> This needs a comment:
>
> /*
>  * There are two cases in which execonly is false: 1) for
>  * non-EPT page tables, in which case we need to set the
>  * P bit; 2) for EPT page tables where an X-- page table

In the scenario of non-EPT shadow page table and non-nested, the
present bit can't be set any more since
context->guest_rsvd_check.bad_mt_xwr is always 0.

Regards,
Wanpeng Li

Re: [PATCH 3/5] mmu: don't set the present bit unconditionally

[Wanpeng Li]

2016-06-28 16:57 GMT+08:00 Paolo Bonzini :
>
>
> On 28/06/2016 06:32, Bandan Das wrote:
>> + bool execonly = !(context->guest_rsvd_check.bad_mt_xwr &
>> +   (1ull << VMX_EPT_EXECUTABLE_MASK));
>>
>>   if (set_mmio_spte(vcpu, sptep, gfn, pfn, pte_access))
>>   return 0;
>>
>> - spte = PT_PRESENT_MASK;
>> + if (!execonly)
>> + spte |= PT_PRESENT_MASK;
>
> This needs a comment:
>
> /*
>  * There are two cases in which execonly is false: 1) for
>  * non-EPT page tables, in which case we need to set the
>  * P bit; 2) for EPT page tables where an X-- page table

In the scenario of non-EPT shadow page table and non-nested, the
present bit can't be set any more since
context->guest_rsvd_check.bad_mt_xwr is always 0.

Regards,
Wanpeng Li

Re: [RESEND, v2] powerpc: Export thread_struct.used_vr/used_vsr to user space

[Michael Ellerman]

On Wed, 2016-06-04 at 07:00:12 UTC, Simon Guo wrote:
> These 2 fields track whether user process has used Altivec/VSX
> registers or not. They are used by kernel to setup signal frame
> on user stack correctly regarding vector part.
> 
> CRIU(Checkpoint and Restore In User space) builds signal frame
> for restored process. It will need this export information to
> setup signal frame correctly. And CRIU will need to restore these
> 2 fields for the restored process.
> 
> Signed-off-by: Simon Guo 
> Reviewed-by: Laurent Dufour 
> 
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h 
> b/arch/powerpc/include/uapi/asm/ptrace.h
> index 8036b38..d5afe95 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -176,6 +176,17 @@ struct pt_regs {
>  #define PTRACE_GETREGS64   0x16
>  #define PTRACE_SETREGS64   0x17
>  
> +/*
> + * Get or set some register used bit.
> + * The flags will be saved in a 32 bit data.
> + * Currently it is only used for VR/VSR usage.
> + */
> +#define PTRACE_GET_REGS_USAGE  0x1e
> +#define PTRACE_SET_REGS_USAGE  0x1f
> +
> +#define PTRACE_REGS_USAGE_VR_BIT  0x0001
> +#define PTRACE_REGS_USAGE_VSR_BIT 0x0002


It looks like you just made up this new ptrace ABI ?

Or is it used on other arches ? (no AFAICS)

How do other arches handle this ?

I'm a bit wary of adding new ptrace ABIs.

If we do want to do this, I'd at least think the mask should be u64, to give us
more capacity to add new registers.

cheers

Re: [RESEND, v2] powerpc: Export thread_struct.used_vr/used_vsr to user space

[Michael Ellerman]

On Wed, 2016-06-04 at 07:00:12 UTC, Simon Guo wrote:
> These 2 fields track whether user process has used Altivec/VSX
> registers or not. They are used by kernel to setup signal frame
> on user stack correctly regarding vector part.
> 
> CRIU(Checkpoint and Restore In User space) builds signal frame
> for restored process. It will need this export information to
> setup signal frame correctly. And CRIU will need to restore these
> 2 fields for the restored process.
> 
> Signed-off-by: Simon Guo 
> Reviewed-by: Laurent Dufour 
> 
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h 
> b/arch/powerpc/include/uapi/asm/ptrace.h
> index 8036b38..d5afe95 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -176,6 +176,17 @@ struct pt_regs {
>  #define PTRACE_GETREGS64   0x16
>  #define PTRACE_SETREGS64   0x17
>  
> +/*
> + * Get or set some register used bit.
> + * The flags will be saved in a 32 bit data.
> + * Currently it is only used for VR/VSR usage.
> + */
> +#define PTRACE_GET_REGS_USAGE  0x1e
> +#define PTRACE_SET_REGS_USAGE  0x1f
> +
> +#define PTRACE_REGS_USAGE_VR_BIT  0x0001
> +#define PTRACE_REGS_USAGE_VSR_BIT 0x0002


It looks like you just made up this new ptrace ABI ?

Or is it used on other arches ? (no AFAICS)

How do other arches handle this ?

I'm a bit wary of adding new ptrace ABIs.

If we do want to do this, I'd at least think the mask should be u64, to give us
more capacity to add new registers.

cheers

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> The vGPU folks would like to trap the first access to a BAR by setting
> vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
> then can use remap_pfn_range to place some non-reserved pages in the VMA.
> 
> KVM lacks support for this kind of non-linear VM_PFNMAP mapping, and these
> patches should fix this.

Hi Paolo,

I have tested your patches with the mediated passthru patchset that is being
reviewed in KVM and QEMU mailing list.

The fault handler gets called successfully and the previously mapped memory gets
unmmaped correctly via unmap_mapping_range.

Thanks,
Neo

> 
> Thanks,
> 
> Paolo
> 
> Paolo Bonzini (2):
>   KVM: MMU: prepare to support mapping of VM_IO and VM_PFNMAP frames
>   KVM: MMU: try to fix up page faults before giving up
> 
>  mm/gup.c|  1 +
>  virt/kvm/kvm_main.c | 55 
> -
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH] ARM: uniphier: remove empty DT machine descriptor

[Olof Johansson]

On Tue, Jun 28, 2016 at 06:25:10PM +0900, Masahiro Yamada wrote:
> Since the initial support of mach-uniphier, this has always been
> just empty.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks.


-Olof

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> The vGPU folks would like to trap the first access to a BAR by setting
> vm_ops on the VMAs produced by mmap-ing a VFIO device.  The fault handler
> then can use remap_pfn_range to place some non-reserved pages in the VMA.
> 
> KVM lacks support for this kind of non-linear VM_PFNMAP mapping, and these
> patches should fix this.

Hi Paolo,

I have tested your patches with the mediated passthru patchset that is being
reviewed in KVM and QEMU mailing list.

The fault handler gets called successfully and the previously mapped memory gets
unmmaped correctly via unmap_mapping_range.

Thanks,
Neo

> 
> Thanks,
> 
> Paolo
> 
> Paolo Bonzini (2):
>   KVM: MMU: prepare to support mapping of VM_IO and VM_PFNMAP frames
>   KVM: MMU: try to fix up page faults before giving up
> 
>  mm/gup.c|  1 +
>  virt/kvm/kvm_main.c | 55 
> -
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH] ARM: uniphier: remove empty DT machine descriptor

[Olof Johansson]

On Tue, Jun 28, 2016 at 06:25:10PM +0900, Masahiro Yamada wrote:
> Since the initial support of mach-uniphier, this has always been
> just empty.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks.


-Olof

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
 wrote:
> Hi Duc,
>
> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
>>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
>>>  wrote:
 On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
> From: Tomasz Nowicki 
>
> pci_generic_ecam_ops is used by default. Since there are platforms
> which have non-compliant ECAM space we need to overwrite these
> accessors prior to PCI buses enumeration. In order to do that
> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
> we can use proper PCI config space accessors and bus_shift.
>
> pci_generic_ecam_ops is still used for platforms free from quirks.
>
> Signed-off-by: Tomasz Nowicki 
> ---
>  arch/arm64/kernel/pci.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 94cd43c..a891bda 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> *root)
>   struct pci_config_window *cfg;
>   struct resource cfgres;
>   unsigned int bsz;
> + struct pci_ecam_ops *ops;
>
>   /* Use address from _CBA if present, otherwise lookup MCFG */
>   if (!root->mcfg_addr)
> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> *root)
>   return NULL;
>   }
>
> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
> + ops = pci_mcfg_get_ops(root);
> + bsz = 1 << ops->bus_shift;
>   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>   cfgres.flags = IORESOURCE_MEM;
> - cfg = pci_ecam_create(>device->dev, , bus_res,
> -   _generic_ecam_ops);
> + cfg = pci_ecam_create(>device->dev, , bus_res, ops);

 Arnd pointed this out already, I think that's the only pending question
 here.

 pci_ecam_create() maps ECAM space for config regions retrieved from
 the MCFG, which are *supposed* to be ECAM compliant.

 Do we think that's *always* correct/safe regardless of the kind
 of quirk we are currently fixing up ?

 Or we do think that configuration space regions should come from
 a different resource declared in the ACPI namespace if the regions
 are not MCFG/ECAM compliant (ie config space is not defined through
 MCFG at all - possibly through a _CRS method for a vendor specific
 _HID under the PNP0A03 node ?)
>>>
>>> Hi Lorenzo,
>>>
>>> For X-Gene: the ECAM space is used to access the configuration space
>>> of PCIe devices, with additional help from controller register to
>>> specify the bus, device and function number. Below is the RFC patch
>>> that implements ECAM fixup for X-Gene PCIe controller on top of this
>>> RFC ECAM quirk v3 for your and others reference.
>>
>> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>> your register that is a deliberate abuse of the ACPI standard in
>> that the _CRS is meant to describe resources that are passed on
>> to secondary buses
>
> A potential alternative came up in an off-list discussion: Would it be
> better to hard code the information in the quirk workaround than look it
> up from a repurposed ACPI resource?

Hi Chris, Lorenzo,

Thanks for looking into this.

Yes, I am open for this approach and I think it may work. I can
+ check the pci_config_window resource start address (cfg->res.start)
to figure out the controller and then get the fixed controller
register address
or
+ using the domain number to identify the controller.

Regards,
Duc Dang.
>
> Supporting quirk workarounds for early, non-compliant hardware is
> helpful and perhaps necessary for bootstrapping the ecosystem in a
> timely manner. But we don't really want to provide an expandable or
> reusable interface that would make it easy for new hardware to remain
> non-compliant.
>
> Regards,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
 wrote:
> Hi Duc,
>
> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
>>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
>>>  wrote:
 On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
> From: Tomasz Nowicki 
>
> pci_generic_ecam_ops is used by default. Since there are platforms
> which have non-compliant ECAM space we need to overwrite these
> accessors prior to PCI buses enumeration. In order to do that
> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
> we can use proper PCI config space accessors and bus_shift.
>
> pci_generic_ecam_ops is still used for platforms free from quirks.
>
> Signed-off-by: Tomasz Nowicki 
> ---
>  arch/arm64/kernel/pci.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 94cd43c..a891bda 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> *root)
>   struct pci_config_window *cfg;
>   struct resource cfgres;
>   unsigned int bsz;
> + struct pci_ecam_ops *ops;
>
>   /* Use address from _CBA if present, otherwise lookup MCFG */
>   if (!root->mcfg_addr)
> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
> *root)
>   return NULL;
>   }
>
> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
> + ops = pci_mcfg_get_ops(root);
> + bsz = 1 << ops->bus_shift;
>   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>   cfgres.flags = IORESOURCE_MEM;
> - cfg = pci_ecam_create(>device->dev, , bus_res,
> -   _generic_ecam_ops);
> + cfg = pci_ecam_create(>device->dev, , bus_res, ops);

 Arnd pointed this out already, I think that's the only pending question
 here.

 pci_ecam_create() maps ECAM space for config regions retrieved from
 the MCFG, which are *supposed* to be ECAM compliant.

 Do we think that's *always* correct/safe regardless of the kind
 of quirk we are currently fixing up ?

 Or we do think that configuration space regions should come from
 a different resource declared in the ACPI namespace if the regions
 are not MCFG/ECAM compliant (ie config space is not defined through
 MCFG at all - possibly through a _CRS method for a vendor specific
 _HID under the PNP0A03 node ?)
>>>
>>> Hi Lorenzo,
>>>
>>> For X-Gene: the ECAM space is used to access the configuration space
>>> of PCIe devices, with additional help from controller register to
>>> specify the bus, device and function number. Below is the RFC patch
>>> that implements ECAM fixup for X-Gene PCIe controller on top of this
>>> RFC ECAM quirk v3 for your and others reference.
>>
>> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>> your register that is a deliberate abuse of the ACPI standard in
>> that the _CRS is meant to describe resources that are passed on
>> to secondary buses
>
> A potential alternative came up in an off-list discussion: Would it be
> better to hard code the information in the quirk workaround than look it
> up from a repurposed ACPI resource?

Hi Chris, Lorenzo,

Thanks for looking into this.

Yes, I am open for this approach and I think it may work. I can
+ check the pci_config_window resource start address (cfg->res.start)
to figure out the controller and then get the fixed controller
register address
or
+ using the domain number to identify the controller.

Regards,
Duc Dang.
>
> Supporting quirk workarounds for early, non-compliant hardware is
> helpful and perhaps necessary for bootstrapping the ecosystem in a
> timely manner. But we don't really want to provide an expandable or
> reusable interface that would make it easy for new hardware to remain
> non-compliant.
>
> Regards,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Michael Haas]

Hi,

nice work! Is this in any way related to Bruno Prémonts driver for the 
axp20x?


I've got a reworked version of that lying around, but it's not quite 
ready for submission. Do you know what pieces are missing in your driver 
for axp20x support - as opposed to axp22x, which is already working?


Michael

On 01.07.2016 11:29, Icenowy Zheng wrote:

This driver is the battery power supply driver of axp20x PMIC. Currently
it supports only AXP22x variants.

Signed-off-by: Icenowy Zheng 
---
  drivers/mfd/axp20x.c   |  14 +++
  drivers/power/Makefile |   1 +
  drivers/power/axp20x_battery.c | 254 +
  3 files changed, 269 insertions(+)
  create mode 100644 drivers/power/axp20x_battery.c

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cee5288..064e5015 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -166,6 +166,15 @@ static struct resource axp22x_usb_power_supply_resources[] 
= {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
  };
  
+static struct resource axp22x_battery_resources[] = {

+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_PLUGIN, "BATT_PLUGIN"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_REMOVAL, "BATT_REMOVAL"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_ENT_ACT_MODE, "BATT_ENT_ACT_MODE"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_EXIT_ACT_MODE, 
"BATT_EXIT_ACT_MODE"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG, "CHARG"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG_DONE, "CHARG_DONE"),
+};
+
  static struct resource axp22x_pek_resources[] = {
{
.name   = "PEK_DBR",
@@ -538,6 +547,11 @@ static struct mfd_cell axp22x_cells[] = {
.of_compatible  = "x-powers,axp202-usb-power-supply",
.num_resources  = ARRAY_SIZE(axp22x_usb_power_supply_resources),
.resources  = axp22x_usb_power_supply_resources,
+   }, {
+   .name   = "axp20x-battery",
+   .of_compatible  = "x-powers,axp202-battery",
+   .num_resources  = ARRAY_SIZE(axp22x_battery_resources),
+   .resources  = axp22x_battery_resources,
},
  };
  
diff --git a/drivers/power/Makefile b/drivers/power/Makefile

index e46b75d..1452d23 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
  obj-$(CONFIG_PDA_POWER)   += pda_power.o
  obj-$(CONFIG_APM_POWER)   += apm_power.o
  obj-$(CONFIG_AXP20X_POWER)+= axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_battery.o
  obj-$(CONFIG_MAX8925_POWER)   += max8925_power.o
  obj-$(CONFIG_WM831X_BACKUP)   += wm831x_backup.o
  obj-$(CONFIG_WM831X_POWER)+= wm831x_power.o
diff --git a/drivers/power/axp20x_battery.c b/drivers/power/axp20x_battery.c
new file mode 100644
index 000..8fac2cd
--- /dev/null
+++ b/drivers/power/axp20x_battery.c
@@ -0,0 +1,254 @@
+/*
+ * AXP20x PMIC battery status driver
+ *
+ * Copyright (C) 2016 Icenowy Zheng 
+ * Copyright (C) 2015 Hans de Goede 
+ * Copyright (C) 2014 Bruno Prémont 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME "axp20x-battery"
+
+#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
+#define AXP20X_PWR_STATUS_VBUS_USED BIT(4)
+#define AXP20X_PWR_STATUS_BAT_DIRECTION BIT(2)
+
+#define AXP20X_OP_MODE_CHARGING BIT(6)
+#define AXP20X_OP_MODE_BATTERY_PRESENT BIT(5)
+#define AXP20X_OP_MODE_BATTERY_ACTIVE BIT(3)
+
+#define AXP20X_CAPACITY_CORRECT BIT(7)
+
+struct axp20x_battery {
+   struct axp20x_dev *axp20x;
+   struct regmap *regmap;
+   struct power_supply *supply;
+};
+
+static irqreturn_t axp20x_battery_irq(int irq, void *devid)
+{
+   struct axp20x_battery *power = devid;
+
+   power_supply_changed(power->supply);
+
+   return IRQ_HANDLED;
+}
+
+static int axp20x_battery_get_property(struct power_supply *psy,
+   enum power_supply_property psp, union power_supply_propval *val)
+{
+   struct axp20x_battery *power = power_supply_get_drvdata(psy);
+   unsigned int input, op_mode, capacity, dh, dl;
+   int ret, ext;
+
+   /* All the properties below need the input-status reg value */
+   ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(power->regmap, AXP20X_PWR_OP_MODE, _mode);
+   if (ret)
+   return ret;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_HEALTH:
+   if (!(op_mode & 

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

[Michael Haas]

Hi,

nice work! Is this in any way related to Bruno Prémonts driver for the 
axp20x?


I've got a reworked version of that lying around, but it's not quite 
ready for submission. Do you know what pieces are missing in your driver 
for axp20x support - as opposed to axp22x, which is already working?


Michael

On 01.07.2016 11:29, Icenowy Zheng wrote:

This driver is the battery power supply driver of axp20x PMIC. Currently
it supports only AXP22x variants.

Signed-off-by: Icenowy Zheng 
---
  drivers/mfd/axp20x.c   |  14 +++
  drivers/power/Makefile |   1 +
  drivers/power/axp20x_battery.c | 254 +
  3 files changed, 269 insertions(+)
  create mode 100644 drivers/power/axp20x_battery.c

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cee5288..064e5015 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -166,6 +166,15 @@ static struct resource axp22x_usb_power_supply_resources[] 
= {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
  };
  
+static struct resource axp22x_battery_resources[] = {

+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_PLUGIN, "BATT_PLUGIN"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_REMOVAL, "BATT_REMOVAL"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_ENT_ACT_MODE, "BATT_ENT_ACT_MODE"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_EXIT_ACT_MODE, 
"BATT_EXIT_ACT_MODE"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG, "CHARG"),
+   DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG_DONE, "CHARG_DONE"),
+};
+
  static struct resource axp22x_pek_resources[] = {
{
.name   = "PEK_DBR",
@@ -538,6 +547,11 @@ static struct mfd_cell axp22x_cells[] = {
.of_compatible  = "x-powers,axp202-usb-power-supply",
.num_resources  = ARRAY_SIZE(axp22x_usb_power_supply_resources),
.resources  = axp22x_usb_power_supply_resources,
+   }, {
+   .name   = "axp20x-battery",
+   .of_compatible  = "x-powers,axp202-battery",
+   .num_resources  = ARRAY_SIZE(axp22x_battery_resources),
+   .resources  = axp22x_battery_resources,
},
  };
  
diff --git a/drivers/power/Makefile b/drivers/power/Makefile

index e46b75d..1452d23 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
  obj-$(CONFIG_PDA_POWER)   += pda_power.o
  obj-$(CONFIG_APM_POWER)   += apm_power.o
  obj-$(CONFIG_AXP20X_POWER)+= axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_battery.o
  obj-$(CONFIG_MAX8925_POWER)   += max8925_power.o
  obj-$(CONFIG_WM831X_BACKUP)   += wm831x_backup.o
  obj-$(CONFIG_WM831X_POWER)+= wm831x_power.o
diff --git a/drivers/power/axp20x_battery.c b/drivers/power/axp20x_battery.c
new file mode 100644
index 000..8fac2cd
--- /dev/null
+++ b/drivers/power/axp20x_battery.c
@@ -0,0 +1,254 @@
+/*
+ * AXP20x PMIC battery status driver
+ *
+ * Copyright (C) 2016 Icenowy Zheng 
+ * Copyright (C) 2015 Hans de Goede 
+ * Copyright (C) 2014 Bruno Prémont 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME "axp20x-battery"
+
+#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
+#define AXP20X_PWR_STATUS_VBUS_USED BIT(4)
+#define AXP20X_PWR_STATUS_BAT_DIRECTION BIT(2)
+
+#define AXP20X_OP_MODE_CHARGING BIT(6)
+#define AXP20X_OP_MODE_BATTERY_PRESENT BIT(5)
+#define AXP20X_OP_MODE_BATTERY_ACTIVE BIT(3)
+
+#define AXP20X_CAPACITY_CORRECT BIT(7)
+
+struct axp20x_battery {
+   struct axp20x_dev *axp20x;
+   struct regmap *regmap;
+   struct power_supply *supply;
+};
+
+static irqreturn_t axp20x_battery_irq(int irq, void *devid)
+{
+   struct axp20x_battery *power = devid;
+
+   power_supply_changed(power->supply);
+
+   return IRQ_HANDLED;
+}
+
+static int axp20x_battery_get_property(struct power_supply *psy,
+   enum power_supply_property psp, union power_supply_propval *val)
+{
+   struct axp20x_battery *power = power_supply_get_drvdata(psy);
+   unsigned int input, op_mode, capacity, dh, dl;
+   int ret, ext;
+
+   /* All the properties below need the input-status reg value */
+   ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, );
+   if (ret)
+   return ret;
+
+   ret = regmap_read(power->regmap, AXP20X_PWR_OP_MODE, _mode);
+   if (ret)
+   return ret;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_HEALTH:
+   if (!(op_mode & AXP20X_OP_MODE_BATTERY_PRESENT)) {
+   val->intval = 

[PATCH 09/10] phy: rockhip-usb: use devm_add_action_or_reset()

[Kishon Vijay Abraham I]

From: Sudip Mukherjee 

If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated.  Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.

Signed-off-by: Sudip Mukherjee 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-rockchip-usb.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index e66b5bf..2a7381f 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -236,9 +236,10 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
goto err_clk_prov;
}
 
-   err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
+   err = devm_add_action_or_reset(base->dev, rockchip_usb_phy_action,
+  rk_phy);
if (err)
-   goto err_devm_action;
+   return err;
 
rk_phy->phy = devm_phy_create(base->dev, child, );
if (IS_ERR(rk_phy->phy)) {
@@ -256,9 +257,6 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
else
return rockchip_usb_phy_power(rk_phy, 1);
 
-err_devm_action:
-   if (!rk_phy->uart_enabled)
-   of_clk_del_provider(child);
 err_clk_prov:
if (!rk_phy->uart_enabled)
clk_unregister(rk_phy->clk480m);
-- 
1.7.9.5

[PATCH 09/10] phy: rockhip-usb: use devm_add_action_or_reset()

[Kishon Vijay Abraham I]

From: Sudip Mukherjee 

If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated.  Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.

Signed-off-by: Sudip Mukherjee 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-rockchip-usb.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index e66b5bf..2a7381f 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -236,9 +236,10 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
goto err_clk_prov;
}
 
-   err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
+   err = devm_add_action_or_reset(base->dev, rockchip_usb_phy_action,
+  rk_phy);
if (err)
-   goto err_devm_action;
+   return err;
 
rk_phy->phy = devm_phy_create(base->dev, child, );
if (IS_ERR(rk_phy->phy)) {
@@ -256,9 +257,6 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
else
return rockchip_usb_phy_power(rk_phy, 1);
 
-err_devm_action:
-   if (!rk_phy->uart_enabled)
-   of_clk_del_provider(child);
 err_clk_prov:
if (!rk_phy->uart_enabled)
clk_unregister(rk_phy->clk480m);
-- 
1.7.9.5

[PATCH 04/10] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

[Kishon Vijay Abraham I]

From: David Lechner 

This is a new phy driver for the SoC USB controllers on the TI DA8xx
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.

Signed-off-by: David Lechner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig |   10 ++
 drivers/phy/Makefile|1 +
 drivers/phy/phy-da8xx-usb.c |  245 +++
 3 files changed, 256 insertions(+)
 create mode 100644 drivers/phy/phy-da8xx-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..02afc624 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -44,6 +44,16 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF && HAS_IOMEM
select GENERIC_PHY
 
+config PHY_DA8XX_USB
+   tristate "TI DA8xx USB PHY Driver"
+   depends on ARCH_DAVINCI_DA8XX
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the USB PHY on DA8xx SoCs.
+
+ This driver controls both the USB 1.1 PHY and the USB 2.0 PHY.
+
 config PHY_DM816X_USB
tristate "TI dm816x USB PHY driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..fa8480e 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
 obj-$(CONFIG_PHY_BCM_NS_USB2)  += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
new file mode 100644
index 000..b2e59b6
--- /dev/null
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -0,0 +1,245 @@
+/*
+ * phy-da8xx-usb - TI DaVinci DA8xx USB PHY driver
+ *
+ * Copyright (C) 2016 David Lechner 
+ *
+ * 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 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct da8xx_usb_phy {
+   struct phy_provider *phy_provider;
+   struct phy  *usb11_phy;
+   struct phy  *usb20_phy;
+   struct clk  *usb11_clk;
+   struct clk  *usb20_clk;
+   struct regmap   *regmap;
+};
+
+static int da8xx_usb11_phy_power_on(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
+
+   ret = clk_prepare_enable(d_phy->usb11_clk);
+   if (ret)
+   return ret;
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_USB1SUSPENDM,
+ CFGCHIP2_USB1SUSPENDM);
+
+   return 0;
+}
+
+static int da8xx_usb11_phy_power_off(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_USB1SUSPENDM, 0);
+
+   clk_disable_unprepare(d_phy->usb11_clk);
+
+   return 0;
+}
+
+static const struct phy_ops da8xx_usb11_phy_ops = {
+   .power_on   = da8xx_usb11_phy_power_on,
+   .power_off  = da8xx_usb11_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
+static int da8xx_usb20_phy_power_on(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
+
+   ret = clk_prepare_enable(d_phy->usb20_clk);
+   if (ret)
+   return ret;
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGPWRDN, 0);
+
+   return 0;
+}
+
+static int da8xx_usb20_phy_power_off(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGPWRDN,
+ CFGCHIP2_OTGPWRDN);
+
+   clk_disable_unprepare(d_phy->usb20_clk);
+
+   return 0;
+}
+
+static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   u32 val;
+
+   switch (mode) {
+   case PHY_MODE_USB_HOST: /* Force VBUS valid, ID = 0 */
+   val = CFGCHIP2_OTGMODE_FORCE_HOST;
+   break;
+   case PHY_MODE_USB_DEVICE:   /* Force VBUS valid, ID = 1 */
+   

[PATCH 04/10] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

[Kishon Vijay Abraham I]

From: David Lechner 

This is a new phy driver for the SoC USB controllers on the TI DA8xx
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.

Signed-off-by: David Lechner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig |   10 ++
 drivers/phy/Makefile|1 +
 drivers/phy/phy-da8xx-usb.c |  245 +++
 3 files changed, 256 insertions(+)
 create mode 100644 drivers/phy/phy-da8xx-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..02afc624 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -44,6 +44,16 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF && HAS_IOMEM
select GENERIC_PHY
 
+config PHY_DA8XX_USB
+   tristate "TI DA8xx USB PHY Driver"
+   depends on ARCH_DAVINCI_DA8XX
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the USB PHY on DA8xx SoCs.
+
+ This driver controls both the USB 1.1 PHY and the USB 2.0 PHY.
+
 config PHY_DM816X_USB
tristate "TI dm816x USB PHY driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..fa8480e 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_GENERIC_PHY)   += phy-core.o
 obj-$(CONFIG_PHY_BCM_NS_USB2)  += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
new file mode 100644
index 000..b2e59b6
--- /dev/null
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -0,0 +1,245 @@
+/*
+ * phy-da8xx-usb - TI DaVinci DA8xx USB PHY driver
+ *
+ * Copyright (C) 2016 David Lechner 
+ *
+ * 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 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct da8xx_usb_phy {
+   struct phy_provider *phy_provider;
+   struct phy  *usb11_phy;
+   struct phy  *usb20_phy;
+   struct clk  *usb11_clk;
+   struct clk  *usb20_clk;
+   struct regmap   *regmap;
+};
+
+static int da8xx_usb11_phy_power_on(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
+
+   ret = clk_prepare_enable(d_phy->usb11_clk);
+   if (ret)
+   return ret;
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_USB1SUSPENDM,
+ CFGCHIP2_USB1SUSPENDM);
+
+   return 0;
+}
+
+static int da8xx_usb11_phy_power_off(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_USB1SUSPENDM, 0);
+
+   clk_disable_unprepare(d_phy->usb11_clk);
+
+   return 0;
+}
+
+static const struct phy_ops da8xx_usb11_phy_ops = {
+   .power_on   = da8xx_usb11_phy_power_on,
+   .power_off  = da8xx_usb11_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
+static int da8xx_usb20_phy_power_on(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   int ret;
+
+   ret = clk_prepare_enable(d_phy->usb20_clk);
+   if (ret)
+   return ret;
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGPWRDN, 0);
+
+   return 0;
+}
+
+static int da8xx_usb20_phy_power_off(struct phy *phy)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+
+   regmap_write_bits(d_phy->regmap, CFGCHIP(2), CFGCHIP2_OTGPWRDN,
+ CFGCHIP2_OTGPWRDN);
+
+   clk_disable_unprepare(d_phy->usb20_clk);
+
+   return 0;
+}
+
+static int da8xx_usb20_phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   struct da8xx_usb_phy *d_phy = phy_get_drvdata(phy);
+   u32 val;
+
+   switch (mode) {
+   case PHY_MODE_USB_HOST: /* Force VBUS valid, ID = 0 */
+   val = CFGCHIP2_OTGMODE_FORCE_HOST;
+   break;
+   case PHY_MODE_USB_DEVICE:   /* Force VBUS valid, ID = 1 */
+   val = CFGCHIP2_OTGMODE_FORCE_DEVICE;
+   break;
+   case 

[PATCH 06/10] phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message

[Kishon Vijay Abraham I]

From: Peter Griffin 

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.

Signed-off-by: Peter Griffin 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-qcom-ufs-qmp-20nm.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/phy-qcom-ufs-qmp-20nm.c 
b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
index b16ea77..770087a 100644
--- a/drivers/phy/phy-qcom-ufs-qmp-20nm.c
+++ b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
@@ -196,7 +196,6 @@ static int ufs_qcom_phy_qmp_20nm_probe(struct 
platform_device *pdev)
 
phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
-   dev_err(dev, "%s: failed to allocate phy\n", __func__);
err = -ENOMEM;
goto out;
}
-- 
1.7.9.5

[PATCH 10/10] phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

[Kishon Vijay Abraham I]

From: Yoshihiro Shimoda 

This patch fixes an issue that the extcon_set_cable_state_() is possible
to cause "BUG: scheduling while atomic" because this driver calls
extcon_set_cable_state_() in the interrupt handler and mutex_lock()
is possible to be called by like the following call trace.
So, this patch adds a workqueue function to resolve this issue.

[9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303
[9.714569] Modules linked in:
[9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ 
#86
[9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[9.731624] Call trace:
[9.734077] [] dump_backtrace+0x0/0x1a8
[9.739470] [] show_stack+0x14/0x20
[9.744520] [] dump_stack+0x94/0xb8
[9.749568] [] __schedule_bug+0x44/0x58
[9.754966] [] __schedule+0x4e4/0x598
[9.760185] [] schedule+0x3c/0xa8
[9.765057] [] schedule_preempt_disabled+0x20/0x38
[9.771408] [] mutex_optimistic_spin+0x18c/0x1d0
[9.777583] [] __mutex_lock_slowpath+0x38/0x140
[9.783669] [] mutex_lock+0x44/0x60
[9.788717] [] kobject_uevent_env+0x250/0x500
[9.794634] [] extcon_update_state+0x220/0x298
[9.800634] [] extcon_set_cable_state_+0x78/0x88
[9.806812] [] rcar_gen3_device_recognition+0x5c/0xe0
[9.813420] [] rcar_gen3_phy_usb2_irq+0x3c/0x48
[9.819509] [] handle_irq_event_percpu+0x94/0x140
[9.825769] [] handle_irq_event+0x48/0x78
[9.831334] [] handle_fasteoi_irq+0xb8/0x1b0
[9.837162] [] generic_handle_irq+0x24/0x38
[9.842900] [] __handle_domain_irq+0x5c/0xb8
[9.848727] [] gic_handle_irq+0x58/0xb0

Reported-by: Simon Horman 
Fixes: 2b38543c8db1 ("phy: rcar-gen3-usb2: add extcon support")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-rcar-gen3-usb2.c |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 4be3f5d..31156c9 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
 #define USB2_INT_ENABLE0x000
@@ -81,9 +82,25 @@ struct rcar_gen3_chan {
struct extcon_dev *extcon;
struct phy *phy;
struct regulator *vbus;
+   struct work_struct work;
+   bool extcon_host;
bool has_otg;
 };
 
+static void rcar_gen3_phy_usb2_work(struct work_struct *work)
+{
+   struct rcar_gen3_chan *ch = container_of(work, struct rcar_gen3_chan,
+work);
+
+   if (ch->extcon_host) {
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   } else {
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   }
+}
+
 static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
 {
void __iomem *usb2_base = ch->base;
@@ -130,8 +147,8 @@ static void rcar_gen3_init_for_host(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_host_mode(ch, 1);
rcar_gen3_enable_vbus_ctrl(ch, 1);
 
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   ch->extcon_host = true;
+   schedule_work(>work);
 }
 
 static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
@@ -140,8 +157,8 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_host_mode(ch, 0);
rcar_gen3_enable_vbus_ctrl(ch, 0);
 
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   ch->extcon_host = false;
+   schedule_work(>work);
 }
 
 static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
@@ -301,6 +318,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
if (irq >= 0) {
int ret;
 
+   INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
-- 
1.7.9.5

[PATCH 06/10] phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message

[Kishon Vijay Abraham I]

From: Peter Griffin 

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.

Signed-off-by: Peter Griffin 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-qcom-ufs-qmp-20nm.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/phy-qcom-ufs-qmp-20nm.c 
b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
index b16ea77..770087a 100644
--- a/drivers/phy/phy-qcom-ufs-qmp-20nm.c
+++ b/drivers/phy/phy-qcom-ufs-qmp-20nm.c
@@ -196,7 +196,6 @@ static int ufs_qcom_phy_qmp_20nm_probe(struct 
platform_device *pdev)
 
phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
-   dev_err(dev, "%s: failed to allocate phy\n", __func__);
err = -ENOMEM;
goto out;
}
-- 
1.7.9.5

[PATCH 10/10] phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

[Kishon Vijay Abraham I]

From: Yoshihiro Shimoda 

This patch fixes an issue that the extcon_set_cable_state_() is possible
to cause "BUG: scheduling while atomic" because this driver calls
extcon_set_cable_state_() in the interrupt handler and mutex_lock()
is possible to be called by like the following call trace.
So, this patch adds a workqueue function to resolve this issue.

[9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303
[9.714569] Modules linked in:
[9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ 
#86
[9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[9.731624] Call trace:
[9.734077] [] dump_backtrace+0x0/0x1a8
[9.739470] [] show_stack+0x14/0x20
[9.744520] [] dump_stack+0x94/0xb8
[9.749568] [] __schedule_bug+0x44/0x58
[9.754966] [] __schedule+0x4e4/0x598
[9.760185] [] schedule+0x3c/0xa8
[9.765057] [] schedule_preempt_disabled+0x20/0x38
[9.771408] [] mutex_optimistic_spin+0x18c/0x1d0
[9.777583] [] __mutex_lock_slowpath+0x38/0x140
[9.783669] [] mutex_lock+0x44/0x60
[9.788717] [] kobject_uevent_env+0x250/0x500
[9.794634] [] extcon_update_state+0x220/0x298
[9.800634] [] extcon_set_cable_state_+0x78/0x88
[9.806812] [] rcar_gen3_device_recognition+0x5c/0xe0
[9.813420] [] rcar_gen3_phy_usb2_irq+0x3c/0x48
[9.819509] [] handle_irq_event_percpu+0x94/0x140
[9.825769] [] handle_irq_event+0x48/0x78
[9.831334] [] handle_fasteoi_irq+0xb8/0x1b0
[9.837162] [] generic_handle_irq+0x24/0x38
[9.842900] [] __handle_domain_irq+0x5c/0xb8
[9.848727] [] gic_handle_irq+0x58/0xb0

Reported-by: Simon Horman 
Fixes: 2b38543c8db1 ("phy: rcar-gen3-usb2: add extcon support")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-rcar-gen3-usb2.c |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 4be3f5d..31156c9 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
 #define USB2_INT_ENABLE0x000
@@ -81,9 +82,25 @@ struct rcar_gen3_chan {
struct extcon_dev *extcon;
struct phy *phy;
struct regulator *vbus;
+   struct work_struct work;
+   bool extcon_host;
bool has_otg;
 };
 
+static void rcar_gen3_phy_usb2_work(struct work_struct *work)
+{
+   struct rcar_gen3_chan *ch = container_of(work, struct rcar_gen3_chan,
+work);
+
+   if (ch->extcon_host) {
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   } else {
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
+   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   }
+}
+
 static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
 {
void __iomem *usb2_base = ch->base;
@@ -130,8 +147,8 @@ static void rcar_gen3_init_for_host(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_host_mode(ch, 1);
rcar_gen3_enable_vbus_ctrl(ch, 1);
 
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+   ch->extcon_host = true;
+   schedule_work(>work);
 }
 
 static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
@@ -140,8 +157,8 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan 
*ch)
rcar_gen3_set_host_mode(ch, 0);
rcar_gen3_enable_vbus_ctrl(ch, 0);
 
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
-   extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+   ch->extcon_host = false;
+   schedule_work(>work);
 }
 
 static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
@@ -301,6 +318,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
if (irq >= 0) {
int ret;
 
+   INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
-- 
1.7.9.5

[PATCH 05/10] phy: rockchip-usb: should be a child device of the GRF

[Kishon Vijay Abraham I]

From: Heiko Stuebner 

The usb-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate
platform-device but instead a sub-device of the GRF - using the
simply-mfd mechanism.

As the usb-phy is part of the kernel for some releases now, we keep
the old (and now deprecated) binding for compatibility purposes.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   27 
 drivers/phy/phy-rockchip-usb.c |   15 ---
 2 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
index 68498d5..cc6be96 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -5,11 +5,13 @@ Required properties:
  "rockchip,rk3066a-usb-phy"
  "rockchip,rk3188-usb-phy"
  "rockchip,rk3288-usb-phy"
- - rockchip,grf : phandle to the syscon managing the "general
-   register files"
  - #address-cells: should be 1
  - #size-cells: should be 0
 
+Deprecated properties:
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files" - phy should be a child of the GRF instead
+
 Sub-nodes:
 Each PHY should be represented as a sub-node.
 
@@ -28,14 +30,19 @@ Optional Properties:
 
 Example:
 
-usbphy: phy {
-   compatible = "rockchip,rk3288-usb-phy";
-   rockchip,grf = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+   usbphy: phy {
+   compatible = "rockchip,rk3288-usb-phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
 
-   usbphy0: usb-phy0 {
-   #phy-cells = <0>;
-   reg = <0x320>;
+   usbphy0: usb-phy0 {
+   #phy-cells = <0>;
+   reg = <0x320>;
+   };
};
 };
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index d60b149..e66b5bf 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -397,8 +397,13 @@ static int rockchip_usb_phy_probe(struct platform_device 
*pdev)
phy_base->pdata = match->data;
 
phy_base->dev = dev;
-   phy_base->reg_base = syscon_regmap_lookup_by_phandle(dev->of_node,
-"rockchip,grf");
+   phy_base->reg_base = ERR_PTR(-ENODEV);
+   if (dev->parent && dev->parent->of_node)
+   phy_base->reg_base = syscon_node_to_regmap(
+   dev->parent->of_node);
+   if (IS_ERR(phy_base->reg_base))
+   phy_base->reg_base = syscon_regmap_lookup_by_phandle(
+   dev->of_node, "rockchip,grf");
if (IS_ERR(phy_base->reg_base)) {
dev_err(>dev, "Missing rockchip,grf property\n");
return PTR_ERR(phy_base->reg_base);
@@ -463,7 +468,11 @@ static int __init rockchip_init_usb_uart(void)
return -ENOTSUPP;
}
 
-   grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+   grf = ERR_PTR(-ENODEV);
+   if (np->parent)
+   grf = syscon_node_to_regmap(np->parent);
+   if (IS_ERR(grf))
+   grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(grf)) {
pr_err("%s: Missing rockchip,grf property, %lu\n",
   __func__, PTR_ERR(grf));
-- 
1.7.9.5

[PATCH 07/10] phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

[Kishon Vijay Abraham I]

From: Peter Griffin 

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.

Signed-off-by: Peter Griffin 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-qcom-ufs-qmp-14nm.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c 
b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
index 56631e7..6ee5149 100644
--- a/drivers/phy/phy-qcom-ufs-qmp-14nm.c
+++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
@@ -140,7 +140,6 @@ static int ufs_qcom_phy_qmp_14nm_probe(struct 
platform_device *pdev)
 
phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
-   dev_err(dev, "%s: failed to allocate phy\n", __func__);
err = -ENOMEM;
goto out;
}
-- 
1.7.9.5

[PATCH 08/10] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

[Kishon Vijay Abraham I]

From: Hans de Goede 

The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.

Signed-off-by: Hans de Goede 
Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-sun4i-usb.c |   34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index de3101f..0a45bc6 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -94,6 +94,7 @@
 
 enum sun4i_usb_phy_type {
sun4i_a10_phy,
+   sun6i_a31_phy,
sun8i_a33_phy,
sun8i_h3_phy,
 };
@@ -122,7 +123,6 @@ struct sun4i_usb_phy_data {
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
-   bool phy0_poll;
struct gpio_desc *id_det_gpio;
struct gpio_desc *vbus_det_gpio;
struct power_supply *vbus_power_supply;
@@ -343,6 +343,24 @@ static bool sun4i_usb_phy0_have_vbus_det(struct 
sun4i_usb_phy_data *data)
return data->vbus_det_gpio || data->vbus_power_supply;
 }
 
+static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
+{
+   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
+   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
+   return true;
+
+   /*
+* The A31 companion pmic (axp221) does not generate vbus change
+* interrupts when the board is driving vbus, so we must poll
+* when using the pmic for vbus-det _and_ we're driving vbus.
+*/
+   if (data->cfg->type == sun6i_a31_phy &&
+   data->vbus_power_supply && data->phys[0].regulator_on)
+   return true;
+
+   return false;
+}
+
 static int sun4i_usb_phy_power_on(struct phy *_phy)
 {
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
@@ -364,7 +382,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
 
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
-   if (phy->index == 0 && data->vbus_det_gpio && data->phy0_poll)
+   if (phy->index == 0 && sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, DEBOUNCE_TIME);
 
return 0;
@@ -385,7 +403,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
 * phy0 vbus typically slowly discharges, sometimes this causes the
 * Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
 */
-   if (phy->index == 0 && data->vbus_det_gpio && !data->phy0_poll)
+   if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, POLL_TIME);
 
return 0;
@@ -468,7 +486,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
if (vbus_notify)
extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
 
-   if (data->phy0_poll)
+   if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
 }
 
@@ -644,11 +662,6 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
}
 
data->id_det_irq = gpiod_to_irq(data->id_det_gpio);
-   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
-   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
-   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
-   data->phy0_poll = true;
-
if (data->id_det_irq > 0) {
ret = devm_request_irq(dev, data->id_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -660,6 +673,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
}
 
+   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
if (data->vbus_det_irq > 0) {
ret = devm_request_irq(dev, data->vbus_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -711,7 +725,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.num_phys = 3,
-   .type = sun4i_a10_phy,
+   .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-- 
1.7.9.5

[PATCH 07/10] phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

[Kishon Vijay Abraham I]

From: Peter Griffin 

kzalloc will issue its own error message including a dump_stack()
so remote the site specific message.

Signed-off-by: Peter Griffin 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-qcom-ufs-qmp-14nm.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/phy/phy-qcom-ufs-qmp-14nm.c 
b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
index 56631e7..6ee5149 100644
--- a/drivers/phy/phy-qcom-ufs-qmp-14nm.c
+++ b/drivers/phy/phy-qcom-ufs-qmp-14nm.c
@@ -140,7 +140,6 @@ static int ufs_qcom_phy_qmp_14nm_probe(struct 
platform_device *pdev)
 
phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
-   dev_err(dev, "%s: failed to allocate phy\n", __func__);
err = -ENOMEM;
goto out;
}
-- 
1.7.9.5

[PATCH 08/10] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

[Kishon Vijay Abraham I]

From: Hans de Goede 

The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.

Signed-off-by: Hans de Goede 
Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-sun4i-usb.c |   34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index de3101f..0a45bc6 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -94,6 +94,7 @@
 
 enum sun4i_usb_phy_type {
sun4i_a10_phy,
+   sun6i_a31_phy,
sun8i_a33_phy,
sun8i_h3_phy,
 };
@@ -122,7 +123,6 @@ struct sun4i_usb_phy_data {
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
-   bool phy0_poll;
struct gpio_desc *id_det_gpio;
struct gpio_desc *vbus_det_gpio;
struct power_supply *vbus_power_supply;
@@ -343,6 +343,24 @@ static bool sun4i_usb_phy0_have_vbus_det(struct 
sun4i_usb_phy_data *data)
return data->vbus_det_gpio || data->vbus_power_supply;
 }
 
+static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
+{
+   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
+   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
+   return true;
+
+   /*
+* The A31 companion pmic (axp221) does not generate vbus change
+* interrupts when the board is driving vbus, so we must poll
+* when using the pmic for vbus-det _and_ we're driving vbus.
+*/
+   if (data->cfg->type == sun6i_a31_phy &&
+   data->vbus_power_supply && data->phys[0].regulator_on)
+   return true;
+
+   return false;
+}
+
 static int sun4i_usb_phy_power_on(struct phy *_phy)
 {
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
@@ -364,7 +382,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
 
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
-   if (phy->index == 0 && data->vbus_det_gpio && data->phy0_poll)
+   if (phy->index == 0 && sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, DEBOUNCE_TIME);
 
return 0;
@@ -385,7 +403,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
 * phy0 vbus typically slowly discharges, sometimes this causes the
 * Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
 */
-   if (phy->index == 0 && data->vbus_det_gpio && !data->phy0_poll)
+   if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, POLL_TIME);
 
return 0;
@@ -468,7 +486,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
if (vbus_notify)
extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
 
-   if (data->phy0_poll)
+   if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
 }
 
@@ -644,11 +662,6 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
}
 
data->id_det_irq = gpiod_to_irq(data->id_det_gpio);
-   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
-   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
-   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
-   data->phy0_poll = true;
-
if (data->id_det_irq > 0) {
ret = devm_request_irq(dev, data->id_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -660,6 +673,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
}
 
+   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
if (data->vbus_det_irq > 0) {
ret = devm_request_irq(dev, data->vbus_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -711,7 +725,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.num_phys = 3,
-   .type = sun4i_a10_phy,
+   .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-- 
1.7.9.5

[PATCH 05/10] phy: rockchip-usb: should be a child device of the GRF

[Kishon Vijay Abraham I]

From: Heiko Stuebner 

The usb-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate
platform-device but instead a sub-device of the GRF - using the
simply-mfd mechanism.

As the usb-phy is part of the kernel for some releases now, we keep
the old (and now deprecated) binding for compatibility purposes.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   27 
 drivers/phy/phy-rockchip-usb.c |   15 ---
 2 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
index 68498d5..cc6be96 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -5,11 +5,13 @@ Required properties:
  "rockchip,rk3066a-usb-phy"
  "rockchip,rk3188-usb-phy"
  "rockchip,rk3288-usb-phy"
- - rockchip,grf : phandle to the syscon managing the "general
-   register files"
  - #address-cells: should be 1
  - #size-cells: should be 0
 
+Deprecated properties:
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files" - phy should be a child of the GRF instead
+
 Sub-nodes:
 Each PHY should be represented as a sub-node.
 
@@ -28,14 +30,19 @@ Optional Properties:
 
 Example:
 
-usbphy: phy {
-   compatible = "rockchip,rk3288-usb-phy";
-   rockchip,grf = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+   usbphy: phy {
+   compatible = "rockchip,rk3288-usb-phy";
+   #address-cells = <1>;
+   #size-cells = <0>;
 
-   usbphy0: usb-phy0 {
-   #phy-cells = <0>;
-   reg = <0x320>;
+   usbphy0: usb-phy0 {
+   #phy-cells = <0>;
+   reg = <0x320>;
+   };
};
 };
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index d60b149..e66b5bf 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -397,8 +397,13 @@ static int rockchip_usb_phy_probe(struct platform_device 
*pdev)
phy_base->pdata = match->data;
 
phy_base->dev = dev;
-   phy_base->reg_base = syscon_regmap_lookup_by_phandle(dev->of_node,
-"rockchip,grf");
+   phy_base->reg_base = ERR_PTR(-ENODEV);
+   if (dev->parent && dev->parent->of_node)
+   phy_base->reg_base = syscon_node_to_regmap(
+   dev->parent->of_node);
+   if (IS_ERR(phy_base->reg_base))
+   phy_base->reg_base = syscon_regmap_lookup_by_phandle(
+   dev->of_node, "rockchip,grf");
if (IS_ERR(phy_base->reg_base)) {
dev_err(>dev, "Missing rockchip,grf property\n");
return PTR_ERR(phy_base->reg_base);
@@ -463,7 +468,11 @@ static int __init rockchip_init_usb_uart(void)
return -ENOTSUPP;
}
 
-   grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+   grf = ERR_PTR(-ENODEV);
+   if (np->parent)
+   grf = syscon_node_to_regmap(np->parent);
+   if (IS_ERR(grf))
+   grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(grf)) {
pr_err("%s: Missing rockchip,grf property, %lu\n",
   __func__, PTR_ERR(grf));
-- 
1.7.9.5

[PATCH 03/10] dt-bindings: Add bindings for phy-da8xx-usb

[Kishon Vijay Abraham I]

From: David Lechner 

Device tree binding for new phy-da8xx-usb driver.

Signed-off-by: David Lechner 
Acked-by: Rob Herring 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/phy-da8xx-usb.txt  |   40 
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
new file mode 100644
index 000..c26478b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
@@ -0,0 +1,40 @@
+TI DA8xx/OMAP-L1xx/AM18xx USB PHY
+
+Required properties:
+ - compatible: must be "ti,da830-usb-phy".
+ - #phy-cells: must be 1.
+
+This device controls the PHY for both the USB 1.1 OHCI and USB 2.0 OTG
+controllers on DA8xx SoCs. Consumers of this device should use index 0 for
+the USB 2.0 phy device and index 1 for the USB 1.1 phy device.
+
+It also requires a "syscon" node with compatible = "ti,da830-cfgchip", "syscon"
+to access the CFGCHIP2 register.
+
+Example:
+
+   cfgchip: cfgchip@1417c {
+   compatible = "ti,da830-cfgchip", "syscon";
+   reg = <0x1417c 0x14>;
+   };
+
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <1>;
+   };
+
+   usb20: usb@20 {
+   compatible = "ti,da830-musb";
+   reg = <0x20 0x1000>;
+   interrupts = <58>;
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+   };
+
+   usb11: usb@225000 {
+   compatible = "ti,da830-ohci";
+   reg = <0x225000 0x1000>;
+   interrupts = <59>;
+   phys = <_phy 1>;
+   phy-names = "usb-phy";
+   };
-- 
1.7.9.5

[GIT PULL] phy: for 4.8 merge window

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for 4.8 merge window below.

Now the controller can configure the mode in which the PHY should
work using the new phy_set_mode API. This was added by David Lechner
required for da8xx-usb phy (used by MUSB). For this I created a signed
tag 'phy-set-mode-v2' since the phy_set_mode API is called from musb
driver which is not part of this pull request. This also adds a new
phy driver for USB PHY in DA8xx SoC and includes other minor cleanups
and fixes.

Consider merging this for the next merge window. Let me know if I have
to change something.

The following changes since commit 04e59a0211ff012ba60c00baca673482570784e9:

  phy-sun4i-usb: Fix irq free conditions to match request conditions 
(2016-06-22 11:33:46 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.8-rc1

for you to fetch changes up to c14f8a4032efa73d9c4e155add47c19252b3bdf4:

  phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt (2016-07-04 18:07:39 
+0530)


phy: for 4.8 -rc1

*) Add a new phy_ops for setting the phy mode
*) Add a new phy driver for DA8xx SoC USB PHY
*) Minor fixes and cleanups

Signed-off-by: Kishon Vijay Abraham I 


David Lechner (3):
  phy: Add set_mode callback
  dt-bindings: Add bindings for phy-da8xx-usb
  phy: da8xx-usb: new driver for DA8xx SoC USB PHY

Hans de Goede (1):
  phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

Heiko Stuebner (1):
  phy: rockchip-usb: should be a child device of the GRF

Kishon Vijay Abraham I (2):
  phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"
  Merge tag 'phy-set-mode-v2' of git://git.kernel.org/.../kishon/linux-phy 
into next

Peter Griffin (2):
  phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message
  phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

Sudip Mukherjee (1):
  phy: rockhip-usb: use devm_add_action_or_reset()

Yoshihiro Shimoda (1):
  phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

 .../devicetree/bindings/phy/phy-da8xx-usb.txt  |   40 
 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   27 ++-
 drivers/phy/Kconfig|   10 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-core.c |   15 ++
 drivers/phy/phy-da8xx-usb.c|  245 
 drivers/phy/phy-qcom-ufs-qmp-14nm.c|1 -
 drivers/phy/phy-qcom-ufs-qmp-20nm.c|1 -
 drivers/phy/phy-rcar-gen3-usb2.c   |   26 ++-
 drivers/phy/phy-rockchip-usb.c |   23 +-
 drivers/phy/phy-sun4i-usb.c|   34 ++-
 drivers/phy/phy-xgene.c|4 +-
 include/linux/phy/phy.h|   17 ++
 13 files changed, 408 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
 create mode 100644 drivers/phy/phy-da8xx-usb.c

[PATCH 03/10] dt-bindings: Add bindings for phy-da8xx-usb

[Kishon Vijay Abraham I]

From: David Lechner 

Device tree binding for new phy-da8xx-usb driver.

Signed-off-by: David Lechner 
Acked-by: Rob Herring 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/phy-da8xx-usb.txt  |   40 
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
new file mode 100644
index 000..c26478b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
@@ -0,0 +1,40 @@
+TI DA8xx/OMAP-L1xx/AM18xx USB PHY
+
+Required properties:
+ - compatible: must be "ti,da830-usb-phy".
+ - #phy-cells: must be 1.
+
+This device controls the PHY for both the USB 1.1 OHCI and USB 2.0 OTG
+controllers on DA8xx SoCs. Consumers of this device should use index 0 for
+the USB 2.0 phy device and index 1 for the USB 1.1 phy device.
+
+It also requires a "syscon" node with compatible = "ti,da830-cfgchip", "syscon"
+to access the CFGCHIP2 register.
+
+Example:
+
+   cfgchip: cfgchip@1417c {
+   compatible = "ti,da830-cfgchip", "syscon";
+   reg = <0x1417c 0x14>;
+   };
+
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <1>;
+   };
+
+   usb20: usb@20 {
+   compatible = "ti,da830-musb";
+   reg = <0x20 0x1000>;
+   interrupts = <58>;
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+   };
+
+   usb11: usb@225000 {
+   compatible = "ti,da830-ohci";
+   reg = <0x225000 0x1000>;
+   interrupts = <59>;
+   phys = <_phy 1>;
+   phy-names = "usb-phy";
+   };
-- 
1.7.9.5

[GIT PULL] phy: for 4.8 merge window

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for 4.8 merge window below.

Now the controller can configure the mode in which the PHY should
work using the new phy_set_mode API. This was added by David Lechner
required for da8xx-usb phy (used by MUSB). For this I created a signed
tag 'phy-set-mode-v2' since the phy_set_mode API is called from musb
driver which is not part of this pull request. This also adds a new
phy driver for USB PHY in DA8xx SoC and includes other minor cleanups
and fixes.

Consider merging this for the next merge window. Let me know if I have
to change something.

The following changes since commit 04e59a0211ff012ba60c00baca673482570784e9:

  phy-sun4i-usb: Fix irq free conditions to match request conditions 
(2016-06-22 11:33:46 +0530)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.8-rc1

for you to fetch changes up to c14f8a4032efa73d9c4e155add47c19252b3bdf4:

  phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt (2016-07-04 18:07:39 
+0530)


phy: for 4.8 -rc1

*) Add a new phy_ops for setting the phy mode
*) Add a new phy driver for DA8xx SoC USB PHY
*) Minor fixes and cleanups

Signed-off-by: Kishon Vijay Abraham I 


David Lechner (3):
  phy: Add set_mode callback
  dt-bindings: Add bindings for phy-da8xx-usb
  phy: da8xx-usb: new driver for DA8xx SoC USB PHY

Hans de Goede (1):
  phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

Heiko Stuebner (1):
  phy: rockchip-usb: should be a child device of the GRF

Kishon Vijay Abraham I (2):
  phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"
  Merge tag 'phy-set-mode-v2' of git://git.kernel.org/.../kishon/linux-phy 
into next

Peter Griffin (2):
  phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message
  phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

Sudip Mukherjee (1):
  phy: rockhip-usb: use devm_add_action_or_reset()

Yoshihiro Shimoda (1):
  phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

 .../devicetree/bindings/phy/phy-da8xx-usb.txt  |   40 
 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   27 ++-
 drivers/phy/Kconfig|   10 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-core.c |   15 ++
 drivers/phy/phy-da8xx-usb.c|  245 
 drivers/phy/phy-qcom-ufs-qmp-14nm.c|1 -
 drivers/phy/phy-qcom-ufs-qmp-20nm.c|1 -
 drivers/phy/phy-rcar-gen3-usb2.c   |   26 ++-
 drivers/phy/phy-rockchip-usb.c |   23 +-
 drivers/phy/phy-sun4i-usb.c|   34 ++-
 drivers/phy/phy-xgene.c|4 +-
 include/linux/phy/phy.h|   17 ++
 13 files changed, 408 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
 create mode 100644 drivers/phy/phy-da8xx-usb.c

[PATCH 01/10] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

[Kishon Vijay Abraham I]

No functional change. Rename "enum phy_mode" to
"enum xgene_phy_mode" in xgene phy driver in
preparation for adding set_mode callback in
phy core.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Loc Ho 
---
 drivers/phy/phy-xgene.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-xgene.c b/drivers/phy/phy-xgene.c
index 385362e..ae266e0 100644
--- a/drivers/phy/phy-xgene.c
+++ b/drivers/phy/phy-xgene.c
@@ -518,7 +518,7 @@ enum clk_type_t {
CLK_INT_SING = 2,   /* Internal single ended */
 };
 
-enum phy_mode {
+enum xgene_phy_mode {
MODE_SATA   = 0,/* List them for simple reference */
MODE_SGMII  = 1,
MODE_PCIE   = 2,
@@ -542,7 +542,7 @@ struct xgene_sata_override_param {
 struct xgene_phy_ctx {
struct device *dev;
struct phy *phy;
-   enum phy_mode mode; /* Mode of operation */
+   enum xgene_phy_mode mode;   /* Mode of operation */
enum clk_type_t clk_type;   /* Input clock selection */
void __iomem *sds_base; /* PHY CSR base addr */
struct clk *clk;/* Optional clock */
-- 
1.7.9.5

[PATCH 02/10] phy: Add set_mode callback

[Kishon Vijay Abraham I]

From: David Lechner 

The initial use for this is for PHYs that have a mode related to USB OTG.
There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
in the USB PHY to override OTG VBUS and ID signals.

Of course, the enum can be expaned in the future to include modes for
other types of PHYs as well.

Suggested-by: Kishon Vijay Abraham I 
Signed-off-by: David Lechner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-core.c  |   15 +++
 include/linux/phy/phy.h |   17 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b72e9a3..8eca906 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
 
+int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   int ret;
+
+   if (!phy || !phy->ops->set_mode)
+   return 0;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->set_mode(phy, mode);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_mode);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index a810f2a..f08b672 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -22,12 +22,20 @@
 
 struct phy;
 
+enum phy_mode {
+   PHY_MODE_INVALID,
+   PHY_MODE_USB_HOST,
+   PHY_MODE_USB_DEVICE,
+   PHY_MODE_USB_OTG,
+};
+
 /**
  * struct phy_ops - set of function pointers for performing phy operations
  * @init: operation to be performed for initializing phy
  * @exit: operation to be performed while exiting
  * @power_on: powering on the phy
  * @power_off: powering off the phy
+ * @set_mode: set the mode of the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -35,6 +43,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+   int (*set_mode)(struct phy *phy, enum phy_mode mode);
struct module *owner;
 };
 
@@ -126,6 +135,7 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+int phy_set_mode(struct phy *phy, enum phy_mode mode);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -233,6 +243,13 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
1.7.9.5

[PATCH 01/10] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

[Kishon Vijay Abraham I]

No functional change. Rename "enum phy_mode" to
"enum xgene_phy_mode" in xgene phy driver in
preparation for adding set_mode callback in
phy core.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Loc Ho 
---
 drivers/phy/phy-xgene.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-xgene.c b/drivers/phy/phy-xgene.c
index 385362e..ae266e0 100644
--- a/drivers/phy/phy-xgene.c
+++ b/drivers/phy/phy-xgene.c
@@ -518,7 +518,7 @@ enum clk_type_t {
CLK_INT_SING = 2,   /* Internal single ended */
 };
 
-enum phy_mode {
+enum xgene_phy_mode {
MODE_SATA   = 0,/* List them for simple reference */
MODE_SGMII  = 1,
MODE_PCIE   = 2,
@@ -542,7 +542,7 @@ struct xgene_sata_override_param {
 struct xgene_phy_ctx {
struct device *dev;
struct phy *phy;
-   enum phy_mode mode; /* Mode of operation */
+   enum xgene_phy_mode mode;   /* Mode of operation */
enum clk_type_t clk_type;   /* Input clock selection */
void __iomem *sds_base; /* PHY CSR base addr */
struct clk *clk;/* Optional clock */
-- 
1.7.9.5

[PATCH 02/10] phy: Add set_mode callback

[Kishon Vijay Abraham I]

From: David Lechner 

The initial use for this is for PHYs that have a mode related to USB OTG.
There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
in the USB PHY to override OTG VBUS and ID signals.

Of course, the enum can be expaned in the future to include modes for
other types of PHYs as well.

Suggested-by: Kishon Vijay Abraham I 
Signed-off-by: David Lechner 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-core.c  |   15 +++
 include/linux/phy/phy.h |   17 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b72e9a3..8eca906 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
 
+int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   int ret;
+
+   if (!phy || !phy->ops->set_mode)
+   return 0;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->set_mode(phy, mode);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_mode);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index a810f2a..f08b672 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -22,12 +22,20 @@
 
 struct phy;
 
+enum phy_mode {
+   PHY_MODE_INVALID,
+   PHY_MODE_USB_HOST,
+   PHY_MODE_USB_DEVICE,
+   PHY_MODE_USB_OTG,
+};
+
 /**
  * struct phy_ops - set of function pointers for performing phy operations
  * @init: operation to be performed for initializing phy
  * @exit: operation to be performed while exiting
  * @power_on: powering on the phy
  * @power_off: powering off the phy
+ * @set_mode: set the mode of the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -35,6 +43,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+   int (*set_mode)(struct phy *phy, enum phy_mode mode);
struct module *owner;
 };
 
@@ -126,6 +135,7 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+int phy_set_mode(struct phy *phy, enum phy_mode mode);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -233,6 +243,13 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
1.7.9.5

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/05/2016 09:35 AM, Neo Jia wrote:
> >On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 11:33 PM, Neo Jia wrote:
> >>
> >
> >Sorry, I think I misread the "allocation" as "mapping". We only delay the
> >cpu mapping, not the allocation.
> 
> So how to understand your statement:
> "at that moment nobody has any knowledge about how the physical mmio gets 
> virtualized"
> 
> The resource, physical MMIO region, has been allocated, why we do not 
> know the physical
> address mapped to the VM?
> 
> >>>
> From a device driver point of view, the physical mmio region never gets 
> allocated until
> >>>the corresponding resource is requested by clients and granted by the 
> >>>mediated device driver.
> >>
> >>Hmm... but you told me that you did not delay the allocation. :(
> >
> >Hi Guangrong,
> >
> >The allocation here is the allocation of device resource, and the only way to
> >access that kind of device resource is via a mmio region of some pages there.
> >
> >For example, if VM needs resource A, and the only way to access resource A is
> >via some kind of device memory at mmio address X.
> >
> >So, we never defer the allocation request during runtime, we just setup the
> >CPU mapping later when it actually gets accessed.
> >
> >>
> >>So it returns to my original question: why not allocate the physical mmio 
> >>region in mmap()?
> >>
> >
> >Without running anything inside the VM, how do you know how the hw resource 
> >gets
> >allocated, therefore no knowledge of the use of mmio region.
> 
> The allocation and mapping can be two independent processes:
> - the first process is just allocation. The MMIO region is allocated from 
> physical
>   hardware and this region is mapped into _QEMU's_ arbitrary virtual address 
> by mmap().
>   At this time, VM can not actually use this resource.
> 
> - the second process is mapping. When VM enable this region, e.g, it enables 
> the
>   PCI BAR, then QEMU maps its virtual address returned by mmap() to VM's 
> physical
>   memory. After that, VM can access this region.
> 
> The second process is completed handled in userspace, that means, the mediated
> device driver needn't care how the resource is mapped into VM.

In your example, you are still picturing it as VFIO direct assign, but the 
solution we are 
talking here is mediated passthru via VFIO framework to virtualize DMA devices 
without SR-IOV.

(Just for completeness, if you really want to use a device in above example as
VFIO passthru, the second step is not completely handled in userspace, it is 
actually the guest
driver who will allocate and setup the proper hw resource which will later ready
for you to access via some mmio pages.)

> 
> This is how QEMU/VFIO currently works, could you please tell me the special 
> points
> of your solution comparing with current QEMU/VFIO and why current model can 
> not fit
> your requirement? So that we can better understand your scenario?

The scenario I am describing here is mediated passthru case, but what you are
describing here (more or less) is VFIO direct assigned case. It is different in 
several
areas, but major difference related to this topic here is:

1) In VFIO direct assigned case, the device (and its resource) is completely 
owned by the VM
therefore its mmio region can be mapped directly into the VM during the VFIO 
mmap() call as
there is no resource sharing among VMs and there is no mediated device driver on
the host to manage such resource, so it is completely owned by the guest.

2) In mediated passthru case, multiple VMs are sharing the same physical 
device, so how
the HW resource gets allocated is completely decided by the guest and host 
device driver of 
the virtualized DMA device, here is the GPU, same as the MMIO pages used to 
access those Hw resource.

Thanks,
Neo

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

[Neo Jia]

On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
> 
> 
> On 07/05/2016 09:35 AM, Neo Jia wrote:
> >On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 11:33 PM, Neo Jia wrote:
> >>
> >
> >Sorry, I think I misread the "allocation" as "mapping". We only delay the
> >cpu mapping, not the allocation.
> 
> So how to understand your statement:
> "at that moment nobody has any knowledge about how the physical mmio gets 
> virtualized"
> 
> The resource, physical MMIO region, has been allocated, why we do not 
> know the physical
> address mapped to the VM?
> 
> >>>
> From a device driver point of view, the physical mmio region never gets 
> allocated until
> >>>the corresponding resource is requested by clients and granted by the 
> >>>mediated device driver.
> >>
> >>Hmm... but you told me that you did not delay the allocation. :(
> >
> >Hi Guangrong,
> >
> >The allocation here is the allocation of device resource, and the only way to
> >access that kind of device resource is via a mmio region of some pages there.
> >
> >For example, if VM needs resource A, and the only way to access resource A is
> >via some kind of device memory at mmio address X.
> >
> >So, we never defer the allocation request during runtime, we just setup the
> >CPU mapping later when it actually gets accessed.
> >
> >>
> >>So it returns to my original question: why not allocate the physical mmio 
> >>region in mmap()?
> >>
> >
> >Without running anything inside the VM, how do you know how the hw resource 
> >gets
> >allocated, therefore no knowledge of the use of mmio region.
> 
> The allocation and mapping can be two independent processes:
> - the first process is just allocation. The MMIO region is allocated from 
> physical
>   hardware and this region is mapped into _QEMU's_ arbitrary virtual address 
> by mmap().
>   At this time, VM can not actually use this resource.
> 
> - the second process is mapping. When VM enable this region, e.g, it enables 
> the
>   PCI BAR, then QEMU maps its virtual address returned by mmap() to VM's 
> physical
>   memory. After that, VM can access this region.
> 
> The second process is completed handled in userspace, that means, the mediated
> device driver needn't care how the resource is mapped into VM.

In your example, you are still picturing it as VFIO direct assign, but the 
solution we are 
talking here is mediated passthru via VFIO framework to virtualize DMA devices 
without SR-IOV.

(Just for completeness, if you really want to use a device in above example as
VFIO passthru, the second step is not completely handled in userspace, it is 
actually the guest
driver who will allocate and setup the proper hw resource which will later ready
for you to access via some mmio pages.)

> 
> This is how QEMU/VFIO currently works, could you please tell me the special 
> points
> of your solution comparing with current QEMU/VFIO and why current model can 
> not fit
> your requirement? So that we can better understand your scenario?

The scenario I am describing here is mediated passthru case, but what you are
describing here (more or less) is VFIO direct assigned case. It is different in 
several
areas, but major difference related to this topic here is:

1) In VFIO direct assigned case, the device (and its resource) is completely 
owned by the VM
therefore its mmio region can be mapped directly into the VM during the VFIO 
mmap() call as
there is no resource sharing among VMs and there is no mediated device driver on
the host to manage such resource, so it is completely owned by the guest.

2) In mediated passthru case, multiple VMs are sharing the same physical 
device, so how
the HW resource gets allocated is completely decided by the guest and host 
device driver of 
the virtualized DMA device, here is the GPU, same as the MMIO pages used to 
access those Hw resource.

Thanks,
Neo

Re: [GIT PULL] ARM: at91: drivers for 4.8 #2

[Olof Johansson]

On Tue, Jun 21, 2016 at 07:03:06PM +0200, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> Here are two simple fixes for our memory drivers.
> 
> The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac:
> 
>   memory: atmel-ebi: add DT bindings documentation (2016-06-02 08:32:25 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-drivers2
> 
> for you to fetch changes up to 8a86a093ca3b924e6c2d5267cffb809965582a8d:
> 
>   memory: atmel-ebi: make it explicitly non-modular (2016-06-21 17:17:45 
> +0200)

Merged, thanks.


-Olof

Re: [GIT PULL] ARM: at91: dt for 4.8 #2 bis

[Olof Johansson]

On Mon, Jul 04, 2016 at 04:16:54PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> Please disregard the previous DT pull request, it had an issue...
> I'm including the corrected change in this one with two fixes for the
> sam9_l9260 and on fix for the sama5d2 xplained.
> Also, adding the PMU node to the sama5d2 doesn't seem too risky.
> 
> The following changes since commit 64c0703e269d442f0406b34e64e23744151ea276:
> 
>   ARM: dts: at91: calao: remove leftovers clock definition (2016-06-10 
> 16:59:30 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-dt2
> 
> for you to fetch changes up to b8bca7eaef9eeda4876b8ded1f49862b0b85181c:
> 
>   ARM: dts: at91: sama5d2_xplained: Update the pmic node (2016-07-04 15:59:46 
> +0200)

Merged, thanks.

-Olof

Re: [GIT PULL] ARM: at91: drivers for 4.8 #2

[Olof Johansson]

On Tue, Jun 21, 2016 at 07:03:06PM +0200, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> Here are two simple fixes for our memory drivers.
> 
> The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac:
> 
>   memory: atmel-ebi: add DT bindings documentation (2016-06-02 08:32:25 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-drivers2
> 
> for you to fetch changes up to 8a86a093ca3b924e6c2d5267cffb809965582a8d:
> 
>   memory: atmel-ebi: make it explicitly non-modular (2016-06-21 17:17:45 
> +0200)

Merged, thanks.


-Olof

Re: [GIT PULL] ARM: at91: dt for 4.8 #2 bis

[Olof Johansson]

On Mon, Jul 04, 2016 at 04:16:54PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> Please disregard the previous DT pull request, it had an issue...
> I'm including the corrected change in this one with two fixes for the
> sam9_l9260 and on fix for the sama5d2 xplained.
> Also, adding the PMU node to the sama5d2 doesn't seem too risky.
> 
> The following changes since commit 64c0703e269d442f0406b34e64e23744151ea276:
> 
>   ARM: dts: at91: calao: remove leftovers clock definition (2016-06-10 
> 16:59:30 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-dt2
> 
> for you to fetch changes up to b8bca7eaef9eeda4876b8ded1f49862b0b85181c:
> 
>   ARM: dts: at91: sama5d2_xplained: Update the pmic node (2016-07-04 15:59:46 
> +0200)

Merged, thanks.

-Olof

Re: [GIT PULL] ARM: at91: soc for 4.8 #2

[Olof Johansson]

On Tue, Jun 21, 2016 at 07:04:54PM +0200, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> Here are more compilation warning fixes and the final documentation for the
> sama5d2 that we forgot about.
> 
> The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70:
> 
>   ARM: at91: debug: add default DEBUG_LL addresses (2016-06-10 17:09:28 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-soc2
> 
> for you to fetch changes up to ab6778eee51b72f2dae79763bf918e3d43331c12:
> 
>   ARM: at91: fix warnings in pm.c (2016-06-21 17:32:31 +0200)
> 
> 
> SoC changes for 4.8 #2:
>  - Add final documentation for sama5d2
>  - Fix some compilation warnings

Merged, thanks.


-Olof

Re: [GIT PULL] ARM: at91: soc for 4.8 #2

[Olof Johansson]

On Tue, Jun 21, 2016 at 07:04:54PM +0200, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> Here are more compilation warning fixes and the final documentation for the
> sama5d2 that we forgot about.
> 
> The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70:
> 
>   ARM: at91: debug: add default DEBUG_LL addresses (2016-06-10 17:09:28 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-4.8-soc2
> 
> for you to fetch changes up to ab6778eee51b72f2dae79763bf918e3d43331c12:
> 
>   ARM: at91: fix warnings in pm.c (2016-06-21 17:32:31 +0200)
> 
> 
> SoC changes for 4.8 #2:
>  - Add final documentation for sama5d2
>  - Fix some compilation warnings

Merged, thanks.


-Olof

[PATCH] ACPI: CPPC: Return error if _CPC is invalid on a CPU

[Hoan Tran]

Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform
supports CPPC, the _CPC object must exist under all processor objects.
If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map()
should return error and CPPC cpufreq driver can not be registered.

Signed-off-by: Hoan Tran 
---
 drivers/acpi/cppc_acpi.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 85fd8f7..2e98173 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -299,8 +299,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
cpc_ptr = per_cpu(cpc_desc_ptr, i);
-   if (!cpc_ptr)
-   continue;
+   if (!cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
pdomain = &(cpc_ptr->domain_info);
cpumask_set_cpu(i, pr->shared_cpu_map);
@@ -322,8 +324,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
-   if (!match_cpc_ptr)
-   continue;
+   if (!match_cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
match_pdomain = &(match_cpc_ptr->domain_info);
if (match_pdomain->domain != pdomain->domain)
@@ -353,8 +357,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
-   if (!match_cpc_ptr)
-   continue;
+   if (!match_cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
match_pdomain = &(match_cpc_ptr->domain_info);
if (match_pdomain->domain != pdomain->domain)
-- 
1.9.1

[PATCH] ACPI: CPPC: Return error if _CPC is invalid on a CPU

[Hoan Tran]

Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform
supports CPPC, the _CPC object must exist under all processor objects.
If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map()
should return error and CPPC cpufreq driver can not be registered.

Signed-off-by: Hoan Tran 
---
 drivers/acpi/cppc_acpi.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 85fd8f7..2e98173 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -299,8 +299,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
cpc_ptr = per_cpu(cpc_desc_ptr, i);
-   if (!cpc_ptr)
-   continue;
+   if (!cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
pdomain = &(cpc_ptr->domain_info);
cpumask_set_cpu(i, pr->shared_cpu_map);
@@ -322,8 +324,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
-   if (!match_cpc_ptr)
-   continue;
+   if (!match_cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
match_pdomain = &(match_cpc_ptr->domain_info);
if (match_pdomain->domain != pdomain->domain)
@@ -353,8 +357,10 @@ int acpi_get_psd_map(struct cpudata **all_cpu_data)
continue;
 
match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
-   if (!match_cpc_ptr)
-   continue;
+   if (!match_cpc_ptr) {
+   retval = -EFAULT;
+   goto err_ret;
+   }
 
match_pdomain = &(match_cpc_ptr->domain_info);
if (match_pdomain->domain != pdomain->domain)
-- 
1.9.1

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Mon, Jun 20, 2016 at 12:12 PM, Duc Dang  wrote:
> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
>  wrote:
>> Hi Duc,
>>
>> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
 On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
  wrote:
> On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
>> From: Tomasz Nowicki 
>>
>> pci_generic_ecam_ops is used by default. Since there are platforms
>> which have non-compliant ECAM space we need to overwrite these
>> accessors prior to PCI buses enumeration. In order to do that
>> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
>> we can use proper PCI config space accessors and bus_shift.
>>
>> pci_generic_ecam_ops is still used for platforms free from quirks.
>>
>> Signed-off-by: Tomasz Nowicki 
>> ---
>>  arch/arm64/kernel/pci.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 94cd43c..a891bda 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> *root)
>>   struct pci_config_window *cfg;
>>   struct resource cfgres;
>>   unsigned int bsz;
>> + struct pci_ecam_ops *ops;
>>
>>   /* Use address from _CBA if present, otherwise lookup MCFG */
>>   if (!root->mcfg_addr)
>> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> *root)
>>   return NULL;
>>   }
>>
>> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
>> + ops = pci_mcfg_get_ops(root);
>> + bsz = 1 << ops->bus_shift;
>>   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>>   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>>   cfgres.flags = IORESOURCE_MEM;
>> - cfg = pci_ecam_create(>device->dev, , bus_res,
>> -   _generic_ecam_ops);
>> + cfg = pci_ecam_create(>device->dev, , bus_res, ops);
>
> Arnd pointed this out already, I think that's the only pending question
> here.
>
> pci_ecam_create() maps ECAM space for config regions retrieved from
> the MCFG, which are *supposed* to be ECAM compliant.
>
> Do we think that's *always* correct/safe regardless of the kind
> of quirk we are currently fixing up ?
>
> Or we do think that configuration space regions should come from
> a different resource declared in the ACPI namespace if the regions
> are not MCFG/ECAM compliant (ie config space is not defined through
> MCFG at all - possibly through a _CRS method for a vendor specific
> _HID under the PNP0A03 node ?)

 Hi Lorenzo,

 For X-Gene: the ECAM space is used to access the configuration space
 of PCIe devices, with additional help from controller register to
 specify the bus, device and function number. Below is the RFC patch
 that implements ECAM fixup for X-Gene PCIe controller on top of this
 RFC ECAM quirk v3 for your and others reference.
>>>
>>> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>>> your register that is a deliberate abuse of the ACPI standard in
>>> that the _CRS is meant to describe resources that are passed on
>>> to secondary buses
>>
>> A potential alternative came up in an off-list discussion: Would it be
>> better to hard code the information in the quirk workaround than look it
>> up from a repurposed ACPI resource?
>
> Hi Chris, Lorenzo,
>
> Thanks for looking into this.
>
> Yes, I am open for this approach and I think it may work. I can
> + check the pci_config_window resource start address (cfg->res.start)
> to figure out the controller and then get the fixed controller
> register address
> or
> + using the domain number to identify the controller.

Hi Chris, Lorenzo,

I reworked the patch to use fix-ed controller address. Please let me know
if you have further comment/concern.

---
[PATCH 1/1] pci: xgene: ECAM fix-up code for X-Gene PCIe

X-Gene PCIe controller does not fully support ECAM.
This patch adds required ECAM fixup to allow X-Gene
PCIe controller to be functional in ACPI boot mode.

Signed-off-by: Duc Dang 
---
v2 changes:
 - Using ECAM base address to identify fixed controller address

 drivers/pci/host/Makefile |   2 +-
 drivers/pci/host/pci-xgene-ecam.c | 291 ++
 2 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/host/pci-xgene-ecam.c

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9c8698e..3480696 100644
--- a/drivers/pci/host/Makefile
+++ 

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Mon, Jun 20, 2016 at 12:12 PM, Duc Dang  wrote:
> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
>  wrote:
>> Hi Duc,
>>
>> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
 On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
  wrote:
> On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
>> From: Tomasz Nowicki 
>>
>> pci_generic_ecam_ops is used by default. Since there are platforms
>> which have non-compliant ECAM space we need to overwrite these
>> accessors prior to PCI buses enumeration. In order to do that
>> we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
>> we can use proper PCI config space accessors and bus_shift.
>>
>> pci_generic_ecam_ops is still used for platforms free from quirks.
>>
>> Signed-off-by: Tomasz Nowicki 
>> ---
>>  arch/arm64/kernel/pci.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 94cd43c..a891bda 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> *root)
>>   struct pci_config_window *cfg;
>>   struct resource cfgres;
>>   unsigned int bsz;
>> + struct pci_ecam_ops *ops;
>>
>>   /* Use address from _CBA if present, otherwise lookup MCFG */
>>   if (!root->mcfg_addr)
>> @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> *root)
>>   return NULL;
>>   }
>>
>> - bsz = 1 << pci_generic_ecam_ops.bus_shift;
>> + ops = pci_mcfg_get_ops(root);
>> + bsz = 1 << ops->bus_shift;
>>   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>>   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>>   cfgres.flags = IORESOURCE_MEM;
>> - cfg = pci_ecam_create(>device->dev, , bus_res,
>> -   _generic_ecam_ops);
>> + cfg = pci_ecam_create(>device->dev, , bus_res, ops);
>
> Arnd pointed this out already, I think that's the only pending question
> here.
>
> pci_ecam_create() maps ECAM space for config regions retrieved from
> the MCFG, which are *supposed* to be ECAM compliant.
>
> Do we think that's *always* correct/safe regardless of the kind
> of quirk we are currently fixing up ?
>
> Or we do think that configuration space regions should come from
> a different resource declared in the ACPI namespace if the regions
> are not MCFG/ECAM compliant (ie config space is not defined through
> MCFG at all - possibly through a _CRS method for a vendor specific
> _HID under the PNP0A03 node ?)

 Hi Lorenzo,

 For X-Gene: the ECAM space is used to access the configuration space
 of PCIe devices, with additional help from controller register to
 specify the bus, device and function number. Below is the RFC patch
 that implements ECAM fixup for X-Gene PCIe controller on top of this
 RFC ECAM quirk v3 for your and others reference.
>>>
>>> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>>> your register that is a deliberate abuse of the ACPI standard in
>>> that the _CRS is meant to describe resources that are passed on
>>> to secondary buses
>>
>> A potential alternative came up in an off-list discussion: Would it be
>> better to hard code the information in the quirk workaround than look it
>> up from a repurposed ACPI resource?
>
> Hi Chris, Lorenzo,
>
> Thanks for looking into this.
>
> Yes, I am open for this approach and I think it may work. I can
> + check the pci_config_window resource start address (cfg->res.start)
> to figure out the controller and then get the fixed controller
> register address
> or
> + using the domain number to identify the controller.

Hi Chris, Lorenzo,

I reworked the patch to use fix-ed controller address. Please let me know
if you have further comment/concern.

---
[PATCH 1/1] pci: xgene: ECAM fix-up code for X-Gene PCIe

X-Gene PCIe controller does not fully support ECAM.
This patch adds required ECAM fixup to allow X-Gene
PCIe controller to be functional in ACPI boot mode.

Signed-off-by: Duc Dang 
---
v2 changes:
 - Using ECAM base address to identify fixed controller address

 drivers/pci/host/Makefile |   2 +-
 drivers/pci/host/pci-xgene-ecam.c | 291 ++
 2 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/host/pci-xgene-ecam.c

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9c8698e..3480696 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 

Re: [PATCH] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

Hi Prashanth,

On Wed, Jun 15, 2016 at 8:55 AM, Prakash, Prashanth
 wrote:
> Hi Hoan,
>
> On 6/14/2016 5:12 PM, Hoan Tran wrote:
>> As PCC will be used by other clients not only CPPC.
>> This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
>> declarations
>>
>> Signed-off-by: Hoan Tran 
>> ---
>>  include/acpi/cppc_acpi.h   | 4 
>>  include/linux/mailbox_client.h | 4 
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
>> index dad8af3..819b4b9 100644
>> --- a/include/acpi/cppc_acpi.h
>> +++ b/include/acpi/cppc_acpi.h
>> @@ -130,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
>> *perf_ctrls);
>>  extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
>>  extern int acpi_get_psd_map(struct cpudata **);
>>
>> -/* Methods to interact with the PCC mailbox controller. */
>> -extern struct mbox_chan *
>> - pcc_mbox_request_channel(struct mbox_client *, unsigned int);
>> -
>>  #endif /* _CPPC_ACPI_H*/
>> diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
>> index 41e2af8..2758d18 100644
>> --- a/include/linux/mailbox_client.h
>> +++ b/include/linux/mailbox_client.h
>> @@ -50,4 +50,8 @@ void mbox_client_txdone(struct mbox_chan *chan, int r); /* 
>> atomic */
>>  bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */
>>  void mbox_free_channel(struct mbox_chan *chan); /* may sleep */
>>
>> +/* Methods to interact with the PCC mailbox controller. */
>> +struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *, int);
>> +void pcc_mbox_free_channel(struct mbox_chan *chan);
>> +
> Since these APIs are specific to PCC, may be we should introduce a new header 
> for pcc clients
> instead of adding to the common mailbox_client header.

Agreed, maybe I should create a "pcc.h" file inside "/include/acpi"
folder. If you have any suggestion about the location of this file,
please let me know.

Thanks
Hoan

>>  #endif /* __MAILBOX_CLIENT_H */
>
> Thanks,
> Prashanth

Re: [PATCH] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

Hi Prashanth,

On Wed, Jun 15, 2016 at 8:55 AM, Prakash, Prashanth
 wrote:
> Hi Hoan,
>
> On 6/14/2016 5:12 PM, Hoan Tran wrote:
>> As PCC will be used by other clients not only CPPC.
>> This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
>> declarations
>>
>> Signed-off-by: Hoan Tran 
>> ---
>>  include/acpi/cppc_acpi.h   | 4 
>>  include/linux/mailbox_client.h | 4 
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
>> index dad8af3..819b4b9 100644
>> --- a/include/acpi/cppc_acpi.h
>> +++ b/include/acpi/cppc_acpi.h
>> @@ -130,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
>> *perf_ctrls);
>>  extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
>>  extern int acpi_get_psd_map(struct cpudata **);
>>
>> -/* Methods to interact with the PCC mailbox controller. */
>> -extern struct mbox_chan *
>> - pcc_mbox_request_channel(struct mbox_client *, unsigned int);
>> -
>>  #endif /* _CPPC_ACPI_H*/
>> diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
>> index 41e2af8..2758d18 100644
>> --- a/include/linux/mailbox_client.h
>> +++ b/include/linux/mailbox_client.h
>> @@ -50,4 +50,8 @@ void mbox_client_txdone(struct mbox_chan *chan, int r); /* 
>> atomic */
>>  bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */
>>  void mbox_free_channel(struct mbox_chan *chan); /* may sleep */
>>
>> +/* Methods to interact with the PCC mailbox controller. */
>> +struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *, int);
>> +void pcc_mbox_free_channel(struct mbox_chan *chan);
>> +
> Since these APIs are specific to PCC, may be we should introduce a new header 
> for pcc clients
> instead of adding to the common mailbox_client header.

Agreed, maybe I should create a "pcc.h" file inside "/include/acpi"
folder. If you have any suggestion about the location of this file,
please let me know.

Thanks
Hoan

>>  #endif /* __MAILBOX_CLIENT_H */
>
> Thanks,
> Prashanth

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo  wrote:
> On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote:
>>
>> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>>>
>>> Hi Sinan
>>>
 -Original Message-
 From: Sinan Kaya [mailto:ok...@codeaurora.org]
 Sent: 13 June 2016 15:03
 To: Gabriele Paoloni; liudongdong (C); helg...@kernel.org;
 a...@arndb.de; will.dea...@arm.com; catalin.mari...@arm.com;
 raf...@kernel.org; hanjun@linaro.org; lorenzo.pieral...@arm.com;
 jchan...@broadcom.com; t...@semihalf.com
 Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
 liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing;
 suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
 p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
 a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
 a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org;
 dhd...@apm.com; jeremy.lin...@arm.com; c...@codeaurora.org; Chenxin
 (Charles); Linuxarm
 Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
 accessors against platfrom specific ECAM quirks

 On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
 > As you can see here Liudongdong has replaced oem_revision with
 > oem_table_id.
 >
 > Now it seems that there are some platforms that have already shipped
 > using a matching based on the oem_revision (right Jon?)
 >
 > However I guess that if in FW they have defined oem_table_id properly
 > they should be able to use this mechanism without needing to a FW
 update.
 >
 > Can these vendors confirm this?
 >
 > Tomasz do you think this can work for Cavium Thunder?
 >
 > Thanks
 >
 > Gab

 Why not have all three of them?

 The initial approach was OEM id and revision id.

 Jeff Hugo indicated that addition (not removing any other fields) of
 table id
 would make more sense.
>>>
>>>
>>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>>> PCI config space accessors against platfrom specific ECAM quirks."
>>>
>>> I quote:
>>>
>>>  "Using the OEM revision
>>>  field does not seem to be appropriate since these are different
>>>  platforms and the revision field appears to be for the purpose of
>>>  tracking differences within a single platform.  Therefore, Cov is
>>>  proposing using the OEM table id as a mechanism to distinguish
>>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>>  same OEM."
>>>
>>> So it looks to me that he pointed out that using the OEM revision field
>>> is wrong...and this is why I have asked if replacing it with the table
>>> id can work for other vendors
>>>
>>> Thanks
>>>
>>> Gab
>>>
>>
>> I had an internal discussion with jeff and cov before posting on the
>> maillist.
>>
>> I think there is missing info in the email.
>>
>> Usage of oem id + table id + revision is ok.
>>
>> Usage of oem id + revision is not ok as one oem can build multiple chips
>> with the same oem id and revision id but different table id. Otherwise,
>> we can run out of revisions very quickly.
>
>
> Agreed.
>
> I'm sorry for the confusion.  My intent was to point out that revision alone
> appeared insufficient to address all the identified problems, but I believe
> there is still a case for using revision. Table id is useful for
> differentiating between platforms/chips.  Revision is useful for
> differentiation between different versions of a single platform/chip
> assuming the silicon is respun or some other fix is applied.  Both solve
> different scenarios, and I'm not aware of a reason why they could not be
> used together to solve all currently identified cases.

Using OEM ID + Table ID + Revision will work for X-Gene platforms as well.

Regards,
Duc Dang.
>
>>
>>>

 --
 Sinan Kaya
 Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
 Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
 Linux Foundation Collaborative Project
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Jeffrey Hugo
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo  wrote:
> On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote:
>>
>> On 2016-06-13 10:29, Gabriele Paoloni wrote:
>>>
>>> Hi Sinan
>>>
 -Original Message-
 From: Sinan Kaya [mailto:ok...@codeaurora.org]
 Sent: 13 June 2016 15:03
 To: Gabriele Paoloni; liudongdong (C); helg...@kernel.org;
 a...@arndb.de; will.dea...@arm.com; catalin.mari...@arm.com;
 raf...@kernel.org; hanjun@linaro.org; lorenzo.pieral...@arm.com;
 jchan...@broadcom.com; t...@semihalf.com
 Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
 liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing;
 suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
 p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
 a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
 a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org;
 dhd...@apm.com; jeremy.lin...@arm.com; c...@codeaurora.org; Chenxin
 (Charles); Linuxarm
 Subject: Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space
 accessors against platfrom specific ECAM quirks

 On 6/13/2016 9:54 AM, Gabriele Paoloni wrote:
 > As you can see here Liudongdong has replaced oem_revision with
 > oem_table_id.
 >
 > Now it seems that there are some platforms that have already shipped
 > using a matching based on the oem_revision (right Jon?)
 >
 > However I guess that if in FW they have defined oem_table_id properly
 > they should be able to use this mechanism without needing to a FW
 update.
 >
 > Can these vendors confirm this?
 >
 > Tomasz do you think this can work for Cavium Thunder?
 >
 > Thanks
 >
 > Gab

 Why not have all three of them?

 The initial approach was OEM id and revision id.

 Jeff Hugo indicated that addition (not removing any other fields) of
 table id
 would make more sense.
>>>
>>>
>>> Mmm from last email of Jeff Hugo on "[RFC PATCH 1/3] pci, acpi: Match
>>> PCI config space accessors against platfrom specific ECAM quirks."
>>>
>>> I quote:
>>>
>>>  "Using the OEM revision
>>>  field does not seem to be appropriate since these are different
>>>  platforms and the revision field appears to be for the purpose of
>>>  tracking differences within a single platform.  Therefore, Cov is
>>>  proposing using the OEM table id as a mechanism to distinguish
>>>  platform A (needs quirk applied) vs platform B (no quirks) from the
>>>  same OEM."
>>>
>>> So it looks to me that he pointed out that using the OEM revision field
>>> is wrong...and this is why I have asked if replacing it with the table
>>> id can work for other vendors
>>>
>>> Thanks
>>>
>>> Gab
>>>
>>
>> I had an internal discussion with jeff and cov before posting on the
>> maillist.
>>
>> I think there is missing info in the email.
>>
>> Usage of oem id + table id + revision is ok.
>>
>> Usage of oem id + revision is not ok as one oem can build multiple chips
>> with the same oem id and revision id but different table id. Otherwise,
>> we can run out of revisions very quickly.
>
>
> Agreed.
>
> I'm sorry for the confusion.  My intent was to point out that revision alone
> appeared insufficient to address all the identified problems, but I believe
> there is still a case for using revision. Table id is useful for
> differentiating between platforms/chips.  Revision is useful for
> differentiation between different versions of a single platform/chip
> assuming the silicon is respun or some other fix is applied.  Both solve
> different scenarios, and I'm not aware of a reason why they could not be
> used together to solve all currently identified cases.

Using OEM ID + Table ID + Revision will work for X-Gene platforms as well.

Regards,
Duc Dang.
>
>>
>>>

 --
 Sinan Kaya
 Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
 Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
 Linux Foundation Collaborative Project
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Jeffrey Hugo
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

Re: [PATCH v5 3/3] gpio: lp873x: Add support for General Purpose Outputs

[Keerthy]

On Monday 04 July 2016 04:52 PM, Linus Walleij wrote:

On Wed, Jun 29, 2016 at 5:44 PM, Keerthy  wrote:


Add driver for lp873x PMIC family GPOs. Two GPOs are supported
and can be configured in Open-drain output or Push-pull output.

Signed-off-by: Keerthy 


Looks all right to me.


+#include 


I guess this means Lee must merge this.

Acked-by: Linus Walleij 


Thanks Linus!



Yours,
Linus Walleij

Re: [PATCH v5 3/3] gpio: lp873x: Add support for General Purpose Outputs

[Keerthy]

On Monday 04 July 2016 04:52 PM, Linus Walleij wrote:

On Wed, Jun 29, 2016 at 5:44 PM, Keerthy  wrote:


Add driver for lp873x PMIC family GPOs. Two GPOs are supported
and can be configured in Open-drain output or Push-pull output.

Signed-off-by: Keerthy 


Looks all right to me.


+#include 


I guess this means Lee must merge this.

Acked-by: Linus Walleij 


Thanks Linus!



Yours,
Linus Walleij

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Prashanth,

On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth
 wrote:
>
>
> On 6/9/2016 2:47 PM, Hoan Tran wrote:
>> Hi Ashwin and Prashanth,
>>
>> On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
>>> Hi Prashanth,
>>>
>>>
>>> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>>>  wrote:

 On 6/8/2016 10:24 AM, Hoan Tran wrote:
> Hi Ashwin,
>
> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>  wrote:
>> + Prashanth (Can you please have a look as well?)
>>
>> On 31 May 2016 at 15:35, Hoan Tran  wrote:
>>> Hi Ashwin,
>> Hi,
>>
>> Sorry about the delay. I'm in the middle of switching jobs and
>> locations, so its been a bit crazy lately.
> It's ok and hope you're doing well.
>
>> I dont have any major
>> concerns with this code, although there could be subtle issues with
>> this IRQ thing. In this patchset, your intent is to add support for
>> PCC subspace type 2. But you're also adding support for tx command
>> completion which is not specific to Type 2. We could support that even
>> in Type 1. Hence I wanted to separate the two, not just for review,
>> but also the async IRQ completion has subtle issues esp. in the case
>> of async platform notification, where you could have a PCC client in
>> the OS writing to the cmd bit and the platform sending an async
>> notification by writing to some bits in the same 8byte address as the
>> cmd bit. So we need some mutual exclusivity there, otherwise the OS
>> and platform could step on each other. Perhaps Prashanth has better
>> insight into this.
> I think, this mutual exclusivity could be in another patch.
 Ashwin,
 Sorry, I am not sure how we can prevent platform and OSPM from stepping on
 each other.  There is a line is spec that says "all operations on status 
 field
 must be made using interlocked operations", but not sure what these
 interlocked operation translates to.
>>> Yes, I had the same question about how to prevent it.
>> For platform notification, if the hardware doesn't support interlocked
>> operations. I think we can use a workaround that, platform triggers
>> interrupt to OSPM without touching status field. The OSPM PCC client
>> will decide what to do with this interrupt. For example, OSPM sends a
>> consumer command to check it.
> How do we decide which platform can support this interlocked operation?
> and how do we decide between a completion notification and platform
> notification?

Truly, we should follow the specification. But I don't know if there's
any hardware support this interlocked operation.
For the decide between a completion notification and platform notification
 - Completion notification: Bit "Command Complete" is set.
 - Platform notification: Bit "Command Complete" is not set.

>
> I think the ACPI spec on platform notification is quite ambiguous and it is
> best to get the necessary clarification and/or correction before implementing
> anything related to platform notification.

Agreed, a clarification inside ACPI Specification is needed

Thanks
Hoan

>
> With respect to to this patch, since we are not doing anything specific to
> platform notification and the interrupt can be used only for notification
> of  completion, I suppose we should be okay.
>
> Thanks,
> Prashanth
>> Thanks
>> Hoan
>>
 Hoan,
 Even if we are not using platform notification, we still need to clear the 
 doorbell
 interrupt bit in the PCC interrupt handler (Section14.2.2 and 14.4).  I 
 didn't see
 clearing the doorbell interrupt bit in this patch (and platform is 
 supposed to set
 it again when it is sending the interrupt again). Did I miss it? or is it 
 intentionally
 left out to avoid the race that Ashwin mentioned above?

>>> The PCC client driver is supposed to do that. Which mean, the
>>> mbox_chan_received_data() function should clear it.
>>>
>>> Thanks
>>> Hoan
>>>
 Thanks,
 Prashanth


>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Prashanth,

On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth
 wrote:
>
>
> On 6/9/2016 2:47 PM, Hoan Tran wrote:
>> Hi Ashwin and Prashanth,
>>
>> On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
>>> Hi Prashanth,
>>>
>>>
>>> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>>>  wrote:

 On 6/8/2016 10:24 AM, Hoan Tran wrote:
> Hi Ashwin,
>
> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>  wrote:
>> + Prashanth (Can you please have a look as well?)
>>
>> On 31 May 2016 at 15:35, Hoan Tran  wrote:
>>> Hi Ashwin,
>> Hi,
>>
>> Sorry about the delay. I'm in the middle of switching jobs and
>> locations, so its been a bit crazy lately.
> It's ok and hope you're doing well.
>
>> I dont have any major
>> concerns with this code, although there could be subtle issues with
>> this IRQ thing. In this patchset, your intent is to add support for
>> PCC subspace type 2. But you're also adding support for tx command
>> completion which is not specific to Type 2. We could support that even
>> in Type 1. Hence I wanted to separate the two, not just for review,
>> but also the async IRQ completion has subtle issues esp. in the case
>> of async platform notification, where you could have a PCC client in
>> the OS writing to the cmd bit and the platform sending an async
>> notification by writing to some bits in the same 8byte address as the
>> cmd bit. So we need some mutual exclusivity there, otherwise the OS
>> and platform could step on each other. Perhaps Prashanth has better
>> insight into this.
> I think, this mutual exclusivity could be in another patch.
 Ashwin,
 Sorry, I am not sure how we can prevent platform and OSPM from stepping on
 each other.  There is a line is spec that says "all operations on status 
 field
 must be made using interlocked operations", but not sure what these
 interlocked operation translates to.
>>> Yes, I had the same question about how to prevent it.
>> For platform notification, if the hardware doesn't support interlocked
>> operations. I think we can use a workaround that, platform triggers
>> interrupt to OSPM without touching status field. The OSPM PCC client
>> will decide what to do with this interrupt. For example, OSPM sends a
>> consumer command to check it.
> How do we decide which platform can support this interlocked operation?
> and how do we decide between a completion notification and platform
> notification?

Truly, we should follow the specification. But I don't know if there's
any hardware support this interlocked operation.
For the decide between a completion notification and platform notification
 - Completion notification: Bit "Command Complete" is set.
 - Platform notification: Bit "Command Complete" is not set.

>
> I think the ACPI spec on platform notification is quite ambiguous and it is
> best to get the necessary clarification and/or correction before implementing
> anything related to platform notification.

Agreed, a clarification inside ACPI Specification is needed

Thanks
Hoan

>
> With respect to to this patch, since we are not doing anything specific to
> platform notification and the interrupt can be used only for notification
> of  completion, I suppose we should be okay.
>
> Thanks,
> Prashanth
>> Thanks
>> Hoan
>>
 Hoan,
 Even if we are not using platform notification, we still need to clear the 
 doorbell
 interrupt bit in the PCC interrupt handler (Section14.2.2 and 14.4).  I 
 didn't see
 clearing the doorbell interrupt bit in this patch (and platform is 
 supposed to set
 it again when it is sending the interrupt again). Did I miss it? or is it 
 intentionally
 left out to avoid the race that Ashwin mentioned above?

>>> The PCC client driver is supposed to do that. Which mean, the
>>> mbox_chan_received_data() function should clear it.
>>>
>>> Thanks
>>> Hoan
>>>
 Thanks,
 Prashanth


>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

[Duc Dang]

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi
 wrote:
>
> On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote:
> > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code
> > > should include ACPI specific callbacks that parse and set-up the
> > > device IRQ number, equivalent to the DT boot path. Owing to the current
> > > ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings
> > > cannot be parsed at device add time, since that would trigger ACPI scan
> > > handlers ordering issues depending on how the ACPI tables are defined.
> >
> > Uh, OK :)  I can't figure out exactly what the problem is here -- I
> > don't know where to look if I wanted to fix the scan handler ordering
> > issues, and I don't know how I could tell if it would ever be safe to
> > move this from driver probe-time back to device add-time.
>
> Right, the commit log could have been more informative.
>
> pcibios_add_device() was added in:
>
> commit d1e6dc91b532 ("arm64: Add architectural support for PCI")
>
> whose commit log does not specify why legacy IRQ parsing should
> be done at pcibios_add_device() either, so honestly we had to
> do with the information we have at hand.
>
> > I also notice that x86 and ia64 call acpi_pci_irq_enable() even later,
> > when the driver *enables* the device.  Is there a reason you didn't do
> > it at the same time as x86 and ia64?  This is another of those pcibios
> > hooks that really don't do anything arch-specific, so I can imagine
> > refactoring this somehow, someday.
>
> Yes, with [1], that was the goal, that stopped because [1] does not
> work on x86.
>
> Only DT platform(s) affected by this change are all platforms relying on
> drivers/pci/host/pci-xgene.c (others rely on pci_fixup_irqs() that
> should be removed too), if on those platforms probing IRQs at device
> enable time works ok I can update this patch (it can be done through [1]
> once we figure out what to do with it on x86) and move the IRQ set-up at
> pcibios_enable_device() time.
>
> @Duc: any feedback on this ?

Hi Lorenzo,

The changes to add pcibios_alloc_irq works fine on X-Gene PCIe

I also tried to remove pcibios_alloc_irq and move its code into
pcibios_enable_device
after pci_enable_resource call and legacy IRQ also works.

Can you also point me to the discussion thread or some info. about the
issue on x86 with [1]?
I want to check if there is any more test case I need to verify.

Regards,
Duc Dang.

>
> Thanks,
> Lorenzo
>
> [1] http://www.spinics.net/lists/linux-pci/msg45950.html
>
> > Did we have this conversation before?  It seems vaguely familiar, so I
> > apologize if you already explained this once.
> >
> > > To solve this problem and consolidate FW PCI legacy IRQs parsing in
> > > one single pcibios callback (pending final removal), this patch moves
> > > DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by
> > > PCI core code at device probe time) and adds ACPI PCI legacy IRQs
> > > parsing to the same callback too, so that FW PCI legacy IRQs parsing
> > > is confined in one single arch callback that can be easily removed
> > > when code parsing PCI legacy IRQs is consolidated and moved to core
> > > PCI code.
> > >
> > > Signed-off-by: Tomasz Nowicki 
> > > Suggested-by: Lorenzo Pieralisi 
> > > ---
> > >  arch/arm64/kernel/pci.c | 11 ---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > index d5d3d26..b3b8a2c 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -51,11 +51,16 @@ int pcibios_enable_device(struct pci_dev *dev, int 
> > > mask)
> > >  }
> > >
> > >  /*
> > > - * Try to assign the IRQ number from DT when adding a new device
> > > + * Try to assign the IRQ number when probing a new device
> > >   */
> > > -int pcibios_add_device(struct pci_dev *dev)
> > > +int pcibios_alloc_irq(struct pci_dev *dev)
> > >  {
> > > -   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +   if (acpi_disabled)
> > > +   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +#ifdef CONFIG_ACPI
> > > +   else
> > > +   return acpi_pci_irq_enable(dev);
> > > +#endif
> > >
> > > return 0;
> > >  }
> > > --
> > > 1.9.1
> > >
> >

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
 wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> + int bus_num = root->secondary.start;
>> + int domain = root->segment;
>> + struct pci_cfg_fixup *f;
>> +
>> + if (!mcfg_table)
>> + return _generic_ecam_ops;
>> +
>> + /*
>> +  * Match against platform specific quirks and return corresponding
>> +  * CAM ops.
>> +  *
>> +  * First match against PCI topology  then use OEM ID and
>> +  * OEM revision from MCFG table standard header.
>> +  */
>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> + if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) 
>> &&
>> + (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) 
>> &&
>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +   ACPI_OEM_ID_SIZE)) &&
>> + (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>> +   ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used here 
> were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
> wouldn't need to be padded out to the full length.
>
>> + return f->ops;
>> + }
>> + /* No quirks, use ECAM */
>> + return _generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status 
>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>   int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> + struct pci_ecam_ops *ops;
>> + char *oem_id;
>> + char *oem_table_id;
>> + int domain;
>> + int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> + static const struct pci_cfg_fixup   \
>> + __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build error
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" 
> does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus) \
static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
 __used __attribute__((__section__(".acpi_fixup_mcfg"), \
aligned((sizeof(void *) =   \
{ ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro 
> ‘DECLARE_ACPI_MCFG_FIXUP’
>  DECLARE_ACPI_MCFG_FIXUP(_32b_ecam_ops, "QCOM", "QDF2432", 
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does 
> not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(_32b_ecam_ops, "QCOM", "QDF2432", 
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Oleg Drokin]

On Jul 4, 2016, at 10:28 PM, Oleg Drokin wrote:

> 
> On Jul 3, 2016, at 2:29 AM, Al Viro wrote:
> 
>> On Sat, Jun 25, 2016 at 12:38:40PM -0400, Oleg Drokin wrote:
>> 
>>> Sorry to nag you about this, but did any of those pan out?
>>> 
>>> d_alloc_parallel() sounds like a bit too heavy there, esp. considering we 
>>> came in with
>>> a dentry already (though a potentially shared one, I understand).
>>> Would not it be better to try and establish some dentry locking rule for 
>>> calling into
>>> d_splice_alias() instead? At least then the callers can make sure the 
>>> dentry does
>>> not change under them?
>>> Though I guess if there's dentry locking like that, we might as well do all 
>>> the
>>> checking in d_splice_alias(), but that means the unhashed dentries would no
>>> longer be disallowed which is a change of semantic from now.--
>> 
>> FWIW, the only interesting case here is this:
>>  * no O_CREAT in flags (otherwise the parent is held exclusive).
>>  * dentry is found in hash
>>  * dentry is negative
>>  * dentry has passed ->d_revalidate() (i.e. in case of
>> NFS it had nfs_neg_need_reval() return false).
>> 
>> Only two instances are non-trivial in that respect - NFS and Lustre.
>> Everything else will simply fail open() with ENOENT in that case.
>> 
>> And at least for NFS we could bloody well do d_drop + d_alloc_parallel +
>> finish_no_open and bugger off in case it's not in_lookup, otherwise do
>> pretty much what we do in case we'd got in_lookup from the very beginning.
>> Some adjustments are needed for that case (basically, we need to make
>> sure we hit d_lookup_done() matching that d_alloc_parallel() and deal
>> with refcounting correctly).
>> 
>> Tentative NFS patch follows; I don't understand Lustre well enough, but it
>> looks like a plausible strategy there as well.
> 
> This patch seems to have brought the other crash back in (or something 
> similar),
> the one with a negative dentry being hashed when it's already hashed.
> it's not as easy to hit as before, but a lot easier than the race we are 
> hitting here.
> 
> Also in all cases it is ls that is crashing now, which seems to highlight it 
> is
> taking some of this new paths added.
> I have half a dosen crashdumps if you want me to look something up there.
> This is on top of 4.7.0-rc6 a99cde438de0c4c0cecc1d1af1a55a75b10bfdef
> with just your patch on top.
> 
> I can reproduce it with both the complex workload, or with a simplified one 
> (attached),
> takes anywhere from 5 to 30 minutes to hit.
> 
>> 
>> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> index d8015a03..5474e39 100644
>> --- a/fs/nfs/dir.c
>> +++ b/fs/nfs/dir.c
>> @@ -1485,11 +1485,13 @@ int nfs_atomic_open(struct inode *dir, struct dentry 
>> *dentry,
>>  struct file *file, unsigned open_flags,
>>  umode_t mode, int *opened)
>> {
>> +DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
>>  struct nfs_open_context *ctx;
>>  struct dentry *res;
>>  struct iattr attr = { .ia_valid = ATTR_OPEN };
>>  struct inode *inode;
>>  unsigned int lookup_flags = 0;
>> +bool switched = false;
>>  int err;
>> 
>>  /* Expect a negative dentry */
>> @@ -1528,6 +1530,17 @@ int nfs_atomic_open(struct inode *dir, struct dentry 
>> *dentry,
>>  attr.ia_size = 0;
>>  }
>> 
>> +if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
>> +d_drop(dentry);
>> +switched = true;
>> +dentry = d_alloc_parallel(dentry->d_parent,
>> +  >d_name, );
> 
> Hm, d_alloc_parallel can return some preexisting dentry it was able to lookup 
> in
> rcu attached to the same parent with the same name it seems?
> What's to stop a parallel thread to rehash the dentry after we dropped it 
> here,
> and so d_alloc_parallel will happily find it?
> I am running a test to verify this theory now.

Ok, so at least in my case we do not come out of d_alloc_parallel() with a 
hashed
dentry, though I wonder why are not you trying to catch this case here?
If you rely on the !d_in_lookup(dentry) below, that seems to be racy.
if it was __d_lookup_rcu() that found the dentry, we do not seem to be 
performing
any additional checks on it and just return it.
But what if it was just added by a parallel caller here that just finished
d_splice_alias (= hashed dentry so it's not rejected by the __d_lookup_rcu) and
at the same time have not progressed all the way to d_lookup_done() call below?

Interesting that in some of the dumps d_hash is all zeroes, which means
it is unhashed, yet the assertion was triggered, so there was some parallel
caller that performed a d_drop on us (but nothing of interest on other CPUs).

In all cases d_flags = 140, so we do not have the DCACHE_PAR_LOOKUP set at the
point of crash.

Also in part of the dumps the dentry is actually positive, not negative.


> 
>> +if (IS_ERR(dentry))
>> +return PTR_ERR(dentry);
>> +

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

[Oleg Drokin]

On Jul 4, 2016, at 10:28 PM, Oleg Drokin wrote:

> 
> On Jul 3, 2016, at 2:29 AM, Al Viro wrote:
> 
>> On Sat, Jun 25, 2016 at 12:38:40PM -0400, Oleg Drokin wrote:
>> 
>>> Sorry to nag you about this, but did any of those pan out?
>>> 
>>> d_alloc_parallel() sounds like a bit too heavy there, esp. considering we 
>>> came in with
>>> a dentry already (though a potentially shared one, I understand).
>>> Would not it be better to try and establish some dentry locking rule for 
>>> calling into
>>> d_splice_alias() instead? At least then the callers can make sure the 
>>> dentry does
>>> not change under them?
>>> Though I guess if there's dentry locking like that, we might as well do all 
>>> the
>>> checking in d_splice_alias(), but that means the unhashed dentries would no
>>> longer be disallowed which is a change of semantic from now.--
>> 
>> FWIW, the only interesting case here is this:
>>  * no O_CREAT in flags (otherwise the parent is held exclusive).
>>  * dentry is found in hash
>>  * dentry is negative
>>  * dentry has passed ->d_revalidate() (i.e. in case of
>> NFS it had nfs_neg_need_reval() return false).
>> 
>> Only two instances are non-trivial in that respect - NFS and Lustre.
>> Everything else will simply fail open() with ENOENT in that case.
>> 
>> And at least for NFS we could bloody well do d_drop + d_alloc_parallel +
>> finish_no_open and bugger off in case it's not in_lookup, otherwise do
>> pretty much what we do in case we'd got in_lookup from the very beginning.
>> Some adjustments are needed for that case (basically, we need to make
>> sure we hit d_lookup_done() matching that d_alloc_parallel() and deal
>> with refcounting correctly).
>> 
>> Tentative NFS patch follows; I don't understand Lustre well enough, but it
>> looks like a plausible strategy there as well.
> 
> This patch seems to have brought the other crash back in (or something 
> similar),
> the one with a negative dentry being hashed when it's already hashed.
> it's not as easy to hit as before, but a lot easier than the race we are 
> hitting here.
> 
> Also in all cases it is ls that is crashing now, which seems to highlight it 
> is
> taking some of this new paths added.
> I have half a dosen crashdumps if you want me to look something up there.
> This is on top of 4.7.0-rc6 a99cde438de0c4c0cecc1d1af1a55a75b10bfdef
> with just your patch on top.
> 
> I can reproduce it with both the complex workload, or with a simplified one 
> (attached),
> takes anywhere from 5 to 30 minutes to hit.
> 
>> 
>> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> index d8015a03..5474e39 100644
>> --- a/fs/nfs/dir.c
>> +++ b/fs/nfs/dir.c
>> @@ -1485,11 +1485,13 @@ int nfs_atomic_open(struct inode *dir, struct dentry 
>> *dentry,
>>  struct file *file, unsigned open_flags,
>>  umode_t mode, int *opened)
>> {
>> +DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
>>  struct nfs_open_context *ctx;
>>  struct dentry *res;
>>  struct iattr attr = { .ia_valid = ATTR_OPEN };
>>  struct inode *inode;
>>  unsigned int lookup_flags = 0;
>> +bool switched = false;
>>  int err;
>> 
>>  /* Expect a negative dentry */
>> @@ -1528,6 +1530,17 @@ int nfs_atomic_open(struct inode *dir, struct dentry 
>> *dentry,
>>  attr.ia_size = 0;
>>  }
>> 
>> +if (!(open_flags & O_CREAT) && !d_unhashed(dentry)) {
>> +d_drop(dentry);
>> +switched = true;
>> +dentry = d_alloc_parallel(dentry->d_parent,
>> +  >d_name, );
> 
> Hm, d_alloc_parallel can return some preexisting dentry it was able to lookup 
> in
> rcu attached to the same parent with the same name it seems?
> What's to stop a parallel thread to rehash the dentry after we dropped it 
> here,
> and so d_alloc_parallel will happily find it?
> I am running a test to verify this theory now.

Ok, so at least in my case we do not come out of d_alloc_parallel() with a 
hashed
dentry, though I wonder why are not you trying to catch this case here?
If you rely on the !d_in_lookup(dentry) below, that seems to be racy.
if it was __d_lookup_rcu() that found the dentry, we do not seem to be 
performing
any additional checks on it and just return it.
But what if it was just added by a parallel caller here that just finished
d_splice_alias (= hashed dentry so it's not rejected by the __d_lookup_rcu) and
at the same time have not progressed all the way to d_lookup_done() call below?

Interesting that in some of the dumps d_hash is all zeroes, which means
it is unhashed, yet the assertion was triggered, so there was some parallel
caller that performed a d_drop on us (but nothing of interest on other CPUs).

In all cases d_flags = 140, so we do not have the DCACHE_PAR_LOOKUP set at the
point of crash.

Also in part of the dumps the dentry is actually positive, not negative.


> 
>> +if (IS_ERR(dentry))
>> +return PTR_ERR(dentry);
>> +

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

[Duc Dang]

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi
 wrote:
>
> On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote:
> > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code
> > > should include ACPI specific callbacks that parse and set-up the
> > > device IRQ number, equivalent to the DT boot path. Owing to the current
> > > ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings
> > > cannot be parsed at device add time, since that would trigger ACPI scan
> > > handlers ordering issues depending on how the ACPI tables are defined.
> >
> > Uh, OK :)  I can't figure out exactly what the problem is here -- I
> > don't know where to look if I wanted to fix the scan handler ordering
> > issues, and I don't know how I could tell if it would ever be safe to
> > move this from driver probe-time back to device add-time.
>
> Right, the commit log could have been more informative.
>
> pcibios_add_device() was added in:
>
> commit d1e6dc91b532 ("arm64: Add architectural support for PCI")
>
> whose commit log does not specify why legacy IRQ parsing should
> be done at pcibios_add_device() either, so honestly we had to
> do with the information we have at hand.
>
> > I also notice that x86 and ia64 call acpi_pci_irq_enable() even later,
> > when the driver *enables* the device.  Is there a reason you didn't do
> > it at the same time as x86 and ia64?  This is another of those pcibios
> > hooks that really don't do anything arch-specific, so I can imagine
> > refactoring this somehow, someday.
>
> Yes, with [1], that was the goal, that stopped because [1] does not
> work on x86.
>
> Only DT platform(s) affected by this change are all platforms relying on
> drivers/pci/host/pci-xgene.c (others rely on pci_fixup_irqs() that
> should be removed too), if on those platforms probing IRQs at device
> enable time works ok I can update this patch (it can be done through [1]
> once we figure out what to do with it on x86) and move the IRQ set-up at
> pcibios_enable_device() time.
>
> @Duc: any feedback on this ?

Hi Lorenzo,

The changes to add pcibios_alloc_irq works fine on X-Gene PCIe

I also tried to remove pcibios_alloc_irq and move its code into
pcibios_enable_device
after pci_enable_resource call and legacy IRQ also works.

Can you also point me to the discussion thread or some info. about the
issue on x86 with [1]?
I want to check if there is any more test case I need to verify.

Regards,
Duc Dang.

>
> Thanks,
> Lorenzo
>
> [1] http://www.spinics.net/lists/linux-pci/msg45950.html
>
> > Did we have this conversation before?  It seems vaguely familiar, so I
> > apologize if you already explained this once.
> >
> > > To solve this problem and consolidate FW PCI legacy IRQs parsing in
> > > one single pcibios callback (pending final removal), this patch moves
> > > DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by
> > > PCI core code at device probe time) and adds ACPI PCI legacy IRQs
> > > parsing to the same callback too, so that FW PCI legacy IRQs parsing
> > > is confined in one single arch callback that can be easily removed
> > > when code parsing PCI legacy IRQs is consolidated and moved to core
> > > PCI code.
> > >
> > > Signed-off-by: Tomasz Nowicki 
> > > Suggested-by: Lorenzo Pieralisi 
> > > ---
> > >  arch/arm64/kernel/pci.c | 11 ---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > index d5d3d26..b3b8a2c 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -51,11 +51,16 @@ int pcibios_enable_device(struct pci_dev *dev, int 
> > > mask)
> > >  }
> > >
> > >  /*
> > > - * Try to assign the IRQ number from DT when adding a new device
> > > + * Try to assign the IRQ number when probing a new device
> > >   */
> > > -int pcibios_add_device(struct pci_dev *dev)
> > > +int pcibios_alloc_irq(struct pci_dev *dev)
> > >  {
> > > -   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +   if (acpi_disabled)
> > > +   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +#ifdef CONFIG_ACPI
> > > +   else
> > > +   return acpi_pci_irq_enable(dev);
> > > +#endif
> > >
> > > return 0;
> > >  }
> > > --
> > > 1.9.1
> > >
> >

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
 wrote:
> Hi Dongdong,
>
> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index d3c3e85..49612b3 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -22,6 +22,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +/* Root pointer to the mapped MCFG table */
>> +static struct acpi_table_mcfg *mcfg_table;
>>
>>  /* Structure to hold entries from the MCFG table */
>>  struct mcfg_entry {
>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>  /* List to save mcfg entries */
>>  static LIST_HEAD(pci_mcfg_list);
>>
>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>> +
>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>> +{
>> + int bus_num = root->secondary.start;
>> + int domain = root->segment;
>> + struct pci_cfg_fixup *f;
>> +
>> + if (!mcfg_table)
>> + return _generic_ecam_ops;
>> +
>> + /*
>> +  * Match against platform specific quirks and return corresponding
>> +  * CAM ops.
>> +  *
>> +  * First match against PCI topology  then use OEM ID and
>> +  * OEM revision from MCFG table standard header.
>> +  */
>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> + if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) 
>> &&
>> + (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) 
>> &&
>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>> +   ACPI_OEM_ID_SIZE)) &&
>> + (!strncmp(f->oem_table_id, mcfg_table->header.oem_table_id,
>> +   ACPI_OEM_TABLE_ID_SIZE)))
>
> This would just be a small convenience, but if the character count used here 
> were
>
> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>
> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings and
> wouldn't need to be padded out to the full length.
>
>> + return f->ops;
>> + }
>> + /* No quirks, use ECAM */
>> + return _generic_ecam_ops;
>> +}
>
>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>> index 7d63a66..088a1da 100644
>> --- a/include/linux/pci-acpi.h
>> +++ b/include/linux/pci-acpi.h
>> @@ -25,6 +25,7 @@ static inline acpi_status 
>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>  extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
>>
>>  extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource *bus_res);
>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
>>
>>  static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
>>  {
>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>   int (*prepare_resources)(struct acpi_pci_root_info *info);
>>  };
>>
>> +struct pci_cfg_fixup {
>> + struct pci_ecam_ops *ops;
>> + char *oem_id;
>> + char *oem_table_id;
>> + int domain;
>> + int bus_num;
>> +};
>> +
>> +#define PCI_MCFG_DOMAIN_ANY  -1
>> +#define PCI_MCFG_BUS_ANY -1
>> +
>> +/* Designate a routine to fix up buggy MCFG */
>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
>> + static const struct pci_cfg_fixup   \
>> + __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
> I'm not entirely sure that this is the right fix--I'm pretty blindly
> following a GCC documentation suggestion [1]--but removing the first two
> preprocessor concatenation operators "##" solved the following build error
> for me.
>
> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and ""QCOM"" 
> does not give a valid preprocessing token
>   __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \

I think the problem is gcc is not happy with quoted string when
processing these tokens
(""QCOM"", the extra "" are added by gcc). So should we not concat
string tokens and
use the fixup definition in v1 of this RFC:
/* Designate a routine to fix up buggy MCFG */
#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus) \
static const struct pci_cfg_fixup __mcfg_fixup_##system##dom##bus\
 __used __attribute__((__section__(".acpi_fixup_mcfg"), \
aligned((sizeof(void *) =   \
{ ops, oem_id, rev, dom, bus };

Regards,
Duc Dang.


>   ^
> arch/arm64/kernel/pci.c:225:1: note: in expansion of macro 
> ‘DECLARE_ACPI_MCFG_FIXUP’
>  DECLARE_ACPI_MCFG_FIXUP(_32b_ecam_ops, "QCOM", "QDF2432", 
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
>  ^
> arch/arm64/kernel/pci.c:225:44: error: pasting ""QCOM"" and ""QDF2432"" does 
> not give a valid preprocessing token
>  DECLARE_ACPI_MCFG_FIXUP(_32b_ecam_ops, "QCOM", "QDF2432", 
> PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
> ^
> 

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Ashwin and Prashanth,

On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
> Hi Prashanth,
>
>
> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>  wrote:
>>
>>
>> On 6/8/2016 10:24 AM, Hoan Tran wrote:
>>> Hi Ashwin,
>>>
>>> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>>>  wrote:
 + Prashanth (Can you please have a look as well?)

 On 31 May 2016 at 15:35, Hoan Tran  wrote:
> Hi Ashwin,
 Hi,

 Sorry about the delay. I'm in the middle of switching jobs and
 locations, so its been a bit crazy lately.
>>> It's ok and hope you're doing well.
>>>
 I dont have any major
 concerns with this code, although there could be subtle issues with
 this IRQ thing. In this patchset, your intent is to add support for
 PCC subspace type 2. But you're also adding support for tx command
 completion which is not specific to Type 2. We could support that even
 in Type 1. Hence I wanted to separate the two, not just for review,
 but also the async IRQ completion has subtle issues esp. in the case
 of async platform notification, where you could have a PCC client in
 the OS writing to the cmd bit and the platform sending an async
 notification by writing to some bits in the same 8byte address as the
 cmd bit. So we need some mutual exclusivity there, otherwise the OS
 and platform could step on each other. Perhaps Prashanth has better
 insight into this.
>>> I think, this mutual exclusivity could be in another patch.
>> Ashwin,
>> Sorry, I am not sure how we can prevent platform and OSPM from stepping on
>> each other.  There is a line is spec that says "all operations on status 
>> field
>> must be made using interlocked operations", but not sure what these
>> interlocked operation translates to.
>
> Yes, I had the same question about how to prevent it.

For platform notification, if the hardware doesn't support interlocked
operations. I think we can use a workaround that, platform triggers
interrupt to OSPM without touching status field. The OSPM PCC client
will decide what to do with this interrupt. For example, OSPM sends a
consumer command to check it.

Thanks
Hoan

>
>>
>> Hoan,
>> Even if we are not using platform notification, we still need to clear the 
>> doorbell
>> interrupt bit in the PCC interrupt handler (Section14.2.2 and 14.4).  I 
>> didn't see
>> clearing the doorbell interrupt bit in this patch (and platform is supposed 
>> to set
>> it again when it is sending the interrupt again). Did I miss it? or is it 
>> intentionally
>> left out to avoid the race that Ashwin mentioned above?
>>
>
> The PCC client driver is supposed to do that. Which mean, the
> mbox_chan_received_data() function should clear it.
>
> Thanks
> Hoan
>
>>
>> Thanks,
>> Prashanth
>>
>>

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Ashwin and Prashanth,

On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
> Hi Prashanth,
>
>
> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>  wrote:
>>
>>
>> On 6/8/2016 10:24 AM, Hoan Tran wrote:
>>> Hi Ashwin,
>>>
>>> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>>>  wrote:
 + Prashanth (Can you please have a look as well?)

 On 31 May 2016 at 15:35, Hoan Tran  wrote:
> Hi Ashwin,
 Hi,

 Sorry about the delay. I'm in the middle of switching jobs and
 locations, so its been a bit crazy lately.
>>> It's ok and hope you're doing well.
>>>
 I dont have any major
 concerns with this code, although there could be subtle issues with
 this IRQ thing. In this patchset, your intent is to add support for
 PCC subspace type 2. But you're also adding support for tx command
 completion which is not specific to Type 2. We could support that even
 in Type 1. Hence I wanted to separate the two, not just for review,
 but also the async IRQ completion has subtle issues esp. in the case
 of async platform notification, where you could have a PCC client in
 the OS writing to the cmd bit and the platform sending an async
 notification by writing to some bits in the same 8byte address as the
 cmd bit. So we need some mutual exclusivity there, otherwise the OS
 and platform could step on each other. Perhaps Prashanth has better
 insight into this.
>>> I think, this mutual exclusivity could be in another patch.
>> Ashwin,
>> Sorry, I am not sure how we can prevent platform and OSPM from stepping on
>> each other.  There is a line is spec that says "all operations on status 
>> field
>> must be made using interlocked operations", but not sure what these
>> interlocked operation translates to.
>
> Yes, I had the same question about how to prevent it.

For platform notification, if the hardware doesn't support interlocked
operations. I think we can use a workaround that, platform triggers
interrupt to OSPM without touching status field. The OSPM PCC client
will decide what to do with this interrupt. For example, OSPM sends a
consumer command to check it.

Thanks
Hoan

>
>>
>> Hoan,
>> Even if we are not using platform notification, we still need to clear the 
>> doorbell
>> interrupt bit in the PCC interrupt handler (Section14.2.2 and 14.4).  I 
>> didn't see
>> clearing the doorbell interrupt bit in this patch (and platform is supposed 
>> to set
>> it again when it is sending the interrupt again). Did I miss it? or is it 
>> intentionally
>> left out to avoid the race that Ashwin mentioned above?
>>
>
> The PCC client driver is supposed to do that. Which mean, the
> mbox_chan_received_data() function should clear it.
>
> Thanks
> Hoan
>
>>
>> Thanks,
>> Prashanth
>>
>>

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki  wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> 在 2016/6/14 17:00, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>>  wrote:

 Hi Duc

 在 2016/6/14 4:57, Duc Dang 写道:
>
>
> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>  wrote:
>>
>>
>> Hi Dongdong,
>>
>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>
>>>
>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>> index d3c3e85..49612b3 100644
>>> --- a/drivers/acpi/pci_mcfg.c
>>> +++ b/drivers/acpi/pci_mcfg.c
>>> @@ -22,6 +22,10 @@
>>>#include 
>>>#include 
>>>#include 
>>> +#include 
>>> +
>>> +/* Root pointer to the mapped MCFG table */
>>> +static struct acpi_table_mcfg *mcfg_table;
>>>
>>>/* Structure to hold entries from the MCFG table */
>>>struct mcfg_entry {
>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>/* List to save mcfg entries */
>>>static LIST_HEAD(pci_mcfg_list);
>>>
>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>> +
>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>> +{
>>> + int bus_num = root->secondary.start;
>>> + int domain = root->segment;
>>> + struct pci_cfg_fixup *f;
>>> +
>>> + if (!mcfg_table)
>>> + return _generic_ecam_ops;
>>> +
>>> + /*
>>> +  * Match against platform specific quirks and return
>>> corresponding
>>> +  * CAM ops.
>>> +  *
>>> +  * First match against PCI topology  then use
>>> OEM ID
>>> and
>>> +  * OEM revision from MCFG table standard header.
>>> +  */
>>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>> f++) {
>>> + if ((f->domain == domain || f->domain ==
>>> PCI_MCFG_DOMAIN_ANY) &&
>>> + (f->bus_num == bus_num || f->bus_num ==
>>> PCI_MCFG_BUS_ANY) &&
>>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>> +   ACPI_OEM_ID_SIZE)) &&
>>> + (!strncmp(f->oem_table_id,
>>> mcfg_table->header.oem_table_id,
>>> +   ACPI_OEM_TABLE_ID_SIZE)))
>>
>>
>>
>> This would just be a small convenience, but if the character count
>> used
>> here were
>>
>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>
>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>> substrings
>> and
>> wouldn't need to be padded out to the full length.
>>
>>> + return f->ops;
>>> + }
>>> + /* No quirks, use ECAM */
>>> + return _generic_ecam_ops;
>>> +}
>>
>>
>>
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 7d63a66..088a1da 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>> handle);
>>>
>>>extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>> *bus_res);
>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>> *root);
>>>
>>>static inline acpi_handle acpi_find_root_bridge_handle(struct
>>> pci_dev
>>> *pdev)
>>>{
>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>> int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>};
>>>
>>> +struct pci_cfg_fixup {
>>> + struct pci_ecam_ops *ops;
>>> + char *oem_id;
>>> + char *oem_table_id;
>>> + int domain;
>>> + int bus_num;
>>> +};
>>> +
>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>> +#define PCI_MCFG_BUS_ANY -1
>>> +
>>> +/* Designate a routine to fix up buggy MCFG */
>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>> bus) \
>>> + static const struct
>>> pci_cfg_fixup   \
>>> +
>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>>
>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>> following a GCC documentation suggestion [1]--but removing the
>> first two
>> preprocessor concatenation operators "##" solved the following build
>> error
>> for me.
>>
>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>> ""QCOM"" does not give a valid preprocessing token
>> 

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki  wrote:
> On 14.06.2016 11:45, Dongdong Liu wrote:
>>
>> Hi Duc
>>
>> 在 2016/6/14 17:00, Duc Dang 写道:
>>>
>>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu
>>>  wrote:

 Hi Duc

 在 2016/6/14 4:57, Duc Dang 写道:
>
>
> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>  wrote:
>>
>>
>> Hi Dongdong,
>>
>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:
>>>
>>>
>>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>>> index d3c3e85..49612b3 100644
>>> --- a/drivers/acpi/pci_mcfg.c
>>> +++ b/drivers/acpi/pci_mcfg.c
>>> @@ -22,6 +22,10 @@
>>>#include 
>>>#include 
>>>#include 
>>> +#include 
>>> +
>>> +/* Root pointer to the mapped MCFG table */
>>> +static struct acpi_table_mcfg *mcfg_table;
>>>
>>>/* Structure to hold entries from the MCFG table */
>>>struct mcfg_entry {
>>> @@ -35,6 +39,38 @@ struct mcfg_entry {
>>>/* List to save mcfg entries */
>>>static LIST_HEAD(pci_mcfg_list);
>>>
>>> +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
>>> +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
>>> +
>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>> +{
>>> + int bus_num = root->secondary.start;
>>> + int domain = root->segment;
>>> + struct pci_cfg_fixup *f;
>>> +
>>> + if (!mcfg_table)
>>> + return _generic_ecam_ops;
>>> +
>>> + /*
>>> +  * Match against platform specific quirks and return
>>> corresponding
>>> +  * CAM ops.
>>> +  *
>>> +  * First match against PCI topology  then use
>>> OEM ID
>>> and
>>> +  * OEM revision from MCFG table standard header.
>>> +  */
>>> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>> f++) {
>>> + if ((f->domain == domain || f->domain ==
>>> PCI_MCFG_DOMAIN_ANY) &&
>>> + (f->bus_num == bus_num || f->bus_num ==
>>> PCI_MCFG_BUS_ANY) &&
>>> + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>> +   ACPI_OEM_ID_SIZE)) &&
>>> + (!strncmp(f->oem_table_id,
>>> mcfg_table->header.oem_table_id,
>>> +   ACPI_OEM_TABLE_ID_SIZE)))
>>
>>
>>
>> This would just be a small convenience, but if the character count
>> used
>> here were
>>
>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>
>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be
>> substrings
>> and
>> wouldn't need to be padded out to the full length.
>>
>>> + return f->ops;
>>> + }
>>> + /* No quirks, use ECAM */
>>> + return _generic_ecam_ops;
>>> +}
>>
>>
>>
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 7d63a66..088a1da 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -25,6 +25,7 @@ static inline acpi_status
>>> pci_acpi_remove_pm_notifier(struct acpi_device *dev)
>>>extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle
>>> handle);
>>>
>>>extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
>>> *bus_res);
>>> +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
>>> *root);
>>>
>>>static inline acpi_handle acpi_find_root_bridge_handle(struct
>>> pci_dev
>>> *pdev)
>>>{
>>> @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
>>> int (*prepare_resources)(struct acpi_pci_root_info *info);
>>>};
>>>
>>> +struct pci_cfg_fixup {
>>> + struct pci_ecam_ops *ops;
>>> + char *oem_id;
>>> + char *oem_table_id;
>>> + int domain;
>>> + int bus_num;
>>> +};
>>> +
>>> +#define PCI_MCFG_DOMAIN_ANY  -1
>>> +#define PCI_MCFG_BUS_ANY -1
>>> +
>>> +/* Designate a routine to fix up buggy MCFG */
>>> +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom,
>>> bus) \
>>> + static const struct
>>> pci_cfg_fixup   \
>>> +
>>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>>
>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>> following a GCC documentation suggestion [1]--but removing the
>> first two
>> preprocessor concatenation operators "##" solved the following build
>> error
>> for me.
>>
>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>> ""QCOM"" does not give a valid preprocessing token
>> __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>
>
>
> I think the problem is gcc 

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu  wrote:
> Hi Duc
>
> 在 2016/6/14 4:57, Duc Dang 写道:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>  wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:

 diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
 index d3c3e85..49612b3 100644
 --- a/drivers/acpi/pci_mcfg.c
 +++ b/drivers/acpi/pci_mcfg.c
 @@ -22,6 +22,10 @@
   #include 
   #include 
   #include 
 +#include 
 +
 +/* Root pointer to the mapped MCFG table */
 +static struct acpi_table_mcfg *mcfg_table;

   /* Structure to hold entries from the MCFG table */
   struct mcfg_entry {
 @@ -35,6 +39,38 @@ struct mcfg_entry {
   /* List to save mcfg entries */
   static LIST_HEAD(pci_mcfg_list);

 +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
 +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
 +
 +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
 +{
 + int bus_num = root->secondary.start;
 + int domain = root->segment;
 + struct pci_cfg_fixup *f;
 +
 + if (!mcfg_table)
 + return _generic_ecam_ops;
 +
 + /*
 +  * Match against platform specific quirks and return corresponding
 +  * CAM ops.
 +  *
 +  * First match against PCI topology  then use OEM ID
 and
 +  * OEM revision from MCFG table standard header.
 +  */
 + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
 f++) {
 + if ((f->domain == domain || f->domain ==
 PCI_MCFG_DOMAIN_ANY) &&
 + (f->bus_num == bus_num || f->bus_num ==
 PCI_MCFG_BUS_ANY) &&
 + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
 +   ACPI_OEM_ID_SIZE)) &&
 + (!strncmp(f->oem_table_id,
 mcfg_table->header.oem_table_id,
 +   ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
 + return f->ops;
 + }
 + /* No quirks, use ECAM */
 + return _generic_ecam_ops;
 +}
>>>
>>>
 diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
 index 7d63a66..088a1da 100644
 --- a/include/linux/pci-acpi.h
 +++ b/include/linux/pci-acpi.h
 @@ -25,6 +25,7 @@ static inline acpi_status
 pci_acpi_remove_pm_notifier(struct acpi_device *dev)
   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);

   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
 *bus_res);
 +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
 *root);

   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
 *pdev)
   {
 @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
int (*prepare_resources)(struct acpi_pci_root_info *info);
   };

 +struct pci_cfg_fixup {
 + struct pci_ecam_ops *ops;
 + char *oem_id;
 + char *oem_table_id;
 + int domain;
 + int bus_num;
 +};
 +
 +#define PCI_MCFG_DOMAIN_ANY  -1
 +#define PCI_MCFG_BUS_ANY -1
 +
 +/* Designate a routine to fix up buggy MCFG */
 +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
 + static const struct pci_cfg_fixup   \
 + __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first two
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>__mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus) \
>>  static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>   __used __attribute__((__section__(".acpi_fixup_mcfg"), \
>>  aligned((sizeof(void *) =   \
>>  { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the 

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu  wrote:
> Hi Duc
>
> 在 2016/6/14 4:57, Duc Dang 写道:
>>
>> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington
>>  wrote:
>>>
>>> Hi Dongdong,
>>>
>>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:

 diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
 index d3c3e85..49612b3 100644
 --- a/drivers/acpi/pci_mcfg.c
 +++ b/drivers/acpi/pci_mcfg.c
 @@ -22,6 +22,10 @@
   #include 
   #include 
   #include 
 +#include 
 +
 +/* Root pointer to the mapped MCFG table */
 +static struct acpi_table_mcfg *mcfg_table;

   /* Structure to hold entries from the MCFG table */
   struct mcfg_entry {
 @@ -35,6 +39,38 @@ struct mcfg_entry {
   /* List to save mcfg entries */
   static LIST_HEAD(pci_mcfg_list);

 +extern struct pci_cfg_fixup __start_acpi_mcfg_fixups[];
 +extern struct pci_cfg_fixup __end_acpi_mcfg_fixups[];
 +
 +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
 +{
 + int bus_num = root->secondary.start;
 + int domain = root->segment;
 + struct pci_cfg_fixup *f;
 +
 + if (!mcfg_table)
 + return _generic_ecam_ops;
 +
 + /*
 +  * Match against platform specific quirks and return corresponding
 +  * CAM ops.
 +  *
 +  * First match against PCI topology  then use OEM ID
 and
 +  * OEM revision from MCFG table standard header.
 +  */
 + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
 f++) {
 + if ((f->domain == domain || f->domain ==
 PCI_MCFG_DOMAIN_ANY) &&
 + (f->bus_num == bus_num || f->bus_num ==
 PCI_MCFG_BUS_ANY) &&
 + (!strncmp(f->oem_id, mcfg_table->header.oem_id,
 +   ACPI_OEM_ID_SIZE)) &&
 + (!strncmp(f->oem_table_id,
 mcfg_table->header.oem_table_id,
 +   ACPI_OEM_TABLE_ID_SIZE)))
>>>
>>>
>>> This would just be a small convenience, but if the character count used
>>> here were
>>>
>>> min(strlen(f->oem_id), ACPI_OEM_ID_SIZE)
>>>
>>> then the parameters to DECLARE_ACPI_MCFG_FIXUP macro could be substrings
>>> and
>>> wouldn't need to be padded out to the full length.
>>>
 + return f->ops;
 + }
 + /* No quirks, use ECAM */
 + return _generic_ecam_ops;
 +}
>>>
>>>
 diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
 index 7d63a66..088a1da 100644
 --- a/include/linux/pci-acpi.h
 +++ b/include/linux/pci-acpi.h
 @@ -25,6 +25,7 @@ static inline acpi_status
 pci_acpi_remove_pm_notifier(struct acpi_device *dev)
   extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);

   extern phys_addr_t pci_mcfg_lookup(u16 domain, struct resource
 *bus_res);
 +extern struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root
 *root);

   static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev
 *pdev)
   {
 @@ -72,6 +73,25 @@ struct acpi_pci_root_ops {
int (*prepare_resources)(struct acpi_pci_root_info *info);
   };

 +struct pci_cfg_fixup {
 + struct pci_ecam_ops *ops;
 + char *oem_id;
 + char *oem_table_id;
 + int domain;
 + int bus_num;
 +};
 +
 +#define PCI_MCFG_DOMAIN_ANY  -1
 +#define PCI_MCFG_BUS_ANY -1
 +
 +/* Designate a routine to fix up buggy MCFG */
 +#define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, oem_table_id, dom, bus) \
 + static const struct pci_cfg_fixup   \
 + __mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>>
>>>
>>> I'm not entirely sure that this is the right fix--I'm pretty blindly
>>> following a GCC documentation suggestion [1]--but removing the first two
>>> preprocessor concatenation operators "##" solved the following build
>>> error
>>> for me.
>>>
>>> include/linux/pci-acpi.h:90:2: error: pasting "__mcfg_fixup_" and
>>> ""QCOM"" does not give a valid preprocessing token
>>>__mcfg_fixup_##oem_id##oem_table_id##dom##bus   \
>>
>>
>> I think the problem is gcc is not happy with quoted string when
>> processing these tokens
>> (""QCOM"", the extra "" are added by gcc). So should we not concat
>> string tokens and
>> use the fixup definition in v1 of this RFC:
>> /* Designate a routine to fix up buggy MCFG */
>> #define DECLARE_ACPI_MCFG_FIXUP(ops, oem_id, rev, dom, bus) \
>>  static const struct pci_cfg_fixup
>> __mcfg_fixup_##system##dom##bus\
>>   __used __attribute__((__section__(".acpi_fixup_mcfg"), \
>>  aligned((sizeof(void *) =   \
>>  { ops, oem_id, rev, dom, bus };
>
>
> V1 fixup exist the redefinition error when compiling mutiple
> 

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters  wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> 
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h    4]Signature : "MCFG"[Memory Mapped
> Configuration table]
> [004h 0004   4] Table Length : 003C
> [008h 0008   1] Revision : 01
> [009h 0009   1] Checksum : 4A
> [00Ah 0010   6]   Oem ID : "APM   "
> [010h 0016   8] Oem Table ID : "XGENE   "
> [018h 0024   4] Oem Revision : 0002
> [01Ch 0028   4]  Asl Compiler ID : "INTL"
> [020h 0032   4]Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h    4]Signature : "MCFG"[Memory Mapped
> Configuration table]
> [004h 0004   4] Table Length : 003C
> [008h 0008   1] Revision : 01
> [009h 0009   1] Checksum : 48
> [00Ah 0010   6]   Oem ID : "APM   "
> [010h 0016   8] Oem Table ID : "XGENE   "
> [018h 0024   4] Oem Revision : 0001
> [01Ch 0028   4]  Asl Compiler ID : "HP  "
> [020h 0032   4]Asl Compiler Revision : 0001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

[Duc Dang]

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters  wrote:
> On 06/13/2016 09:54 AM, Gabriele Paoloni wrote:
>> Hi Tomasz, Jon
>
> Hi Gab,
>
> Sorry for the lag in following up.
>
> 
>
>> As you can see here Liudongdong has replaced oem_revision with
>> oem_table_id.
>>
>> Now it seems that there are some platforms that have already shipped
>> using a matching based on the oem_revision (right Jon?)
>
> Actually, it turns out (Cov is correct) that we can just match on OEM
> Table ID. The revision should not generally be needed and the vendors
> will just need to make sure that they change OEM Table ID in future
> silicon. An example from two shipping platforms:
>
> 1). AppliedMicro Mustang:
>
> [000h    4]Signature : "MCFG"[Memory Mapped
> Configuration table]
> [004h 0004   4] Table Length : 003C
> [008h 0008   1] Revision : 01
> [009h 0009   1] Checksum : 4A
> [00Ah 0010   6]   Oem ID : "APM   "
> [010h 0016   8] Oem Table ID : "XGENE   "
> [018h 0024   4] Oem Revision : 0002
> [01Ch 0028   4]  Asl Compiler ID : "INTL"
> [020h 0032   4]Asl Compiler Revision : 20140724
>
> 2). HP(E[0]) Moonshot:
>
> [000h    4]Signature : "MCFG"[Memory Mapped
> Configuration table]
> [004h 0004   4] Table Length : 003C
> [008h 0008   1] Revision : 01
> [009h 0009   1] Checksum : 48
> [00Ah 0010   6]   Oem ID : "APM   "
> [010h 0016   8] Oem Table ID : "XGENE   "
> [018h 0024   4] Oem Revision : 0001
> [01Ch 0028   4]  Asl Compiler ID : "HP  "
> [020h 0032   4]Asl Compiler Revision : 0001
>
> I have pinged the semiconductor (Applied) and insisted upon a written
> plan (which I have now) for handling the first affect generation(s) and
> future chip roadmap stuff, along with how they plan to upstream this
> immediately as part of this thread. I have also done similar with each
> of the other vendors (this is something ARM or Linaro should be doing).
> But I particularly care about X-Gene because I want it to be loved as
> shipping silicon in production systems (Moonshot) that are sitting and
> waiting in the Fedora Phoenix datacenter in large quantity to come
> online if only an upstream kernel would actually boot on them :)

Thanks for the MCFG information on Moonshot system, Jon.

I will make sure the posted quirk for X-Gene takes care for HPE
Moonshot system as well.

Regards,
Duc Dang.

>
>> However I guess that if in FW they have defined oem_table_id properly
>> they should be able to use this mechanism without needing to a FW update.
>
> Correct.
>
>> Can these vendors confirm this?
>
> I've checked all current shipping silicon and prototypes.
>
>> Tomasz do you think this can work for Cavium Thunder?
>
> Will let the vendors followup directly as well.
>
> Jon.
>
> [0] Fortunately that name change doesn't factor when using semiconductor
> matching...hopefully none of the non-complaint IP companies in gen1
> stuff get bought and change their table names. In the unlikely event
> that that does happen, I will preemptively beat them up and ensure that
> something crazy doesn't happen with table contents.
>
> --
> Computer Architect | Sent from my Fedora powered laptop

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

As PCC will be used by other clients not only CPPC.
This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
declarations

Signed-off-by: Hoan Tran 
---
 include/acpi/cppc_acpi.h   | 4 
 include/linux/mailbox_client.h | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index dad8af3..819b4b9 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -130,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
*perf_ctrls);
 extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
 extern int acpi_get_psd_map(struct cpudata **);
 
-/* Methods to interact with the PCC mailbox controller. */
-extern struct mbox_chan *
-   pcc_mbox_request_channel(struct mbox_client *, unsigned int);
-
 #endif /* _CPPC_ACPI_H*/
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 41e2af8..2758d18 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -50,4 +50,8 @@ void mbox_client_txdone(struct mbox_chan *chan, int r); /* 
atomic */
 bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */
 void mbox_free_channel(struct mbox_chan *chan); /* may sleep */
 
+/* Methods to interact with the PCC mailbox controller. */
+struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *, int);
+void pcc_mbox_free_channel(struct mbox_chan *chan);
+
 #endif /* __MAILBOX_CLIENT_H */
-- 
1.9.1

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

As PCC will be used by other clients not only CPPC.
This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
declarations

Signed-off-by: Hoan Tran 
---
 include/acpi/cppc_acpi.h   | 4 
 include/linux/mailbox_client.h | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index dad8af3..819b4b9 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -130,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
*perf_ctrls);
 extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
 extern int acpi_get_psd_map(struct cpudata **);
 
-/* Methods to interact with the PCC mailbox controller. */
-extern struct mbox_chan *
-   pcc_mbox_request_channel(struct mbox_client *, unsigned int);
-
 #endif /* _CPPC_ACPI_H*/
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 41e2af8..2758d18 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -50,4 +50,8 @@ void mbox_client_txdone(struct mbox_chan *chan, int r); /* 
atomic */
 bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */
 void mbox_free_channel(struct mbox_chan *chan); /* may sleep */
 
+/* Methods to interact with the PCC mailbox controller. */
+struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *, int);
+void pcc_mbox_free_channel(struct mbox_chan *chan);
+
 #endif /* __MAILBOX_CLIENT_H */
-- 
1.9.1

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered

[Duc Dang]

On Fri, Jun 10, 2016 at 12:29 AM, Marc Zyngier  wrote:
> On Thu, 09 Jun 2016 14:10:48 -0700
> David Daney  wrote:
>
>> On 06/06/2016 10:56 AM, Marc Zyngier wrote:
>> > The ARM architected timer produces level-triggered interrupts (this
>> > is mandated by the architecture). Unfortunately, most device-trees
>> > get this wrong, and expose an edge-triggered interrupt.
>> >
>> > Until now, this wasn't too much an issue, as the programming of the
>> > trigger would fail (the corresponding PPI cannot be reconfigured),
>> > and the kernel would be happy with this. But we're about to change
>> > this, and trust DT a lot if the driver doesn't provide its own
>> > trigger information. In that context, the timer breaks badly.
>> >
>> > While we do need to fix the DTs, there is also some userspace out
>> > there (kvmtool) that generates the same kind of broken DT on the
>> > fly, and that will completely break with newer kernels.
>> >
>> > As a safety measure, and to keep buggy software alive as well as
>> > buying us some time to fix DTs all over the place, let's check
>> > what trigger configuration has been given us by the firmware.
>> > If this is not a level configuration, then we know that the
>> > DT/ACPI configuration is bust, and we pick some defaults which
>> > won't be worse than the existing setup.
>> >
>> > Signed-off-by: Marc Zyngier 
>>
>>
>> I tried to test this patch, but there is a problem somewhere that I have
>> not yet tracked down.  On Cavium Thunder (gic-v3 based) I have tested
>> with the device tree interrupt type of both 4 and 8 and get the same result:
>>
>>
>> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ2,
>> assuming level low
>> [0.00] arm_arch_timer: WARNING: Please fix your firmware
>> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ3,
>> assuming level low
>> [0.00] arm_arch_timer: WARNING: Please fix your firmware
>> [0.00] arm_arch_timer: Architected cp15 timer(s) running at
>> 100.00MHz (phys).
>> [0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
>> [0.02] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps
>> every 4398046511100ns
>>
>> It could be that the gic-v3 irq mapping code is broken.  I will try to
>> look into it, but there may be other fixes needed before we would
>> consider this patch to be an improvement.
>
> That's because the core kernel has other bugs which are going to be
> addressed in 4.8. So far, we cannot set the trigger of a per-cpu
> interrupt from the device tree, and we end-up with whatever is the
> default (edge). You can put whatever you want in the DT, it will be
> ignored.
>
> This series in preparation of these fixes landing in 4.8, where we'll
> be able to do the right thing, and will start noticing stupid things
> coming from the DT.
Hi Marc,

I also see the same warning that David saw. Can you please cc me when
the bug fix series
is available? I will test it out for X-Gene 1 and will need to change
the interrupt setting for timer
events on X-Gene 2 as well.

Regards,
Duc Dang.

>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.

Re: [PATCH v3 2/2] arm64: dts: Fix broken architected timer interrupt trigger

[Duc Dang]

On Mon, Jun 6, 2016 at 10:56 AM, Marc Zyngier  wrote:
> The ARM architected timer specification mandates that the interrupt
> associated with each timer is level triggered (which corresponds to
> the "counter >= comparator" condition).
>
> A number of DTs are being remarkably creative, declaring the interrupt
> to be edge triggered. A quick look at the TRM for the corresponding ARM
> CPUs clearly shows that this is wrong, and I've corrected those.
> For non-ARM designs (and in the absence of a publicly available TRM),
> I've made them active low as well, which can't be completely wrong
> as the GIC cannot disinguish between level low and level high.
>
> The respective maintainers are of course welcome to prove me wrong.
>
> While I was at it, I took the liberty to fix a couple of related issue,
> such as some spurious affinity bits on ThunderX, and their complete
> absence on ls1043a (both of which seem to be related to copy-pasting
> from other DTs).
>
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
>  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
>  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
>  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
>  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi   | 8 
>  10 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
> b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> index 445aa67..c2b9bcb 100644
> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> @@ -255,10 +255,10 @@
> /* Local timer */
> timer {
> compatible = "arm,armv8-timer";
> -   interrupts = <1 13 0xf01>,
> -<1 14 0xf01>,
> -<1 11 0xf01>,
> -<1 10 0xf01>;
> +   interrupts = <1 13 0xf08>,
> +<1 14 0xf08>,
> +<1 11 0xf08>,
> +<1 10 0xf08>;
> };
>
> timer0: timer0@ffc03000 {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 832815d..4d9d144 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -100,13 +100,13 @@
> timer {
> compatible = "arm,armv8-timer";
> interrupts =  -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
> };
>
> xtal: xtal-clk {
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index 5147d76..1c4193f 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -110,10 +110,10 @@
>
> timer {
> compatible = "arm,armv8-timer";
> -   interrupts = <1 0 0xff01>,  /* Secure Phys IRQ */
> -<1 13 0xff01>, /* Non-secure Phys IRQ */
> -<1 14 0xff01>, /* Virt IRQ */
> -<1 15 0xff01>; /* Hyp IRQ */
> +   interrupts = <1 0 0xff08>,  /* Secure Phys IRQ */
> +<1 13 0xff08>, /* Non-secure Phys IRQ */
> +<1 14 0xff08>, /* Virt IRQ */
> +<1 15 0xff08>; /* Hyp IRQ */
> clock-frequency = <5000>;
> };

For above changes on apm-storm.dtsi for APM X-Gene 1:

Acked-by: Duc Dang 

Thanks,
Duc Dang.

>
> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> index ec68ec1..9c2d8a7 100644
> --- 

Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered

[Duc Dang]

On Fri, Jun 10, 2016 at 12:29 AM, Marc Zyngier  wrote:
> On Thu, 09 Jun 2016 14:10:48 -0700
> David Daney  wrote:
>
>> On 06/06/2016 10:56 AM, Marc Zyngier wrote:
>> > The ARM architected timer produces level-triggered interrupts (this
>> > is mandated by the architecture). Unfortunately, most device-trees
>> > get this wrong, and expose an edge-triggered interrupt.
>> >
>> > Until now, this wasn't too much an issue, as the programming of the
>> > trigger would fail (the corresponding PPI cannot be reconfigured),
>> > and the kernel would be happy with this. But we're about to change
>> > this, and trust DT a lot if the driver doesn't provide its own
>> > trigger information. In that context, the timer breaks badly.
>> >
>> > While we do need to fix the DTs, there is also some userspace out
>> > there (kvmtool) that generates the same kind of broken DT on the
>> > fly, and that will completely break with newer kernels.
>> >
>> > As a safety measure, and to keep buggy software alive as well as
>> > buying us some time to fix DTs all over the place, let's check
>> > what trigger configuration has been given us by the firmware.
>> > If this is not a level configuration, then we know that the
>> > DT/ACPI configuration is bust, and we pick some defaults which
>> > won't be worse than the existing setup.
>> >
>> > Signed-off-by: Marc Zyngier 
>>
>>
>> I tried to test this patch, but there is a problem somewhere that I have
>> not yet tracked down.  On Cavium Thunder (gic-v3 based) I have tested
>> with the device tree interrupt type of both 4 and 8 and get the same result:
>>
>>
>> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ2,
>> assuming level low
>> [0.00] arm_arch_timer: WARNING: Please fix your firmware
>> [0.00] arm_arch_timer: WARNING: Invalid trigger for IRQ3,
>> assuming level low
>> [0.00] arm_arch_timer: WARNING: Please fix your firmware
>> [0.00] arm_arch_timer: Architected cp15 timer(s) running at
>> 100.00MHz (phys).
>> [0.00] clocksource: arch_sys_counter: mask: 0xff
>> max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
>> [0.02] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps
>> every 4398046511100ns
>>
>> It could be that the gic-v3 irq mapping code is broken.  I will try to
>> look into it, but there may be other fixes needed before we would
>> consider this patch to be an improvement.
>
> That's because the core kernel has other bugs which are going to be
> addressed in 4.8. So far, we cannot set the trigger of a per-cpu
> interrupt from the device tree, and we end-up with whatever is the
> default (edge). You can put whatever you want in the DT, it will be
> ignored.
>
> This series in preparation of these fixes landing in 4.8, where we'll
> be able to do the right thing, and will start noticing stupid things
> coming from the DT.
Hi Marc,

I also see the same warning that David saw. Can you please cc me when
the bug fix series
is available? I will test it out for X-Gene 1 and will need to change
the interrupt setting for timer
events on X-Gene 2 as well.

Regards,
Duc Dang.

>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.

Re: [PATCH v3 2/2] arm64: dts: Fix broken architected timer interrupt trigger

[Duc Dang]

On Mon, Jun 6, 2016 at 10:56 AM, Marc Zyngier  wrote:
> The ARM architected timer specification mandates that the interrupt
> associated with each timer is level triggered (which corresponds to
> the "counter >= comparator" condition).
>
> A number of DTs are being remarkably creative, declaring the interrupt
> to be edge triggered. A quick look at the TRM for the corresponding ARM
> CPUs clearly shows that this is wrong, and I've corrected those.
> For non-ARM designs (and in the absence of a publicly available TRM),
> I've made them active low as well, which can't be completely wrong
> as the GIC cannot disinguish between level low and level high.
>
> The respective maintainers are of course welcome to prove me wrong.
>
> While I was at it, I took the liberty to fix a couple of related issue,
> such as some spurious affinity bits on ThunderX, and their complete
> absence on ls1043a (both of which seem to be related to copy-pasting
> from other DTs).
>
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi| 8 
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  | 8 
>  arch/arm64/boot/dts/apm/apm-storm.dtsi   | 8 
>  arch/arm64/boot/dts/broadcom/ns2.dtsi| 8 
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 8 
>  arch/arm64/boot/dts/exynos/exynos7.dtsi  | 8 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   | 8 
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi| 8 
>  arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 8 
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi   | 8 
>  10 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
> b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> index 445aa67..c2b9bcb 100644
> --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
> @@ -255,10 +255,10 @@
> /* Local timer */
> timer {
> compatible = "arm,armv8-timer";
> -   interrupts = <1 13 0xf01>,
> -<1 14 0xf01>,
> -<1 11 0xf01>,
> -<1 10 0xf01>;
> +   interrupts = <1 13 0xf08>,
> +<1 14 0xf08>,
> +<1 11 0xf08>,
> +<1 10 0xf08>;
> };
>
> timer0: timer0@ffc03000 {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 832815d..4d9d144 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -100,13 +100,13 @@
> timer {
> compatible = "arm,armv8-timer";
> interrupts =  -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
>   -   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
> +   (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
> };
>
> xtal: xtal-clk {
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
> b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index 5147d76..1c4193f 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -110,10 +110,10 @@
>
> timer {
> compatible = "arm,armv8-timer";
> -   interrupts = <1 0 0xff01>,  /* Secure Phys IRQ */
> -<1 13 0xff01>, /* Non-secure Phys IRQ */
> -<1 14 0xff01>, /* Virt IRQ */
> -<1 15 0xff01>; /* Hyp IRQ */
> +   interrupts = <1 0 0xff08>,  /* Secure Phys IRQ */
> +<1 13 0xff08>, /* Non-secure Phys IRQ */
> +<1 14 0xff08>, /* Virt IRQ */
> +<1 15 0xff08>; /* Hyp IRQ */
> clock-frequency = <5000>;
> };

For above changes on apm-storm.dtsi for APM X-Gene 1:

Acked-by: Duc Dang 

Thanks,
Duc Dang.

>
> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> index ec68ec1..9c2d8a7 100644
> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
> +++ 

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Tue, Jun 21, 2016 at 2:26 AM, Lorenzo Pieralisi
 wrote:
> On Mon, Jun 20, 2016 at 12:12:24PM -0700, Duc Dang wrote:
>> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
>>  wrote:
>> > Hi Duc,
>> >
>> > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>> >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
>> >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
>> >>>  wrote:
>>  On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
>> > From: Tomasz Nowicki 
>> >
>> > pci_generic_ecam_ops is used by default. Since there are platforms
>> > which have non-compliant ECAM space we need to overwrite these
>> > accessors prior to PCI buses enumeration. In order to do that
>> > we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
>> > we can use proper PCI config space accessors and bus_shift.
>> >
>> > pci_generic_ecam_ops is still used for platforms free from quirks.
>> >
>> > Signed-off-by: Tomasz Nowicki 
>> > ---
>> >  arch/arm64/kernel/pci.c | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> > index 94cd43c..a891bda 100644
>> > --- a/arch/arm64/kernel/pci.c
>> > +++ b/arch/arm64/kernel/pci.c
>> > @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> > *root)
>> >   struct pci_config_window *cfg;
>> >   struct resource cfgres;
>> >   unsigned int bsz;
>> > + struct pci_ecam_ops *ops;
>> >
>> >   /* Use address from _CBA if present, otherwise lookup MCFG */
>> >   if (!root->mcfg_addr)
>> > @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> > *root)
>> >   return NULL;
>> >   }
>> >
>> > - bsz = 1 << pci_generic_ecam_ops.bus_shift;
>> > + ops = pci_mcfg_get_ops(root);
>> > + bsz = 1 << ops->bus_shift;
>> >   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>> >   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>> >   cfgres.flags = IORESOURCE_MEM;
>> > - cfg = pci_ecam_create(>device->dev, , bus_res,
>> > -   _generic_ecam_ops);
>> > + cfg = pci_ecam_create(>device->dev, , bus_res, ops);
>> 
>>  Arnd pointed this out already, I think that's the only pending question
>>  here.
>> 
>>  pci_ecam_create() maps ECAM space for config regions retrieved from
>>  the MCFG, which are *supposed* to be ECAM compliant.
>> 
>>  Do we think that's *always* correct/safe regardless of the kind
>>  of quirk we are currently fixing up ?
>> 
>>  Or we do think that configuration space regions should come from
>>  a different resource declared in the ACPI namespace if the regions
>>  are not MCFG/ECAM compliant (ie config space is not defined through
>>  MCFG at all - possibly through a _CRS method for a vendor specific
>>  _HID under the PNP0A03 node ?)
>> >>>
>> >>> Hi Lorenzo,
>> >>>
>> >>> For X-Gene: the ECAM space is used to access the configuration space
>> >>> of PCIe devices, with additional help from controller register to
>> >>> specify the bus, device and function number. Below is the RFC patch
>> >>> that implements ECAM fixup for X-Gene PCIe controller on top of this
>> >>> RFC ECAM quirk v3 for your and others reference.
>> >>
>> >> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>> >> your register that is a deliberate abuse of the ACPI standard in
>> >> that the _CRS is meant to describe resources that are passed on
>> >> to secondary buses
>> >
>> > A potential alternative came up in an off-list discussion: Would it be
>> > better to hard code the information in the quirk workaround than look it
>> > up from a repurposed ACPI resource?
>>
>> Hi Chris, Lorenzo,
>>
>> Thanks for looking into this.
>>
>> Yes, I am open for this approach and I think it may work. I can +
>> check the pci_config_window resource start address (cfg->res.start) to
>> figure out the controller and then get the fixed controller register
>> address or + using the domain number to identify the controller.
>
> First thing to do is to remove config space entry from PNP0A03
> _CRS, that's a FW bug.

Yes, I will remove it in the next version of firmware release.

>
> You could use the {bus-range, domain} to get that register address,
> anyway, that's not the main concern here.
>
> Thanks,
> Lorenzo
>
>> Regards,
>> Duc Dang.
>> >
>> > Supporting quirk workarounds for early, non-compliant hardware is
>> > helpful and perhaps necessary for bootstrapping the ecosystem in a
>> > timely manner. But we don't really want to provide an expandable or
>> > reusable interface that would make it easy 

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

[Duc Dang]

On Tue, Jun 21, 2016 at 2:26 AM, Lorenzo Pieralisi
 wrote:
> On Mon, Jun 20, 2016 at 12:12:24PM -0700, Duc Dang wrote:
>> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington
>>  wrote:
>> > Hi Duc,
>> >
>> > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote:
>> >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote:
>> >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi
>> >>>  wrote:
>>  On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote:
>> > From: Tomasz Nowicki 
>> >
>> > pci_generic_ecam_ops is used by default. Since there are platforms
>> > which have non-compliant ECAM space we need to overwrite these
>> > accessors prior to PCI buses enumeration. In order to do that
>> > we call pci_mcfg_get_ops to retrieve pci_ecam_ops structure so that
>> > we can use proper PCI config space accessors and bus_shift.
>> >
>> > pci_generic_ecam_ops is still used for platforms free from quirks.
>> >
>> > Signed-off-by: Tomasz Nowicki 
>> > ---
>> >  arch/arm64/kernel/pci.c | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> > index 94cd43c..a891bda 100644
>> > --- a/arch/arm64/kernel/pci.c
>> > +++ b/arch/arm64/kernel/pci.c
>> > @@ -139,6 +139,7 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> > *root)
>> >   struct pci_config_window *cfg;
>> >   struct resource cfgres;
>> >   unsigned int bsz;
>> > + struct pci_ecam_ops *ops;
>> >
>> >   /* Use address from _CBA if present, otherwise lookup MCFG */
>> >   if (!root->mcfg_addr)
>> > @@ -150,12 +151,12 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root 
>> > *root)
>> >   return NULL;
>> >   }
>> >
>> > - bsz = 1 << pci_generic_ecam_ops.bus_shift;
>> > + ops = pci_mcfg_get_ops(root);
>> > + bsz = 1 << ops->bus_shift;
>> >   cfgres.start = root->mcfg_addr + bus_res->start * bsz;
>> >   cfgres.end = cfgres.start + resource_size(bus_res) * bsz - 1;
>> >   cfgres.flags = IORESOURCE_MEM;
>> > - cfg = pci_ecam_create(>device->dev, , bus_res,
>> > -   _generic_ecam_ops);
>> > + cfg = pci_ecam_create(>device->dev, , bus_res, ops);
>> 
>>  Arnd pointed this out already, I think that's the only pending question
>>  here.
>> 
>>  pci_ecam_create() maps ECAM space for config regions retrieved from
>>  the MCFG, which are *supposed* to be ECAM compliant.
>> 
>>  Do we think that's *always* correct/safe regardless of the kind
>>  of quirk we are currently fixing up ?
>> 
>>  Or we do think that configuration space regions should come from
>>  a different resource declared in the ACPI namespace if the regions
>>  are not MCFG/ECAM compliant (ie config space is not defined through
>>  MCFG at all - possibly through a _CRS method for a vendor specific
>>  _HID under the PNP0A03 node ?)
>> >>>
>> >>> Hi Lorenzo,
>> >>>
>> >>> For X-Gene: the ECAM space is used to access the configuration space
>> >>> of PCIe devices, with additional help from controller register to
>> >>> specify the bus, device and function number. Below is the RFC patch
>> >>> that implements ECAM fixup for X-Gene PCIe controller on top of this
>> >>> RFC ECAM quirk v3 for your and others reference.
>> >>
>> >> Yes, you have an additional resource in the PNP0A03 _CRS to describe
>> >> your register that is a deliberate abuse of the ACPI standard in
>> >> that the _CRS is meant to describe resources that are passed on
>> >> to secondary buses
>> >
>> > A potential alternative came up in an off-list discussion: Would it be
>> > better to hard code the information in the quirk workaround than look it
>> > up from a repurposed ACPI resource?
>>
>> Hi Chris, Lorenzo,
>>
>> Thanks for looking into this.
>>
>> Yes, I am open for this approach and I think it may work. I can +
>> check the pci_config_window resource start address (cfg->res.start) to
>> figure out the controller and then get the fixed controller register
>> address or + using the domain number to identify the controller.
>
> First thing to do is to remove config space entry from PNP0A03
> _CRS, that's a FW bug.

Yes, I will remove it in the next version of firmware release.

>
> You could use the {bus-range, domain} to get that register address,
> anyway, that's not the main concern here.
>
> Thanks,
> Lorenzo
>
>> Regards,
>> Duc Dang.
>> >
>> > Supporting quirk workarounds for early, non-compliant hardware is
>> > helpful and perhaps necessary for bootstrapping the ecosystem in a
>> > timely manner. But we don't really want to provide an expandable or
>> > reusable interface that would make it easy for new hardware to remain
>> > non-compliant.
>> >
>> > Regards,
>> > Cov
>> >
>> > --
>> > Qualcomm Innovation 

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Jassi and Rafael,

On Wed, Jun 15, 2016 at 9:19 AM, Prakash, Prashanth
 wrote:
>
>
> On 6/9/2016 4:43 PM, Hoan Tran wrote:
>> Hi Prashanth,
>>
>> On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth
>>  wrote:
>>>
>>> On 6/9/2016 2:47 PM, Hoan Tran wrote:
 Hi Ashwin and Prashanth,

 On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
> Hi Prashanth,
>
>
> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>  wrote:
>> On 6/8/2016 10:24 AM, Hoan Tran wrote:
>>> Hi Ashwin,
>>>
>>> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>>>  wrote:
 + Prashanth (Can you please have a look as well?)

 On 31 May 2016 at 15:35, Hoan Tran  wrote:
> Hi Ashwin,
 Hi,

 Sorry about the delay. I'm in the middle of switching jobs and
 locations, so its been a bit crazy lately.
>>> It's ok and hope you're doing well.
>>>
 I dont have any major
 concerns with this code, although there could be subtle issues with
 this IRQ thing. In this patchset, your intent is to add support for
 PCC subspace type 2. But you're also adding support for tx command
 completion which is not specific to Type 2. We could support that even
 in Type 1. Hence I wanted to separate the two, not just for review,
 but also the async IRQ completion has subtle issues esp. in the case
 of async platform notification, where you could have a PCC client in
 the OS writing to the cmd bit and the platform sending an async
 notification by writing to some bits in the same 8byte address as the
 cmd bit. So we need some mutual exclusivity there, otherwise the OS
 and platform could step on each other. Perhaps Prashanth has better
 insight into this.
>>> I think, this mutual exclusivity could be in another patch.
>> Ashwin,
>> Sorry, I am not sure how we can prevent platform and OSPM from stepping 
>> on
>> each other.  There is a line is spec that says "all operations on status 
>> field
>> must be made using interlocked operations", but not sure what these
>> interlocked operation translates to.
> Yes, I had the same question about how to prevent it.
 For platform notification, if the hardware doesn't support interlocked
 operations. I think we can use a workaround that, platform triggers
 interrupt to OSPM without touching status field. The OSPM PCC client
 will decide what to do with this interrupt. For example, OSPM sends a
 consumer command to check it.
>>> How do we decide which platform can support this interlocked operation?
>>> and how do we decide between a completion notification and platform
>>> notification?
>> Truly, we should follow the specification. But I don't know if there's
>> any hardware support this interlocked operation.
>> For the decide between a completion notification and platform notification
>>  - Completion notification: Bit "Command Complete" is set.
>>  - Platform notification: Bit "Command Complete" is not set.
>>
>>> I think the ACPI spec on platform notification is quite ambiguous and it is
>>> best to get the necessary clarification and/or correction before 
>>> implementing
>>> anything related to platform notification.
>> Agreed, a clarification inside ACPI Specification is needed
> This patch look good to me, as it doesn't deal with platform notification.
> We can try to get some clarification from spec side before handling the 
> platform
> notification pieces.
>
> Reviewed-by: Prashanth Prakash 

Do you have plan to apply this patch ?

Thanks
Hoan

>
> Thanks,
> Prashanth
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kasan: make depot_fetch_stack more robust

[Kuthonuzo Luruo]

On Mon, Jul 4, 2016 at 8:11 PM, Andrey Ryabinin  wrote:
> 2016-07-01 20:38 GMT+03:00 Dmitry Vyukov :
>> I've hit a GPF in depot_fetch_stack when it was given
>> bogus stack handle. I think it was caused by a distant
>> out-of-bounds that hit a different object, as the result
>> we treated uninit garbage as stack handle. Maybe there is
>> something to fix in KASAN logic, but I think it makes
>> sense to make depot_fetch_stack more robust as well.
>>
>> Verify that the provided stack handle looks correct.
>>

> I don't think that adding the kernel code to work around bugs in the
> kernel code makes a lot of sense.
> depot_fetch_stack() fails if invalid handler is passed, and that is a
> bug. You can just add WARN_ON() in
> depot_fetch_stack() if you want to detect such cases..

In this case, the code happens to be a debugging tool that actively anticipates
bad memory accesses. If the tool can reliably detect bad input that could
potentially cause a crash inside the debugger itself, and take actions
to prevent it,
I believe that's a good thing.

> Note that KASAN detects corruption of object's metadata, so such check
> may help only in case of
> corruption page owner's data.

It will also help in case of bad access by non-instrumented code.

>
>> if (page_ext->last_migrate_reason != -1) {
>> ret += snprintf(kbuf + ret, count - ret,
>> @@ -307,12 +308,11 @@ void __dump_page_owner(struct page *page)
>> }
>>
>> handle = READ_ONCE(page_ext->handle);
>> -   if (!handle) {
>> +   if (!depot_fetch_stack(handle, )) {
>> pr_alert("page_owner info is not active (free page?)\n");
>> return;
>> }
>>
>> -   depot_fetch_stack(handle, );
>> pr_alert("page allocated via order %u, migratetype %s, gfp_mask 
>> %#x(%pGg)\n",
>>  page_ext->order, migratetype_names[mt], gfp_mask, 
>> _mask);
>> print_stack_trace(, 0);
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kasan-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kasan-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kasan-dev/CAPAsAGxj61%3DtrcAAPqODX1Z7vV%3D7-faG1oJBL5WCn%3DrBXAsvNA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

[Hoan Tran]

Hi Jassi and Rafael,

On Wed, Jun 15, 2016 at 9:19 AM, Prakash, Prashanth
 wrote:
>
>
> On 6/9/2016 4:43 PM, Hoan Tran wrote:
>> Hi Prashanth,
>>
>> On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth
>>  wrote:
>>>
>>> On 6/9/2016 2:47 PM, Hoan Tran wrote:
 Hi Ashwin and Prashanth,

 On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran  wrote:
> Hi Prashanth,
>
>
> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth
>  wrote:
>> On 6/8/2016 10:24 AM, Hoan Tran wrote:
>>> Hi Ashwin,
>>>
>>> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule
>>>  wrote:
 + Prashanth (Can you please have a look as well?)

 On 31 May 2016 at 15:35, Hoan Tran  wrote:
> Hi Ashwin,
 Hi,

 Sorry about the delay. I'm in the middle of switching jobs and
 locations, so its been a bit crazy lately.
>>> It's ok and hope you're doing well.
>>>
 I dont have any major
 concerns with this code, although there could be subtle issues with
 this IRQ thing. In this patchset, your intent is to add support for
 PCC subspace type 2. But you're also adding support for tx command
 completion which is not specific to Type 2. We could support that even
 in Type 1. Hence I wanted to separate the two, not just for review,
 but also the async IRQ completion has subtle issues esp. in the case
 of async platform notification, where you could have a PCC client in
 the OS writing to the cmd bit and the platform sending an async
 notification by writing to some bits in the same 8byte address as the
 cmd bit. So we need some mutual exclusivity there, otherwise the OS
 and platform could step on each other. Perhaps Prashanth has better
 insight into this.
>>> I think, this mutual exclusivity could be in another patch.
>> Ashwin,
>> Sorry, I am not sure how we can prevent platform and OSPM from stepping 
>> on
>> each other.  There is a line is spec that says "all operations on status 
>> field
>> must be made using interlocked operations", but not sure what these
>> interlocked operation translates to.
> Yes, I had the same question about how to prevent it.
 For platform notification, if the hardware doesn't support interlocked
 operations. I think we can use a workaround that, platform triggers
 interrupt to OSPM without touching status field. The OSPM PCC client
 will decide what to do with this interrupt. For example, OSPM sends a
 consumer command to check it.
>>> How do we decide which platform can support this interlocked operation?
>>> and how do we decide between a completion notification and platform
>>> notification?
>> Truly, we should follow the specification. But I don't know if there's
>> any hardware support this interlocked operation.
>> For the decide between a completion notification and platform notification
>>  - Completion notification: Bit "Command Complete" is set.
>>  - Platform notification: Bit "Command Complete" is not set.
>>
>>> I think the ACPI spec on platform notification is quite ambiguous and it is
>>> best to get the necessary clarification and/or correction before 
>>> implementing
>>> anything related to platform notification.
>> Agreed, a clarification inside ACPI Specification is needed
> This patch look good to me, as it doesn't deal with platform notification.
> We can try to get some clarification from spec side before handling the 
> platform
> notification pieces.
>
> Reviewed-by: Prashanth Prakash 

Do you have plan to apply this patch ?

Thanks
Hoan

>
> Thanks,
> Prashanth
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kasan: make depot_fetch_stack more robust

[Kuthonuzo Luruo]

On Mon, Jul 4, 2016 at 8:11 PM, Andrey Ryabinin  wrote:
> 2016-07-01 20:38 GMT+03:00 Dmitry Vyukov :
>> I've hit a GPF in depot_fetch_stack when it was given
>> bogus stack handle. I think it was caused by a distant
>> out-of-bounds that hit a different object, as the result
>> we treated uninit garbage as stack handle. Maybe there is
>> something to fix in KASAN logic, but I think it makes
>> sense to make depot_fetch_stack more robust as well.
>>
>> Verify that the provided stack handle looks correct.
>>

> I don't think that adding the kernel code to work around bugs in the
> kernel code makes a lot of sense.
> depot_fetch_stack() fails if invalid handler is passed, and that is a
> bug. You can just add WARN_ON() in
> depot_fetch_stack() if you want to detect such cases..

In this case, the code happens to be a debugging tool that actively anticipates
bad memory accesses. If the tool can reliably detect bad input that could
potentially cause a crash inside the debugger itself, and take actions
to prevent it,
I believe that's a good thing.

> Note that KASAN detects corruption of object's metadata, so such check
> may help only in case of
> corruption page owner's data.

It will also help in case of bad access by non-instrumented code.

>
>> if (page_ext->last_migrate_reason != -1) {
>> ret += snprintf(kbuf + ret, count - ret,
>> @@ -307,12 +308,11 @@ void __dump_page_owner(struct page *page)
>> }
>>
>> handle = READ_ONCE(page_ext->handle);
>> -   if (!handle) {
>> +   if (!depot_fetch_stack(handle, )) {
>> pr_alert("page_owner info is not active (free page?)\n");
>> return;
>> }
>>
>> -   depot_fetch_stack(handle, );
>> pr_alert("page allocated via order %u, migratetype %s, gfp_mask 
>> %#x(%pGg)\n",
>>  page_ext->order, migratetype_names[mt], gfp_mask, 
>> _mask);
>> print_stack_trace(, 0);
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kasan-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kasan-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kasan-dev/CAPAsAGxj61%3DtrcAAPqODX1Z7vV%3D7-faG1oJBL5WCn%3DrBXAsvNA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

[Duc Dang]

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington
 wrote:
> Hi Tomasz,
>
> On 06/28/2016 03:54 AM, Tomasz Nowicki wrote:
>
>> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
>> new file mode 100644
>> index 000..fb2b184
>> --- /dev/null
>> +++ b/drivers/pci/host/mcfg-quirks.c
>> @@ -0,0 +1,88 @@
>
>> +static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
>> +  struct acpi_table_header *mcfg_header)
>> +{
>> + int olen = min_t(u8, strlen(f->oem_id), ACPI_OEM_ID_SIZE);
>> + int tlen = min_t(u8, strlen(f->oem_table_id), ACPI_OEM_TABLE_ID_SIZE);
>> +
>> + return (!strncmp(f->oem_id, mcfg_header->oem_id, olen) &&
>> + !strncmp(f->oem_table_id, mcfg_header->oem_table_id, tlen) &&
>> + f->oem_revision == mcfg_header->oem_revision);
>> +}
>
> Ard's comments on v3 included:
>
> "... exact OEM table/rev id matches ..."
> "... substring match ... out of the question ..."
>
> I originally advocated the substring match approach because
> space-padding the input strings was unfamiliar. But given that some
> vendors have a "PLAT" then "PLAT2   " naming scheme, where the
> former needs quirks and the latter (hopefully) doesn't, I agree with Ard
> and think space-padded inputs is the better way to go. Sorry for the
> lack of foresight.

I think having OEM Table ID as "PLAT   " and then "PLAT2  " (the the
next version of the SoC)
is common. So yes, matching full string is better as we can use "PLAT2  "
in MCFG table and not worry about the "PLAT" sub-string match causes the quirk
to be applied unintentionally.

>
> (I'm happy to rip it out, test, and communicate the delta however you'd
> prefer--just let me know.)
>
> Regards,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
Regards,
Duc Dang.

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

[Duc Dang]

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington
 wrote:
> Hi Tomasz,
>
> On 06/28/2016 03:54 AM, Tomasz Nowicki wrote:
>
>> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
>> new file mode 100644
>> index 000..fb2b184
>> --- /dev/null
>> +++ b/drivers/pci/host/mcfg-quirks.c
>> @@ -0,0 +1,88 @@
>
>> +static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
>> +  struct acpi_table_header *mcfg_header)
>> +{
>> + int olen = min_t(u8, strlen(f->oem_id), ACPI_OEM_ID_SIZE);
>> + int tlen = min_t(u8, strlen(f->oem_table_id), ACPI_OEM_TABLE_ID_SIZE);
>> +
>> + return (!strncmp(f->oem_id, mcfg_header->oem_id, olen) &&
>> + !strncmp(f->oem_table_id, mcfg_header->oem_table_id, tlen) &&
>> + f->oem_revision == mcfg_header->oem_revision);
>> +}
>
> Ard's comments on v3 included:
>
> "... exact OEM table/rev id matches ..."
> "... substring match ... out of the question ..."
>
> I originally advocated the substring match approach because
> space-padding the input strings was unfamiliar. But given that some
> vendors have a "PLAT" then "PLAT2   " naming scheme, where the
> former needs quirks and the latter (hopefully) doesn't, I agree with Ard
> and think space-padded inputs is the better way to go. Sorry for the
> lack of foresight.

I think having OEM Table ID as "PLAT   " and then "PLAT2  " (the the
next version of the SoC)
is common. So yes, matching full string is better as we can use "PLAT2  "
in MCFG table and not worry about the "PLAT" sub-string match causes the quirk
to be applied unintentionally.

>
> (I'm happy to rip it out, test, and communicate the delta however you'd
> prefer--just let me know.)
>
> Regards,
> Cov
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
Regards,
Duc Dang.

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

[Hoan Tran]

On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule
 wrote:
>
> On 27 May 2016 at 12:41, Hoan Tran  wrote:
> > Hi Ashwin,
>
> Hi,
>
> >
> > Yes, I saw kernel crash.
> > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then
> > crash during cppc_get_perf_caps() access CPPC shared memory.
> >
> > It's not only "PCC channel request fail" can create this issue but
> > "acpi_get_psd() fail" also creates it
> >
> > Thanks
> > Hoan
>
>
> Just for future reference. :)
>
> https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
>
>
> >
> > On Fri, May 27, 2016 at 9:10 AM, Ashwin Chaugule
> >  wrote:
> >> On 25 May 2016 at 15:09, Hoan Tran  wrote:
> >>> When CPPC fails to request PCC channel, the CPC data is freed
> >>> and cpc_desc_ptr points to the invalid data. This change prevents
> >>> this issue by moving cpc_desc_ptr assignment after PCC channel
> >>> request.
> >>>
> >>> Signed-off-by: Hoan Tran 
> >>> ---
> >>>  drivers/acpi/cppc_acpi.c | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> >>> index 8adac69..85fd8f7 100644
> >>> --- a/drivers/acpi/cppc_acpi.c
> >>> +++ b/drivers/acpi/cppc_acpi.c
> >>> @@ -595,9 +595,6 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> >>> *pr)
> >>> /* Store CPU Logical ID */
> >>> cpc_ptr->cpu_id = pr->id;
> >>>
> >>> -   /* Plug it into this CPUs CPC descriptor. */
> >>> -   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> >>> -
> >>> /* Parse PSD data for this CPU */
> >>> ret = acpi_get_psd(cpc_ptr, handle);
> >>> if (ret)
> >>> @@ -610,6 +607,9 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> >>> *pr)
> >>> goto out_free;
> >>> }
> >>>
> >>> +   /* Plug PSD data into this CPUs CPC descriptor. */
> >>> +   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> >>> +
> >>
> >> Are you seeing a real problem without this change? I'm missing where
> >> this pointer is dereferenced if the PCC channel request fails.
> >>
>
> So, after freeing the cpc_ptr, we need to NULL the per-cpu pointer as
> well. Alternately, not assign it until everything passes and rely on
> the static declaration, which is the path you've taken here.
>
> Acked-by: Ashwin Chaugule 

Hi Rafael,

Do you have plan to apply this patch ?

Thanks
Hoan

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

[Hoan Tran]

On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule
 wrote:
>
> On 27 May 2016 at 12:41, Hoan Tran  wrote:
> > Hi Ashwin,
>
> Hi,
>
> >
> > Yes, I saw kernel crash.
> > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then
> > crash during cppc_get_perf_caps() access CPPC shared memory.
> >
> > It's not only "PCC channel request fail" can create this issue but
> > "acpi_get_psd() fail" also creates it
> >
> > Thanks
> > Hoan
>
>
> Just for future reference. :)
>
> https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
>
>
> >
> > On Fri, May 27, 2016 at 9:10 AM, Ashwin Chaugule
> >  wrote:
> >> On 25 May 2016 at 15:09, Hoan Tran  wrote:
> >>> When CPPC fails to request PCC channel, the CPC data is freed
> >>> and cpc_desc_ptr points to the invalid data. This change prevents
> >>> this issue by moving cpc_desc_ptr assignment after PCC channel
> >>> request.
> >>>
> >>> Signed-off-by: Hoan Tran 
> >>> ---
> >>>  drivers/acpi/cppc_acpi.c | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> >>> index 8adac69..85fd8f7 100644
> >>> --- a/drivers/acpi/cppc_acpi.c
> >>> +++ b/drivers/acpi/cppc_acpi.c
> >>> @@ -595,9 +595,6 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> >>> *pr)
> >>> /* Store CPU Logical ID */
> >>> cpc_ptr->cpu_id = pr->id;
> >>>
> >>> -   /* Plug it into this CPUs CPC descriptor. */
> >>> -   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> >>> -
> >>> /* Parse PSD data for this CPU */
> >>> ret = acpi_get_psd(cpc_ptr, handle);
> >>> if (ret)
> >>> @@ -610,6 +607,9 @@ int acpi_cppc_processor_probe(struct acpi_processor 
> >>> *pr)
> >>> goto out_free;
> >>> }
> >>>
> >>> +   /* Plug PSD data into this CPUs CPC descriptor. */
> >>> +   per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
> >>> +
> >>
> >> Are you seeing a real problem without this change? I'm missing where
> >> this pointer is dereferenced if the PCC channel request fails.
> >>
>
> So, after freeing the cpc_ptr, we need to NULL the per-cpu pointer as
> well. Alternately, not assign it until everything passes and rely on
> the static declaration, which is the path you've taken here.
>
> Acked-by: Ashwin Chaugule 

Hi Rafael,

Do you have plan to apply this patch ?

Thanks
Hoan

[PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

Exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
declarations into a pcc.h header file.

v2
 * Introduce pcc.h header file for pcc client methods

v1
 * Initial

Signed-off-by: Hoan Tran 
---
 include/acpi/cppc_acpi.h |  7 +--
 include/acpi/pcc.h   | 29 +
 2 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100644 include/acpi/pcc.h

diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 259683a..ab1da43 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -15,10 +15,9 @@
 #define _CPPC_ACPI_H
 
 #include 
-#include 
-#include 
 #include 
 
+#include 
 #include 
 
 /* Only support CPPCv2 for now. */
@@ -131,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
*perf_ctrls);
 extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
 extern int acpi_get_psd_map(struct cpudata **);
 
-/* Methods to interact with the PCC mailbox controller. */
-extern struct mbox_chan *
-   pcc_mbox_request_channel(struct mbox_client *, unsigned int);
-
 #endif /* _CPPC_ACPI_H*/
diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h
new file mode 100644
index 000..17a940a
--- /dev/null
+++ b/include/acpi/pcc.h
@@ -0,0 +1,29 @@
+/*
+ * PCC (Platform Communications Channel) methods
+ *
+ * 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
+ * of the License.
+ */
+
+#ifndef _PCC_H
+#define _PCC_H
+
+#include 
+#include 
+
+#ifdef CONFIG_PCC
+extern struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
+ int subspace_id);
+extern void pcc_mbox_free_channel(struct mbox_chan *chan);
+#else
+static inline struct mbox_chan *pcc_mbox_request_channel(struct mbox_client 
*cl,
+int subspace_id)
+{
+   return NULL;
+}
+static inline void pcc_mbox_free_channel(struct mbox_chan *chan) { }
+#endif
+
+#endif /* _PCC_H */
-- 
1.9.1

[PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

[Hoan Tran]

Exports pcc_mbox_request_channel() and pcc_mbox_free_channel()
declarations into a pcc.h header file.

v2
 * Introduce pcc.h header file for pcc client methods

v1
 * Initial

Signed-off-by: Hoan Tran 
---
 include/acpi/cppc_acpi.h |  7 +--
 include/acpi/pcc.h   | 29 +
 2 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100644 include/acpi/pcc.h

diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 259683a..ab1da43 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -15,10 +15,9 @@
 #define _CPPC_ACPI_H
 
 #include 
-#include 
-#include 
 #include 
 
+#include 
 #include 
 
 /* Only support CPPCv2 for now. */
@@ -131,8 +130,4 @@ extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls 
*perf_ctrls);
 extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
 extern int acpi_get_psd_map(struct cpudata **);
 
-/* Methods to interact with the PCC mailbox controller. */
-extern struct mbox_chan *
-   pcc_mbox_request_channel(struct mbox_client *, unsigned int);
-
 #endif /* _CPPC_ACPI_H*/
diff --git a/include/acpi/pcc.h b/include/acpi/pcc.h
new file mode 100644
index 000..17a940a
--- /dev/null
+++ b/include/acpi/pcc.h
@@ -0,0 +1,29 @@
+/*
+ * PCC (Platform Communications Channel) methods
+ *
+ * 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
+ * of the License.
+ */
+
+#ifndef _PCC_H
+#define _PCC_H
+
+#include 
+#include 
+
+#ifdef CONFIG_PCC
+extern struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
+ int subspace_id);
+extern void pcc_mbox_free_channel(struct mbox_chan *chan);
+#else
+static inline struct mbox_chan *pcc_mbox_request_channel(struct mbox_client 
*cl,
+int subspace_id)
+{
+   return NULL;
+}
+static inline void pcc_mbox_free_channel(struct mbox_chan *chan) { }
+#endif
+
+#endif /* _PCC_H */
-- 
1.9.1

RE: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> Sent: Thursday, June 30, 2016 23:59
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index b5cc5a6..0b68b58 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -202,8 +202,9 @@ struct ucred {
>  #define AF_VSOCK 40  /* vSockets */
>  #define AF_KCM   41  /* Kernel Connection Multiplexor*/
>  #define AF_QIPCRTR   42  /* Qualcomm IPC Router  */
> +#define AF_HYPERV43  /* Hyper-V Sockets  */
> 
> -#define AF_MAX   43  /* For now.. */
> +#define AF_MAX   44  /* For now.. */

Hi David,
Not sure if you had a chance to review this version.
Now I have a question: may I split the include/linux/socket.h change
and ask you to pre-allocate the number for AF_HYPERV to allow
backporting of Hyper-V Sockets to distro kernels, and to make sure that
applications using the socket type will work with the backport as well
as the upstream kernel?

Thanks,
-- Dexuan

RE: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> Sent: Thursday, June 30, 2016 23:59
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index b5cc5a6..0b68b58 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -202,8 +202,9 @@ struct ucred {
>  #define AF_VSOCK 40  /* vSockets */
>  #define AF_KCM   41  /* Kernel Connection Multiplexor*/
>  #define AF_QIPCRTR   42  /* Qualcomm IPC Router  */
> +#define AF_HYPERV43  /* Hyper-V Sockets  */
> 
> -#define AF_MAX   43  /* For now.. */
> +#define AF_MAX   44  /* For now.. */

Hi David,
Not sure if you had a chance to review this version.
Now I have a question: may I split the include/linux/socket.h change
and ask you to pre-allocate the number for AF_HYPERV to allow
backporting of Hyper-V Sockets to distro kernels, and to make sure that
applications using the socket type will work with the backport as well
as the upstream kernel?

Thanks,
-- Dexuan

Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

[Florian Fainelli]

Le 04/07/2016 16:03, David Miller a écrit :
> From: Philippe Reynes 
> Date: Sun,  3 Jul 2016 17:33:57 +0200
> 
>> There are two generics functions phy_ethtool_{get|set}_link_ksettings,
>> so we can use them instead of defining the same code in the driver.
>>
>> Signed-off-by: Philippe Reynes 
> 
> Applied.
> 

The transformation is not equivalent, we lost the checks on
netif_running() in the process, and those are here for a reason, if the
interface is down and therefore clock gated, MDIO accesses to the PHY
will simply fail outright and cause bus errors.

Philippe, have you tested this?
-- 
Florian

Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

[Florian Fainelli]

Le 04/07/2016 16:03, David Miller a écrit :
> From: Philippe Reynes 
> Date: Sun,  3 Jul 2016 17:33:57 +0200
> 
>> There are two generics functions phy_ethtool_{get|set}_link_ksettings,
>> so we can use them instead of defining the same code in the driver.
>>
>> Signed-off-by: Philippe Reynes 
> 
> Applied.
> 

The transformation is not equivalent, we lost the checks on
netif_running() in the process, and those are here for a reason, if the
interface is down and therefore clock gated, MDIO accesses to the PHY
will simply fail outright and cause bus errors.

Philippe, have you tested this?
-- 
Florian