[PATCH] clocksource: time-orion: Unmap region obtained by of_iomap

Free memory mapping, if orion_timer_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/time-orion.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/time-orion.c

[PATCH] clocksource: time-orion: Unmap region obtained by of_iomap

Free memory mapping, if orion_timer_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/time-orion.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c index

RE: Address already in use problem

From: Neil Horman > Sent: 21 September 2016 16:43 > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > > Hi > > > > we have an SCTP application running in JAVA. and we found that there > > is a problem when we as a client trying to connect to a remote IP > > address. > > > > If the remote

RE: Address already in use problem

From: Neil Horman > Sent: 21 September 2016 16:43 > On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > > Hi > > > > we have an SCTP application running in JAVA. and we found that there > > is a problem when we as a client trying to connect to a remote IP > > address. > > > > If the remote

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

On Wed 2016-09-21 14:38:13, Matt Fleming wrote: > There's no diagnostic checks for figuring out when we've accidentally > missed update_rq_clock() calls. Let's add some by piggybacking on the > rq_*pin_lock() wrappers. > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

On Wed 2016-09-21 14:38:13, Matt Fleming wrote: > There's no diagnostic checks for figuring out when we've accidentally > missed update_rq_clock() calls. Let's add some by piggybacking on the > rq_*pin_lock() wrappers. > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index

Re: [PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific functions

On Wed, Sep 21, 2016 at 02:55:27PM +0200, Ingo Molnar wrote: > > * Andrew Banman wrote: > > > Add the UV4-specific function definitions and define an operations struct > > to implement them in the BAU driver. > > > > Many BAU MMRs, although functionally the same, have new

Re: [PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific functions

On Wed, Sep 21, 2016 at 02:55:27PM +0200, Ingo Molnar wrote: > > * Andrew Banman wrote: > > > Add the UV4-specific function definitions and define an operations struct > > to implement them in the BAU driver. > > > > Many BAU MMRs, although functionally the same, have new addresses on UV4 > >

[PATCH v7 5/6] perf annotate: Fix jump target outside of function address range

If jump target is outside of function range, perf is not handling it correctly. Especially when target address is lesser than function start address, target offset will be negative. But, target address declared to be unsigned, converts negative number into 2's complement. See below example. Here

[PATCH v7 3/6] perf annotate: Show raw form for jump instruction with indirect target

For jump instructions that does not include target address as direct operand, use raw value for that. This is needed for certain powerpc jump instructions that use target address in a register (such as bctr, btar, ...). Before: ld r12,32088(r12) mtctr r12 v bctr

[PATCH v7 6/6] perf annotate: cross arch annotate support fixes for ARM

From: Kim Phillips For ARM we remove the list that contains non-arm insns, and instead add more maintainable branch instruction regex logic. Signed-off-by: Kim Phillips Signed-off-by: Ravi Bangoria --- Changes in

[PATCH v7 5/6] perf annotate: Fix jump target outside of function address range

If jump target is outside of function range, perf is not handling it correctly. Especially when target address is lesser than function start address, target offset will be negative. But, target address declared to be unsigned, converts negative number into 2's complement. See below example. Here

[PATCH v7 3/6] perf annotate: Show raw form for jump instruction with indirect target

For jump instructions that does not include target address as direct operand, use raw value for that. This is needed for certain powerpc jump instructions that use target address in a register (such as bctr, btar, ...). Before: ld r12,32088(r12) mtctr r12 v bctr

[PATCH v7 6/6] perf annotate: cross arch annotate support fixes for ARM

From: Kim Phillips For ARM we remove the list that contains non-arm insns, and instead add more maintainable branch instruction regex logic. Signed-off-by: Kim Phillips Signed-off-by: Ravi Bangoria --- Changes in v7: - Little bit change in initializing instruction list.

[PATCH v7 4/6] perf annotate: Support jump instruction with target as second operand

Current perf is not able to parse jump instruction when second operand contains target address. Arch like powerpc has such instructions. For example, 'bne cr7,0xc00f6154'. objdump o/p: c00f6140: ld r9,1032(r31) c00f6144: cmpdi cr7,r9,0 c00f6148:

[PATCH v7 2/6] perf annotate: Add support for powerpc

From: "Naveen N. Rao" Current perf can disassemble annotated function but it does not have parsing logic for powerpc instructions. So all navigation options are not available for powerpc. Apart from that, Powerpc has long list of branch instructions and

[PATCH v7 4/6] perf annotate: Support jump instruction with target as second operand

Current perf is not able to parse jump instruction when second operand contains target address. Arch like powerpc has such instructions. For example, 'bne cr7,0xc00f6154'. objdump o/p: c00f6140: ld r9,1032(r31) c00f6144: cmpdi cr7,r9,0 c00f6148:

[PATCH v7 2/6] perf annotate: Add support for powerpc

From: "Naveen N. Rao" Current perf can disassemble annotated function but it does not have parsing logic for powerpc instructions. So all navigation options are not available for powerpc. Apart from that, Powerpc has long list of branch instructions and hardcoding them in table appears to be

[PATCH v7 1/6] perf annotate: Add cross arch annotate support

Change current data structures and function to enable cross arch annotate. Current perf implementation does not support cross arch annotate. To make it truly cross arch, instruction table of all arch should be present in perf binary. And use appropriate table based on arch where perf.data was

[PATCH v7 1/6] perf annotate: Add cross arch annotate support

Change current data structures and function to enable cross arch annotate. Current perf implementation does not support cross arch annotate. To make it truly cross arch, instruction table of all arch should be present in perf binary. And use appropriate table based on arch where perf.data was

[PATCH v7 0/6] perf annotate: Cross arch support + few fixes

Currently Perf annotate support code navigation (branches and calls) only when run on the same architecture where perf.data was recorded. But, for example, record on powerpc server and annotate on client's x86 desktop is not supported. This patchset adds supports for that. Example: Record on

[PATCH v7 0/6] perf annotate: Cross arch support + few fixes

Currently Perf annotate support code navigation (branches and calls) only when run on the same architecture where perf.data was recorded. But, for example, record on powerpc server and annotate on client's x86 desktop is not supported. This patchset adds supports for that. Example: Record on

[PATCH 2/2] sched: do not call workqueue sleep hook if task is already dead

If panic_on_oops is not set and oops happens inside workqueue kthread, kernel kills this kthread. Current patch fixes recursive GPF which happens in that case with the following stack: [] dump_stack+0x68/0x93 [] ? do_exit+0x7ab/0xc10 [] __schedule_bug+0x83/0xe0 [] __schedule+0x7ea/0xba0

[PATCH 1/2] x86/dumpstack: on oops do not rewind stack for kthread

kthread uses stack and keeps completion structure on it to be woken up on vfork_done completion. In commit 2deb4be28 Andy Lutomirski rewinds the stack unconditionally and further completion of task->vfork_done for any kthread leads to stack corruption (or infinite spin on attempt to spin lock on

[PATCH 2/2] sched: do not call workqueue sleep hook if task is already dead

If panic_on_oops is not set and oops happens inside workqueue kthread, kernel kills this kthread. Current patch fixes recursive GPF which happens in that case with the following stack: [] dump_stack+0x68/0x93 [] ? do_exit+0x7ab/0xc10 [] __schedule_bug+0x83/0xe0 [] __schedule+0x7ea/0xba0

[PATCH 1/2] x86/dumpstack: on oops do not rewind stack for kthread

kthread uses stack and keeps completion structure on it to be woken up on vfork_done completion. In commit 2deb4be28 Andy Lutomirski rewinds the stack unconditionally and further completion of task->vfork_done for any kthread leads to stack corruption (or infinite spin on attempt to spin lock on

Re: [PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem

On Wed, Sep 21, 2016 at 04:35:14PM +0100, Ard Biesheuvel wrote: > Since I will be co-maintaining the EFI subsystem, it makes sense to > mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS > so that Matt, the list and I get cc'ed on proposed changes. > > Cc: Catalin Marinas

Re: [PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem

On Wed, Sep 21, 2016 at 04:35:14PM +0100, Ard Biesheuvel wrote: > Since I will be co-maintaining the EFI subsystem, it makes sense to > mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS > so that Matt, the list and I get cc'ed on proposed changes. > > Cc: Catalin Marinas > Cc:

Re: Address already in use problem

On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > Hi > > we have an SCTP application running in JAVA. and we found that there > is a problem when we as a client trying to connect to a remote IP > address. > > If the remote IP address is not accessible, our application will keep >

Re: Address already in use problem

On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote: > Hi > > we have an SCTP application running in JAVA. and we found that there > is a problem when we as a client trying to connect to a remote IP > address. > > If the remote IP address is not accessible, our application will keep >

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, 21 Sep, at 04:35:13PM, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc: Matt Fleming

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, 21 Sep, at 04:35:13PM, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc: Matt Fleming > Signed-off-by:

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, Sep 21, 2016 at 04:35:13PM +0100, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc: Matt Fleming

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, Sep 21, 2016 at 04:35:13PM +0100, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc: Matt Fleming >

Re: [BUG] perf report --pid not reporting correctly

Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: > Hi Arnaldo, > > I ran into an issue trying to use the --pid filtering option of perf report. > > I do a system-wide collection and then I want to narrow down the > reporting to a specific process: > > $ perf record -a -e

Re: [BUG] perf report --pid not reporting correctly

Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: > Hi Arnaldo, > > I ran into an issue trying to use the --pid filtering option of perf report. > > I do a system-wide collection and then I want to narrow down the > reporting to a specific process: > > $ perf record -a -e

Re: [PATCH 05/61] perf tools: Introduce c2c_decode_stats function

On Wed, Sep 21, 2016 at 11:16:26AM -0400, Don Zickus wrote: > On Wed, Sep 21, 2016 at 11:18:29AM +0200, Jiri Olsa wrote: > > On Wed, Sep 21, 2016 at 09:08:40AM +, Stanislav Ievlev wrote: > > > Hi, Jiri! > > > > > > Why are you not using unsigned integer for counters in c2c_stats > > >

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

I'm thinking about the case where you want to merge traces from L0 and L2. If the user code in L0 always knew the TSC offset of the current VMCS, rather than the TSC offset of the L1 VMCS, this would be trivial, regardless of the nature of L1. On Wed, Sep 21, 2016 at 8:22 AM, Paolo Bonzini

Re: [PATCH 05/61] perf tools: Introduce c2c_decode_stats function

On Wed, Sep 21, 2016 at 11:16:26AM -0400, Don Zickus wrote: > On Wed, Sep 21, 2016 at 11:18:29AM +0200, Jiri Olsa wrote: > > On Wed, Sep 21, 2016 at 09:08:40AM +, Stanislav Ievlev wrote: > > > Hi, Jiri! > > > > > > Why are you not using unsigned integer for counters in c2c_stats > > >

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

I'm thinking about the case where you want to merge traces from L0 and L2. If the user code in L0 always knew the TSC offset of the current VMCS, rather than the TSC offset of the L1 VMCS, this would be trivial, regardless of the nature of L1. On Wed, Sep 21, 2016 at 8:22 AM, Paolo Bonzini

[PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem

Since I will be co-maintaining the EFI subsystem, it makes sense to mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS so that Matt, the list and I get cc'ed on proposed changes. Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King

[PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem

Since I will be co-maintaining the EFI subsystem, it makes sense to mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS so that Matt, the list and I get cc'ed on proposed changes. Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Signed-off-by: Ard Biesheuvel ---

[PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

At the request of Matt, I am taking up co-maintainership of the EFI subsystem. So add my name to the EFI section in MAINTAINERS, and change the SCM tree reference to point to the new shared Git repo. Cc: Matt Fleming Signed-off-by: Ard Biesheuvel

[PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

At the request of Matt, I am taking up co-maintainership of the EFI subsystem. So add my name to the EFI section in MAINTAINERS, and change the SCM tree reference to point to the new shared Git repo. Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- MAINTAINERS | 3 ++- 1 file changed, 2

strace lockup when tracing exec in go

[I am CCing strace mailing list because even if this turns out to be a kernel bug strace seems to be doing something unexpected - more on that below] Hi, Aleksa has reported the following lockup when stracing the following go program % cat exec.go package main import ( "os" "syscall"

strace lockup when tracing exec in go

[I am CCing strace mailing list because even if this turns out to be a kernel bug strace seems to be doing something unexpected - more on that below] Hi, Aleksa has reported the following lockup when stracing the following go program % cat exec.go package main import ( "os" "syscall"

[PATCH] clocksource: vf_pit_timer: Unmap region obtained by of_iomap

Free memory mapping, if pit_timer_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/vf_pit_timer.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/vf_pit_timer.c

Re: [PATCH 03/61] perf tools: Make hist_entry__snprintf work over struct perf_hpp_list

On Wed, Sep 21, 2016 at 12:14:32PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 19, 2016 at 03:09:12PM +0200, Jiri Olsa escreveu: > > Make hist_entry__snprintf to take perf_hpp_list as an argument > > instead of using he->hists->hpp_list. This way we can display > > arbitrary list of

Re: [PATCH 03/61] perf tools: Make hist_entry__snprintf work over struct perf_hpp_list

On Wed, Sep 21, 2016 at 12:14:32PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 19, 2016 at 03:09:12PM +0200, Jiri Olsa escreveu: > > Make hist_entry__snprintf to take perf_hpp_list as an argument > > instead of using he->hists->hpp_list. This way we can display > > arbitrary list of

[PATCH] clocksource: vf_pit_timer: Unmap region obtained by of_iomap

Free memory mapping, if pit_timer_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/vf_pit_timer.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/clocksource/vf_pit_timer.c b/drivers/clocksource/vf_pit_timer.c index

Re: [PATCH v2 1/9] ext4: allow DAX writeback for hole punch

On Tue, Aug 23, 2016 at 04:04:11PM -0600, Ross Zwisler wrote: > Currently when doing a DAX hole punch with ext4 we fail to do a writeback. > This is because the logic around filemap_write_and_wait_range() in > ext4_punch_hole() only looks for dirty page cache pages in the radix tree, > not for

Re: [PATCH v2 1/9] ext4: allow DAX writeback for hole punch

On Tue, Aug 23, 2016 at 04:04:11PM -0600, Ross Zwisler wrote: > Currently when doing a DAX hole punch with ext4 we fail to do a writeback. > This is because the logic around filemap_write_and_wait_range() in > ext4_punch_hole() only looks for dirty page cache pages in the radix tree, > not for

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

On 21/09/2016 17:19, Jim Mattson wrote: > Doesn't that assume you can run the merge program in L1? You only need the TSC offset, but we should make sure that L0 tracepoints contain enough information to figure out the L0->L2 TSC offsets (they are the values in VMCS02). That said, how would you

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

On 21/09/2016 17:19, Jim Mattson wrote: > Doesn't that assume you can run the merge program in L1? You only need the TSC offset, but we should make sure that L0 tracepoints contain enough information to figure out the L0->L2 TSC offsets (they are the values in VMCS02). That said, how would you

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

Doesn't that assume you can run the merge program in L1? On Mon, Sep 19, 2016 at 10:37 PM, Paolo Bonzini wrote: > > > On 20/09/2016 00:18, Jim Mattson wrote: >> Hmmm. Yes, I think it does. With this patch series, >> vcpu->arch.tsc_offset appears to contain L1's TSC offset

Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()

Doesn't that assume you can run the merge program in L1? On Mon, Sep 19, 2016 at 10:37 PM, Paolo Bonzini wrote: > > > On 20/09/2016 00:18, Jim Mattson wrote: >> Hmmm. Yes, I think it does. With this patch series, >> vcpu->arch.tsc_offset appears to contain L1's TSC offset (perhaps >> making

[PATCH] clocksource: timer-sp804: Unmap region obtained by of_iomap

Free memory mapping, if integrator_cp_of_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/timer-sp804.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/timer-sp804.c b/drivers/clocksource/timer-sp804.c index

[PATCH] clocksource: timer-sp804: Unmap region obtained by of_iomap

Free memory mapping, if integrator_cp_of_init is not successful. Signed-off-by: Arvind Yadav --- drivers/clocksource/timer-sp804.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clocksource/timer-sp804.c b/drivers/clocksource/timer-sp804.c index d078633..419995d 100644 ---

RE: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

>From: Arnd Bergmann [mailto:a...@arndb.de] >On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote: >> >> Hello Arnd, >> >> We tried this patch on NXP platforms (ls2085 and ls1043) which use >> dwc3 controller without any glue layer. On first go, this did not >> work. But after

RE: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

>From: Arnd Bergmann [mailto:a...@arndb.de] >On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote: >> >> Hello Arnd, >> >> We tried this patch on NXP platforms (ls2085 and ls1043) which use >> dwc3 controller without any glue layer. On first go, this did not >> work. But after

Re: [PATCH 05/61] perf tools: Introduce c2c_decode_stats function

On Wed, Sep 21, 2016 at 11:18:29AM +0200, Jiri Olsa wrote: > On Wed, Sep 21, 2016 at 09:08:40AM +, Stanislav Ievlev wrote: > > Hi, Jiri! > > > > Why are you not using unsigned integer for counters in c2c_stats structure? > > hi, > never really thought of that, because that's one of the

Re: [PATCH 05/61] perf tools: Introduce c2c_decode_stats function

On Wed, Sep 21, 2016 at 11:18:29AM +0200, Jiri Olsa wrote: > On Wed, Sep 21, 2016 at 09:08:40AM +, Stanislav Ievlev wrote: > > Hi, Jiri! > > > > Why are you not using unsigned integer for counters in c2c_stats structure? > > hi, > never really thought of that, because that's one of the

Re: [PATCH 04/61] perf tools: Use bigger buffer for stdio headers

Em Mon, Sep 19, 2016 at 03:09:13PM +0200, Jiri Olsa escreveu: > With node column on big CPUs servers we can run out > of stdio header space quite soon. Enlarging header > buffer. Applied. - Arnaldo > Link: http://lkml.kernel.org/n/tip-p55193hynw8mmok6i2o1w...@git.kernel.org > Signed-off-by:

Re: [PATCH 04/61] perf tools: Use bigger buffer for stdio headers

Em Mon, Sep 19, 2016 at 03:09:13PM +0200, Jiri Olsa escreveu: > With node column on big CPUs servers we can run out > of stdio header space quite soon. Enlarging header > buffer. Applied. - Arnaldo > Link: http://lkml.kernel.org/n/tip-p55193hynw8mmok6i2o1w...@git.kernel.org > Signed-off-by:

Re: [PATCH 02/61] perf tools: Remove superfluous initialization of weight

Em Mon, Sep 19, 2016 at 03:09:11PM +0200, Jiri Olsa escreveu: > Removing superfluous initialization of weight, > it's already set to 0 via memset. Thanks, applied. > Link: http://lkml.kernel.org/n/tip-1fmf7sw8p16zwl9q6au10...@git.kernel.org > Signed-off-by: Jiri Olsa > --- >

Re: [PATCH 02/61] perf tools: Remove superfluous initialization of weight

Em Mon, Sep 19, 2016 at 03:09:11PM +0200, Jiri Olsa escreveu: > Removing superfluous initialization of weight, > it's already set to 0 via memset. Thanks, applied. > Link: http://lkml.kernel.org/n/tip-1fmf7sw8p16zwl9q6au10...@git.kernel.org > Signed-off-by: Jiri Olsa > --- >

Re: [PATCH 03/61] perf tools: Make hist_entry__snprintf work over struct perf_hpp_list

Em Mon, Sep 19, 2016 at 03:09:12PM +0200, Jiri Olsa escreveu: > Make hist_entry__snprintf to take perf_hpp_list as an argument > instead of using he->hists->hpp_list. This way we can display > arbitrary list of entries regardles of the hists setup, which > will be useful in following patches. > >

Re: [PATCH 03/61] perf tools: Make hist_entry__snprintf work over struct perf_hpp_list

Em Mon, Sep 19, 2016 at 03:09:12PM +0200, Jiri Olsa escreveu: > Make hist_entry__snprintf to take perf_hpp_list as an argument > instead of using he->hists->hpp_list. This way we can display > arbitrary list of entries regardles of the hists setup, which > will be useful in following patches. > >

Re: [PATCH v2 1/1] mm/hugetlb: fix memory offline with hugepage size > memory block size

On Wed, 21 Sep 2016 21:17:29 +0800 Rui Teng wrote: > > /* > > * Dissolve free hugepages in a given pfn range. Used by memory hotplug to > > * make specified memory blocks removable from the system. > > - * Note that start_pfn should aligned with (minimum)

Re: [PATCH v2 1/1] mm/hugetlb: fix memory offline with hugepage size > memory block size

On Wed, 21 Sep 2016 21:17:29 +0800 Rui Teng wrote: > > /* > > * Dissolve free hugepages in a given pfn range. Used by memory hotplug to > > * make specified memory blocks removable from the system. > > - * Note that start_pfn should aligned with (minimum) hugepage size. > > + * Note that

[PATCH -next] gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

From: Wei Yongjun Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). Generated by: scripts/coccinelle/api/err_cast.cocci Signed-off-by: Wei Yongjun --- drivers/gpu/ipu-v3/ipu-image-convert.c | 2 +- 1 file changed, 1 insertion(+),

Re: EFI co-maintainer

On Wed, Sep 21, 2016 at 4:09 PM, Matt Fleming wrote: > Folks, > > I've asked, and Ard has agreed to step up and help me co-maintain the > EFI subsystem. > > Given that there are now two maintainers, we're moving to a shared git > repository on kernel.org, hosted at, > >

[PATCH -next] gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

From: Wei Yongjun Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). Generated by: scripts/coccinelle/api/err_cast.cocci Signed-off-by: Wei Yongjun --- drivers/gpu/ipu-v3/ipu-image-convert.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: EFI co-maintainer

On Wed, Sep 21, 2016 at 4:09 PM, Matt Fleming wrote: > Folks, > > I've asked, and Ard has agreed to step up and help me co-maintain the > EFI subsystem. > > Given that there are now two maintainers, we're moving to a shared git > repository on kernel.org, hosted at, > >

Re: [PATCH] ptp_clock: future-proofing drivers against PTP subsystem becoming optional

On 21/09/16 00:25, Nicolas Pitre wrote: > Drivers must be ready to accept NULL from ptp_clock_register() if the > PTP clock subsystem is configured out. > > This patch documents that and ensures that all drivers cope well > with a NULL return. > > Signed-off-by: Nicolas Pitre >

Re: [PATCH] ptp_clock: future-proofing drivers against PTP subsystem becoming optional

On 21/09/16 00:25, Nicolas Pitre wrote: > Drivers must be ready to accept NULL from ptp_clock_register() if the > PTP clock subsystem is configured out. > > This patch documents that and ensures that all drivers cope well > with a NULL return. > > Signed-off-by: Nicolas Pitre > Reviewed-by:

EFI co-maintainer

Folks, I've asked, and Ard has agreed to step up and help me co-maintain the EFI subsystem. Given that there are now two maintainers, we're moving to a shared git repository on kernel.org, hosted at, git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git Expect a MAINTAINERS patch soon.

EFI co-maintainer

Folks, I've asked, and Ard has agreed to step up and help me co-maintain the EFI subsystem. Given that there are now two maintainers, we're moving to a shared git repository on kernel.org, hosted at, git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git Expect a MAINTAINERS patch soon.

[PATCH -next] soc: mediatek: PMIC wrap: fix missing clk_disable_unprepare() on error in pwrap_probe()

From: Wei Yongjun Fix the missing clk_disable_unprepare() before return from pwrap_probe() in the error handling case. Signed-off-by: Wei Yongjun --- drivers/soc/mediatek/mtk-pmic-wrap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH -next] soc: mediatek: PMIC wrap: fix missing clk_disable_unprepare() on error in pwrap_probe()

From: Wei Yongjun Fix the missing clk_disable_unprepare() before return from pwrap_probe() in the error handling case. Signed-off-by: Wei Yongjun --- drivers/soc/mediatek/mtk-pmic-wrap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c

[PATCH] random: Fix early crash in credit_entropy_bits

From: Jiri Olsa When printing out some early acpi messages I hit bug in work queue code. The system_wq is not initialized at the time acpi_early_init is called and causes irq storm that makes credit_entropy_bits call schedule_work and crash: BUG: unable to handle kernel NULL

[PATCH] random: Fix early crash in credit_entropy_bits

From: Jiri Olsa When printing out some early acpi messages I hit bug in work queue code. The system_wq is not initialized at the time acpi_early_init is called and causes irq storm that makes credit_entropy_bits call schedule_work and crash: BUG: unable to handle kernel NULL pointer

[PATCH v5] soc: qcom: add l2 cache perf events driver

Adds perf events support for L2 cache PMU. The L2 cache PMU driver is named 'l2cache_0' and can be used with perf events to profile L2 events such as cache hits and misses. Signed-off-by: Neil Leeder --- v5: Fold the header and l2-accessors into .c file Use

[PATCH v5] soc: qcom: add l2 cache perf events driver

Adds perf events support for L2 cache PMU. The L2 cache PMU driver is named 'l2cache_0' and can be used with perf events to profile L2 events such as cache hits and misses. Signed-off-by: Neil Leeder --- v5: Fold the header and l2-accessors into .c file Use multi-instance framework for hotplug

[PATCH -next] phy: rockchip-typec: fix non static symbol warnings

From: Wei Yongjun Fixes the following sparse warnings: drivers/phy/phy-rockchip-typec.c:295:16: warning: symbol 'usb3_pll_cfg' was not declared. Should it be static? drivers/phy/phy-rockchip-typec.c:312:16: warning: symbol 'dp_pll_cfg' was not declared. Should it be

[PATCH -next] phy: rockchip-typec: fix non static symbol warnings

From: Wei Yongjun Fixes the following sparse warnings: drivers/phy/phy-rockchip-typec.c:295:16: warning: symbol 'usb3_pll_cfg' was not declared. Should it be static? drivers/phy/phy-rockchip-typec.c:312:16: warning: symbol 'dp_pll_cfg' was not declared. Should it be static? Signed-off-by:

Re: [PATCH] ipmi: Fix ioremap error handling in bt-bmc

On 09/21/2016 12:05 PM, Joel Stanley wrote: > devm_ioremap_resource returns ERR_PTR so we can't check for NULL. Thanks for spotting this. Acked-by: Cédric Le Goater C. > Signed-off-by: Joel Stanley > --- > drivers/char/ipmi/bt-bmc.c | 4 ++-- > 1 file

Re: [PATCH] ipmi: Fix ioremap error handling in bt-bmc

On 09/21/2016 12:05 PM, Joel Stanley wrote: > devm_ioremap_resource returns ERR_PTR so we can't check for NULL. Thanks for spotting this. Acked-by: Cédric Le Goater C. > Signed-off-by: Joel Stanley > --- > drivers/char/ipmi/bt-bmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2

Re: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU

On Tue, 20 Sep 2016, Andrew Banman wrote: > The following patch set adds support for UV4 architecture to the Broadcast > Assist Unit (BAU). Major hardware changes to the BAU require these fixes to > ensure correct operation and to avoid illegal MMR writes. Nice work and aside of the nitpicks

Re: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU

On Tue, 20 Sep 2016, Andrew Banman wrote: > The following patch set adds support for UV4 architecture to the Broadcast > Assist Unit (BAU). Major hardware changes to the BAU require these fixes to > ensure correct operation and to avoid illegal MMR writes. Nice work and aside of the nitpicks

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

Hi Jon, On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter wrote: > On 21/09/16 09:53, Geert Uytterhoeven wrote: >> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote: >>> Some devices may require more than one PM domain to operate and this is >>> not

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

Hi Jon, On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter wrote: > On 21/09/16 09:53, Geert Uytterhoeven wrote: >> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote: >>> Some devices may require more than one PM domain to operate and this is >>> not currently by the PM domain framework. Furthermore,

kredit

Suchen Sie ein Unternehmen Darlehen zu qualifizieren. Wenn ja jetzt bewerben. mit Darlehen Darlehen Zinssatz bei uns heute auf Anita Investmentgesellschaft. per e-Mail an anitaloansfi...@outlook.com

kredit

Suchen Sie ein Unternehmen Darlehen zu qualifizieren. Wenn ja jetzt bewerben. mit Darlehen Darlehen Zinssatz bei uns heute auf Anita Investmentgesellschaft. per e-Mail an anitaloansfi...@outlook.com

Re: [PATCH v5 0/6] Introduce ZONE_CMA

"Aneesh Kumar K.V" writes: > Joonsoo Kim writes: > >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: >>> Joonsoo Kim writes: >>> >>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V >>> >

Re: [PATCH v5 0/6] Introduce ZONE_CMA

"Aneesh Kumar K.V" writes: > Joonsoo Kim writes: > >> On Tue, Aug 30, 2016 at 04:09:37PM +0530, Aneesh Kumar K.V wrote: >>> Joonsoo Kim writes: >>> >>> > 2016-08-29 18:27 GMT+09:00 Aneesh Kumar K.V >>> > : >>> >> js1...@gmail.com writes: >>> >> >>> >>> From: Joonsoo Kim >>> >>> >>> >>>

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

Boris, On 09/21/2016 04:25 PM, Boris Brezillon wrote: > Daniel, Richard, > > On Wed, 21 Sep 2016 11:44:41 +0200 > Daniel Walter wrote: > >> From: Richard Weinberger >> >> Provide a nand_cleanup() function to free all nand related resources >> without

Re: [PATCH v2 02/46] mtd: nand: Provide nand_cleanup() function to free NAND related resources

Boris, On 09/21/2016 04:25 PM, Boris Brezillon wrote: > Daniel, Richard, > > On Wed, 21 Sep 2016 11:44:41 +0200 > Daniel Walter wrote: > >> From: Richard Weinberger >> >> Provide a nand_cleanup() function to free all nand related resources >> without unregistering the mtd device. >> This

[PATCH 1/1] Fix tasks being forgotten for a long time on SMP

Now without HTML >From e9a304ae91fa2a4427bde7d3aea18296d0ebb27f Mon Sep 17 00:00:00 2001 From: Yuriy Romanenko Date: Tue, 20 Sep 2016 17:47:28 -0700 Subject: [PATCH] Fix tasks being forgotten for a long time on SMP Observed occasional very high latency on an embedded

[PATCH 1/1] Fix tasks being forgotten for a long time on SMP

Now without HTML >From e9a304ae91fa2a4427bde7d3aea18296d0ebb27f Mon Sep 17 00:00:00 2001 From: Yuriy Romanenko Date: Tue, 20 Sep 2016 17:47:28 -0700 Subject: [PATCH] Fix tasks being forgotten for a long time on SMP Observed occasional very high latency on an embedded SMP system between a task

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