[PATCH -v2 6/6] locking,netfilter: Fix nf_conntrack_lock()

nf_conntrack_lock{,_all}() is borken as it misses a bunch of memory barriers to order the whole global vs local locks scheme. Even x86 (and other TSO archs) are affected. Signed-off-by: Peter Zijlstra (Intel) --- net/netfilter/nf_conntrack_core.c | 18 +-

[PATCH -v2 6/6] locking,netfilter: Fix nf_conntrack_lock()

nf_conntrack_lock{,_all}() is borken as it misses a bunch of memory barriers to order the whole global vs local locks scheme. Even x86 (and other TSO archs) are affected. Signed-off-by: Peter Zijlstra (Intel) --- net/netfilter/nf_conntrack_core.c | 18 +- 1 file changed, 17

[PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

This patch updates/fixes all spin_unlock_wait() implementations. The update is in semantics; where it previously was only a control dependency, we now upgrade to a full load-acquire to match the store-release from the spin_unlock() we waited on. This ensures that when spin_unlock_wait() returns,

[PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

This patch updates/fixes all spin_unlock_wait() implementations. The update is in semantics; where it previously was only a control dependency, we now upgrade to a full load-acquire to match the store-release from the spin_unlock() we waited on. This ensures that when spin_unlock_wait() returns,

[PATCH -v2 3/6] locking: Introduce smp_acquire__after_ctrl_dep

Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 15 ++- ipc/sem.c| 14 ++ 2 files changed, 12

[PATCH -v2 3/6] locking: Introduce smp_acquire__after_ctrl_dep

Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 15 ++- ipc/sem.c| 14 ++ 2 files changed, 12 insertions(+), 17 deletions(-)

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 26/05/16 12:42, Dmitry Osipenko wrote: > On 26.05.2016 11:42, Jon Hunter wrote: >> >> On 25/05/16 19:51, Dmitry Osipenko wrote: >>> On 25.05.2016 18:09, Jon Hunter wrote: >> >> ... >> If you are able to reproduce this on v3.18, then it would be good if you could trace the CCF

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 26/05/16 12:42, Dmitry Osipenko wrote: > On 26.05.2016 11:42, Jon Hunter wrote: >> >> On 25/05/16 19:51, Dmitry Osipenko wrote: >>> On 25.05.2016 18:09, Jon Hunter wrote: >> >> ... >> If you are able to reproduce this on v3.18, then it would be good if you could trace the CCF

Re: [PATCH 1/6] mm, oom: do not loop over all tasks if there are no external tasks sharing mm

Michal Hocko wrote: > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5bb2f7698ad7..0e33e912f7e4 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -820,6 +820,13 @@ void oom_kill_process(struct oom_control *oc, struct > task_struct *p, > task_unlock(victim); > > /* > +

Re: [PATCH 1/6] mm, oom: do not loop over all tasks if there are no external tasks sharing mm

Michal Hocko wrote: > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5bb2f7698ad7..0e33e912f7e4 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -820,6 +820,13 @@ void oom_kill_process(struct oom_control *oc, struct > task_struct *p, > task_unlock(victim); > > /* > +

[PATCH V2] fs: ubifs: Replace kmem_cache_alloc/memset with kmem_cache_zalloc

Code is more readable when using kmem_cache_zalloc instead of kmem_cache_alloc/memset. Signed-off-by: Salah Triki --- fs/ubifs/super.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 7034995..f509200 100644

[PATCH V2] fs: ubifs: Replace kmem_cache_alloc/memset with kmem_cache_zalloc

Code is more readable when using kmem_cache_zalloc instead of kmem_cache_alloc/memset. Signed-off-by: Salah Triki --- fs/ubifs/super.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 7034995..f509200 100644 --- a/fs/ubifs/super.c

[PATCH -v2 1/6] locking: Replace smp_cond_acquire with smp_cond_load_acquire

This new form allows using hardware assisted waiting. Requested-by: Will Deacon Suggested-by: Linus Torvalds Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 25 +++--

[PATCH -v2 1/6] locking: Replace smp_cond_acquire with smp_cond_load_acquire

This new form allows using hardware assisted waiting. Requested-by: Will Deacon Suggested-by: Linus Torvalds Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 25 +++-- kernel/locking/qspinlock.c | 12 ++-- kernel/sched/core.c|8

[PATCH -v2 2/6] locking: Introduce cmpwait()

Provide the cmpwait() primitive, which will 'spin' wait for a variable to change and use it to implement smp_cond_load_acquire(). This primitive can be implemented with hardware assist on some platforms (ARM64, x86). Suggested-by: Will Deacon Signed-off-by: Peter Zijlstra

[PATCH -v2 2/6] locking: Introduce cmpwait()

Provide the cmpwait() primitive, which will 'spin' wait for a variable to change and use it to implement smp_cond_load_acquire(). This primitive can be implemented with hardware assist on some platforms (ARM64, x86). Suggested-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) ---

[PATCH -v2 0/6] spin_unlock_wait borkage

This version rewrites all spin_unlock_wait() implementations to provide the acquire order against the spin_unlock() release we wait on, ensuring we can fully observe the critical section we waited on. It pulls in the smp_cond_acquire() rewrite because it introduces a lot more users of it. All

[PATCH -v2 0/6] spin_unlock_wait borkage

This version rewrites all spin_unlock_wait() implementations to provide the acquire order against the spin_unlock() release we wait on, ensuring we can fully observe the critical section we waited on. It pulls in the smp_cond_acquire() rewrite because it introduces a lot more users of it. All

[PATCH -v2 5/6] locking: Update spin_unlock_wait users

With the modified semantics of spin_unlock_wait() a number of explicit barriers can be removed. And update the comment for the do_exit() usecase, as that was somewhat stale/obscure. Signed-off-by: Peter Zijlstra (Intel) --- ipc/sem.c |1 - kernel/exit.c |

[PATCH -v2 5/6] locking: Update spin_unlock_wait users

With the modified semantics of spin_unlock_wait() a number of explicit barriers can be removed. And update the comment for the do_exit() usecase, as that was somewhat stale/obscure. Signed-off-by: Peter Zijlstra (Intel) --- ipc/sem.c |1 - kernel/exit.c |8 ++--

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, 2016-05-26 at 16:59 +0300, Vladimir Davydov wrote: > On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > > On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > > > > On Tue, 2016-05-24 at 19:13

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, 2016-05-26 at 16:59 +0300, Vladimir Davydov wrote: > On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > > On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > > > > On Tue, 2016-05-24 at 19:13

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 23:01:06 +0200 > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > >> From: Arnd Bergmann > >> Date: Wed, 25 May 2016 22:47:33 +0200 > >>

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 23:01:06 +0200 > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > >> From: Arnd Bergmann > >> Date: Wed, 25 May 2016 22:47:33 +0200 > >> > >> > If we use the normal

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

Michal Hocko wrote: > +/* > + * Checks whether the given task is dying or exiting and likely to > + * release its address space. This means that all threads and processes > + * sharing the same mm have to be killed or exiting. > + */ > +static inline bool task_will_free_mem(struct task_struct

Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem

Michal Hocko wrote: > +/* > + * Checks whether the given task is dying or exiting and likely to > + * release its address space. This means that all threads and processes > + * sharing the same mm have to be killed or exiting. > + */ > +static inline bool task_will_free_mem(struct task_struct

How should I use kernel-defined i2c structs in this driver

Could anybody please give a hint - which kernel-defined i2c objects, and how many of them, I need to define and use to substitute these driver-defined functions i2c_read(), i2c_write() ? https://github.com/bluecherrydvr/linux/blob/release/tw5864/1.16/drivers/media/pci/tw5864/tw5864-config.c In a

How should I use kernel-defined i2c structs in this driver

Could anybody please give a hint - which kernel-defined i2c objects, and how many of them, I need to define and use to substitute these driver-defined functions i2c_read(), i2c_write() ? https://github.com/bluecherrydvr/linux/blob/release/tw5864/1.16/drivers/media/pci/tw5864/tw5864-config.c In a

Re: [PATCH] fs: ubifs: Replace kmem_cache_alloc/memset with kmem_cache_zalloc

Am 26.05.2016 um 00:04 schrieb Salah Triki: > Use kmem_cache_zalloc instead of kmem_cache_alloc/memset. > > Signed-off-by: Salah Triki > --- > fs/ubifs/super.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c >

Re: [PATCH] fs: ubifs: Replace kmem_cache_alloc/memset with kmem_cache_zalloc

Am 26.05.2016 um 00:04 schrieb Salah Triki: > Use kmem_cache_zalloc instead of kmem_cache_alloc/memset. > > Signed-off-by: Salah Triki > --- > fs/ubifs/super.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c > index

Re: [RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request

Comments inlined. In general the most concerning bit is the need for memory allocation in the IO path (see comment/question below near call to sg_alloc_table). In DM targets we make heavy use of .ctr preallocated memory and/or per-bio-data to avoid memory allocations in the IO path. On Wed, May

Re: [RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request

Comments inlined. In general the most concerning bit is the need for memory allocation in the IO path (see comment/question below near call to sg_alloc_table). In DM targets we make heavy use of .ctr preallocated memory and/or per-bio-data to avoid memory allocations in the IO path. On Wed, May

[PATCH] oom_reaper: close race with exiting task

From: Michal Hocko Tetsuo has reported: [ 74.453958] Out of memory: Kill process 443 (oleg's-test) score 855 or sacrifice child [ 74.456234] Killed process 443 (oleg's-test) total-vm:493248kB, anon-rss:423880kB, file-rss:4kB, shmem-rss:0kB [ 74.459219] sh invoked

[PATCH] oom_reaper: close race with exiting task

From: Michal Hocko Tetsuo has reported: [ 74.453958] Out of memory: Kill process 443 (oleg's-test) score 855 or sacrifice child [ 74.456234] Killed process 443 (oleg's-test) total-vm:493248kB, anon-rss:423880kB, file-rss:4kB, shmem-rss:0kB [ 74.459219] sh invoked oom-killer:

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > > > On Tue, 2016-05-24 at 19:13 +0300, Vladimir Davydov wrote: > > > > On Tue, May 24, 2016 at

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > On Tue, May 24, 2016 at 01:04:33PM -0700, Eric Dumazet wrote: > > > On Tue, 2016-05-24 at 19:13 +0300, Vladimir Davydov wrote: > > > > On Tue, May 24, 2016 at

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/26/2016 12:51 AM, Neil Armstrong wrote: Add watchdog specific driver for Amlogic Meson GXBB SoC. Wondering - why RFC ? Signed-off-by: Neil Armstrong --- drivers/watchdog/Makefile | 1 + drivers/watchdog/meson_gxbb_wdt.c | 287

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/26/2016 12:51 AM, Neil Armstrong wrote: Add watchdog specific driver for Amlogic Meson GXBB SoC. Wondering - why RFC ? Signed-off-by: Neil Armstrong --- drivers/watchdog/Makefile | 1 + drivers/watchdog/meson_gxbb_wdt.c | 287 ++ 2

Re: [RFC][PATCH 3/3] locking,netfilter: Fix nf_conntrack_lock()

On Tue, May 24, 2016 at 10:41:43PM +0200, Manfred Spraul wrote: > >--- a/net/netfilter/nf_conntrack_core.c > >+++ b/net/netfilter/nf_conntrack_core.c > >@@ -74,7 +74,18 @@ void nf_conntrack_lock(spinlock_t *lock) > > spin_lock(lock); > > while (unlikely(nf_conntrack_locks_all)) { > >

Re: [RFC][PATCH 3/3] locking,netfilter: Fix nf_conntrack_lock()

On Tue, May 24, 2016 at 10:41:43PM +0200, Manfred Spraul wrote: > >--- a/net/netfilter/nf_conntrack_core.c > >+++ b/net/netfilter/nf_conntrack_core.c > >@@ -74,7 +74,18 @@ void nf_conntrack_lock(spinlock_t *lock) > > spin_lock(lock); > > while (unlikely(nf_conntrack_locks_all)) { > >

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

Hi, yury The coredump is usable in our platform. It miss the following definition: +#define compat_elf_greg_t elf_greg_t +#define compat_elf_gregset_t elf_gregset_t And it leads to the wrong register save in core dump. After apply this patch, gdb could debug core dump files. Here is the

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

Hi, yury The coredump is usable in our platform. It miss the following definition: +#define compat_elf_greg_t elf_greg_t +#define compat_elf_gregset_t elf_gregset_t And it leads to the wrong register save in core dump. After apply this patch, gdb could debug core dump files. Here is the

[PATCH] clk: rockchip: fix cclk error handing

It maybe due to a copy-paste error the error handing should be cclk not clk. Reported-by: Lin Huang Signed-off-by: Xing Zheng --- drivers/clk/rockchip/clk-cpu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] clk: rockchip: fix cclk error handing

It maybe due to a copy-paste error the error handing should be cclk not clk. Reported-by: Lin Huang Signed-off-by: Xing Zheng --- drivers/clk/rockchip/clk-cpu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/rockchip/clk-cpu.c

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/25/2016 02:30 PM, Matt Fleming wrote: > On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: >> >> I looked into this and this would be a large change also to parse tables >> and build lists. It occurred to me that this could all be taken care of >> if the early_memremap calls were changed to

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/25/2016 02:30 PM, Matt Fleming wrote: > On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: >> >> I looked into this and this would be a large change also to parse tables >> and build lists. It occurred to me that this could all be taken care of >> if the early_memremap calls were changed to

Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

[Jumping in the discussion at Bastien's request] On Thu, May 19, 2016 at 3:21 PM, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv wrote: >> Hi, >> >>> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of >>> Rafael J.

Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

[Jumping in the discussion at Bastien's request] On Thu, May 19, 2016 at 3:21 PM, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv wrote: >> Hi, >> >>> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of >>> Rafael J. Wysocki >>> Subject: Re: [RFC PATCH 1/2]

Re: [PATCH] watchdog: Add a device managed API for watchdog_register_device()

On 05/26/2016 01:31 AM, Neil Armstrong wrote: This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Neil Armstrong --- Documentation/driver-model/devres.txt | 3 +++ drivers/watchdog/watchdog_core.c

Re: [PATCH] watchdog: Add a device managed API for watchdog_register_device()

On 05/26/2016 01:31 AM, Neil Armstrong wrote: This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Neil Armstrong --- Documentation/driver-model/devres.txt | 3 +++ drivers/watchdog/watchdog_core.c | 36

Re: [PATCH v4] extcon: gpio: Add the support for Device tree bindings

Hi Venkat, There is some miscommunication. On previous my reply, I don't mean that the author of the patch[1] is changed from me to you. I'd like you to remain the original author(me) for the patch[1] without changing the author. [1] https://lkml.org/lkml/2015/10/21/8 - [PATCH v3] extcon: gpio:

Re: [PATCH v4] extcon: gpio: Add the support for Device tree bindings

Hi Venkat, There is some miscommunication. On previous my reply, I don't mean that the author of the patch[1] is changed from me to you. I'd like you to remain the original author(me) for the patch[1] without changing the author. [1] https://lkml.org/lkml/2015/10/21/8 - [PATCH v3] extcon: gpio:

Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On Thu, May 26, 2016 at 8:05 AM, loic pallardy wrote: > > > On 05/26/2016 02:46 PM, Rob Herring wrote: >> >> On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez >> wrote: >>> >>> On 25 May 2016 at 19:24, Rob Herring wrote:

Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On Thu, May 26, 2016 at 8:05 AM, loic pallardy wrote: > > > On 05/26/2016 02:46 PM, Rob Herring wrote: >> >> On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez >> wrote: >>> >>> On 25 May 2016 at 19:24, Rob Herring wrote: On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: > For a normal memory@ devicetree node, its reg property can contains more > memory blocks. > > Because we don't known how many memory blocks maybe contained, so we try > from index=0, increase 1 until error returned(the end). > >

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: > For a normal memory@ devicetree node, its reg property can contains more > memory blocks. > > Because we don't known how many memory blocks maybe contained, so we try > from index=0, increase 1 until error returned(the end). > >

Re: [PATCH v2] net: alx: use custom skb allocator

On Thu, 2016-05-26 at 16:41 +0800, Feng Tang wrote: > On Wed, May 25, 2016 at 07:53:41PM -0400, David Miller wrote: > > > > But now that we have at least two instances of this code we really > > need to put a common version somewhere. :-/ > > I agree, and furthermore I noticed there are some

Re: [PATCH v2] net: alx: use custom skb allocator

On Thu, 2016-05-26 at 16:41 +0800, Feng Tang wrote: > On Wed, May 25, 2016 at 07:53:41PM -0400, David Miller wrote: > > > > But now that we have at least two instances of this code we really > > need to put a common version somewhere. :-/ > > I agree, and furthermore I noticed there are some

Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On 05/26/2016 02:46 PM, Rob Herring wrote: On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez wrote: On 25 May 2016 at 19:24, Rob Herring wrote: On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote: This patch allows fine tuning

Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On 05/26/2016 02:46 PM, Rob Herring wrote: On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez wrote: On 25 May 2016 at 19:24, Rob Herring wrote: On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote: This patch allows fine tuning of the quads FS for audio clocks accuracy.

[PATCH v3] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v3: - rename DOC to rockchip,rk3399-max98357a-rt5514-da7219.txt - rename compatible to

[PATCH v3] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v3: - rename DOC to rockchip,rk3399-max98357a-rt5514-da7219.txt - rename compatible to rockchip,rk3399-max98357a-rt5514-da7219 - rename source

[PATCH] ASoC: mediatek: Change the order of MCLK clock configuration

Because MCLK opens later and closes earlier than codec, this patch changes the order of MCLK clock configuration. Signed-off-by: PC Liao --- sound/soc/mediatek/mtk-afe-pcm.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git

[PATCH] ASoC: mediatek: Change the order of MCLK clock configuration

Because MCLK opens later and closes earlier than codec, this patch changes the order of MCLK clock configuration. Signed-off-by: PC Liao --- sound/soc/mediatek/mtk-afe-pcm.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/sound/soc/mediatek/mtk-afe-pcm.c

Re: [PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

Hello Yakir, On 05/26/2016 05:34 AM, Yakir Yang wrote: > Hi Javier, > > On 05/24/2016 01:01 PM, Yakir Yang wrote: >> Hi all, >> >> This series have been posted about one month, still no comments, help here :( > This series works rightly on Rockchip platform, and most of them haven't > touch the

Re: [PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

Hello Yakir, On 05/26/2016 05:34 AM, Yakir Yang wrote: > Hi Javier, > > On 05/24/2016 01:01 PM, Yakir Yang wrote: >> Hi all, >> >> This series have been posted about one month, still no comments, help here :( > This series works rightly on Rockchip platform, and most of them haven't > touch the

Re: [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez wrote: > On 25 May 2016 at 19:24, Rob Herring wrote: >> >> On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote: >> > This patch allows fine tuning of the quads FS for audio clocks >> >

Re: [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks

On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez wrote: > On 25 May 2016 at 19:24, Rob Herring wrote: >> >> On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote: >> > This patch allows fine tuning of the quads FS for audio clocks >> > accuracy. >> > >> > Signed-off-by: Olivier

Re: Builtin microcode does nothing..

On Thu, May 26, 2016 at 01:52:22PM +0200, Gabriel C wrote: > With this patch ontop your your tip brach all is fine. > Tested on both server and both are up and running. Thanks. In the meantime, I've simplified the code even more and testing here with your .config looks good. I'll prepare

Re: Builtin microcode does nothing..

On Thu, May 26, 2016 at 01:52:22PM +0200, Gabriel C wrote: > With this patch ontop your your tip brach all is fine. > Tested on both server and both are up and running. Thanks. In the meantime, I've simplified the code even more and testing here with your .config looks good. I'll prepare

[PATCH 4/6] mm, oom: skip over vforked tasks

From: Michal Hocko vforked tasks are not really sitting on memory so it doesn't matter much to kill them. Parents are waiting for vforked task killable so it is better to chose parent which is the real mm owner. Teach oom_badness to ignore all tasks which haven't passed

[PATCH 4/6] mm, oom: skip over vforked tasks

From: Michal Hocko vforked tasks are not really sitting on memory so it doesn't matter much to kill them. Parents are waiting for vforked task killable so it is better to chose parent which is the real mm owner. Teach oom_badness to ignore all tasks which haven't passed mm_release.

[PATCH 1/6] mm, oom: do not loop over all tasks if there are no external tasks sharing mm

From: Michal Hocko oom_kill_process makes sure to kill all processes outside of the thread group which are sharing the mm. This requires to iterate over all tasks. This is however not a common case so we can optimize it a bit and only do that path only if we know that there are

[PATCH 2/6] proc, oom_adj: extract oom_score_adj setting into a helper

From: Michal Hocko Currently we have two proc interfaces to set oom_score_adj. The legacy /proc//oom_adj and /proc//oom_score_adj which both have their specific handlers. Big part of the logic is duplicated so extract the common code into __set_oom_adj helper. Legacy knob still

[PATCH 1/6] mm, oom: do not loop over all tasks if there are no external tasks sharing mm

From: Michal Hocko oom_kill_process makes sure to kill all processes outside of the thread group which are sharing the mm. This requires to iterate over all tasks. This is however not a common case so we can optimize it a bit and only do that path only if we know that there are external users of

[PATCH 2/6] proc, oom_adj: extract oom_score_adj setting into a helper

From: Michal Hocko Currently we have two proc interfaces to set oom_score_adj. The legacy /proc//oom_adj and /proc//oom_score_adj which both have their specific handlers. Big part of the logic is duplicated so extract the common code into __set_oom_adj helper. Legacy knob still expects some

[PATCH 6/6] mm, oom: fortify task_will_free_mem

From: Michal Hocko task_will_free_mem is rather weak. It doesn't really tell whether the task has chance to drop its mm. 98748bd72200 ("oom: consider multi-threaded tasks in task_will_free_mem") made a first step into making it more robust for multi-threaded applications so now

[PATCH 5/6] mm, oom: kill all tasks sharing the mm

From: Michal Hocko Currently oom_kill_process skips both the oom reaper and SIG_KILL if a process sharing the same mm is unkillable via OOM_ADJUST_MIN. After "mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj" all such processes are sharing the same

[PATCH 6/6] mm, oom: fortify task_will_free_mem

From: Michal Hocko task_will_free_mem is rather weak. It doesn't really tell whether the task has chance to drop its mm. 98748bd72200 ("oom: consider multi-threaded tasks in task_will_free_mem") made a first step into making it more robust for multi-threaded applications so now we know that the

[PATCH 5/6] mm, oom: kill all tasks sharing the mm

From: Michal Hocko Currently oom_kill_process skips both the oom reaper and SIG_KILL if a process sharing the same mm is unkillable via OOM_ADJUST_MIN. After "mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj" all such processes are sharing the same value so we

[PATCH 0/5] Handle oom bypass more gracefully

Hi, the following 6 patches should put some order to very rare cases of mm shared between processes and make the paths which bypass the oom killer oom reapable and so much more reliable finally. Even though mm shared outside of threadgroup is rare (either use_mm by kernel threads or exotic

[PATCH 3/6] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj

From: Michal Hocko oom_score_adj is shared for the thread groups (via struct signal) but this is not sufficient to cover processes sharing mm (CLONE_VM without CLONE_THREAD resp. CLONE_SIGHAND) and so we can easily end up in a situation when some processes update their

[PATCH 0/5] Handle oom bypass more gracefully

Hi, the following 6 patches should put some order to very rare cases of mm shared between processes and make the paths which bypass the oom killer oom reapable and so much more reliable finally. Even though mm shared outside of threadgroup is rare (either use_mm by kernel threads or exotic

[PATCH 3/6] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj

From: Michal Hocko oom_score_adj is shared for the thread groups (via struct signal) but this is not sufficient to cover processes sharing mm (CLONE_VM without CLONE_THREAD resp. CLONE_SIGHAND) and so we can easily end up in a situation when some processes update their oom_score_adj and confuse

Re: [PATCH] Staging: android: ion: fixed a kzalloc coding style issue.

On 26/05/16 09:01, Shubham Bansal wrote: > Fixed a coding style issue. Issue reported by checkpatch.pl. > > Signed-off-by: Shubham Bansal > --- > drivers/staging/android/ion/ion.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH] Staging: android: ion: fixed a kzalloc coding style issue.

On 26/05/16 09:01, Shubham Bansal wrote: > Fixed a coding style issue. Issue reported by checkpatch.pl. > > Signed-off-by: Shubham Bansal > --- > drivers/staging/android/ion/ion.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/android/ion/ion.c >

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Duc, On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote: > On Thu, Feb 25, 2016 at 9:38 AM, Lorenzo Pieralisi > wrote: > > On Wed, Feb 24, 2016 at 02:28:10PM -0800, Duc Dang wrote: > >> On Wed, Feb 24, 2016 at 8:16 AM, Marc Zyngier

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Duc, On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote: > On Thu, Feb 25, 2016 at 9:38 AM, Lorenzo Pieralisi > wrote: > > On Wed, Feb 24, 2016 at 02:28:10PM -0800, Duc Dang wrote: > >> On Wed, Feb 24, 2016 at 8:16 AM, Marc Zyngier wrote: > >> > On 24/02/16 16:09, Mark Salter wrote: >

Re: [PATCH v2] mmc: sdhci: fix wakeup configuration

On Fri, May 20, 2016 at 09:28:56PM +0300, Adrian Hunter wrote: > On 20/05/2016 4:39 p.m., Ulf Hansson wrote: > > On 20 May 2016 at 13:46, Adrian Hunter wrote: > > > On 13/05/16 16:16, Ludovic Desroches wrote: > > > > Activating wakeup event is not enough to get a wakeup

Re: [PATCH v2] mmc: sdhci: fix wakeup configuration

On Fri, May 20, 2016 at 09:28:56PM +0300, Adrian Hunter wrote: > On 20/05/2016 4:39 p.m., Ulf Hansson wrote: > > On 20 May 2016 at 13:46, Adrian Hunter wrote: > > > On 13/05/16 16:16, Ludovic Desroches wrote: > > > > Activating wakeup event is not enough to get a wakeup signal. The > > > >

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

On 26/05/16 05:56, DaeSeok Youn wrote: > 2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : >> On 20/05/16 10:51, Daeseok Youn wrote: >>> the "brd" value cannot be NULL in dgnc_finalize_board_init(). >>> Because "brd" as a parameter of this function was already >>> checked for

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

On 26/05/16 05:56, DaeSeok Youn wrote: > 2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : >> On 20/05/16 10:51, Daeseok Youn wrote: >>> the "brd" value cannot be NULL in dgnc_finalize_board_init(). >>> Because "brd" as a parameter of this function was already >>> checked for NULL. >>> >>>

Re: [PATCH v2] tpm: Factor out common startup code

On Mon, May 16, 2016 at 12:25:47PM -0600, Jason Gunthorpe wrote: > Provide some flags in tpm_class_ops to allow drivers to opt-in to the > common startup sequence. This is the sequence used by tpm_tis and > tpm_crb. > > All drivers should set this flag. > > Signed-off-by: Jason Gunthorpe

Re: [PATCH v2] tpm: Factor out common startup code

On Mon, May 16, 2016 at 12:25:47PM -0600, Jason Gunthorpe wrote: > Provide some flags in tpm_class_ops to allow drivers to opt-in to the > common startup sequence. This is the sequence used by tpm_tis and > tpm_crb. > > All drivers should set this flag. > > Signed-off-by: Jason Gunthorpe >

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hello Pankaj, On 05/26/2016 05:10 AM, pankaj.dubey wrote: [snip] >>> [0.00] Kernel command line: cros_legacy console=ttySAC3,115200 >>> debug earlyprintk cros_debug no_console_suspend root=/dev/ram0 rw >>> ramdisk=32768 initrd=0x4200,3 >>> 2M >> >> I see that you are loading an

Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hello Pankaj, On 05/26/2016 05:10 AM, pankaj.dubey wrote: [snip] >>> [0.00] Kernel command line: cros_legacy console=ttySAC3,115200 >>> debug earlyprintk cros_debug no_console_suspend root=/dev/ram0 rw >>> ramdisk=32768 initrd=0x4200,3 >>> 2M >> >> I see that you are loading an

Re: [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

On Thu, May 26, 2016 at 11:59:22AM +0100, Russell King - ARM Linux wrote: > I _really_ hate seeing architecture internal functions being abused in > drivers - architecture internal functions are there to implement the > official kernel APIs and are not for drivers to poke about with. Exactly - if

Re: [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

On Thu, May 26, 2016 at 11:59:22AM +0100, Russell King - ARM Linux wrote: > I _really_ hate seeing architecture internal functions being abused in > drivers - architecture internal functions are there to implement the > official kernel APIs and are not for drivers to poke about with. Exactly - if

Re: [PATCH 1/1] arm64: fix flush_cache_range

On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > Hi, > As my tracing, it is returned by "if (!page_mapping(page))", because "mmap" > are anonymous pages. I commented below code lines, it works well. > > /* no flushing needed for anonymous pages */ > if

Re: [PATCH 1/1] arm64: fix flush_cache_range

On Thu, May 26, 2016 at 07:46:11PM +0800, Leizhen (ThunderTown) wrote: > Hi, > As my tracing, it is returned by "if (!page_mapping(page))", because "mmap" > are anonymous pages. I commented below code lines, it works well. > > /* no flushing needed for anonymous pages */ > if

<    1   2   3   4   5   6   7   8   9   >