Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 2:16 PM, Josh Poimboeuf wrote: > > I just started seeing this problem today. I suspect it's a ccache > issue, since it only showed up after ccache was updated. Ahh, I didn't even notice that ccache got updated, but yeah, that makes sense.

[PATCH] [media] VPU: mediatek: Fix return value in case of error

If 'dma_alloc_coherent()' returns NULL, 'vpu_alloc_ext_mem()' will return 0 which means success. Return -ENOMEM instead. Signed-off-by: Christophe JAILLET --- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 2:16 PM, Josh Poimboeuf wrote: > > I just started seeing this problem today. I suspect it's a ccache > issue, since it only showed up after ccache was updated. Ahh, I didn't even notice that ccache got updated, but yeah, that makes sense. Linus

[PATCH] [media] VPU: mediatek: Fix return value in case of error

If 'dma_alloc_coherent()' returns NULL, 'vpu_alloc_ext_mem()' will return 0 which means success. Return -ENOMEM instead. Signed-off-by: Christophe JAILLET --- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 2:14 PM, Josh Poimboeuf wrote: > > Is this with your latest pushed master branch? I have F24, but I don't > see the warning. It is with the latest branch, but I was wrong - it doesn't show up for "allmodconfig", it only shows up for my fairly-minimal

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 2:14 PM, Josh Poimboeuf wrote: > > Is this with your latest pushed master branch? I have F24, but I don't > see the warning. It is with the latest branch, but I was wrong - it doesn't show up for "allmodconfig", it only shows up for my fairly-minimal config on this

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 02:06:03PM -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds > wrote: > > > > So this code is clearly missing the magic to tell gcc that the asm > > needs a frame pointer. > > Independently of that, the objtool

Re: [PATCH 1/1] mm/percpu.c: correct max_distance calculation for pcpu_embed_first_chunk()

On 2016/9/24 3:23, Tejun Heo wrote: > On Sat, Sep 24, 2016 at 02:20:24AM +0800, zijun_hu wrote: >> From: zijun_hu >> >> correct max_distance from (base of the highest group + ai->unit_size) >> to (base of the highest group + the group size) >> >> Signed-off-by: zijun_hu

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 02:06:03PM -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds > wrote: > > > > So this code is clearly missing the magic to tell gcc that the asm > > needs a frame pointer. > > Independently of that, the objtool build seems racy or somehow >

Re: [PATCH 1/1] mm/percpu.c: correct max_distance calculation for pcpu_embed_first_chunk()

On 2016/9/24 3:23, Tejun Heo wrote: > On Sat, Sep 24, 2016 at 02:20:24AM +0800, zijun_hu wrote: >> From: zijun_hu >> >> correct max_distance from (base of the highest group + ai->unit_size) >> to (base of the highest group + the group size) >> >> Signed-off-by: zijun_hu > > Nacked-by: Tejun Heo

Re: [PATCH] softirq: let ksoftirqd do its job

On Fri, Sep 23, 2016 at 06:51:04PM +0200, Jesper Dangaard Brouer wrote: > This is your git tree, right: > https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/ > > Doesn't look like you pushed it yet, or do I need to look at a specific > branch? I mainly work from a local quilt queue

Re: [PATCH] softirq: let ksoftirqd do its job

On Fri, Sep 23, 2016 at 06:51:04PM +0200, Jesper Dangaard Brouer wrote: > This is your git tree, right: > https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/ > > Doesn't look like you pushed it yet, or do I need to look at a specific > branch? I mainly work from a local quilt queue

Re: [PATCH] docs-rst: add inter-document cross references

Hi Jon, Em Wed, 21 Sep 2016 15:44:05 -0600 Jonathan Corbet escreveu: > ...and now I'm thinking that's maybe about enough in docs for 4.9...:) I finished handling the plain text files that, IMHO, should be on either user of development process books. As you're feeling that

Re: [PATCH] docs-rst: add inter-document cross references

Hi Jon, Em Wed, 21 Sep 2016 15:44:05 -0600 Jonathan Corbet escreveu: > ...and now I'm thinking that's maybe about enough in docs for 4.9...:) I finished handling the plain text files that, IMHO, should be on either user of development process books. As you're feeling that there are enough

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 01:33:45PM -0700, Linus Torvalds wrote: > Josh, > > the current F24 toolchain causes > > kernel/signal.o: warning: objtool: .altinstr_replacement+0x54: > call without frame pointer save/setup > > during a regular allmodconfig build. > > Doing an objdump says: > >

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 01:33:45PM -0700, Linus Torvalds wrote: > Josh, > > the current F24 toolchain causes > > kernel/signal.o: warning: objtool: .altinstr_replacement+0x54: > call without frame pointer save/setup > > during a regular allmodconfig build. > > Doing an objdump says: > >

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Thu, 22 Sep 2016, kbuild test robot wrote: > Hi Nicolas, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 7d1e042314619115153a0f6f06e4552c09a50e13 > commit: 461a5e51060c93f5844113f4be9dba513cc92830

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Thu, 22 Sep 2016, kbuild test robot wrote: > Hi Nicolas, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 7d1e042314619115153a0f6f06e4552c09a50e13 > commit: 461a5e51060c93f5844113f4be9dba513cc92830

[PATCH] f2fs: remove dirty inode pages in error path

When getting EIO while handling orphan inodes, we can get some dirty node pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try to flush node pages. But in this case, we should prevent to do that, since we will try again from the start. Signed-off-by: Jaegeuk Kim

[PATCH] f2fs: remove dirty inode pages in error path

When getting EIO while handling orphan inodes, we can get some dirty node pages. Then, f2fs_write_node_pages() called by iput(node_inode) will try to flush node pages. But in this case, we should prevent to do that, since we will try again from the start. Signed-off-by: Jaegeuk Kim ---

[PATCH] drm/nouveau/secboot/gm20b: Fix return value in case of error

If 'ioremap()' returns 0, 'gm20b_tegra_read_wpr()' will return 0 as well, which means success. Return -ENOMEM instead Signed-off-by: Christophe JAILLET --- Not sure that -ENOMEM is the best value. I've taken it because it is often used in such a case. ---

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds wrote: > > So this code is clearly missing the magic to tell gcc that the asm > needs a frame pointer. Independently of that, the objtool build seems racy or somehow fragile. I've now twice gotten into a situation

Re: new objtool warnings again...

On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds wrote: > > So this code is clearly missing the magic to tell gcc that the asm > needs a frame pointer. Independently of that, the objtool build seems racy or somehow fragile. I've now twice gotten into a situation where I end up getting cat:

[PATCH] drm/nouveau/secboot/gm20b: Fix return value in case of error

If 'ioremap()' returns 0, 'gm20b_tegra_read_wpr()' will return 0 as well, which means success. Return -ENOMEM instead Signed-off-by: Christophe JAILLET --- Not sure that -ENOMEM is the best value. I've taken it because it is often used in such a case. ---

[PATCH cgroup/for-4.8-fixes] cgroup: fix invalid controller enable rejections with cgroup namespace

>From 9157056da8f8c4a6305f15619e269f164b63a6de Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 23 Sep 2016 16:55:49 -0400 On the v2 hierarchy, "cgroup.subtree_control" rejects controller enables if the cgroup has processes in it. The enforcement of this logic assumes that

[PATCH cgroup/for-4.8-fixes] cgroup: fix invalid controller enable rejections with cgroup namespace

>From 9157056da8f8c4a6305f15619e269f164b63a6de Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 23 Sep 2016 16:55:49 -0400 On the v2 hierarchy, "cgroup.subtree_control" rejects controller enables if the cgroup has processes in it. The enforcement of this logic assumes that the cgroup

[PATCH 1/2] bpf samples: fix compiler errors with sockex2 and sockex3

These samples fail to compile as 'struct flow_keys' conflicts with definition in net/flow_dissector.h. Fix the same by renaming the structure used in the sample. Signed-off-by: Naveen N. Rao --- samples/bpf/sockex2_kern.c | 10 +-

[PATCH 2/2] bpf samples: update tracex5 sample to use __seccomp_filter

seccomp_phase1() does not exist anymore. Instead, update sample to use __seccomp_filter(). While at it, set max locked memory to unlimited. Signed-off-by: Naveen N. Rao --- I am not completely sure if __seccomp_filter is the right place to hook in. This works for

[PATCH 2/2] bpf samples: update tracex5 sample to use __seccomp_filter

seccomp_phase1() does not exist anymore. Instead, update sample to use __seccomp_filter(). While at it, set max locked memory to unlimited. Signed-off-by: Naveen N. Rao --- I am not completely sure if __seccomp_filter is the right place to hook in. This works for me though. Please review.

[PATCH 1/2] bpf samples: fix compiler errors with sockex2 and sockex3

These samples fail to compile as 'struct flow_keys' conflicts with definition in net/flow_dissector.h. Fix the same by renaming the structure used in the sample. Signed-off-by: Naveen N. Rao --- samples/bpf/sockex2_kern.c | 10 +- samples/bpf/sockex3_kern.c | 8

Re: [PATCH v4] staging: ion: Fix a coding style issue

On 09/23/2016 11:03 AM, Antti Keränen wrote: This patch fixes the alignment of an allocation flag block comment and moves the comments before each #define. Acked-by: Laura Abbott Signed-off-by: Antti Keränen --- In addition to fixing the alignment

Re: [PATCH v4] staging: ion: Fix a coding style issue

On 09/23/2016 11:03 AM, Antti Keränen wrote: This patch fixes the alignment of an allocation flag block comment and moves the comments before each #define. Acked-by: Laura Abbott Signed-off-by: Antti Keränen --- In addition to fixing the alignment issue, this version of the patch moves

[PATCH 3/3] bpf powerpc: add support for bpf constant blinding

In line with similar support for other architectures by Daniel Borkmann. 'MOD Default X' from test_bpf without constant blinding: 84 bytes emitted from JIT compiler (pass:3, flen:7) d58a4688 + : 0: nop 4: nop 8: std r27,-40(r1) c: std r28,-32(r1) 10: xor

[PATCH 3/3] bpf powerpc: add support for bpf constant blinding

In line with similar support for other architectures by Daniel Borkmann. 'MOD Default X' from test_bpf without constant blinding: 84 bytes emitted from JIT compiler (pass:3, flen:7) d58a4688 + : 0: nop 4: nop 8: std r27,-40(r1) c: std r28,-32(r1) 10: xor

Re: [RFC PATCH 0/6] perf: Add AUX data sampling

On Fri, Sep 23, 2016 at 10:19:43AM -0700, Andi Kleen wrote: > On Fri, Sep 23, 2016 at 01:49:17PM +0200, Peter Zijlstra wrote: > > On Fri, Sep 23, 2016 at 02:27:20PM +0300, Alexander Shishkin wrote: > > > Hi Peter, > > > > > > This is an RFC, I'm not sending the tooling bits in this series, > > >

[PATCH 1/3] bpf powerpc: introduce accessors for using the tmp local stack space

While at it, ensure that the location of the local save area is consistent whether or not we setup our own stackframe. This property is utilised in the next patch that adds support for tail calls. Signed-off-by: Naveen N. Rao --- arch/powerpc/net/bpf_jit64.h

[PATCH 2/3] bpf powerpc: implement support for tail calls

Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF programs. This can be achieved either by: (1) retaining the stack setup by the first eBPF program and having all subsequent eBPF programs re-using it, or, (2) by unwinding/tearing down the stack and having each eBPF program deal

Re: [RFC PATCH 0/6] perf: Add AUX data sampling

On Fri, Sep 23, 2016 at 10:19:43AM -0700, Andi Kleen wrote: > On Fri, Sep 23, 2016 at 01:49:17PM +0200, Peter Zijlstra wrote: > > On Fri, Sep 23, 2016 at 02:27:20PM +0300, Alexander Shishkin wrote: > > > Hi Peter, > > > > > > This is an RFC, I'm not sending the tooling bits in this series, > > >

[PATCH 1/3] bpf powerpc: introduce accessors for using the tmp local stack space

While at it, ensure that the location of the local save area is consistent whether or not we setup our own stackframe. This property is utilised in the next patch that adds support for tail calls. Signed-off-by: Naveen N. Rao --- arch/powerpc/net/bpf_jit64.h | 16 +---

[PATCH 2/3] bpf powerpc: implement support for tail calls

Tail calls allow JIT'ed eBPF programs to call into other JIT'ed eBPF programs. This can be achieved either by: (1) retaining the stack setup by the first eBPF program and having all subsequent eBPF programs re-using it, or, (2) by unwinding/tearing down the stack and having each eBPF program deal

new objtool warnings again...

Josh, the current F24 toolchain causes kernel/signal.o: warning: objtool: .altinstr_replacement+0x54: call without frame pointer save/setup during a regular allmodconfig build. Doing an objdump says: ... 54: e8 00 00 00 00 callq 59 <.altinstr_replacement+0x59>

new objtool warnings again...

Josh, the current F24 toolchain causes kernel/signal.o: warning: objtool: .altinstr_replacement+0x54: call without frame pointer save/setup during a regular allmodconfig build. Doing an objdump says: ... 54: e8 00 00 00 00 callq 59 <.altinstr_replacement+0x59>

[PATCH 2/3] ARM: pxa: ezx: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/ezx.c | 176 1 file changed, 72 insertions(+),

[PATCH 2/3] ARM: pxa: ezx: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/ezx.c | 176 1 file changed, 72 insertions(+), 104 deletions(-) diff

[PATCH 3/3] ARM: pxa: em-x270: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/em-x270.c | 85 ++--- 1 file changed, 27 insertions(+),

[PATCH 3/3] ARM: pxa: em-x270: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/em-x270.c | 85 ++--- 1 file changed, 27 insertions(+), 58 deletions(-) diff

Re: [PATCH] vme: fake: mark symbols static where possible

On 23 September 2016 at 14:38, Baoyou Xie wrote: > We get 4 warnings when building kernel with W=1: > drivers/vme/bridges/vme_fake.c:384:6: warning: no previous prototype for > 'fake_lm_check' [-Wmissing-prototypes] > drivers/vme/bridges/vme_fake.c:619:6: warning: no

[PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git

Re: [PATCH] vme: fake: mark symbols static where possible

On 23 September 2016 at 14:38, Baoyou Xie wrote: > We get 4 warnings when building kernel with W=1: > drivers/vme/bridges/vme_fake.c:384:6: warning: no previous prototype for > 'fake_lm_check' [-Wmissing-prototypes] > drivers/vme/bridges/vme_fake.c:619:6: warning: no previous prototype for >

[PATCH 1/3] ARM: pxa: mioa701: use the new pxa_camera platform_data

pxa_camera has transitioned from a soc_camera driver to a standalone v4l2 driver. Amend the device declaration accordingly. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-pxa/mioa701.c

Re: [PATCH 0/2] Ajust lockdep static allocations

On 9/23/2016 3:17 PM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 02:57:39PM -0500, Babu Moger wrote: We checked again. Yes, It goes in .bss section. But in sparc we have to fit .text, .data, .bss in 7 permanent TLBs(that is totally 28MB). It was fine so far. But the commit

Re: [PATCH 0/2] Ajust lockdep static allocations

On 9/23/2016 3:17 PM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 02:57:39PM -0500, Babu Moger wrote: We checked again. Yes, It goes in .bss section. But in sparc we have to fit .text, .data, .bss in 7 permanent TLBs(that is totally 28MB). It was fine so far. But the commit

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

On Fri, Sep 23, 2016 at 10:26:15AM -0700, Andi Kleen wrote: > > Afaict there's no actual need to hide the AUX buffer for this sampling > > stuff; the user knows about all this and can simply mmap() the AUX part. > > The sample could either point to locations in the AUX buffer, or (as I > > think

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

On Fri, Sep 23, 2016 at 10:26:15AM -0700, Andi Kleen wrote: > > Afaict there's no actual need to hide the AUX buffer for this sampling > > stuff; the user knows about all this and can simply mmap() the AUX part. > > The sample could either point to locations in the AUX buffer, or (as I > > think

[PATCH] nfp: bpf: improve handling for disabled BPF syscall

I stumbled over a new warning during randconfig testing, with CONFIG_BPF_SYSCALL disabled: drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function 'nfp_net_bpf_offload': drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void *)+4)' may be used uninitialized in

[PATCH] nfp: bpf: improve handling for disabled BPF syscall

I stumbled over a new warning during randconfig testing, with CONFIG_BPF_SYSCALL disabled: drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function 'nfp_net_bpf_offload': drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void *)+4)' may be used uninitialized in

[RFC 0/2] Add device tree property and quirk for supporting sdhci

Some board configurations can not support sd highspeed mode due to the distance between the card slot and the controller. The card and controller report that they are capable of highspeed however, so we need a mechanism for specifying that the setup is incapable of supporting highspeed mode. The

[RFC 0/2] Add device tree property and quirk for supporting sdhci

Some board configurations can not support sd highspeed mode due to the distance between the card slot and the controller. The card and controller report that they are capable of highspeed however, so we need a mechanism for specifying that the setup is incapable of supporting highspeed mode. The

[RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

Certain board configurations can make highspeed malfunction due to timing issues. In these cases a way is needed to force the controller and card into standard speed even if they otherwise appear to be capable of highspeed. The sd-broken-highspeed property will let the sdhci driver know that

[RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set

From: Chen Yee Chew When the sd-broken-highspeed property is set the sdhci driver will not go into highspeed mode even if the controller and card appear to otherwise support highspeed mode. This is useful in cases where the controller and card support highspeed, but the

[RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

Certain board configurations can make highspeed malfunction due to timing issues. In these cases a way is needed to force the controller and card into standard speed even if they otherwise appear to be capable of highspeed. The sd-broken-highspeed property will let the sdhci driver know that

[RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set

From: Chen Yee Chew When the sd-broken-highspeed property is set the sdhci driver will not go into highspeed mode even if the controller and card appear to otherwise support highspeed mode. This is useful in cases where the controller and card support highspeed, but the board configuration or

Re: [PATCH v2] signals: Avoid unnecessary taking of sighand->siglock

23.09.2016 19:56, Waiman Long пишет: When running certain database workload on a high-end system with many CPUs, it was found that spinlock contention in the sigprocmask syscalls became a significant portion of the overall CPU cycles as shown below. Hi, I was recently facing the same problem,

Re: [PATCH v2] signals: Avoid unnecessary taking of sighand->siglock

23.09.2016 19:56, Waiman Long пишет: When running certain database workload on a high-end system with many CPUs, it was found that spinlock contention in the sigprocmask syscalls became a significant portion of the overall CPU cycles as shown below. Hi, I was recently facing the same problem,

Re: [PATCH 0/2] Ajust lockdep static allocations

On Fri, Sep 23, 2016 at 02:57:39PM -0500, Babu Moger wrote: > We checked again. Yes, It goes in .bss section. But in sparc we have > to fit .text, .data, .bss in 7 permanent TLBs(that is totally 28MB). > It was fine so far. But the commit 1413c0389333 ("lockdep: Increase > static

Re: [PATCH 0/2] Ajust lockdep static allocations

On Fri, Sep 23, 2016 at 02:57:39PM -0500, Babu Moger wrote: > We checked again. Yes, It goes in .bss section. But in sparc we have > to fit .text, .data, .bss in 7 permanent TLBs(that is totally 28MB). > It was fine so far. But the commit 1413c0389333 ("lockdep: Increase > static

RE: [PATCH 2/2] radix-tree: Fix optimisation problem

From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus Torvalds > On Thu, Sep 22, 2016 at 11:53 AM, Matthew Wilcox > wrote: > > > > Change the test suite to compile with -O2, and > > fix the optimisation problem by passing 'entry' through

RE: [PATCH 2/2] radix-tree: Fix optimisation problem

From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus Torvalds > On Thu, Sep 22, 2016 at 11:53 AM, Matthew Wilcox > wrote: > > > > Change the test suite to compile with -O2, and > > fix the optimisation problem by passing 'entry' through entry_to_node() > > so gcc

[PATCH] mlx5: Add ndo_poll_controller() implementation

This implements ndo_poll_controller in net_device_ops for mlx5, which is necessary to use netconsole with this driver. Signed-off-by: Calvin Owens --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 20 1 file changed, 20 insertions(+) diff --git

[PATCH] mlx5: Add ndo_poll_controller() implementation

This implements ndo_poll_controller in net_device_ops for mlx5, which is necessary to use netconsole with this driver. Signed-off-by: Calvin Owens --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 20 1 file changed, 20 insertions(+) diff --git

Re: [PATCH 0/2] Ajust lockdep static allocations

On 09/23/2016 01:57 PM, Babu Moger wrote: On 9/23/2016 10:40 AM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: Correct, We can't boot with lockdep. Sorry I did not make that clear. We have a limit on static size of the kernel. This stuff should be in

Re: [PATCH 0/2] Ajust lockdep static allocations

On 09/23/2016 01:57 PM, Babu Moger wrote: On 9/23/2016 10:40 AM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: Correct, We can't boot with lockdep. Sorry I did not make that clear. We have a limit on static size of the kernel. This stuff should be in

Re: [RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

Hi, On 09/23/2016 03:07 PM, Dave Gerlach wrote: The OPP framework allows each OPP to set a opp-supported-hw property which provides values that are matched against supported_hw values provided by the platform to limit support for certain OPPs on specific hardware. Currently, if the platform does

Re: [RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

Hi, On 09/23/2016 03:07 PM, Dave Gerlach wrote: The OPP framework allows each OPP to set a opp-supported-hw property which provides values that are matched against supported_hw values provided by the platform to limit support for certain OPPs on specific hardware. Currently, if the platform does

[RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

The OPP framework allows each OPP to set a opp-supported-hw property which provides values that are matched against supported_hw values provided by the platform to limit support for certain OPPs on specific hardware. Currently, if the platform does not set supported_hw values, all OPPs are

[RFC PATCH] PM / OPP: Don't support OPP if it provides supported-hw but platform does not

The OPP framework allows each OPP to set a opp-supported-hw property which provides values that are matched against supported_hw values provided by the platform to limit support for certain OPPs on specific hardware. Currently, if the platform does not set supported_hw values, all OPPs are

Re: [PATCH v2 1/3] dt-bindings: display: display-timing: Add property to configure sync drive edge

On Thu, Sep 22, 2016 at 01:35:24PM +0300, Peter Ujfalusi wrote: > There are display panels which demands that the sync signal is driven on > different edge than the pixel data. > With the syncclk-active property we can specify the clk edge to be used to > drive the sync signal. When the property

Re: [PATCH v2 1/3] dt-bindings: display: display-timing: Add property to configure sync drive edge

On Thu, Sep 22, 2016 at 01:35:24PM +0300, Peter Ujfalusi wrote: > There are display panels which demands that the sync signal is driven on > different edge than the pixel data. > With the syncclk-active property we can specify the clk edge to be used to > drive the sync signal. When the property

[GIT PULL] Btrfs

Hi Linus, We have two fixes in my for-linus-4.8 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.8 Josef is fixing a problem when quotas are enabled with his latest ENOSPC rework, and Jeff is adding more checks into the subvol ioctls to avoid tripping up

[GIT PULL] Btrfs

Hi Linus, We have two fixes in my for-linus-4.8 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.8 Josef is fixing a problem when quotas are enabled with his latest ENOSPC rework, and Jeff is adding more checks into the subvol ioctls to avoid tripping up

Re: [PATCH 1/3] watchdog: bindings: dw_wdt: add reset lines

On Thu, Sep 22, 2016 at 09:02:30AM +0200, Steffen Trumtrar wrote: > Document the reset lines holding the watchdog core in reset. > > Signed-off-by: Steffen Trumtrar > Cc: Wim Van Sebroeck > Cc: Rob Herring > Cc: Mark Rutland

Re: [PATCH 1/3] watchdog: bindings: dw_wdt: add reset lines

On Thu, Sep 22, 2016 at 09:02:30AM +0200, Steffen Trumtrar wrote: > Document the reset lines holding the watchdog core in reset. > > Signed-off-by: Steffen Trumtrar > Cc: Wim Van Sebroeck > Cc: Rob Herring > Cc: Mark Rutland > Cc: linux-watch...@vger.kernel.org > Cc:

Re: [PATCH 2/2] PM / OPP: Multiple regulators aren't supported yet

On Wed, Sep 21, 2016 at 03:02:50PM +0530, Viresh Kumar wrote: > Multiple regulators per device aren't supported yet by the kernel code > and the bindings provided in documentation aren't sufficient to handle > that case (as there is no way for kernel code to link multiple > voltage/current values

Re: [PATCH 2/2] PM / OPP: Multiple regulators aren't supported yet

On Wed, Sep 21, 2016 at 03:02:50PM +0530, Viresh Kumar wrote: > Multiple regulators per device aren't supported yet by the kernel code > and the bindings provided in documentation aren't sufficient to handle > that case (as there is no way for kernel code to link multiple > voltage/current values

Re: [PATCH RT 3/7] net: add back the missing serialization in ip_send_unicast_reply()

On Fri, 23 Sep 2016 15:50:11 -0400 Steven Rostedt wrote: > 3.2.82-rt119-rc1 stable review patch. > If anyone has any objections, please let me know. I once again forgot to fix the umlaut before sending it via quilt. I'll have to try to fix quilt when I get a chance. --

Re: [PATCH RT 3/7] net: add back the missing serialization in ip_send_unicast_reply()

On Fri, 23 Sep 2016 15:50:11 -0400 Steven Rostedt wrote: > 3.2.82-rt119-rc1 stable review patch. > If anyone has any objections, please let me know. I once again forgot to fix the umlaut before sending it via quilt. I'll have to try to fix quilt when I get a chance. -- Steve > >

Re: [PATCH 0/2] Ajust lockdep static allocations

On 9/23/2016 10:40 AM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: Correct, We can't boot with lockdep. Sorry I did not make that clear. We have a limit on static size of the kernel. This stuff should be in .bss not .data. It should not affect the

Re: [PATCH 0/2] Ajust lockdep static allocations

On 9/23/2016 10:40 AM, Peter Zijlstra wrote: On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: Correct, We can't boot with lockdep. Sorry I did not make that clear. We have a limit on static size of the kernel. This stuff should be in .bss not .data. It should not affect the

Re: [PATCH 1/2] PM / OPP: compatible is an optional property

On Fri, Sep 23, 2016 at 10:45:26AM +0530, Viresh Kumar wrote: > On 22-09-16, 12:24, Stephen Boyd wrote: > > On 09/21/2016 02:32 AM, Viresh Kumar wrote: > > > It was never compulsory to have a compatible string in the OPP table. > > > Fix the documentation to mark it optional. > > > NAK. > > >

Re: [PATCH 1/2] PM / OPP: compatible is an optional property

On Fri, Sep 23, 2016 at 10:45:26AM +0530, Viresh Kumar wrote: > On 22-09-16, 12:24, Stephen Boyd wrote: > > On 09/21/2016 02:32 AM, Viresh Kumar wrote: > > > It was never compulsory to have a compatible string in the OPP table. > > > Fix the documentation to mark it optional. > > > NAK. > > >

[PATCH RT 7/7] Linux 3.2.82-rt119-rc1

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (Red Hat)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 6/7] fs/dcache: incremental fixup of the retry routine

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It has been pointed out by tglx that on UP the non-RT task could spin its entire time slice because the lock owner is preempted.

[PATCH RT 1/7] timers: wakeup all timer waiters

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is

[PATCH RT 7/7] Linux 3.2.82-rt119-rc1

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (Red Hat)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 6/7] fs/dcache: incremental fixup of the retry routine

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It has been pointed out by tglx that on UP the non-RT task could spin its entire time slice because the lock owner is preempted. This won't happen on !RT.

[PATCH RT 1/7] timers: wakeup all timer waiters

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is running and once this one

[PATCH RT 5/7] fs/dcache: resched/chill only if we make no progress

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() / cond_resched()

[PATCH RT 4/7] net: add a lock around icmp_sk()

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It looks like the this_cpu_ptr() access in icmp_sk() is protected with local_bh_disable(). To avoid missing serialization in -RT I

[PATCH RT 5/7] fs/dcache: resched/chill only if we make no progress

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() / cond_resched() was invoked. This

[PATCH RT 4/7] net: add a lock around icmp_sk()

3.2.82-rt119-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It looks like the this_cpu_ptr() access in icmp_sk() is protected with local_bh_disable(). To avoid missing serialization in -RT I am adding here a local

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