Re: [PATCH v2 0/7] fix fanotify issues with the series in v4.12

On Mon, Oct 30, 2017 at 6:27 PM, Jan Kara wrote: > On Fri 27-10-17 13:53:20, Jan Kara wrote: >> On Wed 25-10-17 16:31:39, Miklos Szeredi wrote: >> > On Wed, Oct 25, 2017 at 10:41 AM, Miklos Szeredi >> > wrote: >> > > We discovered some problems in the latest

Re: [PATCH v2 0/7] fix fanotify issues with the series in v4.12

On Mon, Oct 30, 2017 at 6:27 PM, Jan Kara wrote: > On Fri 27-10-17 13:53:20, Jan Kara wrote: >> On Wed 25-10-17 16:31:39, Miklos Szeredi wrote: >> > On Wed, Oct 25, 2017 at 10:41 AM, Miklos Szeredi >> > wrote: >> > > We discovered some problems in the latest fsnotify/fanotify codebase with >> >

[PATCH] Sony-laptop: Use common error handling code in sony_nc_setup_rfkill()

From: Markus Elfring Date: Mon, 30 Oct 2017 21:10:49 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] Sony-laptop: Use common error handling code in sony_nc_setup_rfkill()

From: Markus Elfring Date: Mon, 30 Oct 2017 21:10:49 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/platform/x86/sony-laptop.c |

Re: [PATCH] HID: i2c-hid: add reset gpio property

On Mon, Oct 30, 2017 at 11:57 AM, Brian Norris wrote: > + devicetree list > > Hi, > > On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote: >> some i2c hid devices have reset gpio, need to control >> it in the driver. >> >> Change-Id:

Re: [PATCH] HID: i2c-hid: add reset gpio property

On Mon, Oct 30, 2017 at 11:57 AM, Brian Norris wrote: > + devicetree list > > Hi, > > On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote: >> some i2c hid devices have reset gpio, need to control >> it in the driver. >> >> Change-Id: I87bca954bffc7eb7b35711406f522cb3d0fc2ded > > You should

Re: [ghes_copy_tofrom_phys] BUG: sleeping function called from invalid context at mm/page_alloc.c:4150

On 10/30/2017 1:46 PM, Linus Torvalds wrote: On Mon, Oct 30, 2017 at 10:20 AM, Linus Torvalds wrote: I will add a "might_sleep()" to ioremap_page_range() itself, so that we get this warning more reliably and much eailer. Right now it has been hidden by the fact

[PATCH] Novatek NT71392QG panel support

--- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-novatek-nt71392qg.c | 438 3 files changed, 448 insertions(+) mode change 100644 => 100755 drivers/gpu/drm/panel/Kconfig

Re: [ghes_copy_tofrom_phys] BUG: sleeping function called from invalid context at mm/page_alloc.c:4150

On 10/30/2017 1:46 PM, Linus Torvalds wrote: On Mon, Oct 30, 2017 at 10:20 AM, Linus Torvalds wrote: I will add a "might_sleep()" to ioremap_page_range() itself, so that we get this warning more reliably and much eailer. Right now it has been hidden by the fact that most of the time the time

[PATCH] Novatek NT71392QG panel support

--- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-novatek-nt71392qg.c | 438 3 files changed, 448 insertions(+) mode change 100644 => 100755 drivers/gpu/drm/panel/Kconfig

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

> > CHECK: braces {} should be used on all arms of this statement > > And checkpatch should die a horrible death, so what ? :-) I buy this to some degree... > Sorry, I can't help but trolling here when checkpatch enforce obviously > disgusting and wasteful coding style. ... but not this. Most

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

> > CHECK: braces {} should be used on all arms of this statement > > And checkpatch should die a horrible death, so what ? :-) I buy this to some degree... > Sorry, I can't help but trolling here when checkpatch enforce obviously > disgusting and wasteful coding style. ... but not this. Most

Re: [Intel-gfx] [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 07:10:11PM +, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > > CC intel-gfx. > > Thanks, these are all interesting (even if some of them seem to be > from random kernels). > > Fengguang, is this a new script

Re: [Intel-gfx] [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 07:10:11PM +, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > > CC intel-gfx. > > Thanks, these are all interesting (even if some of them seem to be > from random kernels). > > Fengguang, is this a new script that you started running?

Re: [PATCH v6 6/6] perf util: use correct IP mapping to find srcline for hist entry

Em Wed, Oct 25, 2017 at 10:46:00AM +0900, Namhyung Kim escreveu: > Hi Milian, > > On Tue, Oct 24, 2017 at 10:51:43AM +0200, Milian Wolff wrote: > > On Freitag, 20. Oktober 2017 07:15:33 CEST Namhyung Kim wrote: > > > I looked into it and found a bug handling cumulative (children) > > > entries.

Re: [PATCH v6 6/6] perf util: use correct IP mapping to find srcline for hist entry

Em Wed, Oct 25, 2017 at 10:46:00AM +0900, Namhyung Kim escreveu: > Hi Milian, > > On Tue, Oct 24, 2017 at 10:51:43AM +0200, Milian Wolff wrote: > > On Freitag, 20. Oktober 2017 07:15:33 CEST Namhyung Kim wrote: > > > I looked into it and found a bug handling cumulative (children) > > > entries.

Re: n950: mmc fails to work, omap_hsmmc 480b4000.mmc: RX DMA channel request failed ? was Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi! > Then I was (finally!) able to run dmesg, and that tells me: > > [0.816040] mousedev: PS/2 mouse device common for all mice > [0.817657] input: TWL4030 Keypad as > /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:keypad/input/input0 > [0.820800] i2c

Re: n950: mmc fails to work, omap_hsmmc 480b4000.mmc: RX DMA channel request failed ? was Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi! > Then I was (finally!) able to run dmesg, and that tells me: > > [0.816040] mousedev: PS/2 mouse device common for all mice > [0.817657] input: TWL4030 Keypad as > /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:keypad/input/input0 > [0.820800] i2c

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 03:48 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> >> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) > Hi Boris, I am trying to repro the warnings below. I have been > unsuccessful so far. What system are you using? Fedora? CentOS? Do

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/30/2017 03:48 PM, Stefano Stabellini wrote: > On Mon, 30 Oct 2017, Boris Ostrovsky wrote: >> >> Build warnings (gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)) > Hi Boris, I am trying to repro the warnings below. I have been > unsuccessful so far. What system are you using? Fedora? CentOS? Do

Re: [PATCH 4.13 44/85] tracing/samples: Fix creation and deletion of simple_thread_fn creation

On Tue, 24 Oct 2017 15:07:18 +0200 Greg Kroah-Hartman wrote: > 4.13-stable review patch. If anyone has any objections, please let me know. Just that it needs a fix. > > --- a/samples/trace_events/trace-events-sample.c > +++

Re: [PATCH 4.13 44/85] tracing/samples: Fix creation and deletion of simple_thread_fn creation

On Tue, 24 Oct 2017 15:07:18 +0200 Greg Kroah-Hartman wrote: > 4.13-stable review patch. If anyone has any objections, please let me know. Just that it needs a fix. > > --- a/samples/trace_events/trace-events-sample.c > +++ b/samples/trace_events/trace-events-sample.c > @@ -78,29 +78,37 @@

Re: WARNING in get_pi_state

On Mon, Oct 30, 2017 at 10:44 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8fd0520d9cec0896d48d3921bc642a9ee81eae0c > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620

Re: WARNING in get_pi_state

On Mon, Oct 30, 2017 at 10:44 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8fd0520d9cec0896d48d3921bc642a9ee81eae0c > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Mon, 30 Oct 2017, Boris Ostrovsky wrote: > On 10/26/2017 04:45 PM, Boris Ostrovsky wrote: > > On 10/26/2017 04:16 PM, Stefano Stabellini wrote: > >> On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > >>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile.

Re: [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Mon, 30 Oct 2017, Boris Ostrovsky wrote: > On 10/26/2017 04:45 PM, Boris Ostrovsky wrote: > > On 10/26/2017 04:16 PM, Stefano Stabellini wrote: > >> On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > >>> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile.

Re: [PATCH] leds: lp55xx: fix spelling mistake: 'cound' -> 'could'

Hi Arvind, Thanks for the patch. On 10/29/2017 06:55 AM, Arvind Yadav wrote: > Trivial fix to spelling mistakes in 'lp5523_init_program_engine'. > > Signed-off-by: Arvind Yadav > --- > drivers/leds/leds-lp5523.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] leds: lp55xx: fix spelling mistake: 'cound' -> 'could'

Hi Arvind, Thanks for the patch. On 10/29/2017 06:55 AM, Arvind Yadav wrote: > Trivial fix to spelling mistakes in 'lp5523_init_program_engine'. > > Signed-off-by: Arvind Yadav > --- > drivers/leds/leds-lp5523.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PATCH] x86/boot: Disable warnings about GNU extensions

The kernel makes use of several GCC extensions, disable clang warnings about that in the boot code, as we already do for the rest of the kernel. This suppresses the following warning when building with clang: ./include/linux/cgroup-defs.h:391:16: warning: field 'cgrp' with variable sized

[PATCH] x86/boot: Disable warnings about GNU extensions

The kernel makes use of several GCC extensions, disable clang warnings about that in the boot code, as we already do for the rest of the kernel. This suppresses the following warning when building with clang: ./include/linux/cgroup-defs.h:391:16: warning: field 'cgrp' with variable sized

n950: mmc fails to work, omap_hsmmc 480b4000.mmc: RX DMA channel request failed ? was Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi! I was able to setup nfsroot, and boot postmarketos (with root read/only, but that's good enough for debugging). Then I was (finally!) able to run dmesg, and that tells me: [0.816040] mousedev: PS/2 mouse device common for all mice [0.817657] input: TWL4030 Keypad as

n950: mmc fails to work, omap_hsmmc 480b4000.mmc: RX DMA channel request failed ? was Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another

Hi! I was able to setup nfsroot, and boot postmarketos (with root read/only, but that's good enough for debugging). Then I was (finally!) able to run dmesg, and that tells me: [0.816040] mousedev: PS/2 mouse device common for all mice [0.817657] input: TWL4030 Keypad as

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

>> Are you looking for a limitation of such source code search patterns? > > Exactly. Would you like to explain your view a bit more? Regards, Markus

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

>> Are you looking for a limitation of such source code search patterns? > > Exactly. Would you like to explain your view a bit more? Regards, Markus

Re: possible deadlock in process_one_work

On Mon, Oct 30, 2017 at 10:32 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 9506597de2cde02d48c11d5c250250b9143f59f7 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >

Re: possible deadlock in process_one_work

On Mon, Oct 30, 2017 at 10:32 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 9506597de2cde02d48c11d5c250250b9143f59f7 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

On Mon, Oct 30, 2017 at 8:32 PM, SF Markus Elfring wrote: >>> Add a jump target so that a bit of exception handling can be better reused >>> at the end of this function. >>> >>> This issue was detected by using the Coccinelle software. >> >> Does Coccinelle have a

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

On Mon, Oct 30, 2017 at 8:32 PM, SF Markus Elfring wrote: >>> Add a jump target so that a bit of exception handling can be better reused >>> at the end of this function. >>> >>> This issue was detected by using the Coccinelle software. >> >> Does Coccinelle have a threshold for how much cleanup

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

>> Add a jump target so that a bit of exception handling can be better reused >> at the end of this function. >> >> This issue was detected by using the Coccinelle software. > > Does Coccinelle have a threshold for how much cleanup can be shared? Are you looking for a limitation of such source

Re: pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

>> Add a jump target so that a bit of exception handling can be better reused >> at the end of this function. >> >> This issue was detected by using the Coccinelle software. > > Does Coccinelle have a threshold for how much cleanup can be shared? Are you looking for a limitation of such source

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote: > > Here are 3 dmesgs related to wireless and 1 from ethernet. Fengguang, these would be lovelier still _if_ you have DEBUG_INFO enabled on the kernel, and your script were to find things like "symbol+0xhex/0xhex", and

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu wrote: > > Here are 3 dmesgs related to wireless and 1 from ethernet. Fengguang, these would be lovelier still _if_ you have DEBUG_INFO enabled on the kernel, and your script were to find things like "symbol+0xhex/0xhex", and run

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon, Oct 30, 2017 at 1:29 AM, Michal Hocko wrote: > On Fri 27-10-17 13:50:47, Shakeel Butt wrote: >> > Why is OOM-disabling a thing? Why isn't this simply a "kill everything >> > else before you kill me"? It's crashing the kernel in trying to >> > protect a userspace

Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon, Oct 30, 2017 at 1:29 AM, Michal Hocko wrote: > On Fri 27-10-17 13:50:47, Shakeel Butt wrote: >> > Why is OOM-disabling a thing? Why isn't this simply a "kill everything >> > else before you kill me"? It's crashing the kernel in trying to >> > protect a userspace application. How is that

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > cd4175b11685b11c40e31a03e05084cc212b0649 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > cd4175b11685b11c40e31a03e05084cc212b0649 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: WARNING in task_participate_group_stop

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > d95e159cd1da1ed4dbf76bf203e8ffaf231395e4 > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620

Re: WARNING in task_participate_group_stop

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > d95e159cd1da1ed4dbf76bf203e8ffaf231395e4 > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer

Re: rseq event_counter field

- On Oct 30, 2017, at 2:08 PM, Kyle Huey m...@kylehuey.com wrote: > On Sat, Oct 28, 2017 at 1:20 PM, Andy Lutomirski wrote: >> Answering both emails here. >> >> Also, welcome Kyle. Kyle, how badly does rseq's proposed >> event_counter break rr? For that matter, how badly

Re: rseq event_counter field

- On Oct 30, 2017, at 2:08 PM, Kyle Huey m...@kylehuey.com wrote: > On Sat, Oct 28, 2017 at 1:20 PM, Andy Lutomirski wrote: >> Answering both emails here. >> >> Also, welcome Kyle. Kyle, how badly does rseq's proposed >> event_counter break rr? For that matter, how badly does rseq without

Re: [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util

Hi Viresh, On Mon, Oct 30, 2017 at 2:22 AM, Viresh Kumar wrote: > You have prefixed most of the Cc'd names with "Cc: " somehow :) Yeah :( What happened is I decided to play with using a text file to input --cc-cmd for git send-patch. Turns out I was too careless with

Re: [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util

Hi Viresh, On Mon, Oct 30, 2017 at 2:22 AM, Viresh Kumar wrote: > You have prefixed most of the Cc'd names with "Cc: " somehow :) Yeah :( What happened is I decided to play with using a text file to input --cc-cmd for git send-patch. Turns out I was too careless with forgetting to remove the

Re: [PATCH] pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

Hi Markus, On Mon, Oct 30, 2017 at 7:36 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 30 Oct 2017 19:26:56 +0100 > > Add a jump target so that a bit of exception handling can be better reused > at the end of this

Re: [PATCH] pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

Hi Markus, On Mon, Oct 30, 2017 at 7:36 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 30 Oct 2017 19:26:56 +0100 > > Add a jump target so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the Coccinelle

Re: KASAN: use-after-free Read in __do_page_fault

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 887c8ba753fbe809ba93fa3cfd0cc46db18d37d4 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >

Re: KASAN: use-after-free Read in __do_page_fault

On Mon, Oct 30, 2017 at 10:12 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 887c8ba753fbe809ba93fa3cfd0cc46db18d37d4 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

[PATCH] mmc:host:sdhci-pci:V3-Addition of Arasan PCI Controller with integrated phy.

The Arasan controller is based on a FPGA platform and has integrated phy with specific registers used during initialization and management of different modes. The phy and the controller are integrated and registers are very specific to Arasan. Arasan being an IP provider, licenses these IPs to

[PATCH] mmc:host:sdhci-pci:V3-Addition of Arasan PCI Controller with integrated phy.

The Arasan controller is based on a FPGA platform and has integrated phy with specific registers used during initialization and management of different modes. The phy and the controller are integrated and registers are very specific to Arasan. Arasan being an IP provider, licenses these IPs to

Re: [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > CC intel-gfx. Thanks, these are all interesting (even if some of them seem to be from random kernels). Fengguang, is this a new script that you started running? Because I'm *hoping* it's not that rc6 suddenly seems

Re: [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > CC intel-gfx. Thanks, these are all interesting (even if some of them seem to be from random kernels). Fengguang, is this a new script that you started running? Because I'm *hoping* it's not that rc6 suddenly seems so flaky, and it's

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 10/30/2017 04:57 AM, Christian Borntraeger wrote: adding qemu devel and add Daniel and Erik from libvirt to keep them in the loop. On 10/29/2017 12:11 PM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:45 -0400 Tony Krowiak wrote: Tony Krowiak (19): KVM:

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 10/30/2017 04:57 AM, Christian Borntraeger wrote: adding qemu devel and add Daniel and Erik from libvirt to keep them in the loop. On 10/29/2017 12:11 PM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:45 -0400 Tony Krowiak wrote: Tony Krowiak (19): KVM: s390: SIE considerations for

Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

Hi Viresh, On Mon, Oct 30, 2017 at 5:07 AM, Viresh Kumar wrote: > On 28-10-17, 02:59, Joel Fernandes wrote: >> Updating CPU frequency on last dequeue of a CPU is useless. Because the >> utilization since CPU came out of idle can increase till the last dequeue, >> this

Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

Hi Viresh, On Mon, Oct 30, 2017 at 5:07 AM, Viresh Kumar wrote: > On 28-10-17, 02:59, Joel Fernandes wrote: >> Updating CPU frequency on last dequeue of a CPU is useless. Because the >> utilization since CPU came out of idle can increase till the last dequeue, >> this >> means we are requesting

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 7:11 AM, Dave Jones wrote: > Something scary for halloween. Only saw this once so far. Scary indeed. I don't see any pattern. It's 18 quad-words with one unwritten entry before the last one. And most of them look like kernel pointers, but not

Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 7:11 AM, Dave Jones wrote: > Something scary for halloween. Only saw this once so far. Scary indeed. I don't see any pattern. It's 18 quad-words with one unwritten entry before the last one. And most of them look like kernel pointers, but not all. The quad-words are:

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 10/30/2017 11:46 AM, Maciej S. Szmigiero wrote: > On 30.10.2017 19:36, Florian Fainelli wrote: >> On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: >>> Currently, we create a LED trigger for any link speed known to a PHY. >>> These triggers only fire when their exact link speed had been

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 10/30/2017 11:46 AM, Maciej S. Szmigiero wrote: > On 30.10.2017 19:36, Florian Fainelli wrote: >> On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: >>> Currently, we create a LED trigger for any link speed known to a PHY. >>> These triggers only fire when their exact link speed had been

Re: [PATCH v9 06/10] arm64: dts: allwinner: Restore EMAC changes

On Fri, Oct 27, 2017 at 05:11:14PM +0200, Maxime Ripard wrote: > On Tue, Oct 24, 2017 at 07:57:10PM +0200, Corentin Labbe wrote: > > The original dwmac-sun8i DT bindings have some issue on how to handle > > integrated PHY and was reverted in last RC of 4.13. > > But now we have a solution so we

Re: [PATCH v9 06/10] arm64: dts: allwinner: Restore EMAC changes

On Fri, Oct 27, 2017 at 05:11:14PM +0200, Maxime Ripard wrote: > On Tue, Oct 24, 2017 at 07:57:10PM +0200, Corentin Labbe wrote: > > The original dwmac-sun8i DT bindings have some issue on how to handle > > integrated PHY and was reverted in last RC of 4.13. > > But now we have a solution so we

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

On 10/30/2017 11:46 AM, Vivien Didelot wrote: > Hi Florian, > > Florian Fainelli writes: > >> Reviewed-by: Florian Fainelli >> >> One nit below: >> >>> static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) >>> { >>> + struct

Re: [RFC PATCH v8 4/7] of/irq: Adjust of pci irq parsing for multiple interrupts

On Mon, Oct 30, 2017 at 10:05:51AM +0800, Jeffy Chen wrote: > On 10/27/2017 10:38 PM, Rob Herring wrote: > >>+ prop = of_find_property(dn, "interrupt-names", NULL); > >>>+ for (name = of_prop_next_string(prop, NULL); name; > >>>+ name = of_prop_next_string(prop,

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

On 10/30/2017 11:46 AM, Vivien Didelot wrote: > Hi Florian, > > Florian Fainelli writes: > >> Reviewed-by: Florian Fainelli >> >> One nit below: >> >>> static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) >>> { >>> + struct device_node *ethernet = of_parse_phandle(dn,

Re: [RFC PATCH v8 4/7] of/irq: Adjust of pci irq parsing for multiple interrupts

On Mon, Oct 30, 2017 at 10:05:51AM +0800, Jeffy Chen wrote: > On 10/27/2017 10:38 PM, Rob Herring wrote: > >>+ prop = of_find_property(dn, "interrupt-names", NULL); > >>>+ for (name = of_prop_next_string(prop, NULL); name; > >>>+ name = of_prop_next_string(prop,

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 30.10.2017 19:36, Florian Fainelli wrote: > On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: >> Currently, we create a LED trigger for any link speed known to a PHY. >> These triggers only fire when their exact link speed had been negotiated >> (they aren't cumulative, that is, they don't

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 30.10.2017 19:36, Florian Fainelli wrote: > On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: >> Currently, we create a LED trigger for any link speed known to a PHY. >> These triggers only fire when their exact link speed had been negotiated >> (they aren't cumulative, that is, they don't

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

Hi Florian, Florian Fainelli writes: > Reviewed-by: Florian Fainelli > > One nit below: > >> static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) >> { >> +struct device_node *ethernet = of_parse_phandle(dn, "ethernet", 0);

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

Hi Florian, Florian Fainelli writes: > Reviewed-by: Florian Fainelli > > One nit below: > >> static int dsa_port_parse_of(struct dsa_port *dp, struct device_node *dn) >> { >> +struct device_node *ethernet = of_parse_phandle(dn, "ethernet", 0); >> +struct device_node *link =

Re: [PATCH net-next 7/7] net: dsa: remove name arg from slave create

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Now that slave dsa_port always have their name set, there is no need to > pass it to dsa_slave_create() anymore. Remove this argument. > > Signed-off-by: Vivien Didelot Reviewed-by: Florian Fainelli

Re: [PATCH net-next 7/7] net: dsa: remove name arg from slave create

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Now that slave dsa_port always have their name set, there is no need to > pass it to dsa_slave_create() anymore. Remove this argument. > > Signed-off-by: Vivien Didelot Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH net-next 6/7] net: dsa: get port name at parse time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Get the optional "label" property and assign a default one directly at > parse time instead of doing it when creating the slave. > > For legacy, simply assign the port name stored in cd->port_names. > > Signed-off-by: Vivien Didelot

Re: [PATCH net-next 6/7] net: dsa: get port name at parse time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Get the optional "label" property and assign a default one directly at > parse time instead of doing it when creating the slave. > > For legacy, simply assign the port name stored in cd->port_names. > > Signed-off-by: Vivien Didelot Reviewed-by:

Re: KASAN: use-after-free Read in sit_tunnel_xmit

On Mon, Oct 30, 2017 at 8:34 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 4dc12ffeaeac939097a3f55c881d3dc3523dff0c > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler:

Re: KASAN: use-after-free Read in sit_tunnel_xmit

On Mon, Oct 30, 2017 at 8:34 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 4dc12ffeaeac939097a3f55c881d3dc3523dff0c > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [PATCH net-next 5/7] net: dsa: get master device at port parsing time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Fetching the master device can be done directly when a port is parsed > from device tree or pdata, instead of waiting until dsa_dst_parse. > > Now that -EPROBE_DEFER is returned before we add the switch to the tree, > there is no need to check for

Re: [PATCH net-next 5/7] net: dsa: get master device at port parsing time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Fetching the master device can be done directly when a port is parsed > from device tree or pdata, instead of waiting until dsa_dst_parse. > > Now that -EPROBE_DEFER is returned before we add the switch to the tree, > there is no need to check for

Looking for AT24 maintainer

Hi, quite obviously, I don't have the time anymore to maintain the AT24 driver. So, I am looking for someone to take over maintainership. It is a driver with very few patches coming in. It is just that they piled up a bit due to my inability to process them. I think it is a good driver to start

Looking for AT24 maintainer

Hi, quite obviously, I don't have the time anymore to maintain the AT24 driver. So, I am looking for someone to take over maintainership. It is a driver with very few patches coming in. It is just that they piled up a bit due to my inability to process them. I think it is a good driver to start

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Assign a port's type at parsed time instead of waiting for the tree to > be completed. > > Because this is now done earlier, we can use the port's type in > dsa_port_is_* helpers instead of digging again in topology description. > > Signed-off-by:

Re: [PATCH net-next 3/7] net: dsa: get port type at parse time

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Assign a port's type at parsed time instead of waiting for the tree to > be completed. > > Because this is now done earlier, we can use the port's type in > dsa_port_is_* helpers instead of digging again in topology description. > > Signed-off-by:

Re: [PATCH net-next 2/7] net: dsa: add port parse functions

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Add symmetrical DSA port parsing functions for pdata and device tree, > used to parse and validate a given port node or platform data. > > They don't do much for the moment but will be extended later on to > assign a port type and get device

Re: [PATCH net-next 2/7] net: dsa: add port parse functions

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > Add symmetrical DSA port parsing functions for pdata and device tree, > used to parse and validate a given port node or platform data. > > They don't do much for the moment but will be extended later on to > assign a port type and get device

Re: [PATCH net-next 1/7] net: dsa: get ports within parsing code

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > There is no point into hiding the -EINVAL error code in ERR_PTR from a > dsa_get_ports function, simply get the "ports" node directly from within > the dsa_parse_ports_dn function. > > This also has the effect to make the pdata and device tree

Re: [PATCH net-next 1/7] net: dsa: get ports within parsing code

On 10/27/2017 12:55 PM, Vivien Didelot wrote: > There is no point into hiding the -EINVAL error code in ERR_PTR from a > dsa_get_ports function, simply get the "ports" node directly from within > the dsa_parse_ports_dn function. > > This also has the effect to make the pdata and device tree

[PATCH] pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

From: Markus Elfring Date: Mon, 30 Oct 2017 19:26:56 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] pinctrl: sirf: Use common error handling code in sirfsoc_dt_node_to_map()

From: Markus Elfring Date: Mon, 30 Oct 2017 19:26:56 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/pinctrl/sirf/pinctrl-sirf.c |

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_runtime_pm.c between commit: 2a8408e537250 ("drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume") from Linus' tree and commit: 57522c4c87de2 ("drm/i915/cnl: Reprogram DMC firmware after

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_runtime_pm.c between commit: 2a8408e537250 ("drm/i915/cnl: Reprogram DMC firmware after S3/S4 resume") from Linus' tree and commit: 57522c4c87de2 ("drm/i915/cnl: Reprogram DMC firmware after

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: > Currently, we create a LED trigger for any link speed known to a PHY. > These triggers only fire when their exact link speed had been negotiated > (they aren't cumulative, that is, they don't fire for "their or any higher" > link speed). > >

Re: [PATCH] net: phy: leds: Add support for "link" trigger

On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote: > Currently, we create a LED trigger for any link speed known to a PHY. > These triggers only fire when their exact link speed had been negotiated > (they aren't cumulative, that is, they don't fire for "their or any higher" > link speed). > >

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