Re: [git pull] drm for v4.7

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds wrote: > > I'll test this out and look what happens, but I hate getting different > results than what I'm told to expect. Hmm. I also get a lot of ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference

Re: [git pull] drm for v4.7

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds wrote: > > I'll test this out and look what happens, but I hate getting different > results than what I'm told to expect. Hmm. I also get a lot of ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or variable defined in the

Re: [PATCH] Fix RC5 decoding with Fintek CIR chipset

On Sat, May 14, 2016 at 06:01:26PM +0100, Jonathan McDowell wrote: >Fix RC5 decoding with Fintek CIR chipset > >Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5 >decoding by adding a check for trailing silence to ensure a valid RC5 >command had been received. Unfortunately the

Re: [PATCH] Fix RC5 decoding with Fintek CIR chipset

On Sat, May 14, 2016 at 06:01:26PM +0100, Jonathan McDowell wrote: >Fix RC5 decoding with Fintek CIR chipset > >Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5 >decoding by adding a check for trailing silence to ensure a valid RC5 >command had been received. Unfortunately the

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, May 23, 2016 at 02:49:09PM -0400, Rik van Riel wrote: > On Mon, 2016-05-23 at 20:42 +0200, Michal Hocko wrote: > > On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > > > > > > Currently khugepaged makes swapin readahead under > > > down_write. This patch supplies to make swapin > > >

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, May 23, 2016 at 02:49:09PM -0400, Rik van Riel wrote: > On Mon, 2016-05-23 at 20:42 +0200, Michal Hocko wrote: > > On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > > > > > > Currently khugepaged makes swapin readahead under > > > down_write. This patch supplies to make swapin > > >

Re: [git pull] drm for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie wrote: > > Here's the main drm pull request for 4.7, it's been > a busy one, and I've been a bit more distracted in > real life this merge window. Hmm. I pulled this, but I think I'll have to unpull again. Neither the diffstat not

Re: [git pull] drm for v4.7

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie wrote: > > Here's the main drm pull request for 4.7, it's been > a busy one, and I've been a bit more distracted in > real life this merge window. Hmm. I pulled this, but I think I'll have to unpull again. Neither the diffstat not the shortlog

[PATCH] drm/i915/ilk: Disable SSC for DPLLs if we're not using it

Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes,

[PATCH] drm/i915/ilk: Disable SSC for DPLLs if we're not using it

Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes,

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, 2016-05-23 at 20:42 +0200, Michal Hocko wrote: > On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > > > > Currently khugepaged makes swapin readahead under > > down_write. This patch supplies to make swapin > > readahead under down_read instead of down_write. > You are still keeping

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, 2016-05-23 at 20:42 +0200, Michal Hocko wrote: > On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > > > > Currently khugepaged makes swapin readahead under > > down_write. This patch supplies to make swapin > > readahead under down_read instead of down_write. > You are still keeping

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote: > On 05/18/2016 12:58 PM, Jason Low wrote: > > It should be fine to use the standard READ_ONCE here, even if it's just > > for documentation, as it's probably not going to cost anything in > > practice. It would be better to avoid adding any

Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE

On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote: > On 05/18/2016 12:58 PM, Jason Low wrote: > > It should be fine to use the standard READ_ONCE here, even if it's just > > for documentation, as it's probably not going to cost anything in > > practice. It would be better to avoid adding any

[PATCH] misc: at24: Fix typo in at24 header file

This commit fixes a simple typo s/mvmem/nvmem in the example. Signed-off-by: Moritz Fischer --- include/linux/platform_data/at24.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/platform_data/at24.h

[PATCH] misc: at24: Fix typo in at24 header file

This commit fixes a simple typo s/mvmem/nvmem in the example. Signed-off-by: Moritz Fischer --- include/linux/platform_data/at24.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h index dc9a13e..be830b1

RE: livepatch: change to a per-task consistency model

On Mon, 23 May 2016, David Laight wrote: > Related, please can we have a flag for the sleep and/or process so that > an uninterruptible sleep doesn't trigger the 'hung task' detector TASK_KILLABLE > and also stops the process counting towards the 'load average'. TASK_NOLOAD -- Jiri Kosina

RE: livepatch: change to a per-task consistency model

On Mon, 23 May 2016, David Laight wrote: > Related, please can we have a flag for the sleep and/or process so that > an uninterruptible sleep doesn't trigger the 'hung task' detector TASK_KILLABLE > and also stops the process counting towards the 'load average'. TASK_NOLOAD -- Jiri Kosina

Re: [PATCH 3/4] x86: Rewrite switch_to() code

On Mon, May 23, 2016 at 10:03:54AM -0700, Andy Lutomirski wrote: > On Mon, May 23, 2016 at 9:46 AM, Josh Poimboeuf wrote: > > On Mon, May 23, 2016 at 06:49:03AM -0500, Josh Poimboeuf wrote: > >> On Mon, May 23, 2016 at 06:47:22AM -0500, Josh Poimboeuf wrote: > >> > On Mon,

Re: [PATCH 3/4] x86: Rewrite switch_to() code

On Mon, May 23, 2016 at 10:03:54AM -0700, Andy Lutomirski wrote: > On Mon, May 23, 2016 at 9:46 AM, Josh Poimboeuf wrote: > > On Mon, May 23, 2016 at 06:49:03AM -0500, Josh Poimboeuf wrote: > >> On Mon, May 23, 2016 at 06:47:22AM -0500, Josh Poimboeuf wrote: > >> > On Mon, May 23, 2016 at

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > Currently khugepaged makes swapin readahead under > down_write. This patch supplies to make swapin > readahead under down_read instead of down_write. You are still keeping down_write. Can we do without it altogether? Blocking mmap_sem of a remote

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon 23-05-16 20:14:11, Ebru Akagunduz wrote: > Currently khugepaged makes swapin readahead under > down_write. This patch supplies to make swapin > readahead under down_read instead of down_write. You are still keeping down_write. Can we do without it altogether? Blocking mmap_sem of a remote

[v2 PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

Per the suggestion from Michal Hocko [1], DEFERRED_STRUCT_PAGE_INIT requires some ordering wrt other initialization operations, e.g. page_ext_init has to happen after the whole memmap is initialized properly. For SPARSEMEM this requires to wait for page_alloc_init_late. Other memory models (e.g.

[v2 PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

Per the suggestion from Michal Hocko [1], DEFERRED_STRUCT_PAGE_INIT requires some ordering wrt other initialization operations, e.g. page_ext_init has to happen after the whole memmap is initialized properly. For SPARSEMEM this requires to wait for page_alloc_init_late. Other memory models (e.g.

[RFC 4/7] iio: Add current_trigger_id alternative

This allows controlling the current trigger by numeric ID rather than name. Signed-off-by: Crestez Dan Leonard --- Documentation/ABI/testing/sysfs-bus-iio | 9 +++ Documentation/DocBook/iio.tmpl | 4 +- drivers/iio/industrialio-trigger.c | 115

[RFC 6/7] iio: Refuse to register triggers with duplicate names

The trigger name is documented as unique but drivers are currently allowed to register triggers with duplicate names. This should be considered a bug since it makes the 'current_trigger' interface unusable. Signed-off-by: Crestez Dan Leonard ---

[RFC 4/7] iio: Add current_trigger_id alternative

This allows controlling the current trigger by numeric ID rather than name. Signed-off-by: Crestez Dan Leonard --- Documentation/ABI/testing/sysfs-bus-iio | 9 +++ Documentation/DocBook/iio.tmpl | 4 +- drivers/iio/industrialio-trigger.c | 115

[RFC 6/7] iio: Refuse to register triggers with duplicate names

The trigger name is documented as unique but drivers are currently allowed to register triggers with duplicate names. This should be considered a bug since it makes the 'current_trigger' interface unusable. Signed-off-by: Crestez Dan Leonard --- drivers/iio/industrialio-trigger.c | 21

[PATCHv3 3/7] iio: generic_buffer: Add --trigger-num option

Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c index 3f16e9f..e8c3052 100644 ---

[RFC 0/7] Deal with iio trigger names

IIO documents that trigger names are unique but does not actually guarantee this. You can easily create a software trigger with a duplicate name if you enable CONFIG_IIO_HRTIMER_TRIGGER: mkdir /sys/kernel/config/iio/triggers/hrtimer/\ `cat

[PATCHv3 3/7] iio: generic_buffer: Add --trigger-num option

Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c index 3f16e9f..e8c3052 100644 --- a/tools/iio/generic_buffer.c +++

[RFC 0/7] Deal with iio trigger names

IIO documents that trigger names are unique but does not actually guarantee this. You can easily create a software trigger with a duplicate name if you enable CONFIG_IIO_HRTIMER_TRIGGER: mkdir /sys/kernel/config/iio/triggers/hrtimer/\ `cat

[RFC 7/7] iio: Make trigger names unique

This changes the format of trigger names for some drivers so that the result always includes indio_dev->id and is thus unique. Signed-off-by: Crestez Dan Leonard --- drivers/iio/adc/max1027.c | 4 ++--

[PATCHv3 1/7] iio: generic_buffer: Cleanup when receiving signals

This will clean (disable buffer/trigger/channels) when doing something like a CTRL-C. Otherwise restarting generic_buffer requires a manual echo 0 > buffer/enable This also cleanup up all the code freeing string buffers at the end of main. We initialize all pointers to NULL so that cleanup can

[PATCHv3 2/7] iio: generic_buffer: Add --device-num option

This makes it possible to distinguish between iio devices with the same name. Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 69 ++ 1 file changed, 51 insertions(+), 18 deletions(-) diff --git

[RFC 5/7] iio: generic_buffer: Use current_trigger_id

This is a preferred alternative to 'current_trigger'. Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c index

[RFC 7/7] iio: Make trigger names unique

This changes the format of trigger names for some drivers so that the result always includes indio_dev->id and is thus unique. Signed-off-by: Crestez Dan Leonard --- drivers/iio/adc/max1027.c | 4 ++-- drivers/iio/common/st_sensors/st_sensors_trigger.c | 2 +-

[PATCHv3 1/7] iio: generic_buffer: Cleanup when receiving signals

This will clean (disable buffer/trigger/channels) when doing something like a CTRL-C. Otherwise restarting generic_buffer requires a manual echo 0 > buffer/enable This also cleanup up all the code freeing string buffers at the end of main. We initialize all pointers to NULL so that cleanup can

[PATCHv3 2/7] iio: generic_buffer: Add --device-num option

This makes it possible to distinguish between iio devices with the same name. Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 69 ++ 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/tools/iio/generic_buffer.c

[RFC 5/7] iio: generic_buffer: Use current_trigger_id

This is a preferred alternative to 'current_trigger'. Signed-off-by: Crestez Dan Leonard --- tools/iio/generic_buffer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c index e8c3052..b23371a 100644 ---

Re: powerpc/pseries: start rtasd before PCI probing

On Mon, 23 May 2016 20:23:19 +0200 Thomas Huth wrote: > On 23.05.2016 10:28, Greg Kurz wrote: > > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > > x86 and pseries. If you consider the following steps: > > - start a VM > > - add a PCI device via

Re: powerpc/pseries: start rtasd before PCI probing

On Mon, 23 May 2016 20:23:19 +0200 Thomas Huth wrote: > On 23.05.2016 10:28, Greg Kurz wrote: > > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > > x86 and pseries. If you consider the following steps: > > - start a VM > > - add a PCI device via the QEMU monitor

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

On Fri, May 20, 2016 at 07:32:09PM +1000, Michael Ellerman wrote: > On Thu, 2016-05-19 at 08:00 -0700, Paul E. McKenney wrote: > > On Thu, May 19, 2016 at 04:41:17PM +0200, Peter Zijlstra wrote: > > > On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > > > > Agreed, these sorts of

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

On Fri, May 20, 2016 at 07:32:09PM +1000, Michael Ellerman wrote: > On Thu, 2016-05-19 at 08:00 -0700, Paul E. McKenney wrote: > > On Thu, May 19, 2016 at 04:41:17PM +0200, Peter Zijlstra wrote: > > > On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > > > > Agreed, these sorts of

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

On 5/23/2016 11:22 AM, Michal Hocko wrote: On Mon 23-05-16 09:54:31, Yang Shi wrote: Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT should be incompatible with FLATMEM, make this explicitly in Kconfig. I guess the changelog could benefit from some clarification.

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

On 5/23/2016 11:22 AM, Michal Hocko wrote: On Mon 23-05-16 09:54:31, Yang Shi wrote: Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT should be incompatible with FLATMEM, make this explicitly in Kconfig. I guess the changelog could benefit from some clarification.

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

On 05/23/2016 01:56 PM, Lorenzo Pieralisi wrote: > On Tue, May 17, 2016 at 12:48:53PM -0400, Jon Masters wrote: >> On 05/17/2016 12:44 PM, Jon Masters wrote: >> >>> 1). During development of a platform, it is much easier to debug >>> problems with tables if you can test replacement ones without

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

On 05/23/2016 01:56 PM, Lorenzo Pieralisi wrote: > On Tue, May 17, 2016 at 12:48:53PM -0400, Jon Masters wrote: >> On 05/17/2016 12:44 PM, Jon Masters wrote: >> >>> 1). During development of a platform, it is much easier to debug >>> problems with tables if you can test replacement ones without

Re: powerpc/pseries: start rtasd before PCI probing

On 23.05.2016 10:28, Greg Kurz wrote: > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > x86 and pseries. If you consider the following steps: > - start a VM > - add a PCI device via the QEMU monitor before the rtasd has started (for > example starting the VM in

Re: powerpc/pseries: start rtasd before PCI probing

On 23.05.2016 10:28, Greg Kurz wrote: > A strange behaviour is observed when comparing PCI hotplug in QEMU, between > x86 and pseries. If you consider the following steps: > - start a VM > - add a PCI device via the QEMU monitor before the rtasd has started (for > example starting the VM in

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

On Mon 23-05-16 09:54:31, Yang Shi wrote: > Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT > should be incompatible with FLATMEM, make this explicitly in Kconfig. I guess the changelog could benefit from some clarification. What do you think about the following: "

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

On Mon 23-05-16 09:54:31, Yang Shi wrote: > Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT > should be incompatible with FLATMEM, make this explicitly in Kconfig. I guess the changelog could benefit from some clarification. What do you think about the following: "

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/23/2016 01:25 PM, Mark Rutland wrote: > On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote: >> L2 registers are accessed using a select register and data >> register pair. To prevent multiple concurrent writes to the >> select register by independent drivers, the write to the >>

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/23/2016 01:25 PM, Mark Rutland wrote: > On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote: >> L2 registers are accessed using a select register and data >> register pair. To prevent multiple concurrent writes to the >> select register by independent drivers, the write to the >>

[GIT PULL] ftracetest: Use proper logic to find process PID

Linus, Reviewing the selftest I recently submitted, I realize that the second part of it uses my old hack to get the PID of the spawned background tasks, which doesn't work for all shells, instead of the common use of $!. Please pull the latest trace-v4.7-3 tree, which can be found at:

[GIT PULL] ftracetest: Use proper logic to find process PID

Linus, Reviewing the selftest I recently submitted, I realize that the second part of it uses my old hack to get the PID of the spawned background tasks, which doesn't work for all shells, instead of the common use of $!. Please pull the latest trace-v4.7-3 tree, which can be found at:

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/23/2016 01:04 PM, Stephen Boyd wrote: > On 05/23/2016 08:43 AM, Neil Leeder wrote: >> >> On 5/20/2016 05:19 PM, Stephen Boyd wrote: >> >>> >>> Is there a patch to add sysreg.h to arch/arm? It would be nice to use >>> one l2 accessor API on arm64 and arm. >>> >> Sounds like a good thing for

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/23/2016 01:04 PM, Stephen Boyd wrote: > On 05/23/2016 08:43 AM, Neil Leeder wrote: >> >> On 5/20/2016 05:19 PM, Stephen Boyd wrote: >> >>> >>> Is there a patch to add sysreg.h to arch/arm? It would be nice to use >>> one l2 accessor API on arm64 and arm. >>> >> Sounds like a good thing for

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On Mon 23-05-16 09:42:00, Shi, Yang wrote: > On 5/23/2016 12:31 AM, Michal Hocko wrote: > > On Fri 20-05-16 08:41:09, Shi, Yang wrote: > > > On 5/20/2016 6:16 AM, Michal Hocko wrote: > > > > On Thu 19-05-16 15:13:26, Yang Shi wrote: > > > > [...] > > > > > diff --git a/init/main.c b/init/main.c >

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On Mon 23-05-16 09:42:00, Shi, Yang wrote: > On 5/23/2016 12:31 AM, Michal Hocko wrote: > > On Fri 20-05-16 08:41:09, Shi, Yang wrote: > > > On 5/20/2016 6:16 AM, Michal Hocko wrote: > > > > On Thu 19-05-16 15:13:26, Yang Shi wrote: > > > > [...] > > > > > diff --git a/init/main.c b/init/main.c >

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Sun, May 22, 2016 at 6:26 PM, Yang Zhang wrote: > On 2016/5/21 2:37, David Matlack wrote: >> >> It's not obvious to me why polling for a timer interrupt would improve >> context switch latency. Can you explain a bit more? > > > We have a workload which using high

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Sun, May 22, 2016 at 6:26 PM, Yang Zhang wrote: > On 2016/5/21 2:37, David Matlack wrote: >> >> It's not obvious to me why polling for a timer interrupt would improve >> context switch latency. Can you explain a bit more? > > > We have a workload which using high resolution timer(less than

Re: [PATCH 1/4] isa: Allow ISA-style drivers on modern systems

On Mon, May 23, 2016 at 7:58 AM, William Breathitt Gray wrote: > > For now, the ISA_BUS Kconfig option is only be available on X86 > architectures. Support for other architectures may be added as required. So I'd prefer to see that > +config ISA_BUS_API > +

Re: [PATCH 1/4] isa: Allow ISA-style drivers on modern systems

On Mon, May 23, 2016 at 7:58 AM, William Breathitt Gray wrote: > > For now, the ISA_BUS Kconfig option is only be available on X86 > architectures. Support for other architectures may be added as required. So I'd prefer to see that > +config ISA_BUS_API > + def_bool ISA part in

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: > From: Wanpeng Li I'm ok with this patch, but I'd like to better understand the target workloads. What type of workloads do you expect to benefit from this? > > If an emulated lapic timer will fire

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: > From: Wanpeng Li I'm ok with this patch, but I'd like to better understand the target workloads. What type of workloads do you expect to benefit from this? > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of

Re: [PATCH] Input: wacom_w8001 - Ignore bogus idx values in interrupt

On Mon, May 23, 2016 at 9:52 AM, Dmitry Torokhov wrote: > On Sun, May 22, 2016 at 10:21:45PM -0700, Ping Cheng wrote: >> Hi Chris, >> >> On Sun, May 22, 2016 at 6:42 PM, Chris J Arges >> wrote: >> > I've noticed crashes when using my x60t

Re: [PATCH] Input: wacom_w8001 - Ignore bogus idx values in interrupt

On Mon, May 23, 2016 at 9:52 AM, Dmitry Torokhov wrote: > On Sun, May 22, 2016 at 10:21:45PM -0700, Ping Cheng wrote: >> Hi Chris, >> >> On Sun, May 22, 2016 at 6:42 PM, Chris J Arges >> wrote: >> > I've noticed crashes when using my x60t using a coreboot bios. When using >> > the pen I can

Re: [PATCH] kernel/kcov: unproxify debugfs file's fops

s_create_file(). > > Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private > data") > Fixes: 5c9a8750a640 ("kernel: add kcov code coverage") > Signed-off-by: Nicolai Stange <nicsta...@gmail.com> > --- > App

Re: [PATCH] kernel/kcov: unproxify debugfs file's fops

> Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private > data") > Fixes: 5c9a8750a640 ("kernel: add kcov code coverage") > Signed-off-by: Nicolai Stange > --- > Applicable to linux-next 20160523. > In particular,

Applied "regulator: mt6397: Constify struct regulator_ops" to the regulator tree

The patch regulator: mt6397: Constify struct regulator_ops has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "spi: Add file patterns for spi device tree bindings" to the spi tree

The patch spi: Add file patterns for spi device tree bindings has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: sem_lock() vs qspinlocks

On Mon, May 23, 2016 at 5:25 AM, Peter Zijlstra wrote: > > Paul has smp_mb__after_unlock_lock() for the RCpc 'upgrade'. How about > something like: > > smp_mb__after_lock() I'd much rather make the naming be higher level. It's not necessarily going to be a "mb", and

Applied "regulator: mt6397: Constify struct regulator_ops" to the regulator tree

The patch regulator: mt6397: Constify struct regulator_ops has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "spi: Add file patterns for spi device tree bindings" to the spi tree

The patch spi: Add file patterns for spi device tree bindings has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

Re: sem_lock() vs qspinlocks

On Mon, May 23, 2016 at 5:25 AM, Peter Zijlstra wrote: > > Paul has smp_mb__after_unlock_lock() for the RCpc 'upgrade'. How about > something like: > > smp_mb__after_lock() I'd much rather make the naming be higher level. It's not necessarily going to be a "mb", and while the problem is

Applied "regulator: pv880x0: Clean up unnecessary header inclusion" to the regulator tree

The patch regulator: pv880x0: Clean up unnecessary header inclusion has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: pv880x0: Clean up unnecessary header inclusion" to the regulator tree

The patch regulator: pv880x0: Clean up unnecessary header inclusion has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree

The patch regulator: mt6397: Add buck change mode regulator interface for mt6397 has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "regulator: mt6397: Add buck change mode regulator interface for mt6397" to the regulator tree

The patch regulator: mt6397: Add buck change mode regulator interface for mt6397 has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "ASoC: Add file patterns for sound device tree bindings" to the asoc tree

The patch ASoC: Add file patterns for sound device tree bindings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: kirkwood: fix build failure" to the asoc tree

The patch ASoC: kirkwood: fix build failure has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Applied "ASoC: Add file patterns for sound device tree bindings" to the asoc tree

The patch ASoC: Add file patterns for sound device tree bindings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: kirkwood: fix build failure" to the asoc tree

The patch ASoC: kirkwood: fix build failure has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Applied "regmap: Add file patterns for regmap device tree bindings" to the regmap tree

The patch regmap: Add file patterns for regmap device tree bindings has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regmap: Add file patterns for regmap device tree bindings" to the regmap tree

The patch regmap: Add file patterns for regmap device tree bindings has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH 1/2] mtd: spi-nor: disable software protection for Macronix flash at startup

Hi Matthias, Le 23/05/2016 18:32, Matthias Schiffer a écrit : > On 05/23/2016 04:01 PM, Cyrille Pitchen wrote: >> Hi Matthias, >> >> Le 18/05/2016 15:32, Matthias Schiffer a écrit : >>> This patch has been tested in OpenWrt for a few months and seems to work >>> correctly. >>> >>> Signed-off-by:

Re: [PATCH 1/2] mtd: spi-nor: disable software protection for Macronix flash at startup

Hi Matthias, Le 23/05/2016 18:32, Matthias Schiffer a écrit : > On 05/23/2016 04:01 PM, Cyrille Pitchen wrote: >> Hi Matthias, >> >> Le 18/05/2016 15:32, Matthias Schiffer a écrit : >>> This patch has been tested in OpenWrt for a few months and seems to work >>> correctly. >>> >>> Signed-off-by:

Applied "ASoC: dwc: Add helper functions to disable/enable irqs" to the asoc tree

The patch ASoC: dwc: Add helper functions to disable/enable irqs has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: dwc: Add helper functions to disable/enable irqs" to the asoc tree

The patch ASoC: dwc: Add helper functions to disable/enable irqs has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

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

On Tue, May 17, 2016 at 12:48:53PM -0400, Jon Masters wrote: > On 05/17/2016 12:44 PM, Jon Masters wrote: > > > 1). During development of a platform, it is much easier to debug > > problems with tables if you can test replacement ones without having to > > respin the firmware. In the server

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

On Tue, May 17, 2016 at 12:48:53PM -0400, Jon Masters wrote: > On 05/17/2016 12:44 PM, Jon Masters wrote: > > > 1). During development of a platform, it is much easier to debug > > problems with tables if you can test replacement ones without having to > > respin the firmware. In the server

Re: [PATCH] x86: fix potential memleak in do_error_trap

On Mon 23-05-16 17:33:55, Oleg Nesterov wrote: > On 05/23, Michal Hocko wrote: > > > > @@ -271,6 +271,7 @@ static void do_error_trap(struct pt_regs *regs, long > > error_code, char *str, > > > > if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) != > >

Re: [PATCH] x86: fix potential memleak in do_error_trap

On Mon 23-05-16 17:33:55, Oleg Nesterov wrote: > On 05/23, Michal Hocko wrote: > > > > @@ -271,6 +271,7 @@ static void do_error_trap(struct pt_regs *regs, long > > error_code, char *str, > > > > if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) != > >

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

On 5/20/2016 2:31 AM, Sricharan wrote: Hi, @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg) goto err; qup->blk.pos++; + + /* Handle SMBus block read length */ + if

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

On 5/20/2016 2:31 AM, Sricharan wrote: Hi, @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg) goto err; qup->blk.pos++; + + /* Handle SMBus block read length */ + if

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, May 23, 2016 at 08:14:11PM +0300, Ebru Akagunduz wrote: > Currently khugepaged makes swapin readahead under > down_write. This patch supplies to make swapin > readahead under down_read instead of down_write. > > The patch was tested with a test program that allocates > 800MB of memory,

Re: [PATCH 3/3] mm, thp: make swapin readahead under down_read of mmap_sem

On Mon, May 23, 2016 at 08:14:11PM +0300, Ebru Akagunduz wrote: > Currently khugepaged makes swapin readahead under > down_write. This patch supplies to make swapin > readahead under down_read instead of down_write. > > The patch was tested with a test program that allocates > 800MB of memory,

Re: [PATCH] mm: memcontrol: fix possible css ref leak on oom

On Mon 23-05-16 19:02:10, Vladimir Davydov wrote: > mem_cgroup_oom may be invoked multiple times while a process is handling > a page fault, in which case current->memcg_in_oom will be overwritten > leaking the previously taken css reference. Have you seen this happening? I was under impression

Re: [PATCH] mm: memcontrol: fix possible css ref leak on oom

On Mon 23-05-16 19:02:10, Vladimir Davydov wrote: > mem_cgroup_oom may be invoked multiple times while a process is handling > a page fault, in which case current->memcg_in_oom will be overwritten > leaking the previously taken css reference. Have you seen this happening? I was under impression

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