[Patch v5 1/2] arm: kernel: Add SMC structure parameter

[Andy Gross]

This patch adds a quirk parameter to the arm_smccc_smc call.  The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.  The current arm_smccc_smc is renamed and macros are used
instead to specify the standard arm_smccc_smc or the arm_smccc_smc_quirk
function.

This patch and partial implementation was suggested by Will Deacon.

Signed-off-by: Andy Gross 
Reviewed-by: Will Deacon 
---
 arch/arm/kernel/armksyms.c  |  2 +-
 arch/arm/kernel/smccc-call.S|  7 ---
 arch/arm64/kernel/arm64ksyms.c  |  2 +-
 arch/arm64/kernel/asm-offsets.c |  7 +--
 arch/arm64/kernel/smccc-call.S  |  7 ---
 include/linux/arm-smccc.h   | 27 +++
 6 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 7e45f69..c2a8e79 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -178,6 +178,6 @@
 #endif
 
 #ifdef CONFIG_HAVE_ARM_SMCCC
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
 EXPORT_SYMBOL(arm_smccc_hvc);
 #endif
diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 2e48b67..eb666d7 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -46,11 +46,12 @@ UNWIND( .fnend)
 /*
  * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC SMCCC_SMC
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
 
 /*
  * void smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 78f3680..43370a0 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -73,5 +73,5 @@
 #endif
 
/* arm-smccc */
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
 EXPORT_SYMBOL(arm_smccc_hvc);
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index bc049af..b3bb7ef 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -143,8 +143,11 @@ int main(void)
   DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, 
system_regs));
   DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, 
callee_saved_regs));
 #endif
-  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
-  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, 
a0));
+  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, 
a2));
+  DEFINE(ARM_SMCCC_QUIRK_ID_OFFS,  offsetof(struct arm_smccc_quirk, id));
+  DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_quirk, 
state));
+
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..6290696 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -27,11 +27,12 @@
 /*
  * void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC   smc
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
 
 /*
  * void arm_smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index b5abfda..ab937db 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -72,19 +72,34 @@ struct arm_smccc_res {
 };
 
 /**
- * arm_smccc_smc() - make SMC calls
+ * struct arm_smccc_quirk - Contains quirk information
+ * @id: quirk identification
+ * @state: quirk specific information
+ * @a6: Qualcomm quirk entry for returning post-smc call contents of a6
+ */
+struct arm_smccc_quirk {
+   int id;
+   union {
+   unsigned long a6;
+   } state;
+};
+
+/**
+ * __arm_smccc_smc() - make SMC calls
  * @a0-a7: arguments passed in registers 0 to 7
  * @res: result values from registers 0 to 3
+ * @quirk: points to an arm_smccc_quirk, or NULL when no quirks are required.
  *
  * This function is used to make SMC calls following SMC Calling Convention.
  * The content of the supplied param are copied to registers 0 to 

[Patch v5 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Andy Gross]

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.

On Qualcomm ARM64 platforms, the SMC call can return before it has
completed.  If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.

The quirk stores off the session ID from the interrupted call in the
quirk structure so that it can be used by the caller.

This patch folds in a fix given by Sricharan R:
https://lkml.org/lkml/2016/9/28/272

This patch also folds in a fix for the hvc call, provided by James Morse
and Yuri Norov.

Signed-off-by: Andy Gross 
Reviewed-by: Will Deacon 
---
 arch/arm64/kernel/smccc-call.S | 15 ---
 drivers/firmware/qcom_scm-64.c | 13 ++---
 include/linux/arm-smccc.h  | 11 ---
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 6290696..ac33dc2 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -12,15 +12,24 @@
  *
  */
 #include 
+#include 
 #include 
 
-   .macro SMCCC instr
+   .macro SMCCC instr, maybe_quirk = 0
.cfi_startproc
\instr  #0
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
-   ret
+   .if \maybe_quirk != 0
+   ldr x4, [sp, #8]
+   cbz x4, 1f /* no quirk structure */
+   ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
+   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
+   b.ne1f
+   str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+   .endif
+1: ret
.cfi_endproc
.endm
 
@@ -31,7 +40,7 @@
  *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(__arm_smccc_smc)
-   SMCCC   smc
+   SMCCC   smc, 1
 ENDPROC(__arm_smccc_smc)
 
 /*
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..1e2e519 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -91,6 +91,7 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, u32 
cmd_id,
dma_addr_t args_phys = 0;
void *args_virt = NULL;
size_t alloc_len;
+   struct arm_smccc_quirk quirk = {.id = ARM_SMCCC_QUIRK_QCOM_A6};
 
if (unlikely(arglen > N_REGISTER_ARGS)) {
alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
@@ -131,10 +132,16 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, 
u32 cmd_id,
 qcom_smccc_convention,
 ARM_SMCCC_OWNER_SIP, fn_id);
 
+   quirk.state.a6 = 0;
+
do {
-   arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res);
+   arm_smccc_smc_quirk(cmd, desc->arginfo, desc->args[0],
+ desc->args[1], desc->args[2], x5,
+ quirk.state.a6, 0, res, );
+
+   if (res->a0 == QCOM_SCM_INTERRUPTED)
+   cmd = res->a0;
+
} while (res->a0 == QCOM_SCM_INTERRUPTED);
 
mutex_unlock(_scm_lock);
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index ab937db..6cd101e 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -14,9 +14,6 @@
 #ifndef __LINUX_ARM_SMCCC_H
 #define __LINUX_ARM_SMCCC_H
 
-#include 
-#include 
-
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -60,6 +57,13 @@
 #define ARM_SMCCC_OWNER_TRUSTED_OS 50
 #define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
 
+#define ARM_SMCCC_QUIRK_NONE   0
+#define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 */
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
 /**
  * struct arm_smccc_res - Result from SMC/HVC call
  * @a0-a3 result values from registers 0 to 3
@@ -120,4 +124,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, unsigned 
long a1,
 
 #define arm_smccc_smc_quirk(...) __arm_smccc_smc(__VA_ARGS__)
 
+#endif /*__ASSEMBLY__*/
 #endif /*__LINUX_ARM_SMCCC_H*/
-- 
1.9.1

[no subject]

[Andy Gross]

Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks

At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls.  As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.

The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms.  When this occurs, the
call must be restarted using information that was passed back during
the original smc call.

The first patch in this series adds a quirk structure and also adds a
quirk parameter to arm_smccc_smc calls.  I added macros to allow users
to choose the API they need.  This keeps all of the current users who
do not need quirks from having to change anything.

The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.

The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7

Changes from v4:
  - Fix issue with hvc calls.

Changes from v3:
  - Fix documentation

Changes from v2:
  - Use variadic macros

Changes from v1:
  - Add macros to handle both use cases per review comments

Andy Gross (2):
  arm: kernel: Add SMC structure parameter
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm/kernel/armksyms.c  |  2 +-
 arch/arm/kernel/smccc-call.S|  7 ---
 arch/arm64/kernel/arm64ksyms.c  |  2 +-
 arch/arm64/kernel/asm-offsets.c |  7 +--
 arch/arm64/kernel/smccc-call.S  | 22 --
 drivers/firmware/qcom_scm-64.c  | 13 ++---
 include/linux/arm-smccc.h   | 38 +++---
 7 files changed, 68 insertions(+), 23 deletions(-)

-- 
1.9.1

[Patch v5 1/2] arm: kernel: Add SMC structure parameter

[Andy Gross]

This patch adds a quirk parameter to the arm_smccc_smc call.  The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.  The current arm_smccc_smc is renamed and macros are used
instead to specify the standard arm_smccc_smc or the arm_smccc_smc_quirk
function.

This patch and partial implementation was suggested by Will Deacon.

Signed-off-by: Andy Gross 
Reviewed-by: Will Deacon 
---
 arch/arm/kernel/armksyms.c  |  2 +-
 arch/arm/kernel/smccc-call.S|  7 ---
 arch/arm64/kernel/arm64ksyms.c  |  2 +-
 arch/arm64/kernel/asm-offsets.c |  7 +--
 arch/arm64/kernel/smccc-call.S  |  7 ---
 include/linux/arm-smccc.h   | 27 +++
 6 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 7e45f69..c2a8e79 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -178,6 +178,6 @@
 #endif
 
 #ifdef CONFIG_HAVE_ARM_SMCCC
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
 EXPORT_SYMBOL(arm_smccc_hvc);
 #endif
diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 2e48b67..eb666d7 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -46,11 +46,12 @@ UNWIND( .fnend)
 /*
  * void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC SMCCC_SMC
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
 
 /*
  * void smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 78f3680..43370a0 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -73,5 +73,5 @@
 #endif
 
/* arm-smccc */
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
 EXPORT_SYMBOL(arm_smccc_hvc);
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index bc049af..b3bb7ef 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -143,8 +143,11 @@ int main(void)
   DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, 
system_regs));
   DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, 
callee_saved_regs));
 #endif
-  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, a0));
-  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, a2));
+  DEFINE(ARM_SMCCC_RES_X0_OFFS,offsetof(struct arm_smccc_res, 
a0));
+  DEFINE(ARM_SMCCC_RES_X2_OFFS,offsetof(struct arm_smccc_res, 
a2));
+  DEFINE(ARM_SMCCC_QUIRK_ID_OFFS,  offsetof(struct arm_smccc_quirk, id));
+  DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS,   offsetof(struct arm_smccc_quirk, 
state));
+
   BLANK();
   DEFINE(HIBERN_PBE_ORIG,  offsetof(struct pbe, orig_address));
   DEFINE(HIBERN_PBE_ADDR,  offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..6290696 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -27,11 +27,12 @@
 /*
  * void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
  *   unsigned long a3, unsigned long a4, unsigned long a5,
- *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ *   unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ *   struct arm_smccc_quirk *quirk)
  */
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC   smc
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
 
 /*
  * void arm_smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index b5abfda..ab937db 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -72,19 +72,34 @@ struct arm_smccc_res {
 };
 
 /**
- * arm_smccc_smc() - make SMC calls
+ * struct arm_smccc_quirk - Contains quirk information
+ * @id: quirk identification
+ * @state: quirk specific information
+ * @a6: Qualcomm quirk entry for returning post-smc call contents of a6
+ */
+struct arm_smccc_quirk {
+   int id;
+   union {
+   unsigned long a6;
+   } state;
+};
+
+/**
+ * __arm_smccc_smc() - make SMC calls
  * @a0-a7: arguments passed in registers 0 to 7
  * @res: result values from registers 0 to 3
+ * @quirk: points to an arm_smccc_quirk, or NULL when no quirks are required.
  *
  * This function is used to make SMC calls following SMC Calling Convention.
  * The content of the supplied param are copied to registers 0 to 7 prior
  * to the SMC instruction. The 

[Patch v5 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Andy Gross]

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.

On Qualcomm ARM64 platforms, the SMC call can return before it has
completed.  If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.

The quirk stores off the session ID from the interrupted call in the
quirk structure so that it can be used by the caller.

This patch folds in a fix given by Sricharan R:
https://lkml.org/lkml/2016/9/28/272

This patch also folds in a fix for the hvc call, provided by James Morse
and Yuri Norov.

Signed-off-by: Andy Gross 
Reviewed-by: Will Deacon 
---
 arch/arm64/kernel/smccc-call.S | 15 ---
 drivers/firmware/qcom_scm-64.c | 13 ++---
 include/linux/arm-smccc.h  | 11 ---
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 6290696..ac33dc2 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -12,15 +12,24 @@
  *
  */
 #include 
+#include 
 #include 
 
-   .macro SMCCC instr
+   .macro SMCCC instr, maybe_quirk = 0
.cfi_startproc
\instr  #0
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
-   ret
+   .if \maybe_quirk != 0
+   ldr x4, [sp, #8]
+   cbz x4, 1f /* no quirk structure */
+   ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
+   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
+   b.ne1f
+   str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+   .endif
+1: ret
.cfi_endproc
.endm
 
@@ -31,7 +40,7 @@
  *   struct arm_smccc_quirk *quirk)
  */
 ENTRY(__arm_smccc_smc)
-   SMCCC   smc
+   SMCCC   smc, 1
 ENDPROC(__arm_smccc_smc)
 
 /*
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..1e2e519 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -91,6 +91,7 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, u32 
cmd_id,
dma_addr_t args_phys = 0;
void *args_virt = NULL;
size_t alloc_len;
+   struct arm_smccc_quirk quirk = {.id = ARM_SMCCC_QUIRK_QCOM_A6};
 
if (unlikely(arglen > N_REGISTER_ARGS)) {
alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
@@ -131,10 +132,16 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, 
u32 cmd_id,
 qcom_smccc_convention,
 ARM_SMCCC_OWNER_SIP, fn_id);
 
+   quirk.state.a6 = 0;
+
do {
-   arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res);
+   arm_smccc_smc_quirk(cmd, desc->arginfo, desc->args[0],
+ desc->args[1], desc->args[2], x5,
+ quirk.state.a6, 0, res, );
+
+   if (res->a0 == QCOM_SCM_INTERRUPTED)
+   cmd = res->a0;
+
} while (res->a0 == QCOM_SCM_INTERRUPTED);
 
mutex_unlock(_scm_lock);
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index ab937db..6cd101e 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -14,9 +14,6 @@
 #ifndef __LINUX_ARM_SMCCC_H
 #define __LINUX_ARM_SMCCC_H
 
-#include 
-#include 
-
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -60,6 +57,13 @@
 #define ARM_SMCCC_OWNER_TRUSTED_OS 50
 #define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
 
+#define ARM_SMCCC_QUIRK_NONE   0
+#define ARM_SMCCC_QUIRK_QCOM_A61 /* Save/restore register a6 */
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
 /**
  * struct arm_smccc_res - Result from SMC/HVC call
  * @a0-a3 result values from registers 0 to 3
@@ -120,4 +124,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, unsigned 
long a1,
 
 #define arm_smccc_smc_quirk(...) __arm_smccc_smc(__VA_ARGS__)
 
+#endif /*__ASSEMBLY__*/
 #endif /*__LINUX_ARM_SMCCC_H*/
-- 
1.9.1

[no subject]

[Andy Gross]

Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks

At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls.  As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.

The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms.  When this occurs, the
call must be restarted using information that was passed back during
the original smc call.

The first patch in this series adds a quirk structure and also adds a
quirk parameter to arm_smccc_smc calls.  I added macros to allow users
to choose the API they need.  This keeps all of the current users who
do not need quirks from having to change anything.

The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.

The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7

Changes from v4:
  - Fix issue with hvc calls.

Changes from v3:
  - Fix documentation

Changes from v2:
  - Use variadic macros

Changes from v1:
  - Add macros to handle both use cases per review comments

Andy Gross (2):
  arm: kernel: Add SMC structure parameter
  firmware: qcom: scm: Fix interrupted SCM calls

 arch/arm/kernel/armksyms.c  |  2 +-
 arch/arm/kernel/smccc-call.S|  7 ---
 arch/arm64/kernel/arm64ksyms.c  |  2 +-
 arch/arm64/kernel/asm-offsets.c |  7 +--
 arch/arm64/kernel/smccc-call.S  | 22 --
 drivers/firmware/qcom_scm-64.c  | 13 ++---
 include/linux/arm-smccc.h   | 38 +++---
 7 files changed, 68 insertions(+), 23 deletions(-)

-- 
1.9.1

[PATCH v5 0/2] PM / devfreq: Change the device name on sysfs entry

[Chanwoo Choi]

These patches change the name of sysfs entry for devfreq/devfreq-event device
as following:
- old
For devfreq, /sys/class/devfreq/[non-standard device name]
For devfreq-event, /sys/class/devfreq-event/event.(X)

- new
For devfreq, /sys/class/devfreq/devfreq(X)
For devfreq-event, /sys/class/devfreq-event/event(X)

Changes from v4:
- Applied the patch1/2 on v4 series.
- Add new ABI document for devfreq-event class.

Changes from v3:
(https://lkml.org/lkml/2017/1/16/254)
- Patch3 initializes the init value of 'event_no' in order to remove
  the unneeded operation (-1) when calling the atomic_inc_return(_no).
- Patch4 uses the integer type for unique number of devfreq device.

Changes from v2:
(https://lkml.org/lkml/2016/12/28/102)
- On v2 patchset, patch1/2/3/5 were merged on devfreq git repo.
- Remain the warning message for exynos-ppmu.c
  when failed to get the clock of ppmu.
- Rebase these patches on devfreq git repo[1].

Changes from v1:
- Rebase these patches on v4.10-rc1.
- Include the separate patch[2] in these patches.

Depends on:
- These patches are based on patch[1].
[1] https://lkml.org/lkml/2017/1/31/120

Chanwoo Choi (2):
  PM / devfreq: Simplify the sysfs name of devfreq-event device
  PM / devfreq: Modify the device name as devfreq(X) for sysfs

 .../ABI/testing/sysfs-class-devfreq-event  | 25 ++
 drivers/devfreq/devfreq-event.c|  4 ++--
 drivers/devfreq/devfreq.c  |  4 +++-
 3 files changed, 30 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq-event

-- 
1.9.1

[PATCH v5 1/2] PM / devfreq: Simplify the sysfs name of devfreq-event device

[Chanwoo Choi]

This patch just removes '.' character from the sysfs name of devfreq-event
device as following. Usually, the subsystem uses the similiar naming style
such as {framework name}{Number}.
- old : /sys/class/devfreq-event/event.(X)
- new : /sys/class/devfreq-event/event(X)

And this patch initializes the value of 'event_no' with -1
in order to remove the unneeded operation (-1) when calling
the atomic_inc_return(_no).

Lastly, this patch adds the ABI document for devfreq-event class.

Signed-off-by: Chanwoo Choi 
---
 .../ABI/testing/sysfs-class-devfreq-event  | 25 ++
 drivers/devfreq/devfreq-event.c|  4 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq-event

diff --git a/Documentation/ABI/testing/sysfs-class-devfreq-event 
b/Documentation/ABI/testing/sysfs-class-devfreq-event
new file mode 100644
index ..ceaf0f686d4a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-devfreq-event
@@ -0,0 +1,25 @@
+What:  /sys/class/devfreq-event/event(x)/
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   Provide a place in sysfs for the devfreq-event objects.
+   This allows accessing various devfreq-event specific variables.
+   The name of devfreq-event object denoted as 'event(x)' which
+   includes the unique number of 'x' for each devfreq-event object.
+
+What:  /sys/class/devfreq-event/event(x)/name
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   The /sys/class/devfreq-event/event(x)/name attribute contains
+   the name of the devfreq-event object. This attribute is
+   read-only.
+
+What:  /sys/class/devfreq-event/event(x)/enable_count
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   The /sys/class/devfreq-event/event(x)/enable_count attribute
+   contains the reference count to enable the devfreq-event
+   object. If the device is enabled, the value of attribute is
+   greater than zero.
diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
index 9aea2c7ecbe6..8648b32ebc89 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -306,7 +306,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
device *dev,
struct devfreq_event_desc *desc)
 {
struct devfreq_event_dev *edev;
-   static atomic_t event_no = ATOMIC_INIT(0);
+   static atomic_t event_no = ATOMIC_INIT(-1);
int ret;
 
if (!dev || !desc)
@@ -329,7 +329,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
device *dev,
edev->dev.class = devfreq_event_class;
edev->dev.release = devfreq_event_release_edev;
 
-   dev_set_name(>dev, "event.%d", atomic_inc_return(_no) - 1);
+   dev_set_name(>dev, "event%d", atomic_inc_return(_no));
ret = device_register(>dev);
if (ret < 0) {
put_device(>dev);
-- 
1.9.1

[PATCH v5 0/2] PM / devfreq: Change the device name on sysfs entry

[Chanwoo Choi]

These patches change the name of sysfs entry for devfreq/devfreq-event device
as following:
- old
For devfreq, /sys/class/devfreq/[non-standard device name]
For devfreq-event, /sys/class/devfreq-event/event.(X)

- new
For devfreq, /sys/class/devfreq/devfreq(X)
For devfreq-event, /sys/class/devfreq-event/event(X)

Changes from v4:
- Applied the patch1/2 on v4 series.
- Add new ABI document for devfreq-event class.

Changes from v3:
(https://lkml.org/lkml/2017/1/16/254)
- Patch3 initializes the init value of 'event_no' in order to remove
  the unneeded operation (-1) when calling the atomic_inc_return(_no).
- Patch4 uses the integer type for unique number of devfreq device.

Changes from v2:
(https://lkml.org/lkml/2016/12/28/102)
- On v2 patchset, patch1/2/3/5 were merged on devfreq git repo.
- Remain the warning message for exynos-ppmu.c
  when failed to get the clock of ppmu.
- Rebase these patches on devfreq git repo[1].

Changes from v1:
- Rebase these patches on v4.10-rc1.
- Include the separate patch[2] in these patches.

Depends on:
- These patches are based on patch[1].
[1] https://lkml.org/lkml/2017/1/31/120

Chanwoo Choi (2):
  PM / devfreq: Simplify the sysfs name of devfreq-event device
  PM / devfreq: Modify the device name as devfreq(X) for sysfs

 .../ABI/testing/sysfs-class-devfreq-event  | 25 ++
 drivers/devfreq/devfreq-event.c|  4 ++--
 drivers/devfreq/devfreq.c  |  4 +++-
 3 files changed, 30 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq-event

-- 
1.9.1

[PATCH v5 1/2] PM / devfreq: Simplify the sysfs name of devfreq-event device

[Chanwoo Choi]

This patch just removes '.' character from the sysfs name of devfreq-event
device as following. Usually, the subsystem uses the similiar naming style
such as {framework name}{Number}.
- old : /sys/class/devfreq-event/event.(X)
- new : /sys/class/devfreq-event/event(X)

And this patch initializes the value of 'event_no' with -1
in order to remove the unneeded operation (-1) when calling
the atomic_inc_return(_no).

Lastly, this patch adds the ABI document for devfreq-event class.

Signed-off-by: Chanwoo Choi 
---
 .../ABI/testing/sysfs-class-devfreq-event  | 25 ++
 drivers/devfreq/devfreq-event.c|  4 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-devfreq-event

diff --git a/Documentation/ABI/testing/sysfs-class-devfreq-event 
b/Documentation/ABI/testing/sysfs-class-devfreq-event
new file mode 100644
index ..ceaf0f686d4a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-devfreq-event
@@ -0,0 +1,25 @@
+What:  /sys/class/devfreq-event/event(x)/
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   Provide a place in sysfs for the devfreq-event objects.
+   This allows accessing various devfreq-event specific variables.
+   The name of devfreq-event object denoted as 'event(x)' which
+   includes the unique number of 'x' for each devfreq-event object.
+
+What:  /sys/class/devfreq-event/event(x)/name
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   The /sys/class/devfreq-event/event(x)/name attribute contains
+   the name of the devfreq-event object. This attribute is
+   read-only.
+
+What:  /sys/class/devfreq-event/event(x)/enable_count
+Date:  January 2017
+Contact:   Chanwoo Choi 
+Description:
+   The /sys/class/devfreq-event/event(x)/enable_count attribute
+   contains the reference count to enable the devfreq-event
+   object. If the device is enabled, the value of attribute is
+   greater than zero.
diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
index 9aea2c7ecbe6..8648b32ebc89 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -306,7 +306,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
device *dev,
struct devfreq_event_desc *desc)
 {
struct devfreq_event_dev *edev;
-   static atomic_t event_no = ATOMIC_INIT(0);
+   static atomic_t event_no = ATOMIC_INIT(-1);
int ret;
 
if (!dev || !desc)
@@ -329,7 +329,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
device *dev,
edev->dev.class = devfreq_event_class;
edev->dev.release = devfreq_event_release_edev;
 
-   dev_set_name(>dev, "event.%d", atomic_inc_return(_no) - 1);
+   dev_set_name(>dev, "event%d", atomic_inc_return(_no));
ret = device_register(>dev);
if (ret < 0) {
put_device(>dev);
-- 
1.9.1

[PATCH v5 2/2] PM / devfreq: Modify the device name as devfreq(X) for sysfs

[Chanwoo Choi]

This patch modifies the device name as devfreq(X) for sysfs by using the 
'devfreq'
prefix word instead of separate device name. On user-space aspect, user would
find the some devfreq drvier with 'devfreq(X)' pattern. So, this patch modify 
the
device name as following:
- /sys/class/devfreq/[non-standard device name] -> /sys/class/devfreq/devfreq(X)

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 2e685164c549..4aa72b5ed660 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -519,6 +519,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
 {
struct devfreq *devfreq;
struct devfreq_governor *governor;
+   static atomic_t devfreq_no = ATOMIC_INIT(-1);
int err = 0;
 
if (!dev || !profile || !governor_name) {
@@ -560,7 +561,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_lock(>lock);
}
 
-   dev_set_name(>dev, "%s", dev_name(dev));
+   dev_set_name(>dev, "devfreq%d",
+   atomic_inc_return(_no));
err = device_register(>dev);
if (err) {
mutex_unlock(>lock);
-- 
1.9.1

[PATCH v5 2/2] PM / devfreq: Modify the device name as devfreq(X) for sysfs

[Chanwoo Choi]

This patch modifies the device name as devfreq(X) for sysfs by using the 
'devfreq'
prefix word instead of separate device name. On user-space aspect, user would
find the some devfreq drvier with 'devfreq(X)' pattern. So, this patch modify 
the
device name as following:
- /sys/class/devfreq/[non-standard device name] -> /sys/class/devfreq/devfreq(X)

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 2e685164c549..4aa72b5ed660 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -519,6 +519,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
 {
struct devfreq *devfreq;
struct devfreq_governor *governor;
+   static atomic_t devfreq_no = ATOMIC_INIT(-1);
int err = 0;
 
if (!dev || !profile || !governor_name) {
@@ -560,7 +561,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_lock(>lock);
}
 
-   dev_set_name(>dev, "%s", dev_name(dev));
+   dev_set_name(>dev, "devfreq%d",
+   atomic_inc_return(_no));
err = device_register(>dev);
if (err) {
mutex_unlock(>lock);
-- 
1.9.1

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

[Naveen N. Rao]

On 2017/01/31 07:43AM, Michael Ellerman wrote:
> Anju T Sudhakar  writes:
> 
> > Detour buffer contains instructions to create an in memory pt_regs.
> > After the execution of the pre-handler, a call is made for instruction 
> > emulation.
> > The NIP is determined in advanced through dummy instruction emulation and a 
> > branch
> > instruction is created to the NIP at the end of the trampoline.
> >
> > Instruction slot for detour buffer is allocated from the reserved area.
> > For the time being, 64KB is reserved in memory for this purpose.
> >
> > Instructions which can be emulated using analyse_instr() are suppliants
> > for optimization. Before optimization ensure that the address range
> > between the detour buffer allocated and the instruction being probed
> > is within ± 32MB.
> >
> > Signed-off-by: Anju T Sudhakar 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  .../features/debug/optprobes/arch-support.txt  |   2 +-
> >  arch/powerpc/Kconfig   |   1 +
> >  arch/powerpc/include/asm/kprobes.h |  24 +-
> >  arch/powerpc/include/asm/sstep.h   |   1 +
> >  arch/powerpc/kernel/Makefile   |   1 +
> >  arch/powerpc/kernel/optprobes.c| 331 
> > +
> >  arch/powerpc/kernel/optprobes_head.S   | 135 +
> >  arch/powerpc/lib/sstep.c   |  21 ++
> >  8 files changed, 514 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/powerpc/kernel/optprobes.c
> >  create mode 100644 arch/powerpc/kernel/optprobes_head.S
> 
> This breaks the pseries_defconfig (at least) build:
> 
>   In file included from ../include/linux/kprobes.h:45:0,
>from ../arch/powerpc/kernel/optprobes.c:12:
>   ../arch/powerpc/kernel/optprobes.c: In function 
> ‘arch_prepare_optimized_kprobe’:
>   ../arch/powerpc/include/asm/kprobes.h:79:16: error: ‘MODULE_NAME_LEN’ 
> undeclared (first use in this function)
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>   ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:16: note: each undeclared 
> identifier is reported only once for each function it appears in
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>   ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:82:14: error: assignment discards 
> ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> if ((modsym = strchr(name, ':')) != NULL) {   \
> ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:7: error: unused variable 
> ‘dot_name’ [-Werror=unused-variable]
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>  ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:82:14: error: assignment discards 
> ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> if ((modsym = strchr(name, ':')) != NULL) {   \
> ^
>   ../arch/powerpc/kernel/optprobes.c:231:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("emulate_step", emulate_step_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:7: error: unused variable 
> ‘dot_name’ [-Werror=unused-variable]
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>  ^
>   ../arch/powerpc/kernel/optprobes.c:231:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("emulate_step", emulate_step_addr);
> ^~
>   cc1: all warnings being treated as errors
>   make[2]: *** [arch/powerpc/kernel/optprobes.o] Error 1
>   make[2]: *** Waiting for unfinished jobs
>   make[1]: *** [arch/powerpc/kernel] Error 2
>   make[1]: *** Waiting for unfinished jobs
>   make: *** [sub-make] Error 2
> 
> 
> This may not be your bug, but your patch exposes it unfortunately.

Sorry for the trouble, we should have caught this.

- Naveen

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

[Naveen N. Rao]

On 2017/01/31 07:43AM, Michael Ellerman wrote:
> Anju T Sudhakar  writes:
> 
> > Detour buffer contains instructions to create an in memory pt_regs.
> > After the execution of the pre-handler, a call is made for instruction 
> > emulation.
> > The NIP is determined in advanced through dummy instruction emulation and a 
> > branch
> > instruction is created to the NIP at the end of the trampoline.
> >
> > Instruction slot for detour buffer is allocated from the reserved area.
> > For the time being, 64KB is reserved in memory for this purpose.
> >
> > Instructions which can be emulated using analyse_instr() are suppliants
> > for optimization. Before optimization ensure that the address range
> > between the detour buffer allocated and the instruction being probed
> > is within ± 32MB.
> >
> > Signed-off-by: Anju T Sudhakar 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  .../features/debug/optprobes/arch-support.txt  |   2 +-
> >  arch/powerpc/Kconfig   |   1 +
> >  arch/powerpc/include/asm/kprobes.h |  24 +-
> >  arch/powerpc/include/asm/sstep.h   |   1 +
> >  arch/powerpc/kernel/Makefile   |   1 +
> >  arch/powerpc/kernel/optprobes.c| 331 
> > +
> >  arch/powerpc/kernel/optprobes_head.S   | 135 +
> >  arch/powerpc/lib/sstep.c   |  21 ++
> >  8 files changed, 514 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/powerpc/kernel/optprobes.c
> >  create mode 100644 arch/powerpc/kernel/optprobes_head.S
> 
> This breaks the pseries_defconfig (at least) build:
> 
>   In file included from ../include/linux/kprobes.h:45:0,
>from ../arch/powerpc/kernel/optprobes.c:12:
>   ../arch/powerpc/kernel/optprobes.c: In function 
> ‘arch_prepare_optimized_kprobe’:
>   ../arch/powerpc/include/asm/kprobes.h:79:16: error: ‘MODULE_NAME_LEN’ 
> undeclared (first use in this function)
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>   ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:16: note: each undeclared 
> identifier is reported only once for each function it appears in
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>   ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:82:14: error: assignment discards 
> ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> if ((modsym = strchr(name, ':')) != NULL) {   \
> ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:7: error: unused variable 
> ‘dot_name’ [-Werror=unused-variable]
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>  ^
>   ../arch/powerpc/kernel/optprobes.c:230:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("optimized_callback", op_callback_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:82:14: error: assignment discards 
> ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> if ((modsym = strchr(name, ':')) != NULL) {   \
> ^
>   ../arch/powerpc/kernel/optprobes.c:231:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("emulate_step", emulate_step_addr);
> ^~
>   ../arch/powerpc/include/asm/kprobes.h:79:7: error: unused variable 
> ‘dot_name’ [-Werror=unused-variable]
> char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];  \
>  ^
>   ../arch/powerpc/kernel/optprobes.c:231:2: note: in expansion of macro 
> ‘kprobe_lookup_name’
> kprobe_lookup_name("emulate_step", emulate_step_addr);
> ^~
>   cc1: all warnings being treated as errors
>   make[2]: *** [arch/powerpc/kernel/optprobes.o] Error 1
>   make[2]: *** Waiting for unfinished jobs
>   make[1]: *** [arch/powerpc/kernel] Error 2
>   make[1]: *** Waiting for unfinished jobs
>   make: *** [sub-make] Error 2
> 
> 
> This may not be your bug, but your patch exposes it unfortunately.

Sorry for the trouble, we should have caught this.

- Naveen

[RFC PATCH v2] Input: gpio_keys - add dt abs/rel button support

[Hans Holmberg]

This change adds support for specifying device tree buttons emitting
abs/rel events.

ABS events were previously supported, but only via platform data, so add
the missing device tree property to allow axis values to be emitted with
abs/rel events.

Also emit 0 on button releases for REL and ABS keys. This is a must-have
for supporting digital joysticks, and aligns the driver whith
gpio-keys-polled.

Finally, report min/max values for abs axes to the input framework.

Signed-off-by: Hans Holmberg 
---

RFC because it alters the behaviour of abs-buttons making them
un-sticky, reporting 0 on button releases - just like gpio-keys-polled.

FWIW, i've looked through the in-tree board files and not found a
single occurence of abs gpio-buttons.

Changes since v1:
* Corrected cc list - now the mailing lists are looped in.

 .../devicetree/bindings/input/gpio-keys.txt| 50 +-
 drivers/input/keyboard/gpio_keys.c | 29 +++--
 2 files changed, 75 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
b/Documentation/devicetree/bindings/input/gpio-keys.txt
index a949404..1b53eed 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
@@ -22,6 +22,13 @@ both at the same time. Specifying both properties is allowed.
 Optional subnode-properties:
- linux,input-type: Specify event type this button/key generates.
  If not specified defaults to <1> == EV_KEY.
+   - linux,input-value: If linux,input-type is EV_ABS or EV_REL then this
+ value is sent for events this button generates when pressed.
+ EV_ABS/EV_REL axis will generate an event with a value of 0 when
+ all buttons with linux,input-type == type and linux,code == axis
+ are released. This value is interpreted as a signed 32 bit value,
+ e.g. to make a button generate a value of -1 use:
+ linux,input-value = <0x>; /* -1 */
- debounce-interval: Debouncing interval time in milliseconds.
  If not specified defaults to 5.
- wakeup-source: Boolean, button can wake-up the system.
@@ -47,4 +54,45 @@ Example nodes:
linux,code = <108>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
};
-   ...
+   ...
+
+   gpio-joystick: {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   up {
+   gpios = < 26 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x>;
+   };
+
+   down {
+   gpios = < 13 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <1>;
+   };
+
+   left {
+   gpios = < 6 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x>;
+   };
+
+   right {
+   gpios = < 5 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x1>;
+   };
+
+   trigger_button {
+   gpios = < 12 1>;
+   linux,code = ;
+   };
+   };
+   ...
diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 9c92cdf..06d6902 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -370,9 +370,11 @@ static void gpio_keys_gpio_report_event(struct 
gpio_button_data *bdata)
return;
}
 
-   if (type == EV_ABS) {
+   if (type == EV_ABS || type == EV_REL) {
if (state)
input_event(input, type, button->code, button->value);
+   else
+   input_event(input, type, button->code, 0);
} else {
input_event(input, type, *bdata->code, state);
}
@@ -584,6 +586,14 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
*bdata->code = button->code;
input_set_capability(input, button->type ?: EV_KEY, *bdata->code);
 
+   if (button->type == EV_ABS) {
+   if (input_abs_get_max(input, button->code) < button->value)
+   input_abs_set_max(input, button->code, button->value);
+
+ 

[RFC PATCH v2] Input: gpio_keys - add dt abs/rel button support

[Hans Holmberg]

This change adds support for specifying device tree buttons emitting
abs/rel events.

ABS events were previously supported, but only via platform data, so add
the missing device tree property to allow axis values to be emitted with
abs/rel events.

Also emit 0 on button releases for REL and ABS keys. This is a must-have
for supporting digital joysticks, and aligns the driver whith
gpio-keys-polled.

Finally, report min/max values for abs axes to the input framework.

Signed-off-by: Hans Holmberg 
---

RFC because it alters the behaviour of abs-buttons making them
un-sticky, reporting 0 on button releases - just like gpio-keys-polled.

FWIW, i've looked through the in-tree board files and not found a
single occurence of abs gpio-buttons.

Changes since v1:
* Corrected cc list - now the mailing lists are looped in.

 .../devicetree/bindings/input/gpio-keys.txt| 50 +-
 drivers/input/keyboard/gpio_keys.c | 29 +++--
 2 files changed, 75 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
b/Documentation/devicetree/bindings/input/gpio-keys.txt
index a949404..1b53eed 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
@@ -22,6 +22,13 @@ both at the same time. Specifying both properties is allowed.
 Optional subnode-properties:
- linux,input-type: Specify event type this button/key generates.
  If not specified defaults to <1> == EV_KEY.
+   - linux,input-value: If linux,input-type is EV_ABS or EV_REL then this
+ value is sent for events this button generates when pressed.
+ EV_ABS/EV_REL axis will generate an event with a value of 0 when
+ all buttons with linux,input-type == type and linux,code == axis
+ are released. This value is interpreted as a signed 32 bit value,
+ e.g. to make a button generate a value of -1 use:
+ linux,input-value = <0x>; /* -1 */
- debounce-interval: Debouncing interval time in milliseconds.
  If not specified defaults to 5.
- wakeup-source: Boolean, button can wake-up the system.
@@ -47,4 +54,45 @@ Example nodes:
linux,code = <108>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
};
-   ...
+   ...
+
+   gpio-joystick: {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   up {
+   gpios = < 26 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x>;
+   };
+
+   down {
+   gpios = < 13 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <1>;
+   };
+
+   left {
+   gpios = < 6 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x>;
+   };
+
+   right {
+   gpios = < 5 1>;
+   linux,input-type = ;
+   linux,code = ;
+   linux,input-value = <0x1>;
+   };
+
+   trigger_button {
+   gpios = < 12 1>;
+   linux,code = ;
+   };
+   };
+   ...
diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 9c92cdf..06d6902 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -370,9 +370,11 @@ static void gpio_keys_gpio_report_event(struct 
gpio_button_data *bdata)
return;
}
 
-   if (type == EV_ABS) {
+   if (type == EV_ABS || type == EV_REL) {
if (state)
input_event(input, type, button->code, button->value);
+   else
+   input_event(input, type, button->code, 0);
} else {
input_event(input, type, *bdata->code, state);
}
@@ -584,6 +586,14 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
*bdata->code = button->code;
input_set_capability(input, button->type ?: EV_KEY, *bdata->code);
 
+   if (button->type == EV_ABS) {
+   if (input_abs_get_max(input, button->code) < button->value)
+   input_abs_set_max(input, button->code, button->value);
+
+   if 

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

[vinayak menon]

On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim  wrote:
> On Fri, Jan 27, 2017 at 01:43:36PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>> in reclaimed pages being greater than the scanned pages
>> in shrink_node. When this is passed to vmpressure, the
>> unsigned arithmetic results in the pressure value to be
>> huge, thus resulting in a critical event being sent to
>> root cgroup. While this can be fixed by underflow checks
>> in vmpressure, adding reclaimed slab without a corresponding
>> increment of nr_scanned results in incorrect vmpressure
>> reporting. So do not consider reclaimed slab pages in
>> vmpressure calculation.
>
> I belive we could enhance the description better.
>
> problem
>
> VM include nr_reclaimed of slab but not nr_scanned so pressure
> calculation can be underflow.
>
> solution
>
> do not consider reclaimed slab pages for vmpressure
>
> why
>
> Freeing a page by slab shrinking depends on each slab's object
> population so the cost model(i.e., scan:free) is not fair with
> LRU pages. Also, every shrinker doesn't account reclaimed pages.
> Lastly, this regression happens since 6b4f7799c6a5
>
Done. Sending an updated one.

>>
>> Signed-off-by: Vinayak Menon 
>> ---
>>  mm/vmscan.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 947ab6f..37c4486 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -2594,16 +2594,16 @@ static bool shrink_node(pg_data_t *pgdat, struct 
>> scan_control *sc)
>>   sc->nr_scanned - nr_scanned,
>>   node_lru_pages);
>>
>> - if (reclaim_state) {
>> - sc->nr_reclaimed += reclaim_state->reclaimed_slab;
>> - reclaim_state->reclaimed_slab = 0;
>> - }
>> -
>>   /* Record the subtree's reclaim efficiency */
>>   vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
>>  sc->nr_scanned - nr_scanned,
>>  sc->nr_reclaimed - nr_reclaimed);
>>
>
> Please add comment about "vmpressure excludes reclaimed pages via slab
> because blah blah blah" so upcoming patches doesn't make mistake again.
>
> Thanks!
>
Done. Thanks Minchan.

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

[vinayak menon]

On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim  wrote:
> On Fri, Jan 27, 2017 at 01:43:36PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>> in reclaimed pages being greater than the scanned pages
>> in shrink_node. When this is passed to vmpressure, the
>> unsigned arithmetic results in the pressure value to be
>> huge, thus resulting in a critical event being sent to
>> root cgroup. While this can be fixed by underflow checks
>> in vmpressure, adding reclaimed slab without a corresponding
>> increment of nr_scanned results in incorrect vmpressure
>> reporting. So do not consider reclaimed slab pages in
>> vmpressure calculation.
>
> I belive we could enhance the description better.
>
> problem
>
> VM include nr_reclaimed of slab but not nr_scanned so pressure
> calculation can be underflow.
>
> solution
>
> do not consider reclaimed slab pages for vmpressure
>
> why
>
> Freeing a page by slab shrinking depends on each slab's object
> population so the cost model(i.e., scan:free) is not fair with
> LRU pages. Also, every shrinker doesn't account reclaimed pages.
> Lastly, this regression happens since 6b4f7799c6a5
>
Done. Sending an updated one.

>>
>> Signed-off-by: Vinayak Menon 
>> ---
>>  mm/vmscan.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 947ab6f..37c4486 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -2594,16 +2594,16 @@ static bool shrink_node(pg_data_t *pgdat, struct 
>> scan_control *sc)
>>   sc->nr_scanned - nr_scanned,
>>   node_lru_pages);
>>
>> - if (reclaim_state) {
>> - sc->nr_reclaimed += reclaim_state->reclaimed_slab;
>> - reclaim_state->reclaimed_slab = 0;
>> - }
>> -
>>   /* Record the subtree's reclaim efficiency */
>>   vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
>>  sc->nr_scanned - nr_scanned,
>>  sc->nr_reclaimed - nr_reclaimed);
>>
>
> Please add comment about "vmpressure excludes reclaimed pages via slab
> because blah blah blah" so upcoming patches doesn't make mistake again.
>
> Thanks!
>
Done. Thanks Minchan.

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> > * Mike Galbraith  wrote:
> 
> > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > > an early boot brick problem.
> > 
> > That's bad - could you perhaps try to bisect it? All recently queued up 
> > patches 
> > that could cause such problems should be readily bisectable.
> 
> Yeah, I'll give it a go as soon as I get some other stuff done.

Please double check whether -tip f18a8a0143b1 works for you (latestest -tip 
freshly pushed out), it might be that my bogus conflict resolution of a 
x86/microcode conflict is what caused your boot problems?

Thanks,

Ingo

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> > * Mike Galbraith  wrote:
> 
> > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > > an early boot brick problem.
> > 
> > That's bad - could you perhaps try to bisect it? All recently queued up 
> > patches 
> > that could cause such problems should be readily bisectable.
> 
> Yeah, I'll give it a go as soon as I get some other stuff done.

Please double check whether -tip f18a8a0143b1 works for you (latestest -tip 
freshly pushed out), it might be that my bogus conflict resolution of a 
x86/microcode conflict is what caused your boot problems?

Thanks,

Ingo

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

[Ingo Molnar]

(Cc:-ed Mike as this could explain his early boot crash/hang?
Mike: please try -tip f18a8a0143b1 that I just pushed out. )

* Borislav Petkov  wrote:

> On Mon, Jan 30, 2017 at 09:46:32AM +0100, Ingo Molnar wrote:
> > Ok, I have applied this to tip:x86/urgent.
> > 
> > Note that there are new conflicts with your pending work in 
> > tip:x86/microcode, and 
> > I fixed them up in:
> > 
> >   7c5b4112040e Merge branch 'x86/urgent' into x86/microcode, to resolve 
> > conflicts
> > 
> > Could you please double-check my conflict resolution?
> 
> Almost, this part is wrong:
> 
> - arch/x86/kernel/cpu/microcode/amd.c 
> -
> index 7889ae492af0,079e81733a58..73082365ed1c
> @@@ -268,20 -316,43 +268,20 @@@ void __load_ucode_amd(unsigned int cpui
>   use_pa  = false;
>   }
>   
> - if (!get_builtin_microcode(, x86_family(cpuid_1_eax)))
>  -if (!get_builtin_microcode(, family))
> ++if (!get_builtin_microcode(, x86_family(cpuid_1_eax)) && 
> !initrd_gone)
>   cp = find_microcode_in_initrd(path, use_pa);
> 
> --
> 
> Btw, I did experiment with the merging because I knew it'll cause
> trouble due to the urgent fix and here's what I did:
> 
> You're merging tip/x86/urgent into tip/x86/microcode so I checked out
> the microcode branch and did:
> 
> $ git checkout -b tip-microcode tip/x86/microcode
> $ git merge -s recursive -X ours tip/x86/urgent
> 
> This way I'm favouring our changes in the conflicting files. It merges
> cleanly and the resulting diff is below.

Nice - I've updated the branch with your resolution. Could you please 
double-check the double checked resolution?

> The logic behind it is is that tip/x86/microcode does away with a bunch
> of code and the urgent change touches some of that code but that's only
> for 4.10.
> 
> It goes away in 4.11 and that's why we should prefer "ours" as the merge
> option.
> 
>[ Btw, I'll send a patch for 4.11 later to make initrd_gone static as
>  it is going to be used only in microcode/core.c after the cleanup. ]
> 
> However, I still haven't figured out how to say "prefer ours but only
> for specific files or subtree" because the diff has that hunk in
> arch/x86/kernel/fpu/core.c too which should definitely not be "ours" as
> it is a fix and there the urgent version should be the one going in.
> 
> Hmmm.

So the diff between your resolution and mine is attached below - now fpu/core.c 
changes, so I'm not sure why fpu/core.c is in your diff?

Thanks,

Ingo

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 73082365ed1c..7889ae492af0 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -268,7 +268,7 @@ void __load_ucode_amd(unsigned int cpuid_1_eax, struct 
cpio_data *ret)
use_pa  = false;
}
 
-   if (!get_builtin_microcode(, x86_family(cpuid_1_eax)) && 
!initrd_gone)
+   if (!get_builtin_microcode(, x86_family(cpuid_1_eax)))
cp = find_microcode_in_initrd(path, use_pa);
 
/* Needed in load_microcode_amd() */
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index e51eeaed8016..b4a4cd39b358 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -230,7 +230,7 @@ static int __init save_microcode_in_initrd(void)
break;
case X86_VENDOR_AMD:
if (c->x86 >= 0x10)
-   ret = save_microcode_in_initrd_amd(cpuid_eax(1));
+   return save_microcode_in_initrd_amd(cpuid_eax(1));
break;
default:
break;

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

[Ingo Molnar]

(Cc:-ed Mike as this could explain his early boot crash/hang?
Mike: please try -tip f18a8a0143b1 that I just pushed out. )

* Borislav Petkov  wrote:

> On Mon, Jan 30, 2017 at 09:46:32AM +0100, Ingo Molnar wrote:
> > Ok, I have applied this to tip:x86/urgent.
> > 
> > Note that there are new conflicts with your pending work in 
> > tip:x86/microcode, and 
> > I fixed them up in:
> > 
> >   7c5b4112040e Merge branch 'x86/urgent' into x86/microcode, to resolve 
> > conflicts
> > 
> > Could you please double-check my conflict resolution?
> 
> Almost, this part is wrong:
> 
> - arch/x86/kernel/cpu/microcode/amd.c 
> -
> index 7889ae492af0,079e81733a58..73082365ed1c
> @@@ -268,20 -316,43 +268,20 @@@ void __load_ucode_amd(unsigned int cpui
>   use_pa  = false;
>   }
>   
> - if (!get_builtin_microcode(, x86_family(cpuid_1_eax)))
>  -if (!get_builtin_microcode(, family))
> ++if (!get_builtin_microcode(, x86_family(cpuid_1_eax)) && 
> !initrd_gone)
>   cp = find_microcode_in_initrd(path, use_pa);
> 
> --
> 
> Btw, I did experiment with the merging because I knew it'll cause
> trouble due to the urgent fix and here's what I did:
> 
> You're merging tip/x86/urgent into tip/x86/microcode so I checked out
> the microcode branch and did:
> 
> $ git checkout -b tip-microcode tip/x86/microcode
> $ git merge -s recursive -X ours tip/x86/urgent
> 
> This way I'm favouring our changes in the conflicting files. It merges
> cleanly and the resulting diff is below.

Nice - I've updated the branch with your resolution. Could you please 
double-check the double checked resolution?

> The logic behind it is is that tip/x86/microcode does away with a bunch
> of code and the urgent change touches some of that code but that's only
> for 4.10.
> 
> It goes away in 4.11 and that's why we should prefer "ours" as the merge
> option.
> 
>[ Btw, I'll send a patch for 4.11 later to make initrd_gone static as
>  it is going to be used only in microcode/core.c after the cleanup. ]
> 
> However, I still haven't figured out how to say "prefer ours but only
> for specific files or subtree" because the diff has that hunk in
> arch/x86/kernel/fpu/core.c too which should definitely not be "ours" as
> it is a fix and there the urgent version should be the one going in.
> 
> Hmmm.

So the diff between your resolution and mine is attached below - now fpu/core.c 
changes, so I'm not sure why fpu/core.c is in your diff?

Thanks,

Ingo

diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
b/arch/x86/kernel/cpu/microcode/amd.c
index 73082365ed1c..7889ae492af0 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -268,7 +268,7 @@ void __load_ucode_amd(unsigned int cpuid_1_eax, struct 
cpio_data *ret)
use_pa  = false;
}
 
-   if (!get_builtin_microcode(, x86_family(cpuid_1_eax)) && 
!initrd_gone)
+   if (!get_builtin_microcode(, x86_family(cpuid_1_eax)))
cp = find_microcode_in_initrd(path, use_pa);
 
/* Needed in load_microcode_amd() */
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index e51eeaed8016..b4a4cd39b358 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -230,7 +230,7 @@ static int __init save_microcode_in_initrd(void)
break;
case X86_VENDOR_AMD:
if (c->x86 >= 0x10)
-   ret = save_microcode_in_initrd_amd(cpuid_eax(1));
+   return save_microcode_in_initrd_amd(cpuid_eax(1));
break;
default:
break;

[PATCH v3] DM: dm-inplace-compress: inplace compressed DM target

[Ram Pai]

This  patch   provides   a   generic device-mapper   compression  device.
Originally written by Shaohua Li.
https://www.redhat.com/archives/dm-devel/2013-December/msg00143.html

I have optimized and hardened the code.

Testing:
---
This compression block device  is  tested in the following scenarios
a) backing a ext4 filesystem 
b) backing swap
Its stress tested on PPC64 and x86 system.

Version v1:
Comments from Alasdair have been incorporated.
https://www.redhat.com/archives/dm-devel/2013-December/msg00144.html

Version v2:
All patches are merged into a single patch.
Major code re-arrangement.
Data and metablocks allocated based on the length of the device
map rather than the size of the backing device.
Size   of   each entry   in  the bitmap array is explicitly set
 to 32bits.
Attempt  to  reuse  the  provided  bio  buffer  space   instead
 of allocating a new one.

Version v3:
Fixed  sector  alignment  bugs  exposed  while   testing on x86.
Explicitly set the maximum request size  to 128K.  Without which
range  locking  failed,  causing  I/Os  to  stamp   each  other.
Fixed an occasional data corruption  caused by wrong size of the
compression buffer.
Added  a   parameter   while  creation  of  the   block  device, 
to  not  sleep   during  memory  allocations. This can be useful
if the device is used as a swap device.

Your comments to improve the code is very much appreciated.

Ram Pai (1):
  From: Shaohua Li 

 .../device-mapper/dm-inplace-compress.txt  |  155 ++
 drivers/md/Kconfig |6 +
 drivers/md/Makefile|2 +
 drivers/md/dm-inplace-compress.c   | 2214 
 drivers/md/dm-inplace-compress.h   |  187 ++
 5 files changed, 2564 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-inplace-compress.txt
 create mode 100644 drivers/md/dm-inplace-compress.c
 create mode 100644 drivers/md/dm-inplace-compress.h

-- 
1.8.3.1

[PATCH v3 1/1] DM: inplace compressed DM target

[Ram Pai]

This is a simple DM target supporting inplace compression. Its best
suited for SSD. The underlying disk must support 512B sector size.
The target only supports 4k sector size.

Disk layout:
|super|...meta...|..data...|

Store unit is 4k (a block). Super is 1 block, which stores meta  and
data size and compression algorithm. Meta is a bitmap. For each data
 block, there are 5 bits meta.

Data:

Data of   a block is compressed. Compressed  data  is round up to 512B,
which is the payload. In disk, payload is  stored at  the beginning of
logical sector  of the block. Let's look  at an example.  Say we store
data to block A, which  is in sector  B(A*8), its orginal  size is 4k,
compressed size is  1500.Compressed data (CD)  will  use three
sectors (512B). The three  sectors  are the  payload. Payload  will be
stored at sector B.

---
... | CD1 | CD2 | CD3 |   |   |   |   || ...
---
^B^B+1  ^B+2  ^B+7 ^B+8

For this block, we will not use sector B+3 to B+7 (a hole). We use four
meta  bits  to  present payload  size. The compressed size (1500) isn't
stored in meta directly. Instead, we  store  it  at  the last 32bits of
payload. In this  example, we store it at the  end  of  sector  B+2. If
compressed size + sizeof(32bits)  crosses a   sector, payload size will
increase one sector.  If payload  uses 8 sectors, we store uncompressed
data directly.

If IO size is bigger than one block, we can store the data as an extent.
Data of the  whole extent will compressed and stored in the similar way
like above.  The first  block of the extent is the head, all others are
the tail.  If extent is 1 block,  the  block  is head. We have 1 bit of
meta to present if a  block  is  head  or  tail. If 4 meta bits of head
block can't  store  extent payload size, we will borrow tail block meta
bits to  store  payload  size.   Max  allowd extent size is 128k, so we
don't compress/decompress too big size data.

Meta:
Modifying   data   will modify meta too. Meta will be written(flush) to
disk   depending   on   meta   write   policy. We support writeback and
writethrough mode.  In  writeback mode, meta will be written to disk in
an interval or a  FLUSH  request.  In  writethrough mode, data and meta
data will be written to disk together.

Advantages:

1. Simple. Since  we  store  compressed  data  in-place,  we don't need
   complicated disk data management.
2. Efficient. For  each  4k, we only need 5 bits meta. 1T data will use
less than 200M meta, so we  can  load  all meta into memory. And actual
compression size is in payload. So   if  IO doesn't need RMW and we use
writeback meta flush, we don't  need  extra IO for meta.

Disadvantages:

1. hole. Since we   store  compressed data in-place, there are a lot of
   holes (in above  example,  B+3 - B+7) Hole can impact IO, because we
   can't do IO merge.

2. 1:1 size. Compression  doesn't  change disk  size. If disk is 1T, we
   can only store 1T data even we do compression.

But this is for SSD only. Generally SSD firmware has a FTL layer to map
disk  sectors  to flash nand. High end SSD firmware has filesystem-like
FTL.

1. hole. Disk has a lot of holes, but SSD FTL   can   still  store data
   contiguous in nand. Even if we can't do IO   merge in  OS layer, SSD
   firmware can do it.

2. 1:1 size. On one side, we write compressed data to SSD, which means
   less  data is  written to SSD. This will be very helpful to improve
   SSD garbage collection, and  so write speed and life cycle. So even
   this is a problem, the target  is still helpful. On the other side,
   advanced SSD FTL can easily do thin provision. For example, if nand
   is   1T   and   we   let   SSD   report   it   as   2T,   and   use
   the  SSD  as  compressed target. In such SSD, we don't have the 1:1
   size issue.

So even if   SSD   FTL   cannot   map   non-contiguous disk sectors to
contiguous nand, the compression target can still function well.

Signed-off-by: Shaohua Li 
Signed-off-by: Ram Pai  
---
 .../device-mapper/dm-inplace-compress.txt  |  155 ++
 drivers/md/Kconfig |6 +
 drivers/md/Makefile|2 +
 drivers/md/dm-inplace-compress.c   | 2214 
 drivers/md/dm-inplace-compress.h   |  187 ++
 5 files changed, 2564 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-inplace-compress.txt
 create mode 100644 drivers/md/dm-inplace-compress.c
 create mode 100644 drivers/md/dm-inplace-compress.h

diff --git a/Documentation/device-mapper/dm-inplace-compress.txt 
b/Documentation/device-mapper/dm-inplace-compress.txt
new file mode 100644
index 000..1835369
--- /dev/null
+++ b/Documentation/device-mapper/dm-inplace-compress.txt
@@ -0,0 +1,155 @@
+Device-Mapper's "inplace-compress" target provides 

[PATCH v3] DM: dm-inplace-compress: inplace compressed DM target

[Ram Pai]

This  patch   provides   a   generic device-mapper   compression  device.
Originally written by Shaohua Li.
https://www.redhat.com/archives/dm-devel/2013-December/msg00143.html

I have optimized and hardened the code.

Testing:
---
This compression block device  is  tested in the following scenarios
a) backing a ext4 filesystem 
b) backing swap
Its stress tested on PPC64 and x86 system.

Version v1:
Comments from Alasdair have been incorporated.
https://www.redhat.com/archives/dm-devel/2013-December/msg00144.html

Version v2:
All patches are merged into a single patch.
Major code re-arrangement.
Data and metablocks allocated based on the length of the device
map rather than the size of the backing device.
Size   of   each entry   in  the bitmap array is explicitly set
 to 32bits.
Attempt  to  reuse  the  provided  bio  buffer  space   instead
 of allocating a new one.

Version v3:
Fixed  sector  alignment  bugs  exposed  while   testing on x86.
Explicitly set the maximum request size  to 128K.  Without which
range  locking  failed,  causing  I/Os  to  stamp   each  other.
Fixed an occasional data corruption  caused by wrong size of the
compression buffer.
Added  a   parameter   while  creation  of  the   block  device, 
to  not  sleep   during  memory  allocations. This can be useful
if the device is used as a swap device.

Your comments to improve the code is very much appreciated.

Ram Pai (1):
  From: Shaohua Li 

 .../device-mapper/dm-inplace-compress.txt  |  155 ++
 drivers/md/Kconfig |6 +
 drivers/md/Makefile|2 +
 drivers/md/dm-inplace-compress.c   | 2214 
 drivers/md/dm-inplace-compress.h   |  187 ++
 5 files changed, 2564 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-inplace-compress.txt
 create mode 100644 drivers/md/dm-inplace-compress.c
 create mode 100644 drivers/md/dm-inplace-compress.h

-- 
1.8.3.1

[PATCH v3 1/1] DM: inplace compressed DM target

[Ram Pai]

This is a simple DM target supporting inplace compression. Its best
suited for SSD. The underlying disk must support 512B sector size.
The target only supports 4k sector size.

Disk layout:
|super|...meta...|..data...|

Store unit is 4k (a block). Super is 1 block, which stores meta  and
data size and compression algorithm. Meta is a bitmap. For each data
 block, there are 5 bits meta.

Data:

Data of   a block is compressed. Compressed  data  is round up to 512B,
which is the payload. In disk, payload is  stored at  the beginning of
logical sector  of the block. Let's look  at an example.  Say we store
data to block A, which  is in sector  B(A*8), its orginal  size is 4k,
compressed size is  1500.Compressed data (CD)  will  use three
sectors (512B). The three  sectors  are the  payload. Payload  will be
stored at sector B.

---
... | CD1 | CD2 | CD3 |   |   |   |   || ...
---
^B^B+1  ^B+2  ^B+7 ^B+8

For this block, we will not use sector B+3 to B+7 (a hole). We use four
meta  bits  to  present payload  size. The compressed size (1500) isn't
stored in meta directly. Instead, we  store  it  at  the last 32bits of
payload. In this  example, we store it at the  end  of  sector  B+2. If
compressed size + sizeof(32bits)  crosses a   sector, payload size will
increase one sector.  If payload  uses 8 sectors, we store uncompressed
data directly.

If IO size is bigger than one block, we can store the data as an extent.
Data of the  whole extent will compressed and stored in the similar way
like above.  The first  block of the extent is the head, all others are
the tail.  If extent is 1 block,  the  block  is head. We have 1 bit of
meta to present if a  block  is  head  or  tail. If 4 meta bits of head
block can't  store  extent payload size, we will borrow tail block meta
bits to  store  payload  size.   Max  allowd extent size is 128k, so we
don't compress/decompress too big size data.

Meta:
Modifying   data   will modify meta too. Meta will be written(flush) to
disk   depending   on   meta   write   policy. We support writeback and
writethrough mode.  In  writeback mode, meta will be written to disk in
an interval or a  FLUSH  request.  In  writethrough mode, data and meta
data will be written to disk together.

Advantages:

1. Simple. Since  we  store  compressed  data  in-place,  we don't need
   complicated disk data management.
2. Efficient. For  each  4k, we only need 5 bits meta. 1T data will use
less than 200M meta, so we  can  load  all meta into memory. And actual
compression size is in payload. So   if  IO doesn't need RMW and we use
writeback meta flush, we don't  need  extra IO for meta.

Disadvantages:

1. hole. Since we   store  compressed data in-place, there are a lot of
   holes (in above  example,  B+3 - B+7) Hole can impact IO, because we
   can't do IO merge.

2. 1:1 size. Compression  doesn't  change disk  size. If disk is 1T, we
   can only store 1T data even we do compression.

But this is for SSD only. Generally SSD firmware has a FTL layer to map
disk  sectors  to flash nand. High end SSD firmware has filesystem-like
FTL.

1. hole. Disk has a lot of holes, but SSD FTL   can   still  store data
   contiguous in nand. Even if we can't do IO   merge in  OS layer, SSD
   firmware can do it.

2. 1:1 size. On one side, we write compressed data to SSD, which means
   less  data is  written to SSD. This will be very helpful to improve
   SSD garbage collection, and  so write speed and life cycle. So even
   this is a problem, the target  is still helpful. On the other side,
   advanced SSD FTL can easily do thin provision. For example, if nand
   is   1T   and   we   let   SSD   report   it   as   2T,   and   use
   the  SSD  as  compressed target. In such SSD, we don't have the 1:1
   size issue.

So even if   SSD   FTL   cannot   map   non-contiguous disk sectors to
contiguous nand, the compression target can still function well.

Signed-off-by: Shaohua Li 
Signed-off-by: Ram Pai  
---
 .../device-mapper/dm-inplace-compress.txt  |  155 ++
 drivers/md/Kconfig |6 +
 drivers/md/Makefile|2 +
 drivers/md/dm-inplace-compress.c   | 2214 
 drivers/md/dm-inplace-compress.h   |  187 ++
 5 files changed, 2564 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-inplace-compress.txt
 create mode 100644 drivers/md/dm-inplace-compress.c
 create mode 100644 drivers/md/dm-inplace-compress.h

diff --git a/Documentation/device-mapper/dm-inplace-compress.txt 
b/Documentation/device-mapper/dm-inplace-compress.txt
new file mode 100644
index 000..1835369
--- /dev/null
+++ b/Documentation/device-mapper/dm-inplace-compress.txt
@@ -0,0 +1,155 @@
+Device-Mapper's "inplace-compress" target provides inplace compression of block
+devices using 

Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

[Peter Rosin]

On 2017-01-30 18:20, Rob Herring wrote:
> On Sat, Jan 28, 2017 at 4:42 PM, Peter Rosin  wrote:
>> On 2017-01-27 20:39, Rob Herring wrote:
>>> On Wed, Jan 18, 2017 at 04:57:10PM +0100, Peter Rosin wrote:
 Describe how a generic multiplexer controller is used to mux an i2c bus.

 Acked-by: Jonathan Cameron 
 Signed-off-by: Peter Rosin 
 ---
  .../devicetree/bindings/i2c/i2c-mux-simple.txt | 81 
 ++
  1 file changed, 81 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt

 diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt 
 b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
 new file mode 100644
 index ..253d5027843b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
 @@ -0,0 +1,81 @@
 +Simple I2C Bus Mux
 +
 +This binding describes an I2C bus multiplexer that uses a mux controller
 +from the mux subsystem to route the I2C signals.
 +
 +  .-.  .-.
 +  | dev |  | dev |
 +..'-'  '-'
 +| SoC|   ||
 +||  .+'
 +|   .--. |  .--+child bus A, on MUX value set to 0
 +|   | I2C  |-|--| Mux  |
 +|   '--' |  '--+---+child bus B, on MUX value set to 1
 +|   .--. | |'--++.
 +|   | MUX- | | |   |||
 +|   | Ctrl |-|-+.-.  .-.  .-.
 +|   '--' |  | dev |  | dev |  | dev |
 +''  '-'  '-'  '-'
 +
 +Required properties:
 +- compatible: i2c-mux-simple,mux-locked or i2c-mux-simple,parent-locked
>>>
>>> Not a fan of using "simple" nor the ','. Perhaps lock type should be
>>> separate property.
>>
>> How about just i2c-mux for the compatible? Because i2c-mux-mux (which
>> follows the naming of previous i2c muxes) looks really stupid. Or
>> perhaps i2c-mux-generic?
> 
> I like "generic" only slightly more than "simple". :)
> 
> If the mux is gpio controlled, then it should still be called
> i2c-gpio-mux. Let's not invent brand new bindings when current ones
> are easily extended. We already have pretty generic names here, let's
> not make them more generic.

Ahh, but the whole point of this new driver is that it does not know
if the mux is gpio controlled, if it is controlled by an adg792 chip
or whatever might appear down the line. So, I think i2c-mux-gpio (and
i2c-gpio-mux) is actively wrong.

This new driver is in fact an i2c-mux driver that (in this aspect) is more
generic than any of the existing i2c-mux drivers, hence my suggestion.

If you see this new driver as something that is superseding the existing
i2c-mux-gpio driver, I'm sad to inform you that the code is not simply
not there. i2c-mux-gpio has acpi support and users may provide platform
data from code. The existing i2c-mux-gpio driver also has the below
mentioned locking heuristic. Adding all those things to the new driver
would make it big and unwieldy and having even more unwanted tentacles
into other subsystems. And why should it be only i2c-mux-gpio that is
merged into this new i2c-mux driver? Why not implement a mux-pinctrl
driver for the new mux subsustem and then merge i2c-mux-pinctrl as well?
I say no, that way lies madness.

>>
>> I'm also happy to have the lock type as a separate property. One lock
>> type, e.g. parent-locked, could be the default and adding a 'mux-locked'
>> property could change that. Would that be ok?
> 
> I prefer this. Then existing bindings can use it.
> 
>> Or should it be a requirement that one of 'mux-locked'/'parent-locked'
>> is always present?
> 
> I would make it boolean and make not present be the more common case.
> Not present could also mean determined via other means as you have
> today with existing bindings. Maybe then you need both properties.

Ok. Lets define that every type of i2c-mux have a default locking.
If no property is found that overrides this default, a heuristic may
be applied that is only allowed to very defensively use non-default
locking (like the current heuristics in i2c-mux-gpio/i2c-mux-pinctrl
attempt to do, they only adjust the locking for impossible cases that
would invariably lead to a deadlock with the default locking). Then,
there should never exist a need to enforce the default locking with
a property.

And given that no current i2c-mux that is mux-locked by default even
have the ability to be parent-locked, there is (currently) no need
for more than a bool 'mux-locked' property.

>>> I'm not sure I get the mux vs. parent locked fully. How do I determine
>>> what type I 

Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

[Peter Rosin]

On 2017-01-30 18:20, Rob Herring wrote:
> On Sat, Jan 28, 2017 at 4:42 PM, Peter Rosin  wrote:
>> On 2017-01-27 20:39, Rob Herring wrote:
>>> On Wed, Jan 18, 2017 at 04:57:10PM +0100, Peter Rosin wrote:
 Describe how a generic multiplexer controller is used to mux an i2c bus.

 Acked-by: Jonathan Cameron 
 Signed-off-by: Peter Rosin 
 ---
  .../devicetree/bindings/i2c/i2c-mux-simple.txt | 81 
 ++
  1 file changed, 81 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt

 diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt 
 b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
 new file mode 100644
 index ..253d5027843b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
 @@ -0,0 +1,81 @@
 +Simple I2C Bus Mux
 +
 +This binding describes an I2C bus multiplexer that uses a mux controller
 +from the mux subsystem to route the I2C signals.
 +
 +  .-.  .-.
 +  | dev |  | dev |
 +..'-'  '-'
 +| SoC|   ||
 +||  .+'
 +|   .--. |  .--+child bus A, on MUX value set to 0
 +|   | I2C  |-|--| Mux  |
 +|   '--' |  '--+---+child bus B, on MUX value set to 1
 +|   .--. | |'--++.
 +|   | MUX- | | |   |||
 +|   | Ctrl |-|-+.-.  .-.  .-.
 +|   '--' |  | dev |  | dev |  | dev |
 +''  '-'  '-'  '-'
 +
 +Required properties:
 +- compatible: i2c-mux-simple,mux-locked or i2c-mux-simple,parent-locked
>>>
>>> Not a fan of using "simple" nor the ','. Perhaps lock type should be
>>> separate property.
>>
>> How about just i2c-mux for the compatible? Because i2c-mux-mux (which
>> follows the naming of previous i2c muxes) looks really stupid. Or
>> perhaps i2c-mux-generic?
> 
> I like "generic" only slightly more than "simple". :)
> 
> If the mux is gpio controlled, then it should still be called
> i2c-gpio-mux. Let's not invent brand new bindings when current ones
> are easily extended. We already have pretty generic names here, let's
> not make them more generic.

Ahh, but the whole point of this new driver is that it does not know
if the mux is gpio controlled, if it is controlled by an adg792 chip
or whatever might appear down the line. So, I think i2c-mux-gpio (and
i2c-gpio-mux) is actively wrong.

This new driver is in fact an i2c-mux driver that (in this aspect) is more
generic than any of the existing i2c-mux drivers, hence my suggestion.

If you see this new driver as something that is superseding the existing
i2c-mux-gpio driver, I'm sad to inform you that the code is not simply
not there. i2c-mux-gpio has acpi support and users may provide platform
data from code. The existing i2c-mux-gpio driver also has the below
mentioned locking heuristic. Adding all those things to the new driver
would make it big and unwieldy and having even more unwanted tentacles
into other subsystems. And why should it be only i2c-mux-gpio that is
merged into this new i2c-mux driver? Why not implement a mux-pinctrl
driver for the new mux subsustem and then merge i2c-mux-pinctrl as well?
I say no, that way lies madness.

>>
>> I'm also happy to have the lock type as a separate property. One lock
>> type, e.g. parent-locked, could be the default and adding a 'mux-locked'
>> property could change that. Would that be ok?
> 
> I prefer this. Then existing bindings can use it.
> 
>> Or should it be a requirement that one of 'mux-locked'/'parent-locked'
>> is always present?
> 
> I would make it boolean and make not present be the more common case.
> Not present could also mean determined via other means as you have
> today with existing bindings. Maybe then you need both properties.

Ok. Lets define that every type of i2c-mux have a default locking.
If no property is found that overrides this default, a heuristic may
be applied that is only allowed to very defensively use non-default
locking (like the current heuristics in i2c-mux-gpio/i2c-mux-pinctrl
attempt to do, they only adjust the locking for impossible cases that
would invariably lead to a deadlock with the default locking). Then,
there should never exist a need to enforce the default locking with
a property.

And given that no current i2c-mux that is mux-locked by default even
have the ability to be parent-locked, there is (currently) no need
for more than a bool 'mux-locked' property.

>>> I'm not sure I get the mux vs. parent locked fully. How do I determine
>>> what type I have? We already have bindings for several types of i2c

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Mike Galbraith]

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> * Mike Galbraith  wrote:

> > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > an early boot brick problem.
> 
> That's bad - could you perhaps try to bisect it? All recently queued up 
> patches 
> that could cause such problems should be readily bisectable.

Yeah, I'll give it a go as soon as I get some other stuff done.

-Mike

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Mike Galbraith]

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> * Mike Galbraith  wrote:

> > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > an early boot brick problem.
> 
> That's bad - could you perhaps try to bisect it? All recently queued up 
> patches 
> that could cause such problems should be readily bisectable.

Yeah, I'll give it a go as soon as I get some other stuff done.

-Mike

Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

[Ingo Molnar]

* Fabian Frederick  wrote:

> complementary definition to atomic_inc_not_zero() featured in
> lib/fault-inject.c
> 
> Signed-off-by: Fabian Frederick 
> ---
>  include/linux/atomic.h | 2 ++
>  lib/fault-inject.c | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index e71835b..d8e6551 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -517,6 +517,8 @@ static inline int atomic_add_unless(atomic_t *v, int a, 
> int u)
>  #define atomic_inc_not_zero(v)   atomic_add_unless((v), 1, 0)
>  #endif
>  
> +#define atomic_dec_not_zero(v)  atomic_add_unless((v), -1, 0)
> +
>  #ifndef atomic_andnot
>  static inline void atomic_andnot(int i, atomic_t *v)
>  {
> diff --git a/lib/fault-inject.c b/lib/fault-inject.c
> index 6a823a5..4ad5dcc 100644
> --- a/lib/fault-inject.c
> +++ b/lib/fault-inject.c
> @@ -52,8 +52,6 @@ static void fail_dump(struct fault_attr *attr)
>   }
>  }
>  
> -#define atomic_dec_not_zero(v)   atomic_add_unless((v), -1, 0)
> -

Why did you convert the tabs to spaces?

Thanks,

Ingo

Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

[Ingo Molnar]

* Fabian Frederick  wrote:

> complementary definition to atomic_inc_not_zero() featured in
> lib/fault-inject.c
> 
> Signed-off-by: Fabian Frederick 
> ---
>  include/linux/atomic.h | 2 ++
>  lib/fault-inject.c | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index e71835b..d8e6551 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -517,6 +517,8 @@ static inline int atomic_add_unless(atomic_t *v, int a, 
> int u)
>  #define atomic_inc_not_zero(v)   atomic_add_unless((v), 1, 0)
>  #endif
>  
> +#define atomic_dec_not_zero(v)  atomic_add_unless((v), -1, 0)
> +
>  #ifndef atomic_andnot
>  static inline void atomic_andnot(int i, atomic_t *v)
>  {
> diff --git a/lib/fault-inject.c b/lib/fault-inject.c
> index 6a823a5..4ad5dcc 100644
> --- a/lib/fault-inject.c
> +++ b/lib/fault-inject.c
> @@ -52,8 +52,6 @@ static void fail_dump(struct fault_attr *attr)
>   }
>  }
>  
> -#define atomic_dec_not_zero(v)   atomic_add_unless((v), -1, 0)
> -

Why did you convert the tabs to spaces?

Thanks,

Ingo

Re: [PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Ingo Molnar]

* Robert O'Callahan  wrote:

> pmc_reprogram_counter() always sets a sample period based on the value of
> pmc->counter. However, hsw_hw_config() rejects sample periods less than
> 2^31 - 1. So for example, a KVM guest doing
>   perf stat -e r2005101c4 sleep 0
> will count some conditional branch events, deschedule the task, reschedule
> the task, try to restore the guest PMU state for the task, in the host
> reach pmc_reprogram_counter() with nonzero pmc->count, trigger EOPNOTSUPP
> in hsw_hw_config(), print "kvm_pmu: event creation failed" in
> pmc_reprogram_counter(), and silently (from the guest's point of view) stop
> counting events.
> 
> We fix event counting by forcing attr.sample_period to always be zero for
> in_tx_cp counters. Sampling doesn't work, but it already didn't work and
> can't be fixed without major changes to the approach in hsw_hw_config().
> 
> Signed-off-by: Robert O'Callahan 
> ---
>  arch/x86/kvm/pmu.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 06ce377..af993d7 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -113,12 +113,18 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, 
> u32 type,
>   .config = config,
>   };
>  
> + attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
> +
>   if (in_tx)
>   attr.config |= HSW_IN_TX;
> - if (in_tx_cp)
> + if (in_tx_cp) {
> + /* HSW_IN_TX_CHECKPOINTED is not supported with nonzero
> +  * period. Just clear the sample period so at least
> +  * allocating the counter doesn't fail.
> +  */
> + attr.sample_period = 0;
>   attr.config |= HSW_IN_TX_CHECKPOINTED;
> -
> - attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
> + }

please use the customary (multi-line) comment style:

  /*
   * Comment .
   * .. goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

Ingo

Re: [PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Ingo Molnar]

* Robert O'Callahan  wrote:

> pmc_reprogram_counter() always sets a sample period based on the value of
> pmc->counter. However, hsw_hw_config() rejects sample periods less than
> 2^31 - 1. So for example, a KVM guest doing
>   perf stat -e r2005101c4 sleep 0
> will count some conditional branch events, deschedule the task, reschedule
> the task, try to restore the guest PMU state for the task, in the host
> reach pmc_reprogram_counter() with nonzero pmc->count, trigger EOPNOTSUPP
> in hsw_hw_config(), print "kvm_pmu: event creation failed" in
> pmc_reprogram_counter(), and silently (from the guest's point of view) stop
> counting events.
> 
> We fix event counting by forcing attr.sample_period to always be zero for
> in_tx_cp counters. Sampling doesn't work, but it already didn't work and
> can't be fixed without major changes to the approach in hsw_hw_config().
> 
> Signed-off-by: Robert O'Callahan 
> ---
>  arch/x86/kvm/pmu.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 06ce377..af993d7 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -113,12 +113,18 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, 
> u32 type,
>   .config = config,
>   };
>  
> + attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
> +
>   if (in_tx)
>   attr.config |= HSW_IN_TX;
> - if (in_tx_cp)
> + if (in_tx_cp) {
> + /* HSW_IN_TX_CHECKPOINTED is not supported with nonzero
> +  * period. Just clear the sample period so at least
> +  * allocating the counter doesn't fail.
> +  */
> + attr.sample_period = 0;
>   attr.config |= HSW_IN_TX_CHECKPOINTED;
> -
> - attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
> + }

please use the customary (multi-line) comment style:

  /*
   * Comment .
   * .. goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

Ingo

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[John Hubbard]

On 01/30/2017 05:57 PM, Dave Hansen wrote:

On 01/30/2017 05:36 PM, Anshuman Khandual wrote:

Let's say we had a CDM node with 100x more RAM than the rest of the
system and it was just as fast as the rest of the RAM.  Would we still
want it isolated like this?  Or would we want a different policy?


But then the other argument being, dont we want to keep this 100X more
memory isolated for some special purpose to be utilized by specific
applications ?


I was thinking that in this case, we wouldn't even want to bother with
having "system RAM" in the fallback lists.  A device who got its memory
usage off by 1% could start to starve the rest of the system.  A sane
policy in this case might be to isolate the "system RAM" from the device's.


I also don't like having these policies hard-coded, and your 100x example above 
helps clarify what can go wrong about it. It would be nicer if, instead, we could 
better express the "distance" between nodes (bandwidth, latency, relative to sysmem, 
perhaps), and let the NUMA system figure out the Right Thing To Do.


I realize that this is not quite possible with NUMA just yet, but I wonder if that's 
a reasonable direction to go with this?


thanks,
john h




Why do we need this hard-coded along with the cpuset stuff later in the
series.  Doesn't taking a node out of the cpuset also take it out of the
fallback lists?


There are two mutually exclusive approaches which are described in
this patch series.

(1) zonelist modification based approach
(2) cpuset restriction based approach

As mentioned in the cover letter,


Well, I'm glad you coded both of them up, but now that we have them how
to we pick which one to throw to the wolves?  Or, do we just merge both
of them and let one bitrot? ;)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[John Hubbard]

On 01/30/2017 05:57 PM, Dave Hansen wrote:

On 01/30/2017 05:36 PM, Anshuman Khandual wrote:

Let's say we had a CDM node with 100x more RAM than the rest of the
system and it was just as fast as the rest of the RAM.  Would we still
want it isolated like this?  Or would we want a different policy?


But then the other argument being, dont we want to keep this 100X more
memory isolated for some special purpose to be utilized by specific
applications ?


I was thinking that in this case, we wouldn't even want to bother with
having "system RAM" in the fallback lists.  A device who got its memory
usage off by 1% could start to starve the rest of the system.  A sane
policy in this case might be to isolate the "system RAM" from the device's.


I also don't like having these policies hard-coded, and your 100x example above 
helps clarify what can go wrong about it. It would be nicer if, instead, we could 
better express the "distance" between nodes (bandwidth, latency, relative to sysmem, 
perhaps), and let the NUMA system figure out the Right Thing To Do.


I realize that this is not quite possible with NUMA just yet, but I wonder if that's 
a reasonable direction to go with this?


thanks,
john h




Why do we need this hard-coded along with the cpuset stuff later in the
series.  Doesn't taking a node out of the cpuset also take it out of the
fallback lists?


There are two mutually exclusive approaches which are described in
this patch series.

(1) zonelist modification based approach
(2) cpuset restriction based approach

As mentioned in the cover letter,


Well, I'm glad you coded both of them up, but now that we have them how
to we pick which one to throw to the wolves?  Or, do we just merge both
of them and let one bitrot? ;)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote:
> > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote:
> > > Running Steven's hotplug stress script in tip.today.  Config is
> > > NOPREEMPT, tune for maximum build time (enterprise default-ish).
> > > 
> > > [   75.268049] x86: Booting SMP configuration:
> > > [   75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > > [   75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4
> > > [   75.294617] smpboot: Booting Node 0 Processor 4 APIC 0x1
> > > [   75.310698] smpboot: Booting Node 0 Processor 5 APIC 0x3
> > > [   75.359056] smpboot: CPU 3 is now offline
> > > [   75.415505] smpboot: CPU 4 is now offline
> > > [   75.479985] smpboot: CPU 5 is now offline
> > > [   75.550674] [ cut here ]
> > > [   75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> > > assert_clock_updated.isra.62.part.63+0x25/0x27
> > > [   75.550679] rq->clock_update_flags < RQCF_ACT_SKIP
> > 
> > The following patch queued in tip/sched/core should fix this issue:
> 
> Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> an early boot brick problem.

That's bad - could you perhaps try to bisect it? All recently queued up patches 
that could cause such problems should be readily bisectable.

The bisection might be faster if you first checked whether 5bf728f02218 works - 
if 
it does then the bug is in the patches in WIP.x86/boot or WIP.x86/fpu.

Thanks,

Ingo

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Ingo Molnar]

* Mike Galbraith  wrote:

> On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote:
> > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote:
> > > Running Steven's hotplug stress script in tip.today.  Config is
> > > NOPREEMPT, tune for maximum build time (enterprise default-ish).
> > > 
> > > [   75.268049] x86: Booting SMP configuration:
> > > [   75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > > [   75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4
> > > [   75.294617] smpboot: Booting Node 0 Processor 4 APIC 0x1
> > > [   75.310698] smpboot: Booting Node 0 Processor 5 APIC 0x3
> > > [   75.359056] smpboot: CPU 3 is now offline
> > > [   75.415505] smpboot: CPU 4 is now offline
> > > [   75.479985] smpboot: CPU 5 is now offline
> > > [   75.550674] [ cut here ]
> > > [   75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> > > assert_clock_updated.isra.62.part.63+0x25/0x27
> > > [   75.550679] rq->clock_update_flags < RQCF_ACT_SKIP
> > 
> > The following patch queued in tip/sched/core should fix this issue:
> 
> Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> an early boot brick problem.

That's bad - could you perhaps try to bisect it? All recently queued up patches 
that could cause such problems should be readily bisectable.

The bisection might be faster if you first checked whether 5bf728f02218 works - 
if 
it does then the bug is in the patches in WIP.x86/boot or WIP.x86/fpu.

Thanks,

Ingo

[PATCH v2] iio: accel: Add driver for the Analog Devices ADXL345 3-axis accelerometer

[Eva Rachel Retuya]

Add basic IIO support for the Analog Devices ADXL345 3-axis accelerometer.
The datasheet can be found here:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf

Signed-off-by: Eva Rachel Retuya 
Cc: Michael Hennerich 
Cc: Daniel Baluta 
Cc: Alison Schofield 
---
v1 Mailing list discussion:
https://marc.info/?l=linux-iio=148533644407371=2 

Changes since v1:
* Switch tag from RFC to PATCH
>From Jonathan's Review
* Kconfig: add input driver's (adxl34x) selection state as dependency.
>From Peter's Review
* Implement full-resolution mode scale.
* Add comment stating FULL_RES is up to 13-bits in resolution.
* Drop newline and le16_to_cpu usage in read_raw.
* Allow the sensor to return to standby mode if iio_device_register fails.

 drivers/iio/accel/Kconfig   |  11 +++
 drivers/iio/accel/Makefile  |   1 +
 drivers/iio/accel/adxl345.c | 194 
 3 files changed, 206 insertions(+)
 create mode 100644 drivers/iio/accel/adxl345.c

diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index ef8401a..2308bac 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -5,6 +5,17 @@
 
 menu "Accelerometers"
 
+config ADXL345
+   tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer Driver"
+   depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
+   depends on I2C
+   help
+ Say Y here if you want to build support for the Analog Devices
+ ADXL345 3-axis digital accelerometer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adxl345.
+
 config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 69fe8ed..618488d 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -3,6 +3,7 @@
 #
 
 # When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_ADXL345) += adxl345.o
 obj-$(CONFIG_BMA180) += bma180.o
 obj-$(CONFIG_BMA220) += bma220_spi.o
 obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
diff --git a/drivers/iio/accel/adxl345.c b/drivers/iio/accel/adxl345.c
new file mode 100644
index 000..c34991f
--- /dev/null
+++ b/drivers/iio/accel/adxl345.c
@@ -0,0 +1,194 @@
+/*
+ * ADXL345 3-Axis Digital Accelerometer
+ *
+ * Copyright (c) 2017 Eva Rachel Retuya 
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * IIO driver for ADXL345
+ * 7-bit I2C slave address: 0x1D (ALT ADDRESS pin tied to VDDIO) or
+ * 0x53 (ALT ADDRESS pin grounded)
+ */
+
+#include 
+#include 
+
+#include 
+
+#define ADXL345_REG_DEVID  0x00
+#define ADXL345_REG_POWER_CTL  0x2D
+#define ADXL345_REG_DATA_FORMAT0x31
+#define ADXL345_REG_DATAX0 0x32
+#define ADXL345_REG_DATAY0 0x34
+#define ADXL345_REG_DATAZ0 0x36
+
+#define ADXL345_POWER_CTL_MEASURE  BIT(3)
+#define ADXL345_POWER_CTL_STANDBY  0x00
+
+#define ADXL345_DATA_FORMAT_FULL_RES   BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_2G 0
+#define ADXL345_DATA_FORMAT_4G 1
+#define ADXL345_DATA_FORMAT_8G 2
+#define ADXL345_DATA_FORMAT_16G3
+
+#define ADXL345_DEVID  0xE5
+
+/*
+ * In full-resolution mode, scale factor is maintained at ~4 mg/LSB
+ * in all g ranges.
+ *
+ * At +/- 16g with 13-bit resolution, scale is computed as:
+ * (16 + 16) * 9.81 / (2^13 - 1) = 0.0383
+ */
+static const int adxl345_uscale = 38300;
+
+struct adxl345_data {
+   struct i2c_client *client;
+   u8 data_range;
+};
+
+#define ADXL345_CHANNEL(reg, axis) {   \
+   .type = IIO_ACCEL,  \
+   .modified = 1,  \
+   .channel2 = IIO_MOD_##axis, \
+   .address = reg, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+}
+
+static const struct iio_chan_spec adxl345_channels[] = {
+   ADXL345_CHANNEL(ADXL345_REG_DATAX0, X),
+   ADXL345_CHANNEL(ADXL345_REG_DATAY0, Y),
+   ADXL345_CHANNEL(ADXL345_REG_DATAZ0, Z),
+};
+
+static int adxl345_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int *val, int *val2, long mask)
+{
+   struct adxl345_data *data = iio_priv(indio_dev);
+   int ret;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   /*
+* 

[PATCH v2] iio: accel: Add driver for the Analog Devices ADXL345 3-axis accelerometer

[Eva Rachel Retuya]

Add basic IIO support for the Analog Devices ADXL345 3-axis accelerometer.
The datasheet can be found here:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf

Signed-off-by: Eva Rachel Retuya 
Cc: Michael Hennerich 
Cc: Daniel Baluta 
Cc: Alison Schofield 
---
v1 Mailing list discussion:
https://marc.info/?l=linux-iio=148533644407371=2 

Changes since v1:
* Switch tag from RFC to PATCH
>From Jonathan's Review
* Kconfig: add input driver's (adxl34x) selection state as dependency.
>From Peter's Review
* Implement full-resolution mode scale.
* Add comment stating FULL_RES is up to 13-bits in resolution.
* Drop newline and le16_to_cpu usage in read_raw.
* Allow the sensor to return to standby mode if iio_device_register fails.

 drivers/iio/accel/Kconfig   |  11 +++
 drivers/iio/accel/Makefile  |   1 +
 drivers/iio/accel/adxl345.c | 194 
 3 files changed, 206 insertions(+)
 create mode 100644 drivers/iio/accel/adxl345.c

diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index ef8401a..2308bac 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -5,6 +5,17 @@
 
 menu "Accelerometers"
 
+config ADXL345
+   tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer Driver"
+   depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
+   depends on I2C
+   help
+ Say Y here if you want to build support for the Analog Devices
+ ADXL345 3-axis digital accelerometer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adxl345.
+
 config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 69fe8ed..618488d 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -3,6 +3,7 @@
 #
 
 # When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_ADXL345) += adxl345.o
 obj-$(CONFIG_BMA180) += bma180.o
 obj-$(CONFIG_BMA220) += bma220_spi.o
 obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
diff --git a/drivers/iio/accel/adxl345.c b/drivers/iio/accel/adxl345.c
new file mode 100644
index 000..c34991f
--- /dev/null
+++ b/drivers/iio/accel/adxl345.c
@@ -0,0 +1,194 @@
+/*
+ * ADXL345 3-Axis Digital Accelerometer
+ *
+ * Copyright (c) 2017 Eva Rachel Retuya 
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * IIO driver for ADXL345
+ * 7-bit I2C slave address: 0x1D (ALT ADDRESS pin tied to VDDIO) or
+ * 0x53 (ALT ADDRESS pin grounded)
+ */
+
+#include 
+#include 
+
+#include 
+
+#define ADXL345_REG_DEVID  0x00
+#define ADXL345_REG_POWER_CTL  0x2D
+#define ADXL345_REG_DATA_FORMAT0x31
+#define ADXL345_REG_DATAX0 0x32
+#define ADXL345_REG_DATAY0 0x34
+#define ADXL345_REG_DATAZ0 0x36
+
+#define ADXL345_POWER_CTL_MEASURE  BIT(3)
+#define ADXL345_POWER_CTL_STANDBY  0x00
+
+#define ADXL345_DATA_FORMAT_FULL_RES   BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_2G 0
+#define ADXL345_DATA_FORMAT_4G 1
+#define ADXL345_DATA_FORMAT_8G 2
+#define ADXL345_DATA_FORMAT_16G3
+
+#define ADXL345_DEVID  0xE5
+
+/*
+ * In full-resolution mode, scale factor is maintained at ~4 mg/LSB
+ * in all g ranges.
+ *
+ * At +/- 16g with 13-bit resolution, scale is computed as:
+ * (16 + 16) * 9.81 / (2^13 - 1) = 0.0383
+ */
+static const int adxl345_uscale = 38300;
+
+struct adxl345_data {
+   struct i2c_client *client;
+   u8 data_range;
+};
+
+#define ADXL345_CHANNEL(reg, axis) {   \
+   .type = IIO_ACCEL,  \
+   .modified = 1,  \
+   .channel2 = IIO_MOD_##axis, \
+   .address = reg, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+}
+
+static const struct iio_chan_spec adxl345_channels[] = {
+   ADXL345_CHANNEL(ADXL345_REG_DATAX0, X),
+   ADXL345_CHANNEL(ADXL345_REG_DATAY0, Y),
+   ADXL345_CHANNEL(ADXL345_REG_DATAZ0, Z),
+};
+
+static int adxl345_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   int *val, int *val2, long mask)
+{
+   struct adxl345_data *data = iio_priv(indio_dev);
+   int ret;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   /*
+* Data is stored in adjacent registers:
+* ADXL345_REG_DATA(X0/Y0/Z0) contain the least significant byte

Re: [PATCH v2 2/2] iio: distance: add devantech us ranger srf04

[Peter Meerwald-Stadler]

> > +   indio_dev->num_channels = ARRAY_SIZE(srf04_chan_spec);
> > +
> > +   return iio_device_register(indio_dev);
> > +}
> > +
> > +static int srf04_remove(struct platform_device *pdev)
> > +{
> > +   struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > +
> > +   iio_device_unregister(indio_dev);
> With nothing else in here, you can use devm_iio_device_register
> and drop the remove entirely.

can devm_request_irq() and devm_iio_device_register() be used together?
if both are devm_ we cant't guarantee that iio_device_unregister() comes 
first in _remove()?

these devm_ things...

> > +
> > +   return 0;
> > +}
> > +
> > +static const struct of_device_id of_srf04_match[] = {
> > +   { .compatible = "devantech,srf04", },
> > +   {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, of_srf04_match);
> > +
> > +static struct platform_driver srf04_driver = {
> > +   .probe  = srf04_probe,
> > +   .remove = srf04_remove,
> > +   .driver = {
> > +   .name   = "srf04-gpio",
> > +   .of_match_table = of_srf04_match,
> > +   },
> > +};
> > +
> > +module_platform_driver(srf04_driver);
> > +
> > +MODULE_AUTHOR("Andreas Klinger ");
> > +MODULE_DESCRIPTION("SRF04 ultrasonic sensor for distance measuring using 
> > GPIOs");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:srf04");
> > 
> 
> --
> 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
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH v2 2/2] iio: distance: add devantech us ranger srf04

[Peter Meerwald-Stadler]

> > +   indio_dev->num_channels = ARRAY_SIZE(srf04_chan_spec);
> > +
> > +   return iio_device_register(indio_dev);
> > +}
> > +
> > +static int srf04_remove(struct platform_device *pdev)
> > +{
> > +   struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > +
> > +   iio_device_unregister(indio_dev);
> With nothing else in here, you can use devm_iio_device_register
> and drop the remove entirely.

can devm_request_irq() and devm_iio_device_register() be used together?
if both are devm_ we cant't guarantee that iio_device_unregister() comes 
first in _remove()?

these devm_ things...

> > +
> > +   return 0;
> > +}
> > +
> > +static const struct of_device_id of_srf04_match[] = {
> > +   { .compatible = "devantech,srf04", },
> > +   {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, of_srf04_match);
> > +
> > +static struct platform_driver srf04_driver = {
> > +   .probe  = srf04_probe,
> > +   .remove = srf04_remove,
> > +   .driver = {
> > +   .name   = "srf04-gpio",
> > +   .of_match_table = of_srf04_match,
> > +   },
> > +};
> > +
> > +module_platform_driver(srf04_driver);
> > +
> > +MODULE_AUTHOR("Andreas Klinger ");
> > +MODULE_DESCRIPTION("SRF04 ultrasonic sensor for distance measuring using 
> > GPIOs");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:srf04");
> > 
> 
> --
> 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
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

RE: [PATCH V2 07/12] PM / OPP: Update OPP users to put reference

[MyungJoo Ham]

> This patch updates dev_pm_opp_find_freq_*() routines to get a reference
> to the OPPs returned by them.
> 
> Also updates the users of dev_pm_opp_find_freq_*() routines to call
> dev_pm_opp_put() after they are done using the OPPs.
> 
> As it is guaranteed the that OPPs wouldn't get freed while being used,
> the RCU read side locking present with the users isn't required anymore.
> Drop it as well.
> 
> This patch also updates all users of devfreq_recommended_opp() which was
> returning an OPP received from the OPP core.
> 
> Note that some of the OPP core routines have gained
> rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
> within them.
> 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Chanwoo Choi  [Devfreq]

This patch gets a lot of fails during application.

For devfreq-side, I've got:
error: drivers/devfreq/devfreq.c: patch does not apply
error: patch failed: drivers/devfreq/exynos-bus.c:103
error: drivers/devfreq/exynos-bus.c: patch does not apply
error: patch failed: drivers/devfreq/governor_passive.c:59
error: drivers/devfreq/governor_passive.c: patch does not apply
error: patch failed: drivers/devfreq/rk3399_dmc.c:91
error: drivers/devfreq/rk3399_dmc.c: patch does not apply
error: patch failed: drivers/devfreq/tegra-devfreq.c:487
error: drivers/devfreq/tegra-devfreq.c: patch does not apply

With the condition that you are going to properly rebase the patch,
you may add "Reviewed-by" from me.
(the code itself looks fine.)

Cheers,
MyungJoo

> ---
>  arch/arm/mach-omap2/pm.c |   5 +-
>  drivers/base/power/opp/core.c| 114 
> +++
>  drivers/base/power/opp/cpu.c |  22 ++-
>  drivers/clk/tegra/clk-dfll.c |  17 ++
>  drivers/cpufreq/exynos5440-cpufreq.c |   5 +-
>  drivers/cpufreq/imx6q-cpufreq.c  |  10 +--
>  drivers/cpufreq/mt8173-cpufreq.c |   8 +--
>  drivers/cpufreq/omap-cpufreq.c   |   4 +-
>  drivers/devfreq/devfreq.c|  14 ++---
>  drivers/devfreq/exynos-bus.c |  14 ++---
>  drivers/devfreq/governor_passive.c   |   4 +-
>  drivers/devfreq/rk3399_dmc.c |  16 ++---
>  drivers/devfreq/tegra-devfreq.c  |   4 +-
>  drivers/thermal/cpu_cooling.c|  11 +---
>  drivers/thermal/devfreq_cooling.c|  15 ++---
>  15 files changed, 110 insertions(+), 153 deletions(-)
> 

Re: next-20170125 hangs on aarch64

[Andy Gross]

On Mon, Jan 30, 2017 at 06:21:25PM +0530, Yury Norov wrote:
> On Mon, Jan 30, 2017 at 11:48:01AM +, James Morse wrote:
> > Hi Yury,
> > 
> > [CC: Andy Gross]
> > 
> > On 29/01/17 12:21, Yury Norov wrote:
> > > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
> > >> Hi all,
> > >>
> > >> I pulled next-20170125 kernel, and found it hanged on boot. The exact 
> > >> reason is
> > >> panic on dereferencing of the 0xffc8 address, which is most probably 
> > >> the
> > >> attempt to dereference the ENOSYS error code as the address. 
> > >> next-20170124 works
> > >> fine, at least it boots.
> > >>
> > >> Does anyone have details on that?
> > 
> > I hit this with next-20170130 too, in /arch/arm64/kernel/smccc-call.S
> > aabde95fc543 changed the SMCCC macro to check for an optional quirk 
> > structure.
> > 
> > A previous patch provided:
> > > #define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
> > 
> > to handle the 'no quirk' case, but this missed HVC calls.
> > The following hunk fixes/hides it for me:

Wow, I botched this completely.  I missed the hvc using the same macro.  I'll
rework with the fixes below.

> 
> It works for me too, but I think "ldr x4, [sp, #8]" should
> also go under (.if \maybe_quirk != 0) condition - like below.

Yes I believe so.

> %<
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index 72ecdca929b1..9e287a7d1822 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -15,18 +15,20 @@
>  #include 
>  #include 
> 
> -   .macro SMCCC instr
> +   .macro SMCCC instr, maybe_quirk = 0
> .cfi_startproc
> \instr  #0
> ldr x4, [sp]
> stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> +   .if \maybe_quirk != 0
> ldr x4, [sp, #8]
> cbz x4, 1f /* no quirk structure */
> ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
> cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> b.ne1f
> str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
> +   .endif
>  1: ret
> .cfi_endproc
> .endm
> @@ -38,7 +40,7 @@
>   *   struct arm_smccc_quirk *quirk)
>   */
>  ENTRY(__arm_smccc_smc)
> -   SMCCC   smc
> +   SMCCC   smc, 1
>  ENDPROC(__arm_smccc_smc)
> 
>  /*
> %<
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH V2 07/12] PM / OPP: Update OPP users to put reference

[MyungJoo Ham]

> This patch updates dev_pm_opp_find_freq_*() routines to get a reference
> to the OPPs returned by them.
> 
> Also updates the users of dev_pm_opp_find_freq_*() routines to call
> dev_pm_opp_put() after they are done using the OPPs.
> 
> As it is guaranteed the that OPPs wouldn't get freed while being used,
> the RCU read side locking present with the users isn't required anymore.
> Drop it as well.
> 
> This patch also updates all users of devfreq_recommended_opp() which was
> returning an OPP received from the OPP core.
> 
> Note that some of the OPP core routines have gained
> rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
> within them.
> 
> Signed-off-by: Viresh Kumar 
> Reviewed-by: Chanwoo Choi  [Devfreq]

This patch gets a lot of fails during application.

For devfreq-side, I've got:
error: drivers/devfreq/devfreq.c: patch does not apply
error: patch failed: drivers/devfreq/exynos-bus.c:103
error: drivers/devfreq/exynos-bus.c: patch does not apply
error: patch failed: drivers/devfreq/governor_passive.c:59
error: drivers/devfreq/governor_passive.c: patch does not apply
error: patch failed: drivers/devfreq/rk3399_dmc.c:91
error: drivers/devfreq/rk3399_dmc.c: patch does not apply
error: patch failed: drivers/devfreq/tegra-devfreq.c:487
error: drivers/devfreq/tegra-devfreq.c: patch does not apply

With the condition that you are going to properly rebase the patch,
you may add "Reviewed-by" from me.
(the code itself looks fine.)

Cheers,
MyungJoo

> ---
>  arch/arm/mach-omap2/pm.c |   5 +-
>  drivers/base/power/opp/core.c| 114 
> +++
>  drivers/base/power/opp/cpu.c |  22 ++-
>  drivers/clk/tegra/clk-dfll.c |  17 ++
>  drivers/cpufreq/exynos5440-cpufreq.c |   5 +-
>  drivers/cpufreq/imx6q-cpufreq.c  |  10 +--
>  drivers/cpufreq/mt8173-cpufreq.c |   8 +--
>  drivers/cpufreq/omap-cpufreq.c   |   4 +-
>  drivers/devfreq/devfreq.c|  14 ++---
>  drivers/devfreq/exynos-bus.c |  14 ++---
>  drivers/devfreq/governor_passive.c   |   4 +-
>  drivers/devfreq/rk3399_dmc.c |  16 ++---
>  drivers/devfreq/tegra-devfreq.c  |   4 +-
>  drivers/thermal/cpu_cooling.c|  11 +---
>  drivers/thermal/devfreq_cooling.c|  15 ++---
>  15 files changed, 110 insertions(+), 153 deletions(-)
> 

Re: next-20170125 hangs on aarch64

[Andy Gross]

On Mon, Jan 30, 2017 at 06:21:25PM +0530, Yury Norov wrote:
> On Mon, Jan 30, 2017 at 11:48:01AM +, James Morse wrote:
> > Hi Yury,
> > 
> > [CC: Andy Gross]
> > 
> > On 29/01/17 12:21, Yury Norov wrote:
> > > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
> > >> Hi all,
> > >>
> > >> I pulled next-20170125 kernel, and found it hanged on boot. The exact 
> > >> reason is
> > >> panic on dereferencing of the 0xffc8 address, which is most probably 
> > >> the
> > >> attempt to dereference the ENOSYS error code as the address. 
> > >> next-20170124 works
> > >> fine, at least it boots.
> > >>
> > >> Does anyone have details on that?
> > 
> > I hit this with next-20170130 too, in /arch/arm64/kernel/smccc-call.S
> > aabde95fc543 changed the SMCCC macro to check for an optional quirk 
> > structure.
> > 
> > A previous patch provided:
> > > #define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
> > 
> > to handle the 'no quirk' case, but this missed HVC calls.
> > The following hunk fixes/hides it for me:

Wow, I botched this completely.  I missed the hvc using the same macro.  I'll
rework with the fixes below.

> 
> It works for me too, but I think "ldr x4, [sp, #8]" should
> also go under (.if \maybe_quirk != 0) condition - like below.

Yes I believe so.

> %<
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index 72ecdca929b1..9e287a7d1822 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -15,18 +15,20 @@
>  #include 
>  #include 
> 
> -   .macro SMCCC instr
> +   .macro SMCCC instr, maybe_quirk = 0
> .cfi_startproc
> \instr  #0
> ldr x4, [sp]
> stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> +   .if \maybe_quirk != 0
> ldr x4, [sp, #8]
> cbz x4, 1f /* no quirk structure */
> ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
> cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> b.ne1f
> str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
> +   .endif
>  1: ret
> .cfi_endproc
> .endm
> @@ -38,7 +40,7 @@
>   *   struct arm_smccc_quirk *quirk)
>   */
>  ENTRY(__arm_smccc_smc)
> -   SMCCC   smc
> +   SMCCC   smc, 1
>  ENDPROC(__arm_smccc_smc)
> 
>  /*
> %<
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: Tree for Jan 31

[Stephen Rothwell]

Hi all,

Changes since 20170130:

New tree: idr

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree gained a conflict against the overlayfs tree and a
build failure, so I just dropped it for today.

The v4l-dvb tree gained a build failure so I used the version from
next-20170130.

The pm tree gained a conflict against the mips tree.

The net-next tree gained conflicts against the net tree.

The block tree lost its build failure.

The pinctrl tree gained a conflict against the arm-soc tree.

Non-merge commits (relative to Linus' tree): 6025
 6756 files changed, 246406 insertions(+), 124169 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (751321b3dd50 Merge tag 'rtc-4.10-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (040587af3122 net/sched: cls_flower: Correct matching on 
ICMPv6 code)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (2b1d530cb315 MAINTAINERS: ath9k-devel is 
closed)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (672980c62c68 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (5d03a2fd2292 USB: serial: option: add 
device ID for HP lt2523 (Novatel E371))
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (

linux-next: Tree for Jan 31

[Stephen Rothwell]

Hi all,

Changes since 20170130:

New tree: idr

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree gained a conflict against the overlayfs tree and a
build failure, so I just dropped it for today.

The v4l-dvb tree gained a build failure so I used the version from
next-20170130.

The pm tree gained a conflict against the mips tree.

The net-next tree gained conflicts against the net tree.

The block tree lost its build failure.

The pinctrl tree gained a conflict against the arm-soc tree.

Non-merge commits (relative to Linus' tree): 6025
 6756 files changed, 246406 insertions(+), 124169 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (751321b3dd50 Merge tag 'rtc-4.10-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (040587af3122 net/sched: cls_flower: Correct matching on 
ICMPv6 code)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (2b1d530cb315 MAINTAINERS: ath9k-devel is 
closed)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (672980c62c68 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (5d03a2fd2292 USB: serial: option: add 
device ID for HP lt2523 (Novatel E371))
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (

Re: [PATCH v6 4/5] iio: light: lm3533-als: Support initialization from Device Tree

[Peter Meerwald-Stadler]

> Implement support for initialization of the lm3533 als driver from
> Device Tree.

minor comment below
 
> Signed-off-by: Bjorn Andersson 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Note that this patch can be merged independently of the other patches in the
> series.
> 
> Changes since v5:
> - None
> 
> Changes since v4:
> - None
> 
> Changes since v3:
> - Moved als DT parsing from mfd driver
> - Gave driver its own compatible
> 
>  drivers/iio/light/lm3533-als.c | 40 +++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index f409c2047c05..eef9f06eb0b1 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -831,6 +832,32 @@ static const struct iio_info lm3533_als_info = {
>   .read_raw   = _als_read_raw,
>  };
>  
> +static struct lm3533_als_platform_data *lm3533_als_of_parse(struct device 
> *dev)
> +{
> + struct lm3533_als_platform_data *als_pdata;
> + struct device_node *node = dev->of_node;
> + int ret;
> + u32 val;
> +
> + als_pdata = devm_kzalloc(dev, sizeof(*als_pdata), GFP_KERNEL);
> + if (!als_pdata)
> + return NULL;
> +
> + als_pdata->pwm_mode = of_property_read_bool(node, "ti,pwm-mode");
> +
> + ret = of_property_read_u32(node, "ti,als-resistance-ohm", );
> + if (ret < 0 && ret != -EINVAL) {
> + dev_err(dev, "unable to read ti,als-resistance-ohm");

\n missing

> + return NULL;
> + }
> +
> + /* Leave at high-Z, if the property was omitted or specified as 0 */
> + if (!ret && val != 0)
> + als_pdata->r_select = 20 / val;
> +
> + return als_pdata;
> +}
> +
>  static int lm3533_als_probe(struct platform_device *pdev)
>  {
>   struct lm3533 *lm3533;
> @@ -843,7 +870,11 @@ static int lm3533_als_probe(struct platform_device *pdev)
>   if (!lm3533)
>   return -EINVAL;
>  
> - pdata = pdev->dev.platform_data;
> + if (pdev->dev.of_node)
> + pdata = lm3533_als_of_parse(>dev);
> + else
> + pdata = pdev->dev.platform_data;
> +
>   if (!pdata) {
>   dev_err(>dev, "no platform data\n");
>   return -EINVAL;
> @@ -914,9 +945,16 @@ static int lm3533_als_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct of_device_id lm3533_als_of_match[] = {
> + { .compatible = "ti,lm3533-als", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_als_of_match);
> +
>  static struct platform_driver lm3533_als_driver = {
>   .driver = {
>   .name   = "lm3533-als",
> + .of_match_table = lm3533_als_of_match,
>   },
>   .probe  = lm3533_als_probe,
>   .remove = lm3533_als_remove,
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH v6 4/5] iio: light: lm3533-als: Support initialization from Device Tree

[Peter Meerwald-Stadler]

> Implement support for initialization of the lm3533 als driver from
> Device Tree.

minor comment below
 
> Signed-off-by: Bjorn Andersson 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Note that this patch can be merged independently of the other patches in the
> series.
> 
> Changes since v5:
> - None
> 
> Changes since v4:
> - None
> 
> Changes since v3:
> - Moved als DT parsing from mfd driver
> - Gave driver its own compatible
> 
>  drivers/iio/light/lm3533-als.c | 40 +++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index f409c2047c05..eef9f06eb0b1 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -831,6 +832,32 @@ static const struct iio_info lm3533_als_info = {
>   .read_raw   = _als_read_raw,
>  };
>  
> +static struct lm3533_als_platform_data *lm3533_als_of_parse(struct device 
> *dev)
> +{
> + struct lm3533_als_platform_data *als_pdata;
> + struct device_node *node = dev->of_node;
> + int ret;
> + u32 val;
> +
> + als_pdata = devm_kzalloc(dev, sizeof(*als_pdata), GFP_KERNEL);
> + if (!als_pdata)
> + return NULL;
> +
> + als_pdata->pwm_mode = of_property_read_bool(node, "ti,pwm-mode");
> +
> + ret = of_property_read_u32(node, "ti,als-resistance-ohm", );
> + if (ret < 0 && ret != -EINVAL) {
> + dev_err(dev, "unable to read ti,als-resistance-ohm");

\n missing

> + return NULL;
> + }
> +
> + /* Leave at high-Z, if the property was omitted or specified as 0 */
> + if (!ret && val != 0)
> + als_pdata->r_select = 20 / val;
> +
> + return als_pdata;
> +}
> +
>  static int lm3533_als_probe(struct platform_device *pdev)
>  {
>   struct lm3533 *lm3533;
> @@ -843,7 +870,11 @@ static int lm3533_als_probe(struct platform_device *pdev)
>   if (!lm3533)
>   return -EINVAL;
>  
> - pdata = pdev->dev.platform_data;
> + if (pdev->dev.of_node)
> + pdata = lm3533_als_of_parse(>dev);
> + else
> + pdata = pdev->dev.platform_data;
> +
>   if (!pdata) {
>   dev_err(>dev, "no platform data\n");
>   return -EINVAL;
> @@ -914,9 +945,16 @@ static int lm3533_als_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct of_device_id lm3533_als_of_match[] = {
> + { .compatible = "ti,lm3533-als", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_als_of_match);
> +
>  static struct platform_driver lm3533_als_driver = {
>   .driver = {
>   .name   = "lm3533-als",
> + .of_match_table = lm3533_als_of_match,
>   },
>   .probe  = lm3533_als_probe,
>   .remove = lm3533_als_remove,
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH] [RFC] fs: Possible filp_open race experiment

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 06:29:36AM +0100, Marek Vasut wrote:
> +CC Greg, LKML as I don't quite know where this should go.

You do know about linux-fsdevel, right?

> On 01/18/2017 12:16 AM, Marek Vasut wrote:
> > I believe there is a possible race condition when configfs attributes
> > trigger filp_open() from the kernel. I initially observed the problem
> > on Linux 4.4 when loading DT overlay , which in turn loads a driver
> > which loads firmware. After some further investigation, I came up with
> > the following minimal-ish example patch, which can trigger the same
> > behavior on Linux 4.10-rc4 (next 20170117).

What in-kernel code causes this problem?  I didn't think DT overlays
were a feature in 4.4, are you running with code that isn't in the
normal releases?

> > The core of the demo is in cfs_over_item_dtbo_write(), which just checks
> > for valid current->fs . This function is triggered by writing data into
> > configfs binary attribute, ie.:

Why are you caring about current->fs?

> > $ mkdir /sys/kernel/config/test/overlays/1/dtbo
> > $ cat file_17201_bytes_long > /sys/kernel/config/test/overlays/1/dtbo
> > 
> > I believe the 'cat' program exits quickly and thus calls fs_exit()
> > before the cfs_over_item_dtbo_write() is called.

How can exit be called before write?

> > Any attempts to
> > access FS (like ie. loading firmware from FS) from that function will
> > therefore fail (by crashing the kernel, NULL pointer dereference in
> > set_root_rcu() in fs/namei.c).
> > 
> > On the other hand, replacing 'cat' with 'dd' yields different result:
> > 
> > $ dd if=file_17201_bytes_long of=/sys/kernel/config/test/overlays/1/dtbo
> > 
> > The kernel does not crash. I believe this is because dd takes slightly
> > longer to complete, so the cfs_over_item_dtbo_write() can complete
> > before the dd process gets to calling fs_exit() and so the filesystem
> > access is still available, thus current->fs is valid.

cat and dd act differently, if you strace them, it should show the
differences, perhaps you can narrow it down there?

> > Note that when using DT overlays (whose configfs interface is not yet
> > mainline),

Ah, we can't do anything about code that is not merged, perhaps it is
just buggy? :)

> > there can easily be a device which requires a firmware in
> > the DT overlay. Such device will invoke firmware load, which uses the
> > filp_open() and will thus trigger the behavior above. Depending on
> > whether one uses dd or cat, the kernel will either crash or not.
> > 
> > Any ideas ?

I think you need to fix your device tree overlay code...

thanks,

greg k-h

Re: [PATCH] [RFC] fs: Possible filp_open race experiment

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 06:29:36AM +0100, Marek Vasut wrote:
> +CC Greg, LKML as I don't quite know where this should go.

You do know about linux-fsdevel, right?

> On 01/18/2017 12:16 AM, Marek Vasut wrote:
> > I believe there is a possible race condition when configfs attributes
> > trigger filp_open() from the kernel. I initially observed the problem
> > on Linux 4.4 when loading DT overlay , which in turn loads a driver
> > which loads firmware. After some further investigation, I came up with
> > the following minimal-ish example patch, which can trigger the same
> > behavior on Linux 4.10-rc4 (next 20170117).

What in-kernel code causes this problem?  I didn't think DT overlays
were a feature in 4.4, are you running with code that isn't in the
normal releases?

> > The core of the demo is in cfs_over_item_dtbo_write(), which just checks
> > for valid current->fs . This function is triggered by writing data into
> > configfs binary attribute, ie.:

Why are you caring about current->fs?

> > $ mkdir /sys/kernel/config/test/overlays/1/dtbo
> > $ cat file_17201_bytes_long > /sys/kernel/config/test/overlays/1/dtbo
> > 
> > I believe the 'cat' program exits quickly and thus calls fs_exit()
> > before the cfs_over_item_dtbo_write() is called.

How can exit be called before write?

> > Any attempts to
> > access FS (like ie. loading firmware from FS) from that function will
> > therefore fail (by crashing the kernel, NULL pointer dereference in
> > set_root_rcu() in fs/namei.c).
> > 
> > On the other hand, replacing 'cat' with 'dd' yields different result:
> > 
> > $ dd if=file_17201_bytes_long of=/sys/kernel/config/test/overlays/1/dtbo
> > 
> > The kernel does not crash. I believe this is because dd takes slightly
> > longer to complete, so the cfs_over_item_dtbo_write() can complete
> > before the dd process gets to calling fs_exit() and so the filesystem
> > access is still available, thus current->fs is valid.

cat and dd act differently, if you strace them, it should show the
differences, perhaps you can narrow it down there?

> > Note that when using DT overlays (whose configfs interface is not yet
> > mainline),

Ah, we can't do anything about code that is not merged, perhaps it is
just buggy? :)

> > there can easily be a device which requires a firmware in
> > the DT overlay. Such device will invoke firmware load, which uses the
> > filp_open() and will thus trigger the behavior above. Depending on
> > whether one uses dd or cat, the kernel will either crash or not.
> > 
> > Any ideas ?

I think you need to fix your device tree overlay code...

thanks,

greg k-h

crash in perf_event_read

[Alexei Starovoitov]

Hi Peter,

rarely I'm seeing the following crash:
[40196.164255] BUG: unable to handle kernel paging request at a11a
[40196.179636] IP: perf_event_read+0xd3/0x1a0
[40196.188669] PGD 82e93a067
[40196.188670] PUD 7e1ddf067
[40196.194629] PMD 0
[40196.200589]
[40196.208284] Oops:  [#1] SMP
[40196.208285] Modules linked in:
[40196.208299] CPU: 24 PID: 4423 Comm: dynoKernelMon Not tainted 
4.10.0-rc5-01189-gc6e0ad0ee5b0 #599
[40196.208300] Hardware name: Quanta Mono Lake-M.2 SATA 20F20BU0270/Mono 
Lake-M.2 SATA, BIOS F20_3A12 10/24/2016
[40196.208301] task: 8807e3b65580 task.stack: c90009748000
[40196.208302] RIP: 0010:perf_event_read+0xd3/0x1a0
[40196.208303] RSP: 0018:c9000974bd48 EFLAGS: 00010202
[40196.208304] RAX: a040 RBX: 8807b79fd000 RCX: 
[40196.208304] RDX: 0018 RSI:  RDI: 
[40196.208305] RBP: c9000974bd80 R08:  R09: 
[40196.208305] R10: 8807cf8c7038 R11:  R12: c9000974bde8
[40196.208306] R13:  R14: 8807b79fd000 R15: 04e0
[40196.208307] FS:  7ff1b45ff700() GS:88085f40() 
knlGS:
[40196.208307] CS:  0010 DS:  ES:  CR0: 80050033
[40196.208308] CR2: a11a CR3: 000850298000 CR4: 003406e0
[40196.208308] DR0:  DR1:  DR2: 
[40196.208309] DR3:  DR6: fffe0ff0 DR7: 0400
[40196.208309] Call Trace:
[40196.208313]  ? __might_sleep+0x4a/0x80
[40196.208316]  perf_event_read_value+0x45/0x130
[40196.208318]  perf_read+0x84/0x2d0
[40196.208322]  __vfs_read+0x28/0x110
[40196.208325]  ? security_file_permission+0x9b/0xc0
[40196.208327]  vfs_read+0xa5/0x170
[40196.208327]  SyS_read+0x46/0xa0
[40196.208329]  do_syscall_64+0x4d/0xb0
[40196.208332]  entry_SYSCALL64_slow_path+0x25/0x25
[40196.208333] RIP: 0033:0x7ff1b6f5716d
[40196.208334] RSP: 002b:7ff1b45fd080 EFLAGS: 0293 ORIG_RAX: 

[40196.208335] RAX: ffda RBX:  RCX: 7ff1b6f5716d
[40196.208335] RDX: 0020 RSI: 7ff1b45fd090 RDI: 0054
[40196.208336] RBP: 7ff1b45fd0e0 R08: 7ff1b65e45c0 R09: 7ff1b45fc9b1
[40196.208336] R10: 0020 R11: 0293 R12: 
[40196.208337] R13: 7ff1b5687000 R14: 0004a817c7fe R15: 04e0
[40196.208337] Code: 60 02 00 00 74 30 48 63 cf 48 c7 c0 40 a0 00 00 48 8b 34 
cd c0 93 d0 81 48 63 ca 48 8b 0c cd c0 93 d0 81 0f b7 8c 08 da 00 00 00 <66> 39 
8c 30 da 00 00 00 0f 44 fa 48 8d 55 d0 b9 01 00 00 00 48
[40196.208353] RIP: perf_event_read+0xd3/0x1a0 RSP: c9000974bd48
[40196.208353] CR2: a11a

The RIP points to this asm:
   0x8115fc9b <+155>:   mov%gs:0x7eeaa486(%rip),%edx# 
0xa128 
   0x8115fca2 <+162>:   testb  $0x2,0x68(%rbx)
   0x8115fca6 <+166>:   mov0x260(%rdi),%edi
   0x8115fcac <+172>:   je 0x8115fcde 
   0x8115fcae <+174>:   movslq %edi,%rcx
   0x8115fcb1 <+177>:   mov$0xa040,%rax
   0x8115fcb8 <+184>:   mov-0x7e2f6c40(,%rcx,8),%rsi
   0x8115fcc0 <+192>:   movslq %edx,%rcx
   0x8115fcc3 <+195>:   mov-0x7e2f6c40(,%rcx,8),%rcx
   0x8115fccb <+203>:   movzwl 0xda(%rax,%rcx,1),%ecx
   0x8115fcd3 <+211>:   cmp%cx,0xda(%rax,%rsi,1)

which is this C code:
perf_event_read():
  local_cpu = get_cpu();
  cpu_to_read = find_cpu_to_read(event, local_cpu);
  put_cpu();

find_cpu_to_read():
  event_pkg =  topology_physical_package_id(event_cpu);
  local_pkg =  topology_physical_package_id(local_cpu);
  if (event_pkg == local_pkg)

If I read the asm correctly at the time of the crash
event_cpu == RDI == 
or in other words event->oncpu == -1
which I think is technically possible here.

Any suggestions how to fix this?
Happy to test any patches, though I don't know how to reproduce reliably.

Thanks

crash in perf_event_read

[Alexei Starovoitov]

Hi Peter,

rarely I'm seeing the following crash:
[40196.164255] BUG: unable to handle kernel paging request at a11a
[40196.179636] IP: perf_event_read+0xd3/0x1a0
[40196.188669] PGD 82e93a067
[40196.188670] PUD 7e1ddf067
[40196.194629] PMD 0
[40196.200589]
[40196.208284] Oops:  [#1] SMP
[40196.208285] Modules linked in:
[40196.208299] CPU: 24 PID: 4423 Comm: dynoKernelMon Not tainted 
4.10.0-rc5-01189-gc6e0ad0ee5b0 #599
[40196.208300] Hardware name: Quanta Mono Lake-M.2 SATA 20F20BU0270/Mono 
Lake-M.2 SATA, BIOS F20_3A12 10/24/2016
[40196.208301] task: 8807e3b65580 task.stack: c90009748000
[40196.208302] RIP: 0010:perf_event_read+0xd3/0x1a0
[40196.208303] RSP: 0018:c9000974bd48 EFLAGS: 00010202
[40196.208304] RAX: a040 RBX: 8807b79fd000 RCX: 
[40196.208304] RDX: 0018 RSI:  RDI: 
[40196.208305] RBP: c9000974bd80 R08:  R09: 
[40196.208305] R10: 8807cf8c7038 R11:  R12: c9000974bde8
[40196.208306] R13:  R14: 8807b79fd000 R15: 04e0
[40196.208307] FS:  7ff1b45ff700() GS:88085f40() 
knlGS:
[40196.208307] CS:  0010 DS:  ES:  CR0: 80050033
[40196.208308] CR2: a11a CR3: 000850298000 CR4: 003406e0
[40196.208308] DR0:  DR1:  DR2: 
[40196.208309] DR3:  DR6: fffe0ff0 DR7: 0400
[40196.208309] Call Trace:
[40196.208313]  ? __might_sleep+0x4a/0x80
[40196.208316]  perf_event_read_value+0x45/0x130
[40196.208318]  perf_read+0x84/0x2d0
[40196.208322]  __vfs_read+0x28/0x110
[40196.208325]  ? security_file_permission+0x9b/0xc0
[40196.208327]  vfs_read+0xa5/0x170
[40196.208327]  SyS_read+0x46/0xa0
[40196.208329]  do_syscall_64+0x4d/0xb0
[40196.208332]  entry_SYSCALL64_slow_path+0x25/0x25
[40196.208333] RIP: 0033:0x7ff1b6f5716d
[40196.208334] RSP: 002b:7ff1b45fd080 EFLAGS: 0293 ORIG_RAX: 

[40196.208335] RAX: ffda RBX:  RCX: 7ff1b6f5716d
[40196.208335] RDX: 0020 RSI: 7ff1b45fd090 RDI: 0054
[40196.208336] RBP: 7ff1b45fd0e0 R08: 7ff1b65e45c0 R09: 7ff1b45fc9b1
[40196.208336] R10: 0020 R11: 0293 R12: 
[40196.208337] R13: 7ff1b5687000 R14: 0004a817c7fe R15: 04e0
[40196.208337] Code: 60 02 00 00 74 30 48 63 cf 48 c7 c0 40 a0 00 00 48 8b 34 
cd c0 93 d0 81 48 63 ca 48 8b 0c cd c0 93 d0 81 0f b7 8c 08 da 00 00 00 <66> 39 
8c 30 da 00 00 00 0f 44 fa 48 8d 55 d0 b9 01 00 00 00 48
[40196.208353] RIP: perf_event_read+0xd3/0x1a0 RSP: c9000974bd48
[40196.208353] CR2: a11a

The RIP points to this asm:
   0x8115fc9b <+155>:   mov%gs:0x7eeaa486(%rip),%edx# 
0xa128 
   0x8115fca2 <+162>:   testb  $0x2,0x68(%rbx)
   0x8115fca6 <+166>:   mov0x260(%rdi),%edi
   0x8115fcac <+172>:   je 0x8115fcde 
   0x8115fcae <+174>:   movslq %edi,%rcx
   0x8115fcb1 <+177>:   mov$0xa040,%rax
   0x8115fcb8 <+184>:   mov-0x7e2f6c40(,%rcx,8),%rsi
   0x8115fcc0 <+192>:   movslq %edx,%rcx
   0x8115fcc3 <+195>:   mov-0x7e2f6c40(,%rcx,8),%rcx
   0x8115fccb <+203>:   movzwl 0xda(%rax,%rcx,1),%ecx
   0x8115fcd3 <+211>:   cmp%cx,0xda(%rax,%rsi,1)

which is this C code:
perf_event_read():
  local_cpu = get_cpu();
  cpu_to_read = find_cpu_to_read(event, local_cpu);
  put_cpu();

find_cpu_to_read():
  event_pkg =  topology_physical_package_id(event_cpu);
  local_pkg =  topology_physical_package_id(local_cpu);
  if (event_pkg == local_pkg)

If I read the asm correctly at the time of the crash
event_cpu == RDI == 
or in other words event->oncpu == -1
which I think is technically possible here.

Any suggestions how to fix this?
Happy to test any patches, though I don't know how to reproduce reliably.

Thanks

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.

What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?

And what do you mean exactly by "(proprietary devices)"?

> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class

Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?

> Tested with these changes, and problem has been solved.

What changes?

thanks,

greg k-h

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.

What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?

And what do you mean exactly by "(proprietary devices)"?

> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class

Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?

> Tested with these changes, and problem has been solved.

What changes?

thanks,

greg k-h

RE: [PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

[MyungJoo Ham]

> The devfreq using passive governor is not able to change the governor.
> So, the user can not change the governor through 'available_governor' sysfs
> entry. Also, the devfreq which don't use the passive governor is not able to
> change to 'passive' governor on the fly.
> 
> Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/devfreq.c  | 31 +++
>  drivers/devfreq/governor_passive.c |  1 +
>  include/linux/devfreq.h|  3 +++
>  3 files changed, 31 insertions(+), 4 deletions(-)

Acked-by: MyungJoo Ham 

Applying to for-next.

RE: [PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

[MyungJoo Ham]

> The devfreq using passive governor is not able to change the governor.
> So, the user can not change the governor through 'available_governor' sysfs
> entry. Also, the devfreq which don't use the passive governor is not able to
> change to 'passive' governor on the fly.
> 
> Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/devfreq/devfreq.c  | 31 +++
>  drivers/devfreq/governor_passive.c |  1 +
>  include/linux/devfreq.h|  3 +++
>  3 files changed, 31 insertions(+), 4 deletions(-)

Acked-by: MyungJoo Ham 

Applying to for-next.

Re: linux-next: manual merge of the vfs-miklos tree with the overlayfs tree and build failure

[Amir Goldstein]

On Tue, Jan 31, 2017 at 2:16 AM, Stephen Rothwell  wrote:
> Hi Miklos,
>
> Today's linux-next merge of the vfs-miklos tree got a conflict in:
>
>   fs/read_write.c
>
> between commit:
>
>   97e147358bea ("vfs: wrap write f_ops with file_{start,end}_write()")
>
> from the overlayfs tree and various duplicated patches between v4.10-rc1
> and the vfs-miklos tree.
>

That's strange.
overlayfs-next whose head is the for mentioned commit is based on
v4.10-rc6 and has no duplicated patches AFAICS

Perhaps you are referring to the similar named patch:

3616119 vfs: no mnt_want_write_file() in vfs_{copy,clone}_file_range()

Miklos has converted mnt_want_write_file() => sb_start_write() for v4.10-rc1
and my change converts it again sb_start_write() => file_start_write(),
which is mostly a semantic difference, but with some implications.


> Please clean up the vfs-miklos tree.
>
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> I then got this build failure from my arm multi_v7_defconfig build:
>
> In file included from /home/sfr/next/next/include/linux/seq_file.h:10:0,
>  from /home/sfr/next/next/include/linux/pinctrl/consumer.h:17,
>  from /home/sfr/next/next/include/linux/pinctrl/devinfo.h:21,
>  from /home/sfr/next/next/include/linux/device.h:24,
>  from /home/sfr/next/next/include/linux/dma-mapping.h:6,
>  from /home/sfr/next/next/arch/arm/kernel/asm-offsets.c:16:
> /home/sfr/next/next/include/linux/fs.h:2566:19: error: redefinition of 
> 'do_clone
> _file_range'
>  static inline int do_clone_file_range(struct file *file_in, loff_t pos_in,
>^
> /home/sfr/next/next/include/linux/fs.h:1743:19: note: previous definition of 
> 'do_clone_file_range' was here
>  static inline int do_clone_file_range(struct file *file_in, loff_t pos_in,
>^
>

Please note that my patch moves do_clone_file_range() from line 1743
to line 2566,
because it needs to use file_start_write(), which is defined in line 2533.
so perhaps the conflict was not resolved correctly?

> so I decided to just drop the vfs-miklos tree for today.
> --
> Cheers,
> Stephen Rothwell

Re: [GIT PULL rcu/next] RCU commits for 4.11

[Ingo Molnar]

* Paul E. McKenney  wrote:

> Hello, Ingo,
> 
> This pull request contains the following changes:
> 
> 1.Documentation updates.
> 
>   http://lkml.kernel.org/r/20170114085032.ga18...@linux.vnet.ibm.com
> 
> 2.Dyntick updates, consolidating open-coded counter accesses
>   into a well-defined API.
> 
>   http://lkml.kernel.org/r/20170124214602.ga2...@linux.vnet.ibm.com
> 
> 3.Miscellaneous fixes.
> 
>   http://lkml.kernel.org/r/20170124215111.gb2...@linux.vnet.ibm.com
> 
> 4.SRCU updates: Simplify algorithm, add formal verification.
> 
>   http://lkml.kernel.org/r/20170124220011.gc2...@linux.vnet.ibm.com
> 
> 5.Torture-test updates.
> 
>   http://lkml.kernel.org/r/20170114092533.ga23...@linux.vnet.ibm.com
> 
> All of these changes have been subjected to 0day Test Robot and -next
> testing, and are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> for-mingo
> 
> for you to fetch changes up to 31945aa9f14085c81cb3257e51bb210698b78626:
> 
>   Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 
> 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD 
> (2017-01-25 12:56:05 -0800)
> 
> 
> Byungchul Park (1):
>   rcu: Only dump stalled-tasks stacks if there was a real stall
> 
> Joel Fernandes (1):
>   llist: Clarify comments about when locking is needed
> 
> Lance Roy (2):
>   srcu: Implement more-efficient reader counts
>   rcutorture: Add CBMC-based formal verification for SRCU
> 
> Mathieu Desnoyers (1):
>   Fix: Disable sys_membarrier when nohz_full is enabled
> 
> Matt Fleming (1):
>   rcu: Enable RCU tracepoints by default to aid in debugging
> 
> Paul E. McKenney (33):
>   rcu: Design documentation for expedited grace periods
>   doc: Update control-dependencies section of memory-barriers.txt
>   doc: Quick-Quiz answers are now inline
>   doc: Add rcutree.rcu_kick_kthreads to kernel-parameters.txt
>   torture: Add a check for CONFIG_RCU_STALL_COMMON for TINY01
>   torture: Add CONFIG_PROVE_RCU_REPEATEDLY=y for TINY02
>   torture: Add tests without slow grace period setup/cleanup
>   torture: Run at least one test with CONFIG_DEBUG_OBJECTS_RCU_HEAD
>   torture: Run one test with DEBUG_LOCK_ALLOC but not PROVE_LOCKING
>   torture: Run a couple scenarios with CONFIG_RCU_EQS_DEBUG
>   torture: Update RCU test scenario documentation
>   torture: Enable DEBUG_OBJECTS_RCU_HEAD for Tiny RCU
>   rcu: Abstract the dynticks momentary-idle operation
>   rcu: Abstract the dynticks snapshot operation
>   lockdep: Make RCU suspicious-access splats use pr_err
>   rcu: Remove unneeded rcu_process_callbacks() declarations
>   rcu: Add long-term CPU kicking
>   rcu: Remove short-term CPU kicking
>   rcu: Once again use NMI-based stack traces in stall warnings
>   rcu: Re-enable TASKS_RCU for User Mode Linux
>   rcu: Don't wake rcuc/X kthreads on NOCB CPUs
>   rcu: Add comment headers to expedited-grace-period counter functions
>   rcu: Make rcu_cpu_starting() use its "cpu" argument
>   rcu: Fix comment in rcu_organize_nocb_kthreads()
>   rcu: Eliminate unused expedited_normal counter
>   rcu: Add lockdep checks to synchronous expedited primitives
>   rcu: Abstract dynticks extended quiescent state enter/exit operations
>   rcu: Abstract extended quiescent state determination
>   rcu: Check cond_resched_rcu_qs() state less often to reduce GP overhead
>   rcu: Adjust FQS offline checks for exact online-CPU detection
>   srcu: Force full grace-period ordering
>   srcu: Reduce probability of SRCU ->unlock_count[] counter overflow
>   Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 
> 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD
> 
> Sebastian Andrzej Siewior (1):
>   rcu: update: Make RCU_EXPEDITE_BOOT be the default
> 
> Tetsuo Handa (1):
>   doc: Fix RCU requirements typos
> 
> Tobias Klauser (1):
>   rcu: Remove unused but set variable
> 
> Yang Shi (1):
>   locktorture: Fix potential memory leak with rw lock test
> 
>  .../Design/Data-Structures/Data-Structures.html|   5 +-
>  .../Design/Expedited-Grace-Periods/ExpRCUFlow.svg  | 830 
> +
>  .../Expedited-Grace-Periods/ExpSchedFlow.svg   | 826 
>  .../Expedited-Grace-Periods.html   | 626 
>  .../RCU/Design/Expedited-Grace-Periods/Funnel0.svg | 275 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel1.svg | 275 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel2.svg | 287 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel3.svg | 323 
>  .../RCU/Design/Expedited-Grace-Periods/Funnel4.svg | 323 
>  

Re: linux-next: manual merge of the vfs-miklos tree with the overlayfs tree and build failure

[Amir Goldstein]

On Tue, Jan 31, 2017 at 2:16 AM, Stephen Rothwell  wrote:
> Hi Miklos,
>
> Today's linux-next merge of the vfs-miklos tree got a conflict in:
>
>   fs/read_write.c
>
> between commit:
>
>   97e147358bea ("vfs: wrap write f_ops with file_{start,end}_write()")
>
> from the overlayfs tree and various duplicated patches between v4.10-rc1
> and the vfs-miklos tree.
>

That's strange.
overlayfs-next whose head is the for mentioned commit is based on
v4.10-rc6 and has no duplicated patches AFAICS

Perhaps you are referring to the similar named patch:

3616119 vfs: no mnt_want_write_file() in vfs_{copy,clone}_file_range()

Miklos has converted mnt_want_write_file() => sb_start_write() for v4.10-rc1
and my change converts it again sb_start_write() => file_start_write(),
which is mostly a semantic difference, but with some implications.


> Please clean up the vfs-miklos tree.
>
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> I then got this build failure from my arm multi_v7_defconfig build:
>
> In file included from /home/sfr/next/next/include/linux/seq_file.h:10:0,
>  from /home/sfr/next/next/include/linux/pinctrl/consumer.h:17,
>  from /home/sfr/next/next/include/linux/pinctrl/devinfo.h:21,
>  from /home/sfr/next/next/include/linux/device.h:24,
>  from /home/sfr/next/next/include/linux/dma-mapping.h:6,
>  from /home/sfr/next/next/arch/arm/kernel/asm-offsets.c:16:
> /home/sfr/next/next/include/linux/fs.h:2566:19: error: redefinition of 
> 'do_clone
> _file_range'
>  static inline int do_clone_file_range(struct file *file_in, loff_t pos_in,
>^
> /home/sfr/next/next/include/linux/fs.h:1743:19: note: previous definition of 
> 'do_clone_file_range' was here
>  static inline int do_clone_file_range(struct file *file_in, loff_t pos_in,
>^
>

Please note that my patch moves do_clone_file_range() from line 1743
to line 2566,
because it needs to use file_start_write(), which is defined in line 2533.
so perhaps the conflict was not resolved correctly?

> so I decided to just drop the vfs-miklos tree for today.
> --
> Cheers,
> Stephen Rothwell

Re: [GIT PULL rcu/next] RCU commits for 4.11

[Ingo Molnar]

* Paul E. McKenney  wrote:

> Hello, Ingo,
> 
> This pull request contains the following changes:
> 
> 1.Documentation updates.
> 
>   http://lkml.kernel.org/r/20170114085032.ga18...@linux.vnet.ibm.com
> 
> 2.Dyntick updates, consolidating open-coded counter accesses
>   into a well-defined API.
> 
>   http://lkml.kernel.org/r/20170124214602.ga2...@linux.vnet.ibm.com
> 
> 3.Miscellaneous fixes.
> 
>   http://lkml.kernel.org/r/20170124215111.gb2...@linux.vnet.ibm.com
> 
> 4.SRCU updates: Simplify algorithm, add formal verification.
> 
>   http://lkml.kernel.org/r/20170124220011.gc2...@linux.vnet.ibm.com
> 
> 5.Torture-test updates.
> 
>   http://lkml.kernel.org/r/20170114092533.ga23...@linux.vnet.ibm.com
> 
> All of these changes have been subjected to 0day Test Robot and -next
> testing, and are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> for-mingo
> 
> for you to fetch changes up to 31945aa9f14085c81cb3257e51bb210698b78626:
> 
>   Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 
> 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD 
> (2017-01-25 12:56:05 -0800)
> 
> 
> Byungchul Park (1):
>   rcu: Only dump stalled-tasks stacks if there was a real stall
> 
> Joel Fernandes (1):
>   llist: Clarify comments about when locking is needed
> 
> Lance Roy (2):
>   srcu: Implement more-efficient reader counts
>   rcutorture: Add CBMC-based formal verification for SRCU
> 
> Mathieu Desnoyers (1):
>   Fix: Disable sys_membarrier when nohz_full is enabled
> 
> Matt Fleming (1):
>   rcu: Enable RCU tracepoints by default to aid in debugging
> 
> Paul E. McKenney (33):
>   rcu: Design documentation for expedited grace periods
>   doc: Update control-dependencies section of memory-barriers.txt
>   doc: Quick-Quiz answers are now inline
>   doc: Add rcutree.rcu_kick_kthreads to kernel-parameters.txt
>   torture: Add a check for CONFIG_RCU_STALL_COMMON for TINY01
>   torture: Add CONFIG_PROVE_RCU_REPEATEDLY=y for TINY02
>   torture: Add tests without slow grace period setup/cleanup
>   torture: Run at least one test with CONFIG_DEBUG_OBJECTS_RCU_HEAD
>   torture: Run one test with DEBUG_LOCK_ALLOC but not PROVE_LOCKING
>   torture: Run a couple scenarios with CONFIG_RCU_EQS_DEBUG
>   torture: Update RCU test scenario documentation
>   torture: Enable DEBUG_OBJECTS_RCU_HEAD for Tiny RCU
>   rcu: Abstract the dynticks momentary-idle operation
>   rcu: Abstract the dynticks snapshot operation
>   lockdep: Make RCU suspicious-access splats use pr_err
>   rcu: Remove unneeded rcu_process_callbacks() declarations
>   rcu: Add long-term CPU kicking
>   rcu: Remove short-term CPU kicking
>   rcu: Once again use NMI-based stack traces in stall warnings
>   rcu: Re-enable TASKS_RCU for User Mode Linux
>   rcu: Don't wake rcuc/X kthreads on NOCB CPUs
>   rcu: Add comment headers to expedited-grace-period counter functions
>   rcu: Make rcu_cpu_starting() use its "cpu" argument
>   rcu: Fix comment in rcu_organize_nocb_kthreads()
>   rcu: Eliminate unused expedited_normal counter
>   rcu: Add lockdep checks to synchronous expedited primitives
>   rcu: Abstract dynticks extended quiescent state enter/exit operations
>   rcu: Abstract extended quiescent state determination
>   rcu: Check cond_resched_rcu_qs() state less often to reduce GP overhead
>   rcu: Adjust FQS offline checks for exact online-CPU detection
>   srcu: Force full grace-period ordering
>   srcu: Reduce probability of SRCU ->unlock_count[] counter overflow
>   Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 
> 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD
> 
> Sebastian Andrzej Siewior (1):
>   rcu: update: Make RCU_EXPEDITE_BOOT be the default
> 
> Tetsuo Handa (1):
>   doc: Fix RCU requirements typos
> 
> Tobias Klauser (1):
>   rcu: Remove unused but set variable
> 
> Yang Shi (1):
>   locktorture: Fix potential memory leak with rw lock test
> 
>  .../Design/Data-Structures/Data-Structures.html|   5 +-
>  .../Design/Expedited-Grace-Periods/ExpRCUFlow.svg  | 830 
> +
>  .../Expedited-Grace-Periods/ExpSchedFlow.svg   | 826 
>  .../Expedited-Grace-Periods.html   | 626 
>  .../RCU/Design/Expedited-Grace-Periods/Funnel0.svg | 275 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel1.svg | 275 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel2.svg | 287 +++
>  .../RCU/Design/Expedited-Grace-Periods/Funnel3.svg | 323 
>  .../RCU/Design/Expedited-Grace-Periods/Funnel4.svg | 323 
>  .../RCU/Design/Expedited-Grace-Periods/Funnel5.svg | 335 

Re: fs, net: deadlock between bind/splice on af_unix

[Cong Wang]

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik  wrote:
> On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote:
>> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik  wrote:
>> > Currently the file creation is potponed until unix_bind can no longer
>> > fail otherwise. With it reordered, it may be someone races you with a
>> > different path and now you are left with a file to clean up. Except it
>> > is quite unclear for me if you can unlink it.
>>
>> What races do you mean here? If you mean someone could get a
>> refcount of that file, it could happen no matter we have bindlock or not
>> since it is visible once created. The filesystem layer should take care of
>> the file refcount so all we need to do here is calling path_put() as in my
>> patch. Or if you mean two threads calling unix_bind() could race without
>> binlock, only one of them should succeed the other one just fails out.
>
> Two threads can race and one fails with EINVAL.
>
> With your patch there is a new file created and it is unclear what to
> do with it - leaving it as it is sounds like the last resort and
> unlinking it sounds extremely fishy as it opens you to games played by
> the user.

But the file is created and visible to users too even without my patch,
the file is also put when the unix sock is released. So the only difference
my patch makes is bindlock is no longer taken during file creation, which
does not seem to be the cause of the problem you complain here.

Mind being more specific?

Re: fs, net: deadlock between bind/splice on af_unix

[Cong Wang]

On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik  wrote:
> On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote:
>> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik  wrote:
>> > Currently the file creation is potponed until unix_bind can no longer
>> > fail otherwise. With it reordered, it may be someone races you with a
>> > different path and now you are left with a file to clean up. Except it
>> > is quite unclear for me if you can unlink it.
>>
>> What races do you mean here? If you mean someone could get a
>> refcount of that file, it could happen no matter we have bindlock or not
>> since it is visible once created. The filesystem layer should take care of
>> the file refcount so all we need to do here is calling path_put() as in my
>> patch. Or if you mean two threads calling unix_bind() could race without
>> binlock, only one of them should succeed the other one just fails out.
>
> Two threads can race and one fails with EINVAL.
>
> With your patch there is a new file created and it is unclear what to
> do with it - leaving it as it is sounds like the last resort and
> unlinking it sounds extremely fishy as it opens you to games played by
> the user.

But the file is created and visible to users too even without my patch,
the file is also put when the unix sock is released. So the only difference
my patch makes is bindlock is no longer taken during file creation, which
does not seem to be the cause of the problem you complain here.

Mind being more specific?

[PATCH v2 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

[Chanwoo Choi]

Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c  | 3 ++-
 drivers/devfreq/governor.h | 2 ++
 drivers/devfreq/governor_passive.c | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ade279d29f1e..4e86cc0106df 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -130,7 +130,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
  * @devfreq:   the devfreq instance
  * @freq:  the update target frequency
  */
-static int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
+int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
int lev, prev_lev, ret = 0;
unsigned long cur_time;
@@ -166,6 +166,7 @@ static int devfreq_update_status(struct devfreq *devfreq, 
unsigned long freq)
devfreq->last_stat_updated = cur_time;
return ret;
 }
+EXPORT_SYMBOL(devfreq_update_status);
 
 /**
  * find_devfreq_governor() - find devfreq governor from name
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..71576b8bdfef 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -38,4 +38,6 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
 extern int devfreq_add_governor(struct devfreq_governor *governor);
 extern int devfreq_remove_governor(struct devfreq_governor *governor);
 
+extern int devfreq_update_status(struct devfreq *devfreq, unsigned long freq);
+
 #endif /* _GOVERNOR_H */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 93795b32dc09..5be96b2249e7 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -112,6 +112,11 @@ static int update_devfreq_passive(struct devfreq *devfreq, 
unsigned long freq)
if (ret < 0)
goto out;
 
+   if (devfreq->profile->freq_table
+   && (devfreq_update_status(devfreq, freq)))
+   dev_err(>dev,
+   "Couldn't update frequency transition information.\n");
+
devfreq->previous_freq = freq;
 
 out:
-- 
1.9.1

[PATCH v2 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

[Chanwoo Choi]

The _remove_devfreq() releases the all resources of the devfreq
device. This function is only called in the devfreq_dev_release().
For that reason, the devfreq core doesn't need to leave the
_remove_devfreq() separately. This patch releases the all
resources in the devfreq_dev_release() and then removes the
_remove_devfreq().

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4e86cc0106df..2e685164c549 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -475,11 +475,15 @@ static int devfreq_notifier_call(struct notifier_block 
*nb, unsigned long type,
 }
 
 /**
- * _remove_devfreq() - Remove devfreq from the list and release its resources.
- * @devfreq:   the devfreq struct
+ * devfreq_dev_release() - Callback for struct device to release the device.
+ * @dev:   the devfreq device
+ *
+ * Remove devfreq from the list and release its resources.
  */
-static void _remove_devfreq(struct devfreq *devfreq)
+static void devfreq_dev_release(struct device *dev)
 {
+   struct devfreq *devfreq = to_devfreq(dev);
+
mutex_lock(_list_lock);
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
mutex_unlock(_list_lock);
@@ -501,19 +505,6 @@ static void _remove_devfreq(struct devfreq *devfreq)
 }
 
 /**
- * devfreq_dev_release() - Callback for struct device to release the device.
- * @dev:   the devfreq device
- *
- * This calls _remove_devfreq() if _remove_devfreq() is not called.
- */
-static void devfreq_dev_release(struct device *dev)
-{
-   struct devfreq *devfreq = to_devfreq(dev);
-
-   _remove_devfreq(devfreq);
-}
-
-/**
  * devfreq_add_device() - Add devfreq feature to the device
  * @dev:   the device to add devfreq feature.
  * @profile:   device-specific profile to run devfreq.
-- 
1.9.1

[PATCH v2 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

[Chanwoo Choi]

Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c  | 3 ++-
 drivers/devfreq/governor.h | 2 ++
 drivers/devfreq/governor_passive.c | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ade279d29f1e..4e86cc0106df 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -130,7 +130,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
  * @devfreq:   the devfreq instance
  * @freq:  the update target frequency
  */
-static int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
+int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
int lev, prev_lev, ret = 0;
unsigned long cur_time;
@@ -166,6 +166,7 @@ static int devfreq_update_status(struct devfreq *devfreq, 
unsigned long freq)
devfreq->last_stat_updated = cur_time;
return ret;
 }
+EXPORT_SYMBOL(devfreq_update_status);
 
 /**
  * find_devfreq_governor() - find devfreq governor from name
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..71576b8bdfef 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -38,4 +38,6 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
 extern int devfreq_add_governor(struct devfreq_governor *governor);
 extern int devfreq_remove_governor(struct devfreq_governor *governor);
 
+extern int devfreq_update_status(struct devfreq *devfreq, unsigned long freq);
+
 #endif /* _GOVERNOR_H */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 93795b32dc09..5be96b2249e7 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -112,6 +112,11 @@ static int update_devfreq_passive(struct devfreq *devfreq, 
unsigned long freq)
if (ret < 0)
goto out;
 
+   if (devfreq->profile->freq_table
+   && (devfreq_update_status(devfreq, freq)))
+   dev_err(>dev,
+   "Couldn't update frequency transition information.\n");
+
devfreq->previous_freq = freq;
 
 out:
-- 
1.9.1

[PATCH v2 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

[Chanwoo Choi]

The _remove_devfreq() releases the all resources of the devfreq
device. This function is only called in the devfreq_dev_release().
For that reason, the devfreq core doesn't need to leave the
_remove_devfreq() separately. This patch releases the all
resources in the devfreq_dev_release() and then removes the
_remove_devfreq().

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4e86cc0106df..2e685164c549 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -475,11 +475,15 @@ static int devfreq_notifier_call(struct notifier_block 
*nb, unsigned long type,
 }
 
 /**
- * _remove_devfreq() - Remove devfreq from the list and release its resources.
- * @devfreq:   the devfreq struct
+ * devfreq_dev_release() - Callback for struct device to release the device.
+ * @dev:   the devfreq device
+ *
+ * Remove devfreq from the list and release its resources.
  */
-static void _remove_devfreq(struct devfreq *devfreq)
+static void devfreq_dev_release(struct device *dev)
 {
+   struct devfreq *devfreq = to_devfreq(dev);
+
mutex_lock(_list_lock);
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
mutex_unlock(_list_lock);
@@ -501,19 +505,6 @@ static void _remove_devfreq(struct devfreq *devfreq)
 }
 
 /**
- * devfreq_dev_release() - Callback for struct device to release the device.
- * @dev:   the devfreq device
- *
- * This calls _remove_devfreq() if _remove_devfreq() is not called.
- */
-static void devfreq_dev_release(struct device *dev)
-{
-   struct devfreq *devfreq = to_devfreq(dev);
-
-   _remove_devfreq(devfreq);
-}
-
-/**
  * devfreq_add_device() - Add devfreq feature to the device
  * @dev:   the device to add devfreq feature.
  * @profile:   device-specific profile to run devfreq.
-- 
1.9.1

[PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

[Chanwoo Choi]

The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c  | 31 +++
 drivers/devfreq/governor_passive.c |  1 +
 include/linux/devfreq.h|  3 +++
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 8e5938c9c7d6..ade279d29f1e 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -940,6 +940,9 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
if (df->governor == governor) {
ret = 0;
goto out;
+   } else if (df->governor->immutable || governor->immutable) {
+   ret = -EINVAL;
+   goto out;
}
 
if (df->governor) {
@@ -969,13 +972,33 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
 {
-   struct devfreq_governor *tmp_governor;
+   struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
-   count += scnprintf([count], (PAGE_SIZE - count - 2),
-  "%s ", tmp_governor->name);
+
+   /*
+* The devfreq with immutable governor (e.g., passive) shows
+* only own governor.
+*/
+   if (df->governor->immutable) {
+   count = scnprintf([count], DEVFREQ_NAME_LEN,
+  "%s ", df->governor_name);
+   /*
+* The devfreq device shows the registered governor except for
+* immutable governors such as passive governor .
+*/
+   } else {
+   struct devfreq_governor *governor;
+
+   list_for_each_entry(governor, _governor_list, node) {
+   if (governor->immutable)
+   continue;
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", governor->name);
+   }
+   }
+
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 9ef46e2592c4..93795b32dc09 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -179,6 +179,7 @@ static int devfreq_passive_event_handler(struct devfreq 
*devfreq,
 
 static struct devfreq_governor devfreq_passive = {
.name = "passive",
+   .immutable = 1,
.get_target_freq = devfreq_passive_get_target_freq,
.event_handler = devfreq_passive_event_handler,
 };
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 2de4e2eea180..e0acb0e5243b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -104,6 +104,8 @@ struct devfreq_dev_profile {
  * struct devfreq_governor - Devfreq policy governor
  * @node:  list node - contains registered devfreq governors
  * @name:  Governor's name
+ * @immutable: Immutable flag for governor. If the value is 1,
+ * this govenror is never changeable to other governor.
  * @get_target_freq:   Returns desired operating frequency for the device.
  * Basically, get_target_freq will run
  * devfreq_dev_profile.get_dev_status() to get the
@@ -121,6 +123,7 @@ struct devfreq_governor {
struct list_head node;
 
const char name[DEVFREQ_NAME_LEN];
+   const unsigned int immutable;
int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
int (*event_handler)(struct devfreq *devfreq,
unsigned int event, void *data);
-- 
1.9.1

[PATCH v2 1/3] PM / devfreq: Fix available_governor sysfs

[Chanwoo Choi]

The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c  | 31 +++
 drivers/devfreq/governor_passive.c |  1 +
 include/linux/devfreq.h|  3 +++
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 8e5938c9c7d6..ade279d29f1e 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -940,6 +940,9 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
if (df->governor == governor) {
ret = 0;
goto out;
+   } else if (df->governor->immutable || governor->immutable) {
+   ret = -EINVAL;
+   goto out;
}
 
if (df->governor) {
@@ -969,13 +972,33 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
 {
-   struct devfreq_governor *tmp_governor;
+   struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
-   count += scnprintf([count], (PAGE_SIZE - count - 2),
-  "%s ", tmp_governor->name);
+
+   /*
+* The devfreq with immutable governor (e.g., passive) shows
+* only own governor.
+*/
+   if (df->governor->immutable) {
+   count = scnprintf([count], DEVFREQ_NAME_LEN,
+  "%s ", df->governor_name);
+   /*
+* The devfreq device shows the registered governor except for
+* immutable governors such as passive governor .
+*/
+   } else {
+   struct devfreq_governor *governor;
+
+   list_for_each_entry(governor, _governor_list, node) {
+   if (governor->immutable)
+   continue;
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", governor->name);
+   }
+   }
+
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 9ef46e2592c4..93795b32dc09 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -179,6 +179,7 @@ static int devfreq_passive_event_handler(struct devfreq 
*devfreq,
 
 static struct devfreq_governor devfreq_passive = {
.name = "passive",
+   .immutable = 1,
.get_target_freq = devfreq_passive_get_target_freq,
.event_handler = devfreq_passive_event_handler,
 };
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 2de4e2eea180..e0acb0e5243b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -104,6 +104,8 @@ struct devfreq_dev_profile {
  * struct devfreq_governor - Devfreq policy governor
  * @node:  list node - contains registered devfreq governors
  * @name:  Governor's name
+ * @immutable: Immutable flag for governor. If the value is 1,
+ * this govenror is never changeable to other governor.
  * @get_target_freq:   Returns desired operating frequency for the device.
  * Basically, get_target_freq will run
  * devfreq_dev_profile.get_dev_status() to get the
@@ -121,6 +123,7 @@ struct devfreq_governor {
struct list_head node;
 
const char name[DEVFREQ_NAME_LEN];
+   const unsigned int immutable;
int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
int (*event_handler)(struct devfreq *devfreq,
unsigned int event, void *data);
-- 
1.9.1

[PATCH v2 0/3] PM / devfreq: Fix issues about passive governor

[Chanwoo Choi]

This patchset fix the two issues about passive governor
and remove the unneeded separate _remove_devfreq() function.

First, the parent devfreq device can use the governors except for
the passive governor on the fly through sysfs entry and the passive
devfreq device is only possible to use the passive governor.

The 'available_governors' entry doesn't distinguish this difference
between parent devfreq and passive devfreq device. So, the patch1
fixes the this issue.

Second, the devfreq updates the statistic of frequency for each
device. But, 'trans_stat' of the passive devfreq device doesn't
update the statistic. So, the patch2 fixes this issue by calling
the update_devfreqw_passive() after setting the frequency
of passive devfreq device.

Finally, the patch3 removes the separate _remove_devfreq()
because this function is only called once in devfreq_dev_release().
I think that it is not necessary to make the separate function.

Changes from v1:
(https://lkml.org/lkml/2017/1/18/52)
- Add acked-by tag of devfreq maintainer to patch2/3.
- Remove the is_passive_gov() function because it is not appropriate
  to handle the specific governor name in the devfreq core. Instead,
  add the new 'immutable' flag to struct devfreq_governor.

Depends on:
- These patches based on the devfreq.git[1].
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-4.10-rc)

For example,
- The v1[2] series includes the detailed example about 'available_governors'
  and 'trans_stat' sysfs entry. We can refer to it.
[2] https://lkml.org/lkml/2017/1/18/52

Chanwoo Choi (3):
  PM / devfreq: Fix available_governor sysfs
  PM / devfreq: Fix wrong trans_stat of passive devfreq device
  PM / devfreq: Remove unnecessary separate _remove_devfreq()

 drivers/devfreq/devfreq.c  | 57 --
 drivers/devfreq/governor.h |  2 ++
 drivers/devfreq/governor_passive.c |  6 
 include/linux/devfreq.h|  3 ++
 4 files changed, 47 insertions(+), 21 deletions(-)

-- 
1.9.1

[PATCH v2 0/3] PM / devfreq: Fix issues about passive governor

[Chanwoo Choi]

This patchset fix the two issues about passive governor
and remove the unneeded separate _remove_devfreq() function.

First, the parent devfreq device can use the governors except for
the passive governor on the fly through sysfs entry and the passive
devfreq device is only possible to use the passive governor.

The 'available_governors' entry doesn't distinguish this difference
between parent devfreq and passive devfreq device. So, the patch1
fixes the this issue.

Second, the devfreq updates the statistic of frequency for each
device. But, 'trans_stat' of the passive devfreq device doesn't
update the statistic. So, the patch2 fixes this issue by calling
the update_devfreqw_passive() after setting the frequency
of passive devfreq device.

Finally, the patch3 removes the separate _remove_devfreq()
because this function is only called once in devfreq_dev_release().
I think that it is not necessary to make the separate function.

Changes from v1:
(https://lkml.org/lkml/2017/1/18/52)
- Add acked-by tag of devfreq maintainer to patch2/3.
- Remove the is_passive_gov() function because it is not appropriate
  to handle the specific governor name in the devfreq core. Instead,
  add the new 'immutable' flag to struct devfreq_governor.

Depends on:
- These patches based on the devfreq.git[1].
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-4.10-rc)

For example,
- The v1[2] series includes the detailed example about 'available_governors'
  and 'trans_stat' sysfs entry. We can refer to it.
[2] https://lkml.org/lkml/2017/1/18/52

Chanwoo Choi (3):
  PM / devfreq: Fix available_governor sysfs
  PM / devfreq: Fix wrong trans_stat of passive devfreq device
  PM / devfreq: Remove unnecessary separate _remove_devfreq()

 drivers/devfreq/devfreq.c  | 57 --
 drivers/devfreq/governor.h |  2 ++
 drivers/devfreq/governor_passive.c |  6 
 include/linux/devfreq.h|  3 ++
 4 files changed, 47 insertions(+), 21 deletions(-)

-- 
1.9.1

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Kalle Valo]

Tony Lindgren  writes:

> * Pavel Machek  [170127 11:41]:
>> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
>> > Pali Rohár  writes:
>> > 
>> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> > >> Pali Rohár  writes:
>> > >> 
>> > >> > 2) It was already tested that example NVS data can be used for N900 
>> > >> > e.g.
>> > >> > for SSH connection. If real correct data are not available it is 
>> > >> > better
>> > >> > to use at least those example (and probably log warning message) so 
>> > >> > user
>> > >> > can connect via SSH and start investigating where is problem.
>> > >> 
>> > >> I disagree. Allowing default calibration data to be used can be
>> > >> unnoticed by user and left her wondering why wifi works so badly.
>> > >
>> > > So there are only two options:
>> > >
>> > > 1) Disallow it and so these users will have non-working wifi.
>> > >
>> > > 2) Allow those data to be used as fallback mechanism.
>> > >
>> > > And personally I'm against 1) because it will break wifi support for
>> > > *all* Nokia N900 devices right now.
>> > 
>> > All two of them? :)
>> 
>> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
>
> Well this silly issue of symlinking and renaming nvs files in a standard
> Linux distro was also hitting me on various devices with wl12xx/wl18xx
> trying to use the same rootfs.
>
> Why don't we just set a custom compatible property for n900 that then
> picks up some other nvs file instead of the default?

Please don't. An ugly kernel workaround in kernel because of user space
problems is a bad idea. wl1251 should just ask for NVS file from user
space, it shouldn't care if it's a "default" file or something else.
That's a user space policy decision.

Why can't you do something like this:

* rename the NVS file linux-firmware to wl1251-nvs.bin.example

* before distro updates linux-firmware create yours own deb/rpm/whatever
  package "wl1251-firmware" which installs your flavor of nvs file (or
  the user fallback helper if more dynamic functionality is preferred)

-- 
Kalle Valo

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Kalle Valo]

Tony Lindgren  writes:

> * Pavel Machek  [170127 11:41]:
>> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
>> > Pali Rohár  writes:
>> > 
>> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> > >> Pali Rohár  writes:
>> > >> 
>> > >> > 2) It was already tested that example NVS data can be used for N900 
>> > >> > e.g.
>> > >> > for SSH connection. If real correct data are not available it is 
>> > >> > better
>> > >> > to use at least those example (and probably log warning message) so 
>> > >> > user
>> > >> > can connect via SSH and start investigating where is problem.
>> > >> 
>> > >> I disagree. Allowing default calibration data to be used can be
>> > >> unnoticed by user and left her wondering why wifi works so badly.
>> > >
>> > > So there are only two options:
>> > >
>> > > 1) Disallow it and so these users will have non-working wifi.
>> > >
>> > > 2) Allow those data to be used as fallback mechanism.
>> > >
>> > > And personally I'm against 1) because it will break wifi support for
>> > > *all* Nokia N900 devices right now.
>> > 
>> > All two of them? :)
>> 
>> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
>
> Well this silly issue of symlinking and renaming nvs files in a standard
> Linux distro was also hitting me on various devices with wl12xx/wl18xx
> trying to use the same rootfs.
>
> Why don't we just set a custom compatible property for n900 that then
> picks up some other nvs file instead of the default?

Please don't. An ugly kernel workaround in kernel because of user space
problems is a bad idea. wl1251 should just ask for NVS file from user
space, it shouldn't care if it's a "default" file or something else.
That's a user space policy decision.

Why can't you do something like this:

* rename the NVS file linux-firmware to wl1251-nvs.bin.example

* before distro updates linux-firmware create yours own deb/rpm/whatever
  package "wl1251-firmware" which installs your flavor of nvs file (or
  the user fallback helper if more dynamic functionality is preferred)

-- 
Kalle Valo

RE: Re: [PATCH v4 1/4] PM / devfreq: Fix the wrong description for userspace governor

[MyungJoo Ham]

> On Tue, Jan 24, 2017 at 4:42 AM, MyungJoo Ham  
> wrote:
> >> This patch fixes the wrong description of governor_userspace.c
> >> and removes the unneeded blank line.
> >>
> >> Signed-off-by: Chanwoo Choi 
> >> ---
> >
> > Applied in for-next
> 
> 
> Quite frankly I'm not entirely sure what's going on in the devfreq land.
> 
> Some patches are ACKed by you, some of them are applied and it is hard
> to say what the rule is.
> 
> Besides, it is quite late in the cycle, so it would be nice to receive
> a pull request for the devfreq material already collected for 4.11.
> 
> Thanks,
> Rafael

- The patches that change ABI is being delayed
  for further discussions with Chanwoo.

- The patches that change mechanisms of handling passive governor
differently in devfreq.c require further updates from Chanwoo;
so they are being not applied for now as well.

If it appears that those two patchset are not going to make in time
(mid this week), I'll send out pull-request for 4.11 without them.


Cheers,
MyungJoo 

[PATCH 2/2] ASoC: qcom: Drop __func__ usage from log prints

[Bjorn Andersson]

The combination of dev_err() and __func__ make most of these log prints
over 100 chars long. Remove the usage of __func__ to clean the kernel
log and as the usage is not necessary to identify the individual log
prints.

Cc: Banajit Goswami 
Cc: Patrick Lai 
Cc: Srinivas Kandagatla 
Signed-off-by: Bjorn Andersson 
---
 sound/soc/qcom/lpass-apq8016.c  |  15 +++---
 sound/soc/qcom/lpass-cpu.c  |  86 ++--
 sound/soc/qcom/lpass-platform.c | 106 
 sound/soc/qcom/storm.c  |  22 +++--
 4 files changed, 103 insertions(+), 126 deletions(-)

diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 3eef0c37ba50..8aed72be3224 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -175,29 +175,28 @@ static int apq8016_lpass_init(struct platform_device 
*pdev)
 
drvdata->pcnoc_mport_clk = devm_clk_get(dev, "pcnoc-mport-clk");
if (IS_ERR(drvdata->pcnoc_mport_clk)) {
-   dev_err(>dev, "%s() error getting pcnoc-mport-clk: %ld\n",
-   __func__, PTR_ERR(drvdata->pcnoc_mport_clk));
+   dev_err(>dev, "error getting pcnoc-mport-clk: %ld\n",
+   PTR_ERR(drvdata->pcnoc_mport_clk));
return PTR_ERR(drvdata->pcnoc_mport_clk);
}
 
ret = clk_prepare_enable(drvdata->pcnoc_mport_clk);
if (ret) {
-   dev_err(>dev, "%s() Error enabling pcnoc-mport-clk: %d\n",
-   __func__, ret);
+   dev_err(>dev, "Error enabling pcnoc-mport-clk: %d\n",
+   ret);
return ret;
}
 
drvdata->pcnoc_sway_clk = devm_clk_get(dev, "pcnoc-sway-clk");
if (IS_ERR(drvdata->pcnoc_sway_clk)) {
-   dev_err(>dev, "%s() error getting pcnoc-sway-clk: %ld\n",
-   __func__, PTR_ERR(drvdata->pcnoc_sway_clk));
+   dev_err(>dev, "error getting pcnoc-sway-clk: %ld\n",
+   PTR_ERR(drvdata->pcnoc_sway_clk));
return PTR_ERR(drvdata->pcnoc_sway_clk);
}
 
ret = clk_prepare_enable(drvdata->pcnoc_sway_clk);
if (ret) {
-   dev_err(>dev, "%s() Error enabling pcnoc_sway_clk: %d\n",
-   __func__, ret);
+   dev_err(>dev, "Error enabling pcnoc_sway_clk: %d\n", ret);
return ret;
}
 
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 1b912a9bb791..5202a584e0c6 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -35,8 +35,8 @@ static int lpass_cpu_daiops_set_sysclk(struct snd_soc_dai 
*dai, int clk_id,
 
ret = clk_set_rate(drvdata->mi2s_osr_clk[dai->driver->id], freq);
if (ret)
-   dev_err(dai->dev, "%s() error setting mi2s osrclk to %u: %d\n",
-   __func__, freq, ret);
+   dev_err(dai->dev, "error setting mi2s osrclk to %u: %d\n",
+   freq, ret);
 
return ret;
 }
@@ -49,15 +49,13 @@ static int lpass_cpu_daiops_startup(struct 
snd_pcm_substream *substream,
 
ret = clk_prepare_enable(drvdata->mi2s_osr_clk[dai->driver->id]);
if (ret) {
-   dev_err(dai->dev, "%s() error in enabling mi2s osr clk: %d\n",
-   __func__, ret);
+   dev_err(dai->dev, "error in enabling mi2s osr clk: %d\n", ret);
return ret;
}
 
ret = clk_prepare_enable(drvdata->mi2s_bit_clk[dai->driver->id]);
if (ret) {
-   dev_err(dai->dev, "%s() error in enabling mi2s bit clk: %d\n",
-   __func__, ret);
+   dev_err(dai->dev, "error in enabling mi2s bit clk: %d\n", ret);
clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]);
return ret;
}
@@ -87,8 +85,7 @@ static int lpass_cpu_daiops_hw_params(struct 
snd_pcm_substream *substream,
 
bitwidth = snd_pcm_format_width(format);
if (bitwidth < 0) {
-   dev_err(dai->dev, "%s() invalid bit width given: %d\n",
-   __func__, bitwidth);
+   dev_err(dai->dev, "invalid bit width given: %d\n", bitwidth);
return bitwidth;
}
 
@@ -106,8 +103,7 @@ static int lpass_cpu_daiops_hw_params(struct 
snd_pcm_substream *substream,
regval |= LPAIF_I2SCTL_BITWIDTH_32;
break;
default:
-   dev_err(dai->dev, "%s() invalid bitwidth given: %d\n",
-   __func__, bitwidth);
+   dev_err(dai->dev, "invalid bitwidth given: %d\n", bitwidth);
return -EINVAL;
}
 
@@ -134,8 +130,8 @@ static int 

RE: Re: [PATCH v4 1/4] PM / devfreq: Fix the wrong description for userspace governor

[MyungJoo Ham]

> On Tue, Jan 24, 2017 at 4:42 AM, MyungJoo Ham  
> wrote:
> >> This patch fixes the wrong description of governor_userspace.c
> >> and removes the unneeded blank line.
> >>
> >> Signed-off-by: Chanwoo Choi 
> >> ---
> >
> > Applied in for-next
> 
> 
> Quite frankly I'm not entirely sure what's going on in the devfreq land.
> 
> Some patches are ACKed by you, some of them are applied and it is hard
> to say what the rule is.
> 
> Besides, it is quite late in the cycle, so it would be nice to receive
> a pull request for the devfreq material already collected for 4.11.
> 
> Thanks,
> Rafael

- The patches that change ABI is being delayed
  for further discussions with Chanwoo.

- The patches that change mechanisms of handling passive governor
differently in devfreq.c require further updates from Chanwoo;
so they are being not applied for now as well.

If it appears that those two patchset are not going to make in time
(mid this week), I'll send out pull-request for 4.11 without them.


Cheers,
MyungJoo 

[PATCH 2/2] ASoC: qcom: Drop __func__ usage from log prints

[Bjorn Andersson]

The combination of dev_err() and __func__ make most of these log prints
over 100 chars long. Remove the usage of __func__ to clean the kernel
log and as the usage is not necessary to identify the individual log
prints.

Cc: Banajit Goswami 
Cc: Patrick Lai 
Cc: Srinivas Kandagatla 
Signed-off-by: Bjorn Andersson 
---
 sound/soc/qcom/lpass-apq8016.c  |  15 +++---
 sound/soc/qcom/lpass-cpu.c  |  86 ++--
 sound/soc/qcom/lpass-platform.c | 106 
 sound/soc/qcom/storm.c  |  22 +++--
 4 files changed, 103 insertions(+), 126 deletions(-)

diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 3eef0c37ba50..8aed72be3224 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -175,29 +175,28 @@ static int apq8016_lpass_init(struct platform_device 
*pdev)
 
drvdata->pcnoc_mport_clk = devm_clk_get(dev, "pcnoc-mport-clk");
if (IS_ERR(drvdata->pcnoc_mport_clk)) {
-   dev_err(>dev, "%s() error getting pcnoc-mport-clk: %ld\n",
-   __func__, PTR_ERR(drvdata->pcnoc_mport_clk));
+   dev_err(>dev, "error getting pcnoc-mport-clk: %ld\n",
+   PTR_ERR(drvdata->pcnoc_mport_clk));
return PTR_ERR(drvdata->pcnoc_mport_clk);
}
 
ret = clk_prepare_enable(drvdata->pcnoc_mport_clk);
if (ret) {
-   dev_err(>dev, "%s() Error enabling pcnoc-mport-clk: %d\n",
-   __func__, ret);
+   dev_err(>dev, "Error enabling pcnoc-mport-clk: %d\n",
+   ret);
return ret;
}
 
drvdata->pcnoc_sway_clk = devm_clk_get(dev, "pcnoc-sway-clk");
if (IS_ERR(drvdata->pcnoc_sway_clk)) {
-   dev_err(>dev, "%s() error getting pcnoc-sway-clk: %ld\n",
-   __func__, PTR_ERR(drvdata->pcnoc_sway_clk));
+   dev_err(>dev, "error getting pcnoc-sway-clk: %ld\n",
+   PTR_ERR(drvdata->pcnoc_sway_clk));
return PTR_ERR(drvdata->pcnoc_sway_clk);
}
 
ret = clk_prepare_enable(drvdata->pcnoc_sway_clk);
if (ret) {
-   dev_err(>dev, "%s() Error enabling pcnoc_sway_clk: %d\n",
-   __func__, ret);
+   dev_err(>dev, "Error enabling pcnoc_sway_clk: %d\n", ret);
return ret;
}
 
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 1b912a9bb791..5202a584e0c6 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -35,8 +35,8 @@ static int lpass_cpu_daiops_set_sysclk(struct snd_soc_dai 
*dai, int clk_id,
 
ret = clk_set_rate(drvdata->mi2s_osr_clk[dai->driver->id], freq);
if (ret)
-   dev_err(dai->dev, "%s() error setting mi2s osrclk to %u: %d\n",
-   __func__, freq, ret);
+   dev_err(dai->dev, "error setting mi2s osrclk to %u: %d\n",
+   freq, ret);
 
return ret;
 }
@@ -49,15 +49,13 @@ static int lpass_cpu_daiops_startup(struct 
snd_pcm_substream *substream,
 
ret = clk_prepare_enable(drvdata->mi2s_osr_clk[dai->driver->id]);
if (ret) {
-   dev_err(dai->dev, "%s() error in enabling mi2s osr clk: %d\n",
-   __func__, ret);
+   dev_err(dai->dev, "error in enabling mi2s osr clk: %d\n", ret);
return ret;
}
 
ret = clk_prepare_enable(drvdata->mi2s_bit_clk[dai->driver->id]);
if (ret) {
-   dev_err(dai->dev, "%s() error in enabling mi2s bit clk: %d\n",
-   __func__, ret);
+   dev_err(dai->dev, "error in enabling mi2s bit clk: %d\n", ret);
clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]);
return ret;
}
@@ -87,8 +85,7 @@ static int lpass_cpu_daiops_hw_params(struct 
snd_pcm_substream *substream,
 
bitwidth = snd_pcm_format_width(format);
if (bitwidth < 0) {
-   dev_err(dai->dev, "%s() invalid bit width given: %d\n",
-   __func__, bitwidth);
+   dev_err(dai->dev, "invalid bit width given: %d\n", bitwidth);
return bitwidth;
}
 
@@ -106,8 +103,7 @@ static int lpass_cpu_daiops_hw_params(struct 
snd_pcm_substream *substream,
regval |= LPAIF_I2SCTL_BITWIDTH_32;
break;
default:
-   dev_err(dai->dev, "%s() invalid bitwidth given: %d\n",
-   __func__, bitwidth);
+   dev_err(dai->dev, "invalid bitwidth given: %d\n", bitwidth);
return -EINVAL;
}
 
@@ -134,8 +130,8 @@ static int lpass_cpu_daiops_hw_params(struct 
snd_pcm_substream *substream,
regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
  

Re: [Patch v4 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Olof Johansson]

On Mon, Jan 30, 2017 at 2:55 AM, Will Deacon  wrote:
> Hi Olof,
>
> On Sun, Jan 29, 2017 at 04:24:51PM -0800, Olof Johansson wrote:
>> On Thu, Jan 19, 2017 at 8:58 AM, Andy Gross  wrote:
>> > This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
>> >
>> > On Qualcomm ARM64 platforms, the SMC call can return before it has
>> > completed.  If this occurs, the call can be restarted, but it requires
>> > using the returned session ID value from the interrupted SMC call.
>> >
>> > The quirk stores off the session ID from the interrupted call in the
>> > quirk structure so that it can be used by the caller.
>> >
>> > This patch folds in a fix given by Sricharan R:
>> > https://lkml.org/lkml/2016/9/28/272
>> >
>> > Signed-off-by: Andy Gross 
>> > Reviewed-by: Will Deacon 
>> > ---
>> >  arch/arm64/kernel/smccc-call.S |  9 -
>> >  drivers/firmware/qcom_scm-64.c | 13 ++---
>> >  include/linux/arm-smccc.h  | 11 ---
>> >  3 files changed, 26 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/arch/arm64/kernel/smccc-call.S 
>> > b/arch/arm64/kernel/smccc-call.S
>> > index 6290696..72ecdca 100644
>> > --- a/arch/arm64/kernel/smccc-call.S
>> > +++ b/arch/arm64/kernel/smccc-call.S
>> > @@ -12,6 +12,7 @@
>> >   *
>> >   */
>> >  #include 
>> > +#include 
>> >  #include 
>> >
>> > .macro SMCCC instr
>> > @@ -20,7 +21,13 @@
>> > ldr x4, [sp]
>> > stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
>> > stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
>> > -   ret
>> > +   ldr x4, [sp, #8]
>> > +   cbz x4, 1f /* no quirk structure */
>> > +   ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
>> > +   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
>> > +   b.ne1f
>> > +   str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
>> > +1: ret
>> > .cfi_endproc
>> > .endm
>>
>> This extends the SMC entry/return path quite a bit.
>
> I honestly doubt it's measurable. You've got an independent load from the
> stack and a cbz that's likely predicted correctly given the static nature
> of the quirk. Then you have an SMC, which is going to trap and dominate
> the cost of this function.
>
>> Is this truly a qualcomm-only quirk, or are other vendors also picking it
>> up?
>
> Currently, it's just qualcomm. Whilst I'd love to say they'll be the only
> people to interpret the SMCCC in an imaginative fashion, I'd be surprised
> if we don't see other vendors making mistakes in this area in the future.

Ok, so the list of checks is anticipated to grow.

>> Why not either make arm_smccc_.* function pointers and update them
>> accordingly, or use a custom version for the specific locations where
>> you want/need to restart the calls? You are after all already wrapping
>> them in qcom_scm_call().
>
> Having the low-level SMC entry code in one place is advantageous because
> it means the SMCCC contract is enforced in common code, making it easier
> to debug and maintain. If a vendor got the contract so badly wrong that
> it didn't resemble SMCCC, then I'd agree with you, but here we're just
> saving and restoring an extra register.

What contract? Qualcomm just violated it and the answer isn't to
enforce, it's to enable their "enhanced" implementation (and it should
be, within reason).

It's not like their own special SMCCC functions have to go in a
different file. Stick them on the side of the current ones in the same
file. The main call is already nicely abstracted with an asm macro so
that part will be shared, and the call sites are per-vendor anyway.

>> Seems like a more appropriate change than burden all platforms with
>> longer code path due to your quirk.
>
> I really don't think it's a problem. Do you have numbers suggesting
> otherwise?

Not on this first quirk, no.

Anyway, I guess I'm just bikeshedding. You should merge this code if
you're happy with it.



Thanks!

-Olof

Re: [Patch v4 2/2] firmware: qcom: scm: Fix interrupted SCM calls

[Olof Johansson]

On Mon, Jan 30, 2017 at 2:55 AM, Will Deacon  wrote:
> Hi Olof,
>
> On Sun, Jan 29, 2017 at 04:24:51PM -0800, Olof Johansson wrote:
>> On Thu, Jan 19, 2017 at 8:58 AM, Andy Gross  wrote:
>> > This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
>> >
>> > On Qualcomm ARM64 platforms, the SMC call can return before it has
>> > completed.  If this occurs, the call can be restarted, but it requires
>> > using the returned session ID value from the interrupted SMC call.
>> >
>> > The quirk stores off the session ID from the interrupted call in the
>> > quirk structure so that it can be used by the caller.
>> >
>> > This patch folds in a fix given by Sricharan R:
>> > https://lkml.org/lkml/2016/9/28/272
>> >
>> > Signed-off-by: Andy Gross 
>> > Reviewed-by: Will Deacon 
>> > ---
>> >  arch/arm64/kernel/smccc-call.S |  9 -
>> >  drivers/firmware/qcom_scm-64.c | 13 ++---
>> >  include/linux/arm-smccc.h  | 11 ---
>> >  3 files changed, 26 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/arch/arm64/kernel/smccc-call.S 
>> > b/arch/arm64/kernel/smccc-call.S
>> > index 6290696..72ecdca 100644
>> > --- a/arch/arm64/kernel/smccc-call.S
>> > +++ b/arch/arm64/kernel/smccc-call.S
>> > @@ -12,6 +12,7 @@
>> >   *
>> >   */
>> >  #include 
>> > +#include 
>> >  #include 
>> >
>> > .macro SMCCC instr
>> > @@ -20,7 +21,13 @@
>> > ldr x4, [sp]
>> > stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
>> > stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
>> > -   ret
>> > +   ldr x4, [sp, #8]
>> > +   cbz x4, 1f /* no quirk structure */
>> > +   ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
>> > +   cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
>> > +   b.ne1f
>> > +   str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
>> > +1: ret
>> > .cfi_endproc
>> > .endm
>>
>> This extends the SMC entry/return path quite a bit.
>
> I honestly doubt it's measurable. You've got an independent load from the
> stack and a cbz that's likely predicted correctly given the static nature
> of the quirk. Then you have an SMC, which is going to trap and dominate
> the cost of this function.
>
>> Is this truly a qualcomm-only quirk, or are other vendors also picking it
>> up?
>
> Currently, it's just qualcomm. Whilst I'd love to say they'll be the only
> people to interpret the SMCCC in an imaginative fashion, I'd be surprised
> if we don't see other vendors making mistakes in this area in the future.

Ok, so the list of checks is anticipated to grow.

>> Why not either make arm_smccc_.* function pointers and update them
>> accordingly, or use a custom version for the specific locations where
>> you want/need to restart the calls? You are after all already wrapping
>> them in qcom_scm_call().
>
> Having the low-level SMC entry code in one place is advantageous because
> it means the SMCCC contract is enforced in common code, making it easier
> to debug and maintain. If a vendor got the contract so badly wrong that
> it didn't resemble SMCCC, then I'd agree with you, but here we're just
> saving and restoring an extra register.

What contract? Qualcomm just violated it and the answer isn't to
enforce, it's to enable their "enhanced" implementation (and it should
be, within reason).

It's not like their own special SMCCC functions have to go in a
different file. Stick them on the side of the current ones in the same
file. The main call is already nicely abstracted with an asm macro so
that part will be shared, and the call sites are per-vendor anyway.

>> Seems like a more appropriate change than burden all platforms with
>> longer code path due to your quirk.
>
> I really don't think it's a problem. Do you have numbers suggesting
> otherwise?

Not on this first quirk, no.

Anyway, I guess I'm just bikeshedding. You should merge this code if
you're happy with it.



Thanks!

-Olof

Re: net: suspicious RCU usage in nf_hook

[Cong Wang]

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet  wrote:
> On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote:
>> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet  wrote:
>> > Oh well, I forgot to submit the official patch I think, Jan 9th.
>> >
>> > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ
>> >
>>
>> Hmm, but why only fragments need skb_orphan()? It seems like
>> any kfree_skb() inside a nf hook needs to have a preceding
>> skb_orphan().
>
>
>>
>> Also, I am not convinced it is similar to commit 8282f27449bf15548
>> which is on RX path.
>
> Well, we clearly see IPv6 reassembly being part of the equation in both
> cases.

Yeah, of course. My worry is that this problem is more than just
IPv6 reassembly.

>
> I was replying to first part of the splat [1], which was already
> diagnosed and had a non official patch.
>
> use after free is also a bug, regardless of jump label being used or
> not.
>
> I still do not really understand this nf_hook issue, I thought we were
> disabling BH in netfilter.

It is a different warning from use-after-free, this one is about sleep
in atomic context, mutex lock is acquired with RCU read lock held.


>
> So the in_interrupt() check in net_disable_timestamp() should trigger,
> this was the intent of netstamp_needed_deferred existence.
>
> Not sure if we can test for rcu_read_lock() as well.
>

The context is process context (TX path before hitting qdisc), and
BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
makes me thinking maybe we really need to disable BH in this
case for nf_hook()? But it is called in RX path too, and BH is
already disabled there.

Re: net: suspicious RCU usage in nf_hook

[Cong Wang]

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet  wrote:
> On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote:
>> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet  wrote:
>> > Oh well, I forgot to submit the official patch I think, Jan 9th.
>> >
>> > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ
>> >
>>
>> Hmm, but why only fragments need skb_orphan()? It seems like
>> any kfree_skb() inside a nf hook needs to have a preceding
>> skb_orphan().
>
>
>>
>> Also, I am not convinced it is similar to commit 8282f27449bf15548
>> which is on RX path.
>
> Well, we clearly see IPv6 reassembly being part of the equation in both
> cases.

Yeah, of course. My worry is that this problem is more than just
IPv6 reassembly.

>
> I was replying to first part of the splat [1], which was already
> diagnosed and had a non official patch.
>
> use after free is also a bug, regardless of jump label being used or
> not.
>
> I still do not really understand this nf_hook issue, I thought we were
> disabling BH in netfilter.

It is a different warning from use-after-free, this one is about sleep
in atomic context, mutex lock is acquired with RCU read lock held.


>
> So the in_interrupt() check in net_disable_timestamp() should trigger,
> this was the intent of netstamp_needed_deferred existence.
>
> Not sure if we can test for rcu_read_lock() as well.
>

The context is process context (TX path before hitting qdisc), and
BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
makes me thinking maybe we really need to disable BH in this
case for nf_hook()? But it is called in RX path too, and BH is
already disabled there.

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Mike Galbraith]

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote:
> On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote:
> > Running Steven's hotplug stress script in tip.today.  Config is
> > NOPREEMPT, tune for maximum build time (enterprise default-ish).
> > 
> > [   75.268049] x86: Booting SMP configuration:
> > [   75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > [   75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4
> > [   75.294617] smpboot: Booting Node 0 Processor 4 APIC 0x1
> > [   75.310698] smpboot: Booting Node 0 Processor 5 APIC 0x3
> > [   75.359056] smpboot: CPU 3 is now offline
> > [   75.415505] smpboot: CPU 4 is now offline
> > [   75.479985] smpboot: CPU 5 is now offline
> > [   75.550674] [ cut here ]
> > [   75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> > assert_clock_updated.isra.62.part.63+0x25/0x27
> > [   75.550679] rq->clock_update_flags < RQCF_ACT_SKIP
> 
> The following patch queued in tip/sched/core should fix this issue:

Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
an early boot brick problem.

> >8
> 
> From 4d25b35ea3729affd37d69c78191ce6f92766e1a Mon Sep 17 00:00:00
> 2001
> From: Matt Fleming 
> Date: Wed, 26 Oct 2016 16:15:44 +0100
> Subject: [PATCH] sched/fair: Restore previous rq_flags when migrating
> tasks in
>  hotplug
> 
> __migrate_task() can return with a different runqueue locked than the
> one we passed as an argument. So that we can repin the lock in
> migrate_tasks() (and keep the update_rq_clock() bit) we need to
> restore the old rq_flags before repinning.
> 
> Note that it wouldn't be correct to change move_queued_task() to
> repin
> because of the change of runqueue and the fact that having an
> up-to-date clock on the initial rq doesn't mean the new rq has one
> too.
> 
> Signed-off-by: Matt Fleming 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/core.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f983e83a353..3b248b03ad8f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5608,7 +5608,7 @@ static void migrate_tasks(struct rq *dead_rq)
>  {
>   struct rq *rq = dead_rq;
>   struct task_struct *next, *stop = rq->stop;
> - struct rq_flags rf;
> + struct rq_flags rf, old_rf;
>   int dest_cpu;
>  
>   /*
> @@ -5669,6 +5669,13 @@ static void migrate_tasks(struct rq *dead_rq)
>   continue;
>   }
>  
> + /*
> +  * __migrate_task() may return with a different
> +  * rq->lock held and a new cookie in 'rf', but we
> need
> +  * to preserve rf::clock_update_flags for 'dead_rq'.
> +  */
> + old_rf = rf;
> +
>   /* Find suitable destination for @next, with force
> if needed. */
>   dest_cpu = select_fallback_rq(dead_rq->cpu, next);
>  
> @@ -5677,6 +5684,7 @@ static void migrate_tasks(struct rq *dead_rq)
>   raw_spin_unlock(>lock);
>   rq = dead_rq;
>   raw_spin_lock(>lock);
> + rf = old_rf;
>   }
>   raw_spin_unlock(>pi_lock);
>   }

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

[Mike Galbraith]

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote:
> On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote:
> > Running Steven's hotplug stress script in tip.today.  Config is
> > NOPREEMPT, tune for maximum build time (enterprise default-ish).
> > 
> > [   75.268049] x86: Booting SMP configuration:
> > [   75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > [   75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4
> > [   75.294617] smpboot: Booting Node 0 Processor 4 APIC 0x1
> > [   75.310698] smpboot: Booting Node 0 Processor 5 APIC 0x3
> > [   75.359056] smpboot: CPU 3 is now offline
> > [   75.415505] smpboot: CPU 4 is now offline
> > [   75.479985] smpboot: CPU 5 is now offline
> > [   75.550674] [ cut here ]
> > [   75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> > assert_clock_updated.isra.62.part.63+0x25/0x27
> > [   75.550679] rq->clock_update_flags < RQCF_ACT_SKIP
> 
> The following patch queued in tip/sched/core should fix this issue:

Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
an early boot brick problem.

> >8
> 
> From 4d25b35ea3729affd37d69c78191ce6f92766e1a Mon Sep 17 00:00:00
> 2001
> From: Matt Fleming 
> Date: Wed, 26 Oct 2016 16:15:44 +0100
> Subject: [PATCH] sched/fair: Restore previous rq_flags when migrating
> tasks in
>  hotplug
> 
> __migrate_task() can return with a different runqueue locked than the
> one we passed as an argument. So that we can repin the lock in
> migrate_tasks() (and keep the update_rq_clock() bit) we need to
> restore the old rq_flags before repinning.
> 
> Note that it wouldn't be correct to change move_queued_task() to
> repin
> because of the change of runqueue and the fact that having an
> up-to-date clock on the initial rq doesn't mean the new rq has one
> too.
> 
> Signed-off-by: Matt Fleming 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/core.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f983e83a353..3b248b03ad8f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5608,7 +5608,7 @@ static void migrate_tasks(struct rq *dead_rq)
>  {
>   struct rq *rq = dead_rq;
>   struct task_struct *next, *stop = rq->stop;
> - struct rq_flags rf;
> + struct rq_flags rf, old_rf;
>   int dest_cpu;
>  
>   /*
> @@ -5669,6 +5669,13 @@ static void migrate_tasks(struct rq *dead_rq)
>   continue;
>   }
>  
> + /*
> +  * __migrate_task() may return with a different
> +  * rq->lock held and a new cookie in 'rf', but we
> need
> +  * to preserve rf::clock_update_flags for 'dead_rq'.
> +  */
> + old_rf = rf;
> +
>   /* Find suitable destination for @next, with force
> if needed. */
>   dest_cpu = select_fallback_rq(dead_rq->cpu, next);
>  
> @@ -5677,6 +5684,7 @@ static void migrate_tasks(struct rq *dead_rq)
>   raw_spin_unlock(>lock);
>   rq = dead_rq;
>   raw_spin_lock(>lock);
> + rf = old_rf;
>   }
>   raw_spin_unlock(>pi_lock);
>   }

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

[Bjorn Andersson]

On Mon 30 Jan 14:01 PST 2017, Bjorn Andersson wrote:

> On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote:
> 
> > The "remoteproc{0,1...}" sysfs entries are added in
> > rproc_add() and deleted in rproc_type_release() instead of
> > in rproc_del(). That leaves these lingering entries sticking
> > around after we return from rproc_del(). Move the
> > rproc_delete_debug_dir() to rproc_del() to fix this.
> > 
> > Signed-off-by: Sarangdhar Joshi 
> 
> I moved the rproc_delete_debug_dir() below the list_del() region to
> allow reuse of the critical region in the upcoming "deleted" patch.
> 

Never mind, I failed at reading. I re-applied this as is.

Regards,
Bjorn

> Applied, thank you.
> 
> Regards,
> Bjorn
> 
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index 953ee29..78200a7 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1315,8 +1315,6 @@ static void rproc_type_release(struct device *dev)
> >  
> > dev_info(>dev, "releasing %s\n", rproc->name);
> >  
> > -   rproc_delete_debug_dir(rproc);
> > -
> > idr_destroy(>notifyids);
> >  
> > if (rproc->index >= 0)
> > @@ -1491,6 +1489,8 @@ int rproc_del(struct rproc *rproc)
> > if (rproc->auto_boot)
> > rproc_shutdown(rproc);
> >  
> > +   rproc_delete_debug_dir(rproc);
> > +
> > /* the rproc is downref'ed as soon as it's removed from the klist */
> > mutex_lock(_list_mutex);
> > list_del(>node);
> > -- 
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> > 

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

[Bjorn Andersson]

On Mon 30 Jan 14:01 PST 2017, Bjorn Andersson wrote:

> On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote:
> 
> > The "remoteproc{0,1...}" sysfs entries are added in
> > rproc_add() and deleted in rproc_type_release() instead of
> > in rproc_del(). That leaves these lingering entries sticking
> > around after we return from rproc_del(). Move the
> > rproc_delete_debug_dir() to rproc_del() to fix this.
> > 
> > Signed-off-by: Sarangdhar Joshi 
> 
> I moved the rproc_delete_debug_dir() below the list_del() region to
> allow reuse of the critical region in the upcoming "deleted" patch.
> 

Never mind, I failed at reading. I re-applied this as is.

Regards,
Bjorn

> Applied, thank you.
> 
> Regards,
> Bjorn
> 
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index 953ee29..78200a7 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1315,8 +1315,6 @@ static void rproc_type_release(struct device *dev)
> >  
> > dev_info(>dev, "releasing %s\n", rproc->name);
> >  
> > -   rproc_delete_debug_dir(rproc);
> > -
> > idr_destroy(>notifyids);
> >  
> > if (rproc->index >= 0)
> > @@ -1491,6 +1489,8 @@ int rproc_del(struct rproc *rproc)
> > if (rproc->auto_boot)
> > rproc_shutdown(rproc);
> >  
> > +   rproc_delete_debug_dir(rproc);
> > +
> > /* the rproc is downref'ed as soon as it's removed from the klist */
> > mutex_lock(_list_mutex);
> > list_del(>node);
> > -- 
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> > 

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

[Neftin, Sasha]

On 1/26/2017 23:19, Philippe Reynes wrote:

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
  drivers/net/ethernet/intel/e1000e/ethtool.c |   91 ++
  1 files changed, 49 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 7aff68a..3768a5c 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -117,15 +117,15 @@ struct e1000_stats {
  
  #define E1000_TEST_LEN ARRAY_SIZE(e1000_gstrings_test)
  
-static int e1000_get_settings(struct net_device *netdev,

- struct ethtool_cmd *ecmd)
+static int e1000_get_link_ksettings(struct net_device *netdev,
+   struct ethtool_link_ksettings *cmd)
  {
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = >hw;
-   u32 speed;
+   u32 speed, supported, advertising;
  
  	if (hw->phy.media_type == e1000_media_type_copper) {

-   ecmd->supported = (SUPPORTED_10baseT_Half |
+   supported = (SUPPORTED_10baseT_Half |
   SUPPORTED_10baseT_Full |
   SUPPORTED_100baseT_Half |
   SUPPORTED_100baseT_Full |
@@ -133,39 +133,36 @@ static int e1000_get_settings(struct net_device *netdev,
   SUPPORTED_Autoneg |
   SUPPORTED_TP);
if (hw->phy.type == e1000_phy_ife)
-   ecmd->supported &= ~SUPPORTED_1000baseT_Full;
-   ecmd->advertising = ADVERTISED_TP;
+   supported &= ~SUPPORTED_1000baseT_Full;
+   advertising = ADVERTISED_TP;
  
  		if (hw->mac.autoneg == 1) {

-   ecmd->advertising |= ADVERTISED_Autoneg;
+   advertising |= ADVERTISED_Autoneg;
/* the e1000 autoneg seems to match ethtool nicely */
-   ecmd->advertising |= hw->phy.autoneg_advertised;
+   advertising |= hw->phy.autoneg_advertised;
}
  
-		ecmd->port = PORT_TP;

-   ecmd->phy_address = hw->phy.addr;
-   ecmd->transceiver = XCVR_INTERNAL;
-
+   cmd->base.port = PORT_TP;
+   cmd->base.phy_address = hw->phy.addr;
} else {
-   ecmd->supported   = (SUPPORTED_1000baseT_Full |
+   supported   = (SUPPORTED_1000baseT_Full |
 SUPPORTED_FIBRE |
 SUPPORTED_Autoneg);
  
-		ecmd->advertising = (ADVERTISED_1000baseT_Full |

+   advertising = (ADVERTISED_1000baseT_Full |
 ADVERTISED_FIBRE |
 ADVERTISED_Autoneg);
  
-		ecmd->port = PORT_FIBRE;

-   ecmd->transceiver = XCVR_EXTERNAL;
+   cmd->base.port = PORT_FIBRE;
}
  
  	speed = SPEED_UNKNOWN;

-   ecmd->duplex = DUPLEX_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
  
  	if (netif_running(netdev)) {

if (netif_carrier_ok(netdev)) {
speed = adapter->link_speed;
-   ecmd->duplex = adapter->link_duplex - 1;
+   cmd->base.duplex = adapter->link_duplex - 1;
}
} else if (!pm_runtime_suspended(netdev->dev.parent)) {
u32 status = er32(STATUS);
@@ -179,30 +176,36 @@ static int e1000_get_settings(struct net_device *netdev,
speed = SPEED_10;
  
  			if (status & E1000_STATUS_FD)

-   ecmd->duplex = DUPLEX_FULL;
+   cmd->base.duplex = DUPLEX_FULL;
else
-   ecmd->duplex = DUPLEX_HALF;
+   cmd->base.duplex = DUPLEX_HALF;
}
}
  
-	ethtool_cmd_speed_set(ecmd, speed);

-   ecmd->autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
+   cmd->base.speed = speed;
+   cmd->base.autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
 hw->mac.autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
  
  	/* MDI-X => 2; MDI =>1; Invalid =>0 */

if ((hw->phy.media_type == e1000_media_type_copper) &&
netif_carrier_ok(netdev))
-   ecmd->eth_tp_mdix = hw->phy.is_mdix ? ETH_TP_MDI_X : ETH_TP_MDI;
+   cmd->base.eth_tp_mdix = hw->phy.is_mdix ?
+   ETH_TP_MDI_X : ETH_TP_MDI;
else
-   ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+   cmd->base.eth_tp_mdix = ETH_TP_MDI_INVALID;
  
 

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

[Neftin, Sasha]

On 1/26/2017 23:19, Philippe Reynes wrote:

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
  drivers/net/ethernet/intel/e1000e/ethtool.c |   91 ++
  1 files changed, 49 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 7aff68a..3768a5c 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -117,15 +117,15 @@ struct e1000_stats {
  
  #define E1000_TEST_LEN ARRAY_SIZE(e1000_gstrings_test)
  
-static int e1000_get_settings(struct net_device *netdev,

- struct ethtool_cmd *ecmd)
+static int e1000_get_link_ksettings(struct net_device *netdev,
+   struct ethtool_link_ksettings *cmd)
  {
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = >hw;
-   u32 speed;
+   u32 speed, supported, advertising;
  
  	if (hw->phy.media_type == e1000_media_type_copper) {

-   ecmd->supported = (SUPPORTED_10baseT_Half |
+   supported = (SUPPORTED_10baseT_Half |
   SUPPORTED_10baseT_Full |
   SUPPORTED_100baseT_Half |
   SUPPORTED_100baseT_Full |
@@ -133,39 +133,36 @@ static int e1000_get_settings(struct net_device *netdev,
   SUPPORTED_Autoneg |
   SUPPORTED_TP);
if (hw->phy.type == e1000_phy_ife)
-   ecmd->supported &= ~SUPPORTED_1000baseT_Full;
-   ecmd->advertising = ADVERTISED_TP;
+   supported &= ~SUPPORTED_1000baseT_Full;
+   advertising = ADVERTISED_TP;
  
  		if (hw->mac.autoneg == 1) {

-   ecmd->advertising |= ADVERTISED_Autoneg;
+   advertising |= ADVERTISED_Autoneg;
/* the e1000 autoneg seems to match ethtool nicely */
-   ecmd->advertising |= hw->phy.autoneg_advertised;
+   advertising |= hw->phy.autoneg_advertised;
}
  
-		ecmd->port = PORT_TP;

-   ecmd->phy_address = hw->phy.addr;
-   ecmd->transceiver = XCVR_INTERNAL;
-
+   cmd->base.port = PORT_TP;
+   cmd->base.phy_address = hw->phy.addr;
} else {
-   ecmd->supported   = (SUPPORTED_1000baseT_Full |
+   supported   = (SUPPORTED_1000baseT_Full |
 SUPPORTED_FIBRE |
 SUPPORTED_Autoneg);
  
-		ecmd->advertising = (ADVERTISED_1000baseT_Full |

+   advertising = (ADVERTISED_1000baseT_Full |
 ADVERTISED_FIBRE |
 ADVERTISED_Autoneg);
  
-		ecmd->port = PORT_FIBRE;

-   ecmd->transceiver = XCVR_EXTERNAL;
+   cmd->base.port = PORT_FIBRE;
}
  
  	speed = SPEED_UNKNOWN;

-   ecmd->duplex = DUPLEX_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
  
  	if (netif_running(netdev)) {

if (netif_carrier_ok(netdev)) {
speed = adapter->link_speed;
-   ecmd->duplex = adapter->link_duplex - 1;
+   cmd->base.duplex = adapter->link_duplex - 1;
}
} else if (!pm_runtime_suspended(netdev->dev.parent)) {
u32 status = er32(STATUS);
@@ -179,30 +176,36 @@ static int e1000_get_settings(struct net_device *netdev,
speed = SPEED_10;
  
  			if (status & E1000_STATUS_FD)

-   ecmd->duplex = DUPLEX_FULL;
+   cmd->base.duplex = DUPLEX_FULL;
else
-   ecmd->duplex = DUPLEX_HALF;
+   cmd->base.duplex = DUPLEX_HALF;
}
}
  
-	ethtool_cmd_speed_set(ecmd, speed);

-   ecmd->autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
+   cmd->base.speed = speed;
+   cmd->base.autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
 hw->mac.autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
  
  	/* MDI-X => 2; MDI =>1; Invalid =>0 */

if ((hw->phy.media_type == e1000_media_type_copper) &&
netif_carrier_ok(netdev))
-   ecmd->eth_tp_mdix = hw->phy.is_mdix ? ETH_TP_MDI_X : ETH_TP_MDI;
+   cmd->base.eth_tp_mdix = hw->phy.is_mdix ?
+   ETH_TP_MDI_X : ETH_TP_MDI;
else
-   ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+   cmd->base.eth_tp_mdix = ETH_TP_MDI_INVALID;
  
  	if (hw->phy.mdix 

Re: [RFC V2 00/12] Define coherent device memory node

[Jerome Glisse]

On Tue, Jan 31, 2017 at 11:18:49AM +0530, Anshuman Khandual wrote:
> Hello Dave/Jerome/Mel,
> 
> Here is the overall layout of the functions I am trying to put together
> through this patch series.
> 
> (1) Define CDM from core VM and kernel perspective
> 
> (2) Isolation/Special consideration for HugeTLB allocations
> 
> (3) Isolation/Special consideration for buddy allocations
> 
>   (a) Zonelist modification based isolation (proposed)
>   (b) Cpuset modification based isolation   (proposed)
>   (c) Buddy modification based isolation(working)
> 
> (4) Define VMA containing CDM memory with a new flag VM_CDM
> 
> (5) Special consideration for VM_CDM marked VMAs
> 
>   (a) Special consideration for auto NUMA
>   (b) Special consideration for KSM

I believe (5) should not be done on per vma basis but on a page basis.
Thus rendering (4) pointless. A vma shouldn't be special because it has
some special kind of memory irespective of what the vma points to.


> Is there are any other area which needs to be taken care of before CDM
> node can be represented completely inside the kernel ?

Maybe thing like swap or suspend and resume (i know you are targetting big
computer and not laptop :)) but you can't presume what platform CDM might
be use latter on.

Also userspace might be confuse by looking a /proc/meminfo or any of the
sysfs file and see all this device memory without understanding that it
is special and might be unwise to be use for regular CPU only task.

I would probably want CDM memory be reported separatly from the rest of
memory. Which also most likely have repercution with memory cgroup.

My expectation is that you only want to use device memory in a process
if and only if that process also use the device to some extent. So
having new group hierarchy for this memory is probably a better path
forward.


Cheers,
Jérôme

Re: [RFC V2 00/12] Define coherent device memory node

[Jerome Glisse]

On Tue, Jan 31, 2017 at 11:18:49AM +0530, Anshuman Khandual wrote:
> Hello Dave/Jerome/Mel,
> 
> Here is the overall layout of the functions I am trying to put together
> through this patch series.
> 
> (1) Define CDM from core VM and kernel perspective
> 
> (2) Isolation/Special consideration for HugeTLB allocations
> 
> (3) Isolation/Special consideration for buddy allocations
> 
>   (a) Zonelist modification based isolation (proposed)
>   (b) Cpuset modification based isolation   (proposed)
>   (c) Buddy modification based isolation(working)
> 
> (4) Define VMA containing CDM memory with a new flag VM_CDM
> 
> (5) Special consideration for VM_CDM marked VMAs
> 
>   (a) Special consideration for auto NUMA
>   (b) Special consideration for KSM

I believe (5) should not be done on per vma basis but on a page basis.
Thus rendering (4) pointless. A vma shouldn't be special because it has
some special kind of memory irespective of what the vma points to.


> Is there are any other area which needs to be taken care of before CDM
> node can be represented completely inside the kernel ?

Maybe thing like swap or suspend and resume (i know you are targetting big
computer and not laptop :)) but you can't presume what platform CDM might
be use latter on.

Also userspace might be confuse by looking a /proc/meminfo or any of the
sysfs file and see all this device memory without understanding that it
is special and might be unwise to be use for regular CPU only task.

I would probably want CDM memory be reported separatly from the rest of
memory. Which also most likely have repercution with memory cgroup.

My expectation is that you only want to use device memory in a process
if and only if that process also use the device to some extent. So
having new group hierarchy for this memory is probably a better path
forward.


Cheers,
Jérôme

Re: [PATCH v2 14/25] ARM: dts: sun8i: sina33: enable ACIN power supply subnode

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 4:54 PM, Quentin Schulz
 wrote:
> The Sinlinx SinA33 has an AXP223 PMIC and an ACIN connector, thus, we
> enable the ACIN power supply in its Device Tree.
>
> Signed-off-by: Quentin Schulz 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v2 14/25] ARM: dts: sun8i: sina33: enable ACIN power supply subnode

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 4:54 PM, Quentin Schulz
 wrote:
> The Sinlinx SinA33 has an AXP223 PMIC and an ACIN connector, thus, we
> enable the ACIN power supply in its Device Tree.
>
> Signed-off-by: Quentin Schulz 

Acked-by: Chen-Yu Tsai 

Re: [RFC V2 08/12] mm: Add new VMA flag VM_CDM

[Jerome Glisse]

On Tue, Jan 31, 2017 at 09:52:20AM +0530, Anshuman Khandual wrote:
> On 01/31/2017 12:22 AM, Jerome Glisse wrote:
> > On Mon, Jan 30, 2017 at 09:05:49AM +0530, Anshuman Khandual wrote:
> >> VMA which contains CDM memory pages should be marked with new VM_CDM flag.
> >> These VMAs need to be identified in various core kernel paths for special
> >> handling and this flag will help in their identification.
> >>
> >> Signed-off-by: Anshuman Khandual 
> > 
> > 
> > Why doing this on vma basis ? Why not special casing all those path on page
> > basis ?
> 
> The primary motivation being the cost. Wont it be too expensive to account
> for and act on individual pages rather than on the VMA as a whole ? For
> example page_to_nid() seemed pretty expensive when tried to tag VMA on
> individual page fault basis.

No i don't think it would be too expensive. What is confusing in this patchset
is that you are conflating 3 different problems. First one is how to create
struct page for coherent device memory and exclude those pages from regular
allocations.

Second one is how to allow userspace to set allocation policy that would direct
allocation for a given vma to use a specific device memory.

Finaly last one is how to block some kernel feature such as numa or ksm as you
expect (and i share that believe) that they will be hurtfull.

I do believe, that this last requirement, is better left to be done on a per 
page
basis as page_to_nid() is only a memory lookup and i would be stun if that 
memory
lookup register as more than a blip on any profiler radar.

The vma flag as all or nothing choice is bad in my view and its stickyness and 
how
to handle its lifetime and inheritance is troubling and hard. Checking through 
node
if a page should undergo ksm or numa is a better solution in my view.

> 
> > 
> > After all you can have a big vma with some pages in it being cdm and other
> > being regular page. The CPU process might migrate to different CPU in a
> > different node and you might still want to have the regular page to migrate
> > to this new node and keep the cdm page while the device is still working
> > on them.
> 
> Right, that is the ideal thing to do. But wont it be better to split the
> big VMA into smaller chunks and tag them appropriately so that those VMAs
> tagged would contain as much CDM pages as possible for them to be likely
> restricted from auto NUMA, KSM etc.

Think a vma in which every odd 4k address point to a device page is device and
even 4k address point to a regular page, would you want to create as many vma
for this ?

Setting policy for allocation make sense, but setting flag that enable/disable
kernel feature for a range, overridding other policy is bad in my view.

> 
> > 
> > This is just an example, same can apply for ksm or any other kernel feature
> > you want to special case. Maybe we can store a set of flag in node that
> > tells what is allowed for page in node (ksm, hugetlb, migrate, numa, ...).
> > 
> > This would be more flexible and the policy choice can be left to each of
> > the device driver.
> 
> Hmm, thats another way of doing the special cases. The other way as Dave
> had mentioned before is to classify coherent memory property into various
> kinds and store them for each node and implement a predefined set of
> restrictions for each kind of coherent memory which might include features
> like auto NUMA, HugeTLB, KSM etc. Maintaining two different property sets
> one for the kind of coherent memory and the other being for each special
> cases) wont be too complicated ?

I am not sure i follow, you have a single mask provided by the driver that
register the memory something like:

CDM_ALLOW_NUMA (1 << 0)
CDM_ALLOW_KSM  (1 << 1)
...

Then you have bool page_node_allow_numa(page), bool page_node_allow_ksm(page),
... that is it. Both numa and ksm perform heavy operations and having to go
check a mask inside node struct isn't gonna slow them down.

I am not talking about kind matching to sets of restriction. Just a simple
mask of thing that allowed on that memory. You can add thing like GUP or any
other mechanism that i can't think of right now.

I really think that the vma flag is a bad idea, my expectation is that we
will see more vma with a mix of device and regular memory. I don't think the
only workload will be some big vma device only (ie only access by device) or
CPU only. I believe we will see everything on the spectrum from highly
fragmented to completetly regular.

Cheers,
Jérôme

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Dwivedi, Avaneesh Kumar (avani)]

On 1/31/2017 3:16 AM, Bjorn Andersson wrote:

On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote:


This patch add additional clock and regulator resource which are
initialized based on compatible and has no impact on existing driver
working. This resourse addition enable the existing driver to handle.
low pass sensor processor device also.

Signed-off-by: Avaneesh Kumar Dwivedi 

Applied, with below modification.

Thanks Bjorn, but please look below inline comment.

---
  drivers/remoteproc/qcom_adsp_pil.c | 43 +++---
  1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c

[..]

  static int adsp_init_regulator(struct qcom_adsp *adsp)
  {
-   adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
+   adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");

We should not change the name of devicetree properties, so I dropped
"vdd_" on both of these.
I observed that giving "cx" or "px" string to devm_regulator_get() was 
returning with dummy regulator, and if i gave "vdd_cx" and "vdd_px" it 
did not print dummy regulator warning.
in device tree these regulators node were defined as "vdd_cx-supply" and 
"vdd_px-supply"



if (IS_ERR(adsp->cx_supply))
return PTR_ERR(adsp->cx_supply);
  
  	regulator_set_load(adsp->cx_supply, 10);
  
+	adsp->px_supply = devm_regulator_get(adsp->dev, "vdd_px");

+   if (IS_ERR(adsp->px_supply))
+   return PTR_ERR(adsp->px_supply);

Regards,
Bjorn


--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [RFC V2 08/12] mm: Add new VMA flag VM_CDM

[Jerome Glisse]

On Tue, Jan 31, 2017 at 09:52:20AM +0530, Anshuman Khandual wrote:
> On 01/31/2017 12:22 AM, Jerome Glisse wrote:
> > On Mon, Jan 30, 2017 at 09:05:49AM +0530, Anshuman Khandual wrote:
> >> VMA which contains CDM memory pages should be marked with new VM_CDM flag.
> >> These VMAs need to be identified in various core kernel paths for special
> >> handling and this flag will help in their identification.
> >>
> >> Signed-off-by: Anshuman Khandual 
> > 
> > 
> > Why doing this on vma basis ? Why not special casing all those path on page
> > basis ?
> 
> The primary motivation being the cost. Wont it be too expensive to account
> for and act on individual pages rather than on the VMA as a whole ? For
> example page_to_nid() seemed pretty expensive when tried to tag VMA on
> individual page fault basis.

No i don't think it would be too expensive. What is confusing in this patchset
is that you are conflating 3 different problems. First one is how to create
struct page for coherent device memory and exclude those pages from regular
allocations.

Second one is how to allow userspace to set allocation policy that would direct
allocation for a given vma to use a specific device memory.

Finaly last one is how to block some kernel feature such as numa or ksm as you
expect (and i share that believe) that they will be hurtfull.

I do believe, that this last requirement, is better left to be done on a per 
page
basis as page_to_nid() is only a memory lookup and i would be stun if that 
memory
lookup register as more than a blip on any profiler radar.

The vma flag as all or nothing choice is bad in my view and its stickyness and 
how
to handle its lifetime and inheritance is troubling and hard. Checking through 
node
if a page should undergo ksm or numa is a better solution in my view.

> 
> > 
> > After all you can have a big vma with some pages in it being cdm and other
> > being regular page. The CPU process might migrate to different CPU in a
> > different node and you might still want to have the regular page to migrate
> > to this new node and keep the cdm page while the device is still working
> > on them.
> 
> Right, that is the ideal thing to do. But wont it be better to split the
> big VMA into smaller chunks and tag them appropriately so that those VMAs
> tagged would contain as much CDM pages as possible for them to be likely
> restricted from auto NUMA, KSM etc.

Think a vma in which every odd 4k address point to a device page is device and
even 4k address point to a regular page, would you want to create as many vma
for this ?

Setting policy for allocation make sense, but setting flag that enable/disable
kernel feature for a range, overridding other policy is bad in my view.

> 
> > 
> > This is just an example, same can apply for ksm or any other kernel feature
> > you want to special case. Maybe we can store a set of flag in node that
> > tells what is allowed for page in node (ksm, hugetlb, migrate, numa, ...).
> > 
> > This would be more flexible and the policy choice can be left to each of
> > the device driver.
> 
> Hmm, thats another way of doing the special cases. The other way as Dave
> had mentioned before is to classify coherent memory property into various
> kinds and store them for each node and implement a predefined set of
> restrictions for each kind of coherent memory which might include features
> like auto NUMA, HugeTLB, KSM etc. Maintaining two different property sets
> one for the kind of coherent memory and the other being for each special
> cases) wont be too complicated ?

I am not sure i follow, you have a single mask provided by the driver that
register the memory something like:

CDM_ALLOW_NUMA (1 << 0)
CDM_ALLOW_KSM  (1 << 1)
...

Then you have bool page_node_allow_numa(page), bool page_node_allow_ksm(page),
... that is it. Both numa and ksm perform heavy operations and having to go
check a mask inside node struct isn't gonna slow them down.

I am not talking about kind matching to sets of restriction. Just a simple
mask of thing that allowed on that memory. You can add thing like GUP or any
other mechanism that i can't think of right now.

I really think that the vma flag is a bad idea, my expectation is that we
will see more vma with a mix of device and regular memory. I don't think the
only workload will be some big vma device only (ie only access by device) or
CPU only. I believe we will see everything on the spectrum from highly
fragmented to completetly regular.

Cheers,
Jérôme

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Dwivedi, Avaneesh Kumar (avani)]

On 1/31/2017 3:16 AM, Bjorn Andersson wrote:

On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote:


This patch add additional clock and regulator resource which are
initialized based on compatible and has no impact on existing driver
working. This resourse addition enable the existing driver to handle.
low pass sensor processor device also.

Signed-off-by: Avaneesh Kumar Dwivedi 

Applied, with below modification.

Thanks Bjorn, but please look below inline comment.

---
  drivers/remoteproc/qcom_adsp_pil.c | 43 +++---
  1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
b/drivers/remoteproc/qcom_adsp_pil.c

[..]

  static int adsp_init_regulator(struct qcom_adsp *adsp)
  {
-   adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
+   adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");

We should not change the name of devicetree properties, so I dropped
"vdd_" on both of these.
I observed that giving "cx" or "px" string to devm_regulator_get() was 
returning with dummy regulator, and if i gave "vdd_cx" and "vdd_px" it 
did not print dummy regulator warning.
in device tree these regulators node were defined as "vdd_cx-supply" and 
"vdd_px-supply"



if (IS_ERR(adsp->cx_supply))
return PTR_ERR(adsp->cx_supply);
  
  	regulator_set_load(adsp->cx_supply, 10);
  
+	adsp->px_supply = devm_regulator_get(adsp->dev, "vdd_px");

+   if (IS_ERR(adsp->px_supply))
+   return PTR_ERR(adsp->px_supply);

Regards,
Bjorn


--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Bjorn Andersson]

On Mon 30 Jan 21:58 PST 2017, Dwivedi, Avaneesh Kumar (avani) wrote:

> 
> 
> On 1/31/2017 3:16 AM, Bjorn Andersson wrote:
> > On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote:
> > 
> > > This patch add additional clock and regulator resource which are
> > > initialized based on compatible and has no impact on existing driver
> > > working. This resourse addition enable the existing driver to handle.
> > > low pass sensor processor device also.
> > > 
> > > Signed-off-by: Avaneesh Kumar Dwivedi 
> > Applied, with below modification.
> Thanks Bjorn, but please look below inline comment.
> > > ---
> > >   drivers/remoteproc/qcom_adsp_pil.c | 43 
> > > +++---
> > >   1 file changed, 36 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
> > > b/drivers/remoteproc/qcom_adsp_pil.c
> > [..]
> > >   static int adsp_init_regulator(struct qcom_adsp *adsp)
> > >   {
> > > - adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
> > > + adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");
> > We should not change the name of devicetree properties, so I dropped
> > "vdd_" on both of these.
> I observed that giving "cx" or "px" string to devm_regulator_get() was
> returning with dummy regulator, and if i gave "vdd_cx" and "vdd_px" it did
> not print dummy regulator warning.
> in device tree these regulators node were defined as "vdd_cx-supply" and
> "vdd_px-supply"

They are named "vdd_cx" and "vdd_px" in the downstream dts, I didn't
notice this originally and as we have a few other discrepancies to the
downstream binding I rather stay compatible with the existing upstream
DT binding than the downstream.

So please update your dts.


Btw, forgot to mention that aggre2 definitely is a "bus" and I think it
should be represented separately, but I figured its better to merge the
driver as is and then remove aggre2 once we have figured out how to
represent/reference it properly.

Regards,
Bjorn

Re: [PATCH v3 2/4] remoteproc: qcom: Add additional agree2_clk and px regulator resource.

[Bjorn Andersson]

On Mon 30 Jan 21:58 PST 2017, Dwivedi, Avaneesh Kumar (avani) wrote:

> 
> 
> On 1/31/2017 3:16 AM, Bjorn Andersson wrote:
> > On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote:
> > 
> > > This patch add additional clock and regulator resource which are
> > > initialized based on compatible and has no impact on existing driver
> > > working. This resourse addition enable the existing driver to handle.
> > > low pass sensor processor device also.
> > > 
> > > Signed-off-by: Avaneesh Kumar Dwivedi 
> > Applied, with below modification.
> Thanks Bjorn, but please look below inline comment.
> > > ---
> > >   drivers/remoteproc/qcom_adsp_pil.c | 43 
> > > +++---
> > >   1 file changed, 36 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.c 
> > > b/drivers/remoteproc/qcom_adsp_pil.c
> > [..]
> > >   static int adsp_init_regulator(struct qcom_adsp *adsp)
> > >   {
> > > - adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
> > > + adsp->cx_supply = devm_regulator_get(adsp->dev, "vdd_cx");
> > We should not change the name of devicetree properties, so I dropped
> > "vdd_" on both of these.
> I observed that giving "cx" or "px" string to devm_regulator_get() was
> returning with dummy regulator, and if i gave "vdd_cx" and "vdd_px" it did
> not print dummy regulator warning.
> in device tree these regulators node were defined as "vdd_cx-supply" and
> "vdd_px-supply"

They are named "vdd_cx" and "vdd_px" in the downstream dts, I didn't
notice this originally and as we have a few other discrepancies to the
downstream binding I rather stay compatible with the existing upstream
DT binding than the downstream.

So please update your dts.


Btw, forgot to mention that aggre2 definitely is a "bus" and I think it
should be represented separately, but I figured its better to merge the
driver as is and then remove aggre2 once we have figured out how to
represent/reference it properly.

Regards,
Bjorn

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

[Bjorn Andersson]

On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote:

> The "remoteproc{0,1...}" sysfs entries are added in
> rproc_add() and deleted in rproc_type_release() instead of
> in rproc_del(). That leaves these lingering entries sticking
> around after we return from rproc_del(). Move the
> rproc_delete_debug_dir() to rproc_del() to fix this.
> 
> Signed-off-by: Sarangdhar Joshi 

I moved the rproc_delete_debug_dir() below the list_del() region to
allow reuse of the critical region in the upcoming "deleted" patch.

Applied, thank you.

Regards,
Bjorn

> ---
>  drivers/remoteproc/remoteproc_core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 953ee29..78200a7 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1315,8 +1315,6 @@ static void rproc_type_release(struct device *dev)
>  
>   dev_info(>dev, "releasing %s\n", rproc->name);
>  
> - rproc_delete_debug_dir(rproc);
> -
>   idr_destroy(>notifyids);
>  
>   if (rproc->index >= 0)
> @@ -1491,6 +1489,8 @@ int rproc_del(struct rproc *rproc)
>   if (rproc->auto_boot)
>   rproc_shutdown(rproc);
>  
> + rproc_delete_debug_dir(rproc);
> +
>   /* the rproc is downref'ed as soon as it's removed from the klist */
>   mutex_lock(_list_mutex);
>   list_del(>node);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH] remoteproc: Move rproc_delete_debug_dir() to rproc_del()

[Bjorn Andersson]

On Mon 23 Jan 17:48 PST 2017, Sarangdhar Joshi wrote:

> The "remoteproc{0,1...}" sysfs entries are added in
> rproc_add() and deleted in rproc_type_release() instead of
> in rproc_del(). That leaves these lingering entries sticking
> around after we return from rproc_del(). Move the
> rproc_delete_debug_dir() to rproc_del() to fix this.
> 
> Signed-off-by: Sarangdhar Joshi 

I moved the rproc_delete_debug_dir() below the list_del() region to
allow reuse of the critical region in the upcoming "deleted" patch.

Applied, thank you.

Regards,
Bjorn

> ---
>  drivers/remoteproc/remoteproc_core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 953ee29..78200a7 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1315,8 +1315,6 @@ static void rproc_type_release(struct device *dev)
>  
>   dev_info(>dev, "releasing %s\n", rproc->name);
>  
> - rproc_delete_debug_dir(rproc);
> -
>   idr_destroy(>notifyids);
>  
>   if (rproc->index >= 0)
> @@ -1491,6 +1489,8 @@ int rproc_del(struct rproc *rproc)
>   if (rproc->auto_boot)
>   rproc_shutdown(rproc);
>  
> + rproc_delete_debug_dir(rproc);
> +
>   /* the rproc is downref'ed as soon as it's removed from the klist */
>   mutex_lock(_list_mutex);
>   list_del(>node);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>