[GIT PULL 00/13] perf/core improvements and fixes

From: Arnaldo Carvalho de Melo Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit a7636d9ecfa3ab7800a7c04c1f89378229eff609: kprobes: Optimize hot path by using percpu counter to collect 'nhit' statistics (2016-02-09 11:08:58 +0100) are

[GIT PULL 00/13] perf/core improvements and fixes

From: Arnaldo Carvalho de Melo Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit a7636d9ecfa3ab7800a7c04c1f89378229eff609: kprobes: Optimize hot path by using percpu counter to collect 'nhit' statistics (2016-02-09 11:08:58 +0100) are available in the

[PATCH 11/13] perf tools: Rename parse_events__free_terms() to parse_events_terms__delete()

From: Arnaldo Carvalho de Melo To follow convention used in other tools/perf/ areas. Also remove the need to check if it is NULL before calling the destructor, again, to follow convention that goes back to free(). Cc: Alexei Starovoitov Cc: He Kuang

[PATCH 05/13] perf tools: Add comment explaining the repsep_snprintf function

From: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-4j67nvlfwbnkg85b969ew...@git.kernel.org Signed-off-by: Arnaldo

[PATCH 11/13] perf tools: Rename parse_events__free_terms() to parse_events_terms__delete()

From: Arnaldo Carvalho de Melo To follow convention used in other tools/perf/ areas. Also remove the need to check if it is NULL before calling the destructor, again, to follow convention that goes back to free(). Cc: Alexei Starovoitov Cc: He Kuang cc: Jiri Olsa Cc: Masami Hiramatsu Cc:

[PATCH 05/13] perf tools: Add comment explaining the repsep_snprintf function

From: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-4j67nvlfwbnkg85b969ew...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/sort.c | 10 +- 1 file changed, 9 insertions(+), 1

[PATCH 12/13] perf data: Fix releasing event_class

From: Wang Nan A new patch in libbabeltrace [1] reveals a object leak problem in 'perf data' CTF support: perf code never releases the event_class which is allocated in add_event() and stored in evsel's private field. If libbabeltrace has the above patch applied, leaking

Applied "regulator: vexpress: rename vexpress regulator implementation" to the regulator tree

The patch regulator: vexpress: rename vexpress regulator implementation 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

[PATCH 12/13] perf data: Fix releasing event_class

From: Wang Nan A new patch in libbabeltrace [1] reveals a object leak problem in 'perf data' CTF support: perf code never releases the event_class which is allocated in add_event() and stored in evsel's private field. If libbabeltrace has the above patch applied, leaking event_class prevents

Applied "regulator: vexpress: rename vexpress regulator implementation" to the regulator tree

The patch regulator: vexpress: rename vexpress regulator implementation 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

Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'

On Mon, Feb 15, 2016 at 06:12:01PM +0100, Uwe Kleine-König wrote: > Hello Greg, > > On Mon, Feb 15, 2016 at 08:49:37AM -0800, Greg Kroah-Hartman wrote: > > On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-König wrote: > > > Greg, can you drop this patch, or do you need a proper changelog for

Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'

On Mon, Feb 15, 2016 at 06:12:01PM +0100, Uwe Kleine-König wrote: > Hello Greg, > > On Mon, Feb 15, 2016 at 08:49:37AM -0800, Greg Kroah-Hartman wrote: > > On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-König wrote: > > > Greg, can you drop this patch, or do you need a proper changelog for

[PATCH 13/13] perf tests: Fix build on older systems where 'signal' is reserved

From: Arnaldo Carvalho de Melo fixing the following problems, for instance, on RHEL6.7: CC /tmp/build/perf/tests/bp_signal.o cc1: warnings being treated as errors tests/bp_signal.c: In function ‘__event’: tests/bp_signal.c:106: error: declaration of ‘signal’

[PATCH 13/13] perf tests: Fix build on older systems where 'signal' is reserved

From: Arnaldo Carvalho de Melo fixing the following problems, for instance, on RHEL6.7: CC /tmp/build/perf/tests/bp_signal.o cc1: warnings being treated as errors tests/bp_signal.c: In function ‘__event’: tests/bp_signal.c:106: error: declaration of ‘signal’ shadows a global

[PATCH 10/13] perf tools: Free the terms list_head in parse_events__free_terms()

From: Wang Nan Fixing a leak, since code calling parse_events__free_terms() expect it to free the list_head too. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: He Kuang

[PATCH 02/13] perf symbols: Fix symbols searching for module in buildid-cache

From: Wang Nan Before this patch, if a sample is triggered inside a module not in /lib/modules/`uname -r`/, even if the module is in buildid-cache, 'perf report' will still be unable to find the correct symbol. For example: # rm -rf ~/.debug/ # perf buildid-cache -a

[PATCH 10/13] perf tools: Free the terms list_head in parse_events__free_terms()

From: Wang Nan Fixing a leak, since code calling parse_events__free_terms() expect it to free the list_head too. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: He Kuang Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: pi3or...@163.com [ Spun off from another

[PATCH 02/13] perf symbols: Fix symbols searching for module in buildid-cache

From: Wang Nan Before this patch, if a sample is triggered inside a module not in /lib/modules/`uname -r`/, even if the module is in buildid-cache, 'perf report' will still be unable to find the correct symbol. For example: # rm -rf ~/.debug/ # perf buildid-cache -a ./mymodule.ko # perf

[PATCH 01/13] perf config: Add '--system' and '--user' options to select which config file is used

From: Taeung Song The '--system' option means $(sysconfdir)/perfconfig and '--user' means $HOME/.perfconfig. If none is used, both system and user config file are read. E.g.: # perf config [] [options] With an specific config file: # perf config --user |

[PATCH 01/13] perf config: Add '--system' and '--user' options to select which config file is used

From: Taeung Song The '--system' option means $(sysconfdir)/perfconfig and '--user' means $HOME/.perfconfig. If none is used, both system and user config file are read. E.g.: # perf config [] [options] With an specific config file: # perf config --user | --system or both

[PATCH 07/13] perf tools: Unlink entries from terms list

From: Wang Nan We were just freeing them, better unlink and init its nodes to catch bugs faster if we keep dangling references to them. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: He Kuang

[PATCH 06/13] perf hists: Do column alignment on the format iterator

From: Arnaldo Carvalho de Melo We were doing column alignment in the format function for each cell, returning a string padded with spaces so that when the next column is printed the cursor is at its column alignment. This ends up needlessly printing trailing spaces, do it at

Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup

Hello, Michal. On Mon, Feb 15, 2016 at 09:54:38PM +0100, Michal Hocko wrote: > I am not sure I understand. Does that mean that a node with no memory > would have its WQ specific pool? I might be missing something but I Yeah, I think it should. > thought that cpu_to_node will return NUMA_NO_NODE

[PATCH 07/13] perf tools: Unlink entries from terms list

From: Wang Nan We were just freeing them, better unlink and init its nodes to catch bugs faster if we keep dangling references to them. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: He Kuang Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: pi3or...@163.com

[PATCH 06/13] perf hists: Do column alignment on the format iterator

From: Arnaldo Carvalho de Melo We were doing column alignment in the format function for each cell, returning a string padded with spaces so that when the next column is printed the cursor is at its column alignment. This ends up needlessly printing trailing spaces, do it at the format

Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup

Hello, Michal. On Mon, Feb 15, 2016 at 09:54:38PM +0100, Michal Hocko wrote: > I am not sure I understand. Does that mean that a node with no memory > would have its WQ specific pool? I might be missing something but I Yeah, I think it should. > thought that cpu_to_node will return NUMA_NO_NODE

[PATCH 04/13] perf python scripting: Append examples to err msg about audit-libs-python

From: Taeung Song To print syscall names, the audit-libs-python package is required.. If not installed, it prints this error string: # perf script syscall-counts Install the audit-libs-python package to get syscall names. But the package name is different in

[PATCH 04/13] perf python scripting: Append examples to err msg about audit-libs-python

From: Taeung Song To print syscall names, the audit-libs-python package is required.. If not installed, it prints this error string: # perf script syscall-counts Install the audit-libs-python package to get syscall names. But the package name is different in Ubuntu, mention that in the

[PATCH 03/13] perf build: Add EXTRA_LDFLAGS option to makefile

From: Zubair Lutfullah Kakakhel To compile for little-endian systems, you need to pass -EL to CC and LD. EXTRA_CFLAGS works to pass -EL to CC. Add EXTRA_LDFLAGS to pass -EL to LD. Signed-off-by: Zubair Lutfullah Kakakhel Cc: Peter

[PATCH 03/13] perf build: Add EXTRA_LDFLAGS option to makefile

From: Zubair Lutfullah Kakakhel To compile for little-endian systems, you need to pass -EL to CC and LD. EXTRA_CFLAGS works to pass -EL to CC. Add EXTRA_LDFLAGS to pass -EL to LD. Signed-off-by: Zubair Lutfullah Kakakhel Cc: Peter Zijlstra Link:

Re: [PATCH 3/4] Drivers: hv: vmbus: remove code duplication in message handling

2016-02-12 16:42+0100, Vitaly Kuznetsov: > We have 3 functions dealing with messages and they all implement > the same logic to finalize reads, move it to vmbus_signal_eom(). > > Suggested-by: Radim Krcmar Reviewed-by: Radim Krčmář

Re: [PATCH 3/4] Drivers: hv: vmbus: remove code duplication in message handling

2016-02-12 16:42+0100, Vitaly Kuznetsov: > We have 3 functions dealing with messages and they all implement > the same logic to finalize reads, move it to vmbus_signal_eom(). > > Suggested-by: Radim Krcmar Reviewed-by: Radim Krčmář

Re: [PATCH] regulator: vexpress: rename vexpress regulator implementation

On Mon, Feb 15, 2016 at 06:31:29PM +, Sudeep Holla wrote: > Understood. I knew lkml.org is broken if we tried very old links but > expected to work at-least for couple of month old patches. Anyways > hopefully [1] still works. It's not old links in particular AFAICT, just general

Re: [PATCH] regulator: vexpress: rename vexpress regulator implementation

On Mon, Feb 15, 2016 at 06:31:29PM +, Sudeep Holla wrote: > Understood. I knew lkml.org is broken if we tried very old links but > expected to work at-least for couple of month old patches. Anyways > hopefully [1] still works. It's not old links in particular AFAICT, just general

Re: [PATCH 2/4] Drivers: hv: vmbus: avoid wait_for_completion() on crash

2016-02-12 16:42+0100, Vitaly Kuznetsov: > wait_for_completion() may sleep, it enables interrupts and this > is something we really want to avoid on crashes because interrupt > handlers can cause other crashes. Switch to the recently introduced > vmbus_wait_for_unload() doing busy wait instead.

Re: [PATCH 2/4] Drivers: hv: vmbus: avoid wait_for_completion() on crash

2016-02-12 16:42+0100, Vitaly Kuznetsov: > wait_for_completion() may sleep, it enables interrupts and this > is something we really want to avoid on crashes because interrupt > handlers can cause other crashes. Switch to the recently introduced > vmbus_wait_for_unload() doing busy wait instead.

[PATCH v2 3/4] ARM: pxa: add the number of DMA requestor lines

Declare the number of DMA requestor lines per platform : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines This information will be used to activate the DMA flow control or not. Signed-off-by: Robert Jarzmik --- Since

[PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line

The current number of requestor lines is limited to 31. This was an error of a previous commit, as this number is platform dependent, and is actually : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines The previous testing did not reveal the

[PATCH v2 3/4] ARM: pxa: add the number of DMA requestor lines

Declare the number of DMA requestor lines per platform : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines This information will be used to activate the DMA flow control or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property

[PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line

The current number of requestor lines is limited to 31. This was an error of a previous commit, as this number is platform dependent, and is actually : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines The previous testing did not reveal the

[PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property documentation

For pxa based platforms, the number of requestor lines should be specified, so that the driver can check if the flow control should be activated (when a requestor line is asked for) or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property to #dma-requests

[PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property documentation

For pxa based platforms, the number of requestor lines should be specified, so that the driver can check if the flow control should be activated (when a requestor line is asked for) or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property to #dma-requests modify default

[PATCH v2 2/4] dmaengine: mmp-pdma: add number of requestors

The DMA chip has a fixed number of requestor lines used for flow control. This number is platform dependent. The pxa_dma dma driver will use this value to activate or not the flow control. There won't be any impact on mmp_pdma driver. Signed-off-by: Robert Jarzmik ---

[PATCH v2 2/4] dmaengine: mmp-pdma: add number of requestors

The DMA chip has a fixed number of requestor lines used for flow control. This number is platform dependent. The pxa_dma dma driver will use this value to activate or not the flow control. There won't be any impact on mmp_pdma driver. Signed-off-by: Robert Jarzmik ---

Re: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant

On Mon, Feb 15, 2016 at 06:31:23PM +0800, Chen-Yu Tsai wrote: > The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221, > though a few LDOs were removed, and a new switch output added. Like the > AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained > to DCDC1 and

Re: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant

On Mon, Feb 15, 2016 at 06:31:23PM +0800, Chen-Yu Tsai wrote: > The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221, > though a few LDOs were removed, and a new switch output added. Like the > AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained > to DCDC1 and

Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup

On Mon 15-02-16 13:21:25, Tejun Heo wrote: > Hello, Michal. > > On Mon, Feb 15, 2016 at 06:33:46PM +0100, Michal Hocko wrote: > > On Wed 10-02-16 10:55:03, Tejun Heo wrote: > > [...] > > > --- a/kernel/workqueue.c > > > +++ b/kernel/workqueue.c > > > @@ -570,6 +570,16 @@ static struct

Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup

On Mon 15-02-16 13:21:25, Tejun Heo wrote: > Hello, Michal. > > On Mon, Feb 15, 2016 at 06:33:46PM +0100, Michal Hocko wrote: > > On Wed 10-02-16 10:55:03, Tejun Heo wrote: > > [...] > > > --- a/kernel/workqueue.c > > > +++ b/kernel/workqueue.c > > > @@ -570,6 +570,16 @@ static struct

Re: [PATCH v2] phy: marvell: Fix and unify reg-init behavior

On Mon, Feb 15, 2016 at 6:01 PM, Clemens Gruber wrote: > +static int marvell_config_init(struct phy_device *phydev) > +{ > + int err; > + > + /* Set registers from marvell,reg-init DT property */ > + err = marvell_of_reg_init(phydev); > + if

Re: [PATCH v2] phy: marvell: Fix and unify reg-init behavior

On Mon, Feb 15, 2016 at 6:01 PM, Clemens Gruber wrote: > +static int marvell_config_init(struct phy_device *phydev) > +{ > + int err; > + > + /* Set registers from marvell,reg-init DT property */ > + err = marvell_of_reg_init(phydev); > + if (err < 0) > +

Re: [PATCH 1/4] Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages

2016-02-12 16:42+0100, Vitaly Kuznetsov: > We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context > and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions > loops to see if there are new messages pending. In case we'll ever see > HVMSG_TIMER_EXPIRED message there

Re: [PATCH 1/4] Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages

2016-02-12 16:42+0100, Vitaly Kuznetsov: > We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context > and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions > loops to see if there are new messages pending. In case we'll ever see > HVMSG_TIMER_EXPIRED message there

Re: [PATCH 1/5] mm, oom: introduce oom reaper

On Sat 06-02-16 22:22:20, Tetsuo Handa wrote: > Michal Hocko wrote: > > There is one notable exception to this, though, if the OOM victim was > > in the process of coredumping the result would be incomplete. This is > > considered a reasonable constrain because the overall system health is > >

Re: [PATCH 1/5] mm, oom: introduce oom reaper

On Sat 06-02-16 22:22:20, Tetsuo Handa wrote: > Michal Hocko wrote: > > There is one notable exception to this, though, if the OOM victim was > > in the process of coredumping the result would be incomplete. This is > > considered a reasonable constrain because the overall system health is > >

Re: [PATCH 3/5] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

On Sat 06-02-16 20:23:43, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > By always waking the OOM reaper up, we can delegate the duty of unlocking > the OOM killer (by clearing TIF_MEMDIE or some other means) to the OOM > reaper because the OOM reaper is tracking all TIF_MEMDIE tasks. And

Re: [PATCH 3/5] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

On Sat 06-02-16 20:23:43, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > By always waking the OOM reaper up, we can delegate the duty of unlocking > the OOM killer (by clearing TIF_MEMDIE or some other means) to the OOM > reaper because the OOM reaper is tracking all TIF_MEMDIE tasks. And

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 8:23 PM, Russell King - ARM Linux wrote: > On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote: >> On 15/02/16 18:54, Rafael J. Wysocki wrote: >> > That would explain it, thanks. >> > >> > So it looks like we should always use

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 8:23 PM, Russell King - ARM Linux wrote: > On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote: >> On 15/02/16 18:54, Rafael J. Wysocki wrote: >> > That would explain it, thanks. >> > >> > So it looks like we should always use irq_work_queue() on UP even if >> >

[PATCH 3.1/5] oom: make oom_reaper freezable

Andrew, this can be either folded into 3/5 patch or go as a standalone one. I would be inclined to have it standalone for the record (the description should be pretty clear about the intention) and because the issue is highly unlikely. OOM during the PM freezer doesn't happen in 99% cases. On Sat

[PATCH 3.1/5] oom: make oom_reaper freezable

Andrew, this can be either folded into 3/5 patch or go as a standalone one. I would be inclined to have it standalone for the record (the description should be pretty clear about the intention) and because the issue is highly unlikely. OOM during the PM freezer doesn't happen in 99% cases. On Sat

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

; >>>> >>>> https://kernelci.org/boot/all/job/next/kernel/next-20160215/ >>>> >>>> The SMP ones seem to fail with some regulator issues? >>>> >>> >>> There is another problem, introduced with 6a0712f6f199e ("PM

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Monday 15 February 2016 21:56:42 Viresh Kumar wrote: > We are currently required to do two checks for regulator pointer: > IS_ERR() and IS_NULL(). > > And multiple instances are reported, about both of these not being used > consistently and so resulting in crashes. > > Fix that by

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 9:09 PM, Guenter Roeck wrote: > On 02/15/2016 11:58 AM, Tony Lindgren wrote: >> >> * Guenter Roeck [160215 11:41]: >>> >>> On 02/15/2016 11:01 AM, Tony Lindgren wrote: >>>> >>>> >>>> https://kernelci.or

Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value

On Monday 15 February 2016 21:56:42 Viresh Kumar wrote: > We are currently required to do two checks for regulator pointer: > IS_ERR() and IS_NULL(). > > And multiple instances are reported, about both of these not being used > consistently and so resulting in crashes. > > Fix that by

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren <t...@atomide.com> wrote: > * Guenter Roeck <li...@roeck-us.net> [160215 11:41]: >> On 02/15/2016 11:01 AM, Tony Lindgren wrote: >> > >> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/ >&

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren wrote: > * Guenter Roeck [160215 11:41]: >> On 02/15/2016 11:01 AM, Tony Lindgren wrote: >> > >> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/ >> > >> >The SMP ones seem to fail with some

Hi lkml

Good morning lkml http://www.drewlin.me/pitch.php?cause=1va2u3y80rqgv Badari Pulavarty

Hi lkml

Good morning lkml http://www.drewlin.me/pitch.php?cause=1va2u3y80rqgv Badari Pulavarty

Applied "regulator: hi655x: Document for hi655x regulator" to the regulator tree

The patch regulator: hi655x: Document for hi655x regulator 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 "regulator: hi655x: Document for hi655x regulator" to the regulator tree

The patch regulator: hi655x: Document for hi655x regulator 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 "regulator: hi655x: enable regulator for hi655x PMIC" to the regulator tree

The patch regulator: hi655x: enable regulator for hi655x PMIC 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

Applied "regulator: hi655x: enable regulator for hi655x PMIC" to the regulator tree

The patch regulator: hi655x: enable regulator for hi655x PMIC 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

[PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property documentation

For pxa based platforms, the number of requestor lines should be specified, so that the driver can check if the flow control should be activated (when a requestor line is asked for) or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property to #dma-requests

[PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property documentation

For pxa based platforms, the number of requestor lines should be specified, so that the driver can check if the flow control should be activated (when a requestor line is asked for) or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property to #dma-requests modify default

Re: [PATCH 2/4] block: check virt boundary in bio_will_gap()

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 4571ef1..b8ff6a3 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -1388,7 +1388,7 @@ static inline bool bvec_gap_to_prev(struct request_queue *q, static inline bool bio_will_gap(struct request_queue *q,

Re: [PATCH 2/4] block: check virt boundary in bio_will_gap()

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 4571ef1..b8ff6a3 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -1388,7 +1388,7 @@ static inline bool bvec_gap_to_prev(struct request_queue *q, static inline bool bio_will_gap(struct request_queue *q,

Re: About support XZ-compressed kernel on x86

On 2016-02-14 Baoquan He wrote: > On 02/13/16 at 08:57pm, Lasse Collin wrote: > > The long comment in arch/x86/boot/compressed/misc.c explains the > > need for the offset for gzip/Deflate. A similar comment in > > lib/decompress_unxz.c explains it for XZ/LZMA2. > > Thank you so much, Lasse. You

Re: About support XZ-compressed kernel on x86

On 2016-02-14 Baoquan He wrote: > On 02/13/16 at 08:57pm, Lasse Collin wrote: > > The long comment in arch/x86/boot/compressed/misc.c explains the > > need for the offset for gzip/Deflate. A similar comment in > > lib/decompress_unxz.c explains it for XZ/LZMA2. > > Thank you so much, Lasse. You

Applied "regmap: irq: add devm apis for regmap_{add,del}_irq_chip" to the regmap tree

The patch regmap: irq: add devm apis for regmap_{add,del}_irq_chip 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: irq: add devm apis for regmap_{add,del}_irq_chip" to the regmap tree

The patch regmap: irq: add devm apis for regmap_{add,del}_irq_chip 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] branch tracer: fix freak link error

On Mon, 15 Feb 2016 21:15:39 +0100 Arnd Bergmann wrote: > Do you also want to add a 'Cc: sta...@vger.kernel.org' tag? > I currently have this in the Tags: Acked-by: Nicolas Pitre Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with

Applied "regulator: axp20x: Use of_match name as default regulator name" to the regulator tree

The patch regulator: axp20x: Use of_match name as default regulator name 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

Re: [PATCH] branch tracer: fix freak link error

On Mon, 15 Feb 2016 21:15:39 +0100 Arnd Bergmann wrote: > Do you also want to add a 'Cc: sta...@vger.kernel.org' tag? > I currently have this in the Tags: Acked-by: Nicolas Pitre Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y") Cc:

Applied "regulator: axp20x: Use of_match name as default regulator name" to the regulator tree

The patch regulator: axp20x: Use of_match name as default regulator name 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

Re: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface

On Monday 15 February 2016 17:01:09 Lars-Peter Clausen wrote: > On 02/15/2016 04:46 PM, Arnd Bergmann wrote: > > +static inline __deprecated int irq_to_gpio(unsigned int irq) > > +{ > > + /* this has clearly not worked for a long time */ > > + return -EINVAL; > > +} > > + > > #define

Re: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface

On Monday 15 February 2016 17:01:09 Lars-Peter Clausen wrote: > On 02/15/2016 04:46 PM, Arnd Bergmann wrote: > > +static inline __deprecated int irq_to_gpio(unsigned int irq) > > +{ > > + /* this has clearly not worked for a long time */ > > + return -EINVAL; > > +} > > + > > #define

Re: [PATCH] branch tracer: fix freak link error

On Monday 15 February 2016 12:47:46 Steven Rostedt wrote: > On Fri, 12 Feb 2016 22:26:42 +0100 > Arnd Bergmann wrote: > > > In my randconfig tests, I came across a bug that involves several > > components: > > > > > > [..] > > > > > This patch avoids the problem by changing

Re: [PATCH] branch tracer: fix freak link error

On Monday 15 February 2016 12:47:46 Steven Rostedt wrote: > On Fri, 12 Feb 2016 22:26:42 +0100 > Arnd Bergmann wrote: > > > In my randconfig tests, I came across a bug that involves several > > components: > > > > > > [..] > > > > > This patch avoids the problem by changing __trace_if() to

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

On Sun 07-02-16 00:33:38, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sat 06-02-16 14:54:24, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > > But if we consider non system-wide OOM events, it is not very > > > > > unlikely to hit > > > > > this race. This queue is useful for

Re: [PATCH 5/5] mm, oom_reaper: implement OOM victims queuing

On Sun 07-02-16 00:33:38, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sat 06-02-16 14:54:24, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > > But if we consider non system-wide OOM events, it is not very > > > > > unlikely to hit > > > > > this race. This queue is useful for

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 02/15/2016 11:58 AM, Tony Lindgren wrote: * Guenter Roeck <li...@roeck-us.net> [160215 11:41]: On 02/15/2016 11:01 AM, Tony Lindgren wrote: https://kernelci.org/boot/all/job/next/kernel/next-20160215/ The SMP ones seem to fail with some regulator issues? There is another p

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On 02/15/2016 11:58 AM, Tony Lindgren wrote: * Guenter Roeck [160215 11:41]: On 02/15/2016 11:01 AM, Tony Lindgren wrote: https://kernelci.org/boot/all/job/next/kernel/next-20160215/ The SMP ones seem to fail with some regulator issues? There is another problem, introduced

[media 7/7] PCI bridge driver for PT3 & PXQ3PE

From: Буди Романто, AreMa Inc Signed-off-by: Буди Романто, AreMa Inc --- drivers/media/pci/Kconfig | 2 +- drivers/media/pci/Makefile | 2 +- drivers/media/pci/ptx/Kconfig | 21 ++ drivers/media/pci/ptx/Makefile | 8 +

[media 7/7] PCI bridge driver for PT3 & PXQ3PE

From: Буди Романто, AreMa Inc Signed-off-by: Буди Романто, AreMa Inc --- drivers/media/pci/Kconfig | 2 +- drivers/media/pci/Makefile | 2 +- drivers/media/pci/ptx/Kconfig | 21 ++ drivers/media/pci/ptx/Makefile | 8 + drivers/media/pci/ptx/pt3_pci.c| 509

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

Cc Kent and Keith. Follows another version which should be more efficient. Kent and Keith, I appreciate much if you may give a review on it. diff --git a/include/linux/bio.h b/include/linux/bio.h index 56d2db8..ef45fec 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -278,11

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

Cc Kent and Keith. Follows another version which should be more efficient. Kent and Keith, I appreciate much if you may give a review on it. diff --git a/include/linux/bio.h b/include/linux/bio.h index 56d2db8..ef45fec 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -278,11

Re: [PATCH 0/3] OOM detection rework v4

On Sun 07-02-16 13:09:33, Tetsuo Handa wrote: [...] > FYI, I again hit unexpected OOM-killer during genxref on linux-4.5-rc2 source. > I think current patchset is too fragile to merge. > > [ 3101.626995] smbd invoked oom-killer: >

Re: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events

On Mon, Feb 15, 2016 at 07:40:37PM +, Will Deacon wrote: > On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote: > > The implemented Cortex A57 events are not A57 specific. > > They are recommended by ARM and can be found on other > > ARMv8 SOCs like Cavium ThunderX too. Therefore move

Re: [PATCH 0/3] OOM detection rework v4

On Sun 07-02-16 13:09:33, Tetsuo Handa wrote: [...] > FYI, I again hit unexpected OOM-killer during genxref on linux-4.5-rc2 source. > I think current patchset is too fragile to merge. > > [ 3101.626995] smbd invoked oom-killer: >

Re: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events

On Mon, Feb 15, 2016 at 07:40:37PM +, Will Deacon wrote: > On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote: > > The implemented Cortex A57 events are not A57 specific. > > They are recommended by ARM and can be found on other > > ARMv8 SOCs like Cavium ThunderX too. Therefore move

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