Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)

[Mimi Zohar]

On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar  wrote:
> >
> > To resolve this locking problem, this patch defines a new
> > ->integrity_read file operation method, which is equivalent to
> > ->read_iter, except that it will not take the i_rwsem lock, but will
> > be called with the i_rwsem held exclusively.
> >
> > Since taking the i_rwsem exclusively is not required for reading the
> > file in order to calculate the file hash, the code only verifies
> > that the lock has been taken.
> 
> Ok, so I'm onboard with the commit message now, but realized that I'm
> not actually convinced that i_rwsem is even meaningful.
> 
> Sure, generic_file_write_iter() does take that lock exclusively, but
> not everybody uses generic_file_write_iter() at all for writing.

> For example, xfs still uses that i_rwsem, but for block-aligned writes
> it will only get it shared. And I'm not convinced some other
> filesystem might not end up using some other lock entirely.
> 
> So I'm basically not entirely convinced that these i_rwsem games make
> any sense at all.
> 
> The filesystem can do its own locking, and I'm starting to think that
> it would be better to just pass this "this is an integrity read" down
> to the filesystem, and expect the filesystem to do the locking based
> on that.

IMA would still need to take the i_rwsem to write the xattr.  Unless
the i_rwsem was taken before calling the integrity_read, calculating
the file hash would be serialized, but would not prevent the file hash
from being calculated multiple times.

(Introducing a new lock would result in the locks being taken in
reverse order for setxattr, chown, chmod syscalls.)

Mimi

Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)

[Mimi Zohar]

On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar  wrote:
> >
> > To resolve this locking problem, this patch defines a new
> > ->integrity_read file operation method, which is equivalent to
> > ->read_iter, except that it will not take the i_rwsem lock, but will
> > be called with the i_rwsem held exclusively.
> >
> > Since taking the i_rwsem exclusively is not required for reading the
> > file in order to calculate the file hash, the code only verifies
> > that the lock has been taken.
> 
> Ok, so I'm onboard with the commit message now, but realized that I'm
> not actually convinced that i_rwsem is even meaningful.
> 
> Sure, generic_file_write_iter() does take that lock exclusively, but
> not everybody uses generic_file_write_iter() at all for writing.

> For example, xfs still uses that i_rwsem, but for block-aligned writes
> it will only get it shared. And I'm not convinced some other
> filesystem might not end up using some other lock entirely.
> 
> So I'm basically not entirely convinced that these i_rwsem games make
> any sense at all.
> 
> The filesystem can do its own locking, and I'm starting to think that
> it would be better to just pass this "this is an integrity read" down
> to the filesystem, and expect the filesystem to do the locking based
> on that.

IMA would still need to take the i_rwsem to write the xattr.  Unless
the i_rwsem was taken before calling the integrity_read, calculating
the file hash would be serialized, but would not prevent the file hash
from being calculated multiple times.

(Introducing a new lock would result in the locks being taken in
reverse order for setxattr, chown, chmod syscalls.)

Mimi

Re: rcu kernel-doc issues (4.14-rc1)

[Paul E. McKenney]

On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote:
> On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc:
> 
> .. kernel-doc:: include/linux/rcupdate.h
>:external:
> ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".

$ grep external include/linux/rcupdate.h
 * by a single external-to-structure RCU-protected pointer, then you may
 * external-to-structure pointer -after- you have completely initialized

Do these comments somehow qualify as an "external" option?  If so, how
do I tell kernel-doc to ignore them?  Or must I reword them to avoid
the word "external"?

> .. kernel-doc:: include/linux/rcupdate_wait.h
>:external:
> ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".

$ grep external include/linux/rcupdate_wait.h

There is no occurrence of the string "external" in this file.  So this
"external" option is unknown to me as well.  So, any hints on how I
should interpret these error messages?

Thanx, Paul

> .. kernel-doc:: include/linux/rcutree.h
>:external:
> ./Documentation/core-api/kernel-api.rst:363: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree.c
>:external:
> ./Documentation/core-api/kernel-api.rst:366: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree_plugin.h
>:external:
> ./Documentation/core-api/kernel-api.rst:369: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree_exp.h
>:external:
> ./Documentation/core-api/kernel-api.rst:372: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/update.c
>:external:
> ./Documentation/core-api/kernel-api.rst:375: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/srcu.h
>:external:
> ./Documentation/core-api/kernel-api.rst:378: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/srcutree.c
>:external:
> ./Documentation/core-api/kernel-api.rst:381: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist_bl.h
>:external:
> ./Documentation/core-api/kernel-api.rst:384: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist.h
>:external:
> ./Documentation/core-api/kernel-api.rst:387: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist_nulls.h
>:external:
> ./Documentation/core-api/kernel-api.rst:390: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rcu_sync.h
>:external:
> ./Documentation/core-api/kernel-api.rst:393: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/sync.c
>:external:
> 
> ../kernel/rcu/tree.c:3091: ERROR: Unexpected indentation.
> ../kernel/rcu/tree.c:3118: ERROR: Unexpected indentation.
> ../kernel/rcu/tree.c:3119: WARNING: Bullet list ends without a blank line; 
> unexpected unindent.
> 
> 
> -- 
> ~Randy
> 

Re: rcu kernel-doc issues (4.14-rc1)

[Paul E. McKenney]

On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote:
> On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc:
> 
> .. kernel-doc:: include/linux/rcupdate.h
>:external:
> ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".

$ grep external include/linux/rcupdate.h
 * by a single external-to-structure RCU-protected pointer, then you may
 * external-to-structure pointer -after- you have completely initialized

Do these comments somehow qualify as an "external" option?  If so, how
do I tell kernel-doc to ignore them?  Or must I reword them to avoid
the word "external"?

> .. kernel-doc:: include/linux/rcupdate_wait.h
>:external:
> ./Documentation/core-api/kernel-api.rst:360: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".

$ grep external include/linux/rcupdate_wait.h

There is no occurrence of the string "external" in this file.  So this
"external" option is unknown to me as well.  So, any hints on how I
should interpret these error messages?

Thanx, Paul

> .. kernel-doc:: include/linux/rcutree.h
>:external:
> ./Documentation/core-api/kernel-api.rst:363: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree.c
>:external:
> ./Documentation/core-api/kernel-api.rst:366: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree_plugin.h
>:external:
> ./Documentation/core-api/kernel-api.rst:369: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/tree_exp.h
>:external:
> ./Documentation/core-api/kernel-api.rst:372: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/update.c
>:external:
> ./Documentation/core-api/kernel-api.rst:375: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/srcu.h
>:external:
> ./Documentation/core-api/kernel-api.rst:378: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/srcutree.c
>:external:
> ./Documentation/core-api/kernel-api.rst:381: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist_bl.h
>:external:
> ./Documentation/core-api/kernel-api.rst:384: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist.h
>:external:
> ./Documentation/core-api/kernel-api.rst:387: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rculist_nulls.h
>:external:
> ./Documentation/core-api/kernel-api.rst:390: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: include/linux/rcu_sync.h
>:external:
> ./Documentation/core-api/kernel-api.rst:393: ERROR: Error in "kernel-doc" 
> directive:
> unknown option: "external".
> 
> .. kernel-doc:: kernel/rcu/sync.c
>:external:
> 
> ../kernel/rcu/tree.c:3091: ERROR: Unexpected indentation.
> ../kernel/rcu/tree.c:3118: ERROR: Unexpected indentation.
> ../kernel/rcu/tree.c:3119: WARNING: Bullet list ends without a blank line; 
> unexpected unindent.
> 
> 
> -- 
> ~Randy
> 

[PATCH 06/10] powerpc/vas: Reduce polling interval for busy state

[Sukadev Bhattiprolu]

A VAS window is normally in "busy" state for only a short duration.
Reduce the time we wait for the window to go to "not-busy" state to
speed-up vas_win_close() a bit.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 95622a9..1422cdd 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1060,21 +1060,23 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
 }
 EXPORT_SYMBOL_GPL(vas_paste_crb);
 
+/*
+ * Wait for the window to go to "not-busy" state. It should only take a
+ * short time to queue a CRB, so window should not be busy for too long.
+ * Trying 5ms intervals.
+ */
 static void poll_window_busy_state(struct vas_window *window)
 {
int busy;
u64 val;
 
 retry:
-   /*
-* Poll Window Busy flag
-*/
val = read_hvwc_reg(window, VREG(WIN_STATUS));
busy = GET_FIELD(VAS_WIN_BUSY, val);
if (busy) {
val = 0;
set_current_state(TASK_UNINTERRUPTIBLE);
-   schedule_timeout(HZ);
+   schedule_timeout(msecs_to_jiffies(5));
goto retry;
}
 }
-- 
2.7.4

[PATCH 06/10] powerpc/vas: Reduce polling interval for busy state

[Sukadev Bhattiprolu]

A VAS window is normally in "busy" state for only a short duration.
Reduce the time we wait for the window to go to "not-busy" state to
speed-up vas_win_close() a bit.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 95622a9..1422cdd 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1060,21 +1060,23 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
 }
 EXPORT_SYMBOL_GPL(vas_paste_crb);
 
+/*
+ * Wait for the window to go to "not-busy" state. It should only take a
+ * short time to queue a CRB, so window should not be busy for too long.
+ * Trying 5ms intervals.
+ */
 static void poll_window_busy_state(struct vas_window *window)
 {
int busy;
u64 val;
 
 retry:
-   /*
-* Poll Window Busy flag
-*/
val = read_hvwc_reg(window, VREG(WIN_STATUS));
busy = GET_FIELD(VAS_WIN_BUSY, val);
if (busy) {
val = 0;
set_current_state(TASK_UNINTERRUPTIBLE);
-   schedule_timeout(HZ);
+   schedule_timeout(msecs_to_jiffies(5));
goto retry;
}
 }
-- 
2.7.4

[PATCH 07/10] powerpc/vas: Save configured window credits

[Sukadev Bhattiprolu]

Save the configured max window credits for a window in the vas_window
structure. We will need this when polling for return of window credits.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 --
 arch/powerpc/platforms/powernv/vas.h| 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 1422cdd..a59a187 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -674,7 +674,7 @@ static void init_winctx_for_rxwin(struct vas_window *rxwin,
 
winctx->rx_fifo = rxattr->rx_fifo;
winctx->rx_fifo_size = rxattr->rx_fifo_size;
-   winctx->wcreds_max = rxattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
+   winctx->wcreds_max = rxwin->wcreds_max;
winctx->pin_win = rxattr->pin_win;
 
winctx->nx_win = rxattr->nx_win;
@@ -844,6 +844,7 @@ struct vas_window *vas_rx_win_open(int vasid, enum 
vas_cop_type cop,
rxwin->nx_win = rxattr->nx_win;
rxwin->user_win = rxattr->user_win;
rxwin->cop = cop;
+   rxwin->wcreds_max = rxattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
if (rxattr->user_win)
rxwin->pid = task_pid_vnr(current);
 
@@ -893,7 +894,7 @@ static void init_winctx_for_txwin(struct vas_window *txwin,
 */
memset(winctx, 0, sizeof(struct vas_winctx));
 
-   winctx->wcreds_max = txattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
+   winctx->wcreds_max = txwin->wcreds_max;
 
winctx->user_win = txattr->user_win;
winctx->nx_win = txwin->rxwin->nx_win;
@@ -978,6 +979,7 @@ struct vas_window *vas_tx_win_open(int vasid, enum 
vas_cop_type cop,
txwin->nx_win = txwin->rxwin->nx_win;
txwin->pid = attr->pid;
txwin->user_win = attr->user_win;
+   txwin->wcreds_max = attr->wcreds_max ?: VAS_WCREDS_DEFAULT;
 
init_winctx_for_txwin(txwin, attr, );
 
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 15d2dfa..ad906f6 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -332,6 +332,7 @@ struct vas_window {
void *hvwc_map; /* HV window context */
void *uwc_map;  /* OS/User window context */
pid_t pid;  /* Linux process id of owner */
+   int wcreds_max; /* Window credits */
 
/* Fields applicable only to send windows */
void *paste_kaddr;
-- 
2.7.4

[PATCH 00/10] powerpc/vas: cleanup and optimizations

[Sukadev Bhattiprolu]

Sanitize cpu/chip id to VAS id mapping, improve vas_win_close()
performance and add a check for return of credits.

Also, fix up couple of initializations/error checks and cleanup
some comments and debug code.

Sukadev Bhattiprolu (10):
  powerpc/vas: init missing fields from [rt]xattr
  powerpc/vas: Validate window credits
  powerpc/vas: Cleanup some debug code
  powerpc/vas: Drop poll_window_cast_out().
  powerpc/vas: Use helper to unpin/close window
  powerpc/vas: Reduce polling interval for busy state
  powerpc/vas: Save configured window credits
  powerpc/vas: poll for return of window credits
  powerpc/vas: Create cpu to vas id mapping
  powerpc/vas, nx-842: Define and use chip_to_vas_id()

 arch/powerpc/include/asm/vas.h  |   9 ++
 arch/powerpc/platforms/powernv/vas-window.c | 133 +---
 arch/powerpc/platforms/powernv/vas.c|  25 +-
 arch/powerpc/platforms/powernv/vas.h|  61 -
 drivers/crypto/nx/nx-842-powernv.c  |  18 +---
 5 files changed, 154 insertions(+), 92 deletions(-)

-- 
2.7.4

[PATCH 02/10] powerpc/vas: Validate window credits

[Sukadev Bhattiprolu]

NX-842, the only user of VAS, sets the window credits to default values
but VAS should check the credits against the possible max values.

The VAS_WCREDS_MIN is not needed and can be dropped.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 ++
 arch/powerpc/platforms/powernv/vas.h| 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index cec7ab7..a2fe120 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -738,6 +738,9 @@ static bool rx_win_args_valid(enum vas_cop_type cop,
if (attr->rx_fifo_size > VAS_RX_FIFO_SIZE_MAX)
return false;
 
+   if (attr->wcreds_max > VAS_RX_WCREDS_MAX)
+   return false;
+
if (attr->nx_win) {
/* cannot be fault or user window if it is nx */
if (attr->fault_win || attr->user_win)
@@ -927,6 +930,9 @@ static bool tx_win_args_valid(enum vas_cop_type cop,
if (cop > VAS_COP_TYPE_MAX)
return false;
 
+   if (attr->wcreds_max > VAS_TX_WCREDS_MAX)
+   return false;
+
if (attr->user_win &&
(cop != VAS_COP_TYPE_FTW || attr->rsvd_txbuf_count))
return false;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 38dee5d..fea0de4 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -106,8 +106,8 @@
  *
  * TODO: Needs tuning for per-process credits
  */
-#define VAS_WCREDS_MIN 16
-#define VAS_WCREDS_MAX ((64 << 10) - 1)
+#define VAS_RX_WCREDS_MAX  ((64 << 10) - 1)
+#define VAS_TX_WCREDS_MAX  ((4 << 10) - 1)
 #define VAS_WCREDS_DEFAULT (1 << 10)
 
 /*
-- 
2.7.4

[PATCH 00/10] powerpc/vas: cleanup and optimizations

[Sukadev Bhattiprolu]

Sanitize cpu/chip id to VAS id mapping, improve vas_win_close()
performance and add a check for return of credits.

Also, fix up couple of initializations/error checks and cleanup
some comments and debug code.

Sukadev Bhattiprolu (10):
  powerpc/vas: init missing fields from [rt]xattr
  powerpc/vas: Validate window credits
  powerpc/vas: Cleanup some debug code
  powerpc/vas: Drop poll_window_cast_out().
  powerpc/vas: Use helper to unpin/close window
  powerpc/vas: Reduce polling interval for busy state
  powerpc/vas: Save configured window credits
  powerpc/vas: poll for return of window credits
  powerpc/vas: Create cpu to vas id mapping
  powerpc/vas, nx-842: Define and use chip_to_vas_id()

 arch/powerpc/include/asm/vas.h  |   9 ++
 arch/powerpc/platforms/powernv/vas-window.c | 133 +---
 arch/powerpc/platforms/powernv/vas.c|  25 +-
 arch/powerpc/platforms/powernv/vas.h|  61 -
 drivers/crypto/nx/nx-842-powernv.c  |  18 +---
 5 files changed, 154 insertions(+), 92 deletions(-)

-- 
2.7.4

[PATCH 02/10] powerpc/vas: Validate window credits

[Sukadev Bhattiprolu]

NX-842, the only user of VAS, sets the window credits to default values
but VAS should check the credits against the possible max values.

The VAS_WCREDS_MIN is not needed and can be dropped.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 ++
 arch/powerpc/platforms/powernv/vas.h| 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index cec7ab7..a2fe120 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -738,6 +738,9 @@ static bool rx_win_args_valid(enum vas_cop_type cop,
if (attr->rx_fifo_size > VAS_RX_FIFO_SIZE_MAX)
return false;
 
+   if (attr->wcreds_max > VAS_RX_WCREDS_MAX)
+   return false;
+
if (attr->nx_win) {
/* cannot be fault or user window if it is nx */
if (attr->fault_win || attr->user_win)
@@ -927,6 +930,9 @@ static bool tx_win_args_valid(enum vas_cop_type cop,
if (cop > VAS_COP_TYPE_MAX)
return false;
 
+   if (attr->wcreds_max > VAS_TX_WCREDS_MAX)
+   return false;
+
if (attr->user_win &&
(cop != VAS_COP_TYPE_FTW || attr->rsvd_txbuf_count))
return false;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 38dee5d..fea0de4 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -106,8 +106,8 @@
  *
  * TODO: Needs tuning for per-process credits
  */
-#define VAS_WCREDS_MIN 16
-#define VAS_WCREDS_MAX ((64 << 10) - 1)
+#define VAS_RX_WCREDS_MAX  ((64 << 10) - 1)
+#define VAS_TX_WCREDS_MAX  ((4 << 10) - 1)
 #define VAS_WCREDS_DEFAULT (1 << 10)
 
 /*
-- 
2.7.4

[PATCH 07/10] powerpc/vas: Save configured window credits

[Sukadev Bhattiprolu]

Save the configured max window credits for a window in the vas_window
structure. We will need this when polling for return of window credits.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 --
 arch/powerpc/platforms/powernv/vas.h| 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 1422cdd..a59a187 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -674,7 +674,7 @@ static void init_winctx_for_rxwin(struct vas_window *rxwin,
 
winctx->rx_fifo = rxattr->rx_fifo;
winctx->rx_fifo_size = rxattr->rx_fifo_size;
-   winctx->wcreds_max = rxattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
+   winctx->wcreds_max = rxwin->wcreds_max;
winctx->pin_win = rxattr->pin_win;
 
winctx->nx_win = rxattr->nx_win;
@@ -844,6 +844,7 @@ struct vas_window *vas_rx_win_open(int vasid, enum 
vas_cop_type cop,
rxwin->nx_win = rxattr->nx_win;
rxwin->user_win = rxattr->user_win;
rxwin->cop = cop;
+   rxwin->wcreds_max = rxattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
if (rxattr->user_win)
rxwin->pid = task_pid_vnr(current);
 
@@ -893,7 +894,7 @@ static void init_winctx_for_txwin(struct vas_window *txwin,
 */
memset(winctx, 0, sizeof(struct vas_winctx));
 
-   winctx->wcreds_max = txattr->wcreds_max ?: VAS_WCREDS_DEFAULT;
+   winctx->wcreds_max = txwin->wcreds_max;
 
winctx->user_win = txattr->user_win;
winctx->nx_win = txwin->rxwin->nx_win;
@@ -978,6 +979,7 @@ struct vas_window *vas_tx_win_open(int vasid, enum 
vas_cop_type cop,
txwin->nx_win = txwin->rxwin->nx_win;
txwin->pid = attr->pid;
txwin->user_win = attr->user_win;
+   txwin->wcreds_max = attr->wcreds_max ?: VAS_WCREDS_DEFAULT;
 
init_winctx_for_txwin(txwin, attr, );
 
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 15d2dfa..ad906f6 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -332,6 +332,7 @@ struct vas_window {
void *hvwc_map; /* HV window context */
void *uwc_map;  /* OS/User window context */
pid_t pid;  /* Linux process id of owner */
+   int wcreds_max; /* Window credits */
 
/* Fields applicable only to send windows */
void *paste_kaddr;
-- 
2.7.4

[PATCH 05/10] powerpc/vas: Use helper to unpin/close window

[Sukadev Bhattiprolu]

Use a helper to have the hardware unpin and mark a window closed.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 8ab8a82..95622a9 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1101,6 +1101,20 @@ static void poll_window_castout(struct vas_window 
*window)
 }
 
 /*
+ * Unpin and close a window so no new requests are accepted and the
+ * hardware can evict this window from cache if necessary.
+ */
+static void unpin_close_window(struct vas_window *window)
+{
+   u64 val;
+
+   val = read_hvwc_reg(window, VREG(WINCTL));
+   val = SET_FIELD(VAS_WINCTL_PIN, val, 0);
+   val = SET_FIELD(VAS_WINCTL_OPEN, val, 0);
+   write_hvwc_reg(window, VREG(WINCTL), val);
+}
+
+/*
  * Close a window.
  *
  * See Section 1.12.1 of VAS workbook v1.05 for details on closing window:
@@ -1114,8 +1128,6 @@ static void poll_window_castout(struct vas_window *window)
  */
 int vas_win_close(struct vas_window *window)
 {
-   u64 val;
-
if (!window)
return 0;
 
@@ -1131,11 +1143,7 @@ int vas_win_close(struct vas_window *window)
 
poll_window_busy_state(window);
 
-   /* Unpin window from cache and close it */
-   val = read_hvwc_reg(window, VREG(WINCTL));
-   val = SET_FIELD(VAS_WINCTL_PIN, val, 0);
-   val = SET_FIELD(VAS_WINCTL_OPEN, val, 0);
-   write_hvwc_reg(window, VREG(WINCTL), val);
+   unpin_close_window(window);
 
poll_window_castout(window);
 
-- 
2.7.4

[PATCH 05/10] powerpc/vas: Use helper to unpin/close window

[Sukadev Bhattiprolu]

Use a helper to have the hardware unpin and mark a window closed.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 8ab8a82..95622a9 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1101,6 +1101,20 @@ static void poll_window_castout(struct vas_window 
*window)
 }
 
 /*
+ * Unpin and close a window so no new requests are accepted and the
+ * hardware can evict this window from cache if necessary.
+ */
+static void unpin_close_window(struct vas_window *window)
+{
+   u64 val;
+
+   val = read_hvwc_reg(window, VREG(WINCTL));
+   val = SET_FIELD(VAS_WINCTL_PIN, val, 0);
+   val = SET_FIELD(VAS_WINCTL_OPEN, val, 0);
+   write_hvwc_reg(window, VREG(WINCTL), val);
+}
+
+/*
  * Close a window.
  *
  * See Section 1.12.1 of VAS workbook v1.05 for details on closing window:
@@ -1114,8 +1128,6 @@ static void poll_window_castout(struct vas_window *window)
  */
 int vas_win_close(struct vas_window *window)
 {
-   u64 val;
-
if (!window)
return 0;
 
@@ -1131,11 +1143,7 @@ int vas_win_close(struct vas_window *window)
 
poll_window_busy_state(window);
 
-   /* Unpin window from cache and close it */
-   val = read_hvwc_reg(window, VREG(WINCTL));
-   val = SET_FIELD(VAS_WINCTL_PIN, val, 0);
-   val = SET_FIELD(VAS_WINCTL_OPEN, val, 0);
-   write_hvwc_reg(window, VREG(WINCTL), val);
+   unpin_close_window(window);
 
poll_window_castout(window);
 
-- 
2.7.4

[PATCH 03/10] powerpc/vas: Cleanup some debug code

[Sukadev Bhattiprolu]

Cleanuup vas.h and the debug code around ifdef vas_debug.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c |  8 +++--
 arch/powerpc/platforms/powernv/vas.h| 56 +++--
 2 files changed, 18 insertions(+), 46 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index a2fe120..67ffc5d 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -726,7 +726,10 @@ static void init_winctx_for_rxwin(struct vas_window *rxwin,
 static bool rx_win_args_valid(enum vas_cop_type cop,
struct vas_rx_win_attr *attr)
 {
-   dump_rx_win_attr(attr);
+   pr_debug("Rxattr: fault %d, notify %d, intr %d, early %d, fifo %d\n",
+   attr->fault_win, attr->notify_disable,
+   attr->intr_disable, attr->notify_early,
+   attr->rx_fifo_size);
 
if (cop >= VAS_COP_TYPE_MAX)
return false;
@@ -1050,7 +1053,8 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
else
rc = -EINVAL;
 
-   print_fifo_msg_count(txwin);
+   pr_debug("Txwin #%d: Msg count %llu\n", txwin->winid,
+   read_hvwc_reg(txwin, VREG(LRFIFO_PUSH)));
 
return rc;
 }
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index fea0de4..15d2dfa 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -259,6 +259,16 @@
 #define VAS_NX_UTIL_ADDER  PPC_BITMASK(32, 63)
 
 /*
+ * VREG(x):
+ * Expand a register's short name (eg: LPID) into two parameters:
+ * - the register's short name in string form ("LPID"), and
+ * - the name of the macro (eg: VAS_LPID_OFFSET), defining the
+ *   register's offset in the window context
+ */
+#define VREG_SFX(n, s) __stringify(n), VAS_##n##s
+#define VREG(r)VREG_SFX(r, _OFFSET)
+
+/*
  * Local Notify Scope Control Register. (Receive windows only).
  */
 enum vas_notify_scope {
@@ -385,43 +395,15 @@ struct vas_winctx {
 
 extern struct vas_instance *find_vas_instance(int vasid);
 
-/*
- * VREG(x):
- * Expand a register's short name (eg: LPID) into two parameters:
- * - the register's short name in string form ("LPID"), and
- * - the name of the macro (eg: VAS_LPID_OFFSET), defining the
- *   register's offset in the window context
- */
-#define VREG_SFX(n, s) __stringify(n), VAS_##n##s
-#define VREG(r)VREG_SFX(r, _OFFSET)
-
-#ifdef vas_debug
-static inline void dump_rx_win_attr(struct vas_rx_win_attr *attr)
-{
-   pr_err("fault %d, notify %d, intr %d early %d\n",
-   attr->fault_win, attr->notify_disable,
-   attr->intr_disable, attr->notify_early);
-
-   pr_err("rx_fifo_size %d, max value %d\n",
-   attr->rx_fifo_size, VAS_RX_FIFO_SIZE_MAX);
-}
-
 static inline void vas_log_write(struct vas_window *win, char *name,
void *regptr, u64 val)
 {
-   if (val)
-   pr_err("%swin #%d: %s reg %p, val 0x%016llx\n",
+   if (!val)
+   pr_debug("%swin #%d: %s reg %p, val 0x%016llx\n",
win->tx_win ? "Tx" : "Rx", win->winid, name,
regptr, val);
 }
 
-#else  /* vas_debug */
-
-#define vas_log_write(win, name, reg, val)
-#define dump_rx_win_attr(attr)
-
-#endif /* vas_debug */
-
 static inline void write_uwc_reg(struct vas_window *win, char *name,
s32 reg, u64 val)
 {
@@ -450,18 +432,4 @@ static inline u64 read_hvwc_reg(struct vas_window *win,
return in_be64(win->hvwc_map+reg);
 }
 
-#ifdef vas_debug
-
-static void print_fifo_msg_count(struct vas_window *txwin)
-{
-   uint64_t read_hvwc_reg(struct vas_window *w, char *n, uint64_t o);
-   pr_devel("Winid %d, Msg count %llu\n", txwin->winid,
-   (uint64_t)read_hvwc_reg(txwin, VREG(LRFIFO_PUSH)));
-}
-#else  /* vas_debug */
-
-#define print_fifo_msg_count(window)
-
-#endif /* vas_debug */
-
 #endif /* _VAS_H */
-- 
2.7.4

[PATCH 03/10] powerpc/vas: Cleanup some debug code

[Sukadev Bhattiprolu]

Cleanuup vas.h and the debug code around ifdef vas_debug.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c |  8 +++--
 arch/powerpc/platforms/powernv/vas.h| 56 +++--
 2 files changed, 18 insertions(+), 46 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index a2fe120..67ffc5d 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -726,7 +726,10 @@ static void init_winctx_for_rxwin(struct vas_window *rxwin,
 static bool rx_win_args_valid(enum vas_cop_type cop,
struct vas_rx_win_attr *attr)
 {
-   dump_rx_win_attr(attr);
+   pr_debug("Rxattr: fault %d, notify %d, intr %d, early %d, fifo %d\n",
+   attr->fault_win, attr->notify_disable,
+   attr->intr_disable, attr->notify_early,
+   attr->rx_fifo_size);
 
if (cop >= VAS_COP_TYPE_MAX)
return false;
@@ -1050,7 +1053,8 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
else
rc = -EINVAL;
 
-   print_fifo_msg_count(txwin);
+   pr_debug("Txwin #%d: Msg count %llu\n", txwin->winid,
+   read_hvwc_reg(txwin, VREG(LRFIFO_PUSH)));
 
return rc;
 }
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index fea0de4..15d2dfa 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -259,6 +259,16 @@
 #define VAS_NX_UTIL_ADDER  PPC_BITMASK(32, 63)
 
 /*
+ * VREG(x):
+ * Expand a register's short name (eg: LPID) into two parameters:
+ * - the register's short name in string form ("LPID"), and
+ * - the name of the macro (eg: VAS_LPID_OFFSET), defining the
+ *   register's offset in the window context
+ */
+#define VREG_SFX(n, s) __stringify(n), VAS_##n##s
+#define VREG(r)VREG_SFX(r, _OFFSET)
+
+/*
  * Local Notify Scope Control Register. (Receive windows only).
  */
 enum vas_notify_scope {
@@ -385,43 +395,15 @@ struct vas_winctx {
 
 extern struct vas_instance *find_vas_instance(int vasid);
 
-/*
- * VREG(x):
- * Expand a register's short name (eg: LPID) into two parameters:
- * - the register's short name in string form ("LPID"), and
- * - the name of the macro (eg: VAS_LPID_OFFSET), defining the
- *   register's offset in the window context
- */
-#define VREG_SFX(n, s) __stringify(n), VAS_##n##s
-#define VREG(r)VREG_SFX(r, _OFFSET)
-
-#ifdef vas_debug
-static inline void dump_rx_win_attr(struct vas_rx_win_attr *attr)
-{
-   pr_err("fault %d, notify %d, intr %d early %d\n",
-   attr->fault_win, attr->notify_disable,
-   attr->intr_disable, attr->notify_early);
-
-   pr_err("rx_fifo_size %d, max value %d\n",
-   attr->rx_fifo_size, VAS_RX_FIFO_SIZE_MAX);
-}
-
 static inline void vas_log_write(struct vas_window *win, char *name,
void *regptr, u64 val)
 {
-   if (val)
-   pr_err("%swin #%d: %s reg %p, val 0x%016llx\n",
+   if (!val)
+   pr_debug("%swin #%d: %s reg %p, val 0x%016llx\n",
win->tx_win ? "Tx" : "Rx", win->winid, name,
regptr, val);
 }
 
-#else  /* vas_debug */
-
-#define vas_log_write(win, name, reg, val)
-#define dump_rx_win_attr(attr)
-
-#endif /* vas_debug */
-
 static inline void write_uwc_reg(struct vas_window *win, char *name,
s32 reg, u64 val)
 {
@@ -450,18 +432,4 @@ static inline u64 read_hvwc_reg(struct vas_window *win,
return in_be64(win->hvwc_map+reg);
 }
 
-#ifdef vas_debug
-
-static void print_fifo_msg_count(struct vas_window *txwin)
-{
-   uint64_t read_hvwc_reg(struct vas_window *w, char *n, uint64_t o);
-   pr_devel("Winid %d, Msg count %llu\n", txwin->winid,
-   (uint64_t)read_hvwc_reg(txwin, VREG(LRFIFO_PUSH)));
-}
-#else  /* vas_debug */
-
-#define print_fifo_msg_count(window)
-
-#endif /* vas_debug */
-
 #endif /* _VAS_H */
-- 
2.7.4

[PATCH 09/10] powerpc/vas: Create cpu to vas id mapping

[Sukadev Bhattiprolu]

Create a cpu to vasid mapping so callers can specify -1 instead of
trying to find a VAS id.

Changelog[v2]
[Michael Ellerman] Use per-cpu variables to simplify code.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/vas.c 
b/arch/powerpc/platforms/powernv/vas.c
index 565a487..abb7090 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -18,15 +18,18 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vas.h"
 
 static DEFINE_MUTEX(vas_mutex);
 static LIST_HEAD(vas_instances);
 
+static DEFINE_PER_CPU(int, cpu_vas_id);
+
 static int init_vas_instance(struct platform_device *pdev)
 {
-   int rc, vasid;
+   int rc, cpu, vasid;
struct resource *res;
struct vas_instance *vinst;
struct device_node *dn = pdev->dev.of_node;
@@ -74,6 +77,11 @@ static int init_vas_instance(struct platform_device *pdev)
"paste_win_id_shift 0x%llx\n", pdev->name, vasid,
vinst->paste_base_addr, vinst->paste_win_id_shift);
 
+   for_each_possible_cpu(cpu) {
+   if (cpu_to_chip_id(cpu) == of_get_ibm_chip_id(dn))
+   per_cpu(cpu_vas_id, cpu) = vasid;
+   }
+
mutex_lock(_mutex);
list_add(>node, _instances);
mutex_unlock(_mutex);
@@ -98,6 +106,10 @@ struct vas_instance *find_vas_instance(int vasid)
struct vas_instance *vinst;
 
mutex_lock(_mutex);
+
+   if (vasid == -1)
+   vasid = per_cpu(cpu_vas_id, smp_processor_id());
+
list_for_each(ent, _instances) {
vinst = list_entry(ent, struct vas_instance, node);
if (vinst->vas_id == vasid) {
-- 
2.7.4

[PATCH 09/10] powerpc/vas: Create cpu to vas id mapping

[Sukadev Bhattiprolu]

Create a cpu to vasid mapping so callers can specify -1 instead of
trying to find a VAS id.

Changelog[v2]
[Michael Ellerman] Use per-cpu variables to simplify code.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/vas.c 
b/arch/powerpc/platforms/powernv/vas.c
index 565a487..abb7090 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -18,15 +18,18 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vas.h"
 
 static DEFINE_MUTEX(vas_mutex);
 static LIST_HEAD(vas_instances);
 
+static DEFINE_PER_CPU(int, cpu_vas_id);
+
 static int init_vas_instance(struct platform_device *pdev)
 {
-   int rc, vasid;
+   int rc, cpu, vasid;
struct resource *res;
struct vas_instance *vinst;
struct device_node *dn = pdev->dev.of_node;
@@ -74,6 +77,11 @@ static int init_vas_instance(struct platform_device *pdev)
"paste_win_id_shift 0x%llx\n", pdev->name, vasid,
vinst->paste_base_addr, vinst->paste_win_id_shift);
 
+   for_each_possible_cpu(cpu) {
+   if (cpu_to_chip_id(cpu) == of_get_ibm_chip_id(dn))
+   per_cpu(cpu_vas_id, cpu) = vasid;
+   }
+
mutex_lock(_mutex);
list_add(>node, _instances);
mutex_unlock(_mutex);
@@ -98,6 +106,10 @@ struct vas_instance *find_vas_instance(int vasid)
struct vas_instance *vinst;
 
mutex_lock(_mutex);
+
+   if (vasid == -1)
+   vasid = per_cpu(cpu_vas_id, smp_processor_id());
+
list_for_each(ent, _instances) {
vinst = list_entry(ent, struct vas_instance, node);
if (vinst->vas_id == vasid) {
-- 
2.7.4

[PATCH 08/10] powerpc/vas: poll for return of window credits

[Sukadev Bhattiprolu]

Normally, the NX driver waits for the CRBs to be processed before closing
the window. But it is better to ensure that the credits are returned before
the window gets reassigned later.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index a59a187..8e14ce1 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1063,6 +1063,49 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
 EXPORT_SYMBOL_GPL(vas_paste_crb);
 
 /*
+ * If credit checking is enabled for this window, poll for the return
+ * of window credits (i.e for NX engines to process any outstanding CRBs).
+ * Since NX-842 waits for the CRBs to be processed before closing the
+ * window, we should not have to wait for too long.
+ *
+ * TODO: We retry in 10ms intervals now. We could/should probably peek at
+ * the VAS_LRFIFO_PUSH_OFFSET register to get an estimate of pending
+ * CRBs on the FIFO and compute the delay dynamically on each retry.
+ * But that is not really needed until we support NX-GZIP access from
+ * user space. (NX-842 driver waits for CSB and Fast thread-wakeup
+ * doesn't use credit checking).
+ */
+static void poll_window_credits(struct vas_window *window)
+{
+   u64 val;
+   int creds, mode;
+
+   val = read_hvwc_reg(window, VREG(WINCTL));
+   if (window->tx_win)
+   mode = GET_FIELD(VAS_WINCTL_TX_WCRED_MODE, val);
+   else
+   mode = GET_FIELD(VAS_WINCTL_RX_WCRED_MODE, val);
+
+   if (!mode)
+   return;
+retry:
+   if (window->tx_win) {
+   val = read_hvwc_reg(window, VREG(TX_WCRED));
+   creds = GET_FIELD(VAS_TX_WCRED, val);
+   } else {
+   val = read_hvwc_reg(window, VREG(LRX_WCRED));
+   creds = GET_FIELD(VAS_LRX_WCRED, val);
+   }
+
+   if (creds < window->wcreds_max) {
+   val = 0;
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(msecs_to_jiffies(10));
+   goto retry;
+   }
+}
+
+/*
  * Wait for the window to go to "not-busy" state. It should only take a
  * short time to queue a CRB, so window should not be busy for too long.
  * Trying 5ms intervals.
@@ -1149,6 +1192,8 @@ int vas_win_close(struct vas_window *window)
 
unpin_close_window(window);
 
+   poll_window_credits(window);
+
poll_window_castout(window);
 
/* if send window, drop reference to matching receive window */
-- 
2.7.4

[PATCH 08/10] powerpc/vas: poll for return of window credits

[Sukadev Bhattiprolu]

Normally, the NX driver waits for the CRBs to be processed before closing
the window. But it is better to ensure that the credits are returned before
the window gets reassigned later.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index a59a187..8e14ce1 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1063,6 +1063,49 @@ int vas_paste_crb(struct vas_window *txwin, int offset, 
bool re)
 EXPORT_SYMBOL_GPL(vas_paste_crb);
 
 /*
+ * If credit checking is enabled for this window, poll for the return
+ * of window credits (i.e for NX engines to process any outstanding CRBs).
+ * Since NX-842 waits for the CRBs to be processed before closing the
+ * window, we should not have to wait for too long.
+ *
+ * TODO: We retry in 10ms intervals now. We could/should probably peek at
+ * the VAS_LRFIFO_PUSH_OFFSET register to get an estimate of pending
+ * CRBs on the FIFO and compute the delay dynamically on each retry.
+ * But that is not really needed until we support NX-GZIP access from
+ * user space. (NX-842 driver waits for CSB and Fast thread-wakeup
+ * doesn't use credit checking).
+ */
+static void poll_window_credits(struct vas_window *window)
+{
+   u64 val;
+   int creds, mode;
+
+   val = read_hvwc_reg(window, VREG(WINCTL));
+   if (window->tx_win)
+   mode = GET_FIELD(VAS_WINCTL_TX_WCRED_MODE, val);
+   else
+   mode = GET_FIELD(VAS_WINCTL_RX_WCRED_MODE, val);
+
+   if (!mode)
+   return;
+retry:
+   if (window->tx_win) {
+   val = read_hvwc_reg(window, VREG(TX_WCRED));
+   creds = GET_FIELD(VAS_TX_WCRED, val);
+   } else {
+   val = read_hvwc_reg(window, VREG(LRX_WCRED));
+   creds = GET_FIELD(VAS_LRX_WCRED, val);
+   }
+
+   if (creds < window->wcreds_max) {
+   val = 0;
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_timeout(msecs_to_jiffies(10));
+   goto retry;
+   }
+}
+
+/*
  * Wait for the window to go to "not-busy" state. It should only take a
  * short time to queue a CRB, so window should not be busy for too long.
  * Trying 5ms intervals.
@@ -1149,6 +1192,8 @@ int vas_win_close(struct vas_window *window)
 
unpin_close_window(window);
 
+   poll_window_credits(window);
+
poll_window_castout(window);
 
/* if send window, drop reference to matching receive window */
-- 
2.7.4

[PATCH 10/10] powerpc/vas, nx-842: Define and use chip_to_vas_id()

[Sukadev Bhattiprolu]

Define a helper, chip_to_vas_id() to map a given chip id to corresponding
vas id.

Normally, callers of vas_rx_win_open() and vas_tx_win_open() would need
the VAS window to be on the same chip where the calling thread is executing.
These callers can pass in -1 for the VAS id.

This interface will be useful if a thread running on one chip wants to open
a window on another chip (like the NX-842 driver does during start up).

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/vas.h   |  9 +
 arch/powerpc/platforms/powernv/vas.c | 11 +++
 drivers/crypto/nx/nx-842-powernv.c   | 18 +++---
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index fd5963a..044748f 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -104,6 +104,15 @@ struct vas_tx_win_attr {
 };
 
 /*
+ * Helper to map a chip id to VAS id.
+ * For POWER9, this is a 1:1 mapping. In the future this maybe a 1:N
+ * mapping in which case, we will need to update this helper.
+ *
+ * Return the VAS id or -1 if no matching vasid is found.
+ */
+int chip_to_vas_id(int chipid);
+
+/*
  * Helper to initialize receive window attributes to defaults for an
  * NX window.
  */
diff --git a/arch/powerpc/platforms/powernv/vas.c 
b/arch/powerpc/platforms/powernv/vas.c
index abb7090..cd9a733 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -123,6 +123,17 @@ struct vas_instance *find_vas_instance(int vasid)
return NULL;
 }
 
+int chip_to_vas_id(int chipid)
+{
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   if (cpu_to_chip_id(cpu) == chipid)
+   return per_cpu(cpu_vas_id, cpu);
+   }
+   return -1;
+}
+
 static int vas_probe(struct platform_device *pdev)
 {
return init_vas_instance(pdev);
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 874ddf5..eb221ed 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -847,24 +847,12 @@ static int __init nx842_powernv_probe_vas(struct 
device_node *pn)
return -EINVAL;
}
 
-   for_each_compatible_node(dn, NULL, "ibm,power9-vas-x") {
-   if (of_get_ibm_chip_id(dn) == chip_id)
-   break;
-   }
-
-   if (!dn) {
-   pr_err("Missing VAS device node\n");
+   vasid = chip_to_vas_id(chip_id);
+   if (vasid < 0) {
+   pr_err("Unable to map chip_id %d to vasid\n", chip_id);
return -EINVAL;
}
 
-   if (of_property_read_u32(dn, "ibm,vas-id", )) {
-   pr_err("Missing ibm,vas-id device property\n");
-   of_node_put(dn);
-   return -EINVAL;
-   }
-
-   of_node_put(dn);
-
for_each_child_of_node(pn, dn) {
if (of_device_is_compatible(dn, "ibm,p9-nx-842")) {
ret = vas_cfg_coproc_info(dn, chip_id, vasid);
-- 
2.7.4

[PATCH 04/10] powerpc/vas: Drop poll_window_cast_out().

[Sukadev Bhattiprolu]

Polling for window cast out is listed in the spec, but turns out that
it is not strictly necessary and slows down window close. Making it a
stub for now.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 34 ++---
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 67ffc5d..8ab8a82 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1079,25 +1079,25 @@ static void poll_window_busy_state(struct vas_window 
*window)
}
 }
 
+/*
+ * Have the hardware cast a window out of cache and wait for it to
+ * be completed.
+ *
+ * NOTE: It can take a relatively long time to cast the window context
+ * out of the cache. It is not strictly necessary to cast out if:
+ *
+ * - we clear the "Pin Window" bit (so hardware is free to evict)
+ *
+ * - we re-initialize the window context when it is reassigned.
+ *
+ * We do the former in vas_win_close() and latter in vas_win_open().
+ * So, ignoring the cast-out for now. We can add it as needed. If
+ * casting out becomes necessary we should consider offloading the
+ * job to a worker thread, so the window close can proceed quickly.
+ */
 static void poll_window_castout(struct vas_window *window)
 {
-   int cached;
-   u64 val;
-
-   /* Cast window context out of the cache */
-retry:
-   val = read_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL));
-   cached = GET_FIELD(VAS_WIN_CACHE_STATUS, val);
-   if (cached) {
-   val = 0ULL;
-   val = SET_FIELD(VAS_CASTOUT_REQ, val, 1);
-   val = SET_FIELD(VAS_PUSH_TO_MEM, val, 0);
-   write_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), val);
-
-   set_current_state(TASK_UNINTERRUPTIBLE);
-   schedule_timeout(HZ);
-   goto retry;
-   }
+   /* stub for now */
 }
 
 /*
-- 
2.7.4

[PATCH 10/10] powerpc/vas, nx-842: Define and use chip_to_vas_id()

[Sukadev Bhattiprolu]

Define a helper, chip_to_vas_id() to map a given chip id to corresponding
vas id.

Normally, callers of vas_rx_win_open() and vas_tx_win_open() would need
the VAS window to be on the same chip where the calling thread is executing.
These callers can pass in -1 for the VAS id.

This interface will be useful if a thread running on one chip wants to open
a window on another chip (like the NX-842 driver does during start up).

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/vas.h   |  9 +
 arch/powerpc/platforms/powernv/vas.c | 11 +++
 drivers/crypto/nx/nx-842-powernv.c   | 18 +++---
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index fd5963a..044748f 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -104,6 +104,15 @@ struct vas_tx_win_attr {
 };
 
 /*
+ * Helper to map a chip id to VAS id.
+ * For POWER9, this is a 1:1 mapping. In the future this maybe a 1:N
+ * mapping in which case, we will need to update this helper.
+ *
+ * Return the VAS id or -1 if no matching vasid is found.
+ */
+int chip_to_vas_id(int chipid);
+
+/*
  * Helper to initialize receive window attributes to defaults for an
  * NX window.
  */
diff --git a/arch/powerpc/platforms/powernv/vas.c 
b/arch/powerpc/platforms/powernv/vas.c
index abb7090..cd9a733 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -123,6 +123,17 @@ struct vas_instance *find_vas_instance(int vasid)
return NULL;
 }
 
+int chip_to_vas_id(int chipid)
+{
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   if (cpu_to_chip_id(cpu) == chipid)
+   return per_cpu(cpu_vas_id, cpu);
+   }
+   return -1;
+}
+
 static int vas_probe(struct platform_device *pdev)
 {
return init_vas_instance(pdev);
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 874ddf5..eb221ed 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -847,24 +847,12 @@ static int __init nx842_powernv_probe_vas(struct 
device_node *pn)
return -EINVAL;
}
 
-   for_each_compatible_node(dn, NULL, "ibm,power9-vas-x") {
-   if (of_get_ibm_chip_id(dn) == chip_id)
-   break;
-   }
-
-   if (!dn) {
-   pr_err("Missing VAS device node\n");
+   vasid = chip_to_vas_id(chip_id);
+   if (vasid < 0) {
+   pr_err("Unable to map chip_id %d to vasid\n", chip_id);
return -EINVAL;
}
 
-   if (of_property_read_u32(dn, "ibm,vas-id", )) {
-   pr_err("Missing ibm,vas-id device property\n");
-   of_node_put(dn);
-   return -EINVAL;
-   }
-
-   of_node_put(dn);
-
for_each_child_of_node(pn, dn) {
if (of_device_is_compatible(dn, "ibm,p9-nx-842")) {
ret = vas_cfg_coproc_info(dn, chip_id, vasid);
-- 
2.7.4

[PATCH 04/10] powerpc/vas: Drop poll_window_cast_out().

[Sukadev Bhattiprolu]

Polling for window cast out is listed in the spec, but turns out that
it is not strictly necessary and slows down window close. Making it a
stub for now.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 34 ++---
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 67ffc5d..8ab8a82 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -1079,25 +1079,25 @@ static void poll_window_busy_state(struct vas_window 
*window)
}
 }
 
+/*
+ * Have the hardware cast a window out of cache and wait for it to
+ * be completed.
+ *
+ * NOTE: It can take a relatively long time to cast the window context
+ * out of the cache. It is not strictly necessary to cast out if:
+ *
+ * - we clear the "Pin Window" bit (so hardware is free to evict)
+ *
+ * - we re-initialize the window context when it is reassigned.
+ *
+ * We do the former in vas_win_close() and latter in vas_win_open().
+ * So, ignoring the cast-out for now. We can add it as needed. If
+ * casting out becomes necessary we should consider offloading the
+ * job to a worker thread, so the window close can proceed quickly.
+ */
 static void poll_window_castout(struct vas_window *window)
 {
-   int cached;
-   u64 val;
-
-   /* Cast window context out of the cache */
-retry:
-   val = read_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL));
-   cached = GET_FIELD(VAS_WIN_CACHE_STATUS, val);
-   if (cached) {
-   val = 0ULL;
-   val = SET_FIELD(VAS_CASTOUT_REQ, val, 1);
-   val = SET_FIELD(VAS_PUSH_TO_MEM, val, 0);
-   write_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), val);
-
-   set_current_state(TASK_UNINTERRUPTIBLE);
-   schedule_timeout(HZ);
-   goto retry;
-   }
+   /* stub for now */
 }
 
 /*
-- 
2.7.4

[PATCH 01/10] powerpc/vas: init missing fields from [rt]xattr

[Sukadev Bhattiprolu]

Initialize a few missing window context fields from the window attributes
specified by the caller. These fields are currently set to their default
values by the caller (NX-842), but would be good to apply them anyway.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 5aae845..cec7ab7 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -679,10 +679,13 @@ static void init_winctx_for_rxwin(struct vas_window 
*rxwin,
 
winctx->nx_win = rxattr->nx_win;
winctx->fault_win = rxattr->fault_win;
+   winctx->user_win = rxattr->user_win;
+   winctx->rej_no_credit = rxattr->rej_no_credit;
winctx->rx_word_mode = rxattr->rx_win_ord_mode;
winctx->tx_word_mode = rxattr->tx_win_ord_mode;
winctx->rx_wcred_mode = rxattr->rx_wcred_mode;
winctx->tx_wcred_mode = rxattr->tx_wcred_mode;
+   winctx->notify_early = rxattr->notify_early;
 
if (winctx->nx_win) {
winctx->data_stamp = true;
@@ -889,11 +892,14 @@ static void init_winctx_for_txwin(struct vas_window 
*txwin,
winctx->user_win = txattr->user_win;
winctx->nx_win = txwin->rxwin->nx_win;
winctx->pin_win = txattr->pin_win;
+   winctx->rej_no_credit = txattr->rej_no_credit;
+   winctx->rsvd_txbuf_enable = txattr->rsvd_txbuf_enable;
 
winctx->rx_wcred_mode = txattr->rx_wcred_mode;
winctx->tx_wcred_mode = txattr->tx_wcred_mode;
winctx->rx_word_mode = txattr->rx_win_ord_mode;
winctx->tx_word_mode = txattr->tx_win_ord_mode;
+   winctx->rsvd_txbuf_count = txattr->rsvd_txbuf_count;
 
if (winctx->nx_win) {
winctx->data_stamp = true;
-- 
2.7.4

[PATCH 01/10] powerpc/vas: init missing fields from [rt]xattr

[Sukadev Bhattiprolu]

Initialize a few missing window context fields from the window attributes
specified by the caller. These fields are currently set to their default
values by the caller (NX-842), but would be good to apply them anyway.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/platforms/powernv/vas-window.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 5aae845..cec7ab7 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -679,10 +679,13 @@ static void init_winctx_for_rxwin(struct vas_window 
*rxwin,
 
winctx->nx_win = rxattr->nx_win;
winctx->fault_win = rxattr->fault_win;
+   winctx->user_win = rxattr->user_win;
+   winctx->rej_no_credit = rxattr->rej_no_credit;
winctx->rx_word_mode = rxattr->rx_win_ord_mode;
winctx->tx_word_mode = rxattr->tx_win_ord_mode;
winctx->rx_wcred_mode = rxattr->rx_wcred_mode;
winctx->tx_wcred_mode = rxattr->tx_wcred_mode;
+   winctx->notify_early = rxattr->notify_early;
 
if (winctx->nx_win) {
winctx->data_stamp = true;
@@ -889,11 +892,14 @@ static void init_winctx_for_txwin(struct vas_window 
*txwin,
winctx->user_win = txattr->user_win;
winctx->nx_win = txwin->rxwin->nx_win;
winctx->pin_win = txattr->pin_win;
+   winctx->rej_no_credit = txattr->rej_no_credit;
+   winctx->rsvd_txbuf_enable = txattr->rsvd_txbuf_enable;
 
winctx->rx_wcred_mode = txattr->rx_wcred_mode;
winctx->tx_wcred_mode = txattr->tx_wcred_mode;
winctx->rx_word_mode = txattr->rx_win_ord_mode;
winctx->tx_word_mode = txattr->tx_win_ord_mode;
+   winctx->rsvd_txbuf_count = txattr->rsvd_txbuf_count;
 
if (winctx->nx_win) {
winctx->data_stamp = true;
-- 
2.7.4

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

[Rob Landley]

On 09/14/2017 04:17 AM, Christophe LEROY wrote:
> Le 14/09/2017 à 01:51, Rob Landley a écrit :
>> From: Rob Landley 
>>
>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
>> /dev/console open after devtmpfs mount.
>>
>> Add workaround for Debian bug that was copied by Ubuntu.
> 
> Is that a bug only for Debian ? Why ?

Look down, specifically this bit:

>> v2 discussion:
>> http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html

That's some discussion of version 2 of this patch, which was merged for
a while last dev cycle, then backed out again because it triggered the
same bug in a number of system init scripts:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.2/07072.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01182.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01505.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01320.html

All of whom copied the broken error "recovery" path from debian. If they
checked whether it was already mounted, or didn't _blank_ the /dev
directory in response to mounting the exact same filesystem over itself
giving -EBUSY, the system would work fine. Heck, if you built a kernel
with a static /dev in initramfs and no devtmpfs configured in, the
script would break things exactly the same way. The breakage is that
script takes a hammer to a perfectly functional /dev directory and then
continues the boot with an empty /dev. That's bonkers.

> Why should a Debian bug be fixed by a workaround in the mainline kernel ?

That was my argument last time, and the answer was "Breaking userspace
is bad, mmmkay." Even when userspace is doing something REALLY OBVIOUSLY
STUPID and it is _clearly_ their fault, as long as they got there first
they've established the status quo and it doesn't matter how silly it is.

This was explicitly stated to me here:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/03292.html

I.E. don't argue with me, argue with him. :)

So, I added a workaround with a printk in hopes of embarassing them into
someday fixing it.

Rob

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

[Rob Landley]

On 09/14/2017 04:17 AM, Christophe LEROY wrote:
> Le 14/09/2017 à 01:51, Rob Landley a écrit :
>> From: Rob Landley 
>>
>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
>> /dev/console open after devtmpfs mount.
>>
>> Add workaround for Debian bug that was copied by Ubuntu.
> 
> Is that a bug only for Debian ? Why ?

Look down, specifically this bit:

>> v2 discussion:
>> http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html

That's some discussion of version 2 of this patch, which was merged for
a while last dev cycle, then backed out again because it triggered the
same bug in a number of system init scripts:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.2/07072.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01182.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01505.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01320.html

All of whom copied the broken error "recovery" path from debian. If they
checked whether it was already mounted, or didn't _blank_ the /dev
directory in response to mounting the exact same filesystem over itself
giving -EBUSY, the system would work fine. Heck, if you built a kernel
with a static /dev in initramfs and no devtmpfs configured in, the
script would break things exactly the same way. The breakage is that
script takes a hammer to a perfectly functional /dev directory and then
continues the boot with an empty /dev. That's bonkers.

> Why should a Debian bug be fixed by a workaround in the mainline kernel ?

That was my argument last time, and the answer was "Breaking userspace
is bad, mmmkay." Even when userspace is doing something REALLY OBVIOUSLY
STUPID and it is _clearly_ their fault, as long as they got there first
they've established the status quo and it doesn't matter how silly it is.

This was explicitly stated to me here:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/03292.html

I.E. don't argue with me, argue with him. :)

So, I added a workaround with a printk in hopes of embarassing them into
someday fixing it.

Rob

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

[Dan Williams]

On Tue, Aug 15, 2017 at 5:27 AM, Jan Kara  wrote:
> On Mon 14-08-17 23:12:16, Dan Williams wrote:
>> The mmap syscall suffers from the ABI anti-pattern of not validating
>> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
>> mechanism to define new behavior that is known to fail on older kernels
>> without the feature. Use the fact that specifying MAP_SHARED and
>> MAP_PRIVATE at the same time is invalid as a cute hack to allow a new
>> set of validated flags to be introduced.
>>
>> This also introduces the ->fmmap() file operation that is ->mmap() plus
>> flags. Each ->fmmap() implementation must fail requests when a locally
>> unsupported flag is specified.
> ...
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 1104e5df39ef..bbe755d0caee 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1674,6 +1674,7 @@ struct file_operations {
>>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>>   int (*mmap) (struct file *, struct vm_area_struct *);
>> + int (*fmmap) (struct file *, struct vm_area_struct *, unsigned long);
>>   int (*open) (struct inode *, struct file *);
>>   int (*flush) (struct file *, fl_owner_t id);
>>   int (*release) (struct inode *, struct file *);
>> @@ -1748,6 +1749,12 @@ static inline int call_mmap(struct file *file, struct 
>> vm_area_struct *vma)
>>   return file->f_op->mmap(file, vma);
>>  }
>>
>> +static inline int call_fmmap(struct file *file, struct vm_area_struct *vma,
>> + unsigned long flags)
>> +{
>> + return file->f_op->fmmap(file, vma, flags);
>> +}
>> +
>
> Hum, I dislike a new file op for this when the only problem with ->mmap is
> that it misses 'flags' argument. I understand there are lots of ->mmap
> implementations out there and modifying prototype of them all is painful
> but is it so bad? Coccinelle patch for this should be rather easy...

So it wasn't all that easy, and Linus declined to take it. I think we
should add a new ->mmap_validate() file operation and save the
tree-wide cleanup until later.

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

[Dan Williams]

On Tue, Aug 15, 2017 at 5:27 AM, Jan Kara  wrote:
> On Mon 14-08-17 23:12:16, Dan Williams wrote:
>> The mmap syscall suffers from the ABI anti-pattern of not validating
>> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
>> mechanism to define new behavior that is known to fail on older kernels
>> without the feature. Use the fact that specifying MAP_SHARED and
>> MAP_PRIVATE at the same time is invalid as a cute hack to allow a new
>> set of validated flags to be introduced.
>>
>> This also introduces the ->fmmap() file operation that is ->mmap() plus
>> flags. Each ->fmmap() implementation must fail requests when a locally
>> unsupported flag is specified.
> ...
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 1104e5df39ef..bbe755d0caee 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1674,6 +1674,7 @@ struct file_operations {
>>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>>   int (*mmap) (struct file *, struct vm_area_struct *);
>> + int (*fmmap) (struct file *, struct vm_area_struct *, unsigned long);
>>   int (*open) (struct inode *, struct file *);
>>   int (*flush) (struct file *, fl_owner_t id);
>>   int (*release) (struct inode *, struct file *);
>> @@ -1748,6 +1749,12 @@ static inline int call_mmap(struct file *file, struct 
>> vm_area_struct *vma)
>>   return file->f_op->mmap(file, vma);
>>  }
>>
>> +static inline int call_fmmap(struct file *file, struct vm_area_struct *vma,
>> + unsigned long flags)
>> +{
>> + return file->f_op->fmmap(file, vma, flags);
>> +}
>> +
>
> Hum, I dislike a new file op for this when the only problem with ->mmap is
> that it misses 'flags' argument. I understand there are lots of ->mmap
> implementations out there and modifying prototype of them all is painful
> but is it so bad? Coccinelle patch for this should be rather easy...

So it wasn't all that easy, and Linus declined to take it. I think we
should add a new ->mmap_validate() file operation and save the
tree-wide cleanup until later.

net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
commit: 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 netfilter: nat: use keyed locks
date:   8 days ago
config: x86_64-randconfig-s4-09170918 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   net//netfilter/nf_nat_core.c: In function 'nf_nat_setup_info':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:432:34: note: in expansion of macro 'ARRAY_SIZE'
  lock = _nat_locks[srchash % ARRAY_SIZE(nf_nat_locks)];
 ^~
   net//netfilter/nf_nat_core.c: In function '__nf_nat_cleanup_conntrack':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:535:33: note: in expansion of macro 'ARRAY_SIZE'
 spin_lock_bh(_nat_locks[h % ARRAY_SIZE(nf_nat_locks)]);
^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:537:35: note: in expansion of macro 'ARRAY_SIZE'
 spin_unlock_bh(_nat_locks[h % ARRAY_SIZE(nf_nat_locks)]);
  ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   net//netfilter/nf_nat_core.c: In function 'nf_nat_init':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:811:24: note: in expansion of macro 

net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
commit: 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 netfilter: nat: use keyed locks
date:   8 days ago
config: x86_64-randconfig-s4-09170918 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   net//netfilter/nf_nat_core.c: In function 'nf_nat_setup_info':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:432:34: note: in expansion of macro 'ARRAY_SIZE'
  lock = _nat_locks[srchash % ARRAY_SIZE(nf_nat_locks)];
 ^~
   net//netfilter/nf_nat_core.c: In function '__nf_nat_cleanup_conntrack':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:535:33: note: in expansion of macro 'ARRAY_SIZE'
 spin_lock_bh(_nat_locks[h % ARRAY_SIZE(nf_nat_locks)]);
^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:537:35: note: in expansion of macro 'ARRAY_SIZE'
 spin_unlock_bh(_nat_locks[h % ARRAY_SIZE(nf_nat_locks)]);
  ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   net//netfilter/nf_nat_core.c: In function 'nf_nat_init':
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
 ^~
   net//netfilter/nf_nat_core.c:810:27: note: in expansion of macro 'ARRAY_SIZE'
 if (nf_nat_htable_size < ARRAY_SIZE(nf_nat_locks))
  ^~
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from net//netfilter/nf_nat_core.c:11:
   include/linux/kernel.h:60:38: warning: division by zero [-Wdiv-by-zero]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 ^
   net//netfilter/nf_nat_core.c:811:24: note: in expansion of macro 

[PATCH v2 03/10] dmaengine: sun6i: Restructure code to allow extension for new SoCs

[Stefan Brüns]

The current code mixes three distinct operations when transforming
the slave config to register settings:

  1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0
  2. range checking
  3. conversion of raw to register values

As the range checks depend on the specific SoC, move these out of the
conversion to distinct operations.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 66 -
 1 file changed, 38 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a6fc066a0ac6..663f4b0b450e 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -118,6 +118,8 @@ struct sun6i_dma_config {
 */
void (*clock_autogate_enable)();
void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
+   u32 src_burst_lengths;
+   u32 dst_burst_lengths;
 };
 
 /*
@@ -266,10 +268,6 @@ static inline s8 convert_burst(u32 maxburst)
 
 static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
 {
-   if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
-   (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
-   return -EINVAL;
-
return addr_width >> 1;
 }
 
@@ -542,41 +540,43 @@ static int set_config(struct sun6i_dma_dev *sdev,
enum dma_transfer_direction direction,
u32 *p_cfg)
 {
+   enum dma_slave_buswidth src_addr_width, dst_addr_width;
+   u32 src_maxburst, dst_maxburst;
s8 src_width, dst_width, src_burst, dst_burst;
 
+   src_addr_width = sconfig->src_addr_width;
+   dst_addr_width = sconfig->dst_addr_width;
+   src_maxburst = sconfig->src_maxburst;
+   dst_maxburst = sconfig->dst_maxburst;
+
switch (direction) {
case DMA_MEM_TO_DEV:
-   src_burst = convert_burst(sconfig->src_maxburst ?
-   sconfig->src_maxburst : 8);
-   src_width = convert_buswidth(sconfig->src_addr_width !=
-   DMA_SLAVE_BUSWIDTH_UNDEFINED ?
-   sconfig->src_addr_width :
-   DMA_SLAVE_BUSWIDTH_4_BYTES);
-   dst_burst = convert_burst(sconfig->dst_maxburst);
-   dst_width = convert_buswidth(sconfig->dst_addr_width);
+   if (src_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+   src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   src_maxburst = src_maxburst ? src_maxburst : 8;
break;
case DMA_DEV_TO_MEM:
-   src_burst = convert_burst(sconfig->src_maxburst);
-   src_width = convert_buswidth(sconfig->src_addr_width);
-   dst_burst = convert_burst(sconfig->dst_maxburst ?
-   sconfig->dst_maxburst : 8);
-   dst_width = convert_buswidth(sconfig->dst_addr_width !=
-   DMA_SLAVE_BUSWIDTH_UNDEFINED ?
-   sconfig->dst_addr_width :
-   DMA_SLAVE_BUSWIDTH_4_BYTES);
+   if (dst_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+   dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dst_maxburst = dst_maxburst ? dst_maxburst : 8;
break;
default:
return -EINVAL;
}
 
-   if (src_burst < 0)
-   return src_burst;
-   if (src_width < 0)
-   return src_width;
-   if (dst_burst < 0)
-   return dst_burst;
-   if (dst_width < 0)
-   return dst_width;
+   if (!(BIT(src_addr_width) & sdev->slave.src_addr_widths))
+   return -EINVAL;
+   if (!(BIT(dst_addr_width) & sdev->slave.dst_addr_widths))
+   return -EINVAL;
+   if (!(BIT(src_maxburst) & sdev->cfg->src_burst_lengths))
+   return -EINVAL;
+   if (!(BIT(dst_maxburst) & sdev->cfg->dst_burst_lengths))
+   return -EINVAL;
+
+   src_width = convert_buswidth(src_addr_width);
+   dst_width = convert_buswidth(dst_addr_width);
+   dst_burst = convert_burst(dst_maxburst);
+   src_burst = convert_burst(src_maxburst);
 
*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
DMA_CHAN_CFG_DST_WIDTH(dst_width);
@@ -1043,6 +1043,8 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_vchans   = 53,
.clock_autogate_enable = sun6i_enable_clock_autogate_noop;
.set_burst_length = sun6i_set_burst_length_a31;
+   .src_burst_lengths = BIT(1) | BIT(8);
+   .dst_burst_lengths = BIT(1) | BIT(8);
 };
 
 /*
@@ -1056,6 +1058,8 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_vchans   = 37,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
.set_burst_length = sun6i_set_burst_length_a31;
+   

[PATCH v2 03/10] dmaengine: sun6i: Restructure code to allow extension for new SoCs

[Stefan Brüns]

The current code mixes three distinct operations when transforming
the slave config to register settings:

  1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0
  2. range checking
  3. conversion of raw to register values

As the range checks depend on the specific SoC, move these out of the
conversion to distinct operations.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 66 -
 1 file changed, 38 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a6fc066a0ac6..663f4b0b450e 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -118,6 +118,8 @@ struct sun6i_dma_config {
 */
void (*clock_autogate_enable)();
void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
+   u32 src_burst_lengths;
+   u32 dst_burst_lengths;
 };
 
 /*
@@ -266,10 +268,6 @@ static inline s8 convert_burst(u32 maxburst)
 
 static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
 {
-   if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
-   (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
-   return -EINVAL;
-
return addr_width >> 1;
 }
 
@@ -542,41 +540,43 @@ static int set_config(struct sun6i_dma_dev *sdev,
enum dma_transfer_direction direction,
u32 *p_cfg)
 {
+   enum dma_slave_buswidth src_addr_width, dst_addr_width;
+   u32 src_maxburst, dst_maxburst;
s8 src_width, dst_width, src_burst, dst_burst;
 
+   src_addr_width = sconfig->src_addr_width;
+   dst_addr_width = sconfig->dst_addr_width;
+   src_maxburst = sconfig->src_maxburst;
+   dst_maxburst = sconfig->dst_maxburst;
+
switch (direction) {
case DMA_MEM_TO_DEV:
-   src_burst = convert_burst(sconfig->src_maxburst ?
-   sconfig->src_maxburst : 8);
-   src_width = convert_buswidth(sconfig->src_addr_width !=
-   DMA_SLAVE_BUSWIDTH_UNDEFINED ?
-   sconfig->src_addr_width :
-   DMA_SLAVE_BUSWIDTH_4_BYTES);
-   dst_burst = convert_burst(sconfig->dst_maxburst);
-   dst_width = convert_buswidth(sconfig->dst_addr_width);
+   if (src_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+   src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   src_maxburst = src_maxburst ? src_maxburst : 8;
break;
case DMA_DEV_TO_MEM:
-   src_burst = convert_burst(sconfig->src_maxburst);
-   src_width = convert_buswidth(sconfig->src_addr_width);
-   dst_burst = convert_burst(sconfig->dst_maxburst ?
-   sconfig->dst_maxburst : 8);
-   dst_width = convert_buswidth(sconfig->dst_addr_width !=
-   DMA_SLAVE_BUSWIDTH_UNDEFINED ?
-   sconfig->dst_addr_width :
-   DMA_SLAVE_BUSWIDTH_4_BYTES);
+   if (dst_addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED)
+   dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dst_maxburst = dst_maxburst ? dst_maxburst : 8;
break;
default:
return -EINVAL;
}
 
-   if (src_burst < 0)
-   return src_burst;
-   if (src_width < 0)
-   return src_width;
-   if (dst_burst < 0)
-   return dst_burst;
-   if (dst_width < 0)
-   return dst_width;
+   if (!(BIT(src_addr_width) & sdev->slave.src_addr_widths))
+   return -EINVAL;
+   if (!(BIT(dst_addr_width) & sdev->slave.dst_addr_widths))
+   return -EINVAL;
+   if (!(BIT(src_maxburst) & sdev->cfg->src_burst_lengths))
+   return -EINVAL;
+   if (!(BIT(dst_maxburst) & sdev->cfg->dst_burst_lengths))
+   return -EINVAL;
+
+   src_width = convert_buswidth(src_addr_width);
+   dst_width = convert_buswidth(dst_addr_width);
+   dst_burst = convert_burst(dst_maxburst);
+   src_burst = convert_burst(src_maxburst);
 
*p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
DMA_CHAN_CFG_DST_WIDTH(dst_width);
@@ -1043,6 +1043,8 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_vchans   = 53,
.clock_autogate_enable = sun6i_enable_clock_autogate_noop;
.set_burst_length = sun6i_set_burst_length_a31;
+   .src_burst_lengths = BIT(1) | BIT(8);
+   .dst_burst_lengths = BIT(1) | BIT(8);
 };
 
 /*
@@ -1056,6 +1058,8 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_vchans   = 37,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
.set_burst_length = sun6i_set_burst_length_a31;
+   .src_burst_lengths = BIT(1) | 

[PATCH v2 04/10] dmaengine: sun6i: Enable additional burst lengths/widths on H3

[Stefan Brüns]

The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with
a width of 1, 2, 4 or 8 bytes.

The register value for the the width is log2-encoded, change the
conversion function to provide the correct value for width == 8.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 54 -
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 663f4b0b450e..f2ee914cd755 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -120,6 +120,8 @@ struct sun6i_dma_config {
void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
u32 src_burst_lengths;
u32 dst_burst_lengths;
+   u32 src_addr_widths;
+   u32 dst_addr_widths;
 };
 
 /*
@@ -259,8 +261,12 @@ static inline s8 convert_burst(u32 maxburst)
switch (maxburst) {
case 1:
return 0;
+   case 4:
+   return 1;
case 8:
return 2;
+   case 16:
+   return 3;
default:
return -EINVAL;
}
@@ -268,7 +274,7 @@ static inline s8 convert_burst(u32 maxburst)
 
 static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
 {
-   return addr_width >> 1;
+   return ilog2(addr_width);
 }
 
 static void sun6i_enable_clock_autogate_noop(struct sun6i_dma_dev *sdev)
@@ -1045,6 +1051,12 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 /*
@@ -1060,6 +1072,12 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
@@ -1070,11 +1088,19 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
+ * It also supports additional burst lengths and bus widths,
+ * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
@@ -1083,8 +1109,16 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_vchans   = 34,
.clock_autogate_enable = sun6i_enable_clock_autogate_h3;
.set_burst_length = sun6i_set_burst_length_h3;
-   .src_burst_lengths = BIT(1) | BIT(8);
-   .dst_burst_lengths = BIT(1) | BIT(8);
+   .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
 };
 
 /*
@@ -1100,6 +1134,12 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+

[PATCH v2 00/10] dmaengine: sun6i: Fixes for H3/A83T, enable A64

[Stefan Brüns]

Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T
(sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for
Allwinner H3 (sun8i) variant") added support for the A83T resp. H3, but missed
some differences between the original A31 and A83T/H3.

The first patch adds a callback to the controller config to set the clock
autogating register of different SoC generations, i.e. A31, A23+A83T, H3+later,
and uses it to for the correct clock autogating setting.

The second patch adds a callback for the burst length setting in the channel
config register, which has different field offsets and new burst widths/lengths,
which differs between H3 and earlier generations

The third patch restructures some code required for the fourth patch and adds 
the
burst lengths to the controller config.

The fourth patch adds the burst widths to the config and adds the handling of 
the
H3 specific burst widths.

Patch 5 restructures the code to decouple some controller details (e.g. channel
count) from the compatible string/the config.

Patches 6, 7 and 8 introduce and use the "dma-chans" property for the A64. 
Although
register compatible to the H3, the channel count differs and thus it requires a
new compatible. To avoid introduction of new compatibles for each minor 
variation,
anything but the register model is moved to devicetree properties. There
is at least one SoC (R40) which can then reuse the A64 compatible, the same
would have worked for A83T+V3s.

Patches 9 and 10 add the DMA controller node to the devicetree and add the DMA
controller reference to the SPI nodes.

This patch series could be called v2, but the patches were split and 
significantly
restructured, thus listing changes individually is not to meaningful.

Changes in v2:
- Use callback for autogating instead of variable for different SoC generations
- Use controller specific callback for burst length setting
- Store burst lengths in config instead of device structure
- Store burst widths in config
- Set default number of dma-request if not provided in config or devicetree

Stefan Brüns (10):
  dmaengine: sun6i: Correct setting of clock autogating register for
A83T/H3
  dmaengine: sun6i: Correct burst length field offsets for H3
  dmaengine: sun6i: Restructure code to allow extension for new SoCs
  dmaengine: sun6i: Enable additional burst lengths/widths on H3
  dmaengine: sun6i: Move number of pchans/vchans/request to device
struct
  arm64: allwinner: a64: Add devicetree binding for DMA controller
  dmaengine: sun6i: Retrieve channel count/max request from devicetree
  dmaengine: sun6i: Add support for Allwinner A64 and compatibles
  arm64: allwinner: a64: Add device node for DMA controller
  arm64: allwinner: a64: add dma controller references to spi nodes

 .../devicetree/bindings/dma/sun6i-dma.txt  |  26 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  15 ++
 drivers/dma/sun6i-dma.c| 265 -
 3 files changed, 248 insertions(+), 58 deletions(-)

-- 
2.14.1

[PATCH v2 04/10] dmaengine: sun6i: Enable additional burst lengths/widths on H3

[Stefan Brüns]

The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with
a width of 1, 2, 4 or 8 bytes.

The register value for the the width is log2-encoded, change the
conversion function to provide the correct value for width == 8.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 54 -
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 663f4b0b450e..f2ee914cd755 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -120,6 +120,8 @@ struct sun6i_dma_config {
void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
u32 src_burst_lengths;
u32 dst_burst_lengths;
+   u32 src_addr_widths;
+   u32 dst_addr_widths;
 };
 
 /*
@@ -259,8 +261,12 @@ static inline s8 convert_burst(u32 maxburst)
switch (maxburst) {
case 1:
return 0;
+   case 4:
+   return 1;
case 8:
return 2;
+   case 16:
+   return 3;
default:
return -EINVAL;
}
@@ -268,7 +274,7 @@ static inline s8 convert_burst(u32 maxburst)
 
 static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
 {
-   return addr_width >> 1;
+   return ilog2(addr_width);
 }
 
 static void sun6i_enable_clock_autogate_noop(struct sun6i_dma_dev *sdev)
@@ -1045,6 +1051,12 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 /*
@@ -1060,6 +1072,12 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
@@ -1070,11 +1088,19 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
+ * It also supports additional burst lengths and bus widths,
+ * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
@@ -1083,8 +1109,16 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_vchans   = 34,
.clock_autogate_enable = sun6i_enable_clock_autogate_h3;
.set_burst_length = sun6i_set_burst_length_h3;
-   .src_burst_lengths = BIT(1) | BIT(8);
-   .dst_burst_lengths = BIT(1) | BIT(8);
+   .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
 };
 
 /*
@@ -1100,6 +1134,12 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
.set_burst_length = sun6i_set_burst_length_a31;
.src_burst_lengths = BIT(1) | BIT(8);
.dst_burst_lengths = BIT(1) | BIT(8);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+   .dst_addr_widths   

[PATCH v2 00/10] dmaengine: sun6i: Fixes for H3/A83T, enable A64

[Stefan Brüns]

Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T
(sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for
Allwinner H3 (sun8i) variant") added support for the A83T resp. H3, but missed
some differences between the original A31 and A83T/H3.

The first patch adds a callback to the controller config to set the clock
autogating register of different SoC generations, i.e. A31, A23+A83T, H3+later,
and uses it to for the correct clock autogating setting.

The second patch adds a callback for the burst length setting in the channel
config register, which has different field offsets and new burst widths/lengths,
which differs between H3 and earlier generations

The third patch restructures some code required for the fourth patch and adds 
the
burst lengths to the controller config.

The fourth patch adds the burst widths to the config and adds the handling of 
the
H3 specific burst widths.

Patch 5 restructures the code to decouple some controller details (e.g. channel
count) from the compatible string/the config.

Patches 6, 7 and 8 introduce and use the "dma-chans" property for the A64. 
Although
register compatible to the H3, the channel count differs and thus it requires a
new compatible. To avoid introduction of new compatibles for each minor 
variation,
anything but the register model is moved to devicetree properties. There
is at least one SoC (R40) which can then reuse the A64 compatible, the same
would have worked for A83T+V3s.

Patches 9 and 10 add the DMA controller node to the devicetree and add the DMA
controller reference to the SPI nodes.

This patch series could be called v2, but the patches were split and 
significantly
restructured, thus listing changes individually is not to meaningful.

Changes in v2:
- Use callback for autogating instead of variable for different SoC generations
- Use controller specific callback for burst length setting
- Store burst lengths in config instead of device structure
- Store burst widths in config
- Set default number of dma-request if not provided in config or devicetree

Stefan Brüns (10):
  dmaengine: sun6i: Correct setting of clock autogating register for
A83T/H3
  dmaengine: sun6i: Correct burst length field offsets for H3
  dmaengine: sun6i: Restructure code to allow extension for new SoCs
  dmaengine: sun6i: Enable additional burst lengths/widths on H3
  dmaengine: sun6i: Move number of pchans/vchans/request to device
struct
  arm64: allwinner: a64: Add devicetree binding for DMA controller
  dmaengine: sun6i: Retrieve channel count/max request from devicetree
  dmaengine: sun6i: Add support for Allwinner A64 and compatibles
  arm64: allwinner: a64: Add device node for DMA controller
  arm64: allwinner: a64: add dma controller references to spi nodes

 .../devicetree/bindings/dma/sun6i-dma.txt  |  26 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  15 ++
 drivers/dma/sun6i-dma.c| 265 -
 3 files changed, 248 insertions(+), 58 deletions(-)

-- 
2.14.1

[PATCH v2 02/10] dmaengine: sun6i: Correct burst length field offsets for H3

[Stefan Brüns]

For the H3, the burst lengths field offsets in the channel configuration
register differs from earlier SoC generations.

Using the A31 register macros actually configured the H3 controller
do to bursts of length 1 always, which although working leads to higher
bus utilisation.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 45bcd5271d94..a6fc066a0ac6 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -68,13 +68,15 @@
 #define DMA_CHAN_CFG_SRC_DRQ(x)((x) & 0x1f)
 #define DMA_CHAN_CFG_SRC_IO_MODE   BIT(5)
 #define DMA_CHAN_CFG_SRC_LINEAR_MODE   (0 << 5)
-#define DMA_CHAN_CFG_SRC_BURST(x)  (((x) & 0x3) << 7)
+#define DMA_CHAN_CFG_SRC_BURST_A31(x)  (((x) & 0x3) << 7)
+#define DMA_CHAN_CFG_SRC_BURST_H3(x)   (((x) & 0x3) << 6)
 #define DMA_CHAN_CFG_SRC_WIDTH(x)  (((x) & 0x3) << 9)
 
 #define DMA_CHAN_CFG_DST_DRQ(x)(DMA_CHAN_CFG_SRC_DRQ(x) << 16)
 #define DMA_CHAN_CFG_DST_IO_MODE   (DMA_CHAN_CFG_SRC_IO_MODE << 16)
 #define DMA_CHAN_CFG_DST_LINEAR_MODE   (DMA_CHAN_CFG_SRC_LINEAR_MODE << 16)
-#define DMA_CHAN_CFG_DST_BURST(x)  (DMA_CHAN_CFG_SRC_BURST(x) << 16)
+#define DMA_CHAN_CFG_DST_BURST_A31(x)  (DMA_CHAN_CFG_SRC_BURST_A31(x) << 16)
+#define DMA_CHAN_CFG_DST_BURST_H3(x)   (DMA_CHAN_CFG_SRC_BURST_H3(x) << 16)
 #define DMA_CHAN_CFG_DST_WIDTH(x)  (DMA_CHAN_CFG_SRC_WIDTH(x) << 16)
 
 #define DMA_CHAN_CUR_SRC   0x10
@@ -115,6 +117,7 @@ struct sun6i_dma_config {
 * BSP kernel source code.
 */
void (*clock_autogate_enable)();
+   void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
 };
 
 /*
@@ -284,6 +287,18 @@ static void sun6i_enable_clock_autogate_h3(struct 
sun6i_dma_dev *sdev)
writel(SUNXI_H3_DMA_GATE_ENABLE, sdev->base + SUNXI_H3_DMA_GATE);
 }
 
+static void sun6i_set_burst_length_a31(u32 *p_cfg, s8 src_burst, s8 dst_burst)
+{
+   *p_cfg |= DMA_CHAN_CFG_SRC_BURST_A31(src_burst) |
+ DMA_CHAN_CFG_DST_BURST_A31(dst_burst);
+}
+
+static void sun6i_set_burst_length_h3(u32 *p_cfg, s8 src_burst, s8 dst_burst)
+{
+   *p_cfg |= DMA_CHAN_CFG_SRC_BURST_H3(src_burst) |
+ DMA_CHAN_CFG_DST_BURST_H3(dst_burst);
+}
+
 static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
 {
struct sun6i_desc *txd = pchan->desc;
@@ -563,11 +578,11 @@ static int set_config(struct sun6i_dma_dev *sdev,
if (dst_width < 0)
return dst_width;
 
-   *p_cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |
-   DMA_CHAN_CFG_SRC_WIDTH(src_width) |
-   DMA_CHAN_CFG_DST_BURST(dst_burst) |
+   *p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
DMA_CHAN_CFG_DST_WIDTH(dst_width);
 
+   sdev->cfg->set_burst_length(p_cfg, src_burst, dst_burst);
+
return 0;
 }
 
@@ -610,11 +625,11 @@ static struct dma_async_tx_descriptor 
*sun6i_dma_prep_dma_memcpy(
DMA_CHAN_CFG_DST_DRQ(DRQ_SDRAM) |
DMA_CHAN_CFG_DST_LINEAR_MODE |
DMA_CHAN_CFG_SRC_LINEAR_MODE |
-   DMA_CHAN_CFG_SRC_BURST(burst) |
DMA_CHAN_CFG_SRC_WIDTH(width) |
-   DMA_CHAN_CFG_DST_BURST(burst) |
DMA_CHAN_CFG_DST_WIDTH(width);
 
+   sdev->cfg->set_burst_length(v_lli->cfg, burst, burst);
+
sun6i_dma_lli_add(NULL, v_lli, p_lli, txd);
 
sun6i_dma_dump_lli(vchan, v_lli);
@@ -1027,6 +1042,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_requests = 30,
.nr_max_vchans   = 53,
.clock_autogate_enable = sun6i_enable_clock_autogate_noop;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 /*
@@ -1039,6 +1055,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_requests = 24,
.nr_max_vchans   = 37,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
@@ -1046,13 +1063,12 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.nr_max_requests = 28,
.nr_max_vchans   = 39,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
- * It also supports additional burst lengths and bus widths,
- * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
@@ -1060,6 +1076,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_requests = 27,
.nr_max_vchans   = 34,
.clock_autogate_enable = sun6i_enable_clock_autogate_h3;
+   .set_burst_length = 

[PATCH v2 02/10] dmaengine: sun6i: Correct burst length field offsets for H3

[Stefan Brüns]

For the H3, the burst lengths field offsets in the channel configuration
register differs from earlier SoC generations.

Using the A31 register macros actually configured the H3 controller
do to bursts of length 1 always, which although working leads to higher
bus utilisation.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 45bcd5271d94..a6fc066a0ac6 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -68,13 +68,15 @@
 #define DMA_CHAN_CFG_SRC_DRQ(x)((x) & 0x1f)
 #define DMA_CHAN_CFG_SRC_IO_MODE   BIT(5)
 #define DMA_CHAN_CFG_SRC_LINEAR_MODE   (0 << 5)
-#define DMA_CHAN_CFG_SRC_BURST(x)  (((x) & 0x3) << 7)
+#define DMA_CHAN_CFG_SRC_BURST_A31(x)  (((x) & 0x3) << 7)
+#define DMA_CHAN_CFG_SRC_BURST_H3(x)   (((x) & 0x3) << 6)
 #define DMA_CHAN_CFG_SRC_WIDTH(x)  (((x) & 0x3) << 9)
 
 #define DMA_CHAN_CFG_DST_DRQ(x)(DMA_CHAN_CFG_SRC_DRQ(x) << 16)
 #define DMA_CHAN_CFG_DST_IO_MODE   (DMA_CHAN_CFG_SRC_IO_MODE << 16)
 #define DMA_CHAN_CFG_DST_LINEAR_MODE   (DMA_CHAN_CFG_SRC_LINEAR_MODE << 16)
-#define DMA_CHAN_CFG_DST_BURST(x)  (DMA_CHAN_CFG_SRC_BURST(x) << 16)
+#define DMA_CHAN_CFG_DST_BURST_A31(x)  (DMA_CHAN_CFG_SRC_BURST_A31(x) << 16)
+#define DMA_CHAN_CFG_DST_BURST_H3(x)   (DMA_CHAN_CFG_SRC_BURST_H3(x) << 16)
 #define DMA_CHAN_CFG_DST_WIDTH(x)  (DMA_CHAN_CFG_SRC_WIDTH(x) << 16)
 
 #define DMA_CHAN_CUR_SRC   0x10
@@ -115,6 +117,7 @@ struct sun6i_dma_config {
 * BSP kernel source code.
 */
void (*clock_autogate_enable)();
+   void (*set_burst_length)(u32 *p_cfg, s8 src_burst, s8 dst_burst);
 };
 
 /*
@@ -284,6 +287,18 @@ static void sun6i_enable_clock_autogate_h3(struct 
sun6i_dma_dev *sdev)
writel(SUNXI_H3_DMA_GATE_ENABLE, sdev->base + SUNXI_H3_DMA_GATE);
 }
 
+static void sun6i_set_burst_length_a31(u32 *p_cfg, s8 src_burst, s8 dst_burst)
+{
+   *p_cfg |= DMA_CHAN_CFG_SRC_BURST_A31(src_burst) |
+ DMA_CHAN_CFG_DST_BURST_A31(dst_burst);
+}
+
+static void sun6i_set_burst_length_h3(u32 *p_cfg, s8 src_burst, s8 dst_burst)
+{
+   *p_cfg |= DMA_CHAN_CFG_SRC_BURST_H3(src_burst) |
+ DMA_CHAN_CFG_DST_BURST_H3(dst_burst);
+}
+
 static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
 {
struct sun6i_desc *txd = pchan->desc;
@@ -563,11 +578,11 @@ static int set_config(struct sun6i_dma_dev *sdev,
if (dst_width < 0)
return dst_width;
 
-   *p_cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |
-   DMA_CHAN_CFG_SRC_WIDTH(src_width) |
-   DMA_CHAN_CFG_DST_BURST(dst_burst) |
+   *p_cfg = DMA_CHAN_CFG_SRC_WIDTH(src_width) |
DMA_CHAN_CFG_DST_WIDTH(dst_width);
 
+   sdev->cfg->set_burst_length(p_cfg, src_burst, dst_burst);
+
return 0;
 }
 
@@ -610,11 +625,11 @@ static struct dma_async_tx_descriptor 
*sun6i_dma_prep_dma_memcpy(
DMA_CHAN_CFG_DST_DRQ(DRQ_SDRAM) |
DMA_CHAN_CFG_DST_LINEAR_MODE |
DMA_CHAN_CFG_SRC_LINEAR_MODE |
-   DMA_CHAN_CFG_SRC_BURST(burst) |
DMA_CHAN_CFG_SRC_WIDTH(width) |
-   DMA_CHAN_CFG_DST_BURST(burst) |
DMA_CHAN_CFG_DST_WIDTH(width);
 
+   sdev->cfg->set_burst_length(v_lli->cfg, burst, burst);
+
sun6i_dma_lli_add(NULL, v_lli, p_lli, txd);
 
sun6i_dma_dump_lli(vchan, v_lli);
@@ -1027,6 +1042,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_requests = 30,
.nr_max_vchans   = 53,
.clock_autogate_enable = sun6i_enable_clock_autogate_noop;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 /*
@@ -1039,6 +1055,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_requests = 24,
.nr_max_vchans   = 37,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
@@ -1046,13 +1063,12 @@ static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.nr_max_requests = 28,
.nr_max_vchans   = 39,
.clock_autogate_enable = sun6i_enable_clock_autogate_a23;
+   .set_burst_length = sun6i_set_burst_length_a31;
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
- * It also supports additional burst lengths and bus widths,
- * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
@@ -1060,6 +1076,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_requests = 27,
.nr_max_vchans   = 34,
.clock_autogate_enable = sun6i_enable_clock_autogate_h3;
+   .set_burst_length = sun6i_set_burst_length_h3;
 };
 
 /*
@@ 

[PATCH v2 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3

[Stefan Brüns]

The H83T uses a compatible string different from the A23, but requires
the same clock autogating register setting.

The H3 also requires setting the clock autogating register, but has
the register at a different offset.

Add three suitable callbacks for the existing controller generations
and set it in the controller config structure.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index bcd496edc70f..45bcd5271d94 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -48,6 +48,9 @@
 #define SUN8I_DMA_GATE 0x20
 #define SUN8I_DMA_GATE_ENABLE  0x4
 
+#define SUNXI_H3_SECURE_REG0x20
+#define SUNXI_H3_DMA_GATE  0x28
+#define SUNXI_H3_DMA_GATE_ENABLE   0x4
 /*
  * Channels specific registers
  */
@@ -111,7 +114,7 @@ struct sun6i_dma_config {
 * however these SoCs really have and need this bit, as seen in the
 * BSP kernel source code.
 */
-   bool gate_needed;
+   void (*clock_autogate_enable)();
 };
 
 /*
@@ -267,6 +270,20 @@ static inline s8 convert_buswidth(enum dma_slave_buswidth 
addr_width)
return addr_width >> 1;
 }
 
+static void sun6i_enable_clock_autogate_noop(struct sun6i_dma_dev *sdev)
+{
+}
+
+static void sun6i_enable_clock_autogate_a23(struct sun6i_dma_dev *sdev)
+{
+   writel(SUN8I_DMA_GATE_ENABLE, sdev->base + SUN8I_DMA_GATE);
+}
+
+static void sun6i_enable_clock_autogate_h3(struct sun6i_dma_dev *sdev)
+{
+   writel(SUNXI_H3_DMA_GATE_ENABLE, sdev->base + SUNXI_H3_DMA_GATE);
+}
+
 static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
 {
struct sun6i_desc *txd = pchan->desc;
@@ -1009,6 +1026,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_channels = 16,
.nr_max_requests = 30,
.nr_max_vchans   = 53,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_noop;
 };
 
 /*
@@ -1020,24 +1038,28 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 24,
.nr_max_vchans   = 37,
-   .gate_needed = true,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 28,
.nr_max_vchans   = 39,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
+ * It also supports additional burst lengths and bus widths,
+ * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_channels = 12,
.nr_max_requests = 27,
.nr_max_vchans   = 34,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_h3;
 };
 
 /*
@@ -1049,7 +1071,7 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 23,
.nr_max_vchans   = 24,
-   .gate_needed = true,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 static const struct of_device_id sun6i_dma_match[] = {
@@ -1199,8 +1221,7 @@ static int sun6i_dma_probe(struct platform_device *pdev)
goto err_dma_unregister;
}
 
-   if (sdc->cfg->gate_needed)
-   writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
+   sdc->cfg->clock_autogate_enable();
 
return 0;
 
-- 
2.14.1

[PATCH v2 09/10] arm64: allwinner: a64: Add device node for DMA controller

[Stefan Brüns]

The A64 SoC has a DMA controller that supports 8 DMA channels
to and from various peripherals. The last used DRQ port is 27.

Add a device node for it.

Signed-off-by: Stefan Brüns 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e9a9d7fb01c8..4f060ecdb061 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -136,6 +136,17 @@
reg = <0x01c0 0x1000>;
};
 
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun50i-a64-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   dma-channels = <8>;
+   dma-requests = <27>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.14.1

[PATCH v2 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3

[Stefan Brüns]

The H83T uses a compatible string different from the A23, but requires
the same clock autogating register setting.

The H3 also requires setting the clock autogating register, but has
the register at a different offset.

Add three suitable callbacks for the existing controller generations
and set it in the controller config structure.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index bcd496edc70f..45bcd5271d94 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -48,6 +48,9 @@
 #define SUN8I_DMA_GATE 0x20
 #define SUN8I_DMA_GATE_ENABLE  0x4
 
+#define SUNXI_H3_SECURE_REG0x20
+#define SUNXI_H3_DMA_GATE  0x28
+#define SUNXI_H3_DMA_GATE_ENABLE   0x4
 /*
  * Channels specific registers
  */
@@ -111,7 +114,7 @@ struct sun6i_dma_config {
 * however these SoCs really have and need this bit, as seen in the
 * BSP kernel source code.
 */
-   bool gate_needed;
+   void (*clock_autogate_enable)();
 };
 
 /*
@@ -267,6 +270,20 @@ static inline s8 convert_buswidth(enum dma_slave_buswidth 
addr_width)
return addr_width >> 1;
 }
 
+static void sun6i_enable_clock_autogate_noop(struct sun6i_dma_dev *sdev)
+{
+}
+
+static void sun6i_enable_clock_autogate_a23(struct sun6i_dma_dev *sdev)
+{
+   writel(SUN8I_DMA_GATE_ENABLE, sdev->base + SUN8I_DMA_GATE);
+}
+
+static void sun6i_enable_clock_autogate_h3(struct sun6i_dma_dev *sdev)
+{
+   writel(SUNXI_H3_DMA_GATE_ENABLE, sdev->base + SUNXI_H3_DMA_GATE);
+}
+
 static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
 {
struct sun6i_desc *txd = pchan->desc;
@@ -1009,6 +1026,7 @@ static struct sun6i_dma_config sun6i_a31_dma_cfg = {
.nr_max_channels = 16,
.nr_max_requests = 30,
.nr_max_vchans   = 53,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_noop;
 };
 
 /*
@@ -1020,24 +1038,28 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 24,
.nr_max_vchans   = 37,
-   .gate_needed = true,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 28,
.nr_max_vchans   = 39,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 /*
  * The H3 has 12 physical channels, a maximum DRQ port id of 27,
  * and a total of 34 usable source and destination endpoints.
+ * It also supports additional burst lengths and bus widths,
+ * and the burst length fields have different offsets.
  */
 
 static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_channels = 12,
.nr_max_requests = 27,
.nr_max_vchans   = 34,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_h3;
 };
 
 /*
@@ -1049,7 +1071,7 @@ static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 23,
.nr_max_vchans   = 24,
-   .gate_needed = true,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_a23;
 };
 
 static const struct of_device_id sun6i_dma_match[] = {
@@ -1199,8 +1221,7 @@ static int sun6i_dma_probe(struct platform_device *pdev)
goto err_dma_unregister;
}
 
-   if (sdc->cfg->gate_needed)
-   writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
+   sdc->cfg->clock_autogate_enable();
 
return 0;
 
-- 
2.14.1

[PATCH v2 09/10] arm64: allwinner: a64: Add device node for DMA controller

[Stefan Brüns]

The A64 SoC has a DMA controller that supports 8 DMA channels
to and from various peripherals. The last used DRQ port is 27.

Add a device node for it.

Signed-off-by: Stefan Brüns 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e9a9d7fb01c8..4f060ecdb061 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -136,6 +136,17 @@
reg = <0x01c0 0x1000>;
};
 
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun50i-a64-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   dma-channels = <8>;
+   dma-requests = <27>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.14.1

[PATCH v2 05/10] dmaengine: sun6i: Move number of pchans/vchans/request to device struct

[Stefan Brüns]

Preparatory patch: If the same compatible is used for different SoCs which
have a common register layout, but different number of channels, the
channel count can no longer be stored in the config. Store it in the
device structure instead.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index f2ee914cd755..245a147f718f 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -185,6 +185,9 @@ struct sun6i_dma_dev {
struct sun6i_pchan  *pchans;
struct sun6i_vchan  *vchans;
const struct sun6i_dma_config *cfg;
+   u32 num_pchans;
+   u32 num_vchans;
+   u32 max_request;
 };
 
 static struct device *chan2dev(struct dma_chan *chan)
@@ -435,7 +438,6 @@ static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
 static void sun6i_dma_tasklet(unsigned long data)
 {
struct sun6i_dma_dev *sdev = (struct sun6i_dma_dev *)data;
-   const struct sun6i_dma_config *cfg = sdev->cfg;
struct sun6i_vchan *vchan;
struct sun6i_pchan *pchan;
unsigned int pchan_alloc = 0;
@@ -463,7 +465,7 @@ static void sun6i_dma_tasklet(unsigned long data)
}
 
spin_lock_irq(>lock);
-   for (pchan_idx = 0; pchan_idx < cfg->nr_max_channels; pchan_idx++) {
+   for (pchan_idx = 0; pchan_idx < sdev->num_pchans; pchan_idx++) {
pchan = >pchans[pchan_idx];
 
if (pchan->vchan || list_empty(>pending))
@@ -484,7 +486,7 @@ static void sun6i_dma_tasklet(unsigned long data)
}
spin_unlock_irq(>lock);
 
-   for (pchan_idx = 0; pchan_idx < cfg->nr_max_channels; pchan_idx++) {
+   for (pchan_idx = 0; pchan_idx < sdev->num_pchans; pchan_idx++) {
if (!(pchan_alloc & BIT(pchan_idx)))
continue;
 
@@ -506,7 +508,7 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void 
*dev_id)
int i, j, ret = IRQ_NONE;
u32 status;
 
-   for (i = 0; i < sdev->cfg->nr_max_channels / DMA_IRQ_CHAN_NR; i++) {
+   for (i = 0; i < sdev->num_pchans / DMA_IRQ_CHAN_NR; i++) {
status = readl(sdev->base + DMA_IRQ_STAT(i));
if (!status)
continue;
@@ -986,7 +988,7 @@ static struct dma_chan *sun6i_dma_of_xlate(struct 
of_phandle_args *dma_spec,
struct dma_chan *chan;
u8 port = dma_spec->args[0];
 
-   if (port > sdev->cfg->nr_max_requests)
+   if (port > sdev->max_request)
return NULL;
 
chan = dma_get_any_slave_channel(>slave);
@@ -1019,7 +1021,7 @@ static inline void sun6i_dma_free(struct sun6i_dma_dev 
*sdev)
 {
int i;
 
-   for (i = 0; i < sdev->cfg->nr_max_vchans; i++) {
+   for (i = 0; i < sdev->num_vchans; i++) {
struct sun6i_vchan *vchan = >vchans[i];
 
list_del(>vc.chan.device_node);
@@ -1226,26 +1228,30 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->slave.residue_granularity  = DMA_RESIDUE_GRANULARITY_BURST;
sdc->slave.dev = >dev;
 
-   sdc->pchans = devm_kcalloc(>dev, sdc->cfg->nr_max_channels,
+   sdc->num_pchans = sdc->cfg->nr_max_channels;
+   sdc->num_vchans = sdc->cfg->nr_max_vchans;
+   sdc->max_request = sdc->cfg->nr_max_requests;
+
+   sdc->pchans = devm_kcalloc(>dev, sdc->num_pchans,
   sizeof(struct sun6i_pchan), GFP_KERNEL);
if (!sdc->pchans)
return -ENOMEM;
 
-   sdc->vchans = devm_kcalloc(>dev, sdc->cfg->nr_max_vchans,
+   sdc->vchans = devm_kcalloc(>dev, sdc->num_vchans,
   sizeof(struct sun6i_vchan), GFP_KERNEL);
if (!sdc->vchans)
return -ENOMEM;
 
tasklet_init(>task, sun6i_dma_tasklet, (unsigned long)sdc);
 
-   for (i = 0; i < sdc->cfg->nr_max_channels; i++) {
+   for (i = 0; i < sdc->num_pchans; i++) {
struct sun6i_pchan *pchan = >pchans[i];
 
pchan->idx = i;
pchan->base = sdc->base + 0x100 + i * 0x40;
}
 
-   for (i = 0; i < sdc->cfg->nr_max_vchans; i++) {
+   for (i = 0; i < sdc->num_vchans; i++) {
struct sun6i_vchan *vchan = >vchans[i];
 
INIT_LIST_HEAD(>node);
-- 
2.14.1

[PATCH v2 05/10] dmaengine: sun6i: Move number of pchans/vchans/request to device struct

[Stefan Brüns]

Preparatory patch: If the same compatible is used for different SoCs which
have a common register layout, but different number of channels, the
channel count can no longer be stored in the config. Store it in the
device structure instead.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index f2ee914cd755..245a147f718f 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -185,6 +185,9 @@ struct sun6i_dma_dev {
struct sun6i_pchan  *pchans;
struct sun6i_vchan  *vchans;
const struct sun6i_dma_config *cfg;
+   u32 num_pchans;
+   u32 num_vchans;
+   u32 max_request;
 };
 
 static struct device *chan2dev(struct dma_chan *chan)
@@ -435,7 +438,6 @@ static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
 static void sun6i_dma_tasklet(unsigned long data)
 {
struct sun6i_dma_dev *sdev = (struct sun6i_dma_dev *)data;
-   const struct sun6i_dma_config *cfg = sdev->cfg;
struct sun6i_vchan *vchan;
struct sun6i_pchan *pchan;
unsigned int pchan_alloc = 0;
@@ -463,7 +465,7 @@ static void sun6i_dma_tasklet(unsigned long data)
}
 
spin_lock_irq(>lock);
-   for (pchan_idx = 0; pchan_idx < cfg->nr_max_channels; pchan_idx++) {
+   for (pchan_idx = 0; pchan_idx < sdev->num_pchans; pchan_idx++) {
pchan = >pchans[pchan_idx];
 
if (pchan->vchan || list_empty(>pending))
@@ -484,7 +486,7 @@ static void sun6i_dma_tasklet(unsigned long data)
}
spin_unlock_irq(>lock);
 
-   for (pchan_idx = 0; pchan_idx < cfg->nr_max_channels; pchan_idx++) {
+   for (pchan_idx = 0; pchan_idx < sdev->num_pchans; pchan_idx++) {
if (!(pchan_alloc & BIT(pchan_idx)))
continue;
 
@@ -506,7 +508,7 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void 
*dev_id)
int i, j, ret = IRQ_NONE;
u32 status;
 
-   for (i = 0; i < sdev->cfg->nr_max_channels / DMA_IRQ_CHAN_NR; i++) {
+   for (i = 0; i < sdev->num_pchans / DMA_IRQ_CHAN_NR; i++) {
status = readl(sdev->base + DMA_IRQ_STAT(i));
if (!status)
continue;
@@ -986,7 +988,7 @@ static struct dma_chan *sun6i_dma_of_xlate(struct 
of_phandle_args *dma_spec,
struct dma_chan *chan;
u8 port = dma_spec->args[0];
 
-   if (port > sdev->cfg->nr_max_requests)
+   if (port > sdev->max_request)
return NULL;
 
chan = dma_get_any_slave_channel(>slave);
@@ -1019,7 +1021,7 @@ static inline void sun6i_dma_free(struct sun6i_dma_dev 
*sdev)
 {
int i;
 
-   for (i = 0; i < sdev->cfg->nr_max_vchans; i++) {
+   for (i = 0; i < sdev->num_vchans; i++) {
struct sun6i_vchan *vchan = >vchans[i];
 
list_del(>vc.chan.device_node);
@@ -1226,26 +1228,30 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->slave.residue_granularity  = DMA_RESIDUE_GRANULARITY_BURST;
sdc->slave.dev = >dev;
 
-   sdc->pchans = devm_kcalloc(>dev, sdc->cfg->nr_max_channels,
+   sdc->num_pchans = sdc->cfg->nr_max_channels;
+   sdc->num_vchans = sdc->cfg->nr_max_vchans;
+   sdc->max_request = sdc->cfg->nr_max_requests;
+
+   sdc->pchans = devm_kcalloc(>dev, sdc->num_pchans,
   sizeof(struct sun6i_pchan), GFP_KERNEL);
if (!sdc->pchans)
return -ENOMEM;
 
-   sdc->vchans = devm_kcalloc(>dev, sdc->cfg->nr_max_vchans,
+   sdc->vchans = devm_kcalloc(>dev, sdc->num_vchans,
   sizeof(struct sun6i_vchan), GFP_KERNEL);
if (!sdc->vchans)
return -ENOMEM;
 
tasklet_init(>task, sun6i_dma_tasklet, (unsigned long)sdc);
 
-   for (i = 0; i < sdc->cfg->nr_max_channels; i++) {
+   for (i = 0; i < sdc->num_pchans; i++) {
struct sun6i_pchan *pchan = >pchans[i];
 
pchan->idx = i;
pchan->base = sdc->base + 0x100 + i * 0x40;
}
 
-   for (i = 0; i < sdc->cfg->nr_max_vchans; i++) {
+   for (i = 0; i < sdc->num_vchans; i++) {
struct sun6i_vchan *vchan = >vchans[i];
 
INIT_LIST_HEAD(>node);
-- 
2.14.1

[PATCH v2 10/10] arm64: allwinner: a64: add dma controller references to spi nodes

[Stefan Brüns]

The spi controller nodes omit the dma controller/channel references, add
it.

This does not yet enable DMA for SPI transfers, as the spi-sun6i driver
lacks support for DMA, but always uses PIO to the FIFO.

Signed-off-by: Stefan Brüns 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 4f060ecdb061..ec71c48b393d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -476,6 +476,8 @@
interrupts = ;
clocks = < CLK_BUS_SPI0>, < CLK_SPI0>;
clock-names = "ahb", "mod";
+   dmas = < 23>, < 23>;
+   dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
resets = < RST_BUS_SPI0>;
@@ -491,6 +493,8 @@
interrupts = ;
clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
clock-names = "ahb", "mod";
+   dmas = < 24>, < 24>;
+   dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
resets = < RST_BUS_SPI1>;
-- 
2.14.1

[PATCH v2 10/10] arm64: allwinner: a64: add dma controller references to spi nodes

[Stefan Brüns]

The spi controller nodes omit the dma controller/channel references, add
it.

This does not yet enable DMA for SPI transfers, as the spi-sun6i driver
lacks support for DMA, but always uses PIO to the FIFO.

Signed-off-by: Stefan Brüns 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 4f060ecdb061..ec71c48b393d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -476,6 +476,8 @@
interrupts = ;
clocks = < CLK_BUS_SPI0>, < CLK_SPI0>;
clock-names = "ahb", "mod";
+   dmas = < 23>, < 23>;
+   dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
resets = < RST_BUS_SPI0>;
@@ -491,6 +493,8 @@
interrupts = ;
clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
clock-names = "ahb", "mod";
+   dmas = < 24>, < 24>;
+   dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
resets = < RST_BUS_SPI1>;
-- 
2.14.1

[PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

[Stefan Brüns]

To avoid introduction of a new compatible for each small SoC/DMA controller
variation, move the definition of the channel count to the devicetree.

The number of vchans is no longer explicit, but limited by the highest
port/DMA request number. The result is a slight overallocation for SoCs
with a sparse port mapping.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 245a147f718f..b5ecc97a0d5a 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -42,6 +42,9 @@
 
 #define DMA_STAT   0x30
 
+/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels */
+#define DMA_MAX_CHANNELS   (DMA_IRQ_CHAN_NR * 0x10 / 4)
+
 /*
  * sun8i specific registers
  */
@@ -65,7 +68,8 @@
 #define DMA_CHAN_LLI_ADDR  0x08
 
 #define DMA_CHAN_CUR_CFG   0x0c
-#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & 0x1f)
+#define DMA_CHAN_MAX_DRQ   0x1f
+#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & DMA_CHAN_MAX_DRQ)
 #define DMA_CHAN_CFG_SRC_IO_MODE   BIT(5)
 #define DMA_CHAN_CFG_SRC_LINEAR_MODE   (0 << 5)
 #define DMA_CHAN_CFG_SRC_BURST_A31(x)  (((x) & 0x3) << 7)
@@ -1157,6 +1161,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);
 static int sun6i_dma_probe(struct platform_device *pdev)
 {
const struct of_device_id *device;
+   struct device_node *np = pdev->dev.of_node;
struct sun6i_dma_dev *sdc;
struct resource *res;
int ret, i;
@@ -1232,6 +1237,36 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->num_vchans = sdc->cfg->nr_max_vchans;
sdc->max_request = sdc->cfg->nr_max_requests;
 
+   ret = of_property_read_u32(np, "dma-channels", >num_pchans);
+   if (ret && !sdc->num_pchans) {
+   dev_err(>dev, "Can't get dma-channels.\n");
+   return ret;
+   }
+
+   if (sdc->num_pchans > DMA_MAX_CHANNELS) {
+   dev_err(>dev, "Number of dma-channels out of range.\n");
+   return -EINVAL;
+   }
+
+   ret = of_property_read_u32(np, "dma-requests", >max_request);
+   if (ret && !sdc->max_request) {
+   dev_info(>dev, "Missing dma-requests, using %u.\n",
+DMA_CHAN_MAX_DRQ);
+   sdc->max_request = DMA_CHAN_MAX_DRQ;
+   }
+
+   if (sdc->max_request > DMA_CHAN_MAX_DRQ) {
+   dev_err(>dev, "Value of dma-requests out of range.\n");
+   return -EINVAL;
+   }
+
+   /*
+* If the number of vchans is not specified, derive it from the
+* highest port number, at most one channel per port and direction.
+*/
+   if (!sdc->num_vchans)
+   sdc->num_vchans = 2 * (sdc->max_request + 1);
+
sdc->pchans = devm_kcalloc(>dev, sdc->num_pchans,
   sizeof(struct sun6i_pchan), GFP_KERNEL);
if (!sdc->pchans)
-- 
2.14.1

[PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

[Stefan Brüns]

To avoid introduction of a new compatible for each small SoC/DMA controller
variation, move the definition of the channel count to the devicetree.

The number of vchans is no longer explicit, but limited by the highest
port/DMA request number. The result is a slight overallocation for SoCs
with a sparse port mapping.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 245a147f718f..b5ecc97a0d5a 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -42,6 +42,9 @@
 
 #define DMA_STAT   0x30
 
+/* Offset between DMA_IRQ_EN and DMA_IRQ_STAT limits number of channels */
+#define DMA_MAX_CHANNELS   (DMA_IRQ_CHAN_NR * 0x10 / 4)
+
 /*
  * sun8i specific registers
  */
@@ -65,7 +68,8 @@
 #define DMA_CHAN_LLI_ADDR  0x08
 
 #define DMA_CHAN_CUR_CFG   0x0c
-#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & 0x1f)
+#define DMA_CHAN_MAX_DRQ   0x1f
+#define DMA_CHAN_CFG_SRC_DRQ(x)((x) & DMA_CHAN_MAX_DRQ)
 #define DMA_CHAN_CFG_SRC_IO_MODE   BIT(5)
 #define DMA_CHAN_CFG_SRC_LINEAR_MODE   (0 << 5)
 #define DMA_CHAN_CFG_SRC_BURST_A31(x)  (((x) & 0x3) << 7)
@@ -1157,6 +1161,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dma_match);
 static int sun6i_dma_probe(struct platform_device *pdev)
 {
const struct of_device_id *device;
+   struct device_node *np = pdev->dev.of_node;
struct sun6i_dma_dev *sdc;
struct resource *res;
int ret, i;
@@ -1232,6 +1237,36 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->num_vchans = sdc->cfg->nr_max_vchans;
sdc->max_request = sdc->cfg->nr_max_requests;
 
+   ret = of_property_read_u32(np, "dma-channels", >num_pchans);
+   if (ret && !sdc->num_pchans) {
+   dev_err(>dev, "Can't get dma-channels.\n");
+   return ret;
+   }
+
+   if (sdc->num_pchans > DMA_MAX_CHANNELS) {
+   dev_err(>dev, "Number of dma-channels out of range.\n");
+   return -EINVAL;
+   }
+
+   ret = of_property_read_u32(np, "dma-requests", >max_request);
+   if (ret && !sdc->max_request) {
+   dev_info(>dev, "Missing dma-requests, using %u.\n",
+DMA_CHAN_MAX_DRQ);
+   sdc->max_request = DMA_CHAN_MAX_DRQ;
+   }
+
+   if (sdc->max_request > DMA_CHAN_MAX_DRQ) {
+   dev_err(>dev, "Value of dma-requests out of range.\n");
+   return -EINVAL;
+   }
+
+   /*
+* If the number of vchans is not specified, derive it from the
+* highest port number, at most one channel per port and direction.
+*/
+   if (!sdc->num_vchans)
+   sdc->num_vchans = 2 * (sdc->max_request + 1);
+
sdc->pchans = devm_kcalloc(>dev, sdc->num_pchans,
   sizeof(struct sun6i_pchan), GFP_KERNEL);
if (!sdc->pchans)
-- 
2.14.1

[PATCH v2 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles

[Stefan Brüns]

The A64 SoC has the same dma engine as the H3 (sun8i), with a
reduced amount of physical channels. To allow future reuse of the
compatible, leave the channel count etc. in the config data blank
and retrieve it from the devicetree.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index b5ecc97a0d5a..118b29bb1eac 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1127,6 +1127,28 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
 BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
 };
 
+/*
+ * The A64 binding uses the number of dma channels from the
+ * device tree node.
+ */
+static struct sun6i_dma_config sun50i_a64_dma_cfg = {
+   .nr_max_channels = 0,
+   .nr_max_requests = 0,
+   .nr_max_vchans   = 0,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_h3;
+   .set_burst_length = sun6i_set_burst_length_h3;
+   .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+};
+
 /*
  * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
  * and a total of 24 usable source and destination endpoints.
@@ -1154,6 +1176,7 @@ static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun8i-a83t-dma", .data = _a83t_dma_cfg 
},
{ .compatible = "allwinner,sun8i-h3-dma", .data = _h3_dma_cfg },
{ .compatible = "allwinner,sun8i-v3s-dma", .data = _v3s_dma_cfg },
+   { .compatible = "allwinner,sun50i-a64-dma", .data = _a64_dma_cfg 
},
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dma_match);
-- 
2.14.1

[PATCH v2 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles

[Stefan Brüns]

The A64 SoC has the same dma engine as the H3 (sun8i), with a
reduced amount of physical channels. To allow future reuse of the
compatible, leave the channel count etc. in the config data blank
and retrieve it from the devicetree.

Signed-off-by: Stefan Brüns 
---
 drivers/dma/sun6i-dma.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index b5ecc97a0d5a..118b29bb1eac 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1127,6 +1127,28 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
 BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
 };
 
+/*
+ * The A64 binding uses the number of dma channels from the
+ * device tree node.
+ */
+static struct sun6i_dma_config sun50i_a64_dma_cfg = {
+   .nr_max_channels = 0,
+   .nr_max_requests = 0,
+   .nr_max_vchans   = 0,
+   .clock_autogate_enable = sun6i_enable_clock_autogate_h3;
+   .set_burst_length = sun6i_set_burst_length_h3;
+   .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16);
+   .src_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+   .dst_addr_widths   = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES) |
+BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+};
+
 /*
  * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
  * and a total of 24 usable source and destination endpoints.
@@ -1154,6 +1176,7 @@ static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun8i-a83t-dma", .data = _a83t_dma_cfg 
},
{ .compatible = "allwinner,sun8i-h3-dma", .data = _h3_dma_cfg },
{ .compatible = "allwinner,sun8i-v3s-dma", .data = _v3s_dma_cfg },
+   { .compatible = "allwinner,sun50i-a64-dma", .data = _a64_dma_cfg 
},
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, sun6i_dma_match);
-- 
2.14.1

[PATCH v2 06/10] arm64: allwinner: a64: Add devicetree binding for DMA controller

[Stefan Brüns]

The A64 is register compatible with the H3, but has a different number
of dma channels and request ports.

Attach additional properties to the node to allow future reuse of the
compatible for controllers with different number of channels/requests.

If dma-requests is not specified, the register layout defined maximum
of 32 is used.

Signed-off-by: Stefan Brüns 
---
 .../devicetree/bindings/dma/sun6i-dma.txt  | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt 
b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index 98fbe1a5c6dd..6ebc79f95202 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -27,6 +27,32 @@ Example:
#dma-cells = <1>;
};
 
+--
+For A64 DMA controller:
+
+Required properties:
+- compatible:  "allwinner,sun50i-a64-dma"
+- dma-channels: Number of DMA channels supported by the controller.
+   Refer to Documentation/devicetree/bindings/dma/dma.txt
+- all properties above, i.e. reg, interrupts, clocks, resets and #dma-cells
+
+Optional properties:
+- dma-requests: Number of DMA request signals supported by the controller.
+   Refer to Documentation/devicetree/bindings/dma/dma.txt
+
+Example:
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun50i-a64-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   dma-channels = <8>;
+   dma-requests = <27>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+--
+
 Clients:
 
 DMA clients connected to the A31 DMA controller must use the format
-- 
2.14.1

[PATCH v2 06/10] arm64: allwinner: a64: Add devicetree binding for DMA controller

[Stefan Brüns]

The A64 is register compatible with the H3, but has a different number
of dma channels and request ports.

Attach additional properties to the node to allow future reuse of the
compatible for controllers with different number of channels/requests.

If dma-requests is not specified, the register layout defined maximum
of 32 is used.

Signed-off-by: Stefan Brüns 
---
 .../devicetree/bindings/dma/sun6i-dma.txt  | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt 
b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index 98fbe1a5c6dd..6ebc79f95202 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -27,6 +27,32 @@ Example:
#dma-cells = <1>;
};
 
+--
+For A64 DMA controller:
+
+Required properties:
+- compatible:  "allwinner,sun50i-a64-dma"
+- dma-channels: Number of DMA channels supported by the controller.
+   Refer to Documentation/devicetree/bindings/dma/dma.txt
+- all properties above, i.e. reg, interrupts, clocks, resets and #dma-cells
+
+Optional properties:
+- dma-requests: Number of DMA request signals supported by the controller.
+   Refer to Documentation/devicetree/bindings/dma/dma.txt
+
+Example:
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun50i-a64-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   dma-channels = <8>;
+   dma-requests = <27>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+--
+
 Clients:
 
 DMA clients connected to the A31 DMA controller must use the format
-- 
2.14.1

[PATCH v5] blktrace: Fix potentail deadlock between delete & sysfs ops

[Waiman Long]

The lockdep code had reported the following unsafe locking scenario:

   CPU0CPU1
   
  lock(s_active#228);
   lock(>bd_mutex/1);
   lock(s_active#228);
  lock(>bd_mutex);

 *** DEADLOCK ***

The deadlock may happen when one task (CPU1) is trying to delete a
partition in a block device and another task (CPU0) is accessing
tracing sysfs file (e.g. /sys/block/dm-1/trace/act_mask) in that
partition.

The s_active isn't an actual lock. It is a reference count (kn->count)
on the sysfs (kernfs) file. Removal of a sysfs file, however, require
a wait until all the references are gone. The reference count is
treated like a rwsem using lockdep instrumentation code.

The fact that a thread is in the sysfs callback method or in the
ioctl call means there is a reference to the opended sysfs or device
file. That should prevent the underlying block structure from being
removed.

Instead of using bd_mutex in the block_device structure, the other
bd_fsfreeze_mutex mutex in the block_device structure is now overloaded
to protect against concurrent blktrace data access in the blktrace.c
file. There is no point in adding one more mutex to the block_device
structure just for blktrace.

Signed-off-by: Waiman Long 
---
 v5:
  - Overload the bd_fsfreeze_mutex in block_device structure for
blktrace protection.

 v4:
  - Use blktrace_mutex in blk_trace_ioctl() as well.

 v3:
  - Use a global blktrace_mutex to serialize sysfs attribute accesses
instead of the bd_mutex.

 v2:
  - Use READ_ONCE() and smp_store_mb() to read and write bd_deleting.
  - Check for signal in the mutex_trylock loops.
  - Use usleep() instead of schedule() for RT tasks.

 include/linux/fs.h  |  2 +-
 kernel/trace/blktrace.c | 26 --
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 339e737..330b572 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -448,7 +448,7 @@ struct block_device {
 
/* The counter of freeze processes */
int bd_fsfreeze_count;
-   /* Mutex for freeze */
+   /* Mutex for freeze and blktrace */
struct mutexbd_fsfreeze_mutex;
 } __randomize_layout;
 
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 2a685b4..7cd5d1d 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -648,6 +648,20 @@ int blk_trace_startstop(struct request_queue *q, int start)
 }
 EXPORT_SYMBOL_GPL(blk_trace_startstop);
 
+/*
+ * When reading or writing the blktrace sysfs files, the references to the
+ * opened sysfs or device files should prevent the underlying block device
+ * from being removed. So no further delete protection is really needed.
+ *
+ * Protection from multiple readers and writers accessing blktrace data
+ * concurrently is still required. The bd_mutex was used for this purpose.
+ * That could lead to deadlock with concurrent block device deletion and
+ * sysfs access. Instead, the block device bd_fsfreeze_mutex is now
+ * overloaded for blktrace data protection. Like freeze/thaw, blktrace
+ * functionality is not frequently used. There is no point in adding
+ * one more mutex to the block_device structure just for blktrace.
+ */
+
 /**
  * blk_trace_ioctl: - handle the ioctls associated with tracing
  * @bdev:  the block device
@@ -665,7 +679,7 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned 
cmd, char __user *arg)
if (!q)
return -ENXIO;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
switch (cmd) {
case BLKTRACESETUP:
@@ -691,7 +705,7 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned 
cmd, char __user *arg)
break;
}
 
-   mutex_unlock(>bd_mutex);
+   mutex_unlock(>bd_fsfreeze_mutex);
return ret;
 }
 
@@ -1727,7 +1741,7 @@ static ssize_t sysfs_blk_trace_attr_show(struct device 
*dev,
if (q == NULL)
goto out_bdput;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
if (attr == _attr_enable) {
ret = sprintf(buf, "%u\n", !!q->blk_trace);
@@ -1746,7 +1760,7 @@ static ssize_t sysfs_blk_trace_attr_show(struct device 
*dev,
ret = sprintf(buf, "%llu\n", q->blk_trace->end_lba);
 
 out_unlock_bdev:
-   mutex_unlock(>bd_mutex);
+   mutex_unlock(>bd_fsfreeze_mutex);
 out_bdput:
bdput(bdev);
 out:
@@ -1788,7 +1802,7 @@ static ssize_t sysfs_blk_trace_attr_store(struct device 
*dev,
if (q == NULL)
goto out_bdput;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
if (attr == _attr_enable) {
if (value)
@@ -1814,7 +1828,7 @@ static ssize_t sysfs_blk_trace_attr_store(struct device 
*dev,
}
 
 out_unlock_bdev:
-   

[PATCH v5] blktrace: Fix potentail deadlock between delete & sysfs ops

[Waiman Long]

The lockdep code had reported the following unsafe locking scenario:

   CPU0CPU1
   
  lock(s_active#228);
   lock(>bd_mutex/1);
   lock(s_active#228);
  lock(>bd_mutex);

 *** DEADLOCK ***

The deadlock may happen when one task (CPU1) is trying to delete a
partition in a block device and another task (CPU0) is accessing
tracing sysfs file (e.g. /sys/block/dm-1/trace/act_mask) in that
partition.

The s_active isn't an actual lock. It is a reference count (kn->count)
on the sysfs (kernfs) file. Removal of a sysfs file, however, require
a wait until all the references are gone. The reference count is
treated like a rwsem using lockdep instrumentation code.

The fact that a thread is in the sysfs callback method or in the
ioctl call means there is a reference to the opended sysfs or device
file. That should prevent the underlying block structure from being
removed.

Instead of using bd_mutex in the block_device structure, the other
bd_fsfreeze_mutex mutex in the block_device structure is now overloaded
to protect against concurrent blktrace data access in the blktrace.c
file. There is no point in adding one more mutex to the block_device
structure just for blktrace.

Signed-off-by: Waiman Long 
---
 v5:
  - Overload the bd_fsfreeze_mutex in block_device structure for
blktrace protection.

 v4:
  - Use blktrace_mutex in blk_trace_ioctl() as well.

 v3:
  - Use a global blktrace_mutex to serialize sysfs attribute accesses
instead of the bd_mutex.

 v2:
  - Use READ_ONCE() and smp_store_mb() to read and write bd_deleting.
  - Check for signal in the mutex_trylock loops.
  - Use usleep() instead of schedule() for RT tasks.

 include/linux/fs.h  |  2 +-
 kernel/trace/blktrace.c | 26 --
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 339e737..330b572 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -448,7 +448,7 @@ struct block_device {
 
/* The counter of freeze processes */
int bd_fsfreeze_count;
-   /* Mutex for freeze */
+   /* Mutex for freeze and blktrace */
struct mutexbd_fsfreeze_mutex;
 } __randomize_layout;
 
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index 2a685b4..7cd5d1d 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -648,6 +648,20 @@ int blk_trace_startstop(struct request_queue *q, int start)
 }
 EXPORT_SYMBOL_GPL(blk_trace_startstop);
 
+/*
+ * When reading or writing the blktrace sysfs files, the references to the
+ * opened sysfs or device files should prevent the underlying block device
+ * from being removed. So no further delete protection is really needed.
+ *
+ * Protection from multiple readers and writers accessing blktrace data
+ * concurrently is still required. The bd_mutex was used for this purpose.
+ * That could lead to deadlock with concurrent block device deletion and
+ * sysfs access. Instead, the block device bd_fsfreeze_mutex is now
+ * overloaded for blktrace data protection. Like freeze/thaw, blktrace
+ * functionality is not frequently used. There is no point in adding
+ * one more mutex to the block_device structure just for blktrace.
+ */
+
 /**
  * blk_trace_ioctl: - handle the ioctls associated with tracing
  * @bdev:  the block device
@@ -665,7 +679,7 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned 
cmd, char __user *arg)
if (!q)
return -ENXIO;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
switch (cmd) {
case BLKTRACESETUP:
@@ -691,7 +705,7 @@ int blk_trace_ioctl(struct block_device *bdev, unsigned 
cmd, char __user *arg)
break;
}
 
-   mutex_unlock(>bd_mutex);
+   mutex_unlock(>bd_fsfreeze_mutex);
return ret;
 }
 
@@ -1727,7 +1741,7 @@ static ssize_t sysfs_blk_trace_attr_show(struct device 
*dev,
if (q == NULL)
goto out_bdput;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
if (attr == _attr_enable) {
ret = sprintf(buf, "%u\n", !!q->blk_trace);
@@ -1746,7 +1760,7 @@ static ssize_t sysfs_blk_trace_attr_show(struct device 
*dev,
ret = sprintf(buf, "%llu\n", q->blk_trace->end_lba);
 
 out_unlock_bdev:
-   mutex_unlock(>bd_mutex);
+   mutex_unlock(>bd_fsfreeze_mutex);
 out_bdput:
bdput(bdev);
 out:
@@ -1788,7 +1802,7 @@ static ssize_t sysfs_blk_trace_attr_store(struct device 
*dev,
if (q == NULL)
goto out_bdput;
 
-   mutex_lock(>bd_mutex);
+   mutex_lock(>bd_fsfreeze_mutex);
 
if (attr == _attr_enable) {
if (value)
@@ -1814,7 +1828,7 @@ static ssize_t sysfs_blk_trace_attr_store(struct device 
*dev,
}
 
 out_unlock_bdev:
-   mutex_unlock(>bd_mutex);
+   

Re: [lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

[Andy Lutomirski]

On Sat, Sep 16, 2017 at 6:40 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an 
> incorrect warning with CONFIG_DEBUG_VM=y, !PCID")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

Yep.  Fix coming.

Re: [lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

[Andy Lutomirski]

On Sat, Sep 16, 2017 at 6:40 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an 
> incorrect warning with CONFIG_DEBUG_VM=y, !PCID")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

Yep.  Fix coming.

Re: [linux-sunxi] [PATCH 3/4] arm64: allwinner: h5: add compatible string for DE2 CCU

[Julian Calaby]

Hi Icenowy,

On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng  wrote:
> The DE2 CCU on Allwinner H5 SoC has a slightly different behavior than
> the one on H3, so the compatible string is not set in the common DTSI
> file.
>
> Add the compatible string of H5 DE2 CCU in H5 DTSI file.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index d9a720bff05d..e237c05cfdb4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -98,6 +98,10 @@
> compatible = "allwinner,sun50i-h5-ccu";
>  };
>
> +_clocks {
> +   compatible = "allwinner,sun50i-h5-de2-clk";
> +};
> +

This is what I get for reviewing before reading the full patch set.

Shouldn't this be rolled into the previous patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 3/4] arm64: allwinner: h5: add compatible string for DE2 CCU

[Julian Calaby]

Hi Icenowy,

On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng  wrote:
> The DE2 CCU on Allwinner H5 SoC has a slightly different behavior than
> the one on H3, so the compatible string is not set in the common DTSI
> file.
>
> Add the compatible string of H5 DE2 CCU in H5 DTSI file.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index d9a720bff05d..e237c05cfdb4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -98,6 +98,10 @@
> compatible = "allwinner,sun50i-h5-ccu";
>  };
>
> +_clocks {
> +   compatible = "allwinner,sun50i-h5-de2-clk";
> +};
> +

This is what I get for reviewing before reading the full patch set.

Shouldn't this be rolled into the previous patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 2/4] ARM: sun8i: h3/h5: add DE2 CCU device node for H3

[Julian Calaby]

Hi Icenowy,

On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng  wrote:
> The DE2 in H3/H5 has a clock control unit in it, and the behavior is
> slightly different between H3 and H5.
>
> Add the common parts in H3/H5 DTSI, and add the compatible string in H3
> DTSI.
>
> The compatible string of H5 DE2 CCU will be added in a separated patch.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi|  4 
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 14 ++
>  2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 11240a8313c2..76a4cbc99bdb 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -85,6 +87,18 @@
> #size-cells = <1>;
> ranges;
>
> +   display_clocks: clock@100 {
> +   /* compatible is in per SoC .dtsi file */

I don't know device tree very well, but shouldn't this node be
disabled so that it doesn't do anything weird on H5? Or are nodes
without compatibles ignored?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 2/4] ARM: sun8i: h3/h5: add DE2 CCU device node for H3

[Julian Calaby]

Hi Icenowy,

On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng  wrote:
> The DE2 in H3/H5 has a clock control unit in it, and the behavior is
> slightly different between H3 and H5.
>
> Add the common parts in H3/H5 DTSI, and add the compatible string in H3
> DTSI.
>
> The compatible string of H5 DE2 CCU will be added in a separated patch.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi|  4 
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 14 ++
>  2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 11240a8313c2..76a4cbc99bdb 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -85,6 +87,18 @@
> #size-cells = <1>;
> ranges;
>
> +   display_clocks: clock@100 {
> +   /* compatible is in per SoC .dtsi file */

I don't know device tree very well, but shouldn't this node be
disabled so that it doesn't do anything weird on H5? Or are nodes
without compatibles ignored?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

[kbuild test robot]

Hi Felix,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
commit: 70539bd79500245cbb4c7af00572fcce540d0105 drm/amd: Update MEC HQD 
loading code for KFD
date:   5 weeks ago
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 70539bd79500245cbb4c7af00572fcce540d0105
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   In file included from include/linux/mmu_context.h:4:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29,
from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23:
   arch/alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
>> arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of 
>> function 'task_thread_info' [-Werror=implicit-function-declaration]
 task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
 ^~~~
>> arch/alpha/include/asm/mmu_context.h:160:24: error: invalid type argument of 
>> '->' (have 'int')
 task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
   ^~
   arch/alpha/include/asm/mmu_context.h: In function 'init_new_context':
   arch/alpha/include/asm/mmu_context.h:238:24: error: invalid type argument of 
'->' (have 'int')
  task_thread_info(tsk)->pcb.ptbr
   ^~
   arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
   arch/alpha/include/asm/mmu_context.h:252:23: error: invalid type argument of 
'->' (have 'int')
 task_thread_info(tsk)->pcb.ptbr
  ^~
   cc1: some warnings being treated as errors

vim +/task_thread_info +160 arch/alpha/include/asm/mmu_context.h

^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  156  
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  157
/* Always update the PCB ASN.  Another thread may have allocated
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  158
   a new mm->context (via flush_tlb_mm) without the ASN serial
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  159
   number wrapping.  We have no way to detect when this is needed.  */
37bfbaf99 include/asm-alpha/mmu_context.h Al Viro2006-01-12 @160
task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  161  }
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  162  

:: The code at line 160 was first introduced by commit
:: 37bfbaf995d2c1f8196ee04c9d6f68258d5ec3e8 [PATCH] alpha: 
task_thread_info()

:: TO: Al Viro 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

[kbuild test robot]

Hi Felix,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e
commit: 70539bd79500245cbb4c7af00572fcce540d0105 drm/amd: Update MEC HQD 
loading code for KFD
date:   5 weeks ago
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 70539bd79500245cbb4c7af00572fcce540d0105
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   In file included from include/linux/mmu_context.h:4:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29,
from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23:
   arch/alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
>> arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of 
>> function 'task_thread_info' [-Werror=implicit-function-declaration]
 task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
 ^~~~
>> arch/alpha/include/asm/mmu_context.h:160:24: error: invalid type argument of 
>> '->' (have 'int')
 task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
   ^~
   arch/alpha/include/asm/mmu_context.h: In function 'init_new_context':
   arch/alpha/include/asm/mmu_context.h:238:24: error: invalid type argument of 
'->' (have 'int')
  task_thread_info(tsk)->pcb.ptbr
   ^~
   arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
   arch/alpha/include/asm/mmu_context.h:252:23: error: invalid type argument of 
'->' (have 'int')
 task_thread_info(tsk)->pcb.ptbr
  ^~
   cc1: some warnings being treated as errors

vim +/task_thread_info +160 arch/alpha/include/asm/mmu_context.h

^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  156  
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  157
/* Always update the PCB ASN.  Another thread may have allocated
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  158
   a new mm->context (via flush_tlb_mm) without the ASN serial
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  159
   number wrapping.  We have no way to detect when this is needed.  */
37bfbaf99 include/asm-alpha/mmu_context.h Al Viro2006-01-12 @160
task_thread_info(next)->pcb.asn = mmc & HARDWARE_ASN_MASK;
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  161  }
^1da177e4 include/asm-alpha/mmu_context.h Linus Torvalds 2005-04-16  162  

:: The code at line 160 was first introduced by commit
:: 37bfbaf995d2c1f8196ee04c9d6f68258d5ec3e8 [PATCH] alpha: 
task_thread_info()

:: TO: Al Viro 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[lkp-robot] [ipmi_si] d830f6514c: WARNING:at_drivers/base/driver.c:#driver_unregister

[kernel test robot]

FYI, we noticed the following commit:

commit: d830f6514cdf359bcd7201306ac792ffa27f7966 ("ipmi_si: Move platform 
device handling to another file")
https://github.com/cminyard/linux-ipmi master-ipmi-rebase

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -m 256M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | f479f8111d | 
d830f6514c |
+-+++
| boot_successes  | 0  | 0  
|
| boot_failures   | 12 | 10 
|
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 12 | 10 
|
| EIP:initialize_tlbstate_and_flush   | 12 | 10 
|
| WARNING:at_drivers/base/driver.c:#driver_unregister | 0  | 10 
|
| EIP:driver_unregister   | 0  | 10 
|
+-+++



[2.815872] WARNING: CPU: 0 PID: 1 at drivers/base/driver.c:191 
driver_unregister+0x1a/0x33
[2.817118] CPU: 0 PID: 1 Comm: swapper Tainted: GW   
4.13.0-06701-gd830f651 #12
[2.817953] task: 8742e000 task.stack: 8743
[2.818413] EIP: driver_unregister+0x1a/0x33
[2.818869] EFLAGS: 00210286 CPU: 0
[2.819223] EAX: 001d EBX: 7a116214 ECX: 0006 EDX: 0007
[2.819847] ESI: ffed EDI:  EBP: 87431f08 ESP: 87431f00
[2.820558]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[2.821095] CR0: 80050033 CR2:  CR3: 01904000 CR4: 0690
[2.821718] Call Trace:
[2.821973]  platform_driver_unregister+0xb/0xd
[2.822405]  cleanup_ipmi_si+0x2a/0x73
[2.822775]  init_ipmi_si+0x149/0x16a
[2.823126]  ? ipmi_thread+0x18b/0x18b
[2.823488]  do_one_initcall+0x7c/0x114
[2.823862]  ? parse_args+0x135/0x1f7
[2.824227]  ? kernel_init_freeable+0xba/0x156
[2.824674]  kernel_init_freeable+0xdd/0x156
[2.825108]  ? rest_init+0x108/0x108
[2.825460]  kernel_init+0x8/0xcb
[2.825815]  ret_from_fork+0x19/0x24
[2.826178] Code: dc ff 5d c3 55 8b 40 3c 89 e5 e8 32 eb dc ff 5d c3 55 85 
c0 89 e5 53 74 08 83 78 3c 00 89 c3 75 0f 68 56 81 6b 79 e8 c6 dd d1 ff <0f> ff 
58 eb 0f 8b 50 34 e8 cc ff ff ff 89 d8 e8 7a eb ff ff 8b
[2.828225] ---[ end trace aff8a0f3cdf046d6 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is 

[lkp-robot] [ipmi_si] d830f6514c: WARNING:at_drivers/base/driver.c:#driver_unregister

[kernel test robot]

FYI, we noticed the following commit:

commit: d830f6514cdf359bcd7201306ac792ffa27f7966 ("ipmi_si: Move platform 
device handling to another file")
https://github.com/cminyard/linux-ipmi master-ipmi-rebase

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -m 256M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | f479f8111d | 
d830f6514c |
+-+++
| boot_successes  | 0  | 0  
|
| boot_failures   | 12 | 10 
|
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 12 | 10 
|
| EIP:initialize_tlbstate_and_flush   | 12 | 10 
|
| WARNING:at_drivers/base/driver.c:#driver_unregister | 0  | 10 
|
| EIP:driver_unregister   | 0  | 10 
|
+-+++



[2.815872] WARNING: CPU: 0 PID: 1 at drivers/base/driver.c:191 
driver_unregister+0x1a/0x33
[2.817118] CPU: 0 PID: 1 Comm: swapper Tainted: GW   
4.13.0-06701-gd830f651 #12
[2.817953] task: 8742e000 task.stack: 8743
[2.818413] EIP: driver_unregister+0x1a/0x33
[2.818869] EFLAGS: 00210286 CPU: 0
[2.819223] EAX: 001d EBX: 7a116214 ECX: 0006 EDX: 0007
[2.819847] ESI: ffed EDI:  EBP: 87431f08 ESP: 87431f00
[2.820558]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[2.821095] CR0: 80050033 CR2:  CR3: 01904000 CR4: 0690
[2.821718] Call Trace:
[2.821973]  platform_driver_unregister+0xb/0xd
[2.822405]  cleanup_ipmi_si+0x2a/0x73
[2.822775]  init_ipmi_si+0x149/0x16a
[2.823126]  ? ipmi_thread+0x18b/0x18b
[2.823488]  do_one_initcall+0x7c/0x114
[2.823862]  ? parse_args+0x135/0x1f7
[2.824227]  ? kernel_init_freeable+0xba/0x156
[2.824674]  kernel_init_freeable+0xdd/0x156
[2.825108]  ? rest_init+0x108/0x108
[2.825460]  kernel_init+0x8/0xcb
[2.825815]  ret_from_fork+0x19/0x24
[2.826178] Code: dc ff 5d c3 55 8b 40 3c 89 e5 e8 32 eb dc ff 5d c3 55 85 
c0 89 e5 53 74 08 83 78 3c 00 89 c3 75 0f 68 56 81 6b 79 e8 c6 dd d1 ff <0f> ff 
58 eb 0f 8b 50 34 e8 cc ff ff ff 89 d8 e8 7a eb ff ff 8b
[2.828225] ---[ end trace aff8a0f3cdf046d6 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is 

[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 89e689f267: kernel_BUG_at_fs/super.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 89e689f267b2c144d7b071443e01fa718727b962 ("kernfs, sysfs, cgroup, 
intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -m 256M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | a62d750e12 | 89e689f267 |
+--+++
| boot_successes   | 22 | 2  |
| boot_failures| 0  | 22 |
| kernel_BUG_at_fs/super.c | 0  | 22 |
| invalid_opcode:#[##] | 0  | 22 |
| EIP:vfs_get_tree | 0  | 22 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 22 |
+--+++



[2.580515] kernel BUG at fs/super.c:1703!
[2.581033] invalid opcode:  [#1]
[2.581372] CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc1-00020-g89e689f #1
[2.581981] task: 8741e000 task.stack: 8742
[2.582400] EIP: vfs_get_tree+0x4d/0xe1
[2.582736] EFLAGS: 00010246 CPU: 0
[2.583052] EAX:  EBX: 83d3a8c8 ECX: 83d3ccc4 EDX: 7970b580
[2.583599] ESI: 0027 EDI:  EBP: 87421f28 ESP: 87421f20
[2.584150]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[2.584619] CR0: 80050033 CR2: 6feff588 CR3: 0bcd4000 CR4: 0690
[2.585174] Call Trace:
[2.585400]  do_mount+0x89e/0x8dc
[2.585694]  ? strndup_user+0x27/0x3f
[2.586016]  SyS_mount+0x52/0x76
[2.586317]  do_int80_syscall_32+0x4c/0xd9
[2.586680]  entry_INT80_32+0x2c/0x2c
[2.586998] EIP: 0x6fef6c3e
[2.587266] EFLAGS: 0216 CPU: 0
[2.587581] EAX: ffda EBX: 0804a3a9 ECX: 0804a3a1 EDX: 0804a3a9
[2.588136] ESI: 000e EDI:  EBP: 77a30778 ESP: 77a306dc
[2.588689]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[2.589176] Code: ff ff ff e9 aa 00 00 00 89 d8 ff d2 85 c0 79 e8 e9 9d 00 
00 00 8b 13 89 d8 ff 52 18 85 c0 0f 88 8e 00 00 00 8b 43 08 85 c0 75 02 <0f> 0b 
8b b0 94 00 00 00 83 be ac 00 00 00 00 75 02 0f ff 8b 43
[2.590882] EIP: vfs_get_tree+0x4d/0xe1 SS:ESP: 0068:87421f20
[2.591412] ---[ end trace 5e29087d876104ae ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#

[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 89e689f267: kernel_BUG_at_fs/super.c

[kernel test robot]

FYI, we noticed the following commit:

commit: 89e689f267b2c144d7b071443e01fa718727b962 ("kernfs, sysfs, cgroup, 
intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -m 256M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | a62d750e12 | 89e689f267 |
+--+++
| boot_successes   | 22 | 2  |
| boot_failures| 0  | 22 |
| kernel_BUG_at_fs/super.c | 0  | 22 |
| invalid_opcode:#[##] | 0  | 22 |
| EIP:vfs_get_tree | 0  | 22 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 22 |
+--+++



[2.580515] kernel BUG at fs/super.c:1703!
[2.581033] invalid opcode:  [#1]
[2.581372] CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc1-00020-g89e689f #1
[2.581981] task: 8741e000 task.stack: 8742
[2.582400] EIP: vfs_get_tree+0x4d/0xe1
[2.582736] EFLAGS: 00010246 CPU: 0
[2.583052] EAX:  EBX: 83d3a8c8 ECX: 83d3ccc4 EDX: 7970b580
[2.583599] ESI: 0027 EDI:  EBP: 87421f28 ESP: 87421f20
[2.584150]  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
[2.584619] CR0: 80050033 CR2: 6feff588 CR3: 0bcd4000 CR4: 0690
[2.585174] Call Trace:
[2.585400]  do_mount+0x89e/0x8dc
[2.585694]  ? strndup_user+0x27/0x3f
[2.586016]  SyS_mount+0x52/0x76
[2.586317]  do_int80_syscall_32+0x4c/0xd9
[2.586680]  entry_INT80_32+0x2c/0x2c
[2.586998] EIP: 0x6fef6c3e
[2.587266] EFLAGS: 0216 CPU: 0
[2.587581] EAX: ffda EBX: 0804a3a9 ECX: 0804a3a1 EDX: 0804a3a9
[2.588136] ESI: 000e EDI:  EBP: 77a30778 ESP: 77a306dc
[2.588689]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b
[2.589176] Code: ff ff ff e9 aa 00 00 00 89 d8 ff d2 85 c0 79 e8 e9 9d 00 
00 00 8b 13 89 d8 ff 52 18 85 c0 0f 88 8e 00 00 00 8b 43 08 85 c0 75 02 <0f> 0b 
8b b0 94 00 00 00 83 be ac 00 00 00 00 75 02 0f ff 8b 43
[2.590882] EIP: vfs_get_tree+0x4d/0xe1 SS:ESP: 0068:87421f20
[2.591412] ---[ end trace 5e29087d876104ae ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#

[lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

[kernel test robot]

FYI, we noticed the following commit:

commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an incorrect 
warning with CONFIG_DEBUG_VM=y, !PCID")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | 4dfc278803 | 
7898f79654 |
+-+++
| boot_successes  | 8  | 4  
|
| boot_failures   | 0  | 4  
|
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 0  | 4  
|
| EIP:initialize_tlbstate_and_flush   | 0  | 4  
|
+-+++



[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:245 
initialize_tlbstate_and_flush+0x49/0xef
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.13.0-10313-g7898f79 #1
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[0.00] task: b243f600 task.stack: b2436000
[0.00] EIP: initialize_tlbstate_and_flush+0x49/0xef
[0.00] EFLAGS: 00210046 CPU: 0
[0.00] EAX: 00040690 EBX: b25a57e0 ECX: 0080 EDX: 0002
[0.00] ESI:  EDI:  EBP: b2437f60 ESP: b2437f50
[0.00]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[0.00] CR0: 80050033 CR2:  CR3: 0277a000 CR4: 00040690
[0.00] Call Trace:
[0.00]  cpu_init+0x98/0x17b
[0.00]  ? __native_set_fixmap+0x21/0x2a
[0.00]  trap_init+0x38/0x40
[0.00]  start_kernel+0x1f6/0x399
[0.00]  i386_start_kernel+0x95/0x99
[0.00]  startup_32_smp+0x164/0x166
[0.00] Code: c5 42 b2 89 45 f0 8b 43 20 e8 3d fa ff ff 3b 45 f0 74 02 
0f ff a1 a0 7d 6b b2 0f ba e0 11 73 0d a1 c8 3c 45 b2 0f ba e0 11 72 02 <0f> ff 
8b 45 f0 ff 15 2c c5 42 b2 66 c7 05 c4 3c 45 b2 00 00 66
[0.00] ---[ end trace be658dd14e22cef1 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y

[lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

[kernel test robot]

FYI, we noticed the following commit:

commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an incorrect 
warning with CONFIG_DEBUG_VM=y, !PCID")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | 4dfc278803 | 
7898f79654 |
+-+++
| boot_successes  | 8  | 4  
|
| boot_failures   | 0  | 4  
|
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 0  | 4  
|
| EIP:initialize_tlbstate_and_flush   | 0  | 4  
|
+-+++



[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:245 
initialize_tlbstate_and_flush+0x49/0xef
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.13.0-10313-g7898f79 #1
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[0.00] task: b243f600 task.stack: b2436000
[0.00] EIP: initialize_tlbstate_and_flush+0x49/0xef
[0.00] EFLAGS: 00210046 CPU: 0
[0.00] EAX: 00040690 EBX: b25a57e0 ECX: 0080 EDX: 0002
[0.00] ESI:  EDI:  EBP: b2437f60 ESP: b2437f50
[0.00]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[0.00] CR0: 80050033 CR2:  CR3: 0277a000 CR4: 00040690
[0.00] Call Trace:
[0.00]  cpu_init+0x98/0x17b
[0.00]  ? __native_set_fixmap+0x21/0x2a
[0.00]  trap_init+0x38/0x40
[0.00]  start_kernel+0x1f6/0x399
[0.00]  i386_start_kernel+0x95/0x99
[0.00]  startup_32_smp+0x164/0x166
[0.00] Code: c5 42 b2 89 45 f0 8b 43 20 e8 3d fa ff ff 3b 45 f0 74 02 
0f ff a1 a0 7d 6b b2 0f ba e0 11 73 0d a1 c8 3c 45 b2 0f ba e0 11 72 02 <0f> ff 
8b 45 f0 ff 15 2c c5 42 b2 66 c7 05 c4 3c 45 b2 00 00 66
[0.00] ---[ end trace be658dd14e22cef1 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y

kernel-doc: handle DECLARE_KFIFO() ?

[Randy Dunlap]

scripts/kernel-doc handles DECLARE_BITMAP() and DECLARE_HASHTABLE().

Recently drivers/gpio/gpiolib.c has been changed to use DECLARE_KFIFO() *and*
that is inside kernel-doc notation, but scripts/kernel-doc doesn't know about
DECLARE_KFIFO(), so it causes these warnings:

../drivers/gpio/gpiolib.c:593: warning: No description found for parameter '16'
../drivers/gpio/gpiolib.c:593: warning: Excess struct/union/enum/typedef member 
'events' description in 'lineevent_state'

DECLARE_KFIFO(events, struct gpioevent_data, 16);

-- 
~Randy

kernel-doc: handle DECLARE_KFIFO() ?

[Randy Dunlap]

scripts/kernel-doc handles DECLARE_BITMAP() and DECLARE_HASHTABLE().

Recently drivers/gpio/gpiolib.c has been changed to use DECLARE_KFIFO() *and*
that is inside kernel-doc notation, but scripts/kernel-doc doesn't know about
DECLARE_KFIFO(), so it causes these warnings:

../drivers/gpio/gpiolib.c:593: warning: No description found for parameter '16'
../drivers/gpio/gpiolib.c:593: warning: Excess struct/union/enum/typedef member 
'events' description in 'lineevent_state'

DECLARE_KFIFO(events, struct gpioevent_data, 16);

-- 
~Randy

rcu kernel-doc issues (4.14-rc1)

[Randy Dunlap]

On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc:

.. kernel-doc:: include/linux/rcupdate.h
   :external:
./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcupdate_wait.h
   :external:
./Documentation/core-api/kernel-api.rst:360: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcutree.h
   :external:
./Documentation/core-api/kernel-api.rst:363: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree.c
   :external:
./Documentation/core-api/kernel-api.rst:366: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree_plugin.h
   :external:
./Documentation/core-api/kernel-api.rst:369: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree_exp.h
   :external:
./Documentation/core-api/kernel-api.rst:372: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/update.c
   :external:
./Documentation/core-api/kernel-api.rst:375: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/srcu.h
   :external:
./Documentation/core-api/kernel-api.rst:378: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/srcutree.c
   :external:
./Documentation/core-api/kernel-api.rst:381: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist_bl.h
   :external:
./Documentation/core-api/kernel-api.rst:384: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist.h
   :external:
./Documentation/core-api/kernel-api.rst:387: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist_nulls.h
   :external:
./Documentation/core-api/kernel-api.rst:390: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcu_sync.h
   :external:
./Documentation/core-api/kernel-api.rst:393: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/sync.c
   :external:

../kernel/rcu/tree.c:3091: ERROR: Unexpected indentation.
../kernel/rcu/tree.c:3118: ERROR: Unexpected indentation.
../kernel/rcu/tree.c:3119: WARNING: Bullet list ends without a blank line; 
unexpected unindent.


-- 
~Randy

rcu kernel-doc issues (4.14-rc1)

[Randy Dunlap]

On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc:

.. kernel-doc:: include/linux/rcupdate.h
   :external:
./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcupdate_wait.h
   :external:
./Documentation/core-api/kernel-api.rst:360: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcutree.h
   :external:
./Documentation/core-api/kernel-api.rst:363: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree.c
   :external:
./Documentation/core-api/kernel-api.rst:366: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree_plugin.h
   :external:
./Documentation/core-api/kernel-api.rst:369: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/tree_exp.h
   :external:
./Documentation/core-api/kernel-api.rst:372: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/update.c
   :external:
./Documentation/core-api/kernel-api.rst:375: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/srcu.h
   :external:
./Documentation/core-api/kernel-api.rst:378: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/srcutree.c
   :external:
./Documentation/core-api/kernel-api.rst:381: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist_bl.h
   :external:
./Documentation/core-api/kernel-api.rst:384: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist.h
   :external:
./Documentation/core-api/kernel-api.rst:387: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rculist_nulls.h
   :external:
./Documentation/core-api/kernel-api.rst:390: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: include/linux/rcu_sync.h
   :external:
./Documentation/core-api/kernel-api.rst:393: ERROR: Error in "kernel-doc" 
directive:
unknown option: "external".

.. kernel-doc:: kernel/rcu/sync.c
   :external:

../kernel/rcu/tree.c:3091: ERROR: Unexpected indentation.
../kernel/rcu/tree.c:3118: ERROR: Unexpected indentation.
../kernel/rcu/tree.c:3119: WARNING: Bullet list ends without a blank line; 
unexpected unindent.


-- 
~Randy

Re: Query regarding synchronize_sched_expedited and resched_cpu

[Paul E. McKenney]

On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote:
> Hi,
> 
> We have one query regarding the behavior of RCU expedited grace period,
> for scenario where resched_cpu() in sync_sched_exp_handler() fails to
> acquire the rq lock and returns w/o setting the need_resched. In this
> case, how do we ensure that the CPU notify rcu about the
> end of sched grace period (schedule() -> __schedule() ->
> rcu_note_context_switch(cpu) -> rcu_sched_qs()) , for cases where tick
> is stopped on that CPU.  Is it implied from the rq lock acquisition
> failure, that the owner of the rq lock will enforce context switch?
> For which scenarios in RCU paths (as the function is used only in RCU
> code), we need trylock check in resched_cpu()?
> 
> void resched_cpu(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long flags;
> 
> if (!raw_spin_trylock_irqsave(>lock, flags))
> return;
> resched_curr(rq);
> raw_spin_unlock_irqrestore(>lock, flags);
> }
> 
> 
> This issue was observed in below scenario, where one of the CPUs (CPU1)
> started synchronize_sched_expedited and sent IPI to CPU5, which is in
> the idle path but handled sync_sched_exp_handler() IPI before
> rcu_idle_enter().
> As resched_cpu() failed to acquire the rq lock, need_resched was not set,
> and CPU went to idle; resulting in expedited stall getting reported
> by CPU1.
> 
> Below is the scenario:
> 
> •CPU1 is waiting for expedited wait to complete:
> sync_rcu_exp_select_cpus
> rdp->exp_dynticks_snap & 0x1   // returns 1 for CPU5
> IPI sent to CPU5
> 
> synchronize_sched_expedited_wait
> ret = swait_event_timeout(
> rsp->expedited_wq,
>  sync_rcu_preempt_exp_done(rnp_root),
> jiffies_stall);
> 
>expmask = 0x20 , and CPU 5 is in idle path (in cpuidle_enter())
> 
> 
> 
> •CPU5 handles IPI and fails to acquire rq lock.
> 
> Handles IPI
> sync_sched_exp_handler
> resched_cpu
> returns while failing to try lock acquire rq->lock
> need_resched is not set
> 
> •CPU5 calls  rcu_idle_enter() and as need_resched is not set, goes to
> idle (schedule() is not called).
> 
> •CPU 1 reports RCU stall.

Good catch and good detective work!!!

I will be working on a fix this week, hopefully involving resched_cpu()
getting a return value so that I can track who needs a later retry.

Thanx, Paul

Re: Query regarding synchronize_sched_expedited and resched_cpu

[Paul E. McKenney]

On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote:
> Hi,
> 
> We have one query regarding the behavior of RCU expedited grace period,
> for scenario where resched_cpu() in sync_sched_exp_handler() fails to
> acquire the rq lock and returns w/o setting the need_resched. In this
> case, how do we ensure that the CPU notify rcu about the
> end of sched grace period (schedule() -> __schedule() ->
> rcu_note_context_switch(cpu) -> rcu_sched_qs()) , for cases where tick
> is stopped on that CPU.  Is it implied from the rq lock acquisition
> failure, that the owner of the rq lock will enforce context switch?
> For which scenarios in RCU paths (as the function is used only in RCU
> code), we need trylock check in resched_cpu()?
> 
> void resched_cpu(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long flags;
> 
> if (!raw_spin_trylock_irqsave(>lock, flags))
> return;
> resched_curr(rq);
> raw_spin_unlock_irqrestore(>lock, flags);
> }
> 
> 
> This issue was observed in below scenario, where one of the CPUs (CPU1)
> started synchronize_sched_expedited and sent IPI to CPU5, which is in
> the idle path but handled sync_sched_exp_handler() IPI before
> rcu_idle_enter().
> As resched_cpu() failed to acquire the rq lock, need_resched was not set,
> and CPU went to idle; resulting in expedited stall getting reported
> by CPU1.
> 
> Below is the scenario:
> 
> •CPU1 is waiting for expedited wait to complete:
> sync_rcu_exp_select_cpus
> rdp->exp_dynticks_snap & 0x1   // returns 1 for CPU5
> IPI sent to CPU5
> 
> synchronize_sched_expedited_wait
> ret = swait_event_timeout(
> rsp->expedited_wq,
>  sync_rcu_preempt_exp_done(rnp_root),
> jiffies_stall);
> 
>expmask = 0x20 , and CPU 5 is in idle path (in cpuidle_enter())
> 
> 
> 
> •CPU5 handles IPI and fails to acquire rq lock.
> 
> Handles IPI
> sync_sched_exp_handler
> resched_cpu
> returns while failing to try lock acquire rq->lock
> need_resched is not set
> 
> •CPU5 calls  rcu_idle_enter() and as need_resched is not set, goes to
> idle (schedule() is not called).
> 
> •CPU 1 reports RCU stall.

Good catch and good detective work!!!

I will be working on a fix this week, hopefully involving resched_cpu()
getting a return value so that I can track who needs a later retry.

Thanx, Paul

Linux 4.14-rc1

[Linus Torvalds]

Yes, I realize this is a day early, and yes, I realize that if I had
waited until tomorrow, I would also have hit the 26th anniversary of
the Linux-0.01 release, but neither of those undeniable facts made me
want to wait with closing the mege window.

This has been an "interesting" merge window. It's not actually all
that unusual in size - I think it's shaping to be a pretty regular
release after 4.13 that was smallish. But unlike 4.13 it also wasn't a
completely smooth merge window, and honestly, I _really_ didn't want
to wait for any possible straggling pull requests.

Don't get me wrong - things don't look bad, but I hate it when I find
issues during the merge window that I feel should have been noticed
before the code made it to me, and it happened a few times this
release.

Admittedly, some of it was simply because we had some unusual
activity. For example, on the x86 VM side, 4.14 doesn't just have
_one_ new core memory management feature, but three: 5-level page
tables, ASID support (it's called "PCID" on x86 for reasons that are
not good) and the AMD memory encryption support. So the fact that we
had a few hiccups is very understandable, and in fact it should amaze
everybody just how smoothly the 5-level page table code integration
seems to have gone, for example.

So 4.14 is getting some very core new functionality.

Obviously, as usual, those kinds of core changes are absolutely
dwarfed by all the device driver updates, that as usual are the bulk
of the patches. This time around, particularly notable is a late
addition to the merge window - or rather, a late removal - in that
we've finally gotten rid of the firmware images from the kernel tree.
That's because people haven't used them for the last few years, since
there's a separate firmware image repository.

But there's changes all over. Documentation, architecture updates,
filesystems, networking, tooling. This was not a small release, even
if I had kind of expected that with much of Europe on vacation in
August we'd have seen a slow-down. Nope.

Anyway, as always, the shortlog is much too big to post, so appended
is the "mergelog", and as always the credit in the merge log goes not
to who wrote the patches, but to the maintainer who actually sent it
to me for merging.  So there's about 90 maintainers mentioned there,
but it should be noted that we have 1500+ individual authors for the
11,500+ individual non-merge commits. So this is very much just a very
high-level overview of the merges I've done, and if you want to see
details, you'll need to go look at the git tree logs.

  Linus

---

Al Viro (6):
misc fixes
ipc compat cleanup and 64-bit time_t
more set_fs removal
mount flag updates
nowait read support
misc leftovers

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (3):
updates
more updates
misc fixes

Bartlomiej Zolnierkiewicz (1):
fbdev updates

Ben LaHaise (1):
aio fix

Bjorn Andersson (2):
remoteproc updates
rpmsg updates

Bjorn Helgaas (2):
PCI updates
PCI fix

Bob Peterson (1):
GFS2 updates

Boris Brezillon (1):
MTD updates

Borislav Petkov (1):
EDAC updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (1):
arm64 updates

Chris Mason (1):
zstd support

Christoph Hellwig (2):
uuid updates
dma-mapping updates

Dan Williams (1):
libnvdimm

Darren Hart (1):
x86 platform driver updates

Darrick Wong (1):
XFS updates

Dave Airlie (2):
drm updates
drm AMD fixes

David Miller (4):
networking updates
networking fixes
sparc updates
networking fixes

David Sterba (1):
btrfs updates

David Teigland (1):
dlm updates

Dmitry Torokhov (2):
input updates
more input updates

Doug Ledford (1):
rdma updates

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (6):
USB/PHY driver updates
tty/serial updates
staging/IIO driver updates
driver core update
char/misc driver updates
firmware removal

Greg Ungerer (1):
m68knommu updates

Guenter Roeck (1):
hwmon updates

Helge Deller (1):
parisc updates

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
ceph updates

Ingo Molnar (24):
debugobjects fix
perf updates
RAS fix
RCU updates
scheduler updates
x86 asm updates
x86 boot updates
x86 build updates
x86 cpuid updates
x86 debug updates
x86 microcode loading updates
x86 spinlock update
syscall updates
locking updates
x86 mm changes
x86 platform updates
EFI updates
irq fixes
perf tooling updates
scheduler fixes
x86 fixes
x86 fixes
scheduler fixes
perf fixes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (2):
SCSI updates
SCSI fixes

Jan Kara (2):
UDF, reiserfs, quota, fsnotify cleanups
quota scaling updates

Jassi 

Linux 4.14-rc1

[Linus Torvalds]

Yes, I realize this is a day early, and yes, I realize that if I had
waited until tomorrow, I would also have hit the 26th anniversary of
the Linux-0.01 release, but neither of those undeniable facts made me
want to wait with closing the mege window.

This has been an "interesting" merge window. It's not actually all
that unusual in size - I think it's shaping to be a pretty regular
release after 4.13 that was smallish. But unlike 4.13 it also wasn't a
completely smooth merge window, and honestly, I _really_ didn't want
to wait for any possible straggling pull requests.

Don't get me wrong - things don't look bad, but I hate it when I find
issues during the merge window that I feel should have been noticed
before the code made it to me, and it happened a few times this
release.

Admittedly, some of it was simply because we had some unusual
activity. For example, on the x86 VM side, 4.14 doesn't just have
_one_ new core memory management feature, but three: 5-level page
tables, ASID support (it's called "PCID" on x86 for reasons that are
not good) and the AMD memory encryption support. So the fact that we
had a few hiccups is very understandable, and in fact it should amaze
everybody just how smoothly the 5-level page table code integration
seems to have gone, for example.

So 4.14 is getting some very core new functionality.

Obviously, as usual, those kinds of core changes are absolutely
dwarfed by all the device driver updates, that as usual are the bulk
of the patches. This time around, particularly notable is a late
addition to the merge window - or rather, a late removal - in that
we've finally gotten rid of the firmware images from the kernel tree.
That's because people haven't used them for the last few years, since
there's a separate firmware image repository.

But there's changes all over. Documentation, architecture updates,
filesystems, networking, tooling. This was not a small release, even
if I had kind of expected that with much of Europe on vacation in
August we'd have seen a slow-down. Nope.

Anyway, as always, the shortlog is much too big to post, so appended
is the "mergelog", and as always the credit in the merge log goes not
to who wrote the patches, but to the maintainer who actually sent it
to me for merging.  So there's about 90 maintainers mentioned there,
but it should be noted that we have 1500+ individual authors for the
11,500+ individual non-merge commits. So this is very much just a very
high-level overview of the merges I've done, and if you want to see
details, you'll need to go look at the git tree logs.

  Linus

---

Al Viro (6):
misc fixes
ipc compat cleanup and 64-bit time_t
more set_fs removal
mount flag updates
nowait read support
misc leftovers

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (3):
updates
more updates
misc fixes

Bartlomiej Zolnierkiewicz (1):
fbdev updates

Ben LaHaise (1):
aio fix

Bjorn Andersson (2):
remoteproc updates
rpmsg updates

Bjorn Helgaas (2):
PCI updates
PCI fix

Bob Peterson (1):
GFS2 updates

Boris Brezillon (1):
MTD updates

Borislav Petkov (1):
EDAC updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (1):
arm64 updates

Chris Mason (1):
zstd support

Christoph Hellwig (2):
uuid updates
dma-mapping updates

Dan Williams (1):
libnvdimm

Darren Hart (1):
x86 platform driver updates

Darrick Wong (1):
XFS updates

Dave Airlie (2):
drm updates
drm AMD fixes

David Miller (4):
networking updates
networking fixes
sparc updates
networking fixes

David Sterba (1):
btrfs updates

David Teigland (1):
dlm updates

Dmitry Torokhov (2):
input updates
more input updates

Doug Ledford (1):
rdma updates

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (6):
USB/PHY driver updates
tty/serial updates
staging/IIO driver updates
driver core update
char/misc driver updates
firmware removal

Greg Ungerer (1):
m68knommu updates

Guenter Roeck (1):
hwmon updates

Helge Deller (1):
parisc updates

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
ceph updates

Ingo Molnar (24):
debugobjects fix
perf updates
RAS fix
RCU updates
scheduler updates
x86 asm updates
x86 boot updates
x86 build updates
x86 cpuid updates
x86 debug updates
x86 microcode loading updates
x86 spinlock update
syscall updates
locking updates
x86 mm changes
x86 platform updates
EFI updates
irq fixes
perf tooling updates
scheduler fixes
x86 fixes
x86 fixes
scheduler fixes
perf fixes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (2):
SCSI updates
SCSI fixes

Jan Kara (2):
UDF, reiserfs, quota, fsnotify cleanups
quota scaling updates

Jassi 

Re: Regression in virtio block driver with 4.13.2

[Laura Abbott]

On 09/15/2017 10:37 AM, Christoph Hellwig wrote:

On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote:

Hi,

Fedora got a bug report on an early version of 4.13.2
https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg


Can you check if the issue goes away when you disable
CONFIG_VIRTIO_BLK_SCSI?



Yes, the issue goes  away when CONFIG_VIRTIO_BLK_SCSI is
disabled.

Thanks,
Laura

Re: Regression in virtio block driver with 4.13.2

[Laura Abbott]

On 09/15/2017 10:37 AM, Christoph Hellwig wrote:

On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote:

Hi,

Fedora got a bug report on an early version of 4.13.2
https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg


Can you check if the issue goes away when you disable
CONFIG_VIRTIO_BLK_SCSI?



Yes, the issue goes  away when CONFIG_VIRTIO_BLK_SCSI is
disabled.

Thanks,
Laura

Re: [PATCH] irqchip/gicv3: Add support for Range Selector (RS) feature

[Shanker Donthineni]

Hi Marc,

On 09/16/2017 01:14 PM, Marc Zyngier wrote:
> On Fri, Sep 15 2017 at 10:08:56 am BST, Shanker Donthineni 
>  wrote:
> 
> Hi Shanker,
> 
>> A new feature Range Selector (RS) has been added to GIC specification
>> in order to support more than 16 CPUs at affinity level 0. New fields
>> are introduced in SGI system registers (ICC_SGI0R_EL1, ICC_SGI1R_EL1
>> and ICC_ASGI1R_EL1) to relax an artificial limit of 16 at level 0.
>>
>> - A new RSS field in ICC_CTLR_EL3, ICC_CTLR_EL1 and ICV_CTLR_EL1:
>>   [18] - Range Selector Support (RSS)
>>   0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
>>   0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
>>
>> - A new RS field in ICC_SGI0R_EL1, ICC_SGI1R_EL1 and ICC_ASGI1R_EL1:
>>   [47:44] - RangeSelector (RS) which group of 16 TargetList[n] field
>> TargetList[n] represents aff0 value ((RS*16)+n)
>> When ICC_CTLR_EL3.RSS==0 or ICC_CTLR_EL1.RSS==0, RS is RES0.
>>
>> - A new RSS field in GICD_TYPER:
>>   [26] - Range Selector Support (RSS)
>>   0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
>>   0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
>>
>> Signed-off-by: Shanker Donthineni 
>> ---
>>  drivers/irqchip/irq-gic-v3.c   | 79 
>> --
>>  include/linux/irqchip/arm-gic-v3.h |  4 ++
>>  2 files changed, 46 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index 984c3ec..ba98c94 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -56,6 +56,7 @@ struct gic_chip_data {
>>  u64 redist_stride;
>>  u32 nr_redist_regions;
>>  unsigned intirq_nr;
>> +boolhas_rss;
>>  struct partition_desc   *ppi_descs[16];
>>  };
>>  
>> @@ -483,6 +484,9 @@ static int gic_populate_rdist(void)
>>  
>>  static void gic_cpu_sys_reg_init(void)
>>  {
>> +int cpu = smp_processor_id();
>> +bool rss;
>> +
>>  /*
>>   * Need to check that the SRE bit has actually been set. If
>>   * not, it means that SRE is disabled at EL2. We're going to
>> @@ -514,6 +518,15 @@ static void gic_cpu_sys_reg_init(void)
>>  
>>  /* ... and let's hit the road... */
>>  gic_write_grpen1(1);
>> +
>> +/* GIC CPU interface has RSS capability? */
>> +rss = !!(read_sysreg_s(SYS_ICC_CTLR_EL1) & ICC_CTLR_EL1_RSS);
>> +
>> +if (gic_data.has_rss != rss)
>> +pr_info("Broken hardware, mismatch RSS, SGIs may not work\n");
> 
> I disagree with this statement. The architecture allows for a non-RSS
> GIC to be matched with RSS-aware CPUs, and vice-versa. This doesn't mean
> the system is broken.
> 

Yes, I agree with you, overlooked the spec. I'll fix it in v2 patch.


>> +else if ((cpu_logical_map(cpu) & 0xf0) && (!rss))
>> +pr_crit("MPIDR bits[7..4] must be zero, cpu=%d\n", cpu);
> 
> That's the real "Gotcha". Finding an MPIDR_EL1.Aff0 >= 16 on any CPU if
> any of the CPUs or the distributor doesn't support RSS is an integration
> blunder. Anything else is perfectly acceptable.
> 
> Unfortunately, this is not something you can decide by looking at a
> single CPU, so you'll need to accumulate some state somehow.
> 
 
Sure, I'll enhance the validation code to check CPU AFF0 value and RSS 
capability 
of each online CPU. Something like this.

 static void gic_cpu_sys_reg_init(void)
 {
 

/* Keep the RSS capability status in per_cpu variable */
per_cpu(has_rss, cpu) = !!(gic_read_ctlr() & ICC_CTLR_EL1_RSS);

/* Does it requires RSS support to send SGIs to this CPU? */
if (!MPIDR_RS(cpu_logical_map(cpu)))
return;

/* Check all the other CPUs have capable of sending SGIs to this CPU */
for_each_online_cpu(i) {
if (i == cpu)
continue;

if (!per_cpu(has_rss, i)) {
pr_crit("CPU%d doesn't support RSS, Can't send SGIs "
"to CPU%d\n", i, cpu);
continue;
}

/**
 * GIC spec says, When ICC_CTLR_EL1.RSS==1 and 
GICD_TYPER.RSS==0,
 * writing ICC_ASGI1R_EL1 register with RS != 0 is a CONSTRAINED
 * UNPREDICTABLE choice of :
 *   - The write is ignored.
 *   - The RS field is treated as 0.
 */
if (!gic_data.has_rss)
pr_crit("CPU%d has RSS support but not GIC Distributor,"
" Can't send SGIs to CPU%d", i, cpu);
}
 }

>> +
>>  }
>>  
>>  static int gic_dist_supports_lpis(void)
>> @@ -554,43 +567,13 @@ static int gic_starting_cpu(unsigned int cpu)
>>  return 0;
>>  }
>>  
>> -static 

Re: [PATCH] irqchip/gicv3: Add support for Range Selector (RS) feature

[Shanker Donthineni]

Hi Marc,

On 09/16/2017 01:14 PM, Marc Zyngier wrote:
> On Fri, Sep 15 2017 at 10:08:56 am BST, Shanker Donthineni 
>  wrote:
> 
> Hi Shanker,
> 
>> A new feature Range Selector (RS) has been added to GIC specification
>> in order to support more than 16 CPUs at affinity level 0. New fields
>> are introduced in SGI system registers (ICC_SGI0R_EL1, ICC_SGI1R_EL1
>> and ICC_ASGI1R_EL1) to relax an artificial limit of 16 at level 0.
>>
>> - A new RSS field in ICC_CTLR_EL3, ICC_CTLR_EL1 and ICV_CTLR_EL1:
>>   [18] - Range Selector Support (RSS)
>>   0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
>>   0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
>>
>> - A new RS field in ICC_SGI0R_EL1, ICC_SGI1R_EL1 and ICC_ASGI1R_EL1:
>>   [47:44] - RangeSelector (RS) which group of 16 TargetList[n] field
>> TargetList[n] represents aff0 value ((RS*16)+n)
>> When ICC_CTLR_EL3.RSS==0 or ICC_CTLR_EL1.RSS==0, RS is RES0.
>>
>> - A new RSS field in GICD_TYPER:
>>   [26] - Range Selector Support (RSS)
>>   0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported.
>>   0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported.
>>
>> Signed-off-by: Shanker Donthineni 
>> ---
>>  drivers/irqchip/irq-gic-v3.c   | 79 
>> --
>>  include/linux/irqchip/arm-gic-v3.h |  4 ++
>>  2 files changed, 46 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index 984c3ec..ba98c94 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -56,6 +56,7 @@ struct gic_chip_data {
>>  u64 redist_stride;
>>  u32 nr_redist_regions;
>>  unsigned intirq_nr;
>> +boolhas_rss;
>>  struct partition_desc   *ppi_descs[16];
>>  };
>>  
>> @@ -483,6 +484,9 @@ static int gic_populate_rdist(void)
>>  
>>  static void gic_cpu_sys_reg_init(void)
>>  {
>> +int cpu = smp_processor_id();
>> +bool rss;
>> +
>>  /*
>>   * Need to check that the SRE bit has actually been set. If
>>   * not, it means that SRE is disabled at EL2. We're going to
>> @@ -514,6 +518,15 @@ static void gic_cpu_sys_reg_init(void)
>>  
>>  /* ... and let's hit the road... */
>>  gic_write_grpen1(1);
>> +
>> +/* GIC CPU interface has RSS capability? */
>> +rss = !!(read_sysreg_s(SYS_ICC_CTLR_EL1) & ICC_CTLR_EL1_RSS);
>> +
>> +if (gic_data.has_rss != rss)
>> +pr_info("Broken hardware, mismatch RSS, SGIs may not work\n");
> 
> I disagree with this statement. The architecture allows for a non-RSS
> GIC to be matched with RSS-aware CPUs, and vice-versa. This doesn't mean
> the system is broken.
> 

Yes, I agree with you, overlooked the spec. I'll fix it in v2 patch.


>> +else if ((cpu_logical_map(cpu) & 0xf0) && (!rss))
>> +pr_crit("MPIDR bits[7..4] must be zero, cpu=%d\n", cpu);
> 
> That's the real "Gotcha". Finding an MPIDR_EL1.Aff0 >= 16 on any CPU if
> any of the CPUs or the distributor doesn't support RSS is an integration
> blunder. Anything else is perfectly acceptable.
> 
> Unfortunately, this is not something you can decide by looking at a
> single CPU, so you'll need to accumulate some state somehow.
> 
 
Sure, I'll enhance the validation code to check CPU AFF0 value and RSS 
capability 
of each online CPU. Something like this.

 static void gic_cpu_sys_reg_init(void)
 {
 

/* Keep the RSS capability status in per_cpu variable */
per_cpu(has_rss, cpu) = !!(gic_read_ctlr() & ICC_CTLR_EL1_RSS);

/* Does it requires RSS support to send SGIs to this CPU? */
if (!MPIDR_RS(cpu_logical_map(cpu)))
return;

/* Check all the other CPUs have capable of sending SGIs to this CPU */
for_each_online_cpu(i) {
if (i == cpu)
continue;

if (!per_cpu(has_rss, i)) {
pr_crit("CPU%d doesn't support RSS, Can't send SGIs "
"to CPU%d\n", i, cpu);
continue;
}

/**
 * GIC spec says, When ICC_CTLR_EL1.RSS==1 and 
GICD_TYPER.RSS==0,
 * writing ICC_ASGI1R_EL1 register with RS != 0 is a CONSTRAINED
 * UNPREDICTABLE choice of :
 *   - The write is ignored.
 *   - The RS field is treated as 0.
 */
if (!gic_data.has_rss)
pr_crit("CPU%d has RSS support but not GIC Distributor,"
" Can't send SGIs to CPU%d", i, cpu);
}
 }

>> +
>>  }
>>  
>>  static int gic_dist_supports_lpis(void)
>> @@ -554,43 +567,13 @@ static int gic_starting_cpu(unsigned int cpu)
>>  return 0;
>>  }
>>  
>> -static u16 gic_compute_target_list(int *base_cpu, const 

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

[Jonathan Cameron]

On Sat, 16 Sep 2017 15:22:23 -0700
Jonathan Cameron  wrote:

> On Thu, 14 Sep 2017 16:31:06 +0200
> Michael Hennerich  wrote:
> 
> > On 14.09.2017 15:50, Stefan Popa wrote:  
> > > SPI host drivers can use DMA to transfer data, so the buffer should be 
> > > properly allocated.
> > > Keeping it on the stack could cause an undefined behavior.
> > > 
> > > The dedicated reset function solves this issue.
> > > 
> > > Signed-off-by: Stefan Popa 
> > 
> > Acked-by: Michael Hennerich   
> 
> Applied to the togreg branch of iio.git rather than staging
> branch as the reset functionality is reasonably recent and
> not going to be available in stable kernels etc..
> 
> Good work. I was reading this on a plane the other day and
> noticed the same issue - always nice when someone else
> fixes something on your todo list ;)
> 
> Jonathan

Doh, I had forgotten the support was part of a fix for a different
driver so is only in the fixes-togreg branch of iio.git.

I'll take this one the same way with a bit of a tweak to the patch
title to make it clear it is fixing something.

Jonathan
> 
> > 
> > Well done!
> > 
> >   
> > > ---
> > >   drivers/staging/iio/adc/ad7192.c | 4 +---
> > >   1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/staging/iio/adc/ad7192.c 
> > > b/drivers/staging/iio/adc/ad7192.c
> > > index d11c6de..6150d27 100644
> > > --- a/drivers/staging/iio/adc/ad7192.c
> > > +++ b/drivers/staging/iio/adc/ad7192.c
> > > @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st,
> > >   struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
> > >   unsigned long long scale_uv;
> > >   int i, ret, id;
> > > - u8 ones[6];
> > >   
> > >   /* reset the serial interface */
> > > - memset(, 0xFF, 6);
> > > - ret = spi_write(st->sd.spi, , 6);
> > > + ret = ad_sd_reset(>sd, 48);
> > >   if (ret < 0)
> > >   goto out;
> > >   usleep_range(500, 1000); /* Wait for at least 500us */
> > > 
> > 
> >   
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

[Jonathan Cameron]

On Sat, 16 Sep 2017 15:22:23 -0700
Jonathan Cameron  wrote:

> On Thu, 14 Sep 2017 16:31:06 +0200
> Michael Hennerich  wrote:
> 
> > On 14.09.2017 15:50, Stefan Popa wrote:  
> > > SPI host drivers can use DMA to transfer data, so the buffer should be 
> > > properly allocated.
> > > Keeping it on the stack could cause an undefined behavior.
> > > 
> > > The dedicated reset function solves this issue.
> > > 
> > > Signed-off-by: Stefan Popa 
> > 
> > Acked-by: Michael Hennerich   
> 
> Applied to the togreg branch of iio.git rather than staging
> branch as the reset functionality is reasonably recent and
> not going to be available in stable kernels etc..
> 
> Good work. I was reading this on a plane the other day and
> noticed the same issue - always nice when someone else
> fixes something on your todo list ;)
> 
> Jonathan

Doh, I had forgotten the support was part of a fix for a different
driver so is only in the fixes-togreg branch of iio.git.

I'll take this one the same way with a bit of a tweak to the patch
title to make it clear it is fixing something.

Jonathan
> 
> > 
> > Well done!
> > 
> >   
> > > ---
> > >   drivers/staging/iio/adc/ad7192.c | 4 +---
> > >   1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/staging/iio/adc/ad7192.c 
> > > b/drivers/staging/iio/adc/ad7192.c
> > > index d11c6de..6150d27 100644
> > > --- a/drivers/staging/iio/adc/ad7192.c
> > > +++ b/drivers/staging/iio/adc/ad7192.c
> > > @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st,
> > >   struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
> > >   unsigned long long scale_uv;
> > >   int i, ret, id;
> > > - u8 ones[6];
> > >   
> > >   /* reset the serial interface */
> > > - memset(, 0xFF, 6);
> > > - ret = spi_write(st->sd.spi, , 6);
> > > + ret = ad_sd_reset(>sd, 48);
> > >   if (ret < 0)
> > >   goto out;
> > >   usleep_range(500, 1000); /* Wait for at least 500us */
> > > 
> > 
> >   
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

[Jonathan Cameron]

On Thu, 14 Sep 2017 16:31:06 +0200
Michael Hennerich  wrote:

> On 14.09.2017 15:50, Stefan Popa wrote:
> > SPI host drivers can use DMA to transfer data, so the buffer should be 
> > properly allocated.
> > Keeping it on the stack could cause an undefined behavior.
> > 
> > The dedicated reset function solves this issue.
> > 
> > Signed-off-by: Stefan Popa   
> 
> Acked-by: Michael Hennerich 

Applied to the togreg branch of iio.git rather than staging
branch as the reset functionality is reasonably recent and
not going to be available in stable kernels etc..

Good work. I was reading this on a plane the other day and
noticed the same issue - always nice when someone else
fixes something on your todo list ;)

Jonathan

> 
> Well done!
> 
> 
> > ---
> >   drivers/staging/iio/adc/ad7192.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/adc/ad7192.c 
> > b/drivers/staging/iio/adc/ad7192.c
> > index d11c6de..6150d27 100644
> > --- a/drivers/staging/iio/adc/ad7192.c
> > +++ b/drivers/staging/iio/adc/ad7192.c
> > @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st,
> > struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
> > unsigned long long scale_uv;
> > int i, ret, id;
> > -   u8 ones[6];
> >   
> > /* reset the serial interface */
> > -   memset(, 0xFF, 6);
> > -   ret = spi_write(st->sd.spi, , 6);
> > +   ret = ad_sd_reset(>sd, 48);
> > if (ret < 0)
> > goto out;
> > usleep_range(500, 1000); /* Wait for at least 500us */
> >   
> 
> 

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

[Andrey Ryabinin]

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote:
> On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote:
>> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin
>>  wrote:
>>>
>>> I'm not so sure that this is disabled optimization. I assume that global 
>>> rsp makes
>>> changes something in gcc's register allocation logic, or something like 
>>> that leading
>>> to subtle changes in generated code.
>>>
>>> But what I recently find out, is that this "regression" sometimes is 
>>> actually improvement in .text size.
>>> It all depends on .config, e.g:
>>
>> Oh, that would be lovely and solve all the issues.
>>
>> And looking at the code generation differences for one file
>> (kernel/futex.c) and one single config (my default config), the thing
>> that the global stack register seems to change is that it moves some
>> code - particularly completely unrelated inline asm code - inside the
>> region protected by frame pointers.
>>
>> There are a few register allocation changes too, but they didn't seem
>> to make code worse, and I think they were just "incidental" from code
>> movement. And most code movement really seemed to be around inline
>> asms, I  wonder if the gcc logic simply is something like "if the
>> stack pointer is visible as a register, don't move any inline asm
>> across a frame setup".
>>
>> In fact, on that one file and one configuration, the resulting
>> assembler file had three fewer lines of code with that global stack
>> register declaration than with the local one.
>>
>> So at least from just that one case, I can back up Andrey's
>> observation: it's not that the code gets worse, it just is slightly
>> different. Sometimes it's better.
>>
>> So maybe that simple patch to just make the stack pointer be a global
>> register declaration really is the fix for this issue.
>>
>> It's not *pretty*, and I'd much rather just see some explicit way for
>> us to say "this asm wants the frame to be set up", but of the
>> alternatives we've seen, maybe it's the right thing to do?
> 
> Ok, here's the (compile tested) patch in case anybody wants to try it
> out.
> 

I already had almost the same patch, so I just used mine. Patch seems to be
the same as yours except cosmetic details which shouldn't affect the end result.
But just in case it posted below.


The patch was applied on top of b38923a068c10fc36ca8f596d650d095ce390b85 commit,
kernel compiled gcc 7.2.0 

allnoconfig:   textdata bss dec hex filename
base   946920  206384 1215752 2369056  242620 allnoconfig/vmlinux
patched946501  206384 1215752 2368637  24247d allnoconfig_p/vmlinux

defconfig: textdata bss dec hex filename
base   10729978484  876544 16446522 faf43a 
defconfig/vmlinux
patched10730666484  876544 16447210 faf6ea 
defconfig_p/vmlinux

allyesconfig:   textdata bss dec hex filename
base161016572   152888347   49303552363208471   
15a61f17allyesconfig/vmlinux
patched 161003557   152888347   49303552363195456   
15a5ec40allyesconfig_p/vmlinux


---
 arch/x86/include/asm/alternative.h|  3 +--
 arch/x86/include/asm/asm.h|  2 ++
 arch/x86/include/asm/mshyperv.h   | 10 --
 arch/x86/include/asm/paravirt_types.h | 12 +---
 arch/x86/include/asm/preempt.h|  6 ++
 arch/x86/include/asm/processor.h  |  6 ++
 arch/x86/include/asm/rwsem.h  |  3 +--
 arch/x86/include/asm/thread_info.h|  1 -
 arch/x86/include/asm/uaccess.h|  5 +++--
 arch/x86/include/asm/xen/hypercall.h  |  5 ++---
 arch/x86/kvm/emulate.c|  3 +--
 arch/x86/kvm/vmx.c|  3 +--
 arch/x86/mm/fault.c   |  3 +--
 13 files changed, 25 insertions(+), 37 deletions(-)

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

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

[Jonathan Cameron]

On Thu, 14 Sep 2017 16:31:06 +0200
Michael Hennerich  wrote:

> On 14.09.2017 15:50, Stefan Popa wrote:
> > SPI host drivers can use DMA to transfer data, so the buffer should be 
> > properly allocated.
> > Keeping it on the stack could cause an undefined behavior.
> > 
> > The dedicated reset function solves this issue.
> > 
> > Signed-off-by: Stefan Popa   
> 
> Acked-by: Michael Hennerich 

Applied to the togreg branch of iio.git rather than staging
branch as the reset functionality is reasonably recent and
not going to be available in stable kernels etc..

Good work. I was reading this on a plane the other day and
noticed the same issue - always nice when someone else
fixes something on your todo list ;)

Jonathan

> 
> Well done!
> 
> 
> > ---
> >   drivers/staging/iio/adc/ad7192.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/adc/ad7192.c 
> > b/drivers/staging/iio/adc/ad7192.c
> > index d11c6de..6150d27 100644
> > --- a/drivers/staging/iio/adc/ad7192.c
> > +++ b/drivers/staging/iio/adc/ad7192.c
> > @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st,
> > struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
> > unsigned long long scale_uv;
> > int i, ret, id;
> > -   u8 ones[6];
> >   
> > /* reset the serial interface */
> > -   memset(, 0xFF, 6);
> > -   ret = spi_write(st->sd.spi, , 6);
> > +   ret = ad_sd_reset(>sd, 48);
> > if (ret < 0)
> > goto out;
> > usleep_range(500, 1000); /* Wait for at least 500us */
> >   
> 
> 

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

[Andrey Ryabinin]

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote:
> On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote:
>> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin
>>  wrote:
>>>
>>> I'm not so sure that this is disabled optimization. I assume that global 
>>> rsp makes
>>> changes something in gcc's register allocation logic, or something like 
>>> that leading
>>> to subtle changes in generated code.
>>>
>>> But what I recently find out, is that this "regression" sometimes is 
>>> actually improvement in .text size.
>>> It all depends on .config, e.g:
>>
>> Oh, that would be lovely and solve all the issues.
>>
>> And looking at the code generation differences for one file
>> (kernel/futex.c) and one single config (my default config), the thing
>> that the global stack register seems to change is that it moves some
>> code - particularly completely unrelated inline asm code - inside the
>> region protected by frame pointers.
>>
>> There are a few register allocation changes too, but they didn't seem
>> to make code worse, and I think they were just "incidental" from code
>> movement. And most code movement really seemed to be around inline
>> asms, I  wonder if the gcc logic simply is something like "if the
>> stack pointer is visible as a register, don't move any inline asm
>> across a frame setup".
>>
>> In fact, on that one file and one configuration, the resulting
>> assembler file had three fewer lines of code with that global stack
>> register declaration than with the local one.
>>
>> So at least from just that one case, I can back up Andrey's
>> observation: it's not that the code gets worse, it just is slightly
>> different. Sometimes it's better.
>>
>> So maybe that simple patch to just make the stack pointer be a global
>> register declaration really is the fix for this issue.
>>
>> It's not *pretty*, and I'd much rather just see some explicit way for
>> us to say "this asm wants the frame to be set up", but of the
>> alternatives we've seen, maybe it's the right thing to do?
> 
> Ok, here's the (compile tested) patch in case anybody wants to try it
> out.
> 

I already had almost the same patch, so I just used mine. Patch seems to be
the same as yours except cosmetic details which shouldn't affect the end result.
But just in case it posted below.


The patch was applied on top of b38923a068c10fc36ca8f596d650d095ce390b85 commit,
kernel compiled gcc 7.2.0 

allnoconfig:   textdata bss dec hex filename
base   946920  206384 1215752 2369056  242620 allnoconfig/vmlinux
patched946501  206384 1215752 2368637  24247d allnoconfig_p/vmlinux

defconfig: textdata bss dec hex filename
base   10729978484  876544 16446522 faf43a 
defconfig/vmlinux
patched10730666484  876544 16447210 faf6ea 
defconfig_p/vmlinux

allyesconfig:   textdata bss dec hex filename
base161016572   152888347   49303552363208471   
15a61f17allyesconfig/vmlinux
patched 161003557   152888347   49303552363195456   
15a5ec40allyesconfig_p/vmlinux


---
 arch/x86/include/asm/alternative.h|  3 +--
 arch/x86/include/asm/asm.h|  2 ++
 arch/x86/include/asm/mshyperv.h   | 10 --
 arch/x86/include/asm/paravirt_types.h | 12 +---
 arch/x86/include/asm/preempt.h|  6 ++
 arch/x86/include/asm/processor.h  |  6 ++
 arch/x86/include/asm/rwsem.h  |  3 +--
 arch/x86/include/asm/thread_info.h|  1 -
 arch/x86/include/asm/uaccess.h|  5 +++--
 arch/x86/include/asm/xen/hypercall.h  |  5 ++---
 arch/x86/kvm/emulate.c|  3 +--
 arch/x86/kvm/vmx.c|  3 +--
 arch/x86/mm/fault.c   |  3 +--
 13 files changed, 25 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 1b020381ab38..8e3174258c5f 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -218,10 +218,9 @@ static inline int alternatives_text_reserved(void *start, 
void *end)
 #define alternative_call_2(oldfunc, newfunc1, feature1, newfunc2, feature2,   \
   output, input...)  \
 {\
-   register void *__sp asm(_ASM_SP); \
asm volatile (ALTERNATIVE_2("call %P[old]", "call %P[new1]", feature1,\
"call %P[new2]", feature2)\
-   : output, "+r" (__sp) \
+   : output, "+r" (__current_sp)   
  \
: [old] "i" (oldfunc), [new1] "i" (newfunc1), \
  [new2] "i" (newfunc2), ## input);   \
 }
diff --git 

Re: [PATCH] iio: cros_ec: Remove unused variable

[Jonathan Cameron]

On Thu, 14 Sep 2017 23:19:22 +0200
Paolo Cretaro  wrote:

> Fix gcc warning:
> cros_ec_baro.c:130:25: warning: variable ‘ec_device’ set but not used
> 
> Signed-off-by: Paolo Cretaro 

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/pressure/cros_ec_baro.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iio/pressure/cros_ec_baro.c 
> b/drivers/iio/pressure/cros_ec_baro.c
> index 48b2a30f57ae..5fd32ad6c64d 100644
> --- a/drivers/iio/pressure/cros_ec_baro.c
> +++ b/drivers/iio/pressure/cros_ec_baro.c
> @@ -127,7 +127,6 @@ static int cros_ec_baro_probe(struct platform_device 
> *pdev)
>  {
>   struct device *dev = >dev;
>   struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
> - struct cros_ec_device *ec_device;
>   struct iio_dev *indio_dev;
>   struct cros_ec_baro_state *state;
>   struct iio_chan_spec *channel;
> @@ -137,7 +136,6 @@ static int cros_ec_baro_probe(struct platform_device 
> *pdev)
>   dev_warn(dev, "No CROS EC device found.\n");
>   return -EINVAL;
>   }
> - ec_device = ec_dev->ec_dev;
>  
>   indio_dev = devm_iio_device_alloc(dev, sizeof(*state));
>   if (!indio_dev)

Re: [PATCH] iio: cros_ec: Remove unused variable

[Jonathan Cameron]

On Thu, 14 Sep 2017 23:19:22 +0200
Paolo Cretaro  wrote:

> Fix gcc warning:
> cros_ec_baro.c:130:25: warning: variable ‘ec_device’ set but not used
> 
> Signed-off-by: Paolo Cretaro 

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan
> ---
>  drivers/iio/pressure/cros_ec_baro.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iio/pressure/cros_ec_baro.c 
> b/drivers/iio/pressure/cros_ec_baro.c
> index 48b2a30f57ae..5fd32ad6c64d 100644
> --- a/drivers/iio/pressure/cros_ec_baro.c
> +++ b/drivers/iio/pressure/cros_ec_baro.c
> @@ -127,7 +127,6 @@ static int cros_ec_baro_probe(struct platform_device 
> *pdev)
>  {
>   struct device *dev = >dev;
>   struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
> - struct cros_ec_device *ec_device;
>   struct iio_dev *indio_dev;
>   struct cros_ec_baro_state *state;
>   struct iio_chan_spec *channel;
> @@ -137,7 +136,6 @@ static int cros_ec_baro_probe(struct platform_device 
> *pdev)
>   dev_warn(dev, "No CROS EC device found.\n");
>   return -EINVAL;
>   }
> - ec_device = ec_dev->ec_dev;
>  
>   indio_dev = devm_iio_device_alloc(dev, sizeof(*state));
>   if (!indio_dev)

Re: [PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone

[Jonathan Cameron]

On Sat, 16 Sep 2017 12:05:49 +0200
Quentin Schulz  wrote:

> Hi Icenowy,
> 
> On 14/09/2017 16:52, Icenowy Zheng wrote:
> > Because of the restriction of the OF thermal framework, the thermal
> > sensor will fail to probe if the thermal zone doesn't exist.
> >   
> 
> Oh no, that's not good.
> 
> We discussed about it on IRC and I even proposed a patch for it, telling
> you I would post it on the mailing list soon after. Of course, I forgot
> and you definitely should have yelled at me for not doing it :)
> 
> I won't be able to test the patch soon. I can send it to you so that you
> can test it and integrate it in your patch series so it won't block you.
> Otherwise, we'll have to wait for a week or two for me to test it.
> 
> Thanks and sorry for forgetting to post the patch you need,
> Quentin

Other this outstanding issue I'm happy with the series, so hopefully
with Quentin's patch added we should be good to merge this one.

Jonathan

> 
> > Add a partial thermal zone which claims the H3 THS as the thermal sensor.
> > 
> > The cooling device (CPU DVFS) is still not added as it's not ready, and
> > the trip points are also not added yet.
> > 
> > Signed-off-by: Icenowy Zheng 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 3220da3ad790..687c6457d214 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -89,6 +89,15 @@
> > };
> > };
> >  
> > +   thermal-zones {
> > +   cpu-thermal {
> > +   /* milliseconds */
> > +   polling-delay-passive = <250>;
> > +   polling-delay = <1000>;
> > +   thermal-sensors = <>;
> > +   };
> > +   };
> > +
> > timer {
> > compatible = "arm,armv7-timer";
> > interrupts =  > IRQ_TYPE_LEVEL_LOW)>,
> >   
> 

Re: [PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone

[Jonathan Cameron]

On Sat, 16 Sep 2017 12:05:49 +0200
Quentin Schulz  wrote:

> Hi Icenowy,
> 
> On 14/09/2017 16:52, Icenowy Zheng wrote:
> > Because of the restriction of the OF thermal framework, the thermal
> > sensor will fail to probe if the thermal zone doesn't exist.
> >   
> 
> Oh no, that's not good.
> 
> We discussed about it on IRC and I even proposed a patch for it, telling
> you I would post it on the mailing list soon after. Of course, I forgot
> and you definitely should have yelled at me for not doing it :)
> 
> I won't be able to test the patch soon. I can send it to you so that you
> can test it and integrate it in your patch series so it won't block you.
> Otherwise, we'll have to wait for a week or two for me to test it.
> 
> Thanks and sorry for forgetting to post the patch you need,
> Quentin

Other this outstanding issue I'm happy with the series, so hopefully
with Quentin's patch added we should be good to merge this one.

Jonathan

> 
> > Add a partial thermal zone which claims the H3 THS as the thermal sensor.
> > 
> > The cooling device (CPU DVFS) is still not added as it's not ready, and
> > the trip points are also not added yet.
> > 
> > Signed-off-by: Icenowy Zheng 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 3220da3ad790..687c6457d214 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -89,6 +89,15 @@
> > };
> > };
> >  
> > +   thermal-zones {
> > +   cpu-thermal {
> > +   /* milliseconds */
> > +   polling-delay-passive = <250>;
> > +   polling-delay = <1000>;
> > +   thermal-sensors = <>;
> > +   };
> > +   };
> > +
> > timer {
> > compatible = "arm,armv7-timer";
> > interrupts =  > IRQ_TYPE_LEVEL_LOW)>,
> >   
> 

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[Jonathan Cameron]

On Sat, 16 Sep 2017 11:45:47 +0200
Quentin Schulz  wrote:

> Hi Icenowy,
> 
> On 14/09/2017 16:52, Icenowy Zheng wrote:
> > This adds support for the Allwinner H3 thermal sensor.
> > 
> > Allwinner H3 has a thermal sensor like the one in A33, but have its
> > registers nearly all re-arranged, sample clock moved to CCU and a pair
> > of bus clock and reset added. It's also the base of newer SoCs' thermal
> > sensors.
> > 
> > The thermal sensors on A64 and H5 is like the one on H3, but with of
> > course different formula factors.
> > 
> > Signed-off-by: Icenowy Zheng 
> > ---
> > Changes in v4:
> > - Splitted out some code refactors.
> > - Code sequence changed back. (The gpadc_data went back to the start of
> >   the source file)
> > 
> >  drivers/iio/adc/sun4i-gpadc-iio.c | 48 
> > +++
> >  include/linux/mfd/sun4i-gpadc.h   | 27 ++
> >  2 files changed, 75 insertions(+)  
> [...]
> > diff --git a/include/linux/mfd/sun4i-gpadc.h 
> > b/include/linux/mfd/sun4i-gpadc.h
> > index 78d31984a222..5c2a12101052 100644
> > --- a/include/linux/mfd/sun4i-gpadc.h
> > +++ b/include/linux/mfd/sun4i-gpadc.h  
> [...]
> > +#define SUN8I_H3_GPADC_CTRL2_T_ACQ1(x) ((GENMASK(15, 
> > 0) * (x)) << 16)
> > +  
> 
> You want to replace * by &.
> 
> ((GENMASK(15, 0) & (x)) << 16)
> 
> Would ((GENMASK(31, 16) & ((x) << 16)) make the bits you set even more
> obvious?

Agreed. Would act as better 'documentation'.

Jonathan
> 
> >  #define SUN4I_GPADC_CTRL3  0x0c
> > +/*
> > + * This register is named "Average filter Control Register" in H3 
> > Datasheet,
> > + * but the register's definition is the same as the old CTRL3 register.
> > + */
> > +#define SUN8I_H3_GPADC_CTRL3   0x70
> >
> 
> I would name it as it is in the documentation:
> SUN8I_H3_THS_FILTER
> 
> No need for comments then.
> 
> >  #define SUN4I_GPADC_CTRL3_FILTER_ENBIT(2)
> >  #define SUN4I_GPADC_CTRL3_FILTER_TYPE(x)   (GENMASK(1, 0) & (x))
> > @@ -71,6 +84,13 @@
> >  #define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN BIT(1)
> >  #define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN   BIT(0)
> >  
> > +#define SUN8I_H3_GPADC_INTC0x44
> > +
> > +#define SUN8I_H3_GPADC_INTC_TEMP_PERIOD(x) ((GENMASK(19, 0) & (x)) 
> > << 12)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_DATA  BIT(8)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_SHUT  BIT(4)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_ALARM BIT(0)
> > +  
> 
> Since it isn't an ADC anymore but rather just a THS, why don't you use
> SUN8I_H3_THS instead of SUN8I_H3_GPADC? That way, it also matches the
> datasheet.
> 
> >  #define SUN4I_GPADC_INT_FIFOS  0x14
> >  
> >  #define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDINGBIT(18)
> > @@ -80,9 +100,16 @@
> >  #define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDINGBIT(1)
> >  #define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING  BIT(0)
> >  
> > +#define SUN8I_H3_GPADC_INTS0x44  
> 
> 0x48
> 
> [...]
> 
> 1) You're not using irqs, why would you define registers that will never
> be used?
> 
> 2) Why aren't you using irqs? I remember we discussed on IRC that you
> had some problems with the H3 when resuming or when probing the driver.
> The register would have a zero in it until you have a first sample that
> arrived (i.e. after the sample rate you set with T_ACQ) that would make
> the thermal framework panic since the thermal sensor would return
> something way too hot and shutdown your board?
> 
> The H3 apparently supports IRQs, why do you not support them for the
> temperature? They might be broken as it is on A33 but then it might be a
> good idea to write it down in a comment in the driver (and not adding
> the unused registers in the header file) or at least in the commit log.
> 
> 3) Now that you have support for clocks, wouldn't it be a good idea to
> disable them during suspend?
> 
> Thanks,
> Quentin

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[Jonathan Cameron]

On Sat, 16 Sep 2017 11:45:47 +0200
Quentin Schulz  wrote:

> Hi Icenowy,
> 
> On 14/09/2017 16:52, Icenowy Zheng wrote:
> > This adds support for the Allwinner H3 thermal sensor.
> > 
> > Allwinner H3 has a thermal sensor like the one in A33, but have its
> > registers nearly all re-arranged, sample clock moved to CCU and a pair
> > of bus clock and reset added. It's also the base of newer SoCs' thermal
> > sensors.
> > 
> > The thermal sensors on A64 and H5 is like the one on H3, but with of
> > course different formula factors.
> > 
> > Signed-off-by: Icenowy Zheng 
> > ---
> > Changes in v4:
> > - Splitted out some code refactors.
> > - Code sequence changed back. (The gpadc_data went back to the start of
> >   the source file)
> > 
> >  drivers/iio/adc/sun4i-gpadc-iio.c | 48 
> > +++
> >  include/linux/mfd/sun4i-gpadc.h   | 27 ++
> >  2 files changed, 75 insertions(+)  
> [...]
> > diff --git a/include/linux/mfd/sun4i-gpadc.h 
> > b/include/linux/mfd/sun4i-gpadc.h
> > index 78d31984a222..5c2a12101052 100644
> > --- a/include/linux/mfd/sun4i-gpadc.h
> > +++ b/include/linux/mfd/sun4i-gpadc.h  
> [...]
> > +#define SUN8I_H3_GPADC_CTRL2_T_ACQ1(x) ((GENMASK(15, 
> > 0) * (x)) << 16)
> > +  
> 
> You want to replace * by &.
> 
> ((GENMASK(15, 0) & (x)) << 16)
> 
> Would ((GENMASK(31, 16) & ((x) << 16)) make the bits you set even more
> obvious?

Agreed. Would act as better 'documentation'.

Jonathan
> 
> >  #define SUN4I_GPADC_CTRL3  0x0c
> > +/*
> > + * This register is named "Average filter Control Register" in H3 
> > Datasheet,
> > + * but the register's definition is the same as the old CTRL3 register.
> > + */
> > +#define SUN8I_H3_GPADC_CTRL3   0x70
> >
> 
> I would name it as it is in the documentation:
> SUN8I_H3_THS_FILTER
> 
> No need for comments then.
> 
> >  #define SUN4I_GPADC_CTRL3_FILTER_ENBIT(2)
> >  #define SUN4I_GPADC_CTRL3_FILTER_TYPE(x)   (GENMASK(1, 0) & (x))
> > @@ -71,6 +84,13 @@
> >  #define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN BIT(1)
> >  #define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN   BIT(0)
> >  
> > +#define SUN8I_H3_GPADC_INTC0x44
> > +
> > +#define SUN8I_H3_GPADC_INTC_TEMP_PERIOD(x) ((GENMASK(19, 0) & (x)) 
> > << 12)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_DATA  BIT(8)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_SHUT  BIT(4)
> > +#define SUN8I_H3_GPADC_INTC_TEMP_ALARM BIT(0)
> > +  
> 
> Since it isn't an ADC anymore but rather just a THS, why don't you use
> SUN8I_H3_THS instead of SUN8I_H3_GPADC? That way, it also matches the
> datasheet.
> 
> >  #define SUN4I_GPADC_INT_FIFOS  0x14
> >  
> >  #define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDINGBIT(18)
> > @@ -80,9 +100,16 @@
> >  #define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDINGBIT(1)
> >  #define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING  BIT(0)
> >  
> > +#define SUN8I_H3_GPADC_INTS0x44  
> 
> 0x48
> 
> [...]
> 
> 1) You're not using irqs, why would you define registers that will never
> be used?
> 
> 2) Why aren't you using irqs? I remember we discussed on IRC that you
> had some problems with the H3 when resuming or when probing the driver.
> The register would have a zero in it until you have a first sample that
> arrived (i.e. after the sample rate you set with T_ACQ) that would make
> the thermal framework panic since the thermal sensor would return
> something way too hot and shutdown your board?
> 
> The H3 apparently supports IRQs, why do you not support them for the
> temperature? They might be broken as it is on A33 but then it might be a
> good idea to write it down in a comment in the driver (and not adding
> the unused registers in the header file) or at least in the commit log.
> 
> 3) Now that you have support for clocks, wouldn't it be a good idea to
> disable them during suspend?
> 
> Thanks,
> Quentin

Re: [PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3

[Jonathan Cameron]

On Thu, 14 Sep 2017 22:52:46 +0800
Icenowy Zheng  wrote:

> Allwinner H3 features a thermal sensor like the one in A33, but has its
> register re-arranged, the clock divider moved to CCU (originally the
> clock divider is in ADC) and added a pair of bus clock and reset.
> 
> Update the binding document to cover H3.
> 
> Signed-off-by: Icenowy Zheng 
> Reviewed-by: Chen-Yu Tsai 
> ---
> Changes in v4:
> - Add nvmem calibration data (not yet used by the driver)
> Changes in v3:
> - Clock name changes.
> - Example node name changes.
> - Add interupts (not yet used by the driver).
> 
>  .../devicetree/bindings/mfd/sun4i-gpadc.txt| 30 
> --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt 
> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> index badff3611a98..6c470d584bf9 100644
> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -4,12 +4,26 @@ The Allwinner SoCs all have an ADC that can also act as a 
> thermal sensor
>  and sometimes as a touchscreen controller.
>  
>  Required properties:
> -  - compatible: "allwinner,sun8i-a33-ths",
> +  - compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a33-ths"
> + - "allwinner,sun8i-h3-ths"
>- reg: mmio address range of the chip,
>- #thermal-sensor-cells: shall be 0,
>- #io-channel-cells: shall be 0,
>  
> -Example:
> +Optional properties:
> +  - nvmem-cells: A phandle to the calibration data provided by a nvmem 
> device.
> + If unspecified default values shall be used.
> +  - nvmem-cell-names: Should be "calibration-data"

I think a cross reference to the nvmem binding docs would be good here.
It wasn't something I could remember coming across before.  Obviously
grep gets you there quickly enough, but a cross reference would be even
better.

Also would it make sense to have an example with these in?

Jonathan
> +
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> +  - clocks: the bus clock and the input clock of the ADC,
> +  - clock-names: should be "bus" and "mod",
> +  - resets: the bus reset of the ADC,
> +  - interrupts: the sampling interrupt of the ADC,
> +
> +Example for A33:
>   ths: ths@01c25000 {
>   compatible = "allwinner,sun8i-a33-ths";
>   reg = <0x01c25000 0x100>;
> @@ -17,6 +31,18 @@ Example:
>   #io-channel-cells = <0>;
>   };
>  
> +Example for H3:
> + ths: thermal-sensor@1c25000 {
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x400>;
> + clocks = < CLK_BUS_THS>, < CLK_THS>;
> + clock-names = "bus", "mod";
> + resets = < RST_BUS_THS>;
> + interrupts = ;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
>  sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>  
>  sun4i resistive touchscreen controller

Re: [PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3

[Jonathan Cameron]

On Thu, 14 Sep 2017 22:52:46 +0800
Icenowy Zheng  wrote:

> Allwinner H3 features a thermal sensor like the one in A33, but has its
> register re-arranged, the clock divider moved to CCU (originally the
> clock divider is in ADC) and added a pair of bus clock and reset.
> 
> Update the binding document to cover H3.
> 
> Signed-off-by: Icenowy Zheng 
> Reviewed-by: Chen-Yu Tsai 
> ---
> Changes in v4:
> - Add nvmem calibration data (not yet used by the driver)
> Changes in v3:
> - Clock name changes.
> - Example node name changes.
> - Add interupts (not yet used by the driver).
> 
>  .../devicetree/bindings/mfd/sun4i-gpadc.txt| 30 
> --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt 
> b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> index badff3611a98..6c470d584bf9 100644
> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -4,12 +4,26 @@ The Allwinner SoCs all have an ADC that can also act as a 
> thermal sensor
>  and sometimes as a touchscreen controller.
>  
>  Required properties:
> -  - compatible: "allwinner,sun8i-a33-ths",
> +  - compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a33-ths"
> + - "allwinner,sun8i-h3-ths"
>- reg: mmio address range of the chip,
>- #thermal-sensor-cells: shall be 0,
>- #io-channel-cells: shall be 0,
>  
> -Example:
> +Optional properties:
> +  - nvmem-cells: A phandle to the calibration data provided by a nvmem 
> device.
> + If unspecified default values shall be used.
> +  - nvmem-cell-names: Should be "calibration-data"

I think a cross reference to the nvmem binding docs would be good here.
It wasn't something I could remember coming across before.  Obviously
grep gets you there quickly enough, but a cross reference would be even
better.

Also would it make sense to have an example with these in?

Jonathan
> +
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> +  - clocks: the bus clock and the input clock of the ADC,
> +  - clock-names: should be "bus" and "mod",
> +  - resets: the bus reset of the ADC,
> +  - interrupts: the sampling interrupt of the ADC,
> +
> +Example for A33:
>   ths: ths@01c25000 {
>   compatible = "allwinner,sun8i-a33-ths";
>   reg = <0x01c25000 0x100>;
> @@ -17,6 +31,18 @@ Example:
>   #io-channel-cells = <0>;
>   };
>  
> +Example for H3:
> + ths: thermal-sensor@1c25000 {
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x400>;
> + clocks = < CLK_BUS_THS>, < CLK_THS>;
> + clock-names = "bus", "mod";
> + resets = < RST_BUS_THS>;
> + interrupts = ;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
>  sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>  
>  sun4i resistive touchscreen controller

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Linus Torvalds]

On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner  wrote:
>
> Yes and no. We get more code which uses cpumasks to store state, just like
> I did, and while a lot of the cpumask functions just work as expected a
> subset including for_each_cpu does not. That's confusing at best and I
> rather avoid the hard to debug issues on UP, which probably gets less
> testing anyway.

I certainly agree that the UP situation has changed over the years.

But I'd hate to make all those loops etc (that the compiler can
currently almost always trivially turn into trivial unconditional
non-loops) be sometrhing that ends up testing a bit and having a
conditional.

I wonder if we could have some checking mode or something that at
least makes those things easier to notice.  But I don't see a sane way
to do that statically.

Looking at that patch of yours, it seems to depend on
'watchdog_allowed_mask' having just been initialized as empty, which
is the case that doesn't work well for UP. So there isn't even any
code to trigger on, it would have to be some added warning to all
users that does something along the lines of 'WARN_ON_ONCE(cpumask !=
1)'

.. and then hardly anybody would run that configuration anyway.

Annoying.

  Linus

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Linus Torvalds]

On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner  wrote:
>
> Yes and no. We get more code which uses cpumasks to store state, just like
> I did, and while a lot of the cpumask functions just work as expected a
> subset including for_each_cpu does not. That's confusing at best and I
> rather avoid the hard to debug issues on UP, which probably gets less
> testing anyway.

I certainly agree that the UP situation has changed over the years.

But I'd hate to make all those loops etc (that the compiler can
currently almost always trivially turn into trivial unconditional
non-loops) be sometrhing that ends up testing a bit and having a
conditional.

I wonder if we could have some checking mode or something that at
least makes those things easier to notice.  But I don't see a sane way
to do that statically.

Looking at that patch of yours, it seems to depend on
'watchdog_allowed_mask' having just been initialized as empty, which
is the case that doesn't work well for UP. So there isn't even any
code to trigger on, it would have to be some added warning to all
users that does something along the lines of 'WARN_ON_ONCE(cpumask !=
1)'

.. and then hardly anybody would run that configuration anyway.

Annoying.

  Linus

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Thomas Gleixner]

On Sat, 16 Sep 2017, Linus Torvalds wrote:
> On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner  wrote:
> >>
> >> So I suspect your perf fix is the right one, and maybe we could/should
> >> just make people more aware of the empty cpumask issue with UP.
> >
> > Right, I just got a bit frightened as I really was not aware about that
> > 'opmtimization' which means that so far I just was lucky not to trip over
> > it.
> 
> Yeah. I can't say that I was really aware of it either in a every-day
> kind of way, it was only when I looked it up that I went "Oh, right,
> that's what we did".
> 
> So it's subtle and unexpected, and the saving grace is basically that
> empty cpumasks are really the exception to begin with. They basically
> don't happen in normal situations.

Yes and no. We get more code which uses cpumasks to store state, just like
I did, and while a lot of the cpumask functions just work as expected a
subset including for_each_cpu does not. That's confusing at best and I
rather avoid the hard to debug issues on UP, which probably gets less
testing anyway.

Thanks,

tglx

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Thomas Gleixner]

On Sat, 16 Sep 2017, Linus Torvalds wrote:
> On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner  wrote:
> >>
> >> So I suspect your perf fix is the right one, and maybe we could/should
> >> just make people more aware of the empty cpumask issue with UP.
> >
> > Right, I just got a bit frightened as I really was not aware about that
> > 'opmtimization' which means that so far I just was lucky not to trip over
> > it.
> 
> Yeah. I can't say that I was really aware of it either in a every-day
> kind of way, it was only when I looked it up that I went "Oh, right,
> that's what we did".
> 
> So it's subtle and unexpected, and the saving grace is basically that
> empty cpumasks are really the exception to begin with. They basically
> don't happen in normal situations.

Yes and no. We get more code which uses cpumasks to store state, just like
I did, and while a lot of the cpumask functions just work as expected a
subset including for_each_cpu does not. That's confusing at best and I
rather avoid the hard to debug issues on UP, which probably gets less
testing anyway.

Thanks,

tglx