[linux-next] RCU: dyntick_idle warnings

[Sergey Senozhatsky]

Hello Paul,

x86_64, linux-next 20161110

WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR));

[0.436242] [ cut here ]
[0.436307] WARNING: CPU: 3 PID: 0 at kernel/rcu/tree.c:380 
rcu_momentary_dyntick_idle+0xa7/0xb8
[0.436381] Modules linked in:
[0.436437] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 
4.9.0-rc4-next-20161110-dbg-1-g0d7df5d-dirty #863
[0.436513] Hardware name: SAMSUNG ELECTRONICS CO.,LTD Samsung DeskTop 
System/Samsung DeskTop System, BIOS 05CC   04/09/2010
[0.436595] Call Trace:
[0.436651]  dump_stack+0x4d/0x63
[0.436706]  __warn+0xb8/0xd3
[0.436760]  warn_slowpath_null+0x18/0x1a
[0.436815]  rcu_momentary_dyntick_idle+0xa7/0xb8
[0.436872]  rcu_note_context_switch+0x2c8/0x2d5
[0.436930]  __schedule+0x62/0x3b6
[0.436984]  schedule+0x84/0x95
[0.437038]  schedule_preempt_disabled+0x10/0x19
[0.437095]  cpu_startup_entry+0x18c/0x191
[0.437152]  start_secondary+0xef/0xf2
[0.437207]  start_cpu+0x5/0x14
[0.437263] ---[ end trace c0bbb435a1f86b8a ]---



WARN_ON_ONCE(!(atomic_read(>dynticks) & 0x1));

[0.895911] [ cut here ]
[0.895966] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree.c:1116 
rcu_nmi_exit+0x63/0x82
[0.896026] Modules linked in:^Ac
[0.896078] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.9.0-rc4-next-20161110-dbg-1-g0d7df5d-dirty #863
[0.896157] Hardware name: SAMSUNG ELECTRONICS CO.,LTD Samsung DeskTop 
System/Samsung DeskTop System, BIOS 05CC   04/09/2010
[0.896236] Call Trace:
[0.896287]  
[0.896338]  dump_stack+0x4d/0x63
[0.896390]  __warn+0xb8/0xd3
[0.896442]  warn_slowpath_null+0x18/0x1a
[0.896495]  rcu_nmi_exit+0x63/0x82
[0.896548]  do_nmi+0x2b4/0x31f
[0.896600]  end_repeat_nmi+0x1a/0x1e
[0.896652] RIP: 0010:ioread32+0xb/0x2f
[0.896705] RSP: :c90176c0 EFLAGS: 0296^Ac
[0.896762] RAX: 0004 RBX: 880132868a80 RCX: 
[0.896820] RDX: 0003 RSI: c9000100e180 RDI: c9000100e180
[0.896879] RBP: c90176c8 R08: 000a R09: b885
[0.896938] R10: c90178e8 R11: 8801330b0080 R12: fffb6f2e
[0.896996] R13: 0006 R14: 005b R15: 88013288f848
[0.897055]  ? ioread32+0xb/0x2f
[0.897107]  ? ioread32+0xb/0x2f
[0.897160]  
[0.897210]  ? nv50_i2c_bus_sense_scl+0x1f/0x24
[0.897265]  nvkm_i2c_bus_getscl+0xa/0xc
[0.897318]  sclhi+0x36/0x6a
[0.897369]  i2c_outb+0x49/0xcf
[0.897422]  try_address+0x30/0x6f
[0.897475]  bit_xfer+0x23a/0x402
[0.897527]  __i2c_transfer+0x156/0x18b
[0.897581]  i2c_transfer+0x6e/0x8c
[0.897634]  ? nvkm_fantog_create+0xcd/0xcd
[0.897688]  nvkm_i2c_bus_probe+0x141/0x200
[0.897741]  ? extdev_table+0xa7/0xc6
[0.897793]  nvkm_therm_ic_ctor+0x141/0x14f
[0.897847]  ? nvkm_therm_ic_ctor+0x141/0x14f
[0.897900]  ? nvbios_rd08+0x1a/0x30
[0.897953]  ? nvbios_therm_sensor_parse+0x97/0x1ca
[0.898008]  nvkm_therm_oneinit+0x19/0x3b
[0.898061]  nvkm_subdev_init+0x89/0x195
[0.898114]  nvkm_device_init+0x145/0x204
[0.898167]  nvkm_udevice_init+0x2f/0x4a
[0.898220]  nvkm_object_init+0x71/0x15d
[0.898273]  nvkm_ioctl_new+0x1aa/0x27a
[0.898326]  ? nvkm_client_notify+0x22/0x22
[0.898380]  ? nvkm_udevice_rd08+0x1f/0x1f
[0.898434]  nvkm_ioctl+0x174/0x1d0
[0.898487]  nvkm_client_ioctl+0xd/0xf
[0.898540]  nvif_object_ioctl+0x42/0x44
[0.898594]  nvif_object_init+0xc4/0x104
[0.898647]  nvif_device_init+0xd/0x2b
[0.898700]  nouveau_drm_load+0x269/0x89e
[0.898753]  drm_dev_register+0x7f/0xc0
[0.898806]  drm_get_pci_dev+0xf3/0x1bd
[0.898860]  nouveau_drm_probe+0x1a2/0x1c1
[0.898913]  pci_device_probe+0x7e/0xe6
[0.898966]  driver_probe_device+0x130/0x284
[0.899020]  __driver_attach+0x6a/0x8c
[0.899074]  ? driver_probe_device+0x284/0x284
[0.899128]  bus_for_each_dev+0x68/0x80
[0.899181]  driver_attach+0x19/0x1b
[0.899234]  bus_add_driver+0xe9/0x1d9
[0.899287]  driver_register+0x83/0xba
[0.899340]  ? ttm_init+0x5d/0x5d
[0.899393]  __pci_register_driver+0x47/0x49
[0.899446]  drm_pci_init+0x47/0xc8
[0.899500]  ? ttm_init+0x5d/0x5d
[0.899552]  ? set_debug_rodata+0x12/0x12
[0.899605]  nouveau_drm_init+0x1db/0x1dd
[0.899658]  do_one_initcall+0x8b/0x10e
[0.899711]  ? set_debug_rodata+0x12/0x12
[0.899765]  kernel_init_freeable+0x123/0x1ab
[0.899819]  ? rest_init+0x7d/0x7d
[0.899871]  kernel_init+0x9/0xeb
[0.899924]  ret_from_fork+0x22/0x30
[0.899977] ---[ end trace c0bbb435a1f86b8b ]---

-ss

[linux-next] RCU: dyntick_idle warnings

[Sergey Senozhatsky]

Hello Paul,

x86_64, linux-next 20161110

WARN_ON_ONCE(!(special & RCU_DYNTICK_CTRL_CTR));

[0.436242] [ cut here ]
[0.436307] WARNING: CPU: 3 PID: 0 at kernel/rcu/tree.c:380 
rcu_momentary_dyntick_idle+0xa7/0xb8
[0.436381] Modules linked in:
[0.436437] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 
4.9.0-rc4-next-20161110-dbg-1-g0d7df5d-dirty #863
[0.436513] Hardware name: SAMSUNG ELECTRONICS CO.,LTD Samsung DeskTop 
System/Samsung DeskTop System, BIOS 05CC   04/09/2010
[0.436595] Call Trace:
[0.436651]  dump_stack+0x4d/0x63
[0.436706]  __warn+0xb8/0xd3
[0.436760]  warn_slowpath_null+0x18/0x1a
[0.436815]  rcu_momentary_dyntick_idle+0xa7/0xb8
[0.436872]  rcu_note_context_switch+0x2c8/0x2d5
[0.436930]  __schedule+0x62/0x3b6
[0.436984]  schedule+0x84/0x95
[0.437038]  schedule_preempt_disabled+0x10/0x19
[0.437095]  cpu_startup_entry+0x18c/0x191
[0.437152]  start_secondary+0xef/0xf2
[0.437207]  start_cpu+0x5/0x14
[0.437263] ---[ end trace c0bbb435a1f86b8a ]---



WARN_ON_ONCE(!(atomic_read(>dynticks) & 0x1));

[0.895911] [ cut here ]
[0.895966] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree.c:1116 
rcu_nmi_exit+0x63/0x82
[0.896026] Modules linked in:^Ac
[0.896078] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.9.0-rc4-next-20161110-dbg-1-g0d7df5d-dirty #863
[0.896157] Hardware name: SAMSUNG ELECTRONICS CO.,LTD Samsung DeskTop 
System/Samsung DeskTop System, BIOS 05CC   04/09/2010
[0.896236] Call Trace:
[0.896287]  
[0.896338]  dump_stack+0x4d/0x63
[0.896390]  __warn+0xb8/0xd3
[0.896442]  warn_slowpath_null+0x18/0x1a
[0.896495]  rcu_nmi_exit+0x63/0x82
[0.896548]  do_nmi+0x2b4/0x31f
[0.896600]  end_repeat_nmi+0x1a/0x1e
[0.896652] RIP: 0010:ioread32+0xb/0x2f
[0.896705] RSP: :c90176c0 EFLAGS: 0296^Ac
[0.896762] RAX: 0004 RBX: 880132868a80 RCX: 
[0.896820] RDX: 0003 RSI: c9000100e180 RDI: c9000100e180
[0.896879] RBP: c90176c8 R08: 000a R09: b885
[0.896938] R10: c90178e8 R11: 8801330b0080 R12: fffb6f2e
[0.896996] R13: 0006 R14: 005b R15: 88013288f848
[0.897055]  ? ioread32+0xb/0x2f
[0.897107]  ? ioread32+0xb/0x2f
[0.897160]  
[0.897210]  ? nv50_i2c_bus_sense_scl+0x1f/0x24
[0.897265]  nvkm_i2c_bus_getscl+0xa/0xc
[0.897318]  sclhi+0x36/0x6a
[0.897369]  i2c_outb+0x49/0xcf
[0.897422]  try_address+0x30/0x6f
[0.897475]  bit_xfer+0x23a/0x402
[0.897527]  __i2c_transfer+0x156/0x18b
[0.897581]  i2c_transfer+0x6e/0x8c
[0.897634]  ? nvkm_fantog_create+0xcd/0xcd
[0.897688]  nvkm_i2c_bus_probe+0x141/0x200
[0.897741]  ? extdev_table+0xa7/0xc6
[0.897793]  nvkm_therm_ic_ctor+0x141/0x14f
[0.897847]  ? nvkm_therm_ic_ctor+0x141/0x14f
[0.897900]  ? nvbios_rd08+0x1a/0x30
[0.897953]  ? nvbios_therm_sensor_parse+0x97/0x1ca
[0.898008]  nvkm_therm_oneinit+0x19/0x3b
[0.898061]  nvkm_subdev_init+0x89/0x195
[0.898114]  nvkm_device_init+0x145/0x204
[0.898167]  nvkm_udevice_init+0x2f/0x4a
[0.898220]  nvkm_object_init+0x71/0x15d
[0.898273]  nvkm_ioctl_new+0x1aa/0x27a
[0.898326]  ? nvkm_client_notify+0x22/0x22
[0.898380]  ? nvkm_udevice_rd08+0x1f/0x1f
[0.898434]  nvkm_ioctl+0x174/0x1d0
[0.898487]  nvkm_client_ioctl+0xd/0xf
[0.898540]  nvif_object_ioctl+0x42/0x44
[0.898594]  nvif_object_init+0xc4/0x104
[0.898647]  nvif_device_init+0xd/0x2b
[0.898700]  nouveau_drm_load+0x269/0x89e
[0.898753]  drm_dev_register+0x7f/0xc0
[0.898806]  drm_get_pci_dev+0xf3/0x1bd
[0.898860]  nouveau_drm_probe+0x1a2/0x1c1
[0.898913]  pci_device_probe+0x7e/0xe6
[0.898966]  driver_probe_device+0x130/0x284
[0.899020]  __driver_attach+0x6a/0x8c
[0.899074]  ? driver_probe_device+0x284/0x284
[0.899128]  bus_for_each_dev+0x68/0x80
[0.899181]  driver_attach+0x19/0x1b
[0.899234]  bus_add_driver+0xe9/0x1d9
[0.899287]  driver_register+0x83/0xba
[0.899340]  ? ttm_init+0x5d/0x5d
[0.899393]  __pci_register_driver+0x47/0x49
[0.899446]  drm_pci_init+0x47/0xc8
[0.899500]  ? ttm_init+0x5d/0x5d
[0.899552]  ? set_debug_rodata+0x12/0x12
[0.899605]  nouveau_drm_init+0x1db/0x1dd
[0.899658]  do_one_initcall+0x8b/0x10e
[0.899711]  ? set_debug_rodata+0x12/0x12
[0.899765]  kernel_init_freeable+0x123/0x1ab
[0.899819]  ? rest_init+0x7d/0x7d
[0.899871]  kernel_init+0x9/0xeb
[0.899924]  ret_from_fork+0x22/0x30
[0.899977] ---[ end trace c0bbb435a1f86b8b ]---

-ss

[PATCH v3 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

In the current code for powernv_add_idle_states, there is a lot of code
duplication while initializing an idle state in powernv_states table.

Add an inline helper function to populate the powernv_states[] table for
a given idle state. Invoke this for populating the "Nap", "Fastsleep"
and the stop states in powernv_add_idle_states.

Signed-off-by: Gautham R. Shenoy 
---
 drivers/cpuidle/cpuidle-powernv.c | 83 ++-
 include/linux/cpuidle.h   |  1 +
 2 files changed, 48 insertions(+), 36 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 7fe442c..9240e08 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -167,6 +167,24 @@ static int powernv_cpuidle_driver_init(void)
return 0;
 }
 
+static inline void add_powernv_state(int index, const char *name,
+unsigned int flags,
+int (*idle_fn)(struct cpuidle_device *,
+   struct cpuidle_driver *,
+   int),
+unsigned int target_residency,
+unsigned int exit_latency,
+u64 psscr_val)
+{
+   strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
+   strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
+   powernv_states[index].flags = flags;
+   powernv_states[index].target_residency = target_residency;
+   powernv_states[index].exit_latency = exit_latency;
+   powernv_states[index].enter = idle_fn;
+   stop_psscr_table[index] = psscr_val;
+}
+
 static int powernv_add_idle_states(void)
 {
struct device_node *power_mgt;
@@ -236,6 +254,7 @@ static int powernv_add_idle_states(void)
"ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
 
for (i = 0; i < dt_idle_states; i++) {
+   unsigned int exit_latency, target_residency;
/*
 * If an idle state has exit latency beyond
 * POWERNV_THRESHOLD_LATENCY_NS then don't use it
@@ -243,28 +262,31 @@ static int powernv_add_idle_states(void)
 */
if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
continue;
+   /*
+* Firmware passes residency and latency values in ns.
+* cpuidle expects it in us.
+*/
+   exit_latency = ((unsigned int)latency_ns[i]) / 1000;
+   target_residency = (!rc) ? ((unsigned int)residency_ns[i]) : 0;
+   target_residency /= 1000;
 
/*
-* Cpuidle accepts exit_latency and target_residency in us.
-* Use default target_residency values if f/w does not expose 
it.
+* For nap and fastsleep, use default target_residency
+* values if f/w does not expose it.
 */
if (flags[i] & OPAL_PM_NAP_ENABLED) {
+   if (!rc)
+   target_residency = 100;
/* Add NAP state */
-   strcpy(powernv_states[nr_idle_states].name, "Nap");
-   strcpy(powernv_states[nr_idle_states].desc, "Nap");
-   powernv_states[nr_idle_states].flags = 0;
-   powernv_states[nr_idle_states].target_residency = 100;
-   powernv_states[nr_idle_states].enter = nap_loop;
+   add_powernv_state(nr_idle_states, "Nap",
+ CPUIDLE_FLAG_NONE, nap_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
-   strncpy(powernv_states[nr_idle_states].name,
-   names[i], CPUIDLE_NAME_LEN);
-   strncpy(powernv_states[nr_idle_states].desc,
-   names[i], CPUIDLE_NAME_LEN);
-   powernv_states[nr_idle_states].flags = 0;
-
-   powernv_states[nr_idle_states].enter = stop_loop;
-   stop_psscr_table[nr_idle_states] = psscr_val[i];
+   add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_NONE, stop_loop,
+ target_residency, exit_latency,
+ psscr_val[i]);
}
 
/*
@@ -274,32 +296,21 @@ static int powernv_add_idle_states(void)
 #ifdef CONFIG_TICK_ONESHOT
if (flags[i] & 

[PATCH] z3fold: don't fail kernel build if z3fold_header is too big

[Vitaly Wool]

Currently the whole kernel build will be stopped if the size of
struct z3fold_header is greater than the size of one chunk, which
is 64 bytes by default. This may stand in the way of automated
test/debug builds so let's remove that and fail the z3fold
initialization in such case instead.

Signed-off-by: Vitaly Wool 
---
 mm/z3fold.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index cd3713d..5fe2652 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -866,10 +866,15 @@ MODULE_ALIAS("zpool-z3fold");
 
 static int __init init_z3fold(void)
 {
-   /* Make sure the z3fold header will fit in one chunk */
-   BUILD_BUG_ON(sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED);
-   zpool_register_driver(_zpool_driver);
+   /* Fail the initialization if z3fold header won't fit in one chunk */
+   if (sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED) {
+   pr_err("z3fold: z3fold_header size (%d) is bigger than "
+   "the chunk size (%d), can't proceed\n",
+   sizeof(struct z3fold_header) , ZHDR_SIZE_ALIGNED);
+   return -E2BIG;
+   }
 
+   zpool_register_driver(_zpool_driver);
return 0;
 }
 
-- 
2.4.2

[PATCH v3 1/3] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

Currently all the low-power idle states are expected to wake up
at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ
that puts the CPU to an idle state and never returns.

On ISA_300, when the ESL and EC bits in the PSSCR are zero, the
CPU is expected to wake up at the next instruction of the idle
instruction.

This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the
no-return variant and reuses the name IDLE_STATE_ENTER_SEQ
for a variant that allows resuming operation at the instruction next
to the idle-instruction.

Signed-off-by: Gautham R. Shenoy 
---
 arch/powerpc/include/asm/cpuidle.h   |  5 -
 arch/powerpc/kernel/exceptions-64s.S |  6 +++---
 arch/powerpc/kernel/idle_book3s.S| 10 +-
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 3919332..0a3255b 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -21,7 +21,7 @@
 
 /* Idle state entry routines */
 #ifdef CONFIG_PPC_P7_NAP
-#defineIDLE_STATE_ENTER_SEQ(IDLE_INST) \
+#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
/* Magic NAP/SLEEP/WINKLE mode enter sequence */\
std r0,0(r1);   \
ptesync;\
@@ -29,6 +29,9 @@
 1: cmpdcr0,r0,r0;  \
bne 1b; \
IDLE_INST;  \
+
+#defineIDLE_STATE_ENTER_SEQ_NORET(IDLE_INST)   \
+   IDLE_STATE_ENTER_SEQ(IDLE_INST) \
b   .
 #endif /* CONFIG_PPC_P7_NAP */
 
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 1ba82ea..7aa8afc 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -381,12 +381,12 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
lbz r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi   r3,PNV_THREAD_NAP
bgt 10f
-   IDLE_STATE_ENTER_SEQ(PPC_NAP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
 10:
cmpwi   r3,PNV_THREAD_SLEEP
bgt 2f
-   IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
/* No return */
 
 2:
@@ -400,7 +400,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
 */
ori r13,r13,1
SET_PACA(r13)
-   IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
/* No return */
 4:
 #endif
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 72dac0b..be90e2f 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -205,7 +205,7 @@ pnv_enter_arch207_idle_mode:
stb r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi   cr3,r3,PNV_THREAD_SLEEP
bge cr3,2f
-   IDLE_STATE_ENTER_SEQ(PPC_NAP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
 2:
/* Sleep or winkle */
@@ -239,7 +239,7 @@ pnv_fastsleep_workaround_at_entry:
 
 common_enter: /* common code for all the threads entering sleep or winkle */
bgt cr3,enter_winkle
-   IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
 
 fastsleep_workaround_at_entry:
ori r15,r15,PNV_CORE_IDLE_LOCK_BIT
@@ -261,7 +261,7 @@ fastsleep_workaround_at_entry:
 enter_winkle:
bl  save_sprs_to_stack
 
-   IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
 
 /*
  * r3 - requested stop state
@@ -280,7 +280,7 @@ power_enter_stop:
ld  r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpdr3,r4
bge 2f
-   IDLE_STATE_ENTER_SEQ(PPC_STOP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
 2:
 /*
  * Entering deep idle state.
@@ -302,7 +302,7 @@ lwarx_loop_stop:
 
bl  save_sprs_to_stack
 
-   IDLE_STATE_ENTER_SEQ(PPC_STOP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
 
 _GLOBAL(power7_idle)
/* Now check if user or arch enabled NAP mode */
-- 
1.9.4

[PATCH v3 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

In the current code for powernv_add_idle_states, there is a lot of code
duplication while initializing an idle state in powernv_states table.

Add an inline helper function to populate the powernv_states[] table for
a given idle state. Invoke this for populating the "Nap", "Fastsleep"
and the stop states in powernv_add_idle_states.

Signed-off-by: Gautham R. Shenoy 
---
 drivers/cpuidle/cpuidle-powernv.c | 83 ++-
 include/linux/cpuidle.h   |  1 +
 2 files changed, 48 insertions(+), 36 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 7fe442c..9240e08 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -167,6 +167,24 @@ static int powernv_cpuidle_driver_init(void)
return 0;
 }
 
+static inline void add_powernv_state(int index, const char *name,
+unsigned int flags,
+int (*idle_fn)(struct cpuidle_device *,
+   struct cpuidle_driver *,
+   int),
+unsigned int target_residency,
+unsigned int exit_latency,
+u64 psscr_val)
+{
+   strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
+   strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
+   powernv_states[index].flags = flags;
+   powernv_states[index].target_residency = target_residency;
+   powernv_states[index].exit_latency = exit_latency;
+   powernv_states[index].enter = idle_fn;
+   stop_psscr_table[index] = psscr_val;
+}
+
 static int powernv_add_idle_states(void)
 {
struct device_node *power_mgt;
@@ -236,6 +254,7 @@ static int powernv_add_idle_states(void)
"ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
 
for (i = 0; i < dt_idle_states; i++) {
+   unsigned int exit_latency, target_residency;
/*
 * If an idle state has exit latency beyond
 * POWERNV_THRESHOLD_LATENCY_NS then don't use it
@@ -243,28 +262,31 @@ static int powernv_add_idle_states(void)
 */
if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
continue;
+   /*
+* Firmware passes residency and latency values in ns.
+* cpuidle expects it in us.
+*/
+   exit_latency = ((unsigned int)latency_ns[i]) / 1000;
+   target_residency = (!rc) ? ((unsigned int)residency_ns[i]) : 0;
+   target_residency /= 1000;
 
/*
-* Cpuidle accepts exit_latency and target_residency in us.
-* Use default target_residency values if f/w does not expose 
it.
+* For nap and fastsleep, use default target_residency
+* values if f/w does not expose it.
 */
if (flags[i] & OPAL_PM_NAP_ENABLED) {
+   if (!rc)
+   target_residency = 100;
/* Add NAP state */
-   strcpy(powernv_states[nr_idle_states].name, "Nap");
-   strcpy(powernv_states[nr_idle_states].desc, "Nap");
-   powernv_states[nr_idle_states].flags = 0;
-   powernv_states[nr_idle_states].target_residency = 100;
-   powernv_states[nr_idle_states].enter = nap_loop;
+   add_powernv_state(nr_idle_states, "Nap",
+ CPUIDLE_FLAG_NONE, nap_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
-   strncpy(powernv_states[nr_idle_states].name,
-   names[i], CPUIDLE_NAME_LEN);
-   strncpy(powernv_states[nr_idle_states].desc,
-   names[i], CPUIDLE_NAME_LEN);
-   powernv_states[nr_idle_states].flags = 0;
-
-   powernv_states[nr_idle_states].enter = stop_loop;
-   stop_psscr_table[nr_idle_states] = psscr_val[i];
+   add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_NONE, stop_loop,
+ target_residency, exit_latency,
+ psscr_val[i]);
}
 
/*
@@ -274,32 +296,21 @@ static int powernv_add_idle_states(void)
 #ifdef CONFIG_TICK_ONESHOT
if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
flags[i] & 

[PATCH] z3fold: don't fail kernel build if z3fold_header is too big

[Vitaly Wool]

Currently the whole kernel build will be stopped if the size of
struct z3fold_header is greater than the size of one chunk, which
is 64 bytes by default. This may stand in the way of automated
test/debug builds so let's remove that and fail the z3fold
initialization in such case instead.

Signed-off-by: Vitaly Wool 
---
 mm/z3fold.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index cd3713d..5fe2652 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -866,10 +866,15 @@ MODULE_ALIAS("zpool-z3fold");
 
 static int __init init_z3fold(void)
 {
-   /* Make sure the z3fold header will fit in one chunk */
-   BUILD_BUG_ON(sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED);
-   zpool_register_driver(_zpool_driver);
+   /* Fail the initialization if z3fold header won't fit in one chunk */
+   if (sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED) {
+   pr_err("z3fold: z3fold_header size (%d) is bigger than "
+   "the chunk size (%d), can't proceed\n",
+   sizeof(struct z3fold_header) , ZHDR_SIZE_ALIGNED);
+   return -E2BIG;
+   }
 
+   zpool_register_driver(_zpool_driver);
return 0;
 }
 
-- 
2.4.2

[PATCH v3 1/3] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

Currently all the low-power idle states are expected to wake up
at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ
that puts the CPU to an idle state and never returns.

On ISA_300, when the ESL and EC bits in the PSSCR are zero, the
CPU is expected to wake up at the next instruction of the idle
instruction.

This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the
no-return variant and reuses the name IDLE_STATE_ENTER_SEQ
for a variant that allows resuming operation at the instruction next
to the idle-instruction.

Signed-off-by: Gautham R. Shenoy 
---
 arch/powerpc/include/asm/cpuidle.h   |  5 -
 arch/powerpc/kernel/exceptions-64s.S |  6 +++---
 arch/powerpc/kernel/idle_book3s.S| 10 +-
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 3919332..0a3255b 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -21,7 +21,7 @@
 
 /* Idle state entry routines */
 #ifdef CONFIG_PPC_P7_NAP
-#defineIDLE_STATE_ENTER_SEQ(IDLE_INST) \
+#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
/* Magic NAP/SLEEP/WINKLE mode enter sequence */\
std r0,0(r1);   \
ptesync;\
@@ -29,6 +29,9 @@
 1: cmpdcr0,r0,r0;  \
bne 1b; \
IDLE_INST;  \
+
+#defineIDLE_STATE_ENTER_SEQ_NORET(IDLE_INST)   \
+   IDLE_STATE_ENTER_SEQ(IDLE_INST) \
b   .
 #endif /* CONFIG_PPC_P7_NAP */
 
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 1ba82ea..7aa8afc 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -381,12 +381,12 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
lbz r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi   r3,PNV_THREAD_NAP
bgt 10f
-   IDLE_STATE_ENTER_SEQ(PPC_NAP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
 10:
cmpwi   r3,PNV_THREAD_SLEEP
bgt 2f
-   IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
/* No return */
 
 2:
@@ -400,7 +400,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
 */
ori r13,r13,1
SET_PACA(r13)
-   IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
/* No return */
 4:
 #endif
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 72dac0b..be90e2f 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -205,7 +205,7 @@ pnv_enter_arch207_idle_mode:
stb r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi   cr3,r3,PNV_THREAD_SLEEP
bge cr3,2f
-   IDLE_STATE_ENTER_SEQ(PPC_NAP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
 2:
/* Sleep or winkle */
@@ -239,7 +239,7 @@ pnv_fastsleep_workaround_at_entry:
 
 common_enter: /* common code for all the threads entering sleep or winkle */
bgt cr3,enter_winkle
-   IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
 
 fastsleep_workaround_at_entry:
ori r15,r15,PNV_CORE_IDLE_LOCK_BIT
@@ -261,7 +261,7 @@ fastsleep_workaround_at_entry:
 enter_winkle:
bl  save_sprs_to_stack
 
-   IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
 
 /*
  * r3 - requested stop state
@@ -280,7 +280,7 @@ power_enter_stop:
ld  r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpdr3,r4
bge 2f
-   IDLE_STATE_ENTER_SEQ(PPC_STOP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
 2:
 /*
  * Entering deep idle state.
@@ -302,7 +302,7 @@ lwarx_loop_stop:
 
bl  save_sprs_to_stack
 
-   IDLE_STATE_ENTER_SEQ(PPC_STOP)
+   IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
 
 _GLOBAL(power7_idle)
/* Now check if user or arch enabled NAP mode */
-- 
1.9.4

[PATCH v3 0/3] powernv:stop: Use psscr_val,mask provided by firmware

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

This is the third iteration of the patchset to use the psscr_val and
psscr_mask provided by the firmware for each of the stop states.

The previous version can be found here:

[v2]: https://lkml.org/lkml/2016/10/27/143
[v1]: https://lkml.org/lkml/2016/9/29/45

This version fixes a couple of bugs pertaining to strncpy and
initialization of the target-residency values of nap and sleep
which were pointed out by Paul and Oliver in the earlier version.

Synopsis
==
In the current implementation, the code for ISA
v3.0 stop implementation has a couple of shortcomings.

a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and
   uses only the RL field from the firmware. While this is not
   incorrect, since the hand-coded values are legitimate, it is not a
   very flexible design since the firmware has the capability to
   communicate these values via the "ibm,cpu-idle-state-psscr" and
   "ibm,cpu-idle-state-psscr-mask" properties. In case where the
   firmware provides values for these fields that is different from
   the hand-coded values, the current code will not work as intended.

b) Due to issue a), the current code assumes that ESL=EC=1 for all the
   stop states and hence the wakeup from the stop instruction will
   happen at 0x100, the system-reset vector. However, the ISA v3.0
   allows the ESL=EC=0 behaviour where the corresponding stop-state
   loses no state and wakes up from the subsequent instruction. The
   current code doesn't handle this case.
   
This patch series addresses these issues.

The first patch in the series renames the existing
IDLE_STATE_ENTER_SEQ macro to IDLE_STATE_ENTER_SEQ_NORET. It reuses
the name IDLE_STATE_ENTER_SEQ for entering into stop-states which wake
up at the subsequent instruction.

The second patch adds a helper function in cpuidle-powernv.c for
initializing entries of the powernv_states[] table that is passed to
the cpu-idle core. This eliminates some of the code duplication in the
function that discovers and initializes the stop states.

The third patch in the series fixes issues a) and b) by ensuring that
the psscr-value and the psscr-mask provided by the firmware are what
will be used to set a particular stop state. It also adds support for
handling wake-up from stop states which were entered with ESL=EC=0.

The third patch also handles the older firmware which sets only the
Requested Level (RL) field in the psscr and psscr-mask exposed in the
device tree. In the presence of such older firmware, this patch will
set the default sane values for for remaining PSSCR fields (i.e PSLL,
MTL, ESL, EC, and TR).

The skiboot patch populates all the relevant fields in the PSSCR
values and the mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html

The patches are based on top of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes

Gautham R. Shenoy (3):
  powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
  cpuidle:powernv: Add helper function to populate powernv idle states.
  powernv: Pass PSSCR value and mask to power9_idle_stop

 arch/powerpc/include/asm/cpuidle.h   |  42 +++-
 arch/powerpc/include/asm/processor.h |   3 +-
 arch/powerpc/kernel/exceptions-64s.S |   6 +-
 arch/powerpc/kernel/idle_book3s.S|  41 +++-
 arch/powerpc/platforms/powernv/idle.c|  81 ++
 arch/powerpc/platforms/powernv/powernv.h |   3 +-
 arch/powerpc/platforms/powernv/smp.c |  14 ++--
 drivers/cpuidle/cpuidle-powernv.c| 111 +++
 include/linux/cpuidle.h  |   1 +
 9 files changed, 219 insertions(+), 83 deletions(-)

-- 
1.9.4

[PATCH v3 3/3] powernv: Pass PSSCR value and mask to power9_idle_stop

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

The power9_idle_stop method currently takes only the requested stop
level as a parameter and picks up the rest of the PSSCR bits from a
hand-coded macro. This is not a very flexible design, especially when
the firmware has the capability to communicate the psscr value and the
mask associated with a particular stop state via device tree.

This patch modifies the power9_idle_stop API to take as parameters the
PSSCR value and the PSSCR mask corresponding to the stop state that
needs to be set. These PSSCR value and mask are respectively obtained
by parsing the "ibm,cpu-idle-state-psscr" and
"ibm,cpu-idle-state-psscr-mask" fields from the device tree.

In addition to this, the patch adds support for handling stop states
for which ESL and EC bits in the PSSCR are zero. As per the
architecture, a wakeup from these stop states resumes execution from
the subsequent instruction as opposed to waking up at the System
Vector.

The older firmware sets only the Requested Level (RL) field in the
psscr and psscr-mask exposed in the device tree. For older firmware
where psscr-mask=0xf, this patch will set the default sane values that
the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
TR).

This skiboot patch that exports fully populated PSSCR values and the
mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html

Signed-off-by: Gautham R. Shenoy 
---
 arch/powerpc/include/asm/cpuidle.h   | 37 +++
 arch/powerpc/include/asm/processor.h |  3 +-
 arch/powerpc/kernel/idle_book3s.S| 31 +++-
 arch/powerpc/platforms/powernv/idle.c| 81 ++--
 arch/powerpc/platforms/powernv/powernv.h |  3 +-
 arch/powerpc/platforms/powernv/smp.c | 14 +++---
 drivers/cpuidle/cpuidle-powernv.c| 40 +++-
 7 files changed, 165 insertions(+), 44 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 0a3255b..41b5d27 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -10,11 +10,48 @@
 #define PNV_CORE_IDLE_LOCK_BIT  0x100
 #define PNV_CORE_IDLE_THREAD_BITS   0x0FF
 
+/*
+ * By default we set the ESL and EC bits in the PSSCR.
+ *
+ * The MTL and PSLL are set to the maximum value possible as per the
+ * ISA, i.e 15.
+ *
+ * The Transition Rate is set to the Maximum value 3.
+ */
+#define PSSCR_HV_DEFAULT_VAL(PSSCR_ESL | PSSCR_EC |\
+   PSSCR_PSLL_MASK | PSSCR_TR_MASK |   \
+   PSSCR_MTL_MASK)
+
+#define PSSCR_HV_DEFAULT_MASK   (PSSCR_ESL | PSSCR_EC |\
+   PSSCR_PSLL_MASK | PSSCR_TR_MASK |   \
+   PSSCR_MTL_MASK | PSSCR_RL_MASK)
+
 #ifndef __ASSEMBLY__
 extern u32 pnv_fastsleep_workaround_at_entry[];
 extern u32 pnv_fastsleep_workaround_at_exit[];
 
 extern u64 pnv_first_deep_stop_state;
+
+/*
+ * Older firmware only populates the RL field in psscr_val and
+ * psscr_mask.
+ *
+ * Set the remaining fields to the default value in case of the
+ * older firmware.
+ */
+static inline u64 compute_psscr_val(u64 psscr_val, u64 psscr_mask)
+{
+   if (psscr_mask == 0xf)
+   return psscr_val | PSSCR_HV_DEFAULT_VAL;
+   return psscr_val;
+}
+
+static inline u64 compute_psscr_mask(u64 psscr_mask)
+{
+   if (psscr_mask == 0xf)
+   return PSSCR_HV_DEFAULT_MASK;
+   return psscr_mask;
+}
 #endif
 
 #endif
diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index c07c31b..422becd 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -458,7 +458,8 @@ static inline unsigned long get_clean_sp(unsigned long sp, 
int is_32)
 extern unsigned long power7_nap(int check_irq);
 extern unsigned long power7_sleep(void);
 extern unsigned long power7_winkle(void);
-extern unsigned long power9_idle_stop(unsigned long stop_level);
+extern unsigned long power9_idle_stop(unsigned long stop_psscr_val,
+ unsigned long stop_psscr_mask);
 
 extern void flush_instruction_cache(void);
 extern void hard_reset_now(void);
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index be90e2f..37ee533 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -40,9 +40,7 @@
 #define _WORC  GPR11
 #define _PTCR  GPR12
 
-#define PSSCR_HV_TEMPLATE  PSSCR_ESL | PSSCR_EC | \
-   PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
-   PSSCR_MTL_MASK
+#define PSSCR_EC_ESL_MASK_SHIFTED  (PSSCR_EC | PSSCR_ESL) >> 16
 
.text
 
@@ -264,7 +262,7 @@ enter_winkle:
IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
 
 /*
- * r3 - requested stop state
+ 

[PATCH v3 3/3] powernv: Pass PSSCR value and mask to power9_idle_stop

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

The power9_idle_stop method currently takes only the requested stop
level as a parameter and picks up the rest of the PSSCR bits from a
hand-coded macro. This is not a very flexible design, especially when
the firmware has the capability to communicate the psscr value and the
mask associated with a particular stop state via device tree.

This patch modifies the power9_idle_stop API to take as parameters the
PSSCR value and the PSSCR mask corresponding to the stop state that
needs to be set. These PSSCR value and mask are respectively obtained
by parsing the "ibm,cpu-idle-state-psscr" and
"ibm,cpu-idle-state-psscr-mask" fields from the device tree.

In addition to this, the patch adds support for handling stop states
for which ESL and EC bits in the PSSCR are zero. As per the
architecture, a wakeup from these stop states resumes execution from
the subsequent instruction as opposed to waking up at the System
Vector.

The older firmware sets only the Requested Level (RL) field in the
psscr and psscr-mask exposed in the device tree. For older firmware
where psscr-mask=0xf, this patch will set the default sane values that
the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
TR).

This skiboot patch that exports fully populated PSSCR values and the
mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html

Signed-off-by: Gautham R. Shenoy 
---
 arch/powerpc/include/asm/cpuidle.h   | 37 +++
 arch/powerpc/include/asm/processor.h |  3 +-
 arch/powerpc/kernel/idle_book3s.S| 31 +++-
 arch/powerpc/platforms/powernv/idle.c| 81 ++--
 arch/powerpc/platforms/powernv/powernv.h |  3 +-
 arch/powerpc/platforms/powernv/smp.c | 14 +++---
 drivers/cpuidle/cpuidle-powernv.c| 40 +++-
 7 files changed, 165 insertions(+), 44 deletions(-)

diff --git a/arch/powerpc/include/asm/cpuidle.h 
b/arch/powerpc/include/asm/cpuidle.h
index 0a3255b..41b5d27 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -10,11 +10,48 @@
 #define PNV_CORE_IDLE_LOCK_BIT  0x100
 #define PNV_CORE_IDLE_THREAD_BITS   0x0FF
 
+/*
+ * By default we set the ESL and EC bits in the PSSCR.
+ *
+ * The MTL and PSLL are set to the maximum value possible as per the
+ * ISA, i.e 15.
+ *
+ * The Transition Rate is set to the Maximum value 3.
+ */
+#define PSSCR_HV_DEFAULT_VAL(PSSCR_ESL | PSSCR_EC |\
+   PSSCR_PSLL_MASK | PSSCR_TR_MASK |   \
+   PSSCR_MTL_MASK)
+
+#define PSSCR_HV_DEFAULT_MASK   (PSSCR_ESL | PSSCR_EC |\
+   PSSCR_PSLL_MASK | PSSCR_TR_MASK |   \
+   PSSCR_MTL_MASK | PSSCR_RL_MASK)
+
 #ifndef __ASSEMBLY__
 extern u32 pnv_fastsleep_workaround_at_entry[];
 extern u32 pnv_fastsleep_workaround_at_exit[];
 
 extern u64 pnv_first_deep_stop_state;
+
+/*
+ * Older firmware only populates the RL field in psscr_val and
+ * psscr_mask.
+ *
+ * Set the remaining fields to the default value in case of the
+ * older firmware.
+ */
+static inline u64 compute_psscr_val(u64 psscr_val, u64 psscr_mask)
+{
+   if (psscr_mask == 0xf)
+   return psscr_val | PSSCR_HV_DEFAULT_VAL;
+   return psscr_val;
+}
+
+static inline u64 compute_psscr_mask(u64 psscr_mask)
+{
+   if (psscr_mask == 0xf)
+   return PSSCR_HV_DEFAULT_MASK;
+   return psscr_mask;
+}
 #endif
 
 #endif
diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index c07c31b..422becd 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -458,7 +458,8 @@ static inline unsigned long get_clean_sp(unsigned long sp, 
int is_32)
 extern unsigned long power7_nap(int check_irq);
 extern unsigned long power7_sleep(void);
 extern unsigned long power7_winkle(void);
-extern unsigned long power9_idle_stop(unsigned long stop_level);
+extern unsigned long power9_idle_stop(unsigned long stop_psscr_val,
+ unsigned long stop_psscr_mask);
 
 extern void flush_instruction_cache(void);
 extern void hard_reset_now(void);
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index be90e2f..37ee533 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -40,9 +40,7 @@
 #define _WORC  GPR11
 #define _PTCR  GPR12
 
-#define PSSCR_HV_TEMPLATE  PSSCR_ESL | PSSCR_EC | \
-   PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
-   PSSCR_MTL_MASK
+#define PSSCR_EC_ESL_MASK_SHIFTED  (PSSCR_EC | PSSCR_ESL) >> 16
 
.text
 
@@ -264,7 +262,7 @@ enter_winkle:
IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
 
 /*
- * r3 - requested stop state
+ * r3 - PSSCR value corresponding to the requested 

[PATCH v3 0/3] powernv:stop: Use psscr_val,mask provided by firmware

[Gautham R. Shenoy]

From: "Gautham R. Shenoy" 

This is the third iteration of the patchset to use the psscr_val and
psscr_mask provided by the firmware for each of the stop states.

The previous version can be found here:

[v2]: https://lkml.org/lkml/2016/10/27/143
[v1]: https://lkml.org/lkml/2016/9/29/45

This version fixes a couple of bugs pertaining to strncpy and
initialization of the target-residency values of nap and sleep
which were pointed out by Paul and Oliver in the earlier version.

Synopsis
==
In the current implementation, the code for ISA
v3.0 stop implementation has a couple of shortcomings.

a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and
   uses only the RL field from the firmware. While this is not
   incorrect, since the hand-coded values are legitimate, it is not a
   very flexible design since the firmware has the capability to
   communicate these values via the "ibm,cpu-idle-state-psscr" and
   "ibm,cpu-idle-state-psscr-mask" properties. In case where the
   firmware provides values for these fields that is different from
   the hand-coded values, the current code will not work as intended.

b) Due to issue a), the current code assumes that ESL=EC=1 for all the
   stop states and hence the wakeup from the stop instruction will
   happen at 0x100, the system-reset vector. However, the ISA v3.0
   allows the ESL=EC=0 behaviour where the corresponding stop-state
   loses no state and wakes up from the subsequent instruction. The
   current code doesn't handle this case.
   
This patch series addresses these issues.

The first patch in the series renames the existing
IDLE_STATE_ENTER_SEQ macro to IDLE_STATE_ENTER_SEQ_NORET. It reuses
the name IDLE_STATE_ENTER_SEQ for entering into stop-states which wake
up at the subsequent instruction.

The second patch adds a helper function in cpuidle-powernv.c for
initializing entries of the powernv_states[] table that is passed to
the cpu-idle core. This eliminates some of the code duplication in the
function that discovers and initializes the stop states.

The third patch in the series fixes issues a) and b) by ensuring that
the psscr-value and the psscr-mask provided by the firmware are what
will be used to set a particular stop state. It also adds support for
handling wake-up from stop states which were entered with ESL=EC=0.

The third patch also handles the older firmware which sets only the
Requested Level (RL) field in the psscr and psscr-mask exposed in the
device tree. In the presence of such older firmware, this patch will
set the default sane values for for remaining PSSCR fields (i.e PSLL,
MTL, ESL, EC, and TR).

The skiboot patch populates all the relevant fields in the PSSCR
values and the mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html

The patches are based on top of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes

Gautham R. Shenoy (3):
  powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
  cpuidle:powernv: Add helper function to populate powernv idle states.
  powernv: Pass PSSCR value and mask to power9_idle_stop

 arch/powerpc/include/asm/cpuidle.h   |  42 +++-
 arch/powerpc/include/asm/processor.h |   3 +-
 arch/powerpc/kernel/exceptions-64s.S |   6 +-
 arch/powerpc/kernel/idle_book3s.S|  41 +++-
 arch/powerpc/platforms/powernv/idle.c|  81 ++
 arch/powerpc/platforms/powernv/powernv.h |   3 +-
 arch/powerpc/platforms/powernv/smp.c |  14 ++--
 drivers/cpuidle/cpuidle-powernv.c| 111 +++
 include/linux/cpuidle.h  |   1 +
 9 files changed, 219 insertions(+), 83 deletions(-)

-- 
1.9.4

[PATCH v4] z3fold: use per-page spinlock

[Vitaly Wool]

Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time.

This patch implements raw spinlock-based per-page locking mechanism
which is lightweight enough to fit nicely into the z3fold header.

Changes from v1 [1]:
- custom locking mechanism changed to spinlocks
- no read/write locks, just per-page spinlock

Changes from v2 [2]:
- if a page is taken off its list by z3fold_alloc(), bail out from
  z3fold_free() early

Changes from v3 [3]:
- spinlock changed to raw spinlock to avoid BUILD_BUG_ON trigger

[1] https://lkml.org/lkml/2016/11/5/59
[2] https://lkml.org/lkml/2016/11/8/400
[3] https://lkml.org/lkml/2016/11/9/146

Signed-off-by: Vitaly Wool 
---
 mm/z3fold.c | 137 ++--
 1 file changed, 97 insertions(+), 40 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index d85dac0..cd3713d 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -98,6 +98,7 @@ enum buddy {
  * struct z3fold_header - z3fold page metadata occupying the first chunk of 
each
  * z3fold page, except for HEADLESS pages
  * @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page lock
  * @first_chunks:  the size of the first buddy in chunks, 0 if free
  * @middle_chunks: the size of the middle buddy in chunks, 0 if free
  * @last_chunks:   the size of the last buddy in chunks, 0 if free
@@ -105,6 +106,7 @@ enum buddy {
  */
 struct z3fold_header {
struct list_head buddy;
+   raw_spinlock_t page_lock;
unsigned short first_chunks;
unsigned short middle_chunks;
unsigned short last_chunks;
@@ -144,6 +146,7 @@ static struct z3fold_header *init_z3fold_page(struct page 
*page)
clear_bit(PAGE_HEADLESS, >private);
clear_bit(MIDDLE_CHUNK_MAPPED, >private);
 
+   raw_spin_lock_init(>page_lock);
zhdr->first_chunks = 0;
zhdr->middle_chunks = 0;
zhdr->last_chunks = 0;
@@ -159,6 +162,19 @@ static void free_z3fold_page(struct z3fold_header *zhdr)
__free_page(virt_to_page(zhdr));
 }
 
+/* Lock a z3fold page */
+static inline void z3fold_page_lock(struct z3fold_header *zhdr)
+{
+   raw_spin_lock(>page_lock);
+}
+
+/* Unlock a z3fold page */
+static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
+{
+   raw_spin_unlock(>page_lock);
+}
+
+
 /*
  * Encodes the handle of a particular buddy within a z3fold page
  * Pool lock should be held as this function accesses first_num
@@ -343,50 +359,60 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
size, gfp_t gfp,
bud = HEADLESS;
else {
chunks = size_to_chunks(size);
-   spin_lock(>lock);
 
/* First, try to find an unbuddied z3fold page. */
zhdr = NULL;
for_each_unbuddied_list(i, chunks) {
-   if (!list_empty(>unbuddied[i])) {
-   zhdr = list_first_entry(>unbuddied[i],
+   spin_lock(>lock);
+   zhdr = list_first_entry_or_null(>unbuddied[i],
struct z3fold_header, buddy);
-   page = virt_to_page(zhdr);
-   if (zhdr->first_chunks == 0) {
-   if (zhdr->middle_chunks != 0 &&
-   chunks >= zhdr->start_middle)
-   bud = LAST;
-   else
-   bud = FIRST;
-   } else if (zhdr->last_chunks == 0)
+   if (!zhdr) {
+   spin_unlock(>lock);
+   continue;
+   }
+   list_del_init(>buddy);
+   spin_unlock(>lock);
+
+   page = virt_to_page(zhdr);
+   z3fold_page_lock(zhdr);
+   if (zhdr->first_chunks == 0) {
+   if (zhdr->middle_chunks != 0 &&
+   chunks >= zhdr->start_middle)
bud = LAST;
-   else if (zhdr->middle_chunks == 0)
-   bud = MIDDLE;
-   else {
-   pr_err("No free chunks in unbuddied\n");
-   WARN_ON(1);
-   continue;
-   }
-   list_del(>buddy);
-   goto found;
+   

[PATCH v4] z3fold: use per-page spinlock

[Vitaly Wool]

Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time.

This patch implements raw spinlock-based per-page locking mechanism
which is lightweight enough to fit nicely into the z3fold header.

Changes from v1 [1]:
- custom locking mechanism changed to spinlocks
- no read/write locks, just per-page spinlock

Changes from v2 [2]:
- if a page is taken off its list by z3fold_alloc(), bail out from
  z3fold_free() early

Changes from v3 [3]:
- spinlock changed to raw spinlock to avoid BUILD_BUG_ON trigger

[1] https://lkml.org/lkml/2016/11/5/59
[2] https://lkml.org/lkml/2016/11/8/400
[3] https://lkml.org/lkml/2016/11/9/146

Signed-off-by: Vitaly Wool 
---
 mm/z3fold.c | 137 ++--
 1 file changed, 97 insertions(+), 40 deletions(-)

diff --git a/mm/z3fold.c b/mm/z3fold.c
index d85dac0..cd3713d 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -98,6 +98,7 @@ enum buddy {
  * struct z3fold_header - z3fold page metadata occupying the first chunk of 
each
  * z3fold page, except for HEADLESS pages
  * @buddy: links the z3fold page into the relevant list in the pool
+ * @page_lock: per-page lock
  * @first_chunks:  the size of the first buddy in chunks, 0 if free
  * @middle_chunks: the size of the middle buddy in chunks, 0 if free
  * @last_chunks:   the size of the last buddy in chunks, 0 if free
@@ -105,6 +106,7 @@ enum buddy {
  */
 struct z3fold_header {
struct list_head buddy;
+   raw_spinlock_t page_lock;
unsigned short first_chunks;
unsigned short middle_chunks;
unsigned short last_chunks;
@@ -144,6 +146,7 @@ static struct z3fold_header *init_z3fold_page(struct page 
*page)
clear_bit(PAGE_HEADLESS, >private);
clear_bit(MIDDLE_CHUNK_MAPPED, >private);
 
+   raw_spin_lock_init(>page_lock);
zhdr->first_chunks = 0;
zhdr->middle_chunks = 0;
zhdr->last_chunks = 0;
@@ -159,6 +162,19 @@ static void free_z3fold_page(struct z3fold_header *zhdr)
__free_page(virt_to_page(zhdr));
 }
 
+/* Lock a z3fold page */
+static inline void z3fold_page_lock(struct z3fold_header *zhdr)
+{
+   raw_spin_lock(>page_lock);
+}
+
+/* Unlock a z3fold page */
+static inline void z3fold_page_unlock(struct z3fold_header *zhdr)
+{
+   raw_spin_unlock(>page_lock);
+}
+
+
 /*
  * Encodes the handle of a particular buddy within a z3fold page
  * Pool lock should be held as this function accesses first_num
@@ -343,50 +359,60 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
size, gfp_t gfp,
bud = HEADLESS;
else {
chunks = size_to_chunks(size);
-   spin_lock(>lock);
 
/* First, try to find an unbuddied z3fold page. */
zhdr = NULL;
for_each_unbuddied_list(i, chunks) {
-   if (!list_empty(>unbuddied[i])) {
-   zhdr = list_first_entry(>unbuddied[i],
+   spin_lock(>lock);
+   zhdr = list_first_entry_or_null(>unbuddied[i],
struct z3fold_header, buddy);
-   page = virt_to_page(zhdr);
-   if (zhdr->first_chunks == 0) {
-   if (zhdr->middle_chunks != 0 &&
-   chunks >= zhdr->start_middle)
-   bud = LAST;
-   else
-   bud = FIRST;
-   } else if (zhdr->last_chunks == 0)
+   if (!zhdr) {
+   spin_unlock(>lock);
+   continue;
+   }
+   list_del_init(>buddy);
+   spin_unlock(>lock);
+
+   page = virt_to_page(zhdr);
+   z3fold_page_lock(zhdr);
+   if (zhdr->first_chunks == 0) {
+   if (zhdr->middle_chunks != 0 &&
+   chunks >= zhdr->start_middle)
bud = LAST;
-   else if (zhdr->middle_chunks == 0)
-   bud = MIDDLE;
-   else {
-   pr_err("No free chunks in unbuddied\n");
-   WARN_ON(1);
-   continue;
-   }
-   list_del(>buddy);
-   goto found;
+ 

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Jacek Anaszewski]

On 11/09/2016 07:26 PM, Rob Herring wrote:

On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:

On 11/03/2016 11:10 AM, Andi Shyti wrote:

Hi Jacek,


Only DT bindings of LED class drivers should be placed in
Documentation/devicetree/bindings/leds. Please move it to the
media bindings.


that's where I placed it first, but Rob asked me to put it in the
LED directory and Cc the LED mailining list.

That's the discussion of the version 2:

https://lkml.org/lkml/2016/9/12/380

Rob, Jacek, could you please agree where I can put the binding?


I'm not sure if this is a good approach. I've noticed also that
backlight bindings have been moved to leds, whereas they don't look
similarly.

We have common.txt LED bindings, that all LED class drivers' bindings
have to follow. Neither backlight bindings nor these ones do that,
which introduces some mess.


And there are probably LED bindings that don't follow common.txt either.


Eventually adding a sub-directory, e.g. remote_control could make it
somehow logically justified, but still - shouldn't bindings be
placed in the documentation directory related to the subsystem of the
driver they are predestined to?


No. While binding directories often mirror the driver directories, they
are not the same. Bindings are grouped by types of h/w and IR LEDs are a
type of LED.

If you prefer a sub-dir, that is fine with me.


Fine. So how about sub-dir "ir" ?

--
Best regards,
Jacek Anaszewski

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Jacek Anaszewski]

On 11/09/2016 07:26 PM, Rob Herring wrote:

On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:

On 11/03/2016 11:10 AM, Andi Shyti wrote:

Hi Jacek,


Only DT bindings of LED class drivers should be placed in
Documentation/devicetree/bindings/leds. Please move it to the
media bindings.


that's where I placed it first, but Rob asked me to put it in the
LED directory and Cc the LED mailining list.

That's the discussion of the version 2:

https://lkml.org/lkml/2016/9/12/380

Rob, Jacek, could you please agree where I can put the binding?


I'm not sure if this is a good approach. I've noticed also that
backlight bindings have been moved to leds, whereas they don't look
similarly.

We have common.txt LED bindings, that all LED class drivers' bindings
have to follow. Neither backlight bindings nor these ones do that,
which introduces some mess.


And there are probably LED bindings that don't follow common.txt either.


Eventually adding a sub-directory, e.g. remote_control could make it
somehow logically justified, but still - shouldn't bindings be
placed in the documentation directory related to the subsystem of the
driver they are predestined to?


No. While binding directories often mirror the driver directories, they
are not the same. Bindings are grouped by types of h/w and IR LEDs are a
type of LED.

If you prefer a sub-dir, that is fine with me.


Fine. So how about sub-dir "ir" ?

--
Best regards,
Jacek Anaszewski

[PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation

[Peter Rosin]

The new size (0x100) also matches the size given in sama5d3.dtsi

Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].

[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16

Signed-off-by: Peter Rosin 
---
 arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi 
b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
 
uart0: serial@f0024000 {
compatible = "atmel,at91sam9260-usart";
-   reg = <0xf0024000 0x200>;
+   reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_uart0>;
@@ -66,7 +66,7 @@
 
uart1: serial@f8028000 {
compatible = "atmel,at91sam9260-usart";
-   reg = <0xf8028000 0x200>;
+   reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
-- 
2.1.4

[PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation

[Peter Rosin]

The new size (0x100) also matches the size given in sama5d3.dtsi

Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].

[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16

Signed-off-by: Peter Rosin 
---
 arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi 
b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
 
uart0: serial@f0024000 {
compatible = "atmel,at91sam9260-usart";
-   reg = <0xf0024000 0x200>;
+   reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_uart0>;
@@ -66,7 +66,7 @@
 
uart1: serial@f8028000 {
compatible = "atmel,at91sam9260-usart";
-   reg = <0xf8028000 0x200>;
+   reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
-- 
2.1.4

Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lee Jones]

On Wed, 09 Nov 2016, Lukasz Majewski wrote:

> Hi Lee,
> 
> > On Tue, 08 Nov 2016, Lukasz Majewski wrote:
> > 
> > > Dear All,
> > > 
> > > > The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> > > > properties when necessary") has posed some extra restrictions on
> > > > blanking and unblanking frame buffer device.
> > > > 
> > > > Unfortunately, pwm_bl driver's probe did not initialize members of
> > > > struct backlight_device necessary for further blank/unblank
> > > > operation.
> > > > 
> > > > This code in case of initial unblank of backlight device (default 
> > > > behaviour) sets use_count to 1 and marks this particular backlight
> > > > device as used by all available fb devices (since it is not known
> > > > during probe how much and which fb devices will be assigned).
> > > > 
> > > > Without this code, the backlight works properly until one tries to
> > > > blank it manually from sysfs with "echo 1
> > > > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > > > > were both set to 0, the logic at
> > > > fb_notifier_callback (@backlight.c) thought that we didn't turn on
> > > > (unblanked) the backlight device and refuses to disable (blank)
> > > > it. As a result we see garbage from fb displayed.
> > > 
> > > COmments/acks are more than welcome :-)
> > 
> > I thought Jingoo already replied to you?
> 
> Yes, Jingoo replied to me and asked for correcting the patch
> description. The corrected patch is the v2.

Ah, I see.  You've attached the v4 to the original set.

Ball is in Jingoo's court.

> > > > Signed-off-by: Lukasz Majewski 
> > > > ---
> > > > The patch has been tested on i.MX6q with 4.9-rc3
> > > > SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> > > > ---
> > > > Changes for v2:
> > > > - Update commit message with proper other commit reference
> > > > 
> > > > ---
> > > >  drivers/video/backlight/pwm_bl.c | 10 +-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> > > > platform_device *pdev) struct pwm_bl_data *pb;
> > > > int initial_blank = FB_BLANK_UNBLANK;
> > > > struct pwm_args pargs;
> > > > -   int ret;
> > > > +   int ret, i;
> > > >  
> > > > if (!data) {
> > > > ret = pwm_backlight_parse_dt(>dev,
> > > > ); @@ -348,6 +348,14 @@ static int
> > > > pwm_backlight_probe(struct platform_device *pdev) 
> > > > bl->props.brightness = data->dft_brightness;
> > > > bl->props.power = initial_blank;
> > > > +
> > > > +   if (initial_blank == FB_BLANK_UNBLANK) {
> > > > +   for (i = 0; i < FB_MAX; i++)
> > > > +   bl->fb_bl_on[i] = true;
> > > > +
> > > > +   bl->use_count = 1;
> > > > +   }
> > > > +
> > > > backlight_update_status(bl);
> > > >  
> > > > platform_set_drvdata(pdev, bl);
> > > 
> > 
> > 
> > 
> 



-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lee Jones]

On Wed, 09 Nov 2016, Lukasz Majewski wrote:

> Hi Lee,
> 
> > On Tue, 08 Nov 2016, Lukasz Majewski wrote:
> > 
> > > Dear All,
> > > 
> > > > The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> > > > properties when necessary") has posed some extra restrictions on
> > > > blanking and unblanking frame buffer device.
> > > > 
> > > > Unfortunately, pwm_bl driver's probe did not initialize members of
> > > > struct backlight_device necessary for further blank/unblank
> > > > operation.
> > > > 
> > > > This code in case of initial unblank of backlight device (default 
> > > > behaviour) sets use_count to 1 and marks this particular backlight
> > > > device as used by all available fb devices (since it is not known
> > > > during probe how much and which fb devices will be assigned).
> > > > 
> > > > Without this code, the backlight works properly until one tries to
> > > > blank it manually from sysfs with "echo 1
> > > > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > > > > were both set to 0, the logic at
> > > > fb_notifier_callback (@backlight.c) thought that we didn't turn on
> > > > (unblanked) the backlight device and refuses to disable (blank)
> > > > it. As a result we see garbage from fb displayed.
> > > 
> > > COmments/acks are more than welcome :-)
> > 
> > I thought Jingoo already replied to you?
> 
> Yes, Jingoo replied to me and asked for correcting the patch
> description. The corrected patch is the v2.

Ah, I see.  You've attached the v4 to the original set.

Ball is in Jingoo's court.

> > > > Signed-off-by: Lukasz Majewski 
> > > > ---
> > > > The patch has been tested on i.MX6q with 4.9-rc3
> > > > SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> > > > ---
> > > > Changes for v2:
> > > > - Update commit message with proper other commit reference
> > > > 
> > > > ---
> > > >  drivers/video/backlight/pwm_bl.c | 10 +-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> > > > platform_device *pdev) struct pwm_bl_data *pb;
> > > > int initial_blank = FB_BLANK_UNBLANK;
> > > > struct pwm_args pargs;
> > > > -   int ret;
> > > > +   int ret, i;
> > > >  
> > > > if (!data) {
> > > > ret = pwm_backlight_parse_dt(>dev,
> > > > ); @@ -348,6 +348,14 @@ static int
> > > > pwm_backlight_probe(struct platform_device *pdev) 
> > > > bl->props.brightness = data->dft_brightness;
> > > > bl->props.power = initial_blank;
> > > > +
> > > > +   if (initial_blank == FB_BLANK_UNBLANK) {
> > > > +   for (i = 0; i < FB_MAX; i++)
> > > > +   bl->fb_bl_on[i] = true;
> > > > +
> > > > +   bl->use_count = 1;
> > > > +   }
> > > > +
> > > > backlight_update_status(bl);
> > > >  
> > > > platform_set_drvdata(pdev, bl);
> > > 
> > 
> > 
> > 
> 



-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

[kbuild test robot]

Hi Srinivas,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
 ^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in 
>> something not a structure or union

vim +/data +630 drivers/mfd/pm8921-core.c

   624  const struct pm8xxx_data *data;
   625  int irq, rc;
   626  unsigned int val;
   627  u32 rev;
   628  struct pm_irq_chip *chip;
   629  
 > 630  data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
   631  if (!data) {
   632  dev_err(>dev, "No matching driver data found\n");
   633  return -EINVAL;

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] mfd: pm8921: add support to pm8821

[kbuild test robot]

Hi Srinivas,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
 ^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in 
>> something not a structure or union

vim +/data +630 drivers/mfd/pm8921-core.c

   624  const struct pm8xxx_data *data;
   625  int irq, rc;
   626  unsigned int val;
   627  u32 rev;
   628  struct pm_irq_chip *chip;
   629  
 > 630  data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
   631  if (!data) {
   632  dev_err(>dev, "No matching driver data found\n");
   633  return -EINVAL;

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


.config.gz
Description: application/gzip

[PATCH 0/3] PCI: hv: clean-up and 2 fixes to the hot-remove case

[Dexuan Cui]

PATCH 1 is just a clean-up. There should be no functional change.

PATCH 2 and 3 are for device hot-remove case. 
Currently the driver will stop working or even cause panic, if we do
hot add/remove quickly a few times. With the 2 patches, everything works
reliably in my tests now.

There can be still a potential issue with hot-remove when we unload 
the driver at the same time. That would require more work of proper
synchronization among the 3 paths: the .probe/.remove, the channel callback,
and the offloaded hv_pci_devices_present()/hv_eject_device_work().

But for now, PATCH 2 and 3 do improve the situation a lot.

Dexuan Cui (3):
  PCI: hv: use the correct buffer size in new_pcichild_device()
  PCI: hv: fix hv_pci_remove() for hot-remove
  PCI: hv: delete the device earlier from hbus->children for hot-remove

 drivers/pci/host/pci-hyperv.c | 67 ++-
 1 file changed, 40 insertions(+), 27 deletions(-)

-- 
2.7.4

[PATCH 0/3] PCI: hv: clean-up and 2 fixes to the hot-remove case

[Dexuan Cui]

PATCH 1 is just a clean-up. There should be no functional change.

PATCH 2 and 3 are for device hot-remove case. 
Currently the driver will stop working or even cause panic, if we do
hot add/remove quickly a few times. With the 2 patches, everything works
reliably in my tests now.

There can be still a potential issue with hot-remove when we unload 
the driver at the same time. That would require more work of proper
synchronization among the 3 paths: the .probe/.remove, the channel callback,
and the offloaded hv_pci_devices_present()/hv_eject_device_work().

But for now, PATCH 2 and 3 do improve the situation a lot.

Dexuan Cui (3):
  PCI: hv: use the correct buffer size in new_pcichild_device()
  PCI: hv: fix hv_pci_remove() for hot-remove
  PCI: hv: delete the device earlier from hbus->children for hot-remove

 drivers/pci/host/pci-hyperv.c | 67 ++-
 1 file changed, 40 insertions(+), 27 deletions(-)

-- 
2.7.4

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Laurent Pinchart]

Hi Luis,

On Wednesday 09 Nov 2016 16:59:30 Luis R. Rodriguez wrote:
> On Wed, Nov 9, 2016 at 4:43 PM, Rafael J. Wysocki wrote:
> > On Mon, Nov 7, 2016 at 10:22 PM, Luis R. Rodriguez wrote:
> >> On Thu, Oct 27, 2016 at 05:25:51PM +0200, Greg Kroah-Hartman wrote:
> >>> On Wed, Oct 26, 2016 at 01:19:02PM +0200, Lukas Wunner wrote:
>  Hi Rafael,
>  
>  sorry for not responding to v5 of your series earlier, just sending
>  this out now in the hope that it reaches you before your travels.
>  
>  On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> > - Modify device_links_check_suppliers(),
> > device_links_driver_bound(),
> > 
> >   device_links_no_driver(), device_links_driver_cleanup(),
> >   device_links_busy(), and device_links_unbind_consumers() to walk
> >   link lists under device_links_lock (to make the new "driver
> >   presence tracking" mechanism work reliably).
> 
>  This change might increase boot time if drivers return -EPROBE_DEFER.
> >>> 
> >>> "might"?  Please verify this before guessing
> >>> 
> >>> And don't make this more complex than needed before actually determining
> >>> a real issue.
> >> 
> >> As clarified by Rafael at Plumbers, this functional dependencies
> >> framework assumes your driver / subsystem supports deferred probe,
> > 
> > It isn't particularly clear what you mean by "support" here.
> 
> I noted some folks had reported issues, and you acknowledged that if
> deferred probe was used in some drivers and if this created an issue
> the same issue would be seen with this framework. AFAICT there are two
> possible issues to consider:
> 
> 1) the one Geert Uytterhoeven noted. Again I'll note what he had mentioned
> [0].
> 
>   "Some drivers / subsystems don’t support deferred probe yet, such failures
> usually don’t blow up, but cause subtle malfunctioning. Example, an
> Ethernet phy could not get its interrupt as the primary IRQ chip had not
> been probed yet, it reverted to polling though. Sub-optimal." [0]
> 
> [0]
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003
> 425.html
> 
> Geert can you provide more details?

This is a more global issue. In many cases drivers depend on optional 
resources. They are able to operate in a degraded mode (reduced feature set, 
reduced performances, ...) when those resources are not present. They can 
easily determine at probe time whether those resources are present, but have 
no way to know, in case they're absent, whether they will be present at some 
point in the near future (due to another driver probing the device providing 
the resource for instance) or if they will never be present (for instance 
because the required driver is missing). In the first case it would make sense 
to defer probe, in the latter case deferring probe forever for missing 
optional resources would prevent the device from being probed successfully at 
all.

The functional dependencies tracking patch series isn't meant to address this 
issue. I can imagine a framework that would notify drivers of optional 
resource availability after probe time, but it would come at a high cost for 
drivers as switching between modes of operation at runtime based on the 
availability of such resources would be way more complex than a mechanism 
based on probe deferral.

> 2) Since deferred probe relies on late_initcall() if your driver must
> load earlier than this deferred probe can create an issue. Andrzej had
> you identified a driver that ran into this and had issues ? If not
> this seems like a semantics thing we should consider in extending the
> documentation for drivers so that driver writers are aware of this
> limitation. I would suppose candidates for this would be anything not
> using module_init() or late_initcall() on their inits and have a
> probe.
> 
> >> if it does not support its not clear what will happen
> > 
> > I don't see any problems here, but if you see any, please just say
> > what they are.
> > 
> >> We have no explicit semantics to check if a driver / subsystem
> >> supports deferred probe.
> > 
> > That's correct, but then do we need it?
> 
> We can determine this by reviewing the two items above.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Laurent Pinchart]

Hi Luis,

On Wednesday 09 Nov 2016 16:59:30 Luis R. Rodriguez wrote:
> On Wed, Nov 9, 2016 at 4:43 PM, Rafael J. Wysocki wrote:
> > On Mon, Nov 7, 2016 at 10:22 PM, Luis R. Rodriguez wrote:
> >> On Thu, Oct 27, 2016 at 05:25:51PM +0200, Greg Kroah-Hartman wrote:
> >>> On Wed, Oct 26, 2016 at 01:19:02PM +0200, Lukas Wunner wrote:
>  Hi Rafael,
>  
>  sorry for not responding to v5 of your series earlier, just sending
>  this out now in the hope that it reaches you before your travels.
>  
>  On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> > - Modify device_links_check_suppliers(),
> > device_links_driver_bound(),
> > 
> >   device_links_no_driver(), device_links_driver_cleanup(),
> >   device_links_busy(), and device_links_unbind_consumers() to walk
> >   link lists under device_links_lock (to make the new "driver
> >   presence tracking" mechanism work reliably).
> 
>  This change might increase boot time if drivers return -EPROBE_DEFER.
> >>> 
> >>> "might"?  Please verify this before guessing
> >>> 
> >>> And don't make this more complex than needed before actually determining
> >>> a real issue.
> >> 
> >> As clarified by Rafael at Plumbers, this functional dependencies
> >> framework assumes your driver / subsystem supports deferred probe,
> > 
> > It isn't particularly clear what you mean by "support" here.
> 
> I noted some folks had reported issues, and you acknowledged that if
> deferred probe was used in some drivers and if this created an issue
> the same issue would be seen with this framework. AFAICT there are two
> possible issues to consider:
> 
> 1) the one Geert Uytterhoeven noted. Again I'll note what he had mentioned
> [0].
> 
>   "Some drivers / subsystems don’t support deferred probe yet, such failures
> usually don’t blow up, but cause subtle malfunctioning. Example, an
> Ethernet phy could not get its interrupt as the primary IRQ chip had not
> been probed yet, it reverted to polling though. Sub-optimal." [0]
> 
> [0]
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003
> 425.html
> 
> Geert can you provide more details?

This is a more global issue. In many cases drivers depend on optional 
resources. They are able to operate in a degraded mode (reduced feature set, 
reduced performances, ...) when those resources are not present. They can 
easily determine at probe time whether those resources are present, but have 
no way to know, in case they're absent, whether they will be present at some 
point in the near future (due to another driver probing the device providing 
the resource for instance) or if they will never be present (for instance 
because the required driver is missing). In the first case it would make sense 
to defer probe, in the latter case deferring probe forever for missing 
optional resources would prevent the device from being probed successfully at 
all.

The functional dependencies tracking patch series isn't meant to address this 
issue. I can imagine a framework that would notify drivers of optional 
resource availability after probe time, but it would come at a high cost for 
drivers as switching between modes of operation at runtime based on the 
availability of such resources would be way more complex than a mechanism 
based on probe deferral.

> 2) Since deferred probe relies on late_initcall() if your driver must
> load earlier than this deferred probe can create an issue. Andrzej had
> you identified a driver that ran into this and had issues ? If not
> this seems like a semantics thing we should consider in extending the
> documentation for drivers so that driver writers are aware of this
> limitation. I would suppose candidates for this would be anything not
> using module_init() or late_initcall() on their inits and have a
> probe.
> 
> >> if it does not support its not clear what will happen
> > 
> > I don't see any problems here, but if you see any, please just say
> > what they are.
> > 
> >> We have no explicit semantics to check if a driver / subsystem
> >> supports deferred probe.
> > 
> > That's correct, but then do we need it?
> 
> We can determine this by reviewing the two items above.

-- 
Regards,

Laurent Pinchart

[PATCH] ASoC: samsung: Makefile cleanup

[Valentin Rothberg]

Commit a076d418235f ("ASoC: samsung: Drop AC97 drivers") removed some
unused code and the associated Kconfig options, but left those options
referenced in the Makefile.  Remove the leftover references in the
Makefile.

Signed-off-by: Valentin Rothberg <valentinrothb...@gmail.com>
---
I found the issue running checkkconfigsymbols.py --diff 
next-20161109..next-20161110

 sound/soc/samsung/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index f3f4a32cd376..27956621c849 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -45,8 +45,6 @@ snd-soc-arndale-rt5631-objs := arndale_rt5631.o
 
 obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK2443_WM9710) += snd-soc-smdk2443-wm9710.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_LN2440SBC_ALC650) += snd-soc-ln2440sbc-alc650.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_S3C24XX_UDA134X) += snd-soc-s3c24xx-uda134x.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SIMTEC) += snd-soc-s3c24xx-simtec.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SIMTEC_HERMES) += snd-soc-s3c24xx-simtec-hermes.o
@@ -56,7 +54,6 @@ obj-$(CONFIG_SND_SOC_SAMSUNG_RX1950_UDA1380) += 
snd-soc-rx1950-uda1380.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8580) += snd-soc-smdk-wm8580.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994) += snd-soc-smdk-wm8994.o
 obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
 obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
 obj-$(CONFIG_SND_SOC_SMDK_WM8580_PCM) += snd-soc-smdk-wm8580pcm.o
-- 
2.10.2

[PATCH] ASoC: samsung: Makefile cleanup

[Valentin Rothberg]

Commit a076d418235f ("ASoC: samsung: Drop AC97 drivers") removed some
unused code and the associated Kconfig options, but left those options
referenced in the Makefile.  Remove the leftover references in the
Makefile.

Signed-off-by: Valentin Rothberg 
---
I found the issue running checkkconfigsymbols.py --diff 
next-20161109..next-20161110

 sound/soc/samsung/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index f3f4a32cd376..27956621c849 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -45,8 +45,6 @@ snd-soc-arndale-rt5631-objs := arndale_rt5631.o
 
 obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK2443_WM9710) += snd-soc-smdk2443-wm9710.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_LN2440SBC_ALC650) += snd-soc-ln2440sbc-alc650.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_S3C24XX_UDA134X) += snd-soc-s3c24xx-uda134x.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SIMTEC) += snd-soc-s3c24xx-simtec.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SIMTEC_HERMES) += snd-soc-s3c24xx-simtec-hermes.o
@@ -56,7 +54,6 @@ obj-$(CONFIG_SND_SOC_SAMSUNG_RX1950_UDA1380) += 
snd-soc-rx1950-uda1380.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8580) += snd-soc-smdk-wm8580.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994) += snd-soc-smdk-wm8994.o
 obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
-obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
 obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
 obj-$(CONFIG_SND_SOC_SMDK_WM8580_PCM) += snd-soc-smdk-wm8580pcm.o
-- 
2.10.2

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[Benjamin Herrenschmidt]

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote:
> The big change would be to handle !MMIO translations, for which we'd
> need a runtime registry of ISA bus instance to find the relevant
> accessor ops and instance-specific data.

Yes. We do something a bit like that on ppc, we find the PCI bus
for which the IO ports match and I have a hook to register the
special indirect ISA.

It's a bit messy, we could do something nicer generically.

Cheers,
Ben.

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[Benjamin Herrenschmidt]

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote:
> The big change would be to handle !MMIO translations, for which we'd
> need a runtime registry of ISA bus instance to find the relevant
> accessor ops and instance-specific data.

Yes. We do something a bit like that on ppc, we find the PCI bus
for which the IO ports match and I have a hook to register the
special indirect ISA.

It's a bit messy, we could do something nicer generically.

Cheers,
Ben.

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Laurent Pinchart]

Hi Luis,

On Monday 07 Nov 2016 22:39:54 Luis R. Rodriguez wrote:
> On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Currently, there is a problem with taking functional dependencies
> > between devices into account.
> > 
> > What I mean by a "functional dependency" is when the driver of device
> > B needs device A to be functional and (generally) its driver to be
> > present in order to work properly.  This has certain consequences
> > for power management (suspend/resume and runtime PM ordering) and
> > shutdown ordering of these devices.  In general, it also implies that
> > the driver of A needs to be working for B to be probed successfully
> > and it cannot be unbound from the device before the B's driver.
> > 
> > Support for representing those functional dependencies between
> > devices is added here to allow the driver core to track them and act
> > on them in certain cases where applicable.
> > 
> > The argument for doing that in the driver core is that there are
> > quite a few distinct use cases involving device dependencies, they
> > are relatively hard to get right in a driver (if one wants to
> > address all of them properly) and it only gets worse if multiplied
> > by the number of drivers potentially needing to do it.
> 
> How many drivers actually *need this* today for suspend / resume ?

I don't think there's a list, but just speaking for Renesas R-Car platforms 
such a dependency exists from all DMA bus masters to the system IOMMUs (we're 
talking about dozens of devices here), as well as from the display, video 
codec and video processing IP cores to transparent memory access IP cores that 
handle burst access and compression/decompression.

> How many of these are because of ACPI firmware bugs rather than
> some other reason ?

None from the list above, even with s/ACPI/DT/.

> Can ACPI somehow be used instead by these devices to address quirks?

Certainly not on ARM embedded platforms :-)

> > Morever, at least one case (asynchronous system suspend/resume) cannot be
> > handled in a single driver at all, because it requires the driver of A to
> > wait for B to suspend (during system suspend) and the driver of B to
> > wait for A to resume (during system resume).
> 
> Why is this all of a sudden a new issue?

It's not a new issue, we've just never addressed it properly so far. Various 
workarounds existed, with various level of success (usually more for runtime 
PM than system suspend/resume).

> It seems there is quite a bit of frameworks already out there that somehow
> deal with some sort of device ordering / dependencies, and I am curious if
> they've been addressing some of these problems for a while now on their own
> somehow with their own solutions, is that the case? For instance can DAPM
> the / DRM / Audio component framework v4l async solution be used or does it
> already address some of these concerns ?
>
> > For this reason, represent dependencies between devices as "links",
> > with the help of struct device_link objects each containing pointers
> > to the "linked" devices, a list node for each of them, status
> > information, flags, and an RCU head for synchronization.
> > 
> > Also add two new list heads, representing the lists of links to the
> > devices that depend on the given one (consumers) and to the devices
> > depended on by it (suppliers), and a "driver presence status" field
> > (needed for figuring out initial states of device links) to struct
> > device.
> > 
> > The entire data structure consisting of all of the lists of link
> > objects for all devices is protected by a mutex (for link object
> > addition/removal and for list walks during device driver probing
> > and removal) and by SRCU (for list walking in other case that will
> > be introduced by subsequent change sets).  In addition, each link
> > object has an internal status field whose value reflects whether or
> > not drivers are bound to the devices pointed to by the link or
> > probing/removal of their drivers is in progress etc.  That field
> > is only modified under the device links mutex, but it may be read
> > outside of it in some cases (introduced by subsequent change sets),
> > so modifications of it are annotated with WRITE_ONCE().
> > 
> > New links are added by calling device_link_add() which takes three
> > arguments: pointers to the devices in question and flags.  In
> > particular, if DL_FLAG_STATELESS is set in the flags, the link status
> > is not to be taken into account for this link and the driver core
> > will not manage it.  In turn, if DL_FLAG_AUTOREMOVE is set in the
> > flags, the driver core will remove the link automatically when the
> > consumer device driver unbinds from it.
> > 
> > One of the actions carried out by device_link_add() is to reorder
> > the lists used for device shutdown and system suspend/resume to
> > put the consumer device along with all of its children and all of
> 

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

[Laurent Pinchart]

Hi Luis,

On Monday 07 Nov 2016 22:39:54 Luis R. Rodriguez wrote:
> On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > Currently, there is a problem with taking functional dependencies
> > between devices into account.
> > 
> > What I mean by a "functional dependency" is when the driver of device
> > B needs device A to be functional and (generally) its driver to be
> > present in order to work properly.  This has certain consequences
> > for power management (suspend/resume and runtime PM ordering) and
> > shutdown ordering of these devices.  In general, it also implies that
> > the driver of A needs to be working for B to be probed successfully
> > and it cannot be unbound from the device before the B's driver.
> > 
> > Support for representing those functional dependencies between
> > devices is added here to allow the driver core to track them and act
> > on them in certain cases where applicable.
> > 
> > The argument for doing that in the driver core is that there are
> > quite a few distinct use cases involving device dependencies, they
> > are relatively hard to get right in a driver (if one wants to
> > address all of them properly) and it only gets worse if multiplied
> > by the number of drivers potentially needing to do it.
> 
> How many drivers actually *need this* today for suspend / resume ?

I don't think there's a list, but just speaking for Renesas R-Car platforms 
such a dependency exists from all DMA bus masters to the system IOMMUs (we're 
talking about dozens of devices here), as well as from the display, video 
codec and video processing IP cores to transparent memory access IP cores that 
handle burst access and compression/decompression.

> How many of these are because of ACPI firmware bugs rather than
> some other reason ?

None from the list above, even with s/ACPI/DT/.

> Can ACPI somehow be used instead by these devices to address quirks?

Certainly not on ARM embedded platforms :-)

> > Morever, at least one case (asynchronous system suspend/resume) cannot be
> > handled in a single driver at all, because it requires the driver of A to
> > wait for B to suspend (during system suspend) and the driver of B to
> > wait for A to resume (during system resume).
> 
> Why is this all of a sudden a new issue?

It's not a new issue, we've just never addressed it properly so far. Various 
workarounds existed, with various level of success (usually more for runtime 
PM than system suspend/resume).

> It seems there is quite a bit of frameworks already out there that somehow
> deal with some sort of device ordering / dependencies, and I am curious if
> they've been addressing some of these problems for a while now on their own
> somehow with their own solutions, is that the case? For instance can DAPM
> the / DRM / Audio component framework v4l async solution be used or does it
> already address some of these concerns ?
>
> > For this reason, represent dependencies between devices as "links",
> > with the help of struct device_link objects each containing pointers
> > to the "linked" devices, a list node for each of them, status
> > information, flags, and an RCU head for synchronization.
> > 
> > Also add two new list heads, representing the lists of links to the
> > devices that depend on the given one (consumers) and to the devices
> > depended on by it (suppliers), and a "driver presence status" field
> > (needed for figuring out initial states of device links) to struct
> > device.
> > 
> > The entire data structure consisting of all of the lists of link
> > objects for all devices is protected by a mutex (for link object
> > addition/removal and for list walks during device driver probing
> > and removal) and by SRCU (for list walking in other case that will
> > be introduced by subsequent change sets).  In addition, each link
> > object has an internal status field whose value reflects whether or
> > not drivers are bound to the devices pointed to by the link or
> > probing/removal of their drivers is in progress etc.  That field
> > is only modified under the device links mutex, but it may be read
> > outside of it in some cases (introduced by subsequent change sets),
> > so modifications of it are annotated with WRITE_ONCE().
> > 
> > New links are added by calling device_link_add() which takes three
> > arguments: pointers to the devices in question and flags.  In
> > particular, if DL_FLAG_STATELESS is set in the flags, the link status
> > is not to be taken into account for this link and the driver core
> > will not manage it.  In turn, if DL_FLAG_AUTOREMOVE is set in the
> > flags, the driver core will remove the link automatically when the
> > consumer device driver unbinds from it.
> > 
> > One of the actions carried out by device_link_add() is to reorder
> > the lists used for device shutdown and system suspend/resume to
> > put the consumer device along with all of its children and all of
> > its consumers (and so on, 

Re: [PATCH] firmware: fix async/manual firmware loading

[Yves-Alexis Perez]

On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
> There are *only* two callers that do this in the kernel. If this is correct 
> *and*
> the assessment of the cast from long to int here is correct that should mean
> these two callers in the kernel that have always requested the UMH firmware
> *fallback* have *always* had a faulty UMH fallback return value...

Thanks for all your mails. Yes, that was my case here, and I noticed it looked
broken for a long time, I didn't investigate who was using it in the kernel
but I had the feeling it was a bit of an abuse of the infrastructure. I still
reported the bug because the quick fix looked OK but I can understand the will
to actually rethink if and how this part is really needed.

Maybe I need to wait a bit before resubmitting any patch with rephrased commit
log to see where this is going?

Regards,
-- 
Yves-Alexis

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] firmware: fix async/manual firmware loading

[Yves-Alexis Perez]

On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
> There are *only* two callers that do this in the kernel. If this is correct 
> *and*
> the assessment of the cast from long to int here is correct that should mean
> these two callers in the kernel that have always requested the UMH firmware
> *fallback* have *always* had a faulty UMH fallback return value...

Thanks for all your mails. Yes, that was my case here, and I noticed it looked
broken for a long time, I didn't investigate who was using it in the kernel
but I had the feeling it was a bit of an abuse of the infrastructure. I still
reported the bug because the quick fix looked OK but I can understand the will
to actually rethink if and how this part is really needed.

Maybe I need to wait a bit before resubmitting any patch with rephrased commit
log to see where this is going?

Regards,
-- 
Yves-Alexis

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
>  wrote:
> > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> >> > Would it not be better to emulate these instructions for them? What
> >> way
> >> > we can verify they're not malicious.
> >>
> >> Forget malice -- if they are really needed for some silly vm86-using
> >> program, let's trap them and emulate them so they return dummy values.
> >>
> >> Also, keep in mind that vm86 is already effectively gated behind a
> >> sysctl for non-root.  I think the default should be that, if root has
> >> enabled vm86, it should work.
> >
> > Then should I keep UMIP enabled by default and still provide an option
> > to disable it via a kernel parameter?
> 
> Probably, but clearcpuid might be good enough.  There might be some
> unexpected breakage.
> 
> >
> > Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> > Under the new approach (of emulating the impacted instructions), this
> > option, a #GP fault would still be generated but the actual values of
> > GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?
> 
> I don't think so.  As far as I know, there is no legitimate reason for
> a vm86-using program to care about what these instructions spit out.
> Heck, in real mode and vm86 mode, there aren't segment descriptors at
> all, so the GDT is really quite useless even if it were readable.

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1]. dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system. In such cases, UMIP might be needed to be disabled.

So, yes, I agree now that UMIP does not need to be disabled specifically
for vm86 tasks but via clearcpuid.

Thanks and BR,
Ricardo
[1].
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/dosext/dpmi/vxd.c#l731 
> 
> I would suggest having all of these instructions return compile-time
> constants in vm86 mode.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
>  wrote:
> > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> >> > Would it not be better to emulate these instructions for them? What
> >> way
> >> > we can verify they're not malicious.
> >>
> >> Forget malice -- if they are really needed for some silly vm86-using
> >> program, let's trap them and emulate them so they return dummy values.
> >>
> >> Also, keep in mind that vm86 is already effectively gated behind a
> >> sysctl for non-root.  I think the default should be that, if root has
> >> enabled vm86, it should work.
> >
> > Then should I keep UMIP enabled by default and still provide an option
> > to disable it via a kernel parameter?
> 
> Probably, but clearcpuid might be good enough.  There might be some
> unexpected breakage.
> 
> >
> > Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> > Under the new approach (of emulating the impacted instructions), this
> > option, a #GP fault would still be generated but the actual values of
> > GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?
> 
> I don't think so.  As far as I know, there is no legitimate reason for
> a vm86-using program to care about what these instructions spit out.
> Heck, in real mode and vm86 mode, there aren't segment descriptors at
> all, so the GDT is really quite useless even if it were readable.

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1]. dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system. In such cases, UMIP might be needed to be disabled.

So, yes, I agree now that UMIP does not need to be disabled specifically
for vm86 tasks but via clearcpuid.

Thanks and BR,
Ricardo
[1].
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/dosext/dpmi/vxd.c#l731 
> 
> I would suggest having all of these instructions return compile-time
> constants in vm86 mode.

[PATCH] audit: skip sessionid sentinel value when auto-incrementing

[Richard Guy Briggs]

The value (unsigned int)-1 is used as a sentinel to indicate the
sessionID is unset.  Skip this value when the session_id value wraps.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 5abf1dc..e414dfa 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
goto out;
 
/* are we setting or clearing? */
-   if (uid_valid(loginuid))
+   if (uid_valid(loginuid)) {
sessionid = (unsigned int)atomic_inc_return(_id);
+   if (unlikely(sessionid == (unsigned int)-1))
+   sessionid = (unsigned 
int)atomic_inc_return(_id);
+   }
 
task->sessionid = sessionid;
task->loginuid = loginuid;
-- 
1.7.1

[PATCH] audit: skip sessionid sentinel value when auto-incrementing

[Richard Guy Briggs]

The value (unsigned int)-1 is used as a sentinel to indicate the
sessionID is unset.  Skip this value when the session_id value wraps.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 5abf1dc..e414dfa 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
goto out;
 
/* are we setting or clearing? */
-   if (uid_valid(loginuid))
+   if (uid_valid(loginuid)) {
sessionid = (unsigned int)atomic_inc_return(_id);
+   if (unlikely(sessionid == (unsigned int)-1))
+   sessionid = (unsigned 
int)atomic_inc_return(_id);
+   }
 
task->sessionid = sessionid;
task->loginuid = loginuid;
-- 
1.7.1

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

[zhichang.yuan]

Hi, Arnd,

On 2016/11/10 5:34, Arnd Bergmann wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
 +   /*
 +* The first PCIBIOS_MIN_IO is reserved specifically for
>>> indirectIO.
 +* It will separate indirectIO range from pci host bridge to
 +* avoid the possible PIO conflict.
 +* Set the indirectIO range directly here.
 +*/
 +   lpcdev->io_ops.start = 0;
 +   lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
 +   lpcdev->io_ops.devpara = lpcdev;
 +   lpcdev->io_ops.pfin = hisilpc_comm_in;
 +   lpcdev->io_ops.pfout = hisilpc_comm_out;
 +   lpcdev->io_ops.pfins = hisilpc_comm_ins;
 +   lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>
>>> I have to look at patch 2 in more detail again, after missing a few
>>> review
>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>> range here, and would hope that we can just go through the same
>>> assignment of logical port ranges that we have for PCI buses,
>>> decoupling
>>> the bus addresses from the linux-internal ones.
>>
>> The point here is that we want to avoid any conflict/overlap between
>> the LPC I/O space and the PCI I/O space. With the assignment above
>> we make sure that LPC never interfere with PCI I/O space.
> 
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.

Do you means that we can pick up the maximal I/O address from all children's
device resources??

Thanks,
Zhichang

> 
>   Arnd
> 
> .
> 

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

[zhichang.yuan]

Hi, Arnd,

On 2016/11/10 5:34, Arnd Bergmann wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
 +   /*
 +* The first PCIBIOS_MIN_IO is reserved specifically for
>>> indirectIO.
 +* It will separate indirectIO range from pci host bridge to
 +* avoid the possible PIO conflict.
 +* Set the indirectIO range directly here.
 +*/
 +   lpcdev->io_ops.start = 0;
 +   lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
 +   lpcdev->io_ops.devpara = lpcdev;
 +   lpcdev->io_ops.pfin = hisilpc_comm_in;
 +   lpcdev->io_ops.pfout = hisilpc_comm_out;
 +   lpcdev->io_ops.pfins = hisilpc_comm_ins;
 +   lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>
>>> I have to look at patch 2 in more detail again, after missing a few
>>> review
>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>> range here, and would hope that we can just go through the same
>>> assignment of logical port ranges that we have for PCI buses,
>>> decoupling
>>> the bus addresses from the linux-internal ones.
>>
>> The point here is that we want to avoid any conflict/overlap between
>> the LPC I/O space and the PCI I/O space. With the assignment above
>> we make sure that LPC never interfere with PCI I/O space.
> 
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.

Do you means that we can pick up the maximal I/O address from all children's
device resources??

Thanks,
Zhichang

> 
>   Arnd
> 
> .
> 

[PATCH] audit: tame initialization warning len_abuf in audit_log_execve_info

[Richard Guy Briggs]

Tame initialization warning of len_abuf in audit_log_execve_info even
though there isn't presently a bug introduced by commit 43761473c254
("audit: fix a double fetch in audit_log_single_execve_arg()").  Using
UNINITIALIZED_VAR instead may mask future bugs.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e414dfa..d161b17 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1000,7 +1000,7 @@ static void audit_log_execve_info(struct audit_context 
*context,
long len_rem;
long len_full;
long len_buf;
-   long len_abuf;
+   long len_abuf = 0;
long len_tmp;
bool require_data;
bool encode;
-- 
1.7.1

[PATCH] audit: tame initialization warning len_abuf in audit_log_execve_info

[Richard Guy Briggs]

Tame initialization warning of len_abuf in audit_log_execve_info even
though there isn't presently a bug introduced by commit 43761473c254
("audit: fix a double fetch in audit_log_single_execve_arg()").  Using
UNINITIALIZED_VAR instead may mask future bugs.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e414dfa..d161b17 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1000,7 +1000,7 @@ static void audit_log_execve_info(struct audit_context 
*context,
long len_rem;
long len_full;
long len_buf;
-   long len_abuf;
+   long len_abuf = 0;
long len_tmp;
bool require_data;
bool encode;
-- 
1.7.1

Re: [PATCH v3] mailbox: PCC: Fix lockdep warning when request PCC channel

[Hoan Tran]

Hi All,

On Thu, Oct 27, 2016 at 3:34 PM, Hoan Tran  wrote:
> This patch fixes the lockdep warning below
>
> [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [7.229776] [ cut here ]
> [7.229787] WARNING: CPU: 1 PID: 1 at 
> linux-next/kernel/locking/lockdep.c:2876 loc
> kdep_trace_alloc+0xe0/0xf0
> [7.229790] Modules linked in:
> [7.229793]
> [7.229798] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 
> #46
> ...
> [7.229900] Call trace:
> [7.229903] Exception stack(0x8007da837890 to 0x8007da8379c0)
> [7.229906] 7880:   8007da834000 
> 0001
> [7.229909] 78a0: 8007da837a70 08a0 60c5 
> 003d
> [7.229912] 78c0: 9374bc6a7f3c7832 00381878 09db7ab8 
> 002f
> [7.229915] 78e0: 0811aabc 08be2548 8007da837990 
> 0811adf8
> [7.229918] 7900: 8007da834000 024080c0 00c0 
> 09021000
> [7.229921] 7920:   08c8f7c8 
> 8007da579810
> [7.229923] 7940: 002f 8007da858000  
> 0001
> [7.229926] 7960: 0001  0811a468 
> 0002
> [7.229929] 7980: 656c62617369645f 00038187 00ee 
> 8007da837850
> [7.229932] 79a0: 09db50c0 09db569d 0006 
> 89db568f
> [7.229936] [] lockdep_trace_alloc+0xe0/0xf0
> [7.229940] [] __kmalloc_track_caller+0x50/0x250
> [7.229945] [] devres_alloc_node+0x28/0x60
> [7.229949] [] devm_request_threaded_irq+0x50/0xe0
> [7.229955] [] pcc_mbox_request_channel+0x110/0x170
> [7.229960] [] acpi_cppc_processor_probe+0x264/0x414
> [7.229963] [] __acpi_processor_start+0x28/0xa0
> [7.229966] [] acpi_processor_start+0x44/0x54
> [7.229970] [] driver_probe_device+0x1fc/0x2b0
> [7.229974] [] __driver_attach+0xb4/0xc0
> [7.229977] [] bus_for_each_dev+0x5c/0xa0
> [7.229980] [] driver_attach+0x20/0x30
> [7.229983] [] bus_add_driver+0x110/0x230
> [7.229987] [] driver_register+0x60/0x100
> [7.229991] [] acpi_processor_driver_init+0x2c/0xb0
> [7.229996] [] do_one_initcall+0x38/0x130
> [7.23] [] kernel_init_freeable+0x210/0x2b4
> [7.230004] [] kernel_init+0x10/0x110
> [7.230007] [] ret_from_fork+0x10/0x50
>
> It's because the spinlock inside pcc_mbox_request_channel() is
> kept too long. This patch releases spinlock before request_irq()
> and free_irq() to fix this issue  as spinlock is only needed to
> protect the channel data.
>
> Signed-off-by: Hoan Tran 
> ---
> v3
>  * Free mailbox irq before reset the channel data
>  * Free channel if it fails to request the mailbox irq
>
> v2
>  * Release spinlock before request_irq() and free_irq() instead of
> using mutex
>
>
>  drivers/mailbox/pcc.c | 70 
> +--
>  1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 08c87fa..4b2f061 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -224,6 +224,38 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  }
>
>  /**
> + * pcc_mbox_free_channel - Clients call this to free their Channel.
> + *
> + * @chan: Pointer to the mailbox channel as returned by
> + * pcc_mbox_request_channel()
> + */
> +void pcc_mbox_free_channel(struct mbox_chan *chan)
> +{
> +   u32 id = chan - pcc_mbox_channels;
> +   unsigned long flags;
> +
> +   if (!chan || !chan->cl)
> +   return;
> +
> +   if (id >= pcc_mbox_ctrl.num_chans) {
> +   pr_debug("pcc_mbox_free_channel: Invalid mbox_chan passed\n");
> +   return;
> +   }
> +
> +   if (pcc_doorbell_irq[id] > 0)
> +   devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
> +
> +   spin_lock_irqsave(>lock, flags);
> +   chan->cl = NULL;
> +   chan->active_req = NULL;
> +   if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
> +   chan->txdone_method = TXDONE_BY_POLL;
> +
> +   spin_unlock_irqrestore(>lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
> +
> +/**
>   * pcc_mbox_request_channel - PCC clients call this function to
>   * request a pointer to their PCC subspace, from which they
>   * can get the details of communicating with the remote.
> @@ -267,6 +299,8 @@ struct mbox_chan *pcc_mbox_request_channel(struct 
> mbox_client *cl,
> if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
> chan->txdone_method |= TXDONE_BY_ACK;
>
> +   spin_unlock_irqrestore(>lock, flags);
> +
> if (pcc_doorbell_irq[subspace_id] > 0) {
> int rc;
>
> @@ -275,50 +309,16 @@ 

Re: [PATCH v3] mailbox: PCC: Fix lockdep warning when request PCC channel

[Hoan Tran]

Hi All,

On Thu, Oct 27, 2016 at 3:34 PM, Hoan Tran  wrote:
> This patch fixes the lockdep warning below
>
> [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [7.229776] [ cut here ]
> [7.229787] WARNING: CPU: 1 PID: 1 at 
> linux-next/kernel/locking/lockdep.c:2876 loc
> kdep_trace_alloc+0xe0/0xf0
> [7.229790] Modules linked in:
> [7.229793]
> [7.229798] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 
> #46
> ...
> [7.229900] Call trace:
> [7.229903] Exception stack(0x8007da837890 to 0x8007da8379c0)
> [7.229906] 7880:   8007da834000 
> 0001
> [7.229909] 78a0: 8007da837a70 08a0 60c5 
> 003d
> [7.229912] 78c0: 9374bc6a7f3c7832 00381878 09db7ab8 
> 002f
> [7.229915] 78e0: 0811aabc 08be2548 8007da837990 
> 0811adf8
> [7.229918] 7900: 8007da834000 024080c0 00c0 
> 09021000
> [7.229921] 7920:   08c8f7c8 
> 8007da579810
> [7.229923] 7940: 002f 8007da858000  
> 0001
> [7.229926] 7960: 0001  0811a468 
> 0002
> [7.229929] 7980: 656c62617369645f 00038187 00ee 
> 8007da837850
> [7.229932] 79a0: 09db50c0 09db569d 0006 
> 89db568f
> [7.229936] [] lockdep_trace_alloc+0xe0/0xf0
> [7.229940] [] __kmalloc_track_caller+0x50/0x250
> [7.229945] [] devres_alloc_node+0x28/0x60
> [7.229949] [] devm_request_threaded_irq+0x50/0xe0
> [7.229955] [] pcc_mbox_request_channel+0x110/0x170
> [7.229960] [] acpi_cppc_processor_probe+0x264/0x414
> [7.229963] [] __acpi_processor_start+0x28/0xa0
> [7.229966] [] acpi_processor_start+0x44/0x54
> [7.229970] [] driver_probe_device+0x1fc/0x2b0
> [7.229974] [] __driver_attach+0xb4/0xc0
> [7.229977] [] bus_for_each_dev+0x5c/0xa0
> [7.229980] [] driver_attach+0x20/0x30
> [7.229983] [] bus_add_driver+0x110/0x230
> [7.229987] [] driver_register+0x60/0x100
> [7.229991] [] acpi_processor_driver_init+0x2c/0xb0
> [7.229996] [] do_one_initcall+0x38/0x130
> [7.23] [] kernel_init_freeable+0x210/0x2b4
> [7.230004] [] kernel_init+0x10/0x110
> [7.230007] [] ret_from_fork+0x10/0x50
>
> It's because the spinlock inside pcc_mbox_request_channel() is
> kept too long. This patch releases spinlock before request_irq()
> and free_irq() to fix this issue  as spinlock is only needed to
> protect the channel data.
>
> Signed-off-by: Hoan Tran 
> ---
> v3
>  * Free mailbox irq before reset the channel data
>  * Free channel if it fails to request the mailbox irq
>
> v2
>  * Release spinlock before request_irq() and free_irq() instead of
> using mutex
>
>
>  drivers/mailbox/pcc.c | 70 
> +--
>  1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 08c87fa..4b2f061 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -224,6 +224,38 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  }
>
>  /**
> + * pcc_mbox_free_channel - Clients call this to free their Channel.
> + *
> + * @chan: Pointer to the mailbox channel as returned by
> + * pcc_mbox_request_channel()
> + */
> +void pcc_mbox_free_channel(struct mbox_chan *chan)
> +{
> +   u32 id = chan - pcc_mbox_channels;
> +   unsigned long flags;
> +
> +   if (!chan || !chan->cl)
> +   return;
> +
> +   if (id >= pcc_mbox_ctrl.num_chans) {
> +   pr_debug("pcc_mbox_free_channel: Invalid mbox_chan passed\n");
> +   return;
> +   }
> +
> +   if (pcc_doorbell_irq[id] > 0)
> +   devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
> +
> +   spin_lock_irqsave(>lock, flags);
> +   chan->cl = NULL;
> +   chan->active_req = NULL;
> +   if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
> +   chan->txdone_method = TXDONE_BY_POLL;
> +
> +   spin_unlock_irqrestore(>lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
> +
> +/**
>   * pcc_mbox_request_channel - PCC clients call this function to
>   * request a pointer to their PCC subspace, from which they
>   * can get the details of communicating with the remote.
> @@ -267,6 +299,8 @@ struct mbox_chan *pcc_mbox_request_channel(struct 
> mbox_client *cl,
> if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
> chan->txdone_method |= TXDONE_BY_ACK;
>
> +   spin_unlock_irqrestore(>lock, flags);
> +
> if (pcc_doorbell_irq[subspace_id] > 0) {
> int rc;
>
> @@ -275,50 +309,16 @@ struct mbox_chan 

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

[Vignesh R]

Hi,

On Thursday 10 November 2016 05:23 AM, John Syne wrote:
> OK, then back to my original question. Given that these DT properties are 
> supported in the driver
> 

Below properties are supported by only by ti_am3335x_adc driver and not
ti_am335x_tsc driver. As author of this patch pointed out in another
reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
see a use case where these values needs to be tweaked for tsc channels,
therefore it does not make sense to be DT properties.

> shouldn’t the following be added to am33xx.dtsi and am4372.dtsi?

Its totally upto board dts files to allocate channels for tsc and adc.
So, how could these be added to dtsi files?

> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> 
> Regards,
> John
>>
>> -- 
>> Regards
>> Vignesh
> 

-- 
Regards
Vignesh

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

[Vignesh R]

Hi,

On Thursday 10 November 2016 05:23 AM, John Syne wrote:
> OK, then back to my original question. Given that these DT properties are 
> supported in the driver
> 

Below properties are supported by only by ti_am3335x_adc driver and not
ti_am335x_tsc driver. As author of this patch pointed out in another
reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
see a use case where these values needs to be tweaked for tsc channels,
therefore it does not make sense to be DT properties.

> shouldn’t the following be added to am33xx.dtsi and am4372.dtsi?

Its totally upto board dts files to allocate channels for tsc and adc.
So, how could these be added to dtsi files?

> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> 
> Regards,
> John
>>
>> -- 
>> Regards
>> Vignesh
> 

-- 
Regards
Vignesh

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[zhichang.yuan]

Hi,Liviu,

Thanks for your comments!


On 2016/11/10 0:50, liviu.du...@arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
> 
> [removed some irrelevant part of discussion, avoid crazy formatting]
> 
 +/**
 + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
 + * @taddr: the io address to be checked.
 + *
 + * Returns 1 when taddr is in the range; otherwise return 0.
 + */
 +int addr_is_indirect_io(u64 taddr)
 +{
 +  if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if  (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
> 
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
> 
>>
>>>
 +  return 0;
 +
 +  return 1;
 +}

  BUILD_EXTIO(b, u8)

 diff --git a/drivers/of/address.c b/drivers/of/address.c
 index 02b2903..cc2a05d 100644
 --- a/drivers/of/address.c
 +++ b/drivers/of/address.c
 @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
return false;
  }

 +
 +/*
 + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
 + *For some isa/lpc devices, no ranges property in ancestor node.
 + *The device addresses are described directly in their regs
>>> property.
 + *This fixup function will be called to get the IO address of
>>> isa/lpc
 + *devices when the normal of_translation failed.
 + *
 + * @parent:   points to the parent dts node;
 + * @bus:  points to the of_bus which can be used to parse
>>> address;
 + * @addr: the address from reg property;
 + * @na:   the address cell counter of @addr;
 + * @presult:  store the address paresed from @addr;
 + *
 + * return 1 when successfully get the I/O address;
 + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
 + */
 +static int of_get_isa_indirect_io(struct device_node *parent,
 +  struct of_bus *bus, __be32 *addr,
 +  int na, u64 *presult)
 +{
 +  unsigned int flags;
 +  unsigned int rlen;
 +
 +  /* whether support indirectIO */
 +  if (!indirect_io_enabled())
 +  return 0;
 +
 +  if (!of_bus_isa_match(parent))
 +  return 0;
 +
 +  flags = bus->get_flags(addr);
 +  if (!(flags & IORESOURCE_IO))
 +  return 0;
 +
 +  /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
 +  if (of_get_property(parent, "ranges", ))
 +  return 0;
 +
 +  *presult = of_read_number(addr + 1, na - 1);
 +  /* this fixup is only valid for specific I/O range. */
 +  return addr_is_indirect_io(*presult);
 +}
 +
  static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
struct of_bus *pbus, __be32 *addr,
int na, int ns, int pna, const char *rprop)
 @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
result = of_read_number(addr, na);
break;
}
 +  /*
 +   * For indirectIO device which has no ranges property, get
 +   * the address from reg directly.
 +   */
 +  if (of_get_isa_indirect_io(dev, bus, addr, na, )) {
 +  pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
 +  of_node_full_name(dev), result);
 +  break;
 +  }

/* Get new parent bus and counts */
pbus = of_match_bus(parent);
 @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
if (taddr == OF_BAD_ADDR)
return -EINVAL;
memset(r, 0, sizeof(struct resource));
 -  if (flags & IORESOURCE_IO) {
 +  if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
unsigned long port;
 +
port = pci_address_to_pio(taddr);
if (port == (unsigned long)-1)
return -EINVAL;
 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
 index ba34907..1a08511 100644
 --- a/drivers/pci/pci.c
 +++ b/drivers/pci/pci.c
 @@ -3263,7 +3263,7 @@ int __weak 

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

[zhichang.yuan]

Hi,Liviu,

Thanks for your comments!


On 2016/11/10 0:50, liviu.du...@arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
> 
> [removed some irrelevant part of discussion, avoid crazy formatting]
> 
 +/**
 + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
 + * @taddr: the io address to be checked.
 + *
 + * Returns 1 when taddr is in the range; otherwise return 0.
 + */
 +int addr_is_indirect_io(u64 taddr)
 +{
 +  if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if  (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
> 
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
> 
>>
>>>
 +  return 0;
 +
 +  return 1;
 +}

  BUILD_EXTIO(b, u8)

 diff --git a/drivers/of/address.c b/drivers/of/address.c
 index 02b2903..cc2a05d 100644
 --- a/drivers/of/address.c
 +++ b/drivers/of/address.c
 @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
return false;
  }

 +
 +/*
 + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
 + *For some isa/lpc devices, no ranges property in ancestor node.
 + *The device addresses are described directly in their regs
>>> property.
 + *This fixup function will be called to get the IO address of
>>> isa/lpc
 + *devices when the normal of_translation failed.
 + *
 + * @parent:   points to the parent dts node;
 + * @bus:  points to the of_bus which can be used to parse
>>> address;
 + * @addr: the address from reg property;
 + * @na:   the address cell counter of @addr;
 + * @presult:  store the address paresed from @addr;
 + *
 + * return 1 when successfully get the I/O address;
 + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
 + */
 +static int of_get_isa_indirect_io(struct device_node *parent,
 +  struct of_bus *bus, __be32 *addr,
 +  int na, u64 *presult)
 +{
 +  unsigned int flags;
 +  unsigned int rlen;
 +
 +  /* whether support indirectIO */
 +  if (!indirect_io_enabled())
 +  return 0;
 +
 +  if (!of_bus_isa_match(parent))
 +  return 0;
 +
 +  flags = bus->get_flags(addr);
 +  if (!(flags & IORESOURCE_IO))
 +  return 0;
 +
 +  /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
 +  if (of_get_property(parent, "ranges", ))
 +  return 0;
 +
 +  *presult = of_read_number(addr + 1, na - 1);
 +  /* this fixup is only valid for specific I/O range. */
 +  return addr_is_indirect_io(*presult);
 +}
 +
  static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
struct of_bus *pbus, __be32 *addr,
int na, int ns, int pna, const char *rprop)
 @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
result = of_read_number(addr, na);
break;
}
 +  /*
 +   * For indirectIO device which has no ranges property, get
 +   * the address from reg directly.
 +   */
 +  if (of_get_isa_indirect_io(dev, bus, addr, na, )) {
 +  pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
 +  of_node_full_name(dev), result);
 +  break;
 +  }

/* Get new parent bus and counts */
pbus = of_match_bus(parent);
 @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
if (taddr == OF_BAD_ADDR)
return -EINVAL;
memset(r, 0, sizeof(struct resource));
 -  if (flags & IORESOURCE_IO) {
 +  if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
unsigned long port;
 +
port = pci_address_to_pio(taddr);
if (port == (unsigned long)-1)
return -EINVAL;
 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
 index ba34907..1a08511 100644
 --- a/drivers/pci/pci.c
 +++ b/drivers/pci/pci.c
 @@ -3263,7 +3263,7 @@ int __weak 

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

[Neftin, Sasha]

On 11/9/2016 11:41 PM, Tyler Baicar wrote:
> Move IRQ free code so that it will happen regardless of the
> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
> if the __E1000_DOWN bit is cleared. This is not sufficient because
> it is possible for __E1000_DOWN to be set without releasing the IRQ.
> In such a situation, we will hit a kernel bug later in e1000_remove
> because the IRQ still has action since it was never freed. A
> secondary bus reset can cause this case to happen.
> 
> Signed-off-by: Tyler Baicar 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 7017281..36cfcb0 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>  
>   if (!test_bit(__E1000_DOWN, >state)) {
>   e1000e_down(adapter, true);
> - e1000_free_irq(adapter);
>  
>   /* Link status message must follow this format */
>   pr_info("%s NIC Link is Down\n", adapter->netdev->name);
>   }   
>  
> + e1000_free_irq(adapter);
> +
>   napi_disable(>napi);
>  
>   e1000e_free_tx_resources(adapter->tx_ring);
> 
I would like not recommend insert this change. This change related
driver state machine, we afraid from lot of synchronization problem and
issues.
We need keep e1000_free_irq in loop and check for 'test_bit' ready.
Another point, does before execute secondary bus reset your SW back up
pcie configuration space as properly?

Sasha

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

[Neftin, Sasha]

On 11/9/2016 11:41 PM, Tyler Baicar wrote:
> Move IRQ free code so that it will happen regardless of the
> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
> if the __E1000_DOWN bit is cleared. This is not sufficient because
> it is possible for __E1000_DOWN to be set without releasing the IRQ.
> In such a situation, we will hit a kernel bug later in e1000_remove
> because the IRQ still has action since it was never freed. A
> secondary bus reset can cause this case to happen.
> 
> Signed-off-by: Tyler Baicar 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 7017281..36cfcb0 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>  
>   if (!test_bit(__E1000_DOWN, >state)) {
>   e1000e_down(adapter, true);
> - e1000_free_irq(adapter);
>  
>   /* Link status message must follow this format */
>   pr_info("%s NIC Link is Down\n", adapter->netdev->name);
>   }   
>  
> + e1000_free_irq(adapter);
> +
>   napi_disable(>napi);
>  
>   e1000e_free_tx_resources(adapter->tx_ring);
> 
I would like not recommend insert this change. This change related
driver state machine, we afraid from lot of synchronization problem and
issues.
We need keep e1000_free_irq in loop and check for 'test_bit' ready.
Another point, does before execute secondary bus reset your SW back up
pcie configuration space as properly?

Sasha

Re: [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support

[Chen-Yu Tsai]

On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
 wrote:
> Signed-off-by: Maxime Ripard 

Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC
needs this in the commit message?

Otherwise,

Acked-by: Chen-Yu Tsai 

> ---
>  drivers/clk/sunxi-ng/ccu_mult.c | 8 
>  drivers/clk/sunxi-ng/ccu_mult.h | 2 ++
>  2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 678b6cb49f01..826302464650 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -75,6 +75,9 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
> unsigned long val;
> u32 reg;
>
> +   if (ccu_frac_helper_is_enabled(>common, >frac))
> +   return ccu_frac_helper_read_rate(>common, >frac);
> +
> reg = readl(cm->common.base + cm->common.reg);
> val = reg >> cm->mult.shift;
> val &= (1 << cm->mult.width) - 1;
> @@ -102,6 +105,11 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned 
> long rate,
> unsigned long flags;
> u32 reg;
>
> +   if (ccu_frac_helper_has_rate(>common, >frac, rate))
> +   return ccu_frac_helper_set_rate(>common, >frac, rate);
> +   else
> +   ccu_frac_helper_disable(>common, >frac);
> +
> ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
> _rate);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> index c1a2134bdc71..bd2e38b5a32a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.h
> +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> @@ -2,6 +2,7 @@
>  #define _CCU_MULT_H_
>
>  #include "ccu_common.h"
> +#include "ccu_frac.h"
>  #include "ccu_mux.h"
>
>  struct ccu_mult_internal {
> @@ -23,6 +24,7 @@ struct ccu_mult_internal {
>  struct ccu_mult {
> u32 enable;
>
> +   struct ccu_frac_internalfrac;
> struct ccu_mult_internalmult;
> struct ccu_mux_internal mux;
> struct ccu_common   common;
> --
> git-series 0.8.11

Re: [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support

[Chen-Yu Tsai]

On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
 wrote:
> Signed-off-by: Maxime Ripard 

Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC
needs this in the commit message?

Otherwise,

Acked-by: Chen-Yu Tsai 

> ---
>  drivers/clk/sunxi-ng/ccu_mult.c | 8 
>  drivers/clk/sunxi-ng/ccu_mult.h | 2 ++
>  2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 678b6cb49f01..826302464650 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -75,6 +75,9 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
> unsigned long val;
> u32 reg;
>
> +   if (ccu_frac_helper_is_enabled(>common, >frac))
> +   return ccu_frac_helper_read_rate(>common, >frac);
> +
> reg = readl(cm->common.base + cm->common.reg);
> val = reg >> cm->mult.shift;
> val &= (1 << cm->mult.width) - 1;
> @@ -102,6 +105,11 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned 
> long rate,
> unsigned long flags;
> u32 reg;
>
> +   if (ccu_frac_helper_has_rate(>common, >frac, rate))
> +   return ccu_frac_helper_set_rate(>common, >frac, rate);
> +   else
> +   ccu_frac_helper_disable(>common, >frac);
> +
> ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
> _rate);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> index c1a2134bdc71..bd2e38b5a32a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.h
> +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> @@ -2,6 +2,7 @@
>  #define _CCU_MULT_H_
>
>  #include "ccu_common.h"
> +#include "ccu_frac.h"
>  #include "ccu_mux.h"
>
>  struct ccu_mult_internal {
> @@ -23,6 +24,7 @@ struct ccu_mult_internal {
>  struct ccu_mult {
> u32 enable;
>
> +   struct ccu_frac_internalfrac;
> struct ccu_mult_internalmult;
> struct ccu_mux_internal mux;
> struct ccu_common   common;
> --
> git-series 0.8.11

Re: [PATCH v2 2/3] firmware: qcom: scm: Remove core, iface and bus clocks dependency

[Bjorn Andersson]

On Wed 09 Nov 17:47 PST 2016, Stephen Boyd wrote:

> On 11/03, Sarangdhar Joshi wrote:
> > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> > index d79fecd..844e90d 100644
> > --- a/drivers/firmware/qcom_scm.c
> > +++ b/drivers/firmware/qcom_scm.c
> > @@ -380,32 +384,40 @@ EXPORT_SYMBOL(qcom_scm_is_available);
> >  static int qcom_scm_probe(struct platform_device *pdev)
> >  {
> > struct qcom_scm *scm;
> > +   uint32_t clks;
> 
> If this was unsigned long flags;
> 

I did look at this too and could only find a mixture of ways people have
done this. Isn't the correct type for this intptr_t?

Regards,
Bjorn

> > int ret;
> >  
> > scm = devm_kzalloc(>dev, sizeof(*scm), GFP_KERNEL);
> > if (!scm)
> > return -ENOMEM;
> >  
> > -   scm->core_clk = devm_clk_get(>dev, "core");
> > -   if (IS_ERR(scm->core_clk)) {
> > -   if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
> > -   return PTR_ERR(scm->core_clk);
> > +   clks = (uint32_t)((uintptr_t)of_device_get_match_data(>dev));
> 
> then this could just be a cast to unsigned long?
> 
> > +   if (clks & SCM_HAS_CORE_CLK) {
> > +   scm->core_clk = devm_clk_get(>dev, "core");
> > +   if (IS_ERR(scm->core_clk)) {
> > +   if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
> > +   return PTR_ERR(scm->core_clk);
> >  
> > -   scm->core_clk = NULL;
> > +   scm->core_clk = NULL;
> > +   }
> > }
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH v2 2/3] firmware: qcom: scm: Remove core, iface and bus clocks dependency

[Bjorn Andersson]

On Wed 09 Nov 17:47 PST 2016, Stephen Boyd wrote:

> On 11/03, Sarangdhar Joshi wrote:
> > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> > index d79fecd..844e90d 100644
> > --- a/drivers/firmware/qcom_scm.c
> > +++ b/drivers/firmware/qcom_scm.c
> > @@ -380,32 +384,40 @@ EXPORT_SYMBOL(qcom_scm_is_available);
> >  static int qcom_scm_probe(struct platform_device *pdev)
> >  {
> > struct qcom_scm *scm;
> > +   uint32_t clks;
> 
> If this was unsigned long flags;
> 

I did look at this too and could only find a mixture of ways people have
done this. Isn't the correct type for this intptr_t?

Regards,
Bjorn

> > int ret;
> >  
> > scm = devm_kzalloc(>dev, sizeof(*scm), GFP_KERNEL);
> > if (!scm)
> > return -ENOMEM;
> >  
> > -   scm->core_clk = devm_clk_get(>dev, "core");
> > -   if (IS_ERR(scm->core_clk)) {
> > -   if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
> > -   return PTR_ERR(scm->core_clk);
> > +   clks = (uint32_t)((uintptr_t)of_device_get_match_data(>dev));
> 
> then this could just be a cast to unsigned long?
> 
> > +   if (clks & SCM_HAS_CORE_CLK) {
> > +   scm->core_clk = devm_clk_get(>dev, "core");
> > +   if (IS_ERR(scm->core_clk)) {
> > +   if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
> > +   return PTR_ERR(scm->core_clk);
> >  
> > -   scm->core_clk = NULL;
> > +   scm->core_clk = NULL;
> > +   }
> > }
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH 1/2] skd: fix msix error handling

[Jens Axboe]

On 11/09/2016 05:55 AM, Arnd Bergmann wrote:

As reported by gcc -Wmaybe-uninitialized, the cleanup path for
skd_acquire_msix tries to free the already allocated msi-x vectors
in reverse order, but the index variable may not have been
used yet:

drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
drivers/block/skd_main.c:3890:8: error: ‘i’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

This changes the failure path to skip releasing the interrupts
if we have not started requesting them yet.


Applied both patches, thanks Arnd.

--
Jens Axboe

Re: [PATCH 1/2] skd: fix msix error handling

[Jens Axboe]

On 11/09/2016 05:55 AM, Arnd Bergmann wrote:

As reported by gcc -Wmaybe-uninitialized, the cleanup path for
skd_acquire_msix tries to free the already allocated msi-x vectors
in reverse order, but the index variable may not have been
used yet:

drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
drivers/block/skd_main.c:3890:8: error: ‘i’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

This changes the failure path to skip releasing the interrupts
if we have not started requesting them yet.


Applied both patches, thanks Arnd.

--
Jens Axboe

Re: [kernel-hardening] [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)

[ZhaoJunmin Zhao(Junmin)]

This patch adds support for XPFO which protects against 'ret2dir' kernel
attacks. The basic idea is to enforce exclusive ownership of page frames
by either the kernel or userspace, unless explicitly requested by the
kernel. Whenever a page destined for userspace is allocated, it is
unmapped from physmap (the kernel's page table). When such a page is
reclaimed from userspace, it is mapped back to physmap.

Additional fields in the page_ext struct are used for XPFO housekeeping.
Specifically two flags to distinguish user vs. kernel pages and to tag
unmapped pages and a reference counter to balance kmap/kunmap operations
and a lock to serialize access to the XPFO fields.

Known issues/limitations:
   - Only supports x86-64 (for now)
   - Only supports 4k pages (for now)
   - There are most likely some legitimate uses cases where the kernel needs
 to access userspace which need to be made XPFO-aware
   - Performance penalty

Reference paper by the original patch authors:
   http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf

Suggested-by: Vasileios P. Kemerlis 
Signed-off-by: Juerg Haefliger 
---
  arch/x86/Kconfig |   3 +-
  arch/x86/mm/init.c   |   2 +-
  drivers/ata/libata-sff.c |   4 +-
  include/linux/highmem.h  |  15 +++-
  include/linux/page_ext.h |   7 ++
  include/linux/xpfo.h |  39 +
  lib/swiotlb.c|   3 +-
  mm/Makefile  |   1 +
  mm/page_alloc.c  |   2 +
  mm/page_ext.c|   4 +
  mm/xpfo.c| 206 +++
  security/Kconfig |  19 +
  12 files changed, 298 insertions(+), 7 deletions(-)
  create mode 100644 include/linux/xpfo.h
  create mode 100644 mm/xpfo.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636d1065..38b334f8fde5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -165,6 +165,7 @@ config X86
select HAVE_STACK_VALIDATIONif X86_64
select ARCH_USES_HIGH_VMA_FLAGS if 
X86_INTEL_MEMORY_PROTECTION_KEYS
select ARCH_HAS_PKEYS   if 
X86_INTEL_MEMORY_PROTECTION_KEYS
+   select ARCH_SUPPORTS_XPFO   if X86_64

  config INSTRUCTION_DECODER
def_bool y
@@ -1361,7 +1362,7 @@ config ARCH_DMA_ADDR_T_64BIT

  config X86_DIRECT_GBPAGES
def_bool y
-   depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK
+   depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK && !XPFO
---help---
  Certain kernel features effectively disable kernel
  linear 1 GB mappings (even if the CPU otherwise
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 22af912d66d2..a6fafbae02bb 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -161,7 +161,7 @@ static int page_size_mask;

  static void __init probe_page_size_mask(void)
  {
-#if !defined(CONFIG_KMEMCHECK)
+#if !defined(CONFIG_KMEMCHECK) && !defined(CONFIG_XPFO)
/*
 * For CONFIG_KMEMCHECK or pagealloc debugging, identity mapping will
 * use small pages.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 051b6158d1b7..58af734be25d 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -715,7 +715,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)

DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");

-   if (PageHighMem(page)) {
+   if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
unsigned long flags;

/* FIXME: use a bounce buffer */
@@ -860,7 +860,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, 
unsigned int bytes)

DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");

-   if (PageHighMem(page)) {
+   if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
unsigned long flags;

/* FIXME: use bounce buffer */
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index bb3f3297062a..7a17c166532f 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 

@@ -55,24 +56,34 @@ static inline struct page *kmap_to_page(void *addr)
  #ifndef ARCH_HAS_KMAP
  static inline void *kmap(struct page *page)
  {
+   void *kaddr;
+
might_sleep();
-   return page_address(page);
+   kaddr = page_address(page);
+   xpfo_kmap(kaddr, page);
+   return kaddr;
  }

  static inline void kunmap(struct page *page)
  {
+   xpfo_kunmap(page_address(page), page);
  }

  static inline void *kmap_atomic(struct page *page)
  {
+   void *kaddr;
+
preempt_disable();
pagefault_disable();
-   return page_address(page);
+   kaddr = page_address(page);
+   xpfo_kmap(kaddr, page);
+   return kaddr;
  }
  #define kmap_atomic_prot(page, prot)  kmap_atomic(page)

  static inline void __kunmap_atomic(void 

Re: [kernel-hardening] [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)

[ZhaoJunmin Zhao(Junmin)]

This patch adds support for XPFO which protects against 'ret2dir' kernel
attacks. The basic idea is to enforce exclusive ownership of page frames
by either the kernel or userspace, unless explicitly requested by the
kernel. Whenever a page destined for userspace is allocated, it is
unmapped from physmap (the kernel's page table). When such a page is
reclaimed from userspace, it is mapped back to physmap.

Additional fields in the page_ext struct are used for XPFO housekeeping.
Specifically two flags to distinguish user vs. kernel pages and to tag
unmapped pages and a reference counter to balance kmap/kunmap operations
and a lock to serialize access to the XPFO fields.

Known issues/limitations:
   - Only supports x86-64 (for now)
   - Only supports 4k pages (for now)
   - There are most likely some legitimate uses cases where the kernel needs
 to access userspace which need to be made XPFO-aware
   - Performance penalty

Reference paper by the original patch authors:
   http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf

Suggested-by: Vasileios P. Kemerlis 
Signed-off-by: Juerg Haefliger 
---
  arch/x86/Kconfig |   3 +-
  arch/x86/mm/init.c   |   2 +-
  drivers/ata/libata-sff.c |   4 +-
  include/linux/highmem.h  |  15 +++-
  include/linux/page_ext.h |   7 ++
  include/linux/xpfo.h |  39 +
  lib/swiotlb.c|   3 +-
  mm/Makefile  |   1 +
  mm/page_alloc.c  |   2 +
  mm/page_ext.c|   4 +
  mm/xpfo.c| 206 +++
  security/Kconfig |  19 +
  12 files changed, 298 insertions(+), 7 deletions(-)
  create mode 100644 include/linux/xpfo.h
  create mode 100644 mm/xpfo.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636d1065..38b334f8fde5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -165,6 +165,7 @@ config X86
select HAVE_STACK_VALIDATIONif X86_64
select ARCH_USES_HIGH_VMA_FLAGS if 
X86_INTEL_MEMORY_PROTECTION_KEYS
select ARCH_HAS_PKEYS   if 
X86_INTEL_MEMORY_PROTECTION_KEYS
+   select ARCH_SUPPORTS_XPFO   if X86_64

  config INSTRUCTION_DECODER
def_bool y
@@ -1361,7 +1362,7 @@ config ARCH_DMA_ADDR_T_64BIT

  config X86_DIRECT_GBPAGES
def_bool y
-   depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK
+   depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK && !XPFO
---help---
  Certain kernel features effectively disable kernel
  linear 1 GB mappings (even if the CPU otherwise
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 22af912d66d2..a6fafbae02bb 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -161,7 +161,7 @@ static int page_size_mask;

  static void __init probe_page_size_mask(void)
  {
-#if !defined(CONFIG_KMEMCHECK)
+#if !defined(CONFIG_KMEMCHECK) && !defined(CONFIG_XPFO)
/*
 * For CONFIG_KMEMCHECK or pagealloc debugging, identity mapping will
 * use small pages.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 051b6158d1b7..58af734be25d 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -715,7 +715,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)

DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");

-   if (PageHighMem(page)) {
+   if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
unsigned long flags;

/* FIXME: use a bounce buffer */
@@ -860,7 +860,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, 
unsigned int bytes)

DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");

-   if (PageHighMem(page)) {
+   if (PageHighMem(page) || xpfo_page_is_unmapped(page)) {
unsigned long flags;

/* FIXME: use bounce buffer */
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index bb3f3297062a..7a17c166532f 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 

@@ -55,24 +56,34 @@ static inline struct page *kmap_to_page(void *addr)
  #ifndef ARCH_HAS_KMAP
  static inline void *kmap(struct page *page)
  {
+   void *kaddr;
+
might_sleep();
-   return page_address(page);
+   kaddr = page_address(page);
+   xpfo_kmap(kaddr, page);
+   return kaddr;
  }

  static inline void kunmap(struct page *page)
  {
+   xpfo_kunmap(page_address(page), page);
  }

  static inline void *kmap_atomic(struct page *page)
  {
+   void *kaddr;
+
preempt_disable();
pagefault_disable();
-   return page_address(page);
+   kaddr = page_address(page);
+   xpfo_kmap(kaddr, page);
+   return kaddr;
  }
  #define kmap_atomic_prot(page, prot)  kmap_atomic(page)

  static inline void __kunmap_atomic(void *addr)
  {
+   xpfo_kunmap(addr, 

Re: [PATCH v4] USB hub_probe: rework ugly goto-into-compound-statement

[Baolin Wang]

Hi,

On 9 November 2016 at 23:35, Eugene Korenevsky  wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
>
> Changes since v3: fix typo
> Changes since v2: extract the code to static function
> Changes since v1: fix spaces instead of tab, add missing 'Signed-off-by'
>
> Signed-off-by: Eugene Korenevsky 
> ---
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..b770c8d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
> kref_put(>kref, hub_release);
>  }
>
> +static int hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> +   /* Some hubs have a subclass of 1, which AFAICT according to the */
> +   /*  specs is not defined, but it works */
> +   if (desc->desc.bInterfaceSubClass != 0 &&
> +   desc->desc.bInterfaceSubClass != 1)
> +   return 0;
> +
> +   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> +   if (desc->desc.bNumEndpoints != 1)
> +   return 0;

We usually return 0 as successful result, can you return kernel error
number if we check the descriptor failed? Or change the return value
of the function as bool type.

> +
> +   /* If it's not an interrupt in endpoint, we'd better punt! */
> +   return usb_endpoint_is_int_in(>endpoint[0].desc);
> +}
> +
>  static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
> *id)
>  {
> struct usb_host_interface *desc;
> -   struct usb_endpoint_descriptor *endpoint;
> struct usb_device *hdev;
> struct usb_hub *hub;
>
> @@ -1800,25 +1815,11 @@ static int hub_probe(struct usb_interface *intf, 
> const struct usb_device_id *id)
> }
>  #endif
>
> -   /* Some hubs have a subclass of 1, which AFAICT according to the */
> -   /*  specs is not defined, but it works */
> -   if ((desc->desc.bInterfaceSubClass != 0) &&
> -   (desc->desc.bInterfaceSubClass != 1)) {
> -descriptor_error:
> +   if (!hub_check_descriptor_sanity(desc)) {
> dev_err(>dev, "bad descriptor, ignoring hub\n");
> return -EIO;
> }
>
> -   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> -   if (desc->desc.bNumEndpoints != 1)
> -   goto descriptor_error;
> -
> -   endpoint = >endpoint[0].desc;
> -
> -   /* If it's not an interrupt in endpoint, we'd better punt! */
> -   if (!usb_endpoint_is_int_in(endpoint))
> -   goto descriptor_error;
> -
> /* We found a hub */
> dev_info(>dev, "USB hub found\n");
>
> @@ -1845,7 +1846,7 @@ static int hub_probe(struct usb_interface *intf, const 
> struct usb_device_id *id)
> if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
> hub->quirk_check_port_auto_suspend = 1;
>
> -   if (hub_configure(hub, endpoint) >= 0)
> +   if (hub_configure(hub, >endpoint[0].desc) >= 0)
> return 0;
>
> hub_disconnect(intf);
> --
> 2.10.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards

Re: [PATCH v4] USB hub_probe: rework ugly goto-into-compound-statement

[Baolin Wang]

Hi,

On 9 November 2016 at 23:35, Eugene Korenevsky  wrote:
> Rework smelling code (goto inside compound statement). Perhaps this is
> legacy. Anyway such code is not appropriate for Linux kernel.
>
> Changes since v3: fix typo
> Changes since v2: extract the code to static function
> Changes since v1: fix spaces instead of tab, add missing 'Signed-off-by'
>
> Signed-off-by: Eugene Korenevsky 
> ---
>  drivers/usb/core/hub.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index cbb1467..b770c8d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1722,10 +1722,25 @@ static void hub_disconnect(struct usb_interface *intf)
> kref_put(>kref, hub_release);
>  }
>
> +static int hub_check_descriptor_sanity(struct usb_host_interface *desc)
> +{
> +   /* Some hubs have a subclass of 1, which AFAICT according to the */
> +   /*  specs is not defined, but it works */
> +   if (desc->desc.bInterfaceSubClass != 0 &&
> +   desc->desc.bInterfaceSubClass != 1)
> +   return 0;
> +
> +   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> +   if (desc->desc.bNumEndpoints != 1)
> +   return 0;

We usually return 0 as successful result, can you return kernel error
number if we check the descriptor failed? Or change the return value
of the function as bool type.

> +
> +   /* If it's not an interrupt in endpoint, we'd better punt! */
> +   return usb_endpoint_is_int_in(>endpoint[0].desc);
> +}
> +
>  static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
> *id)
>  {
> struct usb_host_interface *desc;
> -   struct usb_endpoint_descriptor *endpoint;
> struct usb_device *hdev;
> struct usb_hub *hub;
>
> @@ -1800,25 +1815,11 @@ static int hub_probe(struct usb_interface *intf, 
> const struct usb_device_id *id)
> }
>  #endif
>
> -   /* Some hubs have a subclass of 1, which AFAICT according to the */
> -   /*  specs is not defined, but it works */
> -   if ((desc->desc.bInterfaceSubClass != 0) &&
> -   (desc->desc.bInterfaceSubClass != 1)) {
> -descriptor_error:
> +   if (!hub_check_descriptor_sanity(desc)) {
> dev_err(>dev, "bad descriptor, ignoring hub\n");
> return -EIO;
> }
>
> -   /* Multiple endpoints? What kind of mutant ninja-hub is this? */
> -   if (desc->desc.bNumEndpoints != 1)
> -   goto descriptor_error;
> -
> -   endpoint = >endpoint[0].desc;
> -
> -   /* If it's not an interrupt in endpoint, we'd better punt! */
> -   if (!usb_endpoint_is_int_in(endpoint))
> -   goto descriptor_error;
> -
> /* We found a hub */
> dev_info(>dev, "USB hub found\n");
>
> @@ -1845,7 +1846,7 @@ static int hub_probe(struct usb_interface *intf, const 
> struct usb_device_id *id)
> if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
> hub->quirk_check_port_auto_suspend = 1;
>
> -   if (hub_configure(hub, endpoint) >= 0)
> +   if (hub_configure(hub, >endpoint[0].desc) >= 0)
> return 0;
>
> hub_disconnect(intf);
> --
> 2.10.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards

[PATCH] dt-binding: remoteproc: Introduce ADSP loader binding

[Bjorn Andersson]

This document defines the binding for a component that loads firmware
and control the life cycle of the Qualcomm ADSP Hexagon core.

Cc: Sarangdhar Joshi 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Added the required "xo" clock, from Sarangdhar
- Added smd-edge node
- Corrected example

Changes since v1:
- Added platform names to compatible

 .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
new file mode 100644
index ..471946f2f080
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -0,0 +1,98 @@
+Qualcomm ADSP Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm ADSP Hexagon core.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8974-adsp-pil"
+   "qcom,msm8996-adsp-pil"
+
+- interrupts-extended:
+   Usage: required
+   Value type: 
+   Definition: must list the watchdog, fatal IRQs ready, handover and
+   stop-ack IRQs
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock to be held on behalf of the
+   booting Hexagon core
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo"
+
+- cx-supply:
+   Usage: required
+   Value type: 
+   Definition: reference to the regulator to be held on behalf of the
+   booting Hexagon core
+
+- memory-region:
+   Usage: required
+   Value type: 
+   Definition: reference to the reserved-memory for the ADSP
+
+- qcom,smem-states:
+   Usage: required
+   Value type: 
+   Definition: reference to the smem state for requesting the ADSP to
+   shut down
+
+- qcom,smem-state-names:
+   Usage: required
+   Value type: 
+   Definition: must be "stop"
+
+
+= SUBNODES
+The adsp node may have an subnode named "smd-edge" that describes the SMD edge,
+channels and devices related to the ADSP.  See ../soc/qcom/qcom,smd.txt for
+details on how to describe the SMD edge.
+
+
+= EXAMPLE
+The following example describes the resources needed to boot control the
+ADSP, as it is found on MSM8974 boards.
+
+   adsp {
+   compatible = "qcom,msm8974-adsp-pil";
+
+   interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+   clocks = < RPM_CXO_CLK>;
+   clock-names = "xo";
+
+   cx-supply = <_s2>;
+
+   memory-region = <_region>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   smd-edge {
+   interrupts = <0 156 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 8>;
+   qcom,smd-edge = <1>;
+   };
+   };
-- 
2.5.0

[PATCH] dt-binding: remoteproc: Introduce ADSP loader binding

[Bjorn Andersson]

This document defines the binding for a component that loads firmware
and control the life cycle of the Qualcomm ADSP Hexagon core.

Cc: Sarangdhar Joshi 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Added the required "xo" clock, from Sarangdhar
- Added smd-edge node
- Corrected example

Changes since v1:
- Added platform names to compatible

 .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
new file mode 100644
index ..471946f2f080
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -0,0 +1,98 @@
+Qualcomm ADSP Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm ADSP Hexagon core.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8974-adsp-pil"
+   "qcom,msm8996-adsp-pil"
+
+- interrupts-extended:
+   Usage: required
+   Value type: 
+   Definition: must list the watchdog, fatal IRQs ready, handover and
+   stop-ack IRQs
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock to be held on behalf of the
+   booting Hexagon core
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo"
+
+- cx-supply:
+   Usage: required
+   Value type: 
+   Definition: reference to the regulator to be held on behalf of the
+   booting Hexagon core
+
+- memory-region:
+   Usage: required
+   Value type: 
+   Definition: reference to the reserved-memory for the ADSP
+
+- qcom,smem-states:
+   Usage: required
+   Value type: 
+   Definition: reference to the smem state for requesting the ADSP to
+   shut down
+
+- qcom,smem-state-names:
+   Usage: required
+   Value type: 
+   Definition: must be "stop"
+
+
+= SUBNODES
+The adsp node may have an subnode named "smd-edge" that describes the SMD edge,
+channels and devices related to the ADSP.  See ../soc/qcom/qcom,smd.txt for
+details on how to describe the SMD edge.
+
+
+= EXAMPLE
+The following example describes the resources needed to boot control the
+ADSP, as it is found on MSM8974 boards.
+
+   adsp {
+   compatible = "qcom,msm8974-adsp-pil";
+
+   interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+   clocks = < RPM_CXO_CLK>;
+   clock-names = "xo";
+
+   cx-supply = <_s2>;
+
+   memory-region = <_region>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   smd-edge {
+   interrupts = <0 156 IRQ_TYPE_EDGE_RISING>;
+
+   qcom,ipc = < 8 8>;
+   qcom,smd-edge = <1>;
+   };
+   };
-- 
2.5.0

[PATCH v2 3/5] mfd: palmas: Reset the POWERHOLD mux during power off

[Keerthy]

POWERHOLD signal has higher priority  over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.

PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold.  Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.

Signed-off-by: Keerthy 
---

Changes in v2:

  * Changed pr_err to dev_err
  * removed redundant boolean variable override-powerhold

 drivers/mfd/palmas.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index ee9e9ea..da90124 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,6 +430,20 @@ static void palmas_power_off(void)
 {
unsigned int addr;
int ret, slave;
+   struct device_node *np = palmas_dev->dev->of_node;
+
+   if (of_property_read_bool(np, "ti,palmas-override-powerhold")) {
+   addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+   slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+   ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+   PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+   if (ret)
+   dev_err(palmas_dev->dev,
+   "Unable to write PRIMARY_SECONDARY_PAD2 %d\n",
+   ret);
+   }
 
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
-- 
1.9.1

[PATCH v2 3/5] mfd: palmas: Reset the POWERHOLD mux during power off

[Keerthy]

POWERHOLD signal has higher priority  over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.

PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold.  Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.

Signed-off-by: Keerthy 
---

Changes in v2:

  * Changed pr_err to dev_err
  * removed redundant boolean variable override-powerhold

 drivers/mfd/palmas.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index ee9e9ea..da90124 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,6 +430,20 @@ static void palmas_power_off(void)
 {
unsigned int addr;
int ret, slave;
+   struct device_node *np = palmas_dev->dev->of_node;
+
+   if (of_property_read_bool(np, "ti,palmas-override-powerhold")) {
+   addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+   slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+   ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+   PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+   if (ret)
+   dev_err(palmas_dev->dev,
+   "Unable to write PRIMARY_SECONDARY_PAD2 %d\n",
+   ret);
+   }
 
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
-- 
1.9.1

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.

[Wu-Cheng Li]

From: Wu-Cheng Li 

vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.

Signed-off-by: Wu-Cheng Li 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
 
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+   if (buf->index >= vq->num_buffers) {
+   mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+   return -EINVAL;
+   }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
-- 
2.8.0.rc3.226.g39d4020

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.

[Wu-Cheng Li]

From: Wu-Cheng Li 

vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.

Signed-off-by: Wu-Cheng Li 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
 
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+   if (buf->index >= vq->num_buffers) {
+   mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+   return -EINVAL;
+   }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
-- 
2.8.0.rc3.226.g39d4020

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf

[Wu-Cheng Li]

From: Wu-Cheng Li 

This patch adds a buffer index check in decoder vidioc_qbuf.

Wu-Cheng Li (1):
  mtk-vcodec: add index check in decoder vidioc_qbuf.

 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf

[Wu-Cheng Li]

From: Wu-Cheng Li 

This patch adds a buffer index check in decoder vidioc_qbuf.

Wu-Cheng Li (1):
  mtk-vcodec: add index check in decoder vidioc_qbuf.

 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 
 1 file changed, 4 insertions(+)

-- 
2.8.0.rc3.226.g39d4020

Re: [v16, 0/7] Fix eSDHC host version register bug

[Scott Wood]

On Thu, 2016-11-10 at 04:11 +, Y.B. Lu wrote:
> > 
> > -Original Message-
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> > net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> > 
> > > 
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux- ker...@vger.kernel.org; linux-clk;
> > > io...@lists.linux-foundation.org; net...@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > > 
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > > 
> > > > - i2c-list
> > > > 
> > > > On 9 November 2016 at 04:14, Yangbo Lu  wrote:
> > > > > 
> > > > > 
> > > > > This patchset is used to fix a host version register bug in the
> > > > > T4240-
> > > > > R1.0-R2.0
> > > > > eSDHC controller. To match the SoC version and revision, 15
> > > > > previous version patchsets had tried many methods but all of them
> > > > > were rejected by reviewers.
> > > > > Such as
> > > > > - dts compatible method
> > > > > - syscon method
> > > > > - ifdef PPC method
> > > > > - GUTS driver getting SVR method Anrd suggested a
> > > > > soc_device_match method in v10, and this is the only available
> > > > > method left now. This v11 patchset introduces the soc_device_match
> > > > > interface in soc driver.
> > > > > 
> > > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > > is used to register a soc device which contain soc version and
> > > > > revision information.
> > > > > The other three patches introduce the soc_device_match method in
> > > > > soc driver and apply it on esdhc driver to fix this bug.
> > > > > 
> > > > > ---
> > > > > Changes for v15:
> > > > > - Dropped patch 'dt: bindings: update Freescale DCFG
> > > compatible'
> > > > 
> > > > > 
> > > > >   since the work had been done by below patch on
> > > > > ShawnGuo's linux tree.
> > > > >   'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > > compatible for SCFG
> > > > >    and DCFG'
> > > > > - Fixed error code issue in guts driver Changes for v16:
> > > > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl'
> > > > 
> > > > > 
> > > > > - Added a bug-fix patch from Geert
> > > > > ---
> > > > > 
> > > > > Arnd Bergmann (1):
> > > > >   base: soc: introduce soc_device_match() interface
> > > > > 
> > > > > Geert Uytterhoeven (1):
> > > > >   base: soc: Check for NULL SoC device attributes
> > > > > 
> > > > > Yangbo Lu (5):
> > > > >   ARM64: dts: ls2080a: add device configuration node
> > > > >   dt: bindings: move guts devicetree doc out of powerpc directory
> > > > >   soc: fsl: add GUTS driver for QorIQ platforms
> > > > >   MAINTAINERS: add entry for Freescale SoC drivers
> > > > >   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > > > 
> > > > >  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
> > > > >  MAINTAINERS|  11 +-
> > > > >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
> > > > >  drivers/base/Kconfig   |   1 +
> > > > >  drivers/base/soc.c |  70 ++
> > > > >  drivers/mmc/host/Kconfig   |   1 +
> > > > >  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
> > > > >  drivers/soc/Kconfig|   3 +-
> > > > >  drivers/soc/fsl/Kconfig|  18 ++
> > > > >  drivers/soc/fsl/Makefile   |   1 +
> > > > >  drivers/soc/fsl/guts.c | 236
> > > > > +
> > > > >  include/linux/fsl/guts.h   | 125
> > > > > ++-
> > > > >  include/linux/sys_soc.h|   3 +
> > > > >  13 files changed, 447 insertions(+), 51 deletions(-)
> > > > >  rename Documentation/devicetree/bindings/{powerpc =>
> > > > > soc}/fsl/guts.txt
> > > 

Re: [v16, 0/7] Fix eSDHC host version register bug

[Scott Wood]

On Thu, 2016-11-10 at 04:11 +, Y.B. Lu wrote:
> > 
> > -Original Message-
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > ker...@vger.kernel.org; linux-clk; io...@lists.linux-foundation.org;
> > net...@vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> > 
> > > 
> > > -Original Message-
> > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org;
> > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux- ker...@vger.kernel.org; linux-clk;
> > > io...@lists.linux-foundation.org; net...@vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > > 
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > > 
> > > > - i2c-list
> > > > 
> > > > On 9 November 2016 at 04:14, Yangbo Lu  wrote:
> > > > > 
> > > > > 
> > > > > This patchset is used to fix a host version register bug in the
> > > > > T4240-
> > > > > R1.0-R2.0
> > > > > eSDHC controller. To match the SoC version and revision, 15
> > > > > previous version patchsets had tried many methods but all of them
> > > > > were rejected by reviewers.
> > > > > Such as
> > > > > - dts compatible method
> > > > > - syscon method
> > > > > - ifdef PPC method
> > > > > - GUTS driver getting SVR method Anrd suggested a
> > > > > soc_device_match method in v10, and this is the only available
> > > > > method left now. This v11 patchset introduces the soc_device_match
> > > > > interface in soc driver.
> > > > > 
> > > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > > is used to register a soc device which contain soc version and
> > > > > revision information.
> > > > > The other three patches introduce the soc_device_match method in
> > > > > soc driver and apply it on esdhc driver to fix this bug.
> > > > > 
> > > > > ---
> > > > > Changes for v15:
> > > > > - Dropped patch 'dt: bindings: update Freescale DCFG
> > > compatible'
> > > > 
> > > > > 
> > > > >   since the work had been done by below patch on
> > > > > ShawnGuo's linux tree.
> > > > >   'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > > compatible for SCFG
> > > > >    and DCFG'
> > > > > - Fixed error code issue in guts driver Changes for v16:
> > > > > - Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl'
> > > > 
> > > > > 
> > > > > - Added a bug-fix patch from Geert
> > > > > ---
> > > > > 
> > > > > Arnd Bergmann (1):
> > > > >   base: soc: introduce soc_device_match() interface
> > > > > 
> > > > > Geert Uytterhoeven (1):
> > > > >   base: soc: Check for NULL SoC device attributes
> > > > > 
> > > > > Yangbo Lu (5):
> > > > >   ARM64: dts: ls2080a: add device configuration node
> > > > >   dt: bindings: move guts devicetree doc out of powerpc directory
> > > > >   soc: fsl: add GUTS driver for QorIQ platforms
> > > > >   MAINTAINERS: add entry for Freescale SoC drivers
> > > > >   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > > > 
> > > > >  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
> > > > >  MAINTAINERS|  11 +-
> > > > >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
> > > > >  drivers/base/Kconfig   |   1 +
> > > > >  drivers/base/soc.c |  70 ++
> > > > >  drivers/mmc/host/Kconfig   |   1 +
> > > > >  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
> > > > >  drivers/soc/Kconfig|   3 +-
> > > > >  drivers/soc/fsl/Kconfig|  18 ++
> > > > >  drivers/soc/fsl/Makefile   |   1 +
> > > > >  drivers/soc/fsl/guts.c | 236
> > > > > +
> > > > >  include/linux/fsl/guts.h   | 125
> > > > > ++-
> > > > >  include/linux/sys_soc.h|   3 +
> > > > >  13 files changed, 447 insertions(+), 51 deletions(-)
> > > > >  rename Documentation/devicetree/bindings/{powerpc =>
> > > > > soc}/fsl/guts.txt
> > > > > (91%)
> > > > > 

[PATCH V4 9/9] PM / OPP: Don't assume platform doesn't have regulators

[Viresh Kumar]

If the regulators aren't set explicitly by the platform, the OPP core
assumes that the platform doesn't have any regulator and uses the
clk-only callback.

If the platform failed to register a regulator with the core, then this
can turn out to be a dangerous assumption as the OPP core will try to
change clk without changing regulators.

Handle that properly by making sure that the DT didn't have any entries
for supply voltages as well.

Signed-off-by: Viresh Kumar 
---
V4:
- s/had/have
- fix missing rcu_read_unlock()

 drivers/base/power/opp/core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 3298fac01bb0..cb33f8b2b56d 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -734,7 +734,20 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 
/* Only frequency scaling */
if (!regulators) {
+   unsigned long u_volt = opp->supplies[0].u_volt;
+
rcu_read_unlock();
+
+   /*
+* DT contained supply ratings? Consider platform failed to set
+* regulators.
+*/
+   if (unlikely(u_volt)) {
+   dev_err(dev, "%s: Regulator not registered with OPP 
core\n",
+   __func__);
+   return -EINVAL;
+   }
+
return _generic_set_opp_clk_only(dev, clk, old_freq, freq);
}
 
-- 
2.7.1.410.g6faf27b

[PATCH V4 9/9] PM / OPP: Don't assume platform doesn't have regulators

[Viresh Kumar]

If the regulators aren't set explicitly by the platform, the OPP core
assumes that the platform doesn't have any regulator and uses the
clk-only callback.

If the platform failed to register a regulator with the core, then this
can turn out to be a dangerous assumption as the OPP core will try to
change clk without changing regulators.

Handle that properly by making sure that the DT didn't have any entries
for supply voltages as well.

Signed-off-by: Viresh Kumar 
---
V4:
- s/had/have
- fix missing rcu_read_unlock()

 drivers/base/power/opp/core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 3298fac01bb0..cb33f8b2b56d 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -734,7 +734,20 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 
/* Only frequency scaling */
if (!regulators) {
+   unsigned long u_volt = opp->supplies[0].u_volt;
+
rcu_read_unlock();
+
+   /*
+* DT contained supply ratings? Consider platform failed to set
+* regulators.
+*/
+   if (unlikely(u_volt)) {
+   dev_err(dev, "%s: Regulator not registered with OPP 
core\n",
+   __func__);
+   return -EINVAL;
+   }
+
return _generic_set_opp_clk_only(dev, clk, old_freq, freq);
}
 
-- 
2.7.1.410.g6faf27b

[PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property

[Keerthy]

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 03cec62..6e7db63 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -57,6 +57,7 @@
#interrupt-cells = <2>;
interrupt-controller;
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
-- 
1.9.1

Re: task isolation discussion at Linux Plumbers

[Paul E. McKenney]

On Wed, Nov 09, 2016 at 08:52:13PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote:
> > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney
> >  wrote:
> > 
> > Are you planning on changing rcu_nmi_enter()?  It would make it easier
> > to figure out how they interact if I could see the code.
> 
> It already calls rcu_dynticks_eqs_exit(), courtesy of the earlier
> consolidation patches.
> 
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index dbf20b058f48..342c8ee402d6 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > 
> > 
> > >  /*
> > > @@ -305,17 +318,22 @@ static void rcu_dynticks_eqs_enter(void)
> > >  static void rcu_dynticks_eqs_exit(void)
> > >  {
> > > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > > +   int seq;
> > >
> > > /*
> > > -* CPUs seeing atomic_inc() must see prior idle sojourns,
> > > +* CPUs seeing atomic_inc_return() must see prior idle sojourns,
> > >  * and we also must force ordering with the next RCU read-side
> > >  * critical section.
> > >  */
> > > -   smp_mb__before_atomic(); /* See above. */
> > > -   atomic_inc(>dynticks);
> > > -   smp_mb__after_atomic(); /* See above. */
> > > +   seq = atomic_inc_return(>dynticks);
> > > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > > -!(atomic_read(>dynticks) & 0x1));
> > > +!(seq & RCU_DYNTICK_CTRL_CTR));
> > 
> > I think there's still a race here.  Suppose we're running this code on
> > cpu n and...
> > 
> > > +   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > > +   rcu_eqs_special_exit();
> > > +   /* Prefer duplicate flushes to losing a flush. */
> > > +   smp_mb__before_atomic(); /* NMI safety. */
> > 
> > ... another CPU changes the page tables and calls rcu_eqs_special_set(n) 
> > here.
> 
> But then rcu_eqs_special_set() will return false because we already
> exited the extended quiescent state at the atomic_inc_return() above.
> 
> That should tell the caller to send an IPI.
> 
> > That CPU expects that we will flush prior to continuing, but we won't.
> > Admittedly it's highly unlikely that any stale TLB entries would be
> > created yet, but nothing rules it out.
> 
> That said, 0day is having some heartburn from this, so I must have broken
> something somewhere.  My own tests of course complete just fine...
> 
> > > +   atomic_and(~RCU_DYNTICK_CTRL_MASK, >dynticks);
> > > +   }
> > 
> > Maybe the way to handle it is something like:
> > 
> > this_cpu_write(rcu_nmi_needs_eqs_special, 1);
> > barrier();
> > 
> > /* NMI here will call rcu_eqs_special_exit() regardless of the value
> > in dynticks */
> > 
> > atomic_and(...);
> > smp_mb__after_atomic();
> > rcu_eqs_special_exit();
> > 
> > barrier();
> > this_cpu_write(rcu_nmi_needs_eqs_special, 0);
> > 
> > 
> > Then rcu_nmi_enter() would call rcu_eqs_special_exit() if the dynticks
> > bit is set *or* rcu_nmi_needs_eqs_special is set.
> > 
> > Does that make sense?
> 
> I believe that rcu_eqs_special_set() returning false covers this, but
> could easily be missing something.

And fixing a couple of stupid errors might help.  Probably more where
those came from...

Thanx, Paul



commit 0ea13930e9a89b1741897f5af308692eab08d9e8
Author: Paul E. McKenney 
Date:   Tue Nov 8 14:25:21 2016 -0800

rcu: Maintain special bits at bottom of ->dynticks counter

Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change.  This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings.  It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to do the flush, first to avoid
interrupting usemode tasks and second to handle multiple flush requests
with a single flush in the case of a long-running user task.

This commit therefore reserves a bit at the bottom of the ->dynticks
counter, which is checked upon exit from extended quiescent states.
If it is set, it is cleared and then a new rcu_eqs_special_exit() macro is
invoked, which, if not supplied, is an empty single-pass do-while loop.
If this bottom bit is set on -entry- to an extended quiescent state,
then a WARN_ON_ONCE() triggers.

This bottom bit may be set using a new rcu_eqs_special_set() function,
which returns true if the bit was set, or false if the CPU turned
out to not be in an extended quiescent state.  Please note that 

[PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Keerthy]

GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297b..c28d4eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:
-- 
1.9.1

[PATCH v2 5/5] arm: dts: am57xx-idk-common: Add overide powerhold property

[Keerthy]

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 03cec62..6e7db63 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -57,6 +57,7 @@
#interrupt-cells = <2>;
interrupt-controller;
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
-- 
1.9.1

Re: task isolation discussion at Linux Plumbers

[Paul E. McKenney]

On Wed, Nov 09, 2016 at 08:52:13PM -0800, Paul E. McKenney wrote:
> On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote:
> > On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney
> >  wrote:
> > 
> > Are you planning on changing rcu_nmi_enter()?  It would make it easier
> > to figure out how they interact if I could see the code.
> 
> It already calls rcu_dynticks_eqs_exit(), courtesy of the earlier
> consolidation patches.
> 
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index dbf20b058f48..342c8ee402d6 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > 
> > 
> > >  /*
> > > @@ -305,17 +318,22 @@ static void rcu_dynticks_eqs_enter(void)
> > >  static void rcu_dynticks_eqs_exit(void)
> > >  {
> > > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > > +   int seq;
> > >
> > > /*
> > > -* CPUs seeing atomic_inc() must see prior idle sojourns,
> > > +* CPUs seeing atomic_inc_return() must see prior idle sojourns,
> > >  * and we also must force ordering with the next RCU read-side
> > >  * critical section.
> > >  */
> > > -   smp_mb__before_atomic(); /* See above. */
> > > -   atomic_inc(>dynticks);
> > > -   smp_mb__after_atomic(); /* See above. */
> > > +   seq = atomic_inc_return(>dynticks);
> > > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > > -!(atomic_read(>dynticks) & 0x1));
> > > +!(seq & RCU_DYNTICK_CTRL_CTR));
> > 
> > I think there's still a race here.  Suppose we're running this code on
> > cpu n and...
> > 
> > > +   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > > +   rcu_eqs_special_exit();
> > > +   /* Prefer duplicate flushes to losing a flush. */
> > > +   smp_mb__before_atomic(); /* NMI safety. */
> > 
> > ... another CPU changes the page tables and calls rcu_eqs_special_set(n) 
> > here.
> 
> But then rcu_eqs_special_set() will return false because we already
> exited the extended quiescent state at the atomic_inc_return() above.
> 
> That should tell the caller to send an IPI.
> 
> > That CPU expects that we will flush prior to continuing, but we won't.
> > Admittedly it's highly unlikely that any stale TLB entries would be
> > created yet, but nothing rules it out.
> 
> That said, 0day is having some heartburn from this, so I must have broken
> something somewhere.  My own tests of course complete just fine...
> 
> > > +   atomic_and(~RCU_DYNTICK_CTRL_MASK, >dynticks);
> > > +   }
> > 
> > Maybe the way to handle it is something like:
> > 
> > this_cpu_write(rcu_nmi_needs_eqs_special, 1);
> > barrier();
> > 
> > /* NMI here will call rcu_eqs_special_exit() regardless of the value
> > in dynticks */
> > 
> > atomic_and(...);
> > smp_mb__after_atomic();
> > rcu_eqs_special_exit();
> > 
> > barrier();
> > this_cpu_write(rcu_nmi_needs_eqs_special, 0);
> > 
> > 
> > Then rcu_nmi_enter() would call rcu_eqs_special_exit() if the dynticks
> > bit is set *or* rcu_nmi_needs_eqs_special is set.
> > 
> > Does that make sense?
> 
> I believe that rcu_eqs_special_set() returning false covers this, but
> could easily be missing something.

And fixing a couple of stupid errors might help.  Probably more where
those came from...

Thanx, Paul



commit 0ea13930e9a89b1741897f5af308692eab08d9e8
Author: Paul E. McKenney 
Date:   Tue Nov 8 14:25:21 2016 -0800

rcu: Maintain special bits at bottom of ->dynticks counter

Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change.  This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings.  It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to do the flush, first to avoid
interrupting usemode tasks and second to handle multiple flush requests
with a single flush in the case of a long-running user task.

This commit therefore reserves a bit at the bottom of the ->dynticks
counter, which is checked upon exit from extended quiescent states.
If it is set, it is cleared and then a new rcu_eqs_special_exit() macro is
invoked, which, if not supplied, is an empty single-pass do-while loop.
If this bottom bit is set on -entry- to an extended quiescent state,
then a WARN_ON_ONCE() triggers.

This bottom bit may be set using a new rcu_eqs_special_set() function,
which returns true if the bit was set, or false if the CPU turned
out to not be in an extended quiescent state.  Please note that this
function refuses to set the bit for a 

[PATCH v2 1/5] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Keerthy]

GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297b..c28d4eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.
 
 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:
-- 
1.9.1

[PATCH v2 2/5] mfd: palmas: Remove redundant check in palmas_power_off

[Keerthy]

palmas_dev and palmas_power_off are always assigned together.
So the check for palmas_dev inside palmas_power_off function
is redundant. Removing the same.

Signed-off-by: Keerthy 
---
 drivers/mfd/palmas.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb..ee9e9ea 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -431,9 +431,6 @@ static void palmas_power_off(void)
unsigned int addr;
int ret, slave;
 
-   if (!palmas_dev)
-   return;
-
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
 
-- 
1.9.1

[PATCH v2 2/5] mfd: palmas: Remove redundant check in palmas_power_off

[Keerthy]

palmas_dev and palmas_power_off are always assigned together.
So the check for palmas_dev inside palmas_power_off function
is redundant. Removing the same.

Signed-off-by: Keerthy 
---
 drivers/mfd/palmas.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb..ee9e9ea 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -431,9 +431,6 @@ static void palmas_power_off(void)
unsigned int addr;
int ret, slave;
 
-   if (!palmas_dev)
-   return;
-
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
 
-- 
1.9.1

[PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property

[Keerthy]

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 6df7829..78bee26 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -204,6 +204,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
-- 
1.9.1

[PATCH v2 0/5] mfd: palmas: add powerhold overriding during power off

[Keerthy]

The series lets one over powerhold for pmic.
The powerhold is used to keep the pmic power on even
after the DEV_CTRL On bit is set to off.

Tested on am572x-idk board, dra72-evm, dra7-evm for poweroff. 

Keerthy (5):
  Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override
property definition
  mfd: palmas: Remove redundant check in palmas_power_off
  mfd: palmas: Reset the POWERHOLD mux during power off
  arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
  arm: dts: am57xx-idk-common: Add overide powerhold property

 .../devicetree/bindings/pinctrl/pinctrl-palmas.txt|  9 +
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi   |  1 +
 arch/arm/boot/dts/am57xx-idk-common.dtsi  |  1 +
 drivers/mfd/palmas.c  | 15 +--
 4 files changed, 24 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property

[Keerthy]

The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.

Signed-off-by: Keerthy 
---
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 6df7829..78bee26 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -204,6 +204,7 @@
interrupt-controller;
 
ti,system-power-controller;
+   ti,palmas-override-powerhold;
 
tps659038_pmic {
compatible = "ti,tps659038-pmic";
-- 
1.9.1

[PATCH v2 0/5] mfd: palmas: add powerhold overriding during power off

[Keerthy]

The series lets one over powerhold for pmic.
The powerhold is used to keep the pmic power on even
after the DEV_CTRL On bit is set to off.

Tested on am572x-idk board, dra72-evm, dra7-evm for poweroff. 

Keerthy (5):
  Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override
property definition
  mfd: palmas: Remove redundant check in palmas_power_off
  mfd: palmas: Reset the POWERHOLD mux during power off
  arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
  arm: dts: am57xx-idk-common: Add overide powerhold property

 .../devicetree/bindings/pinctrl/pinctrl-palmas.txt|  9 +
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi   |  1 +
 arch/arm/boot/dts/am57xx-idk-common.dtsi  |  1 +
 drivers/mfd/palmas.c  | 15 +--
 4 files changed, 24 insertions(+), 2 deletions(-)

-- 
1.9.1

Re: task isolation discussion at Linux Plumbers

[Paul E. McKenney]

On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote:
> On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney
>  wrote:
> 
> Are you planning on changing rcu_nmi_enter()?  It would make it easier
> to figure out how they interact if I could see the code.

It already calls rcu_dynticks_eqs_exit(), courtesy of the earlier
consolidation patches.

> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index dbf20b058f48..342c8ee402d6 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> 
> 
> >  /*
> > @@ -305,17 +318,22 @@ static void rcu_dynticks_eqs_enter(void)
> >  static void rcu_dynticks_eqs_exit(void)
> >  {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > +   int seq;
> >
> > /*
> > -* CPUs seeing atomic_inc() must see prior idle sojourns,
> > +* CPUs seeing atomic_inc_return() must see prior idle sojourns,
> >  * and we also must force ordering with the next RCU read-side
> >  * critical section.
> >  */
> > -   smp_mb__before_atomic(); /* See above. */
> > -   atomic_inc(>dynticks);
> > -   smp_mb__after_atomic(); /* See above. */
> > +   seq = atomic_inc_return(>dynticks);
> > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > -!(atomic_read(>dynticks) & 0x1));
> > +!(seq & RCU_DYNTICK_CTRL_CTR));
> 
> I think there's still a race here.  Suppose we're running this code on
> cpu n and...
> 
> > +   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > +   rcu_eqs_special_exit();
> > +   /* Prefer duplicate flushes to losing a flush. */
> > +   smp_mb__before_atomic(); /* NMI safety. */
> 
> ... another CPU changes the page tables and calls rcu_eqs_special_set(n) here.

But then rcu_eqs_special_set() will return false because we already
exited the extended quiescent state at the atomic_inc_return() above.

That should tell the caller to send an IPI.

> That CPU expects that we will flush prior to continuing, but we won't.
> Admittedly it's highly unlikely that any stale TLB entries would be
> created yet, but nothing rules it out.

That said, 0day is having some heartburn from this, so I must have broken
something somewhere.  My own tests of course complete just fine...

> > +   atomic_and(~RCU_DYNTICK_CTRL_MASK, >dynticks);
> > +   }
> 
> Maybe the way to handle it is something like:
> 
> this_cpu_write(rcu_nmi_needs_eqs_special, 1);
> barrier();
> 
> /* NMI here will call rcu_eqs_special_exit() regardless of the value
> in dynticks */
> 
> atomic_and(...);
> smp_mb__after_atomic();
> rcu_eqs_special_exit();
> 
> barrier();
> this_cpu_write(rcu_nmi_needs_eqs_special, 0);
> 
> 
> Then rcu_nmi_enter() would call rcu_eqs_special_exit() if the dynticks
> bit is set *or* rcu_nmi_needs_eqs_special is set.
> 
> Does that make sense?

I believe that rcu_eqs_special_set() returning false covers this, but
could easily be missing something.

Thanx, Paul

Re: task isolation discussion at Linux Plumbers

[Paul E. McKenney]

On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote:
> On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney
>  wrote:
> 
> Are you planning on changing rcu_nmi_enter()?  It would make it easier
> to figure out how they interact if I could see the code.

It already calls rcu_dynticks_eqs_exit(), courtesy of the earlier
consolidation patches.

> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index dbf20b058f48..342c8ee402d6 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> 
> 
> >  /*
> > @@ -305,17 +318,22 @@ static void rcu_dynticks_eqs_enter(void)
> >  static void rcu_dynticks_eqs_exit(void)
> >  {
> > struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
> > +   int seq;
> >
> > /*
> > -* CPUs seeing atomic_inc() must see prior idle sojourns,
> > +* CPUs seeing atomic_inc_return() must see prior idle sojourns,
> >  * and we also must force ordering with the next RCU read-side
> >  * critical section.
> >  */
> > -   smp_mb__before_atomic(); /* See above. */
> > -   atomic_inc(>dynticks);
> > -   smp_mb__after_atomic(); /* See above. */
> > +   seq = atomic_inc_return(>dynticks);
> > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > -!(atomic_read(>dynticks) & 0x1));
> > +!(seq & RCU_DYNTICK_CTRL_CTR));
> 
> I think there's still a race here.  Suppose we're running this code on
> cpu n and...
> 
> > +   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > +   rcu_eqs_special_exit();
> > +   /* Prefer duplicate flushes to losing a flush. */
> > +   smp_mb__before_atomic(); /* NMI safety. */
> 
> ... another CPU changes the page tables and calls rcu_eqs_special_set(n) here.

But then rcu_eqs_special_set() will return false because we already
exited the extended quiescent state at the atomic_inc_return() above.

That should tell the caller to send an IPI.

> That CPU expects that we will flush prior to continuing, but we won't.
> Admittedly it's highly unlikely that any stale TLB entries would be
> created yet, but nothing rules it out.

That said, 0day is having some heartburn from this, so I must have broken
something somewhere.  My own tests of course complete just fine...

> > +   atomic_and(~RCU_DYNTICK_CTRL_MASK, >dynticks);
> > +   }
> 
> Maybe the way to handle it is something like:
> 
> this_cpu_write(rcu_nmi_needs_eqs_special, 1);
> barrier();
> 
> /* NMI here will call rcu_eqs_special_exit() regardless of the value
> in dynticks */
> 
> atomic_and(...);
> smp_mb__after_atomic();
> rcu_eqs_special_exit();
> 
> barrier();
> this_cpu_write(rcu_nmi_needs_eqs_special, 0);
> 
> 
> Then rcu_nmi_enter() would call rcu_eqs_special_exit() if the dynticks
> bit is set *or* rcu_nmi_needs_eqs_special is set.
> 
> Does that make sense?

I believe that rcu_eqs_special_set() returning false covers this, but
could easily be missing something.

Thanx, Paul

[PATCH][RFC v7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

[Chen Yu]

Previously we encountered some memory overflow issues due to
the bogus sleep time brought by inconsistent rtc, which is
triggered when pm_trace is enabled, and we have fixed it
in recent kernel. However it's improper in the first place
to call __timekeeping_inject_sleeptime() in case that pm_trace
is enabled simply because that "hash" time value will wreckage
the timekeeping subsystem.

This patch is originally written by Thomas, which would bypass
the bogus rtc interval when pm_trace is enabled.
Meanwhile, if system succeed to resume back with pm_trace set, the
users are warned to adjust the bogus rtc either by ntp-date or rdate,
by resetting pm_trace_rtc_abused to false, otherwise above tools might
not work as expected.

Originally-from: Thomas Gleixner 
Cc: "Rafael J. Wysocki" 
Cc: John Stultz 
Cc: Xunlei Pang 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: "H. Peter Anvin" 
Cc: Pavel Machek 
Cc: Thomas Gleixner 
Signed-off-by: Chen Yu 
---
 arch/x86/kernel/rtc.c   |  9 +
 drivers/base/power/trace.c  | 27 +++
 drivers/rtc/rtc-cmos.c  |  7 +++
 include/linux/mc146818rtc.h |  1 +
 include/linux/pm-trace.h|  9 -
 5 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 79c6311c..898383c 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -64,6 +64,15 @@ void mach_get_cmos_time(struct timespec *now)
unsigned int status, year, mon, day, hour, min, sec, century = 0;
unsigned long flags;
 
+   /*
+* If pm trace abused the RTC as storage set the timespec to 0
+* which tells the caller that this RTC value is bogus.
+*/
+   if (!pm_trace_rtc_valid()) {
+   now->tv_sec = now->tv_nsec = 0;
+   return;
+   }
+
spin_lock_irqsave(_lock, flags);
 
/*
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c
index efec10b..209e214 100644
--- a/drivers/base/power/trace.c
+++ b/drivers/base/power/trace.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -74,6 +75,9 @@
 
 #define DEVSEED (7919)
 
+bool pm_trace_rtc_abused __read_mostly;
+EXPORT_SYMBOL(pm_trace_rtc_abused);
+
 static unsigned int dev_hash_value;
 
 static int set_magic_time(unsigned int user, unsigned int file, unsigned int 
device)
@@ -104,6 +108,7 @@ static int set_magic_time(unsigned int user, unsigned int 
file, unsigned int dev
time.tm_min = (n % 20) * 3;
n /= 20;
mc146818_set_time();
+   pm_trace_rtc_abused = true;
return n ? -1 : 0;
 }
 
@@ -238,10 +243,32 @@ int show_trace_dev_match(char *buf, size_t size)
device_pm_unlock();
return ret;
 }
+static int pm_trace_notify(struct notifier_block *nb,
+   unsigned long mode, void *_unused)
+{
+   switch (mode) {
+   case PM_POST_HIBERNATION:
+   case PM_POST_SUSPEND:
+   if (pm_trace_rtc_abused) {
+   pm_trace_rtc_abused = false;
+   pr_warn("Possible incorrect RTC due to pm_trace,"
+   "please use ntp-date or rdate to reset.\n");
+   }
+   break;
+   default:
+   break;
+   }
+   return 0;
+}
+
+static struct notifier_block pm_trace_nb = {
+   .notifier_call = pm_trace_notify,
+};
 
 static int early_resume_init(void)
 {
hash_value_early_read = read_magic_time();
+   register_pm_notifier(_trace_nb);
return 0;
 }
 
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index dd3d598..3d9aedc 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -191,6 +191,13 @@ static inline void cmos_write_bank2(unsigned char val, 
unsigned char addr)
 
 static int cmos_read_time(struct device *dev, struct rtc_time *t)
 {
+   /*
+* If pmtrace abused the RTC for storage tell the caller that it is
+* unusable.
+*/
+   if (!pm_trace_rtc_valid())
+   return -EIO;
+
/* REVISIT:  if the clock has a "century" register, use
 * that instead of the heuristic in mc146818_get_time().
 * That'll make Y3K compatility (year > 2070) easy!
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index a585b4b..0661af1 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -16,6 +16,7 @@
 #include/* register access macros */
 #include 
 #include 
+#include 
 
 #ifdef __KERNEL__
 #include /* spinlock_t */
diff --git a/include/linux/pm-trace.h b/include/linux/pm-trace.h
index ecbde7a..7b78793 100644
--- a/include/linux/pm-trace.h
+++ b/include/linux/pm-trace.h
@@ -1,11 +1,17 @@
 #ifndef PM_TRACE_H
 #define PM_TRACE_H
 

[PATCH][RFC v7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

[Chen Yu]

Previously we encountered some memory overflow issues due to
the bogus sleep time brought by inconsistent rtc, which is
triggered when pm_trace is enabled, and we have fixed it
in recent kernel. However it's improper in the first place
to call __timekeeping_inject_sleeptime() in case that pm_trace
is enabled simply because that "hash" time value will wreckage
the timekeeping subsystem.

This patch is originally written by Thomas, which would bypass
the bogus rtc interval when pm_trace is enabled.
Meanwhile, if system succeed to resume back with pm_trace set, the
users are warned to adjust the bogus rtc either by ntp-date or rdate,
by resetting pm_trace_rtc_abused to false, otherwise above tools might
not work as expected.

Originally-from: Thomas Gleixner 
Cc: "Rafael J. Wysocki" 
Cc: John Stultz 
Cc: Xunlei Pang 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: "H. Peter Anvin" 
Cc: Pavel Machek 
Cc: Thomas Gleixner 
Signed-off-by: Chen Yu 
---
 arch/x86/kernel/rtc.c   |  9 +
 drivers/base/power/trace.c  | 27 +++
 drivers/rtc/rtc-cmos.c  |  7 +++
 include/linux/mc146818rtc.h |  1 +
 include/linux/pm-trace.h|  9 -
 5 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 79c6311c..898383c 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -64,6 +64,15 @@ void mach_get_cmos_time(struct timespec *now)
unsigned int status, year, mon, day, hour, min, sec, century = 0;
unsigned long flags;
 
+   /*
+* If pm trace abused the RTC as storage set the timespec to 0
+* which tells the caller that this RTC value is bogus.
+*/
+   if (!pm_trace_rtc_valid()) {
+   now->tv_sec = now->tv_nsec = 0;
+   return;
+   }
+
spin_lock_irqsave(_lock, flags);
 
/*
diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c
index efec10b..209e214 100644
--- a/drivers/base/power/trace.c
+++ b/drivers/base/power/trace.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -74,6 +75,9 @@
 
 #define DEVSEED (7919)
 
+bool pm_trace_rtc_abused __read_mostly;
+EXPORT_SYMBOL(pm_trace_rtc_abused);
+
 static unsigned int dev_hash_value;
 
 static int set_magic_time(unsigned int user, unsigned int file, unsigned int 
device)
@@ -104,6 +108,7 @@ static int set_magic_time(unsigned int user, unsigned int 
file, unsigned int dev
time.tm_min = (n % 20) * 3;
n /= 20;
mc146818_set_time();
+   pm_trace_rtc_abused = true;
return n ? -1 : 0;
 }
 
@@ -238,10 +243,32 @@ int show_trace_dev_match(char *buf, size_t size)
device_pm_unlock();
return ret;
 }
+static int pm_trace_notify(struct notifier_block *nb,
+   unsigned long mode, void *_unused)
+{
+   switch (mode) {
+   case PM_POST_HIBERNATION:
+   case PM_POST_SUSPEND:
+   if (pm_trace_rtc_abused) {
+   pm_trace_rtc_abused = false;
+   pr_warn("Possible incorrect RTC due to pm_trace,"
+   "please use ntp-date or rdate to reset.\n");
+   }
+   break;
+   default:
+   break;
+   }
+   return 0;
+}
+
+static struct notifier_block pm_trace_nb = {
+   .notifier_call = pm_trace_notify,
+};
 
 static int early_resume_init(void)
 {
hash_value_early_read = read_magic_time();
+   register_pm_notifier(_trace_nb);
return 0;
 }
 
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index dd3d598..3d9aedc 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -191,6 +191,13 @@ static inline void cmos_write_bank2(unsigned char val, 
unsigned char addr)
 
 static int cmos_read_time(struct device *dev, struct rtc_time *t)
 {
+   /*
+* If pmtrace abused the RTC for storage tell the caller that it is
+* unusable.
+*/
+   if (!pm_trace_rtc_valid())
+   return -EIO;
+
/* REVISIT:  if the clock has a "century" register, use
 * that instead of the heuristic in mc146818_get_time().
 * That'll make Y3K compatility (year > 2070) easy!
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index a585b4b..0661af1 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -16,6 +16,7 @@
 #include/* register access macros */
 #include 
 #include 
+#include 
 
 #ifdef __KERNEL__
 #include /* spinlock_t */
diff --git a/include/linux/pm-trace.h b/include/linux/pm-trace.h
index ecbde7a..7b78793 100644
--- a/include/linux/pm-trace.h
+++ b/include/linux/pm-trace.h
@@ -1,11 +1,17 @@
 #ifndef PM_TRACE_H
 #define PM_TRACE_H
 
+#include 
 #ifdef CONFIG_PM_TRACE
 #include 
-#include 
 
 extern int pm_trace_enabled;
+extern bool pm_trace_rtc_abused;
+
+static inline bool pm_trace_rtc_valid(void)
+{
+   return 

[GIT PULL] xfs: updates for 4.9-rc5

[Dave Chinner]

Hi Linus,

Can you please pull the XFS fix from the tag below. It's a fix for
an unmount hang (regression) when the filesystem is shutdown. It
was supposed to go to you for -rc3, but I accidentally tagged the
commit prior to it in that pullreq.

Thanks,

-Dave.

The following changes since commit c17a8ef43d6b80ed3519b828c37d18645445949f:

  xfs: clear cowblocks tag when cow fork is emptied (2016-10-24 14:21:08 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git 
tags/xfs-fixes-for-linus-4.9-rc5

for you to fetch changes up to b77428b12b55437b28deae738d9ce8b2e0663b55:

  xfs: defer should abort intent items if the trans roll fails (2016-10-24 
14:21:18 +1100)


xfs: update for 4.9-rc5

In this update:
o fix for aborting deferred transactions on filesystem shutdown.


Darrick J. Wong (1):
  xfs: defer should abort intent items if the trans roll fails

 fs/xfs/libxfs/xfs_defer.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)
-- 
Dave Chinner
da...@fromorbit.com

[GIT PULL] xfs: updates for 4.9-rc5

[Dave Chinner]

Hi Linus,

Can you please pull the XFS fix from the tag below. It's a fix for
an unmount hang (regression) when the filesystem is shutdown. It
was supposed to go to you for -rc3, but I accidentally tagged the
commit prior to it in that pullreq.

Thanks,

-Dave.

The following changes since commit c17a8ef43d6b80ed3519b828c37d18645445949f:

  xfs: clear cowblocks tag when cow fork is emptied (2016-10-24 14:21:08 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git 
tags/xfs-fixes-for-linus-4.9-rc5

for you to fetch changes up to b77428b12b55437b28deae738d9ce8b2e0663b55:

  xfs: defer should abort intent items if the trans roll fails (2016-10-24 
14:21:18 +1100)


xfs: update for 4.9-rc5

In this update:
o fix for aborting deferred transactions on filesystem shutdown.


Darrick J. Wong (1):
  xfs: defer should abort intent items if the trans roll fails

 fs/xfs/libxfs/xfs_defer.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Keerthy]

On Wednesday 09 November 2016 09:40 PM, Lee Jones wrote:

On Thu, 27 Oct 2016, Keerthy wrote:


GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +
 1 file changed, 9 insertions(+)


This requires a DT Ack.


Okay.




diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297b..c28d4eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.

 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

[Keerthy]

On Wednesday 09 November 2016 09:40 PM, Lee Jones wrote:

On Thu, 27 Oct 2016, Keerthy wrote:


GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables driver to over ride the
POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
scenarios.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | 9 +
 1 file changed, 9 insertions(+)


This requires a DT Ack.


Okay.




diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index caf297b..c28d4eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -35,6 +35,15 @@ Optional properties:
 - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode.
Selection primary or secondary function associated to GPADC_START
and SYSEN2 pin/pad for DVFS2 interface
+- ti,palmas-override-powerhold: This is applicable for PMICs for which
+   GPIO7 is configured in POWERHOLD mode which has higher priority
+   over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
+   bit is turned off. This property enables driver to over ride the
+   POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
+   scenarios. So for GPIO7 if ti,palmas-override-powerhold is set
+   then the GPIO_7 field should never be muxed to anything else.
+   It should be set to POWERHOLD by default and only in case of
+   power off scenarios the driver will over ride the mux value.

 This binding uses the following generic properties as defined in
 pinctrl-bindings.txt:

Re: [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y

[Michael Ellerman]

Ard Biesheuvel  writes:

> On 27 October 2016 at 17:27, Ard Biesheuvel  wrote:
>> This series is a followup to the single patch 'modversions: treat symbol
>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>> been sent out so far [0][1]
>>
>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>> and PowerPC64, and where the former gets rid of all runtime relocations
>> related to CRCs, the latter is not as easily convinced.
>>
>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>> routines for 32-bit PowerPC, for which the original fix was effectively
>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>> causes perf issues")
>>
>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>> deal with CRCs being emitted as 32-bit quantities.
>>
>> Patch #3 is the original patch from the v1 and v2 submissions.
>>
>> Changes since v2:
>> - added #1 and #2
>> - updated #3 to deal with CRC entries being emitted from assembler
>> - added Rusty's ack (#3)
>>
>> Branch can be found here:
>> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=kcrctab-reloc
>>
>> [0] http://marc.info/?l=linux-kernel=147652300207369=2
>> [1] http://marc.info/?l=linux-kernel=147695629614409=2
>
> Ping?

Sorry, you didn't cc linuxppc-dev, so it's not in my patchwork list
which tends to mean I miss it.

Will try and test and get back to you.

cheers

Re: [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y

[Michael Ellerman]

Ard Biesheuvel  writes:

> On 27 October 2016 at 17:27, Ard Biesheuvel  wrote:
>> This series is a followup to the single patch 'modversions: treat symbol
>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>> been sent out so far [0][1]
>>
>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>> and PowerPC64, and where the former gets rid of all runtime relocations
>> related to CRCs, the latter is not as easily convinced.
>>
>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>> routines for 32-bit PowerPC, for which the original fix was effectively
>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>> causes perf issues")
>>
>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>> deal with CRCs being emitted as 32-bit quantities.
>>
>> Patch #3 is the original patch from the v1 and v2 submissions.
>>
>> Changes since v2:
>> - added #1 and #2
>> - updated #3 to deal with CRC entries being emitted from assembler
>> - added Rusty's ack (#3)
>>
>> Branch can be found here:
>> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=kcrctab-reloc
>>
>> [0] http://marc.info/?l=linux-kernel=147652300207369=2
>> [1] http://marc.info/?l=linux-kernel=147695629614409=2
>
> Ping?

Sorry, you didn't cc linuxppc-dev, so it's not in my patchwork list
which tends to mean I miss it.

Will try and test and get back to you.

cheers

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

[Keerthy]

On Wednesday 09 November 2016 09:44 PM, Lee Jones wrote:

On Thu, 27 Oct 2016, Keerthy wrote:


POWERHOLD signal has higher priority  over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.

PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold.  Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.

Signed-off-by: Keerthy 
---
 drivers/mfd/palmas.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb..8fbc5e0 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,10 +430,28 @@ static void palmas_power_off(void)
 {
unsigned int addr;
int ret, slave;
+   struct device_node *node;
+   bool override_powerhold;

if (!palmas_dev)


Can this happen?


pm_power_off and palmas_dev are always assigned together. You are right 
this is redundant and can be removed.





return;

+   node = palmas_dev->dev->of_node;


Just do:

struct device_node *np = palmas_dev->dev->of_node;


+   override_powerhold = of_property_read_bool(node,
+   "ti,palmas-override-powerhold");


Break the line after the '=' instead.


okay.




+   if (override_powerhold) {


if (of_property_read_bool(node, "ti,palmas-override-powerhold"))

Then remove 'override_powerhold'.


Okay.




+   addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+   slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+   ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+
PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+   if (ret)
+   pr_err("%s: Unable to write PALMAS_PRIMARY_SECONDARY_PAD2 
%d\n",
+  __func__, ret);


Don't use __func__ in live code.


okay.



And use dev_err();


sure.





+   }
+
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

[Keerthy]

On Wednesday 09 November 2016 09:44 PM, Lee Jones wrote:

On Thu, 27 Oct 2016, Keerthy wrote:


POWERHOLD signal has higher priority  over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.

PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold.  Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.

Signed-off-by: Keerthy 
---
 drivers/mfd/palmas.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 8f8bacb..8fbc5e0 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,10 +430,28 @@ static void palmas_power_off(void)
 {
unsigned int addr;
int ret, slave;
+   struct device_node *node;
+   bool override_powerhold;

if (!palmas_dev)


Can this happen?


pm_power_off and palmas_dev are always assigned together. You are right 
this is redundant and can be removed.





return;

+   node = palmas_dev->dev->of_node;


Just do:

struct device_node *np = palmas_dev->dev->of_node;


+   override_powerhold = of_property_read_bool(node,
+   "ti,palmas-override-powerhold");


Break the line after the '=' instead.


okay.




+   if (override_powerhold) {


if (of_property_read_bool(node, "ti,palmas-override-powerhold"))

Then remove 'override_powerhold'.


Okay.




+   addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+   slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+   ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+
PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+   if (ret)
+   pr_err("%s: Unable to write PALMAS_PRIMARY_SECONDARY_PAD2 
%d\n",
+  __func__, ret);


Don't use __func__ in live code.


okay.



And use dev_err();


sure.





+   }
+
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);

Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

[Viresh Kumar]

On 09-11-16, 17:19, Stephen Boyd wrote:
> On 11/02, Viresh Kumar wrote:
> > On 26-10-16, 12:02, Viresh Kumar wrote:
> > > Hi,
> > > 
> > > Some platforms (like TI) have complex DVFS configuration for CPU
> > > devices, where multiple regulators are required to be configured to
> > > change DVFS state of the device. This was explained well by Nishanth
> > > earlier [1].
> > > 
> > > One of the major complaints around multiple regulators case was that the
> > > DT isn't responsible in any way to represent the ordering in which
> > > multiple supplies need to be programmed, before or after frequency
> > > change. It was considered in this patch and such information is left to
> > > the platform specific OPP driver now, which can register its own
> > > opp_set_rate() callback with the OPP core and the OPP core will then
> > > call it during DVFS.
> > > 
> > > The patches are tested on Exynos5250 (Dual A15). I have hacked around DT
> > > and code to pass values for multiple regulators and verified that they
> > > are all properly read by the kernel (using debugfs interface).
> > > 
> > > Dave Gerlach has already tested it on the real TI platforms and it works
> > > well for him.
> > > 
> > > This is rebased over: linux-next branch in the PM tree.
> > > 
> > > V2->V3:
> > > - The last patch is new
> > > - Removed a debug leftover pr_info() message
> > > - Renamed few names as s/set_rate/set_opp
> > > - Removed a TODO comment (as it is done now with this series)
> > > - created struct for min_uV and max_uV
> > > - kerneldoc comments for structures in pm_opp.h
> > > - s/const char */const char * const
> > > - use kasprintf()
> > > - Some more minor reformatting
> > > - More Ack/RBY tags added
> > 
> > @Stephen: Can you please provide further comments or Acks ?
> > 
> 
> Where did we end up on the topic of RCU usage in OPP? I'd rather
> we figure that out before investing more time in reviewing code
> that we may end up completely rewriting in the future.

We haven't decided anything on that yet and I don't think there is any reason to
block this series for that. There is lots of existing code that needs to be
updated if we decide to walk that path and I wouldn't mind a small addition to
that from this series.

Lots of effort Coding/testing/reviewing has already gone into this work and we
better get it merged now.

-- 
viresh

Re: [PATCH V3 0/9] PM / OPP: Multiple regulator support

[Viresh Kumar]

On 09-11-16, 17:19, Stephen Boyd wrote:
> On 11/02, Viresh Kumar wrote:
> > On 26-10-16, 12:02, Viresh Kumar wrote:
> > > Hi,
> > > 
> > > Some platforms (like TI) have complex DVFS configuration for CPU
> > > devices, where multiple regulators are required to be configured to
> > > change DVFS state of the device. This was explained well by Nishanth
> > > earlier [1].
> > > 
> > > One of the major complaints around multiple regulators case was that the
> > > DT isn't responsible in any way to represent the ordering in which
> > > multiple supplies need to be programmed, before or after frequency
> > > change. It was considered in this patch and such information is left to
> > > the platform specific OPP driver now, which can register its own
> > > opp_set_rate() callback with the OPP core and the OPP core will then
> > > call it during DVFS.
> > > 
> > > The patches are tested on Exynos5250 (Dual A15). I have hacked around DT
> > > and code to pass values for multiple regulators and verified that they
> > > are all properly read by the kernel (using debugfs interface).
> > > 
> > > Dave Gerlach has already tested it on the real TI platforms and it works
> > > well for him.
> > > 
> > > This is rebased over: linux-next branch in the PM tree.
> > > 
> > > V2->V3:
> > > - The last patch is new
> > > - Removed a debug leftover pr_info() message
> > > - Renamed few names as s/set_rate/set_opp
> > > - Removed a TODO comment (as it is done now with this series)
> > > - created struct for min_uV and max_uV
> > > - kerneldoc comments for structures in pm_opp.h
> > > - s/const char */const char * const
> > > - use kasprintf()
> > > - Some more minor reformatting
> > > - More Ack/RBY tags added
> > 
> > @Stephen: Can you please provide further comments or Acks ?
> > 
> 
> Where did we end up on the topic of RCU usage in OPP? I'd rather
> we figure that out before investing more time in reviewing code
> that we may end up completely rewriting in the future.

We haven't decided anything on that yet and I don't think there is any reason to
block this series for that. There is lots of existing code that needs to be
updated if we decide to walk that path and I wouldn't mind a small addition to
that from this series.

Lots of effort Coding/testing/reviewing has already gone into this work and we
better get it merged now.

-- 
viresh

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Kai-Heng Feng]

Hi,

On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork  wrote:
> Oliver Neukum  writes:
>
>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>
>>> These problems could very well be caused by running at SuperSpeed
>>> (USB-3) instead of high speed (USB-2).

Yes, it's running at SuperSpeed, on a Kabylake laptop.

It does not have this issue on a Broadwell laptop, also running at SuperSpeed.

>>>
>>> Is there any way to test what happens when the device is attached to
>>> the computer by a USB-2 cable?  That would prevent it from operating at
>>> SuperSpeed.

I recall old Intel PCH can change the USB host from XHCI to EHCI,
newer PCH does not have this option.

Is there a way to force XHCI run at HighSpeed?

>>>
>>> The main point, however, is that the proposed patch doesn't seem to
>>> address the true problem, which is that the device gets suspended
>>> between probes.  The patch only tries to prevent it from being
>>> suspended during a probe -- which is already prevented by the USB core.
>>
>> But why doesn't it fail during normal operation?
>>
>> I suspect that its firmware requires the altsetting
>>
>> /* should we change control altsetting on a NCM/MBIM function? */
>> if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) 
>> {
>> data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
>> ret = cdc_mbim_set_ctrlalt(dev, intf, 
>> CDC_NCM_COMM_ALTSETTING_MBIM);
>>
>> to be set before it accepts a suspension.
>
> Could be, but I don't think so.  The above code is effectively a noop
> unless the function is a combined NCM/MBIM function.  Something I've
> never seen on a Sierra Wireless device (ignoring the infamous EM7345,
> which really is an Intel device).
>
> This is a typical example of a Sierra Wireless modem configured for
> MBIM:
>
> P:  Vendor=1199 ProdID=9079 Rev= 0.06
> S:  Manufacturer=Sierra Wireless, Incorporated
> S:  Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
> S:  SerialNumber=LF615126xxx
> C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
> A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
> I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
> E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
> I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
>
> The control interface of plain MBIM functions will always have a single
> altsetting, like the example above. So cdc_ncm_select_altsetting(intf)
> returns "0", while CDC_NCM_COMM_ALTSETTING_MBIM is "1".
>
>
> Just for reference, using the Intel^H^H^H^H^HEM7345 as example, this is
> what a combined NCM/MBIM function looks like:
>
>
> P:  Vendor=1199 ProdID=a001 Rev=17.29
> S:  Manufacturer=Sierra Wireless Inc.
> S:  Product=Sierra Wireless EM7345 4G LTE
> S:  SerialNumber=013937000xx
> C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
> A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00
> A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
> E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
> E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
>
> And this is what the code you quote is trying to deal with.  Note the
> different subclass of altsetting 0 and 1 This is incredibly ugly.
>
> FWIW, the modem in question cannot be an EM7345. That modem does not
> have the static interface numbering oddity.  Another sign that it isn't
> a true Sierra device.

Yes, this modem is an EM7445.

>
>
>
>
> Bjørn

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

[Kai-Heng Feng]

Hi,

On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork  wrote:
> Oliver Neukum  writes:
>
>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>
>>> These problems could very well be caused by running at SuperSpeed
>>> (USB-3) instead of high speed (USB-2).

Yes, it's running at SuperSpeed, on a Kabylake laptop.

It does not have this issue on a Broadwell laptop, also running at SuperSpeed.

>>>
>>> Is there any way to test what happens when the device is attached to
>>> the computer by a USB-2 cable?  That would prevent it from operating at
>>> SuperSpeed.

I recall old Intel PCH can change the USB host from XHCI to EHCI,
newer PCH does not have this option.

Is there a way to force XHCI run at HighSpeed?

>>>
>>> The main point, however, is that the proposed patch doesn't seem to
>>> address the true problem, which is that the device gets suspended
>>> between probes.  The patch only tries to prevent it from being
>>> suspended during a probe -- which is already prevented by the USB core.
>>
>> But why doesn't it fail during normal operation?
>>
>> I suspect that its firmware requires the altsetting
>>
>> /* should we change control altsetting on a NCM/MBIM function? */
>> if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) 
>> {
>> data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
>> ret = cdc_mbim_set_ctrlalt(dev, intf, 
>> CDC_NCM_COMM_ALTSETTING_MBIM);
>>
>> to be set before it accepts a suspension.
>
> Could be, but I don't think so.  The above code is effectively a noop
> unless the function is a combined NCM/MBIM function.  Something I've
> never seen on a Sierra Wireless device (ignoring the infamous EM7345,
> which really is an Intel device).
>
> This is a typical example of a Sierra Wireless modem configured for
> MBIM:
>
> P:  Vendor=1199 ProdID=9079 Rev= 0.06
> S:  Manufacturer=Sierra Wireless, Incorporated
> S:  Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
> S:  SerialNumber=LF615126xxx
> C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
> A:  FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
> I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
> E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
> I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
> I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
>
> The control interface of plain MBIM functions will always have a single
> altsetting, like the example above. So cdc_ncm_select_altsetting(intf)
> returns "0", while CDC_NCM_COMM_ALTSETTING_MBIM is "1".
>
>
> Just for reference, using the Intel^H^H^H^H^HEM7345 as example, this is
> what a combined NCM/MBIM function looks like:
>
>
> P:  Vendor=1199 ProdID=a001 Rev=17.29
> S:  Manufacturer=Sierra Wireless Inc.
> S:  Product=Sierra Wireless EM7345 4G LTE
> S:  SerialNumber=013937000xx
> C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
> A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00
> A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
> E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
> E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
>
> And this is what the code you quote is trying to deal with.  Note the
> different subclass of altsetting 0 and 1 This is incredibly ugly.
>
> FWIW, the modem in question cannot be an EM7345. That modem does not
> have the static interface numbering oddity.  Another sign that it isn't
> a true Sierra device.

Yes, this modem is an EM7445.

>
>
>
>
> Bjørn