[PATCH] tracing: fix compiler warnings in trace_events.c

[Geliang Tang]

Fix the following warnings:
  kernel/trace/trace_events.c: In function '__ftrace_clear_event_pids':
  kernel/trace/trace_events.c:579: warning: passing argument 1 of 
'unregister_trace_sched_switch' from incompatible pointer type
  include/trace/events/sched.h:162: note: expected 'void (*)(void *, bool,  
struct task_struct *, struct task_struct *)' but argument is of type 'void 
(*)(void *, struct task_struct *, struct task_struct *)'
  kernel/trace/trace_events.c:580: warning: passing argument 1 of 
'unregister_trace_sched_switch' from incompatible pointer type
  include/trace/events/sched.h:162: note: expected 'void (*)(void *, bool,  
struct task_struct *, struct task_struct *)' but argument is of type 'void 
(*)(void *, struct task_struct *, struct task_struct *)'
  kernel/trace/trace_events.c: In function 'ftrace_event_pid_write':
  kernel/trace/trace_events.c:1724: warning: passing argument 1 of 
'register_trace_prio_sched_switch' from incompatible pointer type
  include/trace/events/sched.h:162: note: expected 'void (*)(void *, bool,  
struct task_struct *, struct task_struct *)' but argument is of type 'void 
(*)(void *, struct task_struct *, struct task_struct *)'
  kernel/trace/trace_events.c:1726: warning: passing argument 1 of 
'register_trace_prio_sched_switch' from incompatible pointer type
  include/trace/events/sched.h:162: note: expected 'void (*)(void *, bool,  
struct task_struct *, struct task_struct *)' but argument is of type 'void 
(*)(void *, struct task_struct *, struct task_struct *)'

Signed-off-by: Geliang Tang 
---
 kernel/trace/trace_events.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index fb0261e..0d86f0c 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -506,7 +506,7 @@ check_ignore_pid(struct trace_pid_list *filtered_pids, 
struct task_struct *task)
 }
 
 static void
-event_filter_pid_sched_switch_probe_pre(void *data,
+event_filter_pid_sched_switch_probe_pre(void *data, bool preempt,
struct task_struct *prev, struct task_struct *next)
 {
struct trace_array *tr = data;
@@ -520,7 +520,7 @@ event_filter_pid_sched_switch_probe_pre(void *data,
 }
 
 static void
-event_filter_pid_sched_switch_probe_post(void *data,
+event_filter_pid_sched_switch_probe_post(void *data, bool preempt,
struct task_struct *prev, struct task_struct *next)
 {
struct trace_array *tr = data;
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 14/20] ARC: [plat-eznps] Use dedicated SMP barriers

[Vineet Gupta]

On Saturday 31 October 2015 06:52 PM, Noam Camus wrote:
> From: Noam Camus 
>
> NPS device got 256 cores and each got 16 HW threads (SMT).
> We use EZchip dedicated ISA to trigger HW scheduler of the
> core that current HW thread belongs to.
> This scheduling makes sure that data beyond barrier is available
> to all HW threads in core and by that to all in device (4K).
>
> Signed-off-by: Noam Camus 
> Cc: Peter Zijlstra 
> ---
>  arch/arc/include/asm/barrier.h |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
> index a720998..c8229b8 100644
> --- a/arch/arc/include/asm/barrier.h
> +++ b/arch/arc/include/asm/barrier.h
> @@ -34,6 +34,12 @@
>  
>  #ifdef CONFIG_ISA_ARCOMPACT
>  
> +#ifdef CONFIG_ARC_PLAT_EZNPS
> +#include 
> +#define mb() asm volatile (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
> +#define rmb()asm volatile (".word %0" : : "i"(CTOP_INST_SCHD_RD) : 
> "memory")

Do u need this even for mandatory barriers whose semantics are not related to 
SMP
at all ? I think you need them only for smb_*

Following is a good introduction to difference between the two !
https://community.arm.com/groups/processors/blog/2011/04/11/memory-access-ordering-part-2--barriers-and-the-linux-kernel

> +#else
> +
>  /*
>   * ARCompact based cores (ARC700) only have SYNC instruction which is super
>   * heavy weight as it flushes the pipeline as well.
> @@ -41,6 +47,8 @@
>   */
>  
>  #define mb() asm volatile("sync\n" : : : "memory")
> +#endif /* CONFIG_ARC_PLAT_EZNPS */
> +
>  #endif
>  
>  #include 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/7] clocksource/drivers/pxa_timer: Move the Kconfig rule

[Daniel Lezcano]

Hi Amit,

On 11/02/2015 08:44 AM, Amit Kucheria wrote:

On Fri, Oct 30, 2015 at 4:22 AM, Daniel Lezcano
 wrote:

Instead of having the clocksource's Kconfig depending on the arch, let the
arch to select the timer it needs.


Is this the prescribed way to do things nowadays? It leads to more
options showing up in 'make menuconfig'. Why do I need to see
CLKSRC_PXA if I'm not even compiling for ARCH_PXA (and not interesting
in COMPILE_TEST)?


That won't happen.

As the 'bool' has no string after, it won't show up in the menuconfig.

Actually, with the next patch, only COMPILE_TEST will show it up in the

Device Drivers->Clocksource drivers.


The CLKSRC_OF dependency is removed because already selected by the ARCH_PXA,
and it is added for SA1100.


This bit makes sense.


Signed-off-by: Daniel Lezcano 
---
  arch/arm/Kconfig| 3 +++
  drivers/clocksource/Kconfig | 3 +--
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..aa32286 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -609,6 +609,7 @@ config ARCH_PXA
 select AUTO_ZRELADDR
 select COMMON_CLK
 select CLKDEV_LOOKUP
+   select CLKSRC_PXA
 select CLKSRC_MMIO
 select CLKSRC_OF
 select GENERIC_CLOCKEVENTS
@@ -669,6 +670,8 @@ config ARCH_SA1100
 select ARCH_SPARSEMEM_ENABLE
 select CLKDEV_LOOKUP
 select CLKSRC_MMIO
+   select CLKSRC_PXA
+   select CLKSRC_OF if OF
 select CPU_FREQ
 select CPU_SA1100
 select GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5cd000c..425abbd 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -289,8 +289,7 @@ config CLKSRC_TANGO_XTAL
 select CLKSRC_OF

  config CLKSRC_PXA
-   def_bool y if ARCH_PXA || ARCH_SA1100
-   select CLKSRC_OF if OF
+   bool



--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 12/28] tracing: Add hist trigger support for user-defined sorting ('sort=' param)

[Namhyung Kim]

On Thu, Oct 22, 2015 at 01:14:16PM -0500, Tom Zanussi wrote:
> Allow users to specify keys and/or values to sort on.  With this
> addition, keys and values specified using the 'keys=' and 'vals='
> keywords can be used to sort the hist trigger output via a new 'sort='
> keyword.  If multiple sort keys are specified, the output will be
> sorted using the second key as a secondary sort key, etc.  The default
> sort order is ascending; if the user wants a different sort order,
> '.descending' can be appended to the specific sort key.  Before this
> addition, output was always sorted by 'hitcount' in ascending order.
> 
> This expands the hist trigger syntax from this:
> 
> # echo hist:keys=xxx:vals=yyy \
>   [ if filter] > event/trigger
> 
> to this:
> 
> # echo hist:keys=xxx:vals=yyy:sort=zzz.descending \
>   [ if filter] > event/trigger
> 
> Signed-off-by: Tom Zanussi 
> Tested-by: Masami Hiramatsu 
> ---

[SNIP]
>  static int create_sort_keys(struct hist_trigger_data *hist_data)
>  {
> + char *fields_str = hist_data->attrs->sort_key_str;
> + struct ftrace_event_field *field = NULL;
> + struct tracing_map_sort_key *sort_key;
> + unsigned int i, j;
>   int ret = 0;
>  
>   hist_data->n_sort_keys = 1; /* sort_keys[0] is always hitcount */

This comment should be updated.

Thanks,
Namhyung


>  
> + if (!fields_str)
> + goto out;
> +
> + strsep(&fields_str, "=");
> + if (!fields_str) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + for (i = 0; i < TRACING_MAP_SORT_KEYS_MAX; i++) {
> + char *field_str, *field_name;
> +
> + sort_key = &hist_data->sort_keys[i];
> +
> + field_str = strsep(&fields_str, ",");
> + if (!field_str) {
> + if (i == 0)
> + ret = -EINVAL;
> + break;
> + }
> +
> + if ((i == TRACING_MAP_SORT_KEYS_MAX - 1) && fields_str) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + field_name = strsep(&field_str, ".");
> + if (!field_name) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (!strcmp(field_name, "hitcount")) {
> + ret = is_descending(field_str);
> + if (ret < 0)
> + break;
> + sort_key->descending = ret;
> + continue;
> + }
> +
> + for (j = 1; j < hist_data->n_fields; j++) {
> + field = hist_data->fields[j]->field;
> + if (field && !strcmp(field_name, field->name)) {
> + sort_key->field_idx = j;
> + ret = is_descending(field_str);
> + if (ret < 0)
> + goto out;
> + sort_key->descending = ret;
> + break;
> + }
> + }
> + if (j == hist_data->n_fields) {
> + ret = -EINVAL;
> + break;
> + }
> + }
> + hist_data->n_sort_keys = i;
> + out:
>   return ret;
>  }
>  
> @@ -737,7 +817,26 @@ static int event_hist_trigger_print(struct seq_file *m,
>   }
>  
>   seq_puts(m, ":sort=");
> - seq_puts(m, "hitcount");
> +
> + for (i = 0; i < hist_data->n_sort_keys; i++) {
> + struct tracing_map_sort_key *sort_key;
> +
> + sort_key = &hist_data->sort_keys[i];
> +
> + if (i > 0)
> + seq_puts(m, ",");
> +
> + if (sort_key->field_idx == HITCOUNT_IDX)
> + seq_puts(m, "hitcount");
> + else {
> + unsigned int idx = sort_key->field_idx;
> +
> + hist_field_print(m, hist_data->fields[idx]);
> + }
> +
> + if (sort_key->descending)
> + seq_puts(m, ".descending");
> + }
>  
>   seq_printf(m, ":size=%u", (1 << hist_data->map->map_bits));
>  
> -- 
> 1.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v1 08/20] ARC: Use res_service as entry point for secondaries

[Noam Camus]

From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] 
Sent: Monday, November 02, 2015 8:38 AM

> I'd suggest leave this arg alone and use whatever PC is needed inside your 
> kick routine
OK

- Noam 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Nov 1

[Geert Uytterhoeven]

Hi Stephen,

On Sun, Nov 1, 2015 at 5:53 PM, Stephen Rothwell  wrote:
> I start again a day early, and this is how you all repay me? ;-)

With all these maintainers showing you fake smiles at Kernel Summit :-)

This only proves how much value your work brings! Thanks a lot!

If I have to answer the question "Which 2 things made m68k maintenance
feather-light?", I'd say "Git and linux-next".

Thanks again (also to Linus for git)!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Crypto Update for 4.4

[Herbert Xu]

Hi Linus:

Here is the crypto update for 4.4:

API:

* Add support for cipher output IVs in testmgr.
* Add missing crypto_ahash_blocksize helper.
* Mark authenc and des ciphers as not allowed under FIPS.

Algorithms:

* Add CRC support to 842 compression.
* Add keywrap algorithm.
* A number of changes to the akcipher interface:
  + Separate functions for setting public/private keys.
  + Use SG lists.

Drivers:

* Add Intel SHA Extension optimised SHA1 and SHA256.
* Use dma_map_sg instead of custom functions in crypto drivers.
* Add support for STM32 RNG.
* Add support for ST RNG.
* Add Device Tree support to exynos RNG driver.
* Add support for mxs-dcp crypto device on MX6SL.
* Add xts(aes) support to caam.
* Add ctr(aes) and xts(aes) support to qat.
* A large set of fixes from Russell King for the marvell/cesa driver.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Alexander Kuleshov (1):
  crypto: jitterentropy - remove unnecessary information from a comment

Arnd Bergmann (1):
  crypto: mxs-dcp - mxs-dcp is an stmp device

Boris BREZILLON (1):
  crypto: testmgr - test IV value after a cipher operation

Boris Brezillon (1):
  crypto: marvell/cesa - fix memory leak

Catalin Vasile (1):
  crypto: caam - add support for acipher xts(aes)

Daniel Thompson (5):
  dt-bindings: Document the STM32 HW RNG bindings
  hwrng: stm32 - add support for STM32 HW RNG
  ARM: dts: stm32f429: Adopt STM32 RNG driver
  hwrng: stm32 - Fix build with CONFIG_PM
  hwrng: exynos - Fix unbalanced PM runtime get/puts

David Howells (1):
  crypto: akcipher - Don't #include crypto/public_key.h as the contents 
aren't used

Fabio Estevam (6):
  crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL
  hwrng: mxc-rnga - Remove unneeded goto label
  hwrng: mxc-rnga - Remove uneeded initialization
  hwrng: mxc-rnga - Remove unnecessary dev_info message
  hwrng: mxc-rnga - Use the preferred format for kzalloc
  crypto: caam - Remove unused JUMP_TYPE_MASK definition

Geliang Tang (1):
  crypto: skcipher - blkcipher and ablkcipher should it be static

Haren Myneni (1):
  crypto: 842 - Add CRC and validation support

Herbert Xu (1):
  crypto: ahash - Add crypto_ahash_blocksize

Horia Geant? (1):
  crypto: tcrypt - avoid mapping from module image addresses

John Griffin (1):
  crypto: qat - don't check for iommu

John Haxby (1):
  crypto: testmgr - Disable fips-allowed for authenc() and des() ciphers

Krzysztof Kozlowski (4):
  dt-bindings: rng: Describe Exynos4 PRNG bindings
  hwrng: exynos - Add timeout for waiting on init done
  hwrng: exynos - Fix missing configuration after suspend to RAM
  hwrng: exynos - Add Device Tree support

LABBE Corentin (14):
  crypto: bfin_crc - replace sg_count by sg_nents
  crypto: amcc - replace get_sg_count by sg_nents_for_len
  crypto: sahara - replace sahara_sg_length with sg_nents_for_len
  crypto: talitos - dma_map_sg can handle chained SG
  crypto: caam - dma_map_sg can handle chained SG
  crypto: sahara - dma_map_sg can handle chained SG
  crypto: qce - dma_map_sg can handle chained SG
  crypto: atmel - Check for clk_prepare_enable() return value
  crypto: atmel - use devm_xxx() managed function
  crypto: ux500 - Use devm_xxx() managed function
  crypto: s390/sha - replace raw value by their coresponding define
  crypto: sahara - set array of const as const
  crypto: n2 - set array of const as const
  lib/mpi: clean unused SHA1_DIGEST_LENGTH

Lee Jones (10):
  hwrng: doc - Fix device node name reference /dev/hw_random => /dev/hwrng
  hwrng: Kconfig - Fix device node name reference /dev/hw_random => 
/dev/hwrng
  hwrng: core - Simplify RNG switching from sysfs
  hwrng: st - Provide DT bindings for ST's Random Number Generator
  hwrng: st - Add support for ST's HW Random Number Generator
  ARM: STi: STiH407: Enable the 2 HW Random Number Generators for STiH4{07, 
10}
  MAINTAINERS: Add ST's Random Number Generator to the ST entry
  hwrng: st: dt: Fix trivial typo in node address
  hwrng: st - Use real-world device timings for timeout
  hwrng: st - Improve FIFO size/depth description

Luis de Bethencourt (4):
  crypto: amcc - Fix module autoload for OF platform driver
  crypto: picoxcell - Fix module autoload for OF platform driver
  crypto: ux500 - Fix module autoload for OF platform drivers
  hwrng: Fix module autoload for OF platform drivers

Nicolas Iooss (1):
  crypto: crc32c-pclmul - use .rodata instead of .rotata

Russell King (32):
  crypto: marvell/cesa - fix stack smashing in marvell/hash.c
  crypto: marvell/cesa - initialise struct mv_cesa_ahash_req
  crypto: marvell/cesa - fix wrong hash results
  crypto: marvell/cesa - factor out common import/export functions
  crypto: marvell/cesa - easier way to get the tra

[lkp] [fs] df4c0e36f1: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd ("fs: dcache: manually unpoison 
dname after allocation to shut up kasan's reports")


The commit fixed a KASan bug, but introduced or revealed a soft lockup
issue as follow.


[  116.546697] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[swapper/0:1]
[  116.546697] irq event stamp: 3018750
[  116.546697] hardirqs last  enabled at (3018749): [] 
restore_args+0x0/0x30
[  116.546697] hardirqs last disabled at (3018750): [] 
apic_timer_interrupt+0x6d/0x80
[  116.546697] softirqs last  enabled at (3018748): [] 
__do_softirq+0x417/0x65b
[  116.546697] softirqs last disabled at (3018743): [] 
irq_exit+0x55/0xc3
[  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-05249-gdf4c0e3 
#1
[  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  116.546697] task: 88002f3f ti: 88002f3f8000 task.ti: 
88002f3f8000
[  116.546697] RIP: 0010:[]  [] 
__asan_load4+0x12/0x91
[  116.546697] RSP: :88002f3fbdc8  EFLAGS: 0282
[  116.546697] RAX: 7fff RBX:  RCX: dc00
[  116.546697] RDX: fbfff0763087 RSI: 83b18b10 RDI: 83b1803c
[  116.546697] RBP: 88002f3fbdf8 R08: 0001 R09: fbfff0763074
[  116.546697] R10: 83b183a7 R11: fbfff0763074 R12: 880038d29003
[  116.546697] R13: ed00071a5200 R14: 818cfadb R15: 88002f3fbdf8
[  116.546697] FS:  () GS:88002f60() 
knlGS:
[  116.546697] CS:  0010 DS:  ES:  CR0: 8005003b
[  116.546697] CR2:  CR3: 02793000 CR4: 06f0
[  116.546697] Stack:
[  116.546697]  83b18d5c 83b18b08 83b18878 
83b18b10
[  116.546697]  83b18868  88002f3fbe48 
8223c4d3
[  116.546697]   c4400d6283b18d40 0202 
0d98
[  116.546697] Call Trace:
[  116.546697]  [] insert_augmented+0x52/0xf5
[  116.546697]  [] rbtree_test_init+0x151/0x205
[  116.546697]  [] ? glob_init+0x11c/0x11c
[  116.546697]  [] do_one_initcall+0x105/0x197
[  116.546697]  [] kernel_init_freeable+0x193/0x22e
[  116.546697]  [] ? rest_init+0x14d/0x14d
[  116.546697]  [] kernel_init+0xe/0xdf
[  116.546697]  [] ret_from_fork+0x7c/0xb0
[  116.546697]  [] ? rest_init+0x14d/0x14d
[  116.546697] Code: 38 00 74 13 48 8b 4d 08 ba 01 00 00 00 be 02 00 00 00 e8 
e0 09 00 00 c9 c3 55 48 b8 ff ff ff ff ff 7f ff ff 48 89 e5 48 83 ec 30 <48> 39 
c7 77 23 48 8b 45 08 48 89 7d d8 48 8d 7d d8 48 c7 45 e8 
[  116.546697] Kernel panic - not syncing: softlockup: hung tasks
[  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G L  
3.19.0-05249-gdf4c0e3 #1
[  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  116.546697]     
88002f603d48
[  116.546697]  8223bcf7 fbfff074360b 8263d4e2 
88002f603dc8
[  116.546697]  82234300 88002f603dc8 0008 
88002f603dd8
[  116.546697] Call Trace:
[  116.546697][] dump_stack+0x4c/0x65
[  116.546697]  [] panic+0xed/0x231
[  116.546697]  [] watchdog_timer_fn+0x1d2/0x1f8
[  116.546697]  [] ? __touch_watchdog+0x1c/0x1c
[  116.546697]  [] __run_hrtimer+0x283/0x6a2
[  116.546697]  [] hrtimer_run_queues+0x126/0x145
[  116.546697]  [] run_local_timers+0xe/0x1a
[  116.546697]  [] update_process_times+0x27/0x54
[  116.546697]  [] tick_nohz_handler+0x101/0x164
[  116.546697]  [] local_apic_timer_interrupt+0x78/0x80
[  116.546697]  [] smp_apic_timer_interrupt+0x57/0x69
[  116.546697]  [] apic_timer_interrupt+0x72/0x80
[  116.546697][] ? __asan_load4+0x12/0x91
[  116.546697]  [] insert_augmented+0x52/0xf5
[  116.546697]  [] rbtree_test_init+0x151/0x205
[  116.546697]  [] ? glob_init+0x11c/0x11c
[  116.546697]  [] do_one_initcall+0x105/0x197
[  116.546697]  [] kernel_init_freeable+0x193/0x22e
[  116.546697]  [] ? rest_init+0x14d/0x14d
[  116.546697]  [] kernel_init+0xe/0xdf
[  116.546697]  [] ret_from_fork+0x7c/0xb0
[  116.546697]  [] ? rest_init+0x14d/0x14d
[  116.546697] Kernel Offset: 0x0 from 0x8100 (relocation range: 
0x8000-0x9fff)


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.19.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_H

Re: [PATCH v4 0/4] Add support for STM32 DMA

[M'boumba Cedric Madianga]

 Hi Vinod,

Do you have any further comments or suggestions on this serie ?

BR,
Cedric

2015-10-16 15:59 GMT+02:00 M'boumba Cedric Madianga :
> This patchset adds support for the STM32 DMA controller.
> This controller provides 8 channels dedicated to managing memory access
> request from one or more peripherals.
> Each stream can have up to 8 requests in total.
>
> Changes since v3:
>  - Fix regression introduced in v3 during request channel
>  - Fix regression introduced in v3 for cyclic mode dma transfer
>  - update interrupt description in DT
>  - remove half transfer interrupt management as client callback as to be
>called only for complete transfer
>
> Changes since v2:
>  - remove interrupt configuration management from DT (Mark)
>  - remove FIFO configuration management from DT except threshold as it is very
>hard to handle it in the driver due to many possible combinations according
>to burst and bus width (Mark)
>  - update DMA client message in DT documentation file
>  - specify the order to be used to set per-channel DMA interrupts in the DT
>(Mark)
>  - remove unused enumerations for channel and request ids (Daniel)
>  - keep as soon as possible 80 lines char for more readability (Vinod)
>  - replace unsigned int by u32 (Vinod)
>  - use GFP_NOWAIT instead of GFP_ATOMIC during dma descriptors allocation
>(Vinod)
>  - return error if burst is not supported in stm32_dma_get_burst() (Vinod)
>  - return error if bus_width is not supported in stm32_dma_get_width() (Vinod)
>  - add FIFO configuration management inside the driver except for threshold
>  - add interrupt configuration management inside the driver (Mark)
>  - rework stm32_dma_chan_irq() to handle error interrupt in one way (Vinod)
>  - rework stm32_dma_set_xfer_param() to be easier to read
>  - update stm32_dma_tx_status() to always return status from 
> dma_cookie_status() (Vinod)
>  - disable clk if we don't manage to stop the DMA channel during channel
>resources allocation (Daniel)
>  - set driver as built-in as DMA will be required by other built-in driver
>
>  Changes since v1:
>   - remove dmamux boolean as it is not needed
>   - replace dma by DMA in Kconfig (Maxime)
>   - add default return value in stm32_dma_get_width()
>   - add defalut return value in stm32_dma_get_burst()
>   - use lower case for constant hexadecimal values (Maxime)
>
> M'boumba Cedric Madianga (4):
>   dt-bindings: Document the STM32 DMA bindings
>   dmaengine: Add STM32 DMA driver
>   ARM: dts: Add STM32 DMA support for STM32F429 MCU
>   ARM: configs: Add STM32 DMA support in STM32 defconfig
>
>  .../devicetree/bindings/dma/stm32-dma.txt  |   82 ++
>  arch/arm/boot/dts/stm32f429.dtsi   |   31 +
>  arch/arm/configs/stm32_defconfig   |2 +
>  drivers/dma/Kconfig|   12 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/stm32-dma.c| 1141 
> 
>  6 files changed, 1269 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt
>  create mode 100644 drivers/dma/stm32-dma.c
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain]

Hi LABBE,

On 2015年10月30日 16:58, LABBE Corentin wrote:
> On Fri, Oct 30, 2015 at 04:22:46PM +0800, Zain Wang wrote:
>> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher 
>> mode.
>> The names registered are:
>> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>> You can alloc tags above in your case.
>>
>> And other algorithms and platforms will be added later on.
>>
>> Signed-off-by: Zain Wang 
>> ---
>>  drivers/crypto/Makefile|   1 +
>>  drivers/crypto/rk_crypto/Makefile  |   3 +
>>  drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>>  drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>>  .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 
>> +
>>  5 files changed, 1190 insertions(+)
>>  create mode 100644 drivers/crypto/rk_crypto/Makefile
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>>
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c3ced6f..00d103c 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>> diff --git a/drivers/crypto/rk_crypto/Makefile 
>> b/drivers/crypto/rk_crypto/Makefile
>> new file mode 100644
>> index 000..0f62d87
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>> +rk_crypto_driver-objs := rk3288_crypto.o \
>> + rk3288_crypto_ablkcipher.o \
>> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
>> b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> new file mode 100644
>> index 000..fe55d7e
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> @@ -0,0 +1,393 @@
>> +/*
>> + *Crypto acceleration support for Rockchip RK3288
>> + *
>> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * Author: Zain Wang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>> + */
>> +
>> +#include "rk3288_crypto.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct crypto_info_t *crypto_p;
>> +
>> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>> +{
>> +if (clk_prepare_enable(dev->clk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>> +__func__, __LINE__);
>> +return -ENOENT;
>> +}
>> +if (clk_prepare_enable(dev->aclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>> +__func__, __LINE__);
>> +goto err_aclk;
>> +}
>> +if (clk_prepare_enable(dev->hclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>> +__func__, __LINE__);
>> +goto err_hclk;
>> +}
>> +if (clk_prepare_enable(dev->pclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>> +__func__, __LINE__);
>> +goto err_pclk;
>> +}
>> +return 0;
>> +
>> +err_pclk:
>> +clk_disable_unprepare(dev->hclk);
>> +err_hclk:
>> +clk_disable_unprepare(dev->aclk);
>> +err_aclk:
>> +clk_disable_unprepare(dev->clk);
>> +
>> +return -ENOENT;
>> +}
> Please return the error value given by clk_prepare_enable()
ok! done!
>
>> +
>> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>> +{
>> +clk_disable_unprepare(dev->hclk);
>> +clk_disable_unprepare(dev->aclk);
>> +clk_disable_unprepare(dev->pclk);
>> +clk_disable_unprepare(dev->clk);
>> +}
>> +
>> +static int check_alignment(struct scatterlist *sg_src,
>> +   struct scatterlist *sg_dst,
>> +   int align_mask)
>> +{
>> +int in, out, align;
>> +
>> +in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>> + IS_ALIGNED(sg_src->length, align_mask);
>> +if (sg_dst == NULL)
>> +return in;
>> +out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>> +  IS_ALIGNED(sg_dst->length, align_mask);
>> +align = in && out;
>> +
>> +return (align && (sg_src->length == sg_dst->length));
>> +}
>> +
>> +static int rk_load_data(struct crypto_info_t *dev,
>> +  struct scatterlist *sg_src,
>> +

[lkp] [freezer] e8de7ec5cc: WARNING: CPU: 1 PID: 699 at include/linux/freezer.h:62 svc_recv+0x3eb/0x80c()

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Jiri-Kosina/PM-vfs-use-filesystem-freezing-instead-of-kthread-freezer/20151030-215223
commit e8de7ec5cc871dacba9149fe6b5aacc545baef2c ("freezer: warn if anyone is 
trying to use freezer on kthreads")


++++
|| f5121659bb | e8de7ec5cc |
++++
| boot_successes | 15 | 11 |
| boot_failures  | 0  | 3  |
| WARNING:at_include/linux/freezer.h:#svc_recv() | 0  | 3  |
| backtrace:nfs4_callback_svc| 0  | 3  |
++++


wget --local-encoding=UTF-8 --retry-connrefused --waitretry 1000 --tries 1000 
http://inn:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/scheduled/vm-kbuild-1G-16/bisect_boot-1-debian-x86_64-2015-02-07.cgz-x86_64-acpi-redef-e8de7ec5cc871dacba9149fe6b5aacc545baef2c-20151031-105622-1k6mt59-0.yaml&job_state=running
 -q -O /dev/null
wait for background monitors: oom-killer watchdog
wget --local-encoding=UTF-8 --retry-connrefused --waitretry 1000 --tries 1000 
http://inn:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/scheduled/vm-kbuild-1G-16/bisect_boot-1-debian-x86_64-2015-02-07.cgz-x86_64-acpi-redef-e8de7ec5cc871dacba9149fe6b5aacc545baef2c-20151031-105622-1k6mt59-0.yaml&loadavg=0.68
 0.16 0.05 1/118 
817&start_time=1446232943&end_time=1446232944&version=/lkp/lkp/.src-20151030-185949&
 -q -O /dev/null
[   25.953285] WARNING: CPU: 1 PID: 699 at include/linux/freezer.h:62 
svc_recv+0x3eb/0x80c()
[   25.954875] CPU: 1 PID: 699 Comm: nfsv4.0-svc Not tainted 
4.3.0-rc7-3-ge8de7ec #304
[   25.956198] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   25.958815]   88003ed9bd78 813d2273 

[   25.960135]  88003ed9bdb0 8107708b 81c4c17c 
88003e0d2000
[   25.961434]  88003eee8000 88003f3df240 7fff 
88003ed9bdc0
[   25.962727] Call Trace:
[   25.963151]  [] dump_stack+0x4b/0x6c
[   25.963999]  [] warn_slowpath_common+0x8a/0xa3
[   25.965015]  [] ? svc_recv+0x3eb/0x80c
[   25.965888]  [] warn_slowpath_null+0x15/0x17
[   25.966839]  [] svc_recv+0x3eb/0x80c
[   25.967687]  [] ? __schedule+0x5cf/0x823
[   25.968629]  [] ? nfs_callback_authenticate+0x29/0x29
[   25.969704]  [] nfs4_callback_svc+0x23/0x3c
[   25.970644]  [] kthread+0xf6/0xfe
[   25.971448]  [] ? __kthread_parkme+0x82/0x82
[   25.972432]  [] ret_from_fork+0x3f/0x70
[   25.973328]  [] ? __kthread_parkme+0x82/0x82
[   25.974283] ---[ end trace d811f9ece3901e91 ]---
[   25.980080] [ cut here ]





Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.3.0-rc7 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

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

Re: [PATCH v2 7/7] PCI: Set NumVFs before computing how many buses VFs require

[Wei Yang]

On Fri, Oct 30, 2015 at 09:03:54AM -0700, Alexander Duyck wrote:
>On 10/29/2015 10:22 PM, Wei Yang wrote:
>>On Thu, Oct 29, 2015 at 05:23:36PM -0500, Bjorn Helgaas wrote:
>>>From: Alexander Duyck 
>>>
>>>VF bus numbers depend on the First VF Offset and VF Stride, and per
>>>sections 3.3.9 and 3.3.10 of the SR-IOV spec r1.1, these depend on the
>>>NumVF value.
>>>
>>>Wait until after we set NumVFs to compute and validate the bus number of
>>>the last VF.
>>>
>>>[bhelgaas: changelog, add spec reference, split to separate patch for
>>>reviewability]
>>>Signed-off-by: Alexander Duyck 
>>>Signed-off-by: Bjorn Helgaas 
>>>---
>>>drivers/pci/iov.c |   18 ++
>>>1 file changed, 10 insertions(+), 8 deletions(-)
>>>
>>>diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>>>index bd1c4fa..9d29712 100644
>>>--- a/drivers/pci/iov.c
>>>+++ b/drivers/pci/iov.c
>>>@@ -274,13 +274,6 @@ static int sriov_enable(struct pci_dev *dev, int 
>>>nr_virtfn)
>>> return -ENOMEM;
>>> }
>>>
>>>-bus = pci_iov_virtfn_bus(dev, nr_virtfn - 1);
>>>-if (bus > dev->bus->busn_res.end) {
>>>-dev_err(&dev->dev, "can't enable %d VFs (bus %02x out of range 
>>>of %pR)\n",
>>>-nr_virtfn, bus, &dev->bus->busn_res);
>>>-return -ENOMEM;
>>>-}
>>>-
>>> if (pci_enable_resources(dev, bars)) {
>>> dev_err(&dev->dev, "SR-IOV: IOV BARS not allocated\n");
>>> return -ENOMEM;
>>>@@ -304,6 +297,15 @@ static int sriov_enable(struct pci_dev *dev, int 
>>>nr_virtfn)
>>> }
>>>
>>> pci_iov_set_numvfs(dev, nr_virtfn);
>>How about move it up?
>
>The idea with moving the write down is to keep the pollution of the SR-IOV
>capability to a minimum.  Basically we have addressed all of the possible
>software issues at this point so all that remains is possible hardware
>complications.  In addition by moving this code down we only have to modify
>this code instead of adding "rc=X; goto foo;" in places where "return X;" was
>used.
>

I think your logic is clear, while it is not easy to classify the software
issue and hardware complications. For example, at the beginning of
sriov_enable(), the hardware value initial VFs number is checked.

And in my mind, this is reasonable to check the hardware issue before software
issue.

For your comment, adding "rc=X; goto foo;", I don't see this would happen.
The code in my mind would like this:


+   pci_iov_set_numvfs(dev, nr_virtfn);
bus = pci_iov_virtfn_bus(dev, nr_virtfn - 1);
if (bus > dev->bus->busn_res.end) {
dev_err(&dev->dev, "can't enable %d VFs (bus %02x out of range 
of %pR)\n",
nr_virtfn, bus, &dev->bus->busn_res);
return -ENOMEM;
}
 
if (pci_enable_resources(dev, bars)) {
dev_err(&dev->dev, "SR-IOV: IOV BARS not allocated\n");
return -ENOMEM;

Do I missed something?

>Also this is an exception case.  There really isn't much point in optimizing
>for something that should never really happen.
>
>>>+
>>>+bus = pci_iov_virtfn_bus(dev, nr_virtfn - 1);
>>>+if (bus > dev->bus->busn_res.end) {
>>>+dev_err(&dev->dev, "can't enable %d VFs (bus %02x out of range 
>>>of %pR)\n",
>>>+nr_virtfn, bus, &dev->bus->busn_res);
>>>+rc = -ENOMEM;
>>>+goto err_bus;
>>>+}
>>>+
>>> iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
>>> pci_cfg_access_lock(dev);
>>> pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
>>>@@ -342,7 +344,7 @@ err_pcibios:
>>> pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
>>> ssleep(1);
>>> pci_cfg_access_unlock(dev);
>>>-
>>>+err_bus:
>>> if (iov->link != dev->devfn)
>>> sysfs_remove_link(&dev->dev.kobj, "dep_link");
>>>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [regression] c4e4528a6d: WARNING: CPU: 0 PID: 1 at kernel/trace/trace_functions_graph.c:223 ftrace_return_to_handler+0x94/0x11f()

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/alaahl/linux.git for-upstream
commit c4e4528a6dbfc0161a9445fdcbc53c26168adda9 ("regression: Disable FENTRY")


+-+++
| | 
b32721f46a | c4e4528a6d |
+-+++
| boot_successes  | 
9  | 0  |
| boot_failures   | 
6  | 13 |
| Out_of_memory:Kill_process  | 
5  ||
| BUG:kernel_boot_hang| 
1  ||
| WARNING:at_kernel/trace/trace_functions_graph.c:#ftrace_return_to_handler() | 
0  | 13 |
| backtrace:register_tracer   | 
0  | 10 |
| backtrace:init_graph_trace  | 
0  | 10 |
| backtrace:kernel_init_freeable  | 
0  | 10 |
| backtrace:cpu_startup_entry | 
0  | 1  |
+-+++


[2.093113] Testing ftrace regs: PASSED
[2.192075] Testing tracer function_graph: 
[2.280011] [ cut here ]
[2.284000] WARNING: CPU: 0 PID: 1 at 
kernel/trace/trace_functions_graph.c:223 ftrace_return_to_handler+0x94/0x11f()
[2.284000] Bad frame pointer: expected 880013803e40, received 
880013803ed0
[2.284000]   from func __calc_delta return to 884e5684
[2.284000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.3.0-rc6-01764-gc4e4528 #1
[2.284000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[2.284000]   880013803d40 88b30204 
880013803d88
[2.284000]  880013803d78 884a7e22 88562357 
885920c9
[2.284000]  8800138151c0 0002b800 880012be0060 
880013803de0
[2.284000] Call Trace:
[2.284000][] dump_stack+0x72/0x9d
[2.284000]  [] warn_slowpath_common+0xbc/0xd5
[2.284000]  [] ? ftrace_return_to_handler+0x94/0x11f
[2.284000]  [] ? devm_memunmap+0x85/0x85
[2.284000]  [] warn_slowpath_fmt+0x48/0x50
[2.284000]  [] ? __calc_delta+0x20/0x176
[2.284000]  [] ftrace_return_to_handler+0x94/0x11f
[2.284000]  [] ? sched_slice+0xf3/0x102
[2.284000]  [] ? sched_slice+0xf3/0x102
[2.284000]  [] return_to_handler+0x15/0x27
[2.284000]  [] ? ftrace_graph_caller+0x94/0x94
[2.284000]  [] sched_slice+0xf3/0x102
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] entity_tick+0x965/0xa30
[2.284000]  [] ? task_tick_fair+0x37/0x67
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] entity_tick+0x7dc/0xa30
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] entity_tick+0x2af/0xa30
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] task_tick_fair+0x37/0x67
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] scheduler_tick+0x56/0x92
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] update_process_times+0x5a/0x67
[2.284000]  [] ftrace_graph_caller+0x94/0x94
[2.284000]  [] tick_periodic+0x83/0x85
[2.284000]  [] apic_timer_interrupt+0x87/0x90
[2.284000][] ? amd_sched_process_job+0x9/0xb0
[2.284000]  [] ? amd_sched_process_job+0x9/0xb0
[2.284000]  [] ? hash_contains_ip+0x22/0x5a
[2.284000]  [] ftrace_get_addr_new+0x29/0xa2
[2.284000]  [] ftrace_replace_code+0x1b6/0x3f8
[2.284000]  [] ftrace_modify_all_code+0x41/0xca
[2.284000]  [] arch_ftrace_update_code+0x10/0x19
[2.284000]  [] ftrace_run_update_code+0x1e/0x3f
[2.284000]  [] ftrace_startup_enable+0x32/0x34
[2.284000]  [] ftrace_startup+0x1c5/0x1e1
[2.284000]  [] ? trace_graph_function+0x78/0x78
[2.284000]  [] register_ftrace_graph+0x241/0x25e
[2.284000]  [] ? ftrace_dump+0x1fd/0x1fd
[2.284000]  [] 
trace_selftest_startup_function_graph+0x55/0xdf
[2.284000]  [] register_tracer+0x12a/0x218
[2.284000]  [] ? init_graph_tracefs+0x32/0x32
[2.284000]  [] init_graph_trace+0x62/0x64
[2.284000]  [] do_one_initcall+0x131/0x224
[2.284000]  [] kernel_init_freeable+0x10e/0x1d1
[2.284000]  [] ? rest_init+0x8c/0x8c
[2.284000]  [] kernel_init+0xe/0x144
[2.284000]  [] ret_from_fork+0x3f/0x70
[2.284000]  [] ? rest_init+0x8c/0x8c
[2.284000] ---[ end trace 62f2af1e4e86c781 ]---
[2.284000] CPU: 0 PID: 1 Comm: swapper/0 Tain

Re: [PATCH 2/3] gpio: ath79: Move to the generic GPIO driver

[Linus Walleij]

On Sun, Nov 1, 2015 at 6:46 PM, Alban  wrote:
> On Sat, 31 Oct 2015 22:02:53 +0100
> Linus Walleij  wrote:

>> Please rebase it on this branch or wait until after the merge window.
>
> I see that you applied my previous patch "gpio: ath79: Convert to the
> state container design pattern", this series was supposed to replace
> this patch. I'm sorry I forgot to mention this. That old patch doesn't
> make much sense any more as most of the code it changed just get
> dropped in the move to GPIO_GENERIC.

Hm you can tell me exactly which commits I need to revert
or something ... I cannot rebase the tree now.

It would be best if you cook a GPIO_GENERIC patch based on
devel.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain]

Hi Stephan,

On 2015年10月30日 16:59, Stephan Mueller wrote:
> Am Freitag, 30. Oktober 2015, 16:22:46 schrieb Zain Wang:
>
> Hi Zain,
>
>> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
>> mode. The names registered are:
>>ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>> You can alloc tags above in your case.
>>
>> And other algorithms and platforms will be added later on.
>>
>> Signed-off-by: Zain Wang 
>> ---
>> drivers/crypto/Makefile|   1 +
>> drivers/crypto/rk_crypto/Makefile  |   3 +
>> drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>> drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>> .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502
>> + 5 files changed, 1190 insertions(+)
>> create mode 100644 drivers/crypto/rk_crypto/Makefile
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>>
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c3ced6f..00d103c 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>> obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>> obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>> diff --git a/drivers/crypto/rk_crypto/Makefile
>> b/drivers/crypto/rk_crypto/Makefile new file mode 100644
>> index 000..0f62d87
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>> +rk_crypto_driver-objs := rk3288_crypto.o \
>> + rk3288_crypto_ablkcipher.o \
>> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c
>> b/drivers/crypto/rk_crypto/rk3288_crypto.c new file mode 100644
>> index 000..fe55d7e
>> --- /dev/null
>> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>> @@ -0,0 +1,393 @@
>> +/*
>> + *Crypto acceleration support for Rockchip RK3288
>> + *
>> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * Author: Zain Wang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>> + */
>> +
>> +#include "rk3288_crypto.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct crypto_info_t *crypto_p;
>> +
>> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>> +{
>> +if (clk_prepare_enable(dev->clk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>> +__func__, __LINE__);
>> +return -ENOENT;
>> +}
>> +if (clk_prepare_enable(dev->aclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>> +__func__, __LINE__);
>> +goto err_aclk;
>> +}
>> +if (clk_prepare_enable(dev->hclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>> +__func__, __LINE__);
>> +goto err_hclk;
>> +}
>> +if (clk_prepare_enable(dev->pclk)) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>> +__func__, __LINE__);
>> +goto err_pclk;
>> +}
>> +return 0;
>> +
>> +err_pclk:
>> +clk_disable_unprepare(dev->hclk);
>> +err_hclk:
>> +clk_disable_unprepare(dev->aclk);
>> +err_aclk:
>> +clk_disable_unprepare(dev->clk);
>> +
>> +return -ENOENT;
>> +}
>> +
>> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>> +{
>> +clk_disable_unprepare(dev->hclk);
>> +clk_disable_unprepare(dev->aclk);
>> +clk_disable_unprepare(dev->pclk);
>> +clk_disable_unprepare(dev->clk);
>> +}
>> +
>> +static int check_alignment(struct scatterlist *sg_src,
>> +   struct scatterlist *sg_dst,
>> +   int align_mask)
>> +{
>> +int in, out, align;
>> +
>> +in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>> + IS_ALIGNED(sg_src->length, align_mask);
>> +if (sg_dst == NULL)
>> +return in;
>> +out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>> +  IS_ALIGNED(sg_dst->length, align_mask);
>> +align = in && out;
>> +
>> +return (align && (sg_src->length == sg_dst->length));
>> +}
>> +
>> +static int rk_load_data(struct crypto_info_t *dev,
>> +  struct scatterlist *sg_src,
>> +  struct scatterlist *sg_dst)
>> +{
>> +uint32_t count;
>> +   

Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs

[Wei Yang]

On Fri, Oct 30, 2015 at 08:57:17AM -0700, Alexander Duyck wrote:
>On 10/29/2015 11:00 PM, ethan zhao wrote:
>>Wei,
>>
>>On 2015/10/30 13:14, Wei Yang wrote:
>>>On Thu, Oct 29, 2015 at 05:23:22PM -0500, Bjorn Helgaas wrote:
From: Alexander Duyck 

Per sec 3.3.3.1 of the SR-IOV spec, r1.1, we must allow 1.0s after
clearing
VF Enable before reading any field in the SR-IOV Extended Capability.

Wait 1 second before calling pci_iov_set_numvfs(), which reads
PCI_SRIOV_VF_OFFSET and PCI_SRIOV_VF_STRIDE after it sets
PCI_SRIOV_NUM_VF.

[bhelgaas: split to separate patch for reviewability, add spec
reference]
Signed-off-by: Alexander Duyck 
Signed-off-by: Bjorn Helgaas 
---
drivers/pci/iov.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index fada98d..24428d5 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -339,13 +339,13 @@ failed:
iov->ctrl &= ~(PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE);
pci_cfg_access_lock(dev);
pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
-pci_iov_set_numvfs(dev, 0);
ssleep(1);
pci_cfg_access_unlock(dev);

if (iov->link != dev->devfn)
sysfs_remove_link(&dev->dev.kobj, "dep_link");

+pci_iov_set_numvfs(dev, 0);
>>>One small question, any specific reason put it here instead of just after
>>>sleep()?
>> Agree,  pci_iov_set_numvfs(dev, 0) should be put before
>>pci_cfg_access_unlock(dev) to avoid race,  because "NumVFs may only be
>>written while VF Enable is Clear"
>
>We are already guaranteeing that aren't we?  I'm assuming there is already
>code in place here somewhere that prevents us from both enabling and
>disabling SR-IOV from more than one thread.  Otherwise how could we hope to
>have any sort of consistent state?
>
>I'm fine with us being more explicit about it if we want to be, but if we are
>going to do it we should probably update all 3 spots where we update NumVFs
>after init instead of just this one.  Perhaps it should be a separate patch.
>

Yep, I think the statement is met, "NumVFs may only be written while VF Enable
is Clear".

While in your commit log, the purpose of this patch is to wait 1 second before
write NumVFs. So I am interesting to know why you move this out of the
pci_cfg_access_lock. Because it looks better? have better performance?

Actually, this is a question instead of a challenge :-)

>- Alex

-- 
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mtd: nand: automate NAND timings selection

[Boris Brezillon]

Hi Ezequiel,

On Sun, 1 Nov 2015 21:37:33 -0300
Ezequiel Garcia  wrote:

> Hi Boris,
> 
> This looks nice. I gave a try at this patch and it allows to simplify
> pxa3xx-nand greatly. A few comments below.
> 
> On 23 Oct 01:03 PM, Boris Brezillon wrote:
> > The NAND framework provides several helpers to query timing modes supported
> > by a NAND chip, but this implies that all NAND controller drivers have
> > to implement the same timings selection dance.
> > 
> > Provide a common logic to select the best timings based on ONFI or
> > ->onfi_timing_mode_default information.
> > NAND controller willing to support timings adjustment should just
> > implement the ->setup_data_interface() method.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/nand/nand_base.c | 189 
> > ++-
> >  include/linux/mtd/nand.h | 115 +++---
> >  2 files changed, 254 insertions(+), 50 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> > index eaf1fcd..52a1f89 100644
> > --- a/drivers/mtd/nand/nand_base.c
> > +++ b/drivers/mtd/nand/nand_base.c
> > @@ -3323,6 +3323,144 @@ static void nand_onfi_detect_micron(struct 
> > nand_chip *chip,
> > chip->setup_read_retry = nand_setup_read_retry_micron;
> >  }
> >  
> > +/**
> > + * nand_setup_data_interface - Setup the data interface and timings on the
> > + *controller side
> > + * @mtd: MTD device structure
> > + * @conf: new configuration to apply
> > + *
> > + * Try to configure the NAND controller to support the provided data
> > + * interface configuration.
> > + *
> > + * Returns 0 in case of success or -ERROR_CODE.
> > + */
> > +static int nand_setup_data_interface(struct mtd_info *mtd,
> > +const struct nand_data_interface *conf)
> > +{
> > +   struct nand_chip *chip = mtd->priv;
> > +   int ret;
> > +
> > +   if (!chip->setup_data_interface)
> > +   return -ENOTSUPP;
> > +
> > +   ret = chip->setup_data_interface(mtd, conf, false);
> > +   if (ret)
> > +   return ret;
> > +
> > +   *chip->data_iface = *conf;
> > +
> > +   return 0;
> > +}
> > +
> > +/**
> > + * nand_setup_data_interface - Check if a data interface config is 
> > supported
> 
> s/setup/check

Yes, I'll fix it.

> 
> > + *by the NAND controller
> > + * @mtd: MTD device structure
> > + * @conf: new configuration to apply
> > + *
> > + * Check if the provided data interface configuration is supported by the
> > + * NAND controller.
> > + *
> > + * Returns 0 if it is supported or -ERROR_CODE.
> > + */
> > +static int nand_check_data_interface(struct mtd_info *mtd,
> > +const struct nand_data_interface *conf)
> > +{
> > +   struct nand_chip *chip = mtd->priv;
> > +
> > +   if (!chip->setup_data_interface)
> > +   return -ENOTSUPP;
> > +
> > +   return chip->setup_data_interface(mtd, conf, true);
> > +}
> > +
> > +/**
> > + * nand_configure_data_interface - Configure the data interface and timings
> > + * @mtd: MTD device structure
> > + *
> > + * Try to configure the data interface and NAND timings appropriately.
> > + * First tries to retrieve supported timing modes from ONFI information,
> > + * and if the NAND chip does not support ONFI, relies on the
> > + * ->onfi_timing_mode_default specified in the nand_ids table.
> > + *
> > + * Returns 0 in case of success or -ERROR_CODE.
> > + */
> > +static int nand_configure_data_interface(struct mtd_info *mtd)
> > +{
> > +   struct nand_chip *chip = mtd->priv;
> > +   struct nand_data_interface *conf;
> > +   int modes, mode, ret = -EINVAL;
> > +
> > +   conf = kzalloc(sizeof(*conf), GFP_KERNEL);
> > +   if (!conf)
> > +   return -ENOMEM;
> > +
> > +   /* TODO: support DDR interfaces */
> > +   conf->type = NAND_SDR_IFACE;
> > +
> > +   /*
> > +* First try to identify the best timings from ONFI parameters and
> > +* if the NAND does not support ONFI, fallback to the default ONFI
> > +* timing mode.
> > +*/
> > +   modes = onfi_get_async_timing_mode(chip);
> > +   if (modes != ONFI_TIMING_MODE_UNKNOWN) {
> > +   for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > +   conf->timings.sdr =
> > +   *onfi_async_timing_mode_to_sdr_timings(mode);
> > +
> > +   ret = nand_check_data_interface(mtd, conf);
> > +   if (!ret)
> > +   break;
> > +   }
> > +   } else {
> > +   mode = chip->onfi_timing_mode_default;
> > +   conf->timings.sdr =
> > +   *onfi_async_timing_mode_to_sdr_timings(mode);
> > +
> > +   ret = nand_check_data_interface(mtd, conf);
> > +   }
> > +
> > +   if (!ret) {
> > +   uint8_t tmode_param[ONFI_SUBFEATURE_PARAM_LEN] = { mode };
> > +   int i;
> > +
> > +   /*
> > +* Ensure the timing mode h

Re: [PATCH] clocksource: dw_apb_timer_of: support timer-based delay

[Daniel Lezcano]

On 11/02/2015 03:51 AM, Jisheng Zhang wrote:

Dear Daniel,

On Fri, 30 Oct 2015 13:37:01 +0100
Daniel Lezcano wrote:


On 10/30/2015 12:09 PM, Jisheng Zhang wrote:

Dear Daniel,

On Fri, 30 Oct 2015 11:44:46 +0100
Daniel Lezcano  wrote:


On 10/30/2015 09:27 AM, Jisheng Zhang wrote:

Implement an ARM delay timer to be used for udelay(). This allows us to
skip the delay loop calibration at boot on Marvell BG2, BG2Q, BG2CD
platforms. And after this patch, udelay() will be unaffected by CPU
frequency changes.

Signed-off-by: Jisheng Zhang 
---
drivers/clocksource/Kconfig   | 10 ++
drivers/clocksource/dw_apb_timer_of.c | 16 
2 files changed, 26 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a7726db..7b081805 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -29,6 +29,16 @@ config DW_APB_TIMER_OF
select DW_APB_TIMER
select CLKSRC_OF

+config DW_APB_TIMER_BASED_DELAY
+   bool "DW APB timer based delay"
+   depends on ARM && DW_APB_TIMER_OF
+   default n
+   help
+ This option enables support for using the DW APB timer to
+ implement timer-based delay. It is useful for skiping the
+ delay loop calibration at boot on some platforms. And the
+ udelay() will be unaffected by CPU frequency changes.
+


Why do you want it to be optional ?



Because in some platforms which has arm arch timer, this dw apb timer
delay isn't needed, the arch timer is better. So we want it be optional
so that the platforms which need this feature select it manually when config
the kernel.


Correct me if I am wrong. If you have the arch timer, you don't need the


Yes, I don't need the dw apb timer if we have arch timer,


dw apb timer at all, no ? So the selection would be arch arm timer *or*
dw_apb_timer ? not arch_arm_timer for delay and dw_apb_timer for
clockevents, right ?


Yes, if we have arch timer, I prefer to use it for clockevent and delay.

Could you please provide suggestion how to handle this case?


If I follow the logic of arch_arm_timer is better than dw_apb timer.

1. The arch_arm_timer is present

 => dw_apb timer is not used at all

 CONFIG_ARM_ARCH_TIMER=y
 # CONFIG_DW_APB_TIMER is not set

2. The arch_arm_timer is *not* present

 => dw_apb_timer is used with delay code

 # CONFIG_ARM_ARCH_TIMER is not set
 CONFIG_DW_APB_TIMER=y

In both cases, DW_APB_TIMER_BASED_DELAY is not needed.


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git pull] m68k updates for 4.4

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-next

for you to fetch changes up to bab84fa9cc09dfa9702029f83ea6bf8bf5ae96af:

  m68k/sun3: Use %pM format specifier to print ethernet address (2015-09-13 
14:37:26 +0200)


Alexander Kuleshov (1):
  m68k/sun3: Use %pM format specifier to print ethernet address

 arch/m68k/sun3/idprom.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

Thanks for pulling!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: of: removing two variables min_uV and max_uV

[Mark Brown]

On Sat, Oct 31, 2015 at 08:31:31PM +0530, Saurabh Sengar wrote:

> - min_uV = of_get_property(np, "regulator-min-microvolt", NULL);
> - if (min_uV)
> - constraints->min_uV = be32_to_cpu(*min_uV);

> + if (!of_property_read_u32(np, "regulator-max-microvolt", &pval))
> + constraints->max_uV = pval;

>   /* Only one voltage?  Then make sure it's set. */
> - if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
> + if (constraints->min_uV == constraints->max_uV)
>   constraints->apply_uV = true;

Your new code is not equivalent to the existing code.  The new code will
set apply_uV even if the DT properties are not present which will in
turn mean that we will end up attempting to apply a setting of 0V if
that happens which is not desirable.


signature.asc
Description: PGP signature

Re: [PATCH v2 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Mark Brown]

On Fri, Oct 30, 2015 at 05:41:43PM -0500, Andrew F. Davis wrote:

> +struct tps65086_regulator {
> + struct regulator_desc desc;
> + unsigned int decay_reg;
> + unsigned int decay_mask;

The decay_reg and decay_mask fields appear to be entirely write only,
why are they present?

> + ret = of_regulator_match(&pdev->dev, pdev->dev.of_node,
> +  tps65086_matches,
> +  ARRAY_SIZE(tps65086_matches));
> + if (ret < 0) {
> + dev_err(tps->dev, "Error parsing regulator init data\n");
> + return ret;
> + }

Please match regulators using the fields in the regulator_desc rather
than open coding.


signature.asc
Description: PGP signature

Re: [lkp] [mm, page_alloc] 43993977ba: +88% OOM possibility

[Huang, Ying]

Michal Hocko  writes:

> On Mon 02-11-15 07:20:37, Huang, Ying wrote:
>> Michal Hocko  writes:
>> 
>> > On Fri 30-10-15 16:21:40, Huang, Ying wrote:
>> >> Michal Hocko  writes:
>> >> 
>> >> > On Wed 28-10-15 13:36:02, kernel test robot wrote:
>> >> >> FYI, we noticed the below changes on
>> >> >> 
>> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
>> >> >> master
>> >> >> commit 43993977baecd838d66ccabc7f682342fc6ff635 ("mm, page_alloc:
>> >> >> distinguish between being unable to sleep, unwilling to sleep and
>> >> >> avoiding waking kswapd")
>> >> >> 
>> >> >> We found the OOM possibility increased 88% in a virtual machine with 
>> >> >> 1G memory.
>> >> >
>> >> > Could you provide dmesg output from this test?
>> >> 
>> >> Sure, Attached.
>> >
>> > I can only see a single allocation failure warning:
>> > kworker/u4:1: page allocation failure: order:0, mode:0x2204000
>> >
>> > This is obviously a non sleeping allocation with ___GFP_KSWAPD_RECLAIM
>> > set. ___GFP_HIGH (aka access to memory reserves) is not required so a
>> > failure of such an allocation is something to be expected.
>> >
>> > [ 2294.616369] Workqueue: btrfs-submit btrfs_submit_helper
>> > [ 2294.616369]   88000d38f5e0 8173f84c 
>> > 
>> > [ 2294.616369]  88000d38f678 811abaee  
>> > 00010038f618
>> > [ 2294.616369]  8800584e4148  8800584e2f00 
>> > 0001
>> > [ 2294.616369] Call Trace:
>> > [ 2294.616369]  [] dump_stack+0x4b/0x63
>> > [ 2294.616369]  [] warn_alloc_failed+0x125/0x13d
>> > [ 2294.616369]  [] __alloc_pages_nodemask+0x7c9/0x915
>> > [ 2294.616369]  [] kmem_getpages+0x91/0x155
>> > [ 2294.616369]  [] fallback_alloc+0x1cc/0x24c
>> > [ 2294.616369]  [] cache_alloc_node+0x151/0x160
>> > [ 2294.616369]  [] __kmalloc+0xb0/0x134
>> > [ 2294.616369]  [] ? sched_clock+0x9/0xb
>> > [ 2294.616369]  [] ? virtqueue_add+0x78/0x37f
>> > [ 2294.616369]  [] virtqueue_add+0x78/0x37f
>> > [ 2294.616369]  [] ? __lock_acquire+0x751/0xf55
>> > [ 2294.616369]  [] virtqueue_add_sgs+0x76/0x85
>> >
>> > The patch you are referring shouldn't make any change in this path
>> > because alloc_indirect which I expect is the allocation failing here
>> > does:
>> > gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH)
>> >
>> > and that came in via b92b1b89a33c ("virtio: force vring descriptors to
>> > be allocated from lowmem").
>> >
>> > Are there more failed allocations during the test? The subject would
>> > suggest so.
>> 
>> We done 24 tests for the commit and 24 tests for its parent.  There is
>> no OOM in any test for the parent commit, but there are OOM in 21 tests
>> for this commit.  This is what I want to say in the subject.  Sorry for
>> confusing.
>
> It would be interesting to see all the page allocation failure warnings
> (if they are different). Maybe other callers have relied on GFP_ATOMIC
> and access to memory reserves. The above path is not this case though.

I take a look at all dmesgs, and found the backtrace for page allocation
failure is same for all.  Is it possible that this commit cause more
memory were allocated or kept in memory so that more OOM were triggered?

Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

On Mon, 02 Nov 2015, Milo Kim wrote:

> TI LMU(Lighting Management Unit) driver supports lighting devices below.
> 
>  Enable pin  Backlights  HWMON  LEDs   Regulators
>  --  --  -    
> LM3532   o   o x xx
> LM3631   o   o x x5 regulators
> LM3632   o   o x x3 regulators
> LM3633   o   o o ox
> LM3695   o   o x xx
> LM3697   o   o o xx
> 
> This patch-set consists of several parts below.
> 
>   DT bindings   : Binding information for each module
>   TI LMU MFD: Device registration, HW enable pin control and
>   I2C register access
>   TI LMU backlight  : Common driver for TI LMU backlight devices
>   Each backlight driver : Chip dependent code
>   HWMON : LMU hardware fault monitoring driver
>   LM3633 LED: LED subsystem and dimming pattern generation
>   supported
>   LM363X regulator  : LM3631 and LM3632 regulator driver for the
>   display bias
> 
> Git location:
>   Please refer to the location below. Branch name is 'ti-lmu'.
>   git clone -b ti-lmu https://github.com/milokim/linux.git
> 
> Milo Kim (16):
>   Documentation: dt-bindings: mfd: add TI LMU device binding information
>   Documentation: dt-bindings: backlight: add TI LMU backlight binding
> information
>   Documentation: dt-bindings: hwmon: add TI LMU HWMON binding
> information
>   Documentation: dt-bindings: leds: add LM3633 LED binding information
>   Documentation: dt-bindings: regulator: add LM363x regulator binding
> information
>   mfd: add TI LMU driver
>   backlight: add TI LMU backlight common driver
>   backlight: ti-lmu-backlight: add LM3532 driver
>   backlight: ti-lmu-backlight: add LM3631 driver
>   backlight: ti-lmu-backlight: add LM3632 driver
>   backlight: ti-lmu-backlight: add LM3633 driver
>   backlight: ti-lmu-backlight: add LM3695 driver
>   backlight: ti-lmu-backlight: add LM3697 driver
>   hwmon: add TI LMU hardware fault monitoring driver
>   leds: add LM3633 driver
>   regulator: add LM363X driver
> 
>  Documentation/ABI/testing/sysfs-class-led-lm3633   |  60 ++
>  .../devicetree/bindings/hwmon/ti-lmu-hwmon.txt |  12 +
>  .../devicetree/bindings/leds/leds-lm3633.txt   |  28 +
>  Documentation/devicetree/bindings/mfd/ti-lmu.txt   | 282 
>  .../bindings/regulator/lm363x-regulator.txt|  28 +
>  .../bindings/video/backlight/ti-lmu-backlight.txt  |  67 ++
>  drivers/hwmon/Kconfig  |  10 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/ti-lmu-hwmon.c   | 393 +++
>  drivers/leds/Kconfig   |  10 +
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-lm3633.c | 749 
> +
>  drivers/mfd/Kconfig|  12 +
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/ti-lmu.c   | 324 +
>  drivers/regulator/Kconfig  |   9 +
>  drivers/regulator/Makefile |   1 +
>  drivers/regulator/lm363x-regulator.c   | 349 ++
>  drivers/video/backlight/Kconfig|  62 ++
>  drivers/video/backlight/Makefile   |   7 +
>  drivers/video/backlight/lm3532_bl.c| 183 +
>  drivers/video/backlight/lm3631_bl.c| 129 
>  drivers/video/backlight/lm3632_bl.c| 125 
>  drivers/video/backlight/lm3633_bl.c| 210 ++
>  drivers/video/backlight/lm3695_bl.c|  91 +++
>  drivers/video/backlight/lm3697_bl.c| 187 +
>  drivers/video/backlight/ti-lmu-backlight.c | 429 
>  drivers/video/backlight/ti-lmu-backlight.h | 152 +

How different are all of these drivers?

Can you create one driver that supports them all instead?

>  include/linux/mfd/ti-lmu-register.h| 277 
>  include/linux/mfd/ti-lmu.h |  81 +++
>  30 files changed, 4270 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-led-lm3633
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
>  create mode 100644 
> Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
>  create mode 100644 drivers/hwmon/ti-lmu-hwmon.c
>  create mode 100644 drivers/leds/leds-lm3633.c
>  crea

Re: [PATCH] bpf: convert hashtab lock to raw lock

[Thomas Gleixner]

On Sun, 1 Nov 2015, Alexei Starovoitov wrote:
> On Sat, Oct 31, 2015 at 09:47:36AM -0400, Steven Rostedt wrote:
> > On Fri, 30 Oct 2015 17:03:58 -0700
> > Alexei Starovoitov  wrote:
> > 
> > > On Fri, Oct 30, 2015 at 03:16:26PM -0700, Yang Shi wrote:
> > > > When running bpf samples on rt kernel, it reports the below warning:
> > > > 
> > > > BUG: sleeping function called from invalid context at 
> > > > kernel/locking/rtmutex.c:917
> > > > in_atomic(): 1, irqs_disabled(): 128, pid: 477, name: ping
> > > > Preemption disabled at:[] kprobe_perf_func+0x30/0x228 
> > > >  
> > > ...
> > > > diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> > > > index 83c209d..972b76b 100644
> > > > --- a/kernel/bpf/hashtab.c
> > > > +++ b/kernel/bpf/hashtab.c
> > > > @@ -17,7 +17,7 @@
> > > >  struct bpf_htab {
> > > > struct bpf_map map;
> > > > struct hlist_head *buckets;
> > > > -   spinlock_t lock;
> > > > +   raw_spinlock_t lock;  
> > > 
> > > How do we address such things in general?
> > > I bet there are tons of places around the kernel that
> > > call spin_lock from atomic.
> > > I'd hate to lose the benefits of lockdep of non-raw spin_lock
> > > just to make rt happy.
> > 
> > You wont lose any benefits of lockdep. Lockdep still checks
> > raw_spin_lock(). The only difference between raw_spin_lock and
> > spin_lock is that in -rt spin_lock turns into an rt_mutex() and
> > raw_spin_lock stays a spin lock.
> 
> I see. The patch makes sense then.
> Would be good to document this peculiarity of spin_lock.

I'm working on a document.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

Is it just me, or have you missed lots of people off Cc?

> TI LMU(Lighting Management Unit) driver supports lighting devices below.
> 
>  Enable pin  Backlights  HWMON  LEDs   Regulators
>  --  --  -    
> LM3532   o   o x xx
> LM3631   o   o x x5 regulators
> LM3632   o   o x x3 regulators
> LM3633   o   o o ox
> LM3695   o   o x xx
> LM3697   o   o o xx
> 
> This patch-set consists of several parts below.
> 
>   DT bindings   : Binding information for each module
>   TI LMU MFD: Device registration, HW enable pin control and
>   I2C register access
>   TI LMU backlight  : Common driver for TI LMU backlight devices
>   Each backlight driver : Chip dependent code
>   HWMON : LMU hardware fault monitoring driver
>   LM3633 LED: LED subsystem and dimming pattern generation
>   supported
>   LM363X regulator  : LM3631 and LM3632 regulator driver for the
>   display bias
> 
> Git location:
>   Please refer to the location below. Branch name is 'ti-lmu'.
>   git clone -b ti-lmu https://github.com/milokim/linux.git
> 
> Milo Kim (16):
>   Documentation: dt-bindings: mfd: add TI LMU device binding information
>   Documentation: dt-bindings: backlight: add TI LMU backlight binding
> information
>   Documentation: dt-bindings: hwmon: add TI LMU HWMON binding
> information
>   Documentation: dt-bindings: leds: add LM3633 LED binding information
>   Documentation: dt-bindings: regulator: add LM363x regulator binding
> information
>   mfd: add TI LMU driver
>   backlight: add TI LMU backlight common driver
>   backlight: ti-lmu-backlight: add LM3532 driver
>   backlight: ti-lmu-backlight: add LM3631 driver
>   backlight: ti-lmu-backlight: add LM3632 driver
>   backlight: ti-lmu-backlight: add LM3633 driver
>   backlight: ti-lmu-backlight: add LM3695 driver
>   backlight: ti-lmu-backlight: add LM3697 driver
>   hwmon: add TI LMU hardware fault monitoring driver
>   leds: add LM3633 driver
>   regulator: add LM363X driver
> 
>  Documentation/ABI/testing/sysfs-class-led-lm3633   |  60 ++
>  .../devicetree/bindings/hwmon/ti-lmu-hwmon.txt |  12 +
>  .../devicetree/bindings/leds/leds-lm3633.txt   |  28 +
>  Documentation/devicetree/bindings/mfd/ti-lmu.txt   | 282 
>  .../bindings/regulator/lm363x-regulator.txt|  28 +
>  .../bindings/video/backlight/ti-lmu-backlight.txt  |  67 ++
>  drivers/hwmon/Kconfig  |  10 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/ti-lmu-hwmon.c   | 393 +++
>  drivers/leds/Kconfig   |  10 +
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-lm3633.c | 749 
> +
>  drivers/mfd/Kconfig|  12 +
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/ti-lmu.c   | 324 +
>  drivers/regulator/Kconfig  |   9 +
>  drivers/regulator/Makefile |   1 +
>  drivers/regulator/lm363x-regulator.c   | 349 ++
>  drivers/video/backlight/Kconfig|  62 ++
>  drivers/video/backlight/Makefile   |   7 +
>  drivers/video/backlight/lm3532_bl.c| 183 +
>  drivers/video/backlight/lm3631_bl.c| 129 
>  drivers/video/backlight/lm3632_bl.c| 125 
>  drivers/video/backlight/lm3633_bl.c| 210 ++
>  drivers/video/backlight/lm3695_bl.c|  91 +++
>  drivers/video/backlight/lm3697_bl.c| 187 +
>  drivers/video/backlight/ti-lmu-backlight.c | 429 
>  drivers/video/backlight/ti-lmu-backlight.h | 152 +
>  include/linux/mfd/ti-lmu-register.h| 277 
>  include/linux/mfd/ti-lmu.h |  81 +++
>  30 files changed, 4270 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-led-lm3633
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
>  create mode 100644 
> Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
>  create mode 100644 drivers/hwmon/ti-lmu-hwmon.c
>  create mode 100644 drivers/leds/leds-lm3633.c
>  create mode 100644 drivers/mfd/ti-lmu.c
>  create mode 100644 drivers/regulator/lm363

b43: removal of B43_PCMCIA

[Valentin Rothberg]

Hi Rafal,

your commit 399500da18f7 ("ssb: pick PCMCIA host code support from b43
driver") has shown up in today's Linux next tree (i.e., next-20151102)
and removes the Kconfig option B43_PCMCIA and references on it in the
code.  However the commit misses to remove the following reference:

drivers/net/wireless/b43/main.c:5829:#ifdef CONFIG_B43_PCMCIA
drivers/net/wireless/b43/main.c-5830-   feat_pcmcia = "M";
drivers/net/wireless/b43/main.c-5831-#endif

Is it by purpose?  In case not, I can send a trivial patch to remove
those three lines.

I detected the issue with scripts/checkkconfigsymbols.py.

Kind regards,
 Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Lee Jones]

On Mon, 02 Nov 2015, Alexandre Belloni wrote:

> On 02/11/2015 at 08:46:21 +0900, Krzysztof Kozlowski wrote :
> > On 02.11.2015 02:40, Alexandre Belloni wrote:
> > > On 30/10/2015 at 11:55:34 +0530, Alim Akhtar wrote :
> > >> RTC found in s2mps15 is almost same as one found on s2mps13
> > >> with few differences in RTC_UPDATE register fields, like:
> > >> 1> Bit[4] and Bit[1] are reversed
> > >>- On s2mps13
> > >>   WUDR -> bit[4], AUDR -> bit[1]
> > >>- On s2mps15
> > >>WUDR -> bit[1], AUDR -> bit[4]
> > >> 2> In case of s2mps13, for alarm register, need to set both
> > >>WDUR and ADUR high, whereas for s2mps15 only set AUDR to high.
> > >> 3> On s2mps15, WUDR, RUDR and AUDR functions should never be used
> > >>at the same time.
> > >>
> > >> This patch add required changes to enable s2mps15 rtc timer.
> > >>
> > >> Cc: Alexandre Belloni 
> > >> Signed-off-by: Alim Akhtar 
> > >> ---
> > >>  drivers/rtc/rtc-s5m.c   |   37 
> > >> +
> > >>  include/linux/mfd/samsung/rtc.h |2 ++
> > >>  2 files changed, 35 insertions(+), 4 deletions(-)
> > >>
> > > Applied after fixing the small alignment issue, thanks.
> > > 
> > 
> > I think you cannot apply it directly because it depends on headers from
> > patch 2/4. It won't build.
> > 
> 
> Yeah, this depends on the mfd tree. I don't thin Lee applied patch 2/4
> yet so I'm taking that one for 4.5.

I don't mind if you take it, but if you do so you need to take the
Regulator patch as well AND provide Mark and I a pull-request from an
immutable branch please. 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] bfs: fix i_blocks accounting

[Wei Fang]

Update inode->i_blocks if succeed to get block, otherwise we'll
get wrong number of blocks.

Signed-off-by: Wei Fang 
---
 fs/bfs/file.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/bfs/file.c b/fs/bfs/file.c
index 97f1b51..f89abdb 100644
--- a/fs/bfs/file.c
+++ b/fs/bfs/file.c
@@ -108,6 +108,7 @@ static int bfs_get_block(struct inode *inode, sector_t 
block,
map_bh(bh_result, sb, phys);
info->si_freeb -= phys - bi->i_eblock;
info->si_lf_eblk = bi->i_eblock = phys;
+   inode->i_blocks = block + 1;
mark_inode_dirty(inode);
err = 0;
goto out;
@@ -141,7 +142,8 @@ static int bfs_get_block(struct inode *inode, sector_t 
block,
 * This assumes nothing can write the inode back while we are here
 * and thus update inode->i_blocks! (XXX)
 */
-   info->si_freeb -= bi->i_eblock - bi->i_sblock + 1 - inode->i_blocks;
+   info->si_freeb -= block + 1 - inode->i_blocks;
+   inode->i_blocks = block + 1;
mark_inode_dirty(inode);
map_bh(bh_result, sb, phys);
 out:
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: b43: removal of B43_PCMCIA

[Rafał Miłecki]

On 2 November 2015 at 10:03, Valentin Rothberg
 wrote:
> your commit 399500da18f7 ("ssb: pick PCMCIA host code support from b43
> driver") has shown up in today's Linux next tree (i.e., next-20151102)
> and removes the Kconfig option B43_PCMCIA and references on it in the
> code.  However the commit misses to remove the following reference:
>
> drivers/net/wireless/b43/main.c:5829:#ifdef CONFIG_B43_PCMCIA
> drivers/net/wireless/b43/main.c-5830-   feat_pcmcia = "M";
> drivers/net/wireless/b43/main.c-5831-#endif
>
> Is it by purpose?  In case not, I can send a trivial patch to remove
> those three lines.
>
> I detected the issue with scripts/checkkconfigsymbols.py.

Nice catch, please remove that line from main.c.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the pinctrl tree with the at91 tree

[Nicolas Ferre]

Le 01/11/2015 15:16, Stephen Rothwell a écrit :
> Hi Linus,
> 
> Today's linux-next merge of the pinctrl tree got a conflict in:
> 
>   arch/arm/boot/dts/sama5d2.dtsi
> 
> between commit:
> 
>   512fc048e4fd ("ARM: at91/dt: sama5d2: add missing devices")
> 
> from the at91 tree and commit:
> 
>   f6c804b08ca5 ("ARM: at91/dt: sama5d2: add pio controller node")
> 
> from the pinctrl tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Hi Stephen,

The fix is good: thanks. (We tend to sort DT nodes by address which
would have given the pinctrl node before the tdes one but that not a big
deal: we still can correct this later with a trivial patch).

Bye,
-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] drm/i915/dma: enforce pr_ consistency

[Jani Nikula]

On Sat, 31 Oct 2015, Ioan-Adrian Ratiu  wrote:
> One branch of the if clause uses pr_info, the other pr_err; change
> the 'false' branch to also use pr_info. This minor oversight has gone
> unfixed since the initial vga_switcheroo implementation in 6a9ee8af.
>
> Signed-off-by: Ioan-Adrian Ratiu 

Pushed to drm-intel-next-queued, thanks for the patch.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 2336af9..b23f465 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -338,7 +338,7 @@ static void i915_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switcheroo_
>   i915_resume_switcheroo(dev);
>   dev->switch_power_state = DRM_SWITCH_POWER_ON;
>   } else {
> - pr_err("switched off\n");
> + pr_info("switched off\n");
>   dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
>   i915_suspend_switcheroo(dev, pmm);
>   dev->switch_power_state = DRM_SWITCH_POWER_OFF;

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: livepatch: old_name@old_addr scheme in livepatch sysfs directory

[Jessica Yu]

+++ Jiri Kosina [01/11/15 10:07 +0100]:

On Sat, 31 Oct 2015, Chris J Arges wrote:


Makes sense to me. Is there a reason why the sysfs entries are visible
to non-root users?


Well, kptr_restrict applies only to values printed using '%pK'. So if the
sysfs handler is using other printk() format string to print the pointer,
it'll be leaked out (and should eventually be fixed).


Hm, I think the func.n solution might be a good temporary fix for now.
Even if we do go with func@addr and use the '%pK' format specifier we
will run into the same problem at kptr_restrict == 2.

Jessica
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ALSA: firewire-lib: fix compare_const_fl.cocci warnings

[Takashi Sakamoto]

Hi Julia,

On Nov 02 2015 16:20, Julia Lawall wrote:

On Mon, 2 Nov 2015, Takashi Sakamoto wrote:


Hi,

On Nov 02 2015 15:55, Julia Lawall wrote:

Move constant to the right of binary operators.

Generated by: scripts/coccinelle/misc/compare_const_fl.cocci

CC: Takashi Sakamoto 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

Depends on personal taste, but the modified version does look a little
nicer to me, since one can better see the relationship between the fdf
and sfc fields.

   amdtp-am824.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/firewire/amdtp-am824.c
+++ b/sound/firewire/amdtp-am824.c
@@ -36,7 +36,7 @@ int amdtp_am824_set_parameters(struct am
if (err < 0)
return err;

-   s->fdf = AMDTP_FDF_AM824 | s->sfc;
+   s->fdf = s->sfc | AMDTP_FDF_AM824;

/*
 * In IEC 61883-6, one data block represents one event. In ALSA, one


Could I request explainations about the advantage of this modification? I
cannot imagine good reasons for this subtle changes...


I put the reason under the --- (better see the relationship between fdf
and sfc).  But if you think the code makes more sense as it is, just
ignore the patch.


Mmm. I'm sorry but I'm not wiling to add 'Reviewed-by' tag to this patch 
because the reason is non-functional and personal.



Thanks

Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/sti: Remove select of CONFIG_FW_LOADER_USER_HELPER_FALLBACK

[Vincent ABRIOU]

Hi Takashi,

I made a rework to load the firmware at a different time, when file 
system is available.
I am now able to remove FW_LOADER_USER_HELPER_FALLBACK.
I will submit a new patch for this.

Vincent

On 10/29/2015 03:53 PM, Takashi Iwai wrote:
> On Thu, 29 Oct 2015 15:37:51 +0100,
> Emil Velikov wrote:
>>
>> On 29 October 2015 at 14:21, Vincent ABRIOU  wrote:
>>> Hi Takashi,
>>>
>>> Removing FW_LOADER_USER_HELPER_FALLBACK leads to a failure in our HQVDP
>>> firmware execution.
>>> Indeed, our firmware is not built-in. It is a proprietary firmware
>>> uploaded into the file system that's why we need the
>>> USER_HELPER_FALLBACK to be able to load it once file system is available.
>>>
>> Hmm most other DRM drivers also require firmware. Whist some allow the
>> firmware to be picked in initrd it's not a strict requirement.
>> So I'm wondering how come there hasn't been (m)any reports,
>> considering that neither one sets USER_HELPER_FALLBACK.
>>
>> Perhaps they also need it, or something in the sti module is done
>> differently ? Just some food for thought.
>
> It's the option each user decides to set or not, depending on the
> deployed system.  Most of PCs don't need them, and actually enabling
> this option causes troubles for them.  On other embedded systems, this
> might be still needed.  So, it's the system setup issue, and not the
> thing a driver needs to care.
>
> Imagine that your driver has "select EXT3_FS" because your system
> requires it; without that option, it won't boot, OMG!
> Is it the right thing?  Obviously no.  The same logic is applied to
> this case, too.
>
>
> Takashi
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: [PATCH v2 2/5] mfd: ts4800-syscon: add driver for TS-4800 syscon

[Lee Jones]

[Cc'ing Arnd]

On Fri, 30 Oct 2015, Damien Riegel wrote:
> On Fri, Oct 30, 2015 at 05:56:56PM +, Lee Jones wrote:
> > On Thu, 29 Oct 2015, Damien Riegel wrote:
> > 
> > > Driver for TS-4800 syscon. These registers belong to a FPGA that is
> > > memory mapped and are used for counters, enable various IPs in the FPGA,
> > > control LEDs, control IOs, etc.
> > > 
> > > Currently, only the watchdog is handled.
> > 
> > Why do you require your own syscon driver?
> > 
> > What's wrong with the generic one?
> > 
> 
> The generic one uses a regmap_config with reg_stride set to 4 and val_bits
> to 32.
> 
> TS-4800 syscon registers are 16-bit wide and must be accessed with 16
> bit read and writes:
> http://wiki.embeddedarm.com/wiki/TS-4800#Syscon
> 
> I will address the other issues in the next version (split commit,
> license issue, style, and superfluous remove).

The Syscon driver was written to be generic so that each
vendor/platform didn't require their own incarnation.  How unique is
the TS-4800?

Perhaps it might be better to supply a generic 16 bit Syscon for
devices akin to the TS-4800?

Arnd, any opinion on this?

> > > Signed-off-by: Damien Riegel 
> > > ---
> > >  .../devicetree/bindings/mfd/ts4800-syscon.txt  | 12 
> > 
> > Separate patch please.
> > 
> > >  drivers/mfd/Kconfig|  7 ++
> > >  drivers/mfd/Makefile   |  1 +
> > >  drivers/mfd/ts4800-syscon.c| 84 
> > > ++
> > >  include/linux/mfd/ts4800-syscon.h  | 24 +++
> > >  5 files changed, 128 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/mfd/ts4800-syscon.txt
> > >  create mode 100644 drivers/mfd/ts4800-syscon.c
> > >  create mode 100644 include/linux/mfd/ts4800-syscon.h
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/ts4800-syscon.txt 
> > > b/Documentation/devicetree/bindings/mfd/ts4800-syscon.txt
> > > new file mode 100644
> > > index 000..8dbc12c
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/ts4800-syscon.txt
> > > @@ -0,0 +1,12 @@
> > > +Technologic Systems Syscon
> > > +
> > > +Required properties:
> > > +- compatible : must be "ts,ts4800-syscon"
> > > +- reg : physical base address and length of memory mapped region
> > > +
> > > +Example:
> > > +
> > > +syscon@b001 {
> > > + compatible = "ts,ts4800-syscon";
> > > + reg = <0xb001 0x3d>;
> > > +};
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index 3f68dd2..8f03dce 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -1302,6 +1302,13 @@ config MFD_TC6393XB
> > >   help
> > > Support for Toshiba Mobile IO Controller TC6393XB
> > >  
> > > +config MFD_TS4800_SYSCON
> > > + tristate "TS-4800 Syscon Support"
> > > + select REGMAP
> > > + select REGMAP_MMIO
> > > + help
> > > +   Support for TS-4800's FPGA Syscon registers
> > > +
> > >  config MFD_VX855
> > >   tristate "VIA VX855/VX875 integrated south bridge"
> > >   depends on PCI
> > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > index ea40e07..e2c0f1b 100644
> > > --- a/drivers/mfd/Makefile
> > > +++ b/drivers/mfd/Makefile
> > > @@ -181,6 +181,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
> > >  obj-$(CONFIG_MFD_DLN2)   += dln2.o
> > >  obj-$(CONFIG_MFD_RT5033) += rt5033.o
> > >  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
> > > +obj-$(CONFIG_MFD_TS4800_SYSCON)  += ts4800-syscon.o
> > >  
> > >  intel-soc-pmic-objs  := intel_soc_pmic_core.o 
> > > intel_soc_pmic_crc.o
> > >  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> > > diff --git a/drivers/mfd/ts4800-syscon.c b/drivers/mfd/ts4800-syscon.c
> > > new file mode 100644
> > > index 000..1e42e96
> > > --- /dev/null
> > > +++ b/drivers/mfd/ts4800-syscon.c
> > > @@ -0,0 +1,84 @@
> > > +/*
> > > + * Device driver for TS-4800 FPGA's syscon
> > > + *
> > > + * Copyright (c) 2015 - Savoir-faire Linux
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > 
> > Why is the MFD v2+ and the Watchdog driver only v2?
> > 
> > > + * This program is distributed in the hope it will be useful, but WITHOUT
> > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
> > > for
> > > + * more details.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > 
> > Alphabetical.
> > 
> > > +
> > > +
> > 
> > Superfluous '\n'.
> > 
> > > +static const struct regmap_config ts4800_regmap_config = {
> > > + .reg_bits = 32,
> > > + .reg_stride = 2,
> > >

Re: [PATCH v2 1/5] of: add vendor prefix for Technologic Systems

[Lee Jones]

On Fri, 30 Oct 2015, Damien Riegel wrote:

> On Fri, Oct 30, 2015 at 06:04:00PM +, Lee Jones wrote:
> > On Thu, 29 Oct 2015, Damien Riegel wrote:
> > 
> > > Signed-off-by: Damien Riegel 
> > > ---
> > >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> > >  1 file changed, 1 insertion(+)
> > 
> > Acked-by: Lee Jones 
> 
> Arnd Bergmann suggested in the v1 thread [1] to change it to
> 'technologic' to avoid confusion. No problem with that ?
> 
> [1] http://www.spinics.net/lists/devicetree/msg100696.html

Sounds very reasonable.

For 'technologic':
  Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

[Zain]

Hi Mark

On 2015年10月30日 22:03, Mark Rutland wrote:
> On Fri, Oct 30, 2015 at 04:22:49PM +0800, Zain Wang wrote:
>> Add DT bindings documentation for the rk3288 crypto drivers.
>>
>> Signed-off-by: Zain Wang 
>> ---
>>  .../devicetree/bindings/crypto/rk-crypto.txt   | 31 
>> ++
>>  1 file changed, 31 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/rk-crypto.txt 
>> b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
>> new file mode 100644
>> index 000..1e50768
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
>> @@ -0,0 +1,31 @@
>> +Rockchip Electronics And Security Accelerator
>> +
>> +Required properties:
>> +- compatible: should be "rockchip,crypto"
> Choose a more specific name. Rockchip could easily come up with another
> crypto accelerator later.
ok! done.
rk3288_crypto may be better than crypto.
>> +- reg: base physical address of the engine and length of memory mapped
>> +   region.
>> +- interrupts: interrupt number
>> +- clocks: clock specifiers
>> +- clock-names: "aclk_crypto" used to clock data
>> +   "hclk_crypto" used to clock data
>> +   "srst_crypto" used to clock crypto accelerator
>> +   "apb_pclk"used to clock dma
>> +-status: Enable
> No need to mention the status property.
ok! done!
> Thanks,
> Mark.
>
>> +
>> +Examples:
>> +
>> +crypto: cypto-controller@ff8a {
>> +compatible = "rockchip,crypto";
>> +reg = <0xff8a 0x4000>;
>> +interrupts = ;
>> +clocks = <&cru ACLK_CRYPTO>,
>> + <&cru HCLK_CRYPTO>,
>> + <&cru SRST_CRYPTO>,
>> + <&cru ACLK_DMAC1>;
>> +
>> +clock-names = "aclk_crypto",
>> +  "hclk_crypto",
>> +  "srst_crypto",
>> +  "apb_pclk";
>> +status = "okay";
>> +};
>> -- 
>> 1.9.1
>>
>>
>
Thanks
Zain

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH powerpc/next 1/2] powerpc: Make value-returning atomics fully ordered

[Peter Zijlstra]

On Mon, Nov 02, 2015 at 09:30:31AM +0800, Boqun Feng wrote:
> According to memory-barriers.txt:
> 
> > Any atomic operation that modifies some state in memory and returns
> > information about the state (old or new) implies an SMP-conditional
> > general memory barrier (smp_mb()) on each side of the actual
> > operation ...
> 
> Which mean these operations should be fully ordered. However on PPC,
> PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
> which is currently "lwsync" if SMP=y. The leading "lwsync" can not
> guarantee fully ordered atomics, according to Paul Mckenney:
> 
> https://lkml.org/lkml/2015/10/14/970
> 
> To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
> the fully-ordered semantics.
> 
> This also makes futex atomics fully ordered, which can avoid possible
> memory ordering problems if userspace code relies on futex system call
> for fully ordered semantics.
> 
> Cc:  # 3.4+
> Signed-off-by: Boqun Feng 

Acked-by: Peter Zijlstra (Intel) 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH powerpc/next 2/2] powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

[Peter Zijlstra]

On Mon, Nov 02, 2015 at 09:30:32AM +0800, Boqun Feng wrote:
> According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_
> versions all need to be fully ordered, however they are now just
> RELEASE+ACQUIRE, which are not fully ordered.
> 
> So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
> __{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
> of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
> b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
> 
> This patch depends on patch "powerpc: Make value-returning atomics fully
> ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.
> 
> Cc:  # 3.4+
> Signed-off-by: Boqun Feng 

Acked-by: Peter Zijlstra (Intel) 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Documentation: update of USB_CHIPIDEA_DEBUG

[Valentin Rothberg]

Hi Peter,

your commit 2fb2884ed856 ("usb: chipidea: delete static debug support")
has shown up in today's Linux next tree (i.e., next-20151102) and
removes the Kconfig option USB_CHIPIDEA_DEBUG in favor of dynamic debug
support.  However, there are some documentary references on this option
still left in the code that may need to be updated:

Documentation/usb/chipidea.txt-9-If you want to check some internal variables 
for otg fsm,
Documentation/usb/chipidea.txt:10:select CONFIG_USB_CHIPIDEA_DEBUG, there are 2 
files which
 ^
Documentation/usb/chipidea.txt-11-can show otg fsm variables and some 
controller registers value:
--
drivers/usb/chipidea/core.c-25- * Compile Options
drivers/usb/chipidea/core.c:26: * - CONFIG_USB_CHIPIDEA_DEBUG: enable debug 
facilities
^
drivers/usb/chipidea/core.c-27- * - STALL_IN:  non-empty bulk-in pipes cannot 
be halted


I'm just pointing to those references, since I don't know if you want to
keep them in the code or not.  I found the issue and your commit with
scipts/checkkconfigsymbols.py.

Kind regards,
 Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Lee Jones]

On Fri, 30 Oct 2015, Andrew F. Davis wrote:

> On 10/30/2015 02:06 PM, Lee Jones wrote:
> >On Fri, 30 Oct 2015, Andrew F. Davis wrote:
> >
> >>On 10/30/2015 12:10 PM, Lee Jones wrote:
> >>>On Thu, 29 Oct 2015, Andrew F. Davis wrote:
> >>>
> The TPS65912 PMIC contains several regulators and a GPIO controller.
> Add bindings for the TPS65912 PMIC.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>   .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +++
> >>>
> >>>Why have you dropped Linus' Review-by?
> >>>
> >>
> >>Strange, I thought I made a change to this. Well this brings up a question,
> >>how much change can we have before we are supposed to drop 
> >>Reviewed/Acked-by?
> >
> >Common sense call I'm afraid. ;)
> >
> >[...]
> >
> + the second cell is used to specify flags.
> + See include/dt-bindings/gpio/gpio.h for possible values.
> >>>
> >>>This is a Linuxisum and shouldn't really live in here.
> >>>
> >>>I think it would be better to document them in ../gpio/gpio.txt and
> >>>reference that instead.
> >>>
> >>
> >>Looks like that is already in ../gpio/gpio.txt:57
> >
> >There is a mention of GPIO_ACTIVE_HIGH, as it's used in an example.
> >However GPIO_ACTIVE_LOW is missing.  I think both could do with
> >documenting properly, then you can refer to them from here.
> >
> 
> I mean the lines above the example, they say to use the macros
> defined in include/dt-bindings/gpio/gpio.h whenever possible,
> that's really all I would say.

Let's at least attempt to stick to the rules.

Please adapt your formatting to  in order to
eradicate any Linuxiness.

> >[...]
> >
> +Required properties:
> + - compatible : Should be "ti,tps65912".
> + - reg : Slave address or chip select number (I2C / SPI).
> + - interrupt-parent : The parent interrupt controller.
> + - interrupts : The interrupt line the device is connected to.
> + - interrupt-controller : Marks the device node as an interrupt 
> controller.
> + - #interrupt-cells: The number of cells to describe an IRQ, this should 
> be 2.
> + The first cell is the IRQ number.
> + The second cell is the flags, encoded as the trigger masks from
> + ../interrupt-controller/interrupts.txt
> >>>
> >>>Nit: We *normally* treat these as bullet-points and not place
> >>>full-stops on them:
> >>>
> >>>$ git grep "compatible" -- Documentation/devicetree/bindings/ | grep -v 
> >>>"\.$" | wc -l
> >>>5227
> >>>$ git grep "compatible.*\.$" -- Documentation/devicetree/bindings/ | wc -l
> >>>486
> >>>
> >>
> >>What about for multi-sentence descriptions, we need the middle full-stops, 
> >>then to not
> >>have one on the end seems kinda odd looking.
> >
> >That's the way I usually do it -- doesn't look too bad. ;)
> >
> >[...]
> >

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 05/20] ARC: rwlock: disable interrupts in !LLSC variant

[Peter Zijlstra]

On Sat, Oct 31, 2015 at 03:15:12PM +0200, Noam Camus wrote:
> From: Noam Camus 
> 
> If we hold rw->lock_mutex and interrupt occures we may
> end up spinning on it for ever during softirq.
> 
> Below you may see an example for interrupt we get while
> nl_table_lock is holding its rw->lock_mutex and we spinned
> on it for ever.
> 
> The concept for the fix was taken from SPARC.
> 
> [2015-05-12 19:16:12] Stack Trace:
> [2015-05-12 19:16:12]   arc_unwind_core+0xb8/0x11c
> [2015-05-12 19:16:12]   dump_stack+0x68/0xac
> [2015-05-12 19:16:12]   _raw_read_lock+0xa8/0xac
> [2015-05-12 19:16:12]   netlink_broadcast_filtered+0x56/0x35c
> [2015-05-12 19:16:12]   nlmsg_notify+0x42/0xa4
> [2015-05-12 19:16:13]   neigh_update+0x1fe/0x44c
> [2015-05-12 19:16:13]   neigh_event_ns+0x40/0xa4
> [2015-05-12 19:16:13]   arp_process+0x46e/0x5a8
> [2015-05-12 19:16:13]   __netif_receive_skb_core+0x358/0x500
> [2015-05-12 19:16:13]   process_backlog+0x92/0x154
> [2015-05-12 19:16:13]   net_rx_action+0xb8/0x188
> [2015-05-12 19:16:13]   __do_softirq+0xda/0x1d8
> [2015-05-12 19:16:14]   irq_exit+0x8a/0x8c
> [2015-05-12 19:16:14]   arch_do_IRQ+0x6c/0xa8
> [2015-05-12 19:16:14]   handle_interrupt_level1+0xe4/0xf0
> 
> Signed-off-by: Noam Camus 
> Cc: Peter Zijlstra 

It might make sense to note that this is a lock internal lock and since
the lock is free to be used from any context, the lock needs to be
IRQ-safe.

Acked-by: Peter Zijlstra (Intel) 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ALSA: firewire-lib: fix compare_const_fl.cocci warnings

[Julia Lawall]

On Mon, 2 Nov 2015, Takashi Sakamoto wrote:

> Hi Julia,
>
> On Nov 02 2015 16:20, Julia Lawall wrote:
> > On Mon, 2 Nov 2015, Takashi Sakamoto wrote:
> >
> > > Hi,
> > >
> > > On Nov 02 2015 15:55, Julia Lawall wrote:
> > > > Move constant to the right of binary operators.
> > > >
> > > > Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> > > >
> > > > CC: Takashi Sakamoto 
> > > > Signed-off-by: Fengguang Wu 
> > > > Signed-off-by: Julia Lawall 
> > > > ---
> > > >
> > > > Depends on personal taste, but the modified version does look a little
> > > > nicer to me, since one can better see the relationship between the fdf
> > > > and sfc fields.
> > > >
> > > >amdtp-am824.c |2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > --- a/sound/firewire/amdtp-am824.c
> > > > +++ b/sound/firewire/amdtp-am824.c
> > > > @@ -36,7 +36,7 @@ int amdtp_am824_set_parameters(struct am
> > > > if (err < 0)
> > > > return err;
> > > >
> > > > -   s->fdf = AMDTP_FDF_AM824 | s->sfc;
> > > > +   s->fdf = s->sfc | AMDTP_FDF_AM824;
> > > >
> > > > /*
> > > >  * In IEC 61883-6, one data block represents one event. In
> > > > ALSA, one
> > >
> > > Could I request explainations about the advantage of this modification? I
> > > cannot imagine good reasons for this subtle changes...
> >
> > I put the reason under the --- (better see the relationship between fdf
> > and sfc).  But if you think the code makes more sense as it is, just
> > ignore the patch.
>
> Mmm. I'm sorry but I'm not wiling to add 'Reviewed-by' tag to this patch
> because the reason is non-functional and personal.

OK, no problem.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [fs] df4c0e36f1: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

[Dmitry Vyukov]

Hi Ying,

Does testing happen with CONFIG_KASAN=y? If not, this is probably a
flake caused by something else.


On Mon, Nov 2, 2015 at 9:06 AM, kernel test robot
 wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd ("fs: dcache: manually 
> unpoison dname after allocation to shut up kasan's reports")
>
>
> The commit fixed a KASan bug, but introduced or revealed a soft lockup
> issue as follow.
>
>
> [  116.546697] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> [swapper/0:1]
> [  116.546697] irq event stamp: 3018750
> [  116.546697] hardirqs last  enabled at (3018749): [] 
> restore_args+0x0/0x30
> [  116.546697] hardirqs last disabled at (3018750): [] 
> apic_timer_interrupt+0x6d/0x80
> [  116.546697] softirqs last  enabled at (3018748): [] 
> __do_softirq+0x417/0x65b
> [  116.546697] softirqs last disabled at (3018743): [] 
> irq_exit+0x55/0xc3
> [  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 3.19.0-05249-gdf4c0e3 #1
> [  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [  116.546697] task: 88002f3f ti: 88002f3f8000 task.ti: 
> 88002f3f8000
> [  116.546697] RIP: 0010:[]  [] 
> __asan_load4+0x12/0x91
> [  116.546697] RSP: :88002f3fbdc8  EFLAGS: 0282
> [  116.546697] RAX: 7fff RBX:  RCX: 
> dc00
> [  116.546697] RDX: fbfff0763087 RSI: 83b18b10 RDI: 
> 83b1803c
> [  116.546697] RBP: 88002f3fbdf8 R08: 0001 R09: 
> fbfff0763074
> [  116.546697] R10: 83b183a7 R11: fbfff0763074 R12: 
> 880038d29003
> [  116.546697] R13: ed00071a5200 R14: 818cfadb R15: 
> 88002f3fbdf8
> [  116.546697] FS:  () GS:88002f60() 
> knlGS:
> [  116.546697] CS:  0010 DS:  ES:  CR0: 8005003b
> [  116.546697] CR2:  CR3: 02793000 CR4: 
> 06f0
> [  116.546697] Stack:
> [  116.546697]  83b18d5c 83b18b08 83b18878 
> 83b18b10
> [  116.546697]  83b18868  88002f3fbe48 
> 8223c4d3
> [  116.546697]   c4400d6283b18d40 0202 
> 0d98
> [  116.546697] Call Trace:
> [  116.546697]  [] insert_augmented+0x52/0xf5
> [  116.546697]  [] rbtree_test_init+0x151/0x205
> [  116.546697]  [] ? glob_init+0x11c/0x11c
> [  116.546697]  [] do_one_initcall+0x105/0x197
> [  116.546697]  [] kernel_init_freeable+0x193/0x22e
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697]  [] kernel_init+0xe/0xdf
> [  116.546697]  [] ret_from_fork+0x7c/0xb0
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697] Code: 38 00 74 13 48 8b 4d 08 ba 01 00 00 00 be 02 00 00 00 e8 
> e0 09 00 00 c9 c3 55 48 b8 ff ff ff ff ff 7f ff ff 48 89 e5 48 83 ec 30 <48> 
> 39 c7 77 23 48 8b 45 08 48 89 7d d8 48 8d 7d d8 48 c7 45 e8
> [  116.546697] Kernel panic - not syncing: softlockup: hung tasks
> [  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G L  
> 3.19.0-05249-gdf4c0e3 #1
> [  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [  116.546697]     
> 88002f603d48
> [  116.546697]  8223bcf7 fbfff074360b 8263d4e2 
> 88002f603dc8
> [  116.546697]  82234300 88002f603dc8 0008 
> 88002f603dd8
> [  116.546697] Call Trace:
> [  116.546697][] dump_stack+0x4c/0x65
> [  116.546697]  [] panic+0xed/0x231
> [  116.546697]  [] watchdog_timer_fn+0x1d2/0x1f8
> [  116.546697]  [] ? __touch_watchdog+0x1c/0x1c
> [  116.546697]  [] __run_hrtimer+0x283/0x6a2
> [  116.546697]  [] hrtimer_run_queues+0x126/0x145
> [  116.546697]  [] run_local_timers+0xe/0x1a
> [  116.546697]  [] update_process_times+0x27/0x54
> [  116.546697]  [] tick_nohz_handler+0x101/0x164
> [  116.546697]  [] local_apic_timer_interrupt+0x78/0x80
> [  116.546697]  [] smp_apic_timer_interrupt+0x57/0x69
> [  116.546697]  [] apic_timer_interrupt+0x72/0x80
> [  116.546697][] ? __asan_load4+0x12/0x91
> [  116.546697]  [] insert_augmented+0x52/0xf5
> [  116.546697]  [] rbtree_test_init+0x151/0x205
> [  116.546697]  [] ? glob_init+0x11c/0x11c
> [  116.546697]  [] do_one_initcall+0x105/0x197
> [  116.546697]  [] kernel_init_freeable+0x193/0x22e
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697]  [] kernel_init+0xe/0xdf
> [  116.546697]  [] ret_from_fork+0x7c/0xb0
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697] Kernel Offset: 0x0 from 0x8100 (relocation range: 
> 0x8000-0x9fff)
>
>
> Thanks,
> Ying Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kern

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

[Paolo Bonzini]

On 30/10/2015 07:16, Yunhong Jiang wrote:
> And with this change, we even don't need the module option anymore, we first 
> try the primary handler, which is in hard irq context, and if failed, then
> threaded irq handler. Am I right?

Yes.

> Paolo/Alex, do you want to work on the patch yourself? If not, I will be 
> happy to try this method.

Of course you can do it yourself.

Thanks!

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

[David Laight]

From: Bendik Rønning Opstad
> Sent: 29 October 2015 22:54
...
> > > > The semantics of the tp->nonagle bits are already a bit complex. My
> > > > sense is that having a setsockopt of TCP_RDB transparently modify the
> > > > nagle behavior is going to add more extra complexity and unanticipated
> > > > behavior than is warranted given the slight possible gain in
> > > > convenience to the app writer. What about a model where the
> > > > application user just needs to remember to call
> > > > setsockopt(TCP_NODELAY) if they want the TCP_RDB behavior to be
> > > > sensible? I see your nice tests at
> > > >
> > > >   https://github.com/bendikro/packetdrill/commit/9916b6c53e33dd04329d29b
> > > >   7d8baf703b2c2ac1b> >
> > > > are already doing that. And my sense is that likewise most
> > > > well-engineered "thin stream" apps will already be using
> > > > setsockopt(TCP_NODELAY). Is that workable?
> 
> This is definitely workable. I agree that it may not be an ideal solution to
> have TCP_RDB disable Nagle, however, it would be useful with a way to easily
> enable RDB and disable Nagle.

If enabling RDB disables Nagle, then what happens when you turn RDB back off?

David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Olof Johansson]

Hi,

1) This seems to have broken BBB in -next for me, bisected down to this patch.

For bootlog:
http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html

2) Please avoid merging DT/platform code in your driver tree, Vinod,
at least without an ack from the platform maintainer. It can be a a
huge mess if they end up causing conflicts, so we always ask to merge
the DT changes through the platform maintainer (Tony in this case) by
default.


Thanks,

-Olof

On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi  wrote:
> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
> enable the DMA even crossbar with ti,am335x-edma-crossbar.
> With the new bindings boards can customize and tweak the DMA channel
> priority to match their needs. With the new binding the memcpy is safe
> to be used since with the old binding it was not possible for a driver
> to know which channel is allowed to be used as non HW triggered channel.
>
> Signed-off-by: Peter Ujfalusi 
> ---
>  arch/arm/boot/dts/am335x-evm.dts|  9 +---
>  arch/arm/boot/dts/am335x-pepper.dts | 11 +
>  arch/arm/boot/dts/am33xx.dtsi   | 96 
> ++---
>  3 files changed, 73 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
> b/arch/arm/boot/dts/am335x-evm.dts
> index 1942a5c8132d..507980672c32 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -743,8 +743,8 @@
>  &mmc3 {
> /* these are on the crossbar and are outlined in the
>xbar-event-map element */
> -   dmas = <&edma 12
> -   &edma 13>;
> +   dmas = <&edma_xbar 12 0 1
> +   &edma_xbar 13 0 2>;
> dma-names = "tx", "rx";
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> @@ -766,11 +766,6 @@
> };
>  };
>
> -&edma {
> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
> -   2 13>;
> -};
> -
>  &sham {
> status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
> b/arch/arm/boot/dts/am335x-pepper.dts
> index 7106114c7464..39073b921664 100644
> --- a/arch/arm/boot/dts/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/am335x-pepper.dts
> @@ -339,13 +339,6 @@
> ti,non-removable;
>  };
>
> -&edma {
> -   /* Map eDMA MMC2 Events from Crossbar */
> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
> -2 13>;
> -};
> -
> -
>  &mmc3 {
> /* Wifi & Bluetooth on MMC #3 */
> status = "okay";
> @@ -354,8 +347,8 @@
> vmmmc-supply = <&v3v3c_reg>;
> bus-width = <4>;
> ti,non-removable;
> -   dmas = <&edma 12
> -   &edma 13>;
> +   dmas = <&edma_xbar 12 0 1
> +   &edma_xbar 13 0 2>;
> dma-names = "tx", "rx";
>  };
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index d23e2524d694..6053e75c6e99 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -174,12 +174,54 @@
> };
>
> edma: edma@4900 {
> -   compatible = "ti,edma3";
> -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> -   reg =   <0x4900 0x1>,
> -   <0x44e10f90 0x40>;
> +   compatible = "ti,edma3-tpcc";
> +   ti,hwmods = "tpcc";
> +   reg =   <0x4900 0x1>;
> +   reg-names = "edma3_cc";
> interrupts = <12 13 14>;
> -   #dma-cells = <1>;
> +   interrupt-names = "edma3_ccint", "emda3_mperr",
> + "edma3_ccerrint";
> +   dma-requests = <64>;
> +   #dma-cells = <2>;
> +
> +   ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> +  <&edma_tptc2 0>;
> +
> +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> +   };
> +
> +   edma_tptc0: tptc@4980 {
> +   compatible = "ti,edma3-tptc";
> +  

Re: [PATCH v1 16/20] ARC: [plat-eznps] Use dedicated cpu_relax()

[Peter Zijlstra]

On Sat, Oct 31, 2015 at 03:15:23PM +0200, Noam Camus wrote:
> From: Tal Zilcer 
> 
> Since the CTOP is SMT hardware multi-threaded, we need to hint
> the HW that now will be a very good time to do a hardware
> thread context switching. This is done by issuing the schd.rw
> instruction (binary coded here so as to not require specific
> revision of GCC to build the kernel).
> sched.rw means that Thread becomes eligible for execution by
> the threads scheduler after all pending read/write
> transactions were completed.
> 
> Signed-off-by: Noam Camus 
> Cc: Peter Zijlstra 
> ---
>  arch/arc/include/asm/processor.h |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arc/include/asm/processor.h 
> b/arch/arc/include/asm/processor.h
> index 7266ede..f1a51a6 100644
> --- a/arch/arc/include/asm/processor.h
> +++ b/arch/arc/include/asm/processor.h
> @@ -58,7 +58,12 @@ struct task_struct;
>   * get optimised away by gcc
>   */
>  #ifdef CONFIG_SMP
> +#ifdef CONFIG_EZNPS_MTM_EXT
> +#define cpu_relax() \
> + __asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory")
> +#else
>  #define cpu_relax()  __asm__ __volatile__ ("" : : : "memory")
> +#endif
>  #else
>  #define cpu_relax()  do { } while (0)
>  #endif

At which point you might want to revisit:

arch/arc/include/asm/processor.h:#define cpu_relax_lowlatency() cpu_relax()

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] ASoC: wm9713: use snd_soc_*() calls to update ac97 registers

[Charles Keepax]

On Sun, Nov 01, 2015 at 08:23:40PM +0100, Robert Jarzmik wrote:
> Convert wm9713 to use the more modern registers manipulation functions,
> such as snd_soc_read(), snd_soc_write() and snd_soc_update_bits().
> 
> Signed-off-by: Robert Jarzmik 
> ---

Reviewed-by: Charles Keepax 

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] wireless:b43: remove last reference on B43_PCMCIA

[Valentin Rothberg]

Remove last reference on Kconfig option B43_PCMCIA, which has been
removed by commit 399500da18f7 ("ssb: pick PCMCIA host code support from
b43 driver").

Signed-off-by: Valentin Rothberg 
---
 drivers/net/wireless/b43/main.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index ec013fbd6a81..190efd3160b7 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -5826,9 +5826,6 @@ static void b43_print_driverinfo(void)
 #ifdef CONFIG_B43_PCI_AUTOSELECT
feat_pci = "P";
 #endif
-#ifdef CONFIG_B43_PCMCIA
-   feat_pcmcia = "M";
-#endif
 #ifdef CONFIG_B43_PHY_N
feat_nphy = "N";
 #endif
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 19/20] ARC: [plat-eznps] replace sync with proper cpu barrier

[Peter Zijlstra]

On Mon, Nov 02, 2015 at 07:48:54AM +, Vineet Gupta wrote:
> Since u bring this up - I think we don't need the original SYNC and/or
> SMT thread schedule at all.  The SYNC here is a historic relic at best
> and we can get rid of it per reasoning below:
> 
> In UP context it is obviously useless, why would we want to stall the
> core for all updates to stack memory of t0 to complete before loading
> kernel ode callee registers from t1 stack's memory.
> 
> In SMP, we could have a potential race in which outdoing task could be
> concurrently picked for running, thus the writes to stack here need to
> be visible before the reads from stack on other core. But I think
> since this is the same rq, there would be a taken spinlock and once a
> core gives it up, an smp barrier would come naturally.
> 
> Peter do u concur ?

I'm still somewhat jet-lagged, but I think the below reference should
answer your question:

lkml.kernel.org/r/20150917130125.gl3...@twins.programming.kicks-ass.net

I (still) need to update that patch and send it out again.

But I think it answers your question; we do not rely on arch code to
provide barriers for the generic code.

Now, if for some reason the arch code has further constraints, then
maybe, but I don't think so.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] usblp: do not set TASK_INTERRUPTIBLE before lock

[Jiri Slaby]

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: GW   
4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 81a4edce 880236ec7ba8 81716651 
 880236ec7bf8 880236ec7be8 8106e146 0282
 81a50119 028b  8802dab7c508
Call Trace:
...
 [] warn_slowpath_fmt+0x46/0x50
 [] __might_sleep+0x7d/0x90
 [] mutex_lock_interruptible_nested+0x2f/0x4b0
 [] usblp_wwait+0xcc/0x310 [usblp]
 [] usblp_write+0x72/0x350 [usblp]
 [] __vfs_write+0x28/0xf0
...

Commit 7f477358e2384c54b190cc3b6ce28277050a041b (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.

Signed-off-by: Jiri Slaby 
Cc: Pete Zaitcev 
Cc: Greg Kroah-Hartman 
Fixes: 7f477358e2 ("usblp: Implement the ENOSPC convention")
---
 drivers/usb/class/usblp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 433bbc34a8a4..071964c7847f 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -884,11 +884,11 @@ static int usblp_wwait(struct usblp *usblp, int nonblock)
 
add_wait_queue(&usblp->wwait, &waita);
for (;;) {
-   set_current_state(TASK_INTERRUPTIBLE);
if (mutex_lock_interruptible(&usblp->mut)) {
rc = -EINTR;
break;
}
+   set_current_state(TASK_INTERRUPTIBLE);
rc = usblp_wtest(usblp, nonblock);
mutex_unlock(&usblp->mut);
if (rc <= 0)
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 000/123] 3.12.50-stable review

[Jiri Slaby]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/29/2015, 01:34 AM, Guenter Roeck wrote:
> On Wed, Oct 28, 2015 at 02:51:22PM +0100, Jiri Slaby wrote:
>> This is the start of the stable review cycle for the 3.12.50
>> release. There are 123 patches in this series, all will be posted
>> as a response to this one.  If anyone has any issues with these
>> being applied, please let me know.
>> 
>> Responses should be made by Fri Oct 30 09:39:16 CET 2015. 
>> Anything received after that time might be too late.
>> 
> Build results: total: 123 pass: 123 fail: 0 Qemu test results: 
> total: 77 pass: 77 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks for testing!


- -- 
js
suse labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWNyskAAoJEL0lsQQGtHBJb/gQAIo9lwawa1sPN8ooYxfaonXR
uUJlJsub0rsZfCjGVJZ6Jqw4mFIdIyGFWXNXVPNe69mUtPnf9EMuC5s5OEr8S5TF
nc4SrCnzMYkjE1OGFkowFApX7y3EyiO0HDex+ut2r98QG22JN/31lZVaMyly07Un
jOdPA3Wsl2RdA0vXetS6HeAX/ixZdH5CKQUBOScogePjIbWhbSqjO1dJCBXQUrxM
SaZc0VsVauXLMLVaM1K7IAhLfo6wLXHUyuCaRFDiXFBBPH3GVXfPkZdhkmEnhbMj
cCO4Ru+yVicq68FwDtwaDxO6VumJGy7QKUnJVoV5qH3GYge1hFgUB7sTLcyTUPED
FmJzPbjqiNZTSQlbwmWnCdUZuye/MX+4Paju8+mZVTYKPfdCxfW/VwaCNSwhq/cA
jyVNkBOTC5TAui7pBwRwRSHdUO7Lpu12u8iNdEpFnlirV+dFbf5V+E2p7qFdNlb3
0zj9VccH9WWaxF9qTMCOcl7MbDOefDUlVBB0ZAut5IYGY6otbNhLTYiQ9vV0FWFT
yOw8pZtlbAv2L1evgXLf7pfbc9EG9+6FLP5hYlRej+AGNvJhyPfStzupc0LTg7dI
UzvamtBVL7/Xz05AzjeEJrH4PoKqSVR7Qbc7OxKkYJLFFGF0/UOb1PzM0mtAhB+s
+f+LF8Gq9bUNQO9pphNm
=SAYR
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] wireless:b43: remove last reference on B43_PCMCIA

[Rafał Miłecki]

On 2 November 2015 at 10:24, Valentin Rothberg
 wrote:
> Remove last reference on Kconfig option B43_PCMCIA, which has been
> removed by commit 399500da18f7 ("ssb: pick PCMCIA host code support from
> b43 driver").
>
> Signed-off-by: Valentin Rothberg 
> ---
>  drivers/net/wireless/b43/main.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index ec013fbd6a81..190efd3160b7 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -5826,9 +5826,6 @@ static void b43_print_driverinfo(void)
>  #ifdef CONFIG_B43_PCI_AUTOSELECT
> feat_pci = "P";
>  #endif
> -#ifdef CONFIG_B43_PCMCIA
> -   feat_pcmcia = "M";
> -#endif
>  #ifdef CONFIG_B43_PHY_N
> feat_nphy = "N";
>  #endif

There is no point of leaving feat_pcmcia variable.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/2] ASoC: wm9713: convert to regmap

[Charles Keepax]

On Sun, Nov 01, 2015 at 08:23:39PM +0100, Robert Jarzmik wrote:
> Convert the Wolfson WM9713 to regmap API. This will leverage all the
> regmap functions (debug, registers update, etc ...).
> 
> As a bonus, this will pave the path to gpio chip introduction, and
> devicetree support. This was tested on the mioa701 board, pxa27x based,
> in PCM playback, and through suspend/resume.
> 
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: fix suspend/resume (that specific part is not tested yet)
> Since v2: split out the snd_soc_*() from regmap support
> Since v3: remove suspend/resume regmap cache operations, rely on
>   regmap volatile registers
> ---

Reviewed-by: Charles Keepax 

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

[Paolo Bonzini]

On 31/10/2015 20:50, Laszlo Ersek wrote:
> Tested-by: Laszlo Ersek 

Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)).

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] MMC for v.4.4

[Ulf Hansson]

Hi Linus,

Here are the PR for MMC for v4.4.

Details about the highlights are as usual found in the signed tag.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 32b88194f71d6ae7768a29f87fbba454728273ee:

  Linux 4.3-rc7 (2015-10-25 10:39:47 +0900)

are available in the git repository at:

  git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.4

for you to fetch changes up to 7cc8d580228cc712edcf7a1856a3bdb38c164e83:

  mmc: dw_mmc: fix the wrong setting for UHS-DDR50 mode (2015-10-29
11:00:43 +0100)


MMC core:
 - Add new API to set VCCQ voltage - mmc_regulator_set_vqmmc()
 - Add new ioctl to allow userspace to send multi commands
 - Wait for card busy signalling before starting SDIO requests
 - Remove MMC_CLKGATE
 - Enable tuning for DDR50 mode
 - Some code clean-up/improvements to mmc pwrseq
 - Use highest priority for eMMC restart handler
 - Add DT bindings for eMMC hardware reset support
 - Extend the mmc_send_tuning() API
 - Improve ios show for debugfs
 - A couple of code optimizations

MMC host:
 - Some generic OF improvements
 - Various code clean-ups
 - sirf: Add support for DDR50
 - sunxi: Add support for card busy detection
 - mediatek: Use MMC_CAP_RUNTIME_RESUME
 - mediatek: Add support for eMMC HW-reset
 - mediatek: Add support for HS400
 - dw_mmc: Convert to use the new mmc_regulator_set_vqmmc() API
 - dw_mmc: Add external DMA interface support
 - dw_mmc: Some various improvements
 - dw_mmc-rockchip: MMC tuning with the clock phase framework
 - sdhci: Properly clear IRQs during resume
 - sdhci: Enable tuning for DDR50 mode
 - sdhci-of-esdhc: Use IRQ mode for card detection
 - sdhci-of-esdhc: Support both BE and LE host controller
 - sdhci-pci: Build o2micro support in the same module
 - sdhci-pci: Support for new Intel host controllers
 - sdhci-acpi: Support for new Intel host controllers


Adrian Hunter (3):
  mmc: sdhci-pci: Add another PCI ID for an Intel eMMC host controller
  mmc: sdhci-pci: Add more PCI IDs for Intel controllers
  mmc: sdhci-acpi: Add more ACPI HIDs for Intel controllers

Alexandru M Stan (3):
  mmc: dw_mmc-rockchip: dt-binding: Add tuning related things
  mmc: dw_mmc-rockchip: MMC tuning with the clock phase framework
  ARM: dts: rockchip: Add drive/sample clocks for rk3288 dw_mmc devices

Ben Hutchings (2):
  mmc: sdhci-pci: Build o2micro support in the same module
  mmc: sdhci-pci: Make sdhci_pci_o2_fujin2_pci_init() static

Chaotian Jing (9):
  mmc: mediatek: Add MMC_CAP_RUNTIME_RESUME support
  mmc: core: Add DT bindings for eMMC hardware reset support
  mmc: dt-bindings: update Mediatek MMC bindings
  mmc: mediatek: make cmd_ints_mask to const
  mmc: mediatek: change the argument "ddr" to "timing"
  mmc: mediatek: fix got GPD checksum error interrupt when data transfer
  mmc: mediatek: add implement of ops->hw_reset()
  mmc: mmc: extend the mmc_send_tuning()
  mmc: mediatek: add HS400 support

Dan Carpenter (2):
  mmc: sdhci-of-at91: remove a line of dead code
  mmc: dw_mmc: NULL dereference in error message

Douglas Anderson (4):
  clk: rockchip: Allow more precision for some mmc clock phases
  clk: rockchip: Make calculations use rounding
  mmc: core: Add mmc_regulator_set_vqmmc()
  mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch

Grant Grundler (1):
  mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD

Haibo Chen (1):
  mmc: sdhci: call sdhci_init() before request irq

Hans de Goede (3):
  mmc: Add mmc_is_io_op helper function
  mmc: Wait for card_busy before starting sdio requests
  mmc: sunxi: Add card busy detection

Heiko Stuebner (2):
  mmc: core: move ocr-bit to voltage translation into separate function
  ARM: dts: rockchip: add tuning related settings to veyron devices

Jaehoon Chung (2):
  mmc: dw_mmc: fix the CardThreshold boundary at CardThrCtl register
  mmc: dw_mmc: fix the wrong setting for UHS-DDR50 mode

Javier Martinez Canillas (7):
  mmc: wbsd: Remove unneded semicolon
  mmc: vub300: Remove unneded semicolons
  mmc: pwrseq: use gpiod_get() instead of index 0
  mmc: sdhci-bcm-kona: fix logic to check for 8-bit data width
  mmc: mmc_spi: Export OF module alias information
  mmc: pwrseq_simple: use GPIO descriptors array API
  mmc: pwrseq: Use highest priority for eMMC restart handler

Jon Hunter (1):
  mmc: block: Add new ioctl to send multi commands

Lokesh Vutla (1):
  mmc: omap_hsmmc: Enable omap_hsmmc for Keystone 2

Luis de Bethencourt (3):
  mmc: moxart: Fix module autoload for OF platform driver
  mmc: omap: Fix module autoload for OF platform driver
  mmc: android-goldfish: Allow compiling the driver with COMPILE_TEST

Michele Curti (1):
  mmc: sdhci-acpi: dete

RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

[David Laight]

From: Bendik Rønning Opstad
> Sent: 23 October 2015 21:50
> RDB is a mechanism that enables a TCP sender to bundle redundant
> (already sent) data with TCP packets containing new data. By bundling
> (retransmitting) already sent data with each TCP packet containing new
> data, the connection will be more resistant to sporadic packet loss
> which reduces the application layer latency significantly in congested
> scenarios.

What sort of traffic flows do you expect this to help?

An ssh (or similar) connection will get additional data to send,
but that sort of data flow needs Nagle in order to reduce the
number of packets sent.
OTOH it might benefit from including unacked data if the Nagle
timer expires.
Being able to set the Nagle timer on a per-connection basis
(or maybe using something based on the RTT instead of 2 secs)
might make packet loss less problematic.

Data flows that already have Nagle disabled (probably anything that
isn't command-response and isn't unidirectional bulk data) are
likely to generate a lot of packets within the RTT.
Resending unacked data will just eat into available network bandwidth
and could easily make any congestion worse.

I think that means you shouldn't resend data more than once, and/or
should make sure that the resent data isn't a significant overhead
on the packet being sent.

David

Re: [PATCH] wireless:b43: remove last reference on B43_PCMCIA

[Valentin Rothberg]

On Nov 02 '15 10:31, Rafał Miłecki wrote:
> On 2 November 2015 at 10:24, Valentin Rothberg
>  wrote:
> > Remove last reference on Kconfig option B43_PCMCIA, which has been
> > removed by commit 399500da18f7 ("ssb: pick PCMCIA host code support from
> > b43 driver").
> >
> > Signed-off-by: Valentin Rothberg 
> > ---
> >  drivers/net/wireless/b43/main.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/b43/main.c 
> > b/drivers/net/wireless/b43/main.c
> > index ec013fbd6a81..190efd3160b7 100644
> > --- a/drivers/net/wireless/b43/main.c
> > +++ b/drivers/net/wireless/b43/main.c
> > @@ -5826,9 +5826,6 @@ static void b43_print_driverinfo(void)
> >  #ifdef CONFIG_B43_PCI_AUTOSELECT
> > feat_pci = "P";
> >  #endif
> > -#ifdef CONFIG_B43_PCMCIA
> > -   feat_pcmcia = "M";
> > -#endif
> >  #ifdef CONFIG_B43_PHY_N
> > feat_nphy = "N";
> >  #endif
> 
> There is no point of leaving feat_pcmcia variable.

Sorry, I will fix and resend the patch.

Thanks,
 Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 05/20] ARC: rwlock: disable interrupts in !LLSC variant

[Vineet Gupta]

On Saturday 31 October 2015 06:45 PM, Noam Camus wrote:
> From: Noam Camus 
> 
> If we hold rw->lock_mutex and interrupt occures we may
> end up spinning on it for ever during softirq.
> 
> Below you may see an example for interrupt we get while
> nl_table_lock is holding its rw->lock_mutex and we spinned
> on it for ever.
> 
> The concept for the fix was taken from SPARC.
> 
> [2015-05-12 19:16:12] Stack Trace:
> [2015-05-12 19:16:12]   arc_unwind_core+0xb8/0x11c
> [2015-05-12 19:16:12]   dump_stack+0x68/0xac
> [2015-05-12 19:16:12]   _raw_read_lock+0xa8/0xac
> [2015-05-12 19:16:12]   netlink_broadcast_filtered+0x56/0x35c
> [2015-05-12 19:16:12]   nlmsg_notify+0x42/0xa4
> [2015-05-12 19:16:13]   neigh_update+0x1fe/0x44c
> [2015-05-12 19:16:13]   neigh_event_ns+0x40/0xa4
> [2015-05-12 19:16:13]   arp_process+0x46e/0x5a8
> [2015-05-12 19:16:13]   __netif_receive_skb_core+0x358/0x500
> [2015-05-12 19:16:13]   process_backlog+0x92/0x154
> [2015-05-12 19:16:13]   net_rx_action+0xb8/0x188
> [2015-05-12 19:16:13]   __do_softirq+0xda/0x1d8
> [2015-05-12 19:16:14]   irq_exit+0x8a/0x8c
> [2015-05-12 19:16:14]   arch_do_IRQ+0x6c/0xa8
> [2015-05-12 19:16:14]   handle_interrupt_level1+0xe4/0xf0
> 
> Signed-off-by: Noam Camus 
> Cc: Peter Zijlstra 
> ---
>  arch/arc/include/asm/spinlock.h |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arc/include/asm/spinlock.h b/arch/arc/include/asm/spinlock.h
> index db8c59d..800e7c4 100644
> --- a/arch/arc/include/asm/spinlock.h
> +++ b/arch/arc/include/asm/spinlock.h
> @@ -610,7 +610,9 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
>  static inline int arch_read_trylock(arch_rwlock_t *rw)
>  {
>   int ret = 0;
> + unsigned long flags;
>  
> + local_irq_save(flags);
>   arch_spin_lock(&(rw->lock_mutex));
>  
>   /*
> @@ -623,6 +625,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
>   }
>  
>   arch_spin_unlock(&(rw->lock_mutex));
> + local_irq_restore(flags);
>  
>   smp_mb();
>   return ret;
> @@ -632,7 +635,9 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
>  static inline int arch_write_trylock(arch_rwlock_t *rw)
>  {
>   int ret = 0;
> + unsigned long flags;
>  
> + local_irq_save(flags);
>   arch_spin_lock(&(rw->lock_mutex));
>  
>   /*
> @@ -646,6 +651,7 @@ static inline int arch_write_trylock(arch_rwlock_t *rw)
>   ret = 1;
>   }
>   arch_spin_unlock(&(rw->lock_mutex));
> + local_irq_restore(flags);
>  
>   return ret;
>  }
> @@ -664,16 +670,24 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>  
>  static inline void arch_read_unlock(arch_rwlock_t *rw)
>  {
> + unsigned long flags;
> +
> + local_irq_save(flags);
>   arch_spin_lock(&(rw->lock_mutex));


Isn't raw_spin_lock_irqsave() equivalent and more concise ?


>   rw->counter++;
>   arch_spin_unlock(&(rw->lock_mutex));
> + local_irq_restore(flags);
>  }
>  
>  static inline void arch_write_unlock(arch_rwlock_t *rw)
>  {
> + unsigned long flags;
> +
> + local_irq_save(flags);
>   arch_spin_lock(&(rw->lock_mutex));
>   rw->counter = __ARCH_RW_LOCK_UNLOCKED__;
>   arch_spin_unlock(&(rw->lock_mutex));
> + local_irq_restore(flags);
>  }
>  
>  #endif
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] devicetree: add Sigma Designs vendor prefix

[Mason]

On 02/10/2015 19:21, Mans Rullgard wrote:

> Add the "sigma" vendor prefix for Sigma Designs, Inc.
> 
> Signed-off-by: Mans Rullgard 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..ea77ee5 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -192,6 +192,7 @@ schindler Schindler
>  seagate  Seagate Technology PLC
>  semtech  Semtech Corporation
>  sharpSharp Corporation
> +sigmaSigma Designs, Inc.
>  sil  Silicon Image
>  silabs   Silicon Laboratories
>  siliconmitus Silicon Mitus, Inc.

Hello,

How can I determine whether this patch has been applied?

(I examined a few branches in Rob's tree.)

Regards.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [fs] df4c0e36f1: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

[Andrey Ryabinin]

2015-11-02 11:06 GMT+03:00 kernel test robot :
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd ("fs: dcache: manually 
> unpoison dname after allocation to shut up kasan's reports")
>
>
> The commit fixed a KASan bug, but introduced or revealed a soft lockup
> issue as follow.
>

I think that this issue is caused by several factors.
 1. Non-preempt kernel + heavy debug options (CONFIG_PREEMPT=n
CONFIG_GCOV_PROFILE_ALL=y CONFIG_KASAN=y)
 2. I suspect that your host is overloaded, thus KVM guest runs too slow.

And the major factor here is number 2.

In your dmesg:
[   67.891156] rbtree testing -> 570841 cycles
[   88.609636] augmented rbtree testing
[  116.546697] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[swapper/0:1]


I've tried to reproduce this, and got this:
[0.693574] rbtree testing -> 15513 cycles
570841/15513 = 36x times faster.

[1.159450] augmented rbtree testing -> 23675 cycles
[1.864996]
It took less than a second, meanwhile in your case it didn't finish in
22 seconds.

This makes me think that your host is overloaded and the problem is on
your side.

>
> [  116.546697] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
> [swapper/0:1]
> [  116.546697] irq event stamp: 3018750
> [  116.546697] hardirqs last  enabled at (3018749): [] 
> restore_args+0x0/0x30
> [  116.546697] hardirqs last disabled at (3018750): [] 
> apic_timer_interrupt+0x6d/0x80
> [  116.546697] softirqs last  enabled at (3018748): [] 
> __do_softirq+0x417/0x65b
> [  116.546697] softirqs last disabled at (3018743): [] 
> irq_exit+0x55/0xc3
> [  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 3.19.0-05249-gdf4c0e3 #1
> [  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [  116.546697] task: 88002f3f ti: 88002f3f8000 task.ti: 
> 88002f3f8000
> [  116.546697] RIP: 0010:[]  [] 
> __asan_load4+0x12/0x91
> [  116.546697] RSP: :88002f3fbdc8  EFLAGS: 0282
> [  116.546697] RAX: 7fff RBX:  RCX: 
> dc00
> [  116.546697] RDX: fbfff0763087 RSI: 83b18b10 RDI: 
> 83b1803c
> [  116.546697] RBP: 88002f3fbdf8 R08: 0001 R09: 
> fbfff0763074
> [  116.546697] R10: 83b183a7 R11: fbfff0763074 R12: 
> 880038d29003
> [  116.546697] R13: ed00071a5200 R14: 818cfadb R15: 
> 88002f3fbdf8
> [  116.546697] FS:  () GS:88002f60() 
> knlGS:
> [  116.546697] CS:  0010 DS:  ES:  CR0: 8005003b
> [  116.546697] CR2:  CR3: 02793000 CR4: 
> 06f0
> [  116.546697] Stack:
> [  116.546697]  83b18d5c 83b18b08 83b18878 
> 83b18b10
> [  116.546697]  83b18868  88002f3fbe48 
> 8223c4d3
> [  116.546697]   c4400d6283b18d40 0202 
> 0d98
> [  116.546697] Call Trace:
> [  116.546697]  [] insert_augmented+0x52/0xf5
> [  116.546697]  [] rbtree_test_init+0x151/0x205
> [  116.546697]  [] ? glob_init+0x11c/0x11c
> [  116.546697]  [] do_one_initcall+0x105/0x197
> [  116.546697]  [] kernel_init_freeable+0x193/0x22e
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697]  [] kernel_init+0xe/0xdf
> [  116.546697]  [] ret_from_fork+0x7c/0xb0
> [  116.546697]  [] ? rest_init+0x14d/0x14d
> [  116.546697] Code: 38 00 74 13 48 8b 4d 08 ba 01 00 00 00 be 02 00 00 00 e8 
> e0 09 00 00 c9 c3 55 48 b8 ff ff ff ff ff 7f ff ff 48 89 e5 48 83 ec 30 <48> 
> 39 c7 77 23 48 8b 45 08 48 89 7d d8 48 8d 7d d8 48 c7 45 e8
> [  116.546697] Kernel panic - not syncing: softlockup: hung tasks
> [  116.546697] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G L  
> 3.19.0-05249-gdf4c0e3 #1
> [  116.546697] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [  116.546697]     
> 88002f603d48
> [  116.546697]  8223bcf7 fbfff074360b 8263d4e2 
> 88002f603dc8
> [  116.546697]  82234300 88002f603dc8 0008 
> 88002f603dd8
> [  116.546697] Call Trace:
> [  116.546697][] dump_stack+0x4c/0x65
> [  116.546697]  [] panic+0xed/0x231
> [  116.546697]  [] watchdog_timer_fn+0x1d2/0x1f8
> [  116.546697]  [] ? __touch_watchdog+0x1c/0x1c
> [  116.546697]  [] __run_hrtimer+0x283/0x6a2
> [  116.546697]  [] hrtimer_run_queues+0x126/0x145
> [  116.546697]  [] run_local_timers+0xe/0x1a
> [  116.546697]  [] update_process_times+0x27/0x54
> [  116.546697]  [] tick_nohz_handler+0x101/0x164
> [  116.546697]  [] local_apic_timer_interrupt+0x78/0x80
> [  116.546697]  [] smp_apic_timer_interrupt+0x57/0x69
> [  116.546697]  [] apic_timer_interrupt+0x72/0x80
> [  116.546697][] ? __asan_load4+0x12/0x91
> [  116.546697]  [] insert_augmented+0

[PATCH v2] regulator: of: removing two variables min_uV and max_uV

[Saurabh Sengar]

replacing the of_get_property function with of_property_read_u32 function
as its help removing two variables.

Signed-off-by: Saurabh Sengar 
---
Hi Mark,

>>   /* Only one voltage?  Then make sure it's set. */
>> - if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
>> + if (constraints->min_uV == constraints->max_uV)
>>   constraints->apply_uV = true;
> Your new code is not equivalent to the existing code.  The new code will
> set apply_uV even if the DT properties are not present which will in
> turn mean that we will end up attempting to apply a setting of 0V if
> that happens which is not desirable.

I have put these check back, please let me know if this v2 patch is worth

 drivers/regulator/of_regulator.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 499e437..3710206 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -28,7 +28,6 @@ static void of_get_regulation_constraints(struct device_node 
*np,
struct regulator_init_data **init_data,
const struct regulator_desc *desc)
 {
-   const __be32 *min_uV, *max_uV;
struct regulation_constraints *constraints = &(*init_data)->constraints;
struct regulator_state *suspend_state;
struct device_node *suspend_np;
@@ -37,18 +36,17 @@ static void of_get_regulation_constraints(struct 
device_node *np,
 
constraints->name = of_get_property(np, "regulator-name", NULL);
 
-   min_uV = of_get_property(np, "regulator-min-microvolt", NULL);
-   if (min_uV)
-   constraints->min_uV = be32_to_cpu(*min_uV);
-   max_uV = of_get_property(np, "regulator-max-microvolt", NULL);
-   if (max_uV)
-   constraints->max_uV = be32_to_cpu(*max_uV);
+   if (!of_property_read_u32(np, "regulator-min-microvolt", &pval))
+   constraints->min_uV = pval;
+   if (!of_property_read_u32(np, "regulator-max-microvolt", &pval))
+   constraints->max_uV = pval;
 
/* Voltage change possible? */
if (constraints->min_uV != constraints->max_uV)
constraints->valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
/* Only one voltage?  Then make sure it's set. */
-   if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
+   if (constraints->min_uV && constraints->max_uV
+   && constraints->min_uV == constraints->max_uV)
constraints->apply_uV = true;
 
if (!of_property_read_u32(np, "regulator-microvolt-offset", &pval))
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.12 000/123] 3.12.50-stable review

[Nikolay Borisov]

Hello Jiri,

I think you should also add this patch:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2871c69e025e8bc507651d5a9cf81a8a7da9d24b

I hit this on 3.12.47 originally -
http://www.spinics.net/lists/dm-devel/msg24531.html

On 10/28/2015 03:51 PM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.50 release.
> There are 123 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Oct 30 09:39:16 CET 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.50-rc1.xz
> and the diffstat can be found below.
> 
> thanks,
> js
> 
> ===
> 
> 
> Aaron Conole (2):
>   af_unix: Convert the unix_sk macro to an inline function for type
> safety
>   af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag
> 
> Alexander Couzens (1):
>   l2tp: protect tunnel->del_work by ref_count
> 
> Andreas Schwab (1):
>   m68k: Define asmlinkage_protect
> 
> Andrew Morton (1):
>   Input: zhenhua - ensure we have BITREVERSE
> 
> Andrey Vagin (1):
>   net/unix: fix logic about sk_peek_offset
> 
> Andy Lutomirski (2):
>   x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code
>   x86/paravirt: Replace the paravirt nop with a bona fide empty function
> 
> Andy Shevchenko (1):
>   dmaengine: dw: properly read DWC_PARAMS register
> 
> Ard Biesheuvel (1):
>   ARM: 8429/1: disable GCC SRA optimization
> 
> Arnaldo Carvalho de Melo (2):
>   perf hists: Update the column width for the "srcline" sort key
>   perf header: Fixup reading of HEADER_NRCPUS feature
> 
> Ben Hutchings (1):
>   genirq: Fix race in register_irq_proc()
> 
> Ben Skeggs (1):
>   drm/nouveau/fbcon: take runpm reference when userspace has an open fd
> 
> Benjamin Tissoires (1):
>   HID: quirks: add QUIRK_NOGET for an other TPV touchscreen
> 
> Bin Liu (2):
>   usb: musb: cppi41: improve rx channel abort routine
>   usb: musb: fix cppi channel teardown for isoch transfer
> 
> Charles Keepax (1):
>   asix: Do full reset during ax88772_bind
> 
> Chris Mason (1):
>   btrfs: fix use after free iterating extrefs
> 
> Christoph Hellwig (1):
>   3w-9xxx: don't unmap bounce buffered commands
> 
> Daniel Lezcano (1):
>   ARM: ux500: cpuidle: fix section mismatch
> 
> Daniel Vetter (1):
>   drm: Reject DRI1 hw lock ioctl functions for kms drivers
> 
> Dave Airlie (1):
>   drm/qxl: only report first monitor as connected if we have no state
> 
> Dave Kleikamp (1):
>   crypto: sparc - initialize blkcipher.ivsize
> 
> David Woodhouse (1):
>   x86/platform: Fix Geode LX timekeeping in the generic x86 build
> 
> Dirk Müller (1):
>   Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS
> 
> Eric Dumazet (1):
>   net: add pfmemalloc check in sk_add_backlog()
> 
> Fabiano Fidêncio (1):
>   drm/qxl: recreate the primary surface when the bo is not primary
> 
> Felix Fietkau (1):
>   ath9k: declare required extra tx headroom
> 
> Filipe Manana (2):
>   Btrfs: fix read corruption of compressed and shared extents
>   Btrfs: update fix for read corruption of compressed and shared extents
> 
> Grazvydas Ignotas (1):
>   ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets
> 
> Guenter Roeck (2):
>   hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for
> most chips
>   spi: Fix documentation of spi_alloc_master()
> 
> Guillaume Nault (1):
>   ppp: don't override sk->sk_state in pppoe_flush_dev()
> 
> Hans Verkuil (1):
>   [media] usbvision: fix locking error
> 
> Henrik Rydberg (1):
>   HID: apple: Add support for the 2015 Macbook Pro
> 
> Huang Rui (1):
>   usb: core: implement AMD remote wakeup quirk
> 
> Ilya Dryomov (1):
>   rbd: fix double free on rbd_dev->header_name
> 
> James Hogan (1):
>   MIPS: dma-default: Fix 32-bit fall back to GFP_DMA
> 
> Jan H. Schönherr (1):
>   sched: Fix cpu_active_mask/cpu_online_mask race
> 
> Jan Kara (1):
>   jbd2: avoid infinite loop when destroying aborted journal
> 
> Jann Horn (1):
>   security: fix typo in security_task_prctl
> 
> Jason Wang (1):
>   kvm: fix zero length mmio searching
> 
> Jeff Mahoney (1):
>   btrfs: skip waiting on ordered range for special files
> 
> Jenny Derzhavetz (1):
>   iser-target: remove command with state ISTATE_REMOVE
> 
> Jiri Slaby (1):
>   Revert "USB: Add device quirk for ASUS T100 Base Station keyboard"
> 
> Joe Perches (1):
>   ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings
> 
> Joe Stringer (1):
>   netfilter: nf_conntrack: Support expectations in different zones
> 
> Joe Thornber (2):
>   dm btree: add ref counting ops for the leaves of top level btrees
>   dm cache: fix NULL pointer when switching from cleaner policy
> 
> Joerg Roedel (1):
>   iommu/amd: Handle integer overflow in dma_ops_area_alloc
> 
> Johan Hovold (1):

Re: tracepoint filter problems

[Peter Zijlstra]

On Thu, Oct 29, 2015 at 12:27:42PM -0300, Arnaldo Carvalho de Melo wrote:
> Hi,
> 
>   In 'perf trace' we have an equivalent to strace's -e option, i.e. a way
> to state which syscalls one wants to see, so, when we do:
> 
> [root@felicio linux]# trace -e open
>  0.348 ( 0.005 ms): ls/6887 open(filename: /etc/ld.so.cache, flags: 
> CLOEXEC   ) = 3
>  0.363 ( 0.005 ms): ls/6887 open(filename: /lib64/libselinux.so.1, flags: 
> CLOEXEC ) = 3
>  0.400 ( 0.006 ms): ls/6887 open(filename: /lib64/libcap.so.2, flags: 
> CLOEXEC ) = 3
>  0.427 ( 0.006 ms): ls/6887 open(filename: /lib64/libacl.so.1, flags: 
> CLOEXEC ) = 3
>  0.454 ( 0.006 ms): ls/6887 open(filename: /lib64/libc.so.6, flags: 
> CLOEXEC   ) = 3
>  0.497 ( 0.006 ms): ls/6887 open(filename: /lib64/libpcre.so.1, flags: 
> CLOEXEC) = 3
>  0.533 ( 0.006 ms): ls/6887 open(filename: /lib64/liblzma.so.5, flags: 
> CLOEXEC) = 3
>  0.561 ( 0.006 ms): ls/6887 open(filename: /lib64/libdl.so.2, flags: 
> CLOEXEC  ) = 3
>  0.586 ( 0.006 ms): ls/6887 open(filename: /lib64/libattr.so.1, flags: 
> CLOEXEC) = 3
>  0.611 ( 0.006 ms): ls/6887 open(filename: /lib64/libpthread.so.0, flags: 
> CLOEXEC ) = 3
>  0.859 ( 0.007 ms): ls/6887 open(filename: 
> /usr/lib/locale/locale-archive, flags: CLOEXEC ) = 3
> ^C[root@felicio linux]#
> 
> I.e. tracing system wide, looking for any program that calls the open 
> syscall, it works, as it
> used the PERF_EVENT_IOC_SET_FILTER to set the relevant 'id == 486' to filter 
> it:
> 
> [root@felicio linux]# head -2 
> /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/format 
> name: sys_enter_open
> ID: 486
> 
> Ok, this is how it should be, all works, but if I try instead calling a 
> program
> that in turn calls another, the filter will apply for the first in line, but
> not for the calls made by another program called from it.
> 
> In the example below 'perf trace' will ask to see just the 'open' syscall, and
> it works for the started workload, namely 'perf record', but then it'll call
> 'sleep 1000' and there the filter doesn't apply, bummer :-\
> 
> The inherit bit is set, sure, as we can see when adding -vv to the 'perf 
> trace'
> call, ideas?

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6939,6 +6939,10 @@ static int perf_tp_filter_match(struct p
 {
void *record = data->raw->data;
 
+   /* only top level events have filters set */
+   if (event->parent)
+   event = event->parent;
+
if (likely(!event->filter) || filter_match_preds(event->filter, record))
return 1;
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] wireless:b43: remove last reference on B43_PCMCIA

[Valentin Rothberg]

Remove last reference on Kconfig option B43_PCMCIA, which has been
removed by commit 399500da18f7 ("ssb: pick PCMCIA host code support from
b43 driver").

Signed-off-by: Valentin Rothberg 
---
 drivers/net/wireless/b43/main.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index ec013fbd6a81..524e5f4a07dd 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -5820,15 +5820,12 @@ void b43_controller_restart(struct b43_wldev *dev, 
const char *reason)
 
 static void b43_print_driverinfo(void)
 {
-   const char *feat_pci = "", *feat_pcmcia = "", *feat_nphy = "",
-  *feat_leds = "", *feat_sdio = "";
+   const char *feat_pci = "", *feat_nphy = "", *feat_leds = "",
+  *feat_sdio = "";
 
 #ifdef CONFIG_B43_PCI_AUTOSELECT
feat_pci = "P";
 #endif
-#ifdef CONFIG_B43_PCMCIA
-   feat_pcmcia = "M";
-#endif
 #ifdef CONFIG_B43_PHY_N
feat_nphy = "N";
 #endif
@@ -5838,10 +5835,8 @@ static void b43_print_driverinfo(void)
 #ifdef CONFIG_B43_SDIO
feat_sdio = "S";
 #endif
-   printk(KERN_INFO "Broadcom 43xx driver loaded "
-  "[ Features: %s%s%s%s%s ]\n",
-  feat_pci, feat_pcmcia, feat_nphy,
-  feat_leds, feat_sdio);
+   printk(KERN_INFO "Broadcom 43xx driver loaded [ Features: %s%s%s%s ]\n",
+  feat_pci, feat_nphy, feat_leds, feat_sdio);
 }
 
 static int __init b43_init(void)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Vinod Koul]

On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote:
> Hi,
> 
> 1) This seems to have broken BBB in -next for me, bisected down to this patch.
> 
> For bootlog:
> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
> 
> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> at least without an ack from the platform maintainer. It can be a a
> huge mess if they end up causing conflicts, so we always ask to merge
> the DT changes through the platform maintainer (Tony in this case) by
> default.

I did warn when applying that I am doing so without ACK on ARM code, noone
said a thing!

I knew Tony was following the work by Peter so assumed he must have been okay
with it otherwise would have spoken for ~couple of weeks these were in
review

Anyway now that we have a regression, I can revert this patch if that fixes,
please confirm, but might break edma... peter?

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 05/20] ARC: rwlock: disable interrupts in !LLSC variant

[Peter Zijlstra]

On Mon, Nov 02, 2015 at 03:12:49PM +0530, Vineet Gupta wrote:
> > @@ -664,16 +670,24 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
> >  
> >  static inline void arch_read_unlock(arch_rwlock_t *rw)
> >  {
> > +   unsigned long flags;
> > +
> > +   local_irq_save(flags);
> > arch_spin_lock(&(rw->lock_mutex));
> 
> 
> Isn't raw_spin_lock_irqsave() equivalent and more concise ?

You might run into header file recursion issues; also raw_spinlock has
lockdep annotations added, whereas the above does not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node

[Alim Akhtar]

This patch add pmic (s2mps15) node of espresso board,
which includes addition of regulators and pmic-clk sub-nodes.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Alim Akhtar 
---
This patch should go in after driver side changes [1] lands.
[1]-> 
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg47736.html

 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349 +++
 1 file changed, 349 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 838a3626dac1..8ce04a0ec928 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -53,6 +53,355 @@
status = "okay";
 };
 
+&hsi2c_4 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <20>;
+   status = "okay";
+
+   s2mps15_pmic@66 {
+   compatible = "samsung,s2mps15-pmic";
+   reg = <0x66>;
+   interrupts = <2 0>;
+   interrupt-parent = <&gpa0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmic_irq>;
+   wakeup-source;
+
+   s2mps15_osc: clocks {
+   compatible = "samsung,s2mps13-clk";
+   #clock-cells = <1>;
+   clock-output-names = "s2mps13_ap", "s2mps13_cp",
+   "s2mps13_bt";
+   };
+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "vdd_ldo1";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <90>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo2_reg: LDO2 {
+   regulator-name = "vdd_ldo2";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <125>;
+   regulator-always-on;
+   };
+
+   ldo3_reg: LDO3 {
+   regulator-name = "vdd_ldo3";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo4_reg: LDO4 {
+   regulator-name = "vdd_ldo4";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <111>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo5_reg: LDO5 {
+   regulator-name = "vdd_ldo5";
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo6_reg: LDO6 {
+   regulator-name = "vdd_ldo6";
+   regulator-min-microvolt = <225>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo7_reg: LDO7 {
+   regulator-name = "vdd_ldo7";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <115>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo8_reg: LDO8 {
+   regulator-name = "vdd_ldo8";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <100>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <125>;
+   };
+
+   ldo9_reg: LDO9 {
+   regulator-name = "vdd_ldo9";
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <100>;
+   regulato

[PATCH 2/2] arm64: dts: exynos7: Enable HS200 mode operation

[Alim Akhtar]

This patch enables HS200 mode operation on exynos7 based
espresso board.
This also remove _broken-cd_ property as per mmc binding documentation
which say one of the properties between broken-cd and non-removable
should be used. And we already use _non-removable_ as emmc mounted
on board which is a non-removable device.

Signed-off-by: Alim Akhtar 
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 8ce04a0ec928..7f19b99fc85b 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -405,8 +405,8 @@
 &mmc_0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
cap-mmc-highspeed;
+   mmc-hs200-1_8v;
non-removable;
card-detect-delay = <200>;
clock-frequency = <8>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ahci: Add Marvell 88se91a2 device id

[Johannes Thumshirn]

On Sat, 2015-10-31 at 10:16 +0900, Tejun Heo wrote:
> On Tue, Oct 27, 2015 at 11:48:14AM +0100, Johannes Thumshirn wrote:
> > On Tue, 2015-10-20 at 09:31 +0200, Johannes Thumshirn wrote:
> > > Add device id for Marvell 88se91a2
> > 
> > Tejun, ping?
> 
> Oops, missed this one somehow.  Applied to libata/for-4.4.
> 
> Thanks.
> 

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] md/raid5: remove redundant check in stripe_add_to_batch_list()

[Roman Gushchin]

The stripe_add_to_batch_list() function is called only if
stripe_can_batch() returned true, so there is no need for double check.

Signed-off-by: Roman Gushchin 
Cc: Neil Brown 
Cc: linux-r...@vger.kernel.org
---
 drivers/md/raid5.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 45933c1..f829ebc 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -768,8 +768,6 @@ static void stripe_add_to_batch_list(struct r5conf *conf, 
struct stripe_head *sh
int hash;
int dd_idx;
 
-   if (!stripe_can_batch(sh))
-   return;
/* Don't cross chunks, so stripe pd_idx/qd_idx is the same */
tmp_sec = sh->sector;
if (!sector_div(tmp_sec, conf->chunk_sectors))
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] IB/ipoib: optimized the function ipoib_mcast_alloc

[Erez Shitrit]

On Sun, Nov 1, 2015 at 8:23 AM, Saurabh Sengar  wrote:
> ipoib_mcast_alloc is called only in atomic context,
> hence removing the extra check.
>
> Signed-off-by: Saurabh Sengar 

Acked-by: Erez Shitrit 

> ---
> Hi,
> Even if in future, if there are some functions expected to call it in normal 
> context(not atomic),
> we can pass the GFP_KERNEL or GFP_ATOMIC directly to function call instead of 
> passing 0 and 1,
> which later again need to be compared in order to change it to GFP_KERNEL and 
> GFP_ATOMIC.
> Please let me know if there are better ways to improve it.
>
>  drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 
> b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> index d750a86..15d35be 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> @@ -132,12 +132,11 @@ void ipoib_mcast_free(struct ipoib_mcast *mcast)
> kfree(mcast);
>  }
>
> -static struct ipoib_mcast *ipoib_mcast_alloc(struct net_device *dev,
> -int can_sleep)
> +static struct ipoib_mcast *ipoib_mcast_alloc(struct net_device *dev)
>  {
> struct ipoib_mcast *mcast;
>
> -   mcast = kzalloc(sizeof *mcast, can_sleep ? GFP_KERNEL : GFP_ATOMIC);
> +   mcast = kzalloc(sizeof *mcast, GFP_ATOMIC);
> if (!mcast)
> return NULL;
>
> @@ -573,7 +572,7 @@ void ipoib_mcast_join_task(struct work_struct *work)
> if (!priv->broadcast) {
> struct ipoib_mcast *broadcast;
>
> -   broadcast = ipoib_mcast_alloc(dev, 0);
> +   broadcast = ipoib_mcast_alloc(dev);
> if (!broadcast) {
> ipoib_warn(priv, "failed to allocate broadcast 
> group\n");
> /*
> @@ -728,7 +727,7 @@ void ipoib_mcast_send(struct net_device *dev, u8 *daddr, 
> struct sk_buff *skb)
> ipoib_dbg_mcast(priv, "setting up send only multicast 
> group for %pI6\n",
> mgid);
>
> -   mcast = ipoib_mcast_alloc(dev, 0);
> +   mcast = ipoib_mcast_alloc(dev);
> if (!mcast) {
> ipoib_warn(priv, "unable to allocate memory "
>"for multicast structure\n");
> @@ -886,7 +885,7 @@ void ipoib_mcast_restart_task(struct work_struct *work)
> ipoib_dbg_mcast(priv, "adding multicast entry for 
> mgid %pI6\n",
> mgid.raw);
>
> -   nmcast = ipoib_mcast_alloc(dev, 0);
> +   nmcast = ipoib_mcast_alloc(dev);
> if (!nmcast) {
> ipoib_warn(priv, "unable to allocate memory 
> for multicast structure\n");
> continue;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: imx: add 'is_prepared' clk_ops callback for pllv3 clk

[Lucas Stach]

Am Dienstag, den 03.11.2015, 02:06 +0800 schrieb Bai Ping:
> Add 'is_prepared' callback function for pllv3 type clk to make sure when
> the system is bootup, the unused clk is in a known state to match the
> prepare count info.
> 
What does this commit fix?
Is it there to ensure clocks are turned off at the disable unused clocks
phase even if they haven't been prepared even once during bootup?

Regards,
Lucas

> Signed-off-by: Bai Ping 
> ---
>  drivers/clk/imx/clk-pllv3.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 6addf8f..c05c43d 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -97,6 +97,16 @@ static void clk_pllv3_unprepare(struct clk_hw *hw)
>   writel_relaxed(val, pll->base);
>  }
>  
> +static int clk_pllv3_is_prepared(struct clk_hw *hw)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> +
> + if (readl_relaxed(pll->base) & BM_PLL_LOCK)
> + return 1;
> +
> + return 0;
> +}
> +
>  static unsigned long clk_pllv3_recalc_rate(struct clk_hw *hw,
>  unsigned long parent_rate)
>  {
> @@ -139,6 +149,7 @@ static int clk_pllv3_set_rate(struct clk_hw *hw, unsigned 
> long rate,
>  static const struct clk_ops clk_pllv3_ops = {
>   .prepare= clk_pllv3_prepare,
>   .unprepare  = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
>   .recalc_rate= clk_pllv3_recalc_rate,
>   .round_rate = clk_pllv3_round_rate,
>   .set_rate   = clk_pllv3_set_rate,
> @@ -193,6 +204,7 @@ static int clk_pllv3_sys_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  static const struct clk_ops clk_pllv3_sys_ops = {
>   .prepare= clk_pllv3_prepare,
>   .unprepare  = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
>   .recalc_rate= clk_pllv3_sys_recalc_rate,
>   .round_rate = clk_pllv3_sys_round_rate,
>   .set_rate   = clk_pllv3_sys_set_rate,
> @@ -265,6 +277,7 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  static const struct clk_ops clk_pllv3_av_ops = {
>   .prepare= clk_pllv3_prepare,
>   .unprepare  = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
>   .recalc_rate= clk_pllv3_av_recalc_rate,
>   .round_rate = clk_pllv3_av_round_rate,
>   .set_rate   = clk_pllv3_av_set_rate,
> @@ -279,6 +292,7 @@ static unsigned long clk_pllv3_enet_recalc_rate(struct 
> clk_hw *hw,
>  static const struct clk_ops clk_pllv3_enet_ops = {
>   .prepare= clk_pllv3_prepare,
>   .unprepare  = clk_pllv3_unprepare,
> + .is_prepared= clk_pllv3_is_prepared,
>   .recalc_rate= clk_pllv3_enet_recalc_rate,
>  };
>  

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/7] clocksource/drivers/pxa_timer: Move the Kconfig rule

[Amit Kucheria]

On Mon, Nov 2, 2015 at 1:33 PM, Daniel Lezcano
 wrote:
>
> Hi Amit,
>
> On 11/02/2015 08:44 AM, Amit Kucheria wrote:
>>
>> On Fri, Oct 30, 2015 at 4:22 AM, Daniel Lezcano
>>  wrote:
>>>
>>> Instead of having the clocksource's Kconfig depending on the arch, let
>>> the
>>> arch to select the timer it needs.
>>
>>
>> Is this the prescribed way to do things nowadays? It leads to more
>> options showing up in 'make menuconfig'. Why do I need to see
>> CLKSRC_PXA if I'm not even compiling for ARCH_PXA (and not interesting
>> in COMPILE_TEST)?
>
>
> That won't happen.
>
> As the 'bool' has no string after, it won't show up in the menuconfig.

Nice, I didn't know that.

> Actually, with the next patch, only COMPILE_TEST will show it up in the
>
> Device Drivers->Clocksource drivers.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc

[Peter Ujfalusi]

In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
do any configuration within TPTC for the eDMA3 to be operational. All
configuration is via the TPCC.
To prevent the omap_device_late_idle() to disable the TPTCs when they are
no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
added.

Signed-off-by: Peter Ujfalusi 
---
Vinod, Olof,

This patch somehow got lost in my working branch. It was mixed within the 
patches
I will have for 4.5 while it should have been within the new eDMA3 binding
series..

Regards,
Peter

 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b78ea..3c7106a09801 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
.name   = "tptc0",
.class  = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
-   .flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+  HWMOD_INIT_NO_IDLE),
.main_clk   = "l3_gclk",
.prcm   = {
.omap4  = {
@@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
.name   = "tptc1",
.class  = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
-   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+  HWMOD_INIT_NO_IDLE),
.main_clk   = "l3_gclk",
.prcm   = {
.omap4  = {
@@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
.name   = "tptc2",
.class  = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
-   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+  HWMOD_INIT_NO_IDLE),
.main_clk   = "l3_gclk",
.prcm   = {
.omap4  = {
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 2/9] Input: goodix - reset device at init

[mika.westerb...@linux.intel.com]

On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote:
> cpi_dev_add_driver_gpios() does not really help with generic drivers
> (unless we keep adding more and more board specific data to them). How
> about we keep track of names used and only allow conversion for the
> first name used, like in the patch below?

That works but it misses one case: When you have optional GPIOs and not
all of them are provided. Currently it ends up the same situation
returning the same GPIO.

I've commented below how we could handle that case as well.

> -- 
> Dmitry
> 
> gpiolib: tighten up ACPI legacy gpio lookups
> 
> From: Dmitry Torokhov 
> 
> We should not fall back to the legacy unnamed gpio lookup style if the
> driver requests gpios with different names, because we'll give out the same
> gpio twice. Let's keep track of the names that were used for the device and
> only do the fallback for the first name used.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/gpio/gpiolib.c |   42 +-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 5db3445..4ae5447 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device 
> *dev, const char *con_id,
>   return desc;
>  }
>  
> +struct acpi_gpio_lookup {
> + struct list_head node;
> + struct device *dev;
> + const char *con_id;
> +};
> +
> +static DEFINE_MUTEX(acpi_gpio_lookup_lock);
> +static LIST_HEAD(acpi_gpio_lookup_list);
> +
> +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id)
> +{
> + struct acpi_gpio_lookup *l, *lookup = NULL;

I'm thinking if we here do

struct acpi_device *adev = ACPI_COMPANION(dev);

/* Never fallback if the device has properties */
if (adev->data.properties || adev->driver_gpios)
return false;

> +
> + mutex_lock(&acpi_gpio_lookup_lock);
> +
> + list_for_each_entry(l, &acpi_gpio_lookup_list, node) {
> + if (l->dev == dev) {
> + lookup = l;
> + break;
> + }
> + }
> +
> + if (!lookup) {
> + lookup = kmalloc(sizeof(*lookup), GFP_KERNEL);
> + if (lookup) {
> + lookup->dev = dev;
> + lookup->con_id = con_id;
> + list_add_tail(&lookup->node, &acpi_gpio_lookup_list);
> + }
> + }
> +
> + mutex_lock(&acpi_gpio_lookup_lock);
> +
> + return lookup &&
> + ((!lookup->con_id && !con_id) ||
> +  (lookup->con_id && con_id &&
> +   strcmp(lookup->con_id, con_id) == 0));
> +}
> +
>  static struct gpio_desc *acpi_find_gpio(struct device *dev, const char 
> *con_id,
>   unsigned int idx,
>   enum gpio_lookup_flags *flags)
> @@ -1765,7 +1804,8 @@ static struct gpio_desc *acpi_find_gpio(struct device 
> *dev, const char *con_id,
>  
>   /* Then from plain _CRS GPIOs */
>   if (IS_ERR(desc)) {
> - desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info);
> + if (acpi_can_fallback_crs(dev, con_id))
> + desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info);

and here we could do

if (!acpi_can_fallback_crs(dev, con_id))
return ERR_PTR(-ENOENT);
desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info);

So instead return -ENOENT so that gpiod_get_index_optional() handles the
missing optional GPIO properly.

>   if (IS_ERR(desc))
>   return desc;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: imx: add 'is_prepared' clk_ops callback for pllv3 clk

[Bai Ping]

Add 'is_prepared' callback function for pllv3 type clk to make sure when
the system is bootup, the unused clk is in a known state to match the
prepare count info.

Signed-off-by: Bai Ping 
---
 drivers/clk/imx/clk-pllv3.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 6addf8f..c05c43d 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -97,6 +97,16 @@ static void clk_pllv3_unprepare(struct clk_hw *hw)
writel_relaxed(val, pll->base);
 }
 
+static int clk_pllv3_is_prepared(struct clk_hw *hw)
+{
+   struct clk_pllv3 *pll = to_clk_pllv3(hw);
+
+   if (readl_relaxed(pll->base) & BM_PLL_LOCK)
+   return 1;
+
+   return 0;
+}
+
 static unsigned long clk_pllv3_recalc_rate(struct clk_hw *hw,
   unsigned long parent_rate)
 {
@@ -139,6 +149,7 @@ static int clk_pllv3_set_rate(struct clk_hw *hw, unsigned 
long rate,
 static const struct clk_ops clk_pllv3_ops = {
.prepare= clk_pllv3_prepare,
.unprepare  = clk_pllv3_unprepare,
+   .is_prepared= clk_pllv3_is_prepared,
.recalc_rate= clk_pllv3_recalc_rate,
.round_rate = clk_pllv3_round_rate,
.set_rate   = clk_pllv3_set_rate,
@@ -193,6 +204,7 @@ static int clk_pllv3_sys_set_rate(struct clk_hw *hw, 
unsigned long rate,
 static const struct clk_ops clk_pllv3_sys_ops = {
.prepare= clk_pllv3_prepare,
.unprepare  = clk_pllv3_unprepare,
+   .is_prepared= clk_pllv3_is_prepared,
.recalc_rate= clk_pllv3_sys_recalc_rate,
.round_rate = clk_pllv3_sys_round_rate,
.set_rate   = clk_pllv3_sys_set_rate,
@@ -265,6 +277,7 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw, 
unsigned long rate,
 static const struct clk_ops clk_pllv3_av_ops = {
.prepare= clk_pllv3_prepare,
.unprepare  = clk_pllv3_unprepare,
+   .is_prepared= clk_pllv3_is_prepared,
.recalc_rate= clk_pllv3_av_recalc_rate,
.round_rate = clk_pllv3_av_round_rate,
.set_rate   = clk_pllv3_av_set_rate,
@@ -279,6 +292,7 @@ static unsigned long clk_pllv3_enet_recalc_rate(struct 
clk_hw *hw,
 static const struct clk_ops clk_pllv3_enet_ops = {
.prepare= clk_pllv3_prepare,
.unprepare  = clk_pllv3_unprepare,
+   .is_prepared= clk_pllv3_is_prepared,
.recalc_rate= clk_pllv3_enet_recalc_rate,
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alexandre Belloni]

On 02/11/2015 at 09:03:59 +, Lee Jones wrote :
> > > I think you cannot apply it directly because it depends on headers from
> > > patch 2/4. It won't build.
> > > 
> > 
> > Yeah, this depends on the mfd tree. I don't thin Lee applied patch 2/4
> > yet so I'm taking that one for 4.5.
> 
> I don't mind if you take it, but if you do so you need to take the
> Regulator patch as well AND provide Mark and I a pull-request from an
> immutable branch please. 
> 

Actually, I was thinking that you would take 2/4 through your tree and I
would either base myself on that or delay the patch for 4.5. You could
also take the rtc patch if you plan to apply 2/4, feel free to add my
acked-by.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Peter Ujfalusi]

Hi Olof,

On 11/02/2015 11:21 AM, Olof Johansson wrote:
> Hi,
> 
> 1) This seems to have broken BBB in -next for me, bisected down to this patch.
> 
> For bootlog:
> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html

Aargh, I had the patch which should have been included to the series (just
sent it):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121134.html

It was mixed with the patches I collected for 4.5, I don't know how this
happened, but this is the reason I have not seen the issue you are seeing.

> 
> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> at least without an ack from the platform maintainer. It can be a a
> huge mess if they end up causing conflicts, so we always ask to merge
> the DT changes through the platform maintainer (Tony in this case) by
> default.
> 
> 
> Thanks,
> 
> -Olof
> 
> On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi  
> wrote:
>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
>> enable the DMA even crossbar with ti,am335x-edma-crossbar.
>> With the new bindings boards can customize and tweak the DMA channel
>> priority to match their needs. With the new binding the memcpy is safe
>> to be used since with the old binding it was not possible for a driver
>> to know which channel is allowed to be used as non HW triggered channel.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  arch/arm/boot/dts/am335x-evm.dts|  9 +---
>>  arch/arm/boot/dts/am335x-pepper.dts | 11 +
>>  arch/arm/boot/dts/am33xx.dtsi   | 96 
>> ++---
>>  3 files changed, 73 insertions(+), 43 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
>> b/arch/arm/boot/dts/am335x-evm.dts
>> index 1942a5c8132d..507980672c32 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -743,8 +743,8 @@
>>  &mmc3 {
>> /* these are on the crossbar and are outlined in the
>>xbar-event-map element */
>> -   dmas = <&edma 12
>> -   &edma 13>;
>> +   dmas = <&edma_xbar 12 0 1
>> +   &edma_xbar 13 0 2>;
>> dma-names = "tx", "rx";
>> status = "okay";
>> vmmc-supply = <&wlan_en_reg>;
>> @@ -766,11 +766,6 @@
>> };
>>  };
>>
>> -&edma {
>> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
>> -   2 13>;
>> -};
>> -
>>  &sham {
>> status = "okay";
>>  };
>> diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
>> b/arch/arm/boot/dts/am335x-pepper.dts
>> index 7106114c7464..39073b921664 100644
>> --- a/arch/arm/boot/dts/am335x-pepper.dts
>> +++ b/arch/arm/boot/dts/am335x-pepper.dts
>> @@ -339,13 +339,6 @@
>> ti,non-removable;
>>  };
>>
>> -&edma {
>> -   /* Map eDMA MMC2 Events from Crossbar */
>> -   ti,edma-xbar-event-map = /bits/ 16 <1 12
>> -2 13>;
>> -};
>> -
>> -
>>  &mmc3 {
>> /* Wifi & Bluetooth on MMC #3 */
>> status = "okay";
>> @@ -354,8 +347,8 @@
>> vmmmc-supply = <&v3v3c_reg>;
>> bus-width = <4>;
>> ti,non-removable;
>> -   dmas = <&edma 12
>> -   &edma 13>;
>> +   dmas = <&edma_xbar 12 0 1
>> +   &edma_xbar 13 0 2>;
>> dma-names = "tx", "rx";
>>  };
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index d23e2524d694..6053e75c6e99 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -174,12 +174,54 @@
>> };
>>
>> edma: edma@4900 {
>> -   compatible = "ti,edma3";
>> -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
>> -   reg =   <0x4900 0x1>,
>> -   <0x44e10f90 0x40>;
>> +   compatible = "ti,edma3-tpcc";
>> +   ti,hwmods = "tpcc";
>> +   reg =   <0x4900 0x1>;
>> +   reg-names = "edma3_cc&quo

Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc

[Vinod Koul]

On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote:
> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
> do any configuration within TPTC for the eDMA3 to be operational. All
> configuration is via the TPCC.
> To prevent the omap_device_late_idle() to disable the TPTCs when they are
> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
> added.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Vinod, Olof,
> 
> This patch somehow got lost in my working branch. It was mixed within the 
> patches
> I will have for 4.5 while it should have been within the new eDMA3 binding
> series..

Does this fix the issue reported by Olof? Also ACK pls for this

-- 
~Vinod
> 
> Regards,
> Peter
> 
>  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> index 907a452b78ea..3c7106a09801 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> @@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
>   .name   = "tptc0",
>   .class  = &am33xx_tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> @@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
>   .name   = "tptc1",
>   .class  = &am33xx_tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> @@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
>   .name   = "tptc2",
>   .class  = &am33xx_tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> -- 
> 2.6.1
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] EDAC queue for 4.4

[Borislav Petkov]

Hi Linus,

please pull the EDAC pile for 4.4. A bunch of fixes all over the place
and some hw enablement this time.

Thanks.

---
The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.4

for you to fetch changes up to 990995bad13c2bcf074f87236d1a6c5e09bd5eff:

  EDAC: Fix PAGES_TO_MiB macro misuse (2015-10-22 22:57:30 +0200)


* Convert EDAC to debugfs wrappers and make drivers use those.  (Borislav 
Petkov)

* L3 and SoC support for xgene_edac. (Loc Ho)

* AMD F15h, models 0x60-6f support to amd64_edac. (Aravind Gopalakrishnan)

* Fixes and cleanups all over the place.


Aravind Gopalakrishnan (4):
  EDAC, ghes_edac: Remove redundant memory_type array
  EDAC, amd64_edac: Extend scrub rate support to F15hM60h
  EDAC, amd64_edac: Update copyright and remove changelog
  Documentation/EDAC: Add reference documents section for amd64_edac

Borislav Petkov (5):
  EDAC: Carve out debugfs functionality
  EDAC: Add debugfs wrappers
  EDAC, altera: Convert to debugfs wrappers
  EDAC, i5100: Convert to debugfs wrappers
  EDAC, xgene: Convert to debugfs wrappers

Dinh Nguyen (1):
  EDAC, altera: SoCFPGA EDAC should not look for ECC_CORR_EN

Loc Ho (5):
  EDAC, Documentation: Update X-Gene EDAC binding for L3/SoC subnodes
  EDAC, xgene: Add L3 support
  EDAC, xgene: Fix possible sprintf() overflow issue
  EDAC, xgene: Add SoC support
  arm64, EDAC: Add L3/SoC DT subnodes to the APM X-Gene SoC EDAC node

Luis de Bethencourt (1):
  EDAC, ppc4xx_edac: Fix module autoload for OF platform driver

Seth Jennings (1):
  EDAC, sb_edac: Fix TAD presence check for sbridge_mci_bind_devs()

Tan Xiaojun (2):
  EDAC: Use edac_debugfs_remove_recursive()
  EDAC: Fix PAGES_TO_MiB macro misuse

Toshi Kani (3):
  EDAC: Fix sysfs dimm_label show operation
  EDAC: Fix sysfs dimm_label store operation
  EDAC: Don't allow empty DIMM labels

 .../devicetree/bindings/edac/apm-xgene-edac.txt|   23 +
 Documentation/edac.txt |   46 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   10 +
 drivers/edac/Makefile  |2 +
 drivers/edac/altera_edac.c |   20 +-
 drivers/edac/altera_edac.h |5 +-
 drivers/edac/amd64_edac.c  |   35 +-
 drivers/edac/amd64_edac.h  |   58 +-
 drivers/edac/debugfs.c |  163 +++
 drivers/edac/edac_core.h   |2 +
 drivers/edac/edac_mc.c |2 +-
 drivers/edac/edac_mc_sysfs.c   |  150 +--
 drivers/edac/edac_module.h |   34 +-
 drivers/edac/ghes_edac.c   |   24 +-
 drivers/edac/i5100_edac.c  |   37 +-
 drivers/edac/ppc4xx_edac.c |1 +
 drivers/edac/sb_edac.c |8 +-
 drivers/edac/xgene_edac.c  | 1193 
 include/linux/edac.h   |2 -
 19 files changed, 1352 insertions(+), 463 deletions(-)
 create mode 100644 drivers/edac/debugfs.c

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc

[Peter Ujfalusi]

On 11/02/2015 12:24 PM, Vinod Koul wrote:
> On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote:
>> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
>> do any configuration within TPTC for the eDMA3 to be operational. All
>> configuration is via the TPCC.
>> To prevent the omap_device_late_idle() to disable the TPTCs when they are
>> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
>> added.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>> Vinod, Olof,
>>
>> This patch somehow got lost in my working branch. It was mixed within the 
>> patches
>> I will have for 4.5 while it should have been within the new eDMA3 binding
>> series..
> 
> Does this fix the issue reported by Olof? Also ACK pls for this

Yes, it is fixing the issue, I have this in my branch. everything looks fine
on AM335x/AM437x/Dra7xx where I have eDMA in use.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [mm, page_alloc] 43993977ba: +88% OOM possibility

[Michal Hocko]

On Mon 02-11-15 16:55:15, Huang, Ying wrote:
> Michal Hocko  writes:
[...]
> > It would be interesting to see all the page allocation failure warnings
> > (if they are different). Maybe other callers have relied on GFP_ATOMIC
> > and access to memory reserves. The above path is not this case though.
> 
> I take a look at all dmesgs, and found the backtrace for page allocation
> failure is same for all.  Is it possible that this commit cause more
> memory were allocated or kept in memory so that more OOM were triggered?

I can imagine that some of the callers were not converted properly or
missed and a lack of __GFP_KSWAPD_RECLAIM could indeed cause a later
kswapd kick off. I am staring into the commit but nothing has jumped at
me yet. Could you collect /proc/vmstat (snapshot every 1s) on both good
and bad kernels. I expect the later would see a less scanning by kswapd.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] pin control changes for the v4.4 kernel cycle

[Linus Walleij]

Hi Linus,

here is the big pull request for v4.4-targeted pin control changes.
The details are in the signed tag.

Development pace is high in pin control again this merge window.
28 contributors, 83 patches.

It hits a few sites outside the pin control subsystem:

- Device tree bindings in Documentation (as usual)
- MAINTAINERS
- drivers/base/* for the "init" state handling by Doug Anderson.
  This has been ACKed by Greg.
- drivers/usb/renesas_usbhs/rcar2.c, for a dependent Renesas
  change in the USB subsystem. This has been ACKed by both
  Greg and Felipe.
- arch/arm/boot/dts/sama5d2.dtsi - this should ideally have
  gone through the ARM SoC tree but ended up here. May cause
  a conflict that was spotted in -next, but it is trivial. I should have
  seen this earlier, mea culpa.

This time I am using Geert Uytterhoeven as submaintainer for SH PFC
since the are three-four people working in parallel with new Renesas
ASICs.

Please pull this in!

Yours,
Linus Walleij


The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v4.4-1

for you to fetch changes up to d99c8053fc2473115f506782822cb7c33c687513:

  pinctrl: pinconf: remove needless loop (2015-10-31 22:13:07 +0100)


This is the big bulk of pin control changes for the
v4.4 kernel development cycle:

Infrastructure:
- Doug Anderson wrote a patch adding an "init" state
  different from the "default" state for pin control
  state handling in the core framework. This is applied
  before the driver's probe() call if defined and takes
  precedence over "default". If both are defined, "init"
  will be applied *before* probe() and "default" will be
  applied *after* probe().

Significant subdriver improvements:
- SH PFC is switched to getting GPIO ranges from the
  device tree ranges property on DT platforms.
- Got rid of CONFIG_ARCH_SHMOBILE_LEGACY, we are all
  modernized.
- Got rid of SH PFC hardcoded IRQ numbers.
- Allwinner sunxi external interrupt through the "r"
  controller.
- Moved the Cygnus driver to use DT-provided GPIO
  ranges.

New drivers:
- Atmel PIO4 pin controller for the SAMA4D2 family

New subdrivers:
- Rockchip RK3036 subdriver
- Renesas SH PFC R8A7795 subdriver
- Allwinner sunxi A83T PIO subdriver
- Freescale i.MX7d iomux lpsr subdriver
- Marvell Berlin BG4CT subdriver
- SiRF Atlas 7 step B SoC subdriver
- Intel Broxton SoC subdriver

Apart from this, the usual slew if syntactic and semantic
fixes.


Adrian Alonso (4):
  pinctrl: freescale: imx: allow mux_reg offset zero
  pinctrl: freescale: imx: add shared input select reg support
  pinctrl: freescale: imx7d: support iomux lpsr controller
  pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings

Antoine Tenart (2):
  pinctrl: berlin: select the pinctrl driver according to the SoC used
  pinctrl: berlin: add explicit dependency on OF

Antoine Ténart (1):
  pinctrl: berlin: fix my family name spelling

Douglas Anderson (1):
  drivers/pinctrl: Add the concept of an "init" state

Geert Uytterhoeven (12):
  pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
  pinctrl: sh-pfc: Remove empty gpio_function_free()
  pinctrl: sh-pfc: Confine legacy function GPIOs to SH
  pinctrl: sh-pfc: r8a7794: Remove bogus SCIF0 SCK pin data
  pinctrl: sh-pfc: r8a7791/r8a7793: Correct SCIFB1_B SCK MOD_SEL value
  pinctrl: sh-pfc: Get rid of CONFIG_ARCH_SHMOBILE_LEGACY
  pinctrl: sh-pfc: r8a7795: add SCIFx support
  pinctrl: sh-pfc: Rename .gpio_data[] to .pinmux_data[]
  usb: renesas_usbhs: Remove unneeded #include

  pinctrl: sh-pfc: Stop including 
  pinctrl: sh-pfc: Remove obsolete r8a7779 platform_device_id entry
  pinctrl: sh-pfc: Remove obsolete r8a7778 platform_device_id entry

Hans de Goede (2):
  pinctrl: sunxi: Fix irq_of_xlate for the r_pio pinctrl block
  pinctrl: sunxi: Add irq pinmuxing to sun6i "r" pincontroller

Javier Martinez Canillas (7):
  pinctrl: mediatek: Consistently use the BIT() macro
  pinctrl: tz1090: Remove unneded semicolons
  pinctrl: tz1090-pdc: Remove unneded semicolons
  pinctrl: mxs: Remove unneded semicolon
  pinctrl: sunxi: Remove unneeded semicolon
  pinctrl: mediatek: Remove unneded semicolon
  pinctrl: samsung: Remove unneded semicolon

Jisheng Zhang (4):
  pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()
  pinctrl: berlin: Make berlin pinctrl driver visible if COMPILE_TEST=y
  pinctrl: berlin: add the berlin4ct pinctrl driver
  pinctrl: dt-binding: document berlin4ct SoC pinctrl

Jon Hunter (1):
  pinctrl: tegra-xusb: Correct lane mux options

Jonas Gorski (1):
  pinctrl: qcom: s

Re: make xconfig no longer works in Fedora

[Michal Marek]

On 2015-11-02 04:20, Thiago Macieira wrote:
> - qtver=`qmake -query QT_VERSION` || { \
> + qtver=`qmake -query QT_VERSION` || \
> + qtver=`qmake-qt5 -query QT_VERSION` || \
> + qtver=`qmake-qt4 -query QT_VERSION` || { \

The qtlibdir= etc assignments below still use qmake directly, plus this
will print an error if the command is not called "qmake." As Alexey
says, we do not need qmake, we need moc and the cflags / ldflags. Since
pkg-config worked for us previously, I suggest to use pkg-config again
and just check which of QtGui or Qt5Widgets is available.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the arm64 tree with Linus' tree

[Catalin Marinas]

On Sun, Nov 01, 2015 at 10:53:27AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/suspend.c
> 
> between commit:
> 
>   e13d918a19a7 ("arm64: kernel: fix tcr_el1.t0sz restore on systems with 
> extended idmap")
> 
> from Linus' tree and commit:
> 
>   8e63d3887669 ("arm64: flush: use local TLB and I-cache invalidation")
> 
> from the arm64 tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

The fix-up is fine. Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 4/5] drm/dsi: Add routine to unregister dsi device

[Andrzej Hajda]

On 11/02/2015 07:28 AM, Archit Taneja wrote:
>
> On 10/30/2015 07:51 PM, Andrzej Hajda wrote:
>> On 10/06/2015 11:24 AM, Archit Taneja wrote:
>>> A driver calling mipi_dsi_device_new might want to unregister the device
>>> once it's done. It might also require it in an error handling path in
>>> case something didn't go right.
>>>
>>> When the dsi host driver calls mipi_dsi_host_unregister, the devices
>>> created by both DT and and without DT will be removed. This does leave
>>> the possibility of the host removing the dsi device without the
>>> peripheral driver being aware of it. I don't know a good way to solve
>>> this. Some suggestions here would be of help too.
>> The 2nd paragraph is not relevant here. It is another issue. Some comments
>> about it:
> Yes, it's probably not the best to put it in the commit message of this
> patch.
>
>> I am not sure, but I guess device should not be removed if it is refcounted
>> properly, it will be just detached from the driver, bus and system (whatever 
>> it
>> means:) ).
>> It does not mean it will be usable and probably some races can occur anyway.
>> I guess i2c and other buses have the same problem, am I right?
> I was concerned about one particular sequence:
>
> 1) DSI host driver calls mipi_dsi_host_unregister: All dsi devices would 
> be unregistered.
>
> 2) dsi device driver calls mipi_dsi_device_unregister: This will try to
> unregister our dsi device
>
> The problem here is that the device will cease to exist after step (1)
> itself, because the refcount of our device will never be 2.
>
> mipi_dsi_host_register() will only register devices represented in DT,
> not the one the drivers register manually.
>
> In other words, the dsi pointer in our driver will point to nothing 
> valid after mipi_dsi_host_unregister is called.
>
> As you said, I guess this exists in other buses too, and it's the
> drivers job to not use them.

I think the whole problem is due to fact we try to use devices
as interfaces to some bus hosts (DSI in our case), these devices
are owned by bus host and we cannot control their lifetime from other code.
The best solution IMO would be to create separate lightweight framework
as I suggested in previous discussion[1]. It should be cleaner solution
without any 'dummy' proxy devices.
But even in this case we would need some callbacks to notify that the provider
is about to be removed.

2nd 'solution' is to leave it as is and pretend everything is OK,
as in case of other frameworks :)

Maybe it would be possible 3rd solution - we could use probe and remove 
callbacks
from dsi driver to notify clients about adding/removal of dsi device to/from 
bus.
So during dummy dsi dev creation we would provide some callbacks which would be
called
by dummy dsi driver probe/remove to notifiy client it can start/stop using dsi
device.
This crazy construction probably can work but looks insane :)

[1]: http://www.spinics.net/lists/linux-arm-msm/msg16945.html

Regards
Andrzej

>
>>> Signed-off-by: Archit Taneja 
>>> ---
>>>   drivers/gpu/drm/drm_mipi_dsi.c | 7 +++
>>>   include/drm/drm_mipi_dsi.h | 2 ++
>>>   2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>>> index db6130a..cbb7373 100644
>>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>>> @@ -183,6 +183,13 @@ err:
>>>   }
>>>   EXPORT_SYMBOL(mipi_dsi_device_new);
>>>
>>> +void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi)
>>> +{
>>> +   if (dsi)
>>> +   device_unregister(&dsi->dev);
>>> +}
>>> +EXPORT_SYMBOL(mipi_dsi_device_unregister);
>>> +
>> I guess NULL check can be removed and the whole function can be inlined.
> Yeah, this check won't help anyway.
>
> I think I'll mention that drivers should use this only in error
> handling paths, and not in the driver's remove() op.
>
> I'll also change this to inlined.
>
> Archit
>
>> Regards
>> Andrzej
>>>   static struct mipi_dsi_device *
>>>   of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node 
>>> *node)
>>>   {
>>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>>> index 93dec7b..68f49f4 100644
>>> --- a/include/drm/drm_mipi_dsi.h
>>> +++ b/include/drm/drm_mipi_dsi.h
>>> @@ -197,6 +197,8 @@ ssize_t mipi_dsi_generic_read(struct mipi_dsi_device 
>>> *dsi, const void *params,
>>>
>>>   struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
>>> struct mipi_dsi_device_info *info);
>>> +void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi);
>>> +
>>>   /**
>>>* enum mipi_dsi_dcs_tear_mode - Tearing Effect Output Line mode
>>>* @MIPI_DSI_DCS_TEAR_MODE_VBLANK: the TE output line consists of 
>>> V-Blanking
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

--
To uns

Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer

[Jiri Kosina]

On Mon, 2 Nov 2015, Rafael J. Wysocki wrote:

> > > > BTW, a quite some of this has been already "pre-discussed" in 
> > > > Documentation/power/freezing-of-tasks.txt (which has BTW been written 
> > > > before we've had the possibility to freeze filesystems, and this fact 
> > > > is 
> > > > even point there out).
> > > 
> > > That is somewhat outdated in my view.  At least my list of reasons for 
> > > using
> > > the freezer is now somewhat different from the one given in that file.
> > 
> > Well, so what is the list then, and how do you know that kthread_run() 
> > users are behaving according to that list? That's basically exactly what 
> > this effort is about -- making some sense out of current situation.
> 
> Currently, the #1 reason for using the freezer is to prevent user space
> from interacting with devices during system suspend/resume.  BTW, that also
> covers devices with runtime PM support, because the handling of user space
> access to them in the runtime PM case may be different.
> 
> For example, if user space does a "read" or "write" on a character device
> which is runtime-suspended at that point, the driver may want to resume the
> device temporarily, carry out the operation and suspend it again, but that
> generally won't work for the system suspend case.

But why would this even be relevant in this discussion, given that at the 
point we are talking about, the whole userspace has been frozen already?

> The #2 reason in my view is that essentially the freezer is what makes a
> difference between runtime idle and system suspend on platforms without
> firmware/hardware suspend support (or the lightweight variants of suspend
> in general).  Namely, it effectively prevents user space from setting up
> timers in the future and helps to reduce interrupt noise causing the CPUs
> to leave deep low-power states too often (at least in some cases).

I am of course at all not trying to remove freezer for userspace. This 
whole discussion is solely about explicit usage of freezer in kthreads.

> The #3 reason is to provide a way for things that might touch persistent
> storage after a hibernation image had been created to prevent themselves from
> running during that time.  Note that it also is a good idea to prevent such
> things from running during system suspend/resume in general so they don't
> try to access devices at wrong times.
> 
> BTW, the freezing of filesystems during system suspend (not hibernation) makes
> sense too, because it will help to address the long-standing issue with 
> storage
> devices that go away while the system is suspended.
> 
> I guess it may also helps to address the case when a device is removed from a
> suspended system, written to on another system in the meantime and inserted
> back into the (still suspended) original system which then is resumed.  Today
> this is an almost guaranteed data corruption scenario, but if the filesystem 
> in
> question is properly frozen during suspend, the driver should be able to 
> detect
> superblock changes during unfreeze.
> 
> So the approach I'd suggest would be to add the freezing of filesystems to the
> suspend/resume code paths just for the above reasons and drop the kthreads
> freezing from the filesystems that support the proper freezing.  The rest
> should be easier to deal with then.

That alone makes sense. It'll however leave a load of freezer users in the 
kernel that make no sense (one example picked completely out of the air: 
w1_process(); what is the reason for it there?) and are likely broken 
(completely random examples again: md, xfsaild -- they think they are 
freezable, but they are not).

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model

[dawei chien]

Hi Viresh,
On Wed, 2015-10-28 at 21:14 +0530, Viresh Kumar wrote:
> On 22-10-15, 20:02, Dawei Chien wrote:
> > Use Intelligent Power Allocation (IPA) technical to add static/dynamic 
> > power model for binding CPU thermal zone.
> > The power allocator governor allocates power budget to control CPU 
> > temperature.
> > 
> > Power Allocator governor is able to keep SOC temperature within a defined 
> > temperature range to avoid SOC overheat and keep it's performance. 
> > mt8173-cpufreq.c need to register its' own power model with power allocator 
> > thermal governor, so that power allocator governor can allocates suitable 
> > power budget to control CPU temperature.
> > 
> > PATCH1 is base on
> > https://patchwork.kernel.org/patch/7034601/
> > 
> > PATCH2 is base on Sascha's thermal driver V9
> > https://patchwork.kernel.org/patch/7249821/
> > https://patchwork.kernel.org/patch/7249861/
> > https://patchwork.kernel.org/patch/7249891/
> > 
> > Change since V1:
> > include mt8171.h and sort header file for mt8173.dtsi
> > 
> > Change since V2:
> > Move dynamic/static power model in device tree
> > 
> > Dawei.Chien (2):
> >   thermal: mediatek: Add cpu power cooling model.
> >   arm64: dts: mt8173: Add thermal zone node for mt8173.
> 
> Sorry for being extremely late in reviewing this stuff. You are
> already on v3 and I haven't reviewed it once. Mostly due to bad timing
> of my holidays and other work pressure.

You're welcome, truly thank you for your kindly reviewing

> Now, there are few things that I feel are not properly addressed here,
> and I may be wrong:
> - Where are the bindings for static-power-points and
>   dynamic-power-coefficient. Sorry I failed to see them in this or
>   other series you mentioned.

Please refer to following document (2-1,2-2) for dynamic-power &
static-power in detail. Besides, do I need to add another document for
our own MT8173 IC.
http://lxr.free-electrons.com/source/Documentation/thermal/cpu-cooling-api.txt

> - Even then, why should we be adding another table into DT for
>   voltage/power ? And not reuse and extend the opp-v2 stuff which is
>   already mainlined now.

We could reuse opp-v2 for static power points after OPPV2 back port to
our currently branch.
However, as far as I know, there is no "power" in opp.c (suck like
opp-hz) as far, so I need to add something in opp.c for my purpose, suck
like add power in _opp_add_static_v2, and add something for return
"power", right? I may be wrong, please kindly give me your suggestion,
thank you.

Actually, I am considering to remove the part of static power point
since it is optional for Power Model. Could you agree with this?
> - There are few issues with the code as well, but I want to see where
>   the bindings should go first. And then only discuss the code
>   further.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT pull] timer updates for 4.4

[Thomas Gleixner]

Linus,

please pull the latest timers-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-core-for-linus

The timer departement provides:

  - More y2038 work in the area of ntp and pps.

  - Optimization of posix cpu timers

  - New time related selftests

  - Some new clocksource drivers

  - The usual pile of fixes, cleanups and improvements


Thanks,

tglx

-->
Alexey Klimov (4):
  clocksource/drivers/em_sti: Remove unneeded memset()s
  clocksource/drivers/sh_cmt: Remove unneeded memset() in sh_cmt_setup()
  clocksource/drivers/h8300_*: Remove unneeded memset()s
  clocksource/drivers/exynos_mct: Use container_of() instead of 
this_cpu_ptr()

Arnd Bergmann (5):
  ntp/pps: use timespec64 for hardpps()
  ntp/pps: replace getnstime_raw_and_real with 64-bit version
  ntp: use timespec64 in sync_cmos_clock
  ntp/pps: use y2038 safe types in pps_event_time
  net: sfc: avoid using timespec

Daniel Lezcano (1):
  clockevents/drivers/mtk: Fix spurious interrupt leading to crash

Dmitry Vyukov (1):
  timers: Fix data race in timer_stats_account_timer()

Guillaume Gomez (1):
  clocksource: Remove return statement from void functions

Jan Beulich (1):
  timers/x86/hpet: Type adjustments

Jason A. Donenfeld (1):
  timeconst: Update path in comment

Jason Low (4):
  posix_cpu_timer: Optimize fastpath_timer_check()
  posix_cpu_timer: Check thread timers only when there are active thread 
timers
  posix_cpu_timer: Convert cputimer->running to bool
  posix_cpu_timer: Reduce unnecessary sighand lock contention

John Stultz (1):
  timers, kselftest: Add 'adjtick' test to validate adjtimex() tick 
adjustments

Lucas Stach (1):
  clocksource/drivers/imx: Allow timer irq affinity change

Marc Gonzalez (1):
  clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Rasmus Villemoes (1):
  timers: Use __fls in apply_slack()

Russell King (1):
  clocksource/drivers/armada-370-xp: Implement ARM delay timer

Yingjoe Chen (1):
  clocksource/drivers/mediatek: Use GPT as sched clock source

Zhen Lei (1):
  time: Fix spelling in comments


 arch/x86/include/asm/hpet.h  |   6 +-
 arch/x86/kernel/early-quirks.c   |   2 +-
 arch/x86/kernel/hpet.c   |  29 ++--
 arch/x86/kernel/quirks.c |   2 +-
 drivers/clocksource/Kconfig  |   4 +
 drivers/clocksource/Makefile |   1 +
 drivers/clocksource/em_sti.c |   2 -
 drivers/clocksource/exynos_mct.c |  12 +-
 drivers/clocksource/h8300_timer16.c  |   1 -
 drivers/clocksource/h8300_timer8.c   |   1 -
 drivers/clocksource/h8300_tpu.c  |   1 -
 drivers/clocksource/mtk_timer.c  |  26 ++--
 drivers/clocksource/sh_cmt.c |   1 -
 drivers/clocksource/tango_xtal.c |  66 +
 drivers/clocksource/time-armada-370-xp.c |  14 ++
 drivers/clocksource/timer-imx-gpt.c  |   3 +-
 drivers/net/ethernet/sfc/ptp.c   |  30 ++---
 drivers/pps/kapi.c   |   4 +-
 include/linux/init_task.h|   3 +-
 include/linux/pps_kernel.h   |  16 +--
 include/linux/sched.h|   9 +-
 include/linux/timekeeping.h  |   4 +-
 include/linux/timex.h|   2 +-
 kernel/fork.c|   2 +-
 kernel/time/clocksource.c|   7 +-
 kernel/time/hrtimer.c|   2 +-
 kernel/time/ntp.c|  16 +--
 kernel/time/ntp_internal.h   |   2 +-
 kernel/time/posix-cpu-timers.c   |  63 ++---
 kernel/time/timeconst.bc |   2 +-
 kernel/time/timekeeping.c|  18 +--
 kernel/time/timer.c  |  13 +-
 tools/testing/selftests/timers/Makefile  |   3 +-
 tools/testing/selftests/timers/adjtick.c | 221 +++
 34 files changed, 468 insertions(+), 120 deletions(-)
 create mode 100644 drivers/clocksource/tango_xtal.c
 create mode 100644 tools/testing/selftests/timers/adjtick.c

diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 5fa9fb0f8809..cc285ec4b2c1 100644
--- a/arch/x86/include/asm/hpet.h
+++ b/arch/x86/include/asm/hpet.h
@@ -63,10 +63,10 @@
 /* hpet memory map physical address */
 extern unsigned long hpet_address;
 extern unsigned long force_hpet_address;
-extern int boot_hpet_disable;
+extern bool boot_hpet_disable;
 extern u8 hpet_blockid;
-extern int hpet_force_user;
-extern u8 hpet_msi_disable;
+extern bool hpet_force_user;
+extern bool hpet_msi_disable;
 extern int is_hpet_enabled(void);
 extern int hpet_enable(void);
 extern void hpet_disable(void);
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 9f9cc682e561..db9a675e751b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -584,7 

[GIT PULL] GPIO changes for the v4.4 kernel cycle

[Linus Walleij]

Hi Linus,

here is the bulk of GPIO changes for the v4.4 development cycle.
The details are in the signed tag as usual.

The only changes hitting outside drivers/gpio are in the pin control
subsystem and these seem to have settled nicely in linux-next.

Development mistakes and catfights are nicely documented in the
reverts as you can see. The outcome of the ABI fight is that we're
working on a chardev ABI for GPIO now, where hope to show results
for the v4.5 kernel.

Please pull it in!

Yours,
Linus Walleij


The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:

  Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.4-1

for you to fetch changes up to 0963670aeaec2287aa263daa0d41384d4dcd5292:

  gpio: fix up SPI submenu (2015-11-01 10:50:19 +0100)


This is the bulk of GPIO changes for v4.4:

GPIO core:
- Define and handle flags for open drain/open collector
  and open source/open emitter, also know as "single-ended"
  configurations.
- Generic request/free operations that handle calling out
  to the (optional) pin control backend.
- Some refactoring related to an ABI change that did not
  happen, yet provide useful.
- Added a real-time compliance checklist. Many GPIO chips
  have irqchips, and need to think this over with the RT
  patches going upstream.
- Restructure, fix and clean up Kconfig menus a bit.

New drivers:
- New driver for AMD Promony.
- New driver for ACCES 104-IDIO-16, a port-mapped I/O
  card, ISA-style. Very retro.

Subdriver changes:
- OMAP changes to handle real time requirements.
- Handle trigger types for edge and level IRQs on PL061
  properly. As this hardware is very common it needs to
  set a proper example for others to follow.
- Some container_of() cleanups.
- Delete the unused MSM driver in favor of the driver that
  is embedded inside the pin control driver.
- Cleanup of the ath79 GPIO driver used by many, many
  OpenWRT router targets.
- A consolidated IT87xx driver replacing the earlier
  very specific IT8761e driver.
- Handle the TI TCA9539 in the PCA953x driver. Also
  handle ACPI devices in this subdriver.
- Drop xilinx arch dependencies as these FPGAs seem to
  profilate over a few different architectures. MIPS and
  ARM come to mind.


Alban Bedel (2):
  gpio: ath79: Convert to the state container design pattern
  gpio: MAINTAINERS: Add an entry for the ATH79 GPIO driver

Andy Shevchenko (2):
  gpio: pca953x: store driver_data for future use
  gpio: pca953x: support ACPI devices found on Galileo Gen2

Dan Carpenter (1):
  gpio: pl061: returning with lock held in pl061_irq_type()

Diego Elio Pettenò (1):
  gpio: add GPIO support for IT87xx, replacing gpio-it8761e

Dirk Behme (1):
  gpio: gpiolib: don't compare an unsigned for >= 0

Grygorii Strashko (4):
  gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
  gpio: omap: convert to use generic irq handler
  gpio: omap: fix static checker warning
  gpio: add a real time compliance notes

Guenter Roeck (1):
  gpio: generic: Revert to old error handling in bgpio_map

Heiner Kallweit (3):
  gpio: generic: improve error handling in bgpio_map
  gpio: generic: modernize remapping
  gpio: generic: use error pointers

Jonas Gorski (5):
  gpiolib: provide generic request/free implementations
  gpio: replace trivial implementations of request/free with generic one
  gpio: gpio-xz: use the generic request/free implementations
  gpio: pl061: use the generic request/free implementations
  pinctrl: replace trivial implementations of gpio_chip request/free

Julia Lawall (1):
  gpio: max730x: eliminate double free

Kamlakant Patel (1):
  gpio: xlp: Convert to use gpiolib irqchip helpers

Laurent Pinchart (2):
  gpiolib: Split GPIO flags parsing and GPIO configuration
  gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag

Linus Walleij (17):
  gpio: keep the GPIO line names internal
  gpio: pl061: detail IRQ trigger handling
  gpio: etraxfs: use container_of() to get state container
  gpio: altera: use container_of() to get state container
  gpio: sx150x: use container_of() to get state container
  gpio: vf610: use container_of() to get state container
  gpio: zynq: use container_of() to get state container
  gpio: add DT bindings for existing consumer flags
  Revert "gpio-sysfs: Use gpio descriptor name instead of gpiochip
names array"
  gpio: pl061: assign the apropriate handler for irqs
  gpio: add a real time compliance checklist
  Revert "gpio: add a real time compliance checklist"
  gpio: group port-mapped I/O drivers in a menu
  gpio: dt-bindings: document the official use of "ngpios"
  gpio: drop surplus X8

Re: [RFC v2 5/5] drm/dsi: Get DSI host by DT device node

[Andrzej Hajda]

On 10/06/2015 11:24 AM, Archit Taneja wrote:
> mipi_dsi_devices are inherently aware of their host because they
> share a parent-child hierarchy in the device tree.
>
> Non-dsi drivers that create a dummy dsi device don't have this data.
> In order to get this information, they require to a phandle to the dsi
> host in the device tree.
>
> Maintain a list of all the hosts DSI that are currently registered.
>
> This list will be used to find the mipi_dsi_host corresponding to the
> device_node passed in of_find_mipi_dsi_host_by_node.
>
> Signed-off-by: Archit Taneja 

Looks OK, beside lack of documentation, after fixing it you can add
Reviewed-by: Andrzej Hajda 

Regards
Andrzej

> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 30 ++
>  include/drm/drm_mipi_dsi.h |  2 ++
>  2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index cbb7373..c51d73e 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -216,6 +216,28 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, 
> struct device_node *node)
>   return mipi_dsi_device_new(host, &info);
>  }
>  
> +static DEFINE_MUTEX(host_lock);
> +static LIST_HEAD(host_list);
> +
> +struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node)
> +{
> + struct mipi_dsi_host *host;
> +
> + mutex_lock(&host_lock);
> +
> + list_for_each_entry(host, &host_list, list) {
> + if (host->dev->of_node == node) {
> + mutex_unlock(&host_lock);
> + return host;
> + }
> + }
> +
> + mutex_unlock(&host_lock);
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
> +
>  int mipi_dsi_host_register(struct mipi_dsi_host *host)
>  {
>   struct device_node *node;
> @@ -227,6 +249,10 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
>   of_mipi_dsi_device_add(host, node);
>   }
>  
> + mutex_lock(&host_lock);
> + list_add_tail(&host->list, &host_list);
> + mutex_unlock(&host_lock);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(mipi_dsi_host_register);
> @@ -243,6 +269,10 @@ static int mipi_dsi_remove_device_fn(struct device *dev, 
> void *priv)
>  void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
>  {
>   device_for_each_child(host->dev, NULL, mipi_dsi_remove_device_fn);
> +
> + mutex_lock(&host_lock);
> + list_del_init(&host->list);
> + mutex_unlock(&host_lock);
>  }
>  EXPORT_SYMBOL(mipi_dsi_host_unregister);
>  
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 68f49f4..15d3068 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -100,10 +100,12 @@ struct mipi_dsi_host_ops {
>  struct mipi_dsi_host {
>   struct device *dev;
>   const struct mipi_dsi_host_ops *ops;
> + struct list_head list;
>  };
>  
>  int mipi_dsi_host_register(struct mipi_dsi_host *host);
>  void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
> +struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node 
> *node);
>  
>  /* DSI mode flags */
>  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.

[dawei chien]

On Wed, 2015-10-28 at 21:09 +0530, Viresh Kumar wrote:
> On 22-10-15, 20:02, Dawei Chien wrote:
> > Add thermal zone node to mt8173.dtsi.
> > 
> > Signed-off-by: Dawei Chien 
> > ---
> > This patch is base on
> > https://patchwork.kernel.org/patch/7249821/
> > https://patchwork.kernel.org/patch/7249861/
> > https://patchwork.kernel.org/patch/7249891/
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi |   90 
> > ++
> >  1 file changed, 90 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 3b18f37..eaf12bf 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include "mt8173-pinfunc.h"
> >  
> >  / {
> > @@ -54,6 +55,18 @@
> > reg = <0x000>;
> > enable-method = "psci";
> > cpu-idle-states = <&CPU_SLEEP_0>;
> > +   static-power-points = <
> > +   859000  43
> > +   908000  52
> > +   983000  86
> > +   1009000 123
> > +   1028000 138
> > +   1083000 172
> > +   1110900 180
> > +   1125000 192
> 
> What's the unit of power here? Is this power accurate? Or just a
> number representing the power ?

The unit is mW. This power was measured by tools, but it may be not
accurate enough since this tool has a error range.

> > +   >;
> > +   dynamic-power-coefficient = <263>;
> > +   #cooling-cells = <2>;
> > };
> 
> @Rob: Looks like another good candidate for the OPP-v2 table? Power.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the rdma tree with Linus' tree

[Sagi Grimberg]

Hi Doug,

Today's linux-next merge of the rdma tree got a conflict in:

   net/sunrpc/xprtrdma/svc_rdma_recvfrom.c

between commit:

   c91aed989694 ("svcrdma: handle rdma read with a non-zero initial page 
offset")

from Linus' tree and commit:

   412a15c0fe53 ("svcrdma: Port to new memory registration API")

from the rdma tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).



Hi Stephen,

The fix looks correct to me.

Cheers,
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 0/4] PCI: rcar: Add support for ARM64 and multiple instances

[Phil Edworthy]

Hi Bjorn,

On 30 October 2015 13:32, Bjorn wrote:
> On Fri, Oct 30, 2015 at 09:00:20AM +, Phil Edworthy wrote:
> > Hi Bjorn,
> >
> > On 30 October 2015 07:24, Phil wrote:
> > > On 30 October 2015 07:19, Phil wrote
> > > > On 29 October 2015 23:03, Bjorn wrote:
> > > > > On Thu, Oct 29, 2015 at 07:48:00PM +0100, Wolfram Sang wrote:
> > > > > > On Thu, Oct 29, 2015 at 04:44:06PM +, Phil Edworthy wrote:
> > > > > > > Hi Wolfram,
> > > > > > >
> > > > > > > On 29 October 2015 16:40, Wolfram wrote:
> > > > > > > > > Ouch, my bad. I have been working with our out-of-tree BSP for
> the
> > > > > Salvator-X
> > > > > > > > board on
> > > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git,
> > > rcar-
> > > > > 3.0.2
> > > > > > > > tag along
> > > > > > > > > with some patches from colleagues. I hadn't noticed this 
> > > > > > > > > patch:
> > > > > > > >
> > > > > > > > Thanks! Any plans for pushing this upstream? We will have the 
> > > > > > > > build
> > > error
> > > > > > > > otherwise...
> > > > > > > After some digging, that patch won't be accepted upstream. I'm
> looking
> > > into
> > > > > how the
> > > > > > > driver can be modified so it doesn't need to call this, but I 
> > > > > > > don't expect
> a
> > > > small
> > > > > or
> > > > > > > imminent fix.
> > > > > >
> > > > > > Yes, I'd think so, too. However, a fix for 4.4 would be needed to
> > > > > > prevent having a final release with a build error.
> > > > >
> > > > > I'm thinking I should drop my pci/host-rcar branch until we
> > > > > have a fix for this.  It currently contains:
> > > > >
> > > > >   9ac724f20774 PCI: rcar: Fix I/O offset for multiple host bridges
> > > > >   7d75b413f5c6 PCI: rcar: Set root bus nr to that provided in DT
> > > > >   4c22eab88c68 PCI: rcar: Remove dependency on ARM-specific struct
> hw_pci
> > > > >   ef18d2e55ea0 PCI: rcar: Make PCI aware of the I/O resources
> > > > >
> > > > > Is that right?  Last I heard, Linus expects to release v4.3 on Sunday,
> > > > > so we really don't have much time to sort this out.
> > > > The simple thing is to re-add Geert's patch to stop this driver being 
> > > > built for
> > > > arm64.
> > > Btw, it's this one: https://patchwork.ozlabs.org/patch/512040/
> > It's worth mentioning that Geert's patch stops both the rcar-pcie driver 
> > and the
> > rcar-pci-gen2 driver from being built on arm64 due to build failures for 
> > both of
> > them. The rcar-pci-gen2 driver is not for R-Car Gen3 devices, and so should 
> > not
> > be built for arm64. The rcar-pcie driver will be used on R-Car Gen3 devices.
> >
> > So if we don't use Geert's patch, I need to fix the rcar-pcie driver so it 
> > doesn't
> > use pci_ioremap_io(), _and_ fix Kconfig so that the rcar-pci-gen2 driver 
> > doesn't
> > get built on arm64.
> > Let's just use Geert's patch for now.
> 
> OK, I re-added Geert's patch.  I split it into two, one for
> rcar-pci-gen2 and another for rcar-pcie, to help me keep things
> straight.  If I understand correctly,
> 
>   - rcar-pci-gen2 depends on the ARM-specific pci_sys_data, and I
> don't have anything queued to address that.
Correct, but you don't need anything other than Geert's patch to
ensure it's not built for arm64.

>   - rcar-pcie depended on the ARM-specific pci_sys_data and
> pci_ioremap_io().  Your patches remove the pci_sys_data
> dependency, and it sounds like future changes will remove the
> pci_ioremap_io() dependency.
That's correct, hopefully I'll have a patch shortly.
Thanks for taking care of this.

 
> The result is in my pci/host-rcar branch:
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-rcar
I haven't tested this yet, but I have looked them over and they look ok.

Thanks
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 11/20] ARC: [plat-eznps] Add eznps platform

[Vineet Gupta]

On Saturday 31 October 2015 06:45 PM, Noam Camus wrote:
> From: Noam Camus 
> 
> This platform include boards:
>   Hardware Emulator (HE)
>   Simulator based upon nSIM.
> 
> Signed-off-by: Noam Camus 
> ---
>  MAINTAINERS |6 +
>  arch/arc/plat-eznps/Kconfig |   34 
>  arch/arc/plat-eznps/Makefile|7 +
>  arch/arc/plat-eznps/entry.S |   76 +


When trying to build with 2015.06 BE tools,

../arch/arc/plat-eznps/entry.S: Assembler messages:
../arch/arc/plat-eznps/entry.S:51: Error: bad instruction `sr
(1<<28),[(0xF800+0x024)]'
make[3]: *** [arch/arc/plat-eznps/entry.o] Error 1
make[2]: *** [arch/arc/plat-eznps] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH net-next 0/6] net: dsa: mv88e6060: cleanup and fix setup

[Neil Armstrong]

This patchset introduces somes fixes and a registers addressing cleanup for
the mv88e6060 DSA driver.

The first patch removes the poll_link as mv88e6xxx.
The 3 following patchs fixes the setup in regards of the datasheet.
The 2 last patches introduces a clean header and replaces all magic values.

Neil Armstrong (6):
  net: dsa: mv88e6060: remove poll_link callback
  net: dsa: mv88e6060: use the correct InitReady bit
  net: dsa: mv88e6060: use the correct MaxFrameSize bit
  net: dsa: mv88e6060: use the correct bit shift for mac0
  net: dsa: mv88e6060: add register defines header file
  net: dsa: mv88e6060: replace magic values with register defines

 drivers/net/dsa/mv88e6060.c | 114 +++-
 drivers/net/dsa/mv88e6060.h | 108 +
 2 files changed, 146 insertions(+), 76 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6060.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH net-next 1/6] net: dsa: mv88e6060: remove poll_link callback

[Neil Armstrong]

As of mv88e6xxx remove the poll_link callback since the link
state change polling is now handled by the phylib.

Tested on a mv88e6060 B0 device with a TI DM816X SoC.

Suggested-by: Andrew Lunn 
Signed-off-by: Neil Armstrong 
---
 drivers/net/dsa/mv88e6060.c | 49 -
 1 file changed, 49 deletions(-)

diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 9093577..6885ef5 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -225,54 +225,6 @@ mv88e6060_phy_write(struct dsa_switch *ds, int port, int 
regnum, u16 val)
return reg_write(ds, addr, regnum, val);
 }

-static void mv88e6060_poll_link(struct dsa_switch *ds)
-{
-   int i;
-
-   for (i = 0; i < DSA_MAX_PORTS; i++) {
-   struct net_device *dev;
-   int uninitialized_var(port_status);
-   int link;
-   int speed;
-   int duplex;
-   int fc;
-
-   dev = ds->ports[i];
-   if (dev == NULL)
-   continue;
-
-   link = 0;
-   if (dev->flags & IFF_UP) {
-   port_status = reg_read(ds, REG_PORT(i), 0x00);
-   if (port_status < 0)
-   continue;
-
-   link = !!(port_status & 0x1000);
-   }
-
-   if (!link) {
-   if (netif_carrier_ok(dev)) {
-   netdev_info(dev, "link down\n");
-   netif_carrier_off(dev);
-   }
-   continue;
-   }
-
-   speed = (port_status & 0x0100) ? 100 : 10;
-   duplex = (port_status & 0x0200) ? 1 : 0;
-   fc = ((port_status & 0xc000) == 0xc000) ? 1 : 0;
-
-   if (!netif_carrier_ok(dev)) {
-   netdev_info(dev,
-   "link up, %d Mb/s, %s duplex, flow control 
%sabled\n",
-   speed,
-   duplex ? "full" : "half",
-   fc ? "en" : "dis");
-   netif_carrier_on(dev);
-   }
-   }
-}
-
 static struct dsa_switch_driver mv88e6060_switch_driver = {
.tag_protocol   = DSA_TAG_PROTO_TRAILER,
.probe  = mv88e6060_probe,
@@ -280,7 +232,6 @@ static struct dsa_switch_driver mv88e6060_switch_driver = {
.set_addr   = mv88e6060_set_addr,
.phy_read   = mv88e6060_phy_read,
.phy_write  = mv88e6060_phy_write,
-   .poll_link  = mv88e6060_poll_link,
 };

 static int __init mv88e6060_init(void)
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH net-next 4/6] net: dsa: mv88e6060: use the correct bit shift for mac0

[Neil Armstrong]

According to the mv88e6060 datasheet, the first mac byte must
be at position 9 instead of 8 since the bit 8 is used to select
if the mac address must differ for each port for Pause frames.
Use the correct shift and set the same mac address for all port.

Signed-off-by: Neil Armstrong 
---
 drivers/net/dsa/mv88e6060.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index ba1899e..1ccfd7a 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -188,7 +188,8 @@ static int mv88e6060_setup(struct dsa_switch *ds)

 static int mv88e6060_set_addr(struct dsa_switch *ds, u8 *addr)
 {
-   REG_WRITE(REG_GLOBAL, 0x01, (addr[0] << 8) | addr[1]);
+   /* Use the same MAC Address as FD Pause frames for all ports */
+   REG_WRITE(REG_GLOBAL, 0x01, (addr[0] << 9) | addr[1]);
REG_WRITE(REG_GLOBAL, 0x02, (addr[2] << 8) | addr[3]);
REG_WRITE(REG_GLOBAL, 0x03, (addr[4] << 8) | addr[5]);

-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/