Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 17:45, David Vrabel wrote: > On 18/05/16 16:42, Juergen Gross wrote: >> On 18/05/16 17:25, Boris Ostrovsky wrote: >>> On 05/18/2016 10:53 AM, Juergen Gross wrote: On 18/05/16 16:46, Boris Ostrovsky wrote: > On 05/18/2016 08:15 AM, Juergen Gross wrote: >> } >> >>

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 17:45, David Vrabel wrote: > On 18/05/16 16:42, Juergen Gross wrote: >> On 18/05/16 17:25, Boris Ostrovsky wrote: >>> On 05/18/2016 10:53 AM, Juergen Gross wrote: On 18/05/16 16:46, Boris Ostrovsky wrote: > On 05/18/2016 08:15 AM, Juergen Gross wrote: >> } >> >>

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 16:42, Juergen Gross wrote: > On 18/05/16 17:25, Boris Ostrovsky wrote: >> On 05/18/2016 10:53 AM, Juergen Gross wrote: >>> On 18/05/16 16:46, Boris Ostrovsky wrote: On 05/18/2016 08:15 AM, Juergen Gross wrote: > } > > +void __init xen_time_setup_guest(void) >

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 16:42, Juergen Gross wrote: > On 18/05/16 17:25, Boris Ostrovsky wrote: >> On 05/18/2016 10:53 AM, Juergen Gross wrote: >>> On 18/05/16 16:46, Boris Ostrovsky wrote: On 05/18/2016 08:15 AM, Juergen Gross wrote: > } > > +void __init xen_time_setup_guest(void) >

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

On Tue, May 17, 2016 at 10:01:37PM -0700, Florian Fainelli wrote: > Le 17/05/2016 21:37, Guenter Roeck a écrit : > > Hi, > > > > my xtensa qemu tests crash in -next as follows. > > > > [ ... ] > > > > [9.366256] libphy: ethoc-mdio: probed > > [9.367389] (null): could not attach to PHY

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

On Tue, May 17, 2016 at 10:01:37PM -0700, Florian Fainelli wrote: > Le 17/05/2016 21:37, Guenter Roeck a écrit : > > Hi, > > > > my xtensa qemu tests crash in -next as follows. > > > > [ ... ] > > > > [9.366256] libphy: ethoc-mdio: probed > > [9.367389] (null): could not attach to PHY

Re: [PATCH] xen: add steal_clock support on x86

On 05/18/2016 10:53 AM, Juergen Gross wrote: > On 18/05/16 16:46, Boris Ostrovsky wrote: >> On 05/18/2016 08:15 AM, Juergen Gross wrote: >>> } >>> >>> +void __init xen_time_setup_guest(void) >>> +{ >>> + pv_time_ops.steal_clock = xen_steal_clock; >>> + >>> +

Re: [PATCH] xen: add steal_clock support on x86

On 05/18/2016 10:53 AM, Juergen Gross wrote: > On 18/05/16 16:46, Boris Ostrovsky wrote: >> On 05/18/2016 08:15 AM, Juergen Gross wrote: >>> } >>> >>> +void __init xen_time_setup_guest(void) >>> +{ >>> + pv_time_ops.steal_clock = xen_steal_clock; >>> + >>> +

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 17:25, Boris Ostrovsky wrote: > On 05/18/2016 10:53 AM, Juergen Gross wrote: >> On 18/05/16 16:46, Boris Ostrovsky wrote: >>> On 05/18/2016 08:15 AM, Juergen Gross wrote: } +void __init xen_time_setup_guest(void) +{ + pv_time_ops.steal_clock =

Re: [PATCH] xen: add steal_clock support on x86

On 18/05/16 17:25, Boris Ostrovsky wrote: > On 05/18/2016 10:53 AM, Juergen Gross wrote: >> On 18/05/16 16:46, Boris Ostrovsky wrote: >>> On 05/18/2016 08:15 AM, Juergen Gross wrote: } +void __init xen_time_setup_guest(void) +{ + pv_time_ops.steal_clock =

Re: [PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

On 18/05/16 16:04, Paul Burton wrote: On Wed, May 18, 2016 at 03:45:22PM +0100, Matt Redfearn wrote: When starting secondary VPEs which support EVA and the SegCtl registers, copy the memory segmentation configuration from the running VPE to ensure that all VPEs in the core have a consitent

Re: [PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

On 18/05/16 16:04, Paul Burton wrote: On Wed, May 18, 2016 at 03:45:22PM +0100, Matt Redfearn wrote: When starting secondary VPEs which support EVA and the SegCtl registers, copy the memory segmentation configuration from the running VPE to ensure that all VPEs in the core have a consitent

[PATCH V3] drm/tegra: Fix crash caused by reference count imbalance

dia.com> --- V3 changes: - Dropped WARN_ON V2 changes: - Updated to next-20160518 - Replaced open coding of call to drm_connector_reference() with __drm_atomic_helper_connector_duplicate_state() per Daniel's feedback. drivers/gpu/drm/tegra/dsi.c | 15 +++ 1 file changed, 11 inserti

[PATCH V3] drm/tegra: Fix crash caused by reference count imbalance

ector_destroy_state() in order to put the reference for the connector. Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)") Signed-off-by: Jon Hunter Reviewed-by: Daniel Vetter Acked-by: Thierry Reding --- V3 changes: - Dropped WARN_ON V2 changes: - Updated to next

Re: [PATCH v6 16/20] IB/fmr_pool: Convert the cleanup thread into kthread worker API

On 04/14/2016 11:14 AM, Petr Mladek wrote: > Kthreads are currently implemented as an infinite loop. Each > has its own variant of checks for terminating, freezing, > awakening. In many cases it is unclear to say in which state > it is and sometimes it is done a wrong way. > > The plan is to

Re: [PATCH v6 16/20] IB/fmr_pool: Convert the cleanup thread into kthread worker API

On 04/14/2016 11:14 AM, Petr Mladek wrote: > Kthreads are currently implemented as an infinite loop. Each > has its own variant of checks for terminating, freezing, > awakening. In many cases it is unclear to say in which state > it is and sometimes it is done a wrong way. > > The plan is to

[RFC PATCH 10/15] x86: Use ISO atomics

Make x86 use the ISO intrinsic atomics. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6268981 18446744071578845184 with this patch:

[RFC PATCH 06/15] Provide 16-bit ISO atomics

Provide an implementation of atomic_inc_short() using ISO atomics. Signed-off-by: David Howells --- include/asm-generic/iso-atomic16.h | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 include/asm-generic/iso-atomic16.h diff --git

[RFC PATCH 11/15] x86: Use ISO bitops

Make x86 use the ISO intrinsic bitops. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6268277 18446744071578845184 with this patch:

[RFC PATCH 10/15] x86: Use ISO atomics

Make x86 use the ISO intrinsic atomics. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6268981 18446744071578845184 with this patch:

[RFC PATCH 06/15] Provide 16-bit ISO atomics

Provide an implementation of atomic_inc_short() using ISO atomics. Signed-off-by: David Howells --- include/asm-generic/iso-atomic16.h | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 include/asm-generic/iso-atomic16.h diff --git

[RFC PATCH 11/15] x86: Use ISO bitops

Make x86 use the ISO intrinsic bitops. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6268277 18446744071578845184 with this patch:

Re: [PATCH 3/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On 05/17/2016 03:46 PM, Mark Rutland wrote: > On Tue, May 17, 2016 at 03:06:03PM +0300, Aleksey Makarov wrote: [...] >> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c >> index feab2ee..1d5e24f 100644 >> --- a/arch/arm64/kernel/setup.c >> +++ b/arch/arm64/kernel/setup.c >>

Re: [PATCH 3/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On 05/17/2016 03:46 PM, Mark Rutland wrote: > On Tue, May 17, 2016 at 03:06:03PM +0300, Aleksey Makarov wrote: [...] >> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c >> index feab2ee..1d5e24f 100644 >> --- a/arch/arm64/kernel/setup.c >> +++ b/arch/arm64/kernel/setup.c >>

Re: [PATCH] mlx5: avoid unused variable warning

On Wed, May 18, 2016 at 04:21:07PM +0200, Arnd Bergmann wrote: > When CONFIG_NET_CLS_ACT is disabled, we get a new warning in the mlx5 > ethernet driver because the tc_for_each_action() loop never references > the iterator: > > mellanox/mlx5/core/en_tc.c: In function 'mlx5e_stats_flower': >

[RFC PATCH 08/15] Provide an implementation of bitops using C++11 atomics

Provide an implementation of various atomic bit functions using the __atomic_fetch_{and,or,xor}() C++11 atomics. This involves creating a mask and adjusting the address in each function as the bit number can be greater than the number of bits in a word and can also be negative. On some arches,

Re: [PATCH] mlx5: avoid unused variable warning

On Wed, May 18, 2016 at 04:21:07PM +0200, Arnd Bergmann wrote: > When CONFIG_NET_CLS_ACT is disabled, we get a new warning in the mlx5 > ethernet driver because the tc_for_each_action() loop never references > the iterator: > > mellanox/mlx5/core/en_tc.c: In function 'mlx5e_stats_flower': >

[RFC PATCH 08/15] Provide an implementation of bitops using C++11 atomics

Provide an implementation of various atomic bit functions using the __atomic_fetch_{and,or,xor}() C++11 atomics. This involves creating a mask and adjusting the address in each function as the bit number can be greater than the number of bits in a word and can also be negative. On some arches,

[RFC PATCH 12/15] x86: Use ISO xchg(), cmpxchg() and friends

Make x86 use the ISO intrinsic xchg(), cmpxchg() and similar functions. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6273589

[RFC PATCH 13/15] x86: Improve spinlocks using ISO C++11 intrinsic atomics

Make some improvements to the x86 spinlock implementation using the ISO C++11 intrinsic atomic wrappers. Note that since the spinlocks use cmpxchg(), xadd() and __add(), it already makes some use of this. (1) Use acquire variants in spin_lock() and spin_trylock() paths. On x86 this

[RFC PATCH 09/15] Make the ISO bitops use 32-bit values internally

Make the ISO bitops use 32-bit values internally so that on x86 we emit the smaller BTRL/BTSL/BTCL instructions rather than BTRQ/BTSQ/BTCQ (which require a prefix). However, if we're going to do this, we really need to change the bit numbers for test_bit(), set_bit(), test_and_set_bit(), etc. to

[RFC PATCH 09/15] Make the ISO bitops use 32-bit values internally

Make the ISO bitops use 32-bit values internally so that on x86 we emit the smaller BTRL/BTSL/BTCL instructions rather than BTRQ/BTSQ/BTCQ (which require a prefix). However, if we're going to do this, we really need to change the bit numbers for test_bit(), set_bit(), test_and_set_bit(), etc. to

[RFC PATCH 12/15] x86: Use ISO xchg(), cmpxchg() and friends

Make x86 use the ISO intrinsic xchg(), cmpxchg() and similar functions. This boots fine, however it can't NOP out the LOCK prefixes if the number of online CPUs is 1. Without this patch, according to size -A, .text for my test kernel is: .text 6273589

[RFC PATCH 13/15] x86: Improve spinlocks using ISO C++11 intrinsic atomics

Make some improvements to the x86 spinlock implementation using the ISO C++11 intrinsic atomic wrappers. Note that since the spinlocks use cmpxchg(), xadd() and __add(), it already makes some use of this. (1) Use acquire variants in spin_lock() and spin_trylock() paths. On x86 this

[RFC PATCH 14/15] x86: Make the mutex implementation use ISO atomic ops

Make the x86 mutex implementation use ISO atomic ops rather than inline assembly. Signed-off-by: David Howells --- arch/x86/include/asm/mutex.h |6 +-- arch/x86/include/asm/mutex_iso.h | 73 ++ 2 files changed, 74

[RFC PATCH 14/15] x86: Make the mutex implementation use ISO atomic ops

Make the x86 mutex implementation use ISO atomic ops rather than inline assembly. Signed-off-by: David Howells --- arch/x86/include/asm/mutex.h |6 +-- arch/x86/include/asm/mutex_iso.h | 73 ++ 2 files changed, 74 insertions(+), 5 deletions(-)

drivers/of: crash on boot

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-next-20160518-sasha-00032-gab479e0-dirty #3090 [ 61.160149] 11000b660e83 8a2fe4e6 88005b3074a0 a3049c42 [ 61.162473] fbfff5c6e404 41b58ab3 adceb660 [ 61.164827] ff

drivers/of: crash on boot

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-next-20160518-sasha-00032-gab479e0-dirty #3090 [ 61.160149] 11000b660e83 8a2fe4e6 88005b3074a0 a3049c42 [ 61.162473] fbfff5c6e404 41b58ab3 adceb660 [ 61.164827] ff

Re: [PATCH v2 omap 3/6] arm: Add _rcuidle tracepoints to allow clk_core_disable() use from idle

On 16/05/2016 20:50, Paul E. McKenney wrote: >> stack backtrace: >> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1114 >> Hardware name: Generic OMAP36xx (Flattened Device Tree) >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >> [] (show_stack) from []

Re: [PATCH v2 omap 3/6] arm: Add _rcuidle tracepoints to allow clk_core_disable() use from idle

On 16/05/2016 20:50, Paul E. McKenney wrote: >> stack backtrace: >> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1114 >> Hardware name: Generic OMAP36xx (Flattened Device Tree) >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >> [] (show_stack) from []

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On 18/05/16 15:56, Alan Stern wrote: On Wed, 18 May 2016, Srinivas Kandagatla wrote: This patch adds a check in ehci_shutdown(), to make sure that the register access is available before accessing registers. The use case is simple, for boards like DB410c where the usb host or device

Re: [PATCH] usb: echi-hcd: Add register access check in shutdown

On 18/05/16 15:56, Alan Stern wrote: On Wed, 18 May 2016, Srinivas Kandagatla wrote: This patch adds a check in ehci_shutdown(), to make sure that the register access is available before accessing registers. The use case is simple, for boards like DB410c where the usb host or device

Re: [PATCH v3] net: sock: move ->sk_shutdown out of bitfields.

On Wed, 2016-05-18 at 17:36 +0300, Andrey Ryabinin wrote: > ->sk_shutdown bits share one bitfield with some other bits in sock struct, > such as ->sk_no_check_[r,t]x, ->sk_userlocks ... > sock_setsockopt() may write to these bits, while holding the socket lock. > > In case of AF_UNIX sockets, we

Re: [PATCH v3] net: sock: move ->sk_shutdown out of bitfields.

On Wed, 2016-05-18 at 17:36 +0300, Andrey Ryabinin wrote: > ->sk_shutdown bits share one bitfield with some other bits in sock struct, > such as ->sk_no_check_[r,t]x, ->sk_userlocks ... > sock_setsockopt() may write to these bits, while holding the socket lock. > > In case of AF_UNIX sockets, we

Re: [RFC PATCH 01/15] cmpxchg_local() is not signed-value safe, so fix generic atomics

On Wednesday 18 May 2016 16:10:45 David Howells wrote: > cmpxchg_local() is not signed-value safe because on a 64-bit machine signed > int arguments to it may be sign-extended to signed long _before_ begin cast > to unsigned long. This potentially causes comparisons to fail when dealing > with

Re: [RFC PATCH 01/15] cmpxchg_local() is not signed-value safe, so fix generic atomics

On Wednesday 18 May 2016 16:10:45 David Howells wrote: > cmpxchg_local() is not signed-value safe because on a 64-bit machine signed > int arguments to it may be sign-extended to signed long _before_ begin cast > to unsigned long. This potentially causes comparisons to fail when dealing > with

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Mon, 2 May 2016, Jiri Kosina wrote: > > From: Jiri Kosina > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > expensive no-op given the fact that the thread is not marked freezable. > > > > I/O helper kthreads, exactly such as the bcache

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Mon, 2 May 2016, Jiri Kosina wrote: > > From: Jiri Kosina > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > expensive no-op given the fact that the thread is not marked freezable. > > > > I/O helper kthreads, exactly such as the bcache writeback thread,

Re: [PATCH] mm: add config option to select the initial overcommit mode

Hi Michal, On 05/17/2016 10:16 PM, Michal Hocko wrote: > On Tue 17-05-16 18:16:58, Sebastian Frias wrote: > [...] >> From reading Documentation/cgroup-v1/memory.txt (and from a few >> replies here talking about cgroups), it looks like the OOM-killer is >> still being actively discussed, well,

Re: [PATCH] mm: add config option to select the initial overcommit mode

Hi Michal, On 05/17/2016 10:16 PM, Michal Hocko wrote: > On Tue 17-05-16 18:16:58, Sebastian Frias wrote: > [...] >> From reading Documentation/cgroup-v1/memory.txt (and from a few >> replies here talking about cgroups), it looks like the OOM-killer is >> still being actively discussed, well,

Re: [PATCH] mm: add config option to select the initial overcommit mode

Hi Austin, On 05/17/2016 07:29 PM, Austin S. Hemmelgarn wrote: >> I see the difference, your answer seems a bit like the one from Austin, >> basically: >> - killing a process is a sort of kernel protection attempting to deal >> "automatically" with some situation, like deciding what is a

Re: [PATCH] mm: add config option to select the initial overcommit mode

Hi Austin, On 05/17/2016 07:29 PM, Austin S. Hemmelgarn wrote: >> I see the difference, your answer seems a bit like the one from Austin, >> basically: >> - killing a process is a sort of kernel protection attempting to deal >> "automatically" with some situation, like deciding what is a

Re: linux-next: Tree for May 18 (rcu/tree)

On 05/17/16 21:30, Stephen Rothwell wrote: > Hi all, > > Please do not add any v4.8 destined material to your linux-next included > branches until after v4.7-rc1 has been released. > > Changes since 20160517: > on i386: In file included from ../kernel/rcu/tree.c:4209:0:

Re: linux-next: Tree for May 18 (rcu/tree)

On 05/17/16 21:30, Stephen Rothwell wrote: > Hi all, > > Please do not add any v4.8 destined material to your linux-next included > branches until after v4.7-rc1 has been released. > > Changes since 20160517: > on i386: In file included from ../kernel/rcu/tree.c:4209:0:

Re: [RFC 06/13] mm, thp: remove __GFP_NORETRY from khugepaged and madvised allocations

On Wed 18-05-16 13:59:53, Vlastimil Babka wrote: > On 05/13/2016 02:05 PM, Michal Hocko wrote: > > On Fri 13-05-16 10:23:31, Vlastimil Babka wrote: > >> On 05/12/2016 06:20 PM, Michal Hocko wrote: > >>> On Tue 10-05-16 09:35:56, Vlastimil Babka wrote: > >>> [...] > diff --git

Re: [RFC 06/13] mm, thp: remove __GFP_NORETRY from khugepaged and madvised allocations

On Wed 18-05-16 13:59:53, Vlastimil Babka wrote: > On 05/13/2016 02:05 PM, Michal Hocko wrote: > > On Fri 13-05-16 10:23:31, Vlastimil Babka wrote: > >> On 05/12/2016 06:20 PM, Michal Hocko wrote: > >>> On Tue 10-05-16 09:35:56, Vlastimil Babka wrote: > >>> [...] > diff --git

Re: [PATCH] mm: fix duplicate words and typos

On 05/17/16 19:35, Li Peng wrote: > Signed-off-by: Li Peng > --- > mm/memcontrol.c | 2 +- > mm/page_alloc.c | 6 +++--- > mm/vmscan.c | 7 +++ > mm/zswap.c | 2 +- > 4 files changed, 8 insertions(+), 9 deletions(-) > diff --git a/mm/vmscan.c b/mm/vmscan.c > index

Re: [PATCH] mm: fix duplicate words and typos

On 05/17/16 19:35, Li Peng wrote: > Signed-off-by: Li Peng > --- > mm/memcontrol.c | 2 +- > mm/page_alloc.c | 6 +++--- > mm/vmscan.c | 7 +++ > mm/zswap.c | 2 +- > 4 files changed, 8 insertions(+), 9 deletions(-) > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 142cb61..8ff5a79

[RFC PATCH 04/15] Convert 32-bit ISO atomics into a template

Convert the 32-bit ISO C++11 atomic implementation into a template that can then be overloaded with #defines to produce 32-bit, long and 64-bit atomics. This is then overloaded to produce the 32-bit atomic_t implementation. This should probably be merged with the previous patch if we want to use

[RFC PATCH 07/15] Provide cmpxchg(), xchg(), xadd() and __add() based on ISO C++11 intrinsics

Provide implementations of cmpxchg(), xchg(), xadd() and __add() using ISO C++11 intrinsics. Also provide variants with less strong ordering. The __atomic_compare_exchange_n() function returns a bool indicating whether or not the exchange took place. On x86, for example, the CMPXCHG instruction

[RFC PATCH 04/15] Convert 32-bit ISO atomics into a template

Convert the 32-bit ISO C++11 atomic implementation into a template that can then be overloaded with #defines to produce 32-bit, long and 64-bit atomics. This is then overloaded to produce the 32-bit atomic_t implementation. This should probably be merged with the previous patch if we want to use

[RFC PATCH 07/15] Provide cmpxchg(), xchg(), xadd() and __add() based on ISO C++11 intrinsics

Provide implementations of cmpxchg(), xchg(), xadd() and __add() using ISO C++11 intrinsics. Also provide variants with less strong ordering. The __atomic_compare_exchange_n() function returns a bool indicating whether or not the exchange took place. On x86, for example, the CMPXCHG instruction

Re: [RFC PATCH 2/3] arch/powerpc : optprobes for powerpc core

On Wed, 18 May 2016 02:09:37 +0530 Anju T wrote: > Instruction slot for detour buffer is allocated from > the reserved area. For the time being 64KB is reserved > in memory for this purpose. ppc_get_optinsn_slot() and > ppc_free_optinsn_slot() are geared towards the

Re: [RFC PATCH 2/3] arch/powerpc : optprobes for powerpc core

On Wed, 18 May 2016 02:09:37 +0530 Anju T wrote: > Instruction slot for detour buffer is allocated from > the reserved area. For the time being 64KB is reserved > in memory for this purpose. ppc_get_optinsn_slot() and > ppc_free_optinsn_slot() are geared towards the allocation and freeing > of

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

On 05/18/2016 11:01 AM, Nicolai Stange wrote: > Thanks a million for reporting! > > 1.) Do you have lockdep enabled? Yup, nothing there. > 2.) Does this happen before or after userspace init has been spawned, > i.e. does the lockup happen at debugfs file creation time or > possibly at

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

On 05/18/2016 11:01 AM, Nicolai Stange wrote: > Thanks a million for reporting! > > 1.) Do you have lockdep enabled? Yup, nothing there. > 2.) Does this happen before or after userspace init has been spawned, > i.e. does the lockup happen at debugfs file creation time or > possibly at

[PATCH] Input: pwm-beeper - fix: scheduling while atomic

Pwm config may sleep so defer it using a worker. Trigger: On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0 and 4.1.24. Unmodified applicable to * 4.6

[PATCH] Input: pwm-beeper - fix: scheduling while atomic

Pwm config may sleep so defer it using a worker. Trigger: On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0 and 4.1.24. Unmodified applicable to * 4.6

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

2016-05-16 19:48 GMT+03:00 Mark Rutland : > /* > + * Iterate over all possible CPUs in a leaf RCU node. > + */ > +#define for_each_leaf_node_possible_cpu(rnp, cpu) \ > + for ((cpu) = rnp->grplo; \ > +cpu <= rnp->grphi; \ > +cpu =

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

2016-05-16 19:48 GMT+03:00 Mark Rutland : > /* > + * Iterate over all possible CPUs in a leaf RCU node. > + */ > +#define for_each_leaf_node_possible_cpu(rnp, cpu) \ > + for ((cpu) = rnp->grplo; \ > +cpu <= rnp->grphi; \ > +cpu = cpumask_next((cpu),

[RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Provide an implementation of the atomic_t functions implemented with ISO-C++11 atomics. This has some advantages over using inline assembly: (1) The compiler has a much better idea of what is going on and can optimise appropriately, whereas with inline assembly, the content is an

[RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Provide an implementation of the atomic_t functions implemented with ISO-C++11 atomics. This has some advantages over using inline assembly: (1) The compiler has a much better idea of what is going on and can optimise appropriately, whereas with inline assembly, the content is an

[RFC PATCH 02/15] tty: ldsem_cmpxchg() should use cmpxchg() not atomic_long_cmpxchg()

ldsem_cmpxchg() should use cmpxchg() not atomic_long_cmpxchg() since the variable it is wangling isn't an atomic_long_t. Signed-off-by: David Howells cc: Peter Hurley cc: Greg Kroah-Hartman --- drivers/tty/tty_ldsem.c

[RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

Here's a set of patches to provide kernel atomics and bitops implemented with ISO C++11 atomic intrinsics. The second part of the set makes the x86 arch use the implementation. Note that the x86 patches are very rough. It would need to be made compile-time conditional in some way and the old

[RFC PATCH 02/15] tty: ldsem_cmpxchg() should use cmpxchg() not atomic_long_cmpxchg()

ldsem_cmpxchg() should use cmpxchg() not atomic_long_cmpxchg() since the variable it is wangling isn't an atomic_long_t. Signed-off-by: David Howells cc: Peter Hurley cc: Greg Kroah-Hartman --- drivers/tty/tty_ldsem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

Here's a set of patches to provide kernel atomics and bitops implemented with ISO C++11 atomic intrinsics. The second part of the set makes the x86 arch use the implementation. Note that the x86 patches are very rough. It would need to be made compile-time conditional in some way and the old

[RFC PATCH 01/15] cmpxchg_local() is not signed-value safe, so fix generic atomics

cmpxchg_local() is not signed-value safe because on a 64-bit machine signed int arguments to it may be sign-extended to signed long _before_ begin cast to unsigned long. This potentially causes comparisons to fail when dealing with negative values. Fix the generic atomic functions that are

[RFC PATCH 01/15] cmpxchg_local() is not signed-value safe, so fix generic atomics

cmpxchg_local() is not signed-value safe because on a 64-bit machine signed int arguments to it may be sign-extended to signed long _before_ begin cast to unsigned long. This potentially causes comparisons to fail when dealing with negative values. Fix the generic atomic functions that are

[RFC v2 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

The MPU has an auxiliary I2C bus for connecting external sensors. This bus has two operating modes: * bypasss: which connects the primary and auxiliary busses together. This is already supported via an i2c mux. * master: where the MPU acts as a master to any external connected sensors. This is

[RFC v2 5/7] iio: inv_mpu6050: Add support for auxiliary I2C master

The MPU has an auxiliary I2C bus for connecting external sensors. This bus has two operating modes: * bypasss: which connects the primary and auxiliary busses together. This is already supported via an i2c mux. * master: where the MPU acts as a master to any external connected sensors. This is

[PATCH v2 6/7] iio: inv_mpu6050: Reformat sample for active scan mask

Right now it is possible to only enable some of the x/y/z channels, for example you can enable accel_z without x or y but if you actually do that what you get is actually only the x channel. Fix this by reformatting the hardware sample to only include the requested channels. Signed-off-by:

[PATCH v2 6/7] iio: inv_mpu6050: Reformat sample for active scan mask

Right now it is possible to only enable some of the x/y/z channels, for example you can enable accel_z without x or y but if you actually do that what you get is actually only the x channel. Fix this by reformatting the hardware sample to only include the requested channels. Signed-off-by:

Re: [PATCH] ARM: exynos: don't select keyboard driver

On 05/18/2016 04:17 PM, Arnd Bergmann wrote: > The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?), > but this fails if CONFIG_INPUT is a loadable module: > > drivers/input/built-in.o: In function `samsung_keypad_remove': > drivers/input/keyboard/samsung-keypad.c:461:

[RFC v2 7/7] iio: inv_mpu6050: Expose channels from slave sensors

This works by copying the iio_chan_specs from the slave device and republishing them as if they belonged to the MPU itself. All read/write_raw operations are forwarded to the other driver. The original device is still registered with linux as a normal driver and works normally and you can poke at

[PATCH] thermal: add the note for set_trip_temp

Fixes commit 60f9ce3ada53 ("thermal: of-thermal: allow setting trip_temp on hardware") Signed-off-by: Caesar Wang Cc: Zhang Rui Cc: Eduardo Valentin Cc: linux...@vger.kernel.org --- include/linux/thermal.h | 2 ++ 1 file

Re: [PATCH] ARM: exynos: don't select keyboard driver

On 05/18/2016 04:17 PM, Arnd Bergmann wrote: > The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?), > but this fails if CONFIG_INPUT is a loadable module: > > drivers/input/built-in.o: In function `samsung_keypad_remove': > drivers/input/keyboard/samsung-keypad.c:461:

[RFC v2 7/7] iio: inv_mpu6050: Expose channels from slave sensors

This works by copying the iio_chan_specs from the slave device and republishing them as if they belonged to the MPU itself. All read/write_raw operations are forwarded to the other driver. The original device is still registered with linux as a normal driver and works normally and you can poke at

[PATCH] thermal: add the note for set_trip_temp

Fixes commit 60f9ce3ada53 ("thermal: of-thermal: allow setting trip_temp on hardware") Signed-off-by: Caesar Wang Cc: Zhang Rui Cc: Eduardo Valentin Cc: linux...@vger.kernel.org --- include/linux/thermal.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/thermal.h

Re: UBSAN whinge in ihci-hub.c

2016-05-18 17:40 GMT+03:00 Alan Stern : > All right, I'm getting very tired of all these bug reports. Besides, > Andrey has a point: Unless you're Linus, arguing against the C standard > is futile. (Even though the language dialect used in the kernel is not > standard

Re: UBSAN whinge in ihci-hub.c

2016-05-18 17:40 GMT+03:00 Alan Stern : > All right, I'm getting very tired of all these bug reports. Besides, > Andrey has a point: Unless you're Linus, arguing against the C standard > is futile. (Even though the language dialect used in the kernel is not > standard C.) > > Does this patch

Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 driver

On Wed, May 18, 2016 at 02:23:16PM +0200, Robin van der Gracht wrote: > This patchset adds a new driver to the auxdisplay subsystem. It also adds > devicetree bindings documentation and a new vendor prefix. > > I added myself as maintainer to the MAINTAINERS file. First off, if you want me to

Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 driver

On Wed, May 18, 2016 at 02:23:16PM +0200, Robin van der Gracht wrote: > This patchset adds a new driver to the auxdisplay subsystem. It also adds > devicetree bindings documentation and a new vendor prefix. > > I added myself as maintainer to the MAINTAINERS file. First off, if you want me to

[PATCH v2 0/7] iio: inv_mpu6050: Support i2c master and external readings

This series attempts to implement support for external readings in i2c master mode. Previous version here: https://www.spinics.net/lists/linux-iio/msg24502.html Patches 1 and 6 should be considered bugfixes. Patches 2,3,4 add regmap support and are mostly unchanged from v2 Patch 5 adds i2c

Re: [PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

On Wed, May 18, 2016 at 03:45:22PM +0100, Matt Redfearn wrote: > When starting secondary VPEs which support EVA and the SegCtl registers, > copy the memory segmentation configuration from the running VPE to ensure > that all VPEs in the core have a consitent virtual memory map. > > The EVA

[PATCH v2 0/7] iio: inv_mpu6050: Support i2c master and external readings

This series attempts to implement support for external readings in i2c master mode. Previous version here: https://www.spinics.net/lists/linux-iio/msg24502.html Patches 1 and 6 should be considered bugfixes. Patches 2,3,4 add regmap support and are mostly unchanged from v2 Patch 5 adds i2c

Re: [PATCH 2/2] MIPS: CPS: Copy EVA configuration when starting secondary VPs.

On Wed, May 18, 2016 at 03:45:22PM +0100, Matt Redfearn wrote: > When starting secondary VPEs which support EVA and the SegCtl registers, > copy the memory segmentation configuration from the running VPE to ensure > that all VPEs in the core have a consitent virtual memory map. > > The EVA

[PATCH v2 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 9 ++--- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 4 +++- 3 files changed, 11 insertions(+), 4 deletions(-) diff

[PATCH v2 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 13 - drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 3 ++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c

[PATCH v2 4/7] iio: inv_mpu6050: Cache non-volatile bits of user_ctrl

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++ drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 9 ++--- drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 4 +++- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git

[PATCH v2 3/7] iio: inv_mpu6050: Only toggle DATA_RDY_EN in inv_reset_fifo

Signed-off-by: Crestez Dan Leonard --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c| 13 - drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 3 ++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c

<    3   4   5   6   7   8   9   10   11   12   >