Re: [PATCH] clocksource: sun4i: Clear interrupts after stopping timer in probe function

On Tue, Jul 26, 2016 at 11:01:59AM +0800, Chen-Yu Tsai wrote: > The bootloader (U-boot) sometimes uses this timer for various delays. > It uses it as a ongoing counter, and does comparisons on the current > counter value. The timer counter is never stopped. > > In some cases when the user

Re: [PATCH] clocksource: sun4i: Clear interrupts after stopping timer in probe function

On Tue, Jul 26, 2016 at 11:01:59AM +0800, Chen-Yu Tsai wrote: > The bootloader (U-boot) sometimes uses this timer for various delays. > It uses it as a ongoing counter, and does comparisons on the current > counter value. The timer counter is never stopped. > > In some cases when the user

[PATCH] USB: appledisplay: Remove deprecated create_singlethread_workqueue

The workqueue "wq" is involved in controlling the brightness of an Apple Cinema Display over USB. It has a single work item(>work) per appledisplay and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with

[PATCH] USB: appledisplay: Remove deprecated create_singlethread_workqueue

The workqueue "wq" is involved in controlling the brightness of an Apple Cinema Display over USB. It has a single work item(>work) per appledisplay and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with

Re: [PATCH] xen/x86: Define stubs for xen_smp_intr_init/xen_smp_intr_free

On 25/07/16 23:14, Boris Ostrovsky wrote: > xen_smp_intr_init() and xen_smp_intr_free() are now called from > enlighten.c and therefore not guaranteed to have CONFIG_SMP. > > Instead of adding multiple ifdefs there provide stubs in smp.h > > Signed-off-by: Boris Ostrovsky

Re: [PATCH] xen/x86: Define stubs for xen_smp_intr_init/xen_smp_intr_free

On 25/07/16 23:14, Boris Ostrovsky wrote: > xen_smp_intr_init() and xen_smp_intr_free() are now called from > enlighten.c and therefore not guaranteed to have CONFIG_SMP. > > Instead of adding multiple ifdefs there provide stubs in smp.h > > Signed-off-by: Boris Ostrovsky Reviewed-by: Juergen

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: [snip] > [snip] > >>> So, from my point of view, the important piece that was missing from > >>> your commit message was the note to use

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

On Mon, Jul 25, 2016 at 09:59:43AM -0500, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: [snip] > [snip] > >>> So, from my point of view, the important piece that was missing from > >>> your commit message was the note to use readlink("/proc/self/fd/%d") > >>> on the returned

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > ... > From: Dexuan Cui > Date: Tue, 26 Jul 2016 03:09:16 + > > > BTW, during the past month, at least 7 other people also reviewed > > the patch and gave me quite a few good comments, which have > > been addressed. > >

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > ... > From: Dexuan Cui > Date: Tue, 26 Jul 2016 03:09:16 + > > > BTW, during the past month, at least 7 other people also reviewed > > the patch and gave me quite a few good comments, which have > > been addressed. > > Correction: Several

[PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

The current VBD layer reserves buffer space for each attached device based on three statically configured settings which are read at boot time. * max_indirect_segs: Maximum amount of segments. * max_ring_page_order: Maximum order of pages to be used for the shared ring. * max_queues: Maximum of

[PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits with initial correct values. Signed-off-by: Bob Liu --- v2: Move blkif_set_queue_limits() after

[PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits with initial correct values. Signed-off-by: Bob Liu --- v2: Move blkif_set_queue_limits() after blkfront_gather_backend_features. ---

[PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

The current VBD layer reserves buffer space for each attached device based on three statically configured settings which are read at boot time. * max_indirect_segs: Maximum amount of segments. * max_ring_page_order: Maximum order of pages to be used for the shared ring. * max_queues: Maximum of

[PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

Two places didn't get updated when 64KB page granularity was introduced, this patch fix them. Signed-off-by: Bob Liu Acked-by: Roger Pau Monné --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

Two places didn't get updated when 64KB page granularity was introduced, this patch fix them. Signed-off-by: Bob Liu Acked-by: Roger Pau Monné --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c

[PATCH] usb: ftdi-elan: Remove deprecated create_singlethread_workqueue

The status workqueue is involved in initializing the Uxxx and polling the Uxxx until a supported PCMCIA CardBus device is detected. It then starts the command and respond workqueues and then loads the module that handles the device, after which it just polls the Uxxx looking for card ejects. The

[PATCH] usb: ftdi-elan: Remove deprecated create_singlethread_workqueue

The status workqueue is involved in initializing the Uxxx and polling the Uxxx until a supported PCMCIA CardBus device is detected. It then starts the command and respond workqueues and then loads the module that handles the device, after which it just polls the Uxxx looking for card ejects. The

[PATCH 1/1] socfpga: defconfig: Enable Altera GPIO driver as module

From: Tien Hock Loh This patch enables Altera GPIO driver as module in socfpga_defconfig Signed-off-by: Tien Hock Loh --- arch/arm/configs/socfpga_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/socfpga_defconfig

[PATCH 1/1] socfpga: defconfig: Enable Altera GPIO driver as module

From: Tien Hock Loh This patch enables Altera GPIO driver as module in socfpga_defconfig Signed-off-by: Tien Hock Loh --- arch/arm/configs/socfpga_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Al Viro wrote: > On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote: > > > > The symptom is that downloaded files (http, ftp, and probably other > > > protocols) have small corrupted segments (about 1-2 kilobytes long) in > > > random locations. Only downloads that sustain a high

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Al Viro wrote: > On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote: > > > > The symptom is that downloaded files (http, ftp, and probably other > > > protocols) have small corrupted segments (about 1-2 kilobytes long) in > > > random locations. Only downloads that sustain a high

Re: linux-next: manual merge of the xen-tip tree with the block tree

Hi Boris, On Mon, 25 Jul 2016 18:25:00 -0400 Boris Ostrovsky wrote: > > > Jeremy Fitzhardinge > > Jeremy is no longer involved with Xen. However, > > Juergen Gross > > is also Linux Xen/x86 maintainer. I have replaced Jeremy

Re: linux-next: manual merge of the xen-tip tree with the block tree

Hi Boris, On Mon, 25 Jul 2016 18:25:00 -0400 Boris Ostrovsky wrote: > > > Jeremy Fitzhardinge > > Jeremy is no longer involved with Xen. However, > > Juergen Gross > > is also Linux Xen/x86 maintainer. I have replaced Jeremy with Juergen. -- Cheers, Stephen Rothwell

linux-next: manual merge of the random tree with the kspp tree

Hi Theodore, Today's linux-next merge of the random tree got a conflict in: drivers/char/random.c between commit: 8c6a68e9eaa5 ("latent_entropy: Mark functions with __latent_entropy") from the kspp tree and commit: e192be9d9a30 ("random: replace non-blocking pool with a Chacha20-based

linux-next: manual merge of the random tree with the kspp tree

Hi Theodore, Today's linux-next merge of the random tree got a conflict in: drivers/char/random.c between commit: 8c6a68e9eaa5 ("latent_entropy: Mark functions with __latent_entropy") from the kspp tree and commit: e192be9d9a30 ("random: replace non-blocking pool with a Chacha20-based

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Thanks for the detailed bug-report. I looked around the web to see if it was already reported or not. If found that this issue was reported before: [0], [1] and [2] by the same person (CC'ed). One difference is that the reporter had this issue with rsync on multiple SPARC systems. I ran a git

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Thanks for the detailed bug-report. I looked around the web to see if it was already reported or not. If found that this issue was reported before: [0], [1] and [2] by the same person (CC'ed). One difference is that the reporter had this issue with rsync on multiple SPARC systems. I ran a git

Re: [PATCH v3 02/11] mm: Hardened usercopy

On Mon, Jul 25, 2016 at 7:03 PM, Michael Ellerman wrote: > Josh Poimboeuf writes: > >> On Thu, Jul 21, 2016 at 11:34:25AM -0700, Kees Cook wrote: >>> On Wed, Jul 20, 2016 at 11:52 PM, Michael Ellerman >>> wrote: >>> > Kees Cook

Re: [PATCH v3 02/11] mm: Hardened usercopy

On Mon, Jul 25, 2016 at 7:03 PM, Michael Ellerman wrote: > Josh Poimboeuf writes: > >> On Thu, Jul 21, 2016 at 11:34:25AM -0700, Kees Cook wrote: >>> On Wed, Jul 20, 2016 at 11:52 PM, Michael Ellerman >>> wrote: >>> > Kees Cook writes: >>> > >>> >> diff --git a/mm/usercopy.c b/mm/usercopy.c

Re: [PATCH 1/3] net: asix: Add in_pm parameter

Please correct the problems Grant Grundler mentioned in all of these patches, and resubmit this entire series freshly. Also, please include a proper "[PATCH 0/3] ..." introduction posting for the series which explains what this series is about, how it implements what it is doing, and why it is

Re: [PATCH 1/3] net: asix: Add in_pm parameter

Please correct the problems Grant Grundler mentioned in all of these patches, and resubmit this entire series freshly. Also, please include a proper "[PATCH 0/3] ..." introduction posting for the series which explains what this series is about, how it implements what it is doing, and why it is

[PATCH] powerpc: sgy_cts1000: Fix gpio_halt_cb()'s signature

Halt callback in struct machdep_calls is declared with __noreturn attribute, so omitting that attribute in gpio_halt_cb()'s signatrue results in compilation error. Change the signature to address the problem as well as change the code of the function to avoid ever returning from the function.

[PATCH] powerpc: sgy_cts1000: Fix gpio_halt_cb()'s signature

Halt callback in struct machdep_calls is declared with __noreturn attribute, so omitting that attribute in gpio_halt_cb()'s signatrue results in compilation error. Change the signature to address the problem as well as change the code of the function to avoid ever returning from the function.

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: > To date, all callers of randomize_range() have set the length to 0, and > check for a zero return value. For the current callers, the only way > to get zero returned is if end <= start. Since they are all adding a >

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: > To date, all callers of randomize_range() have set the length to 0, and > check for a zero return value. For the current callers, the only way > to get zero returned is if end <= start. Since they are all adding a > constant to the start

Re: [kbuild-all] arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 'atomctl' for 'wsr' instruction

Hi Max, On Tue, Jul 26, 2016 at 02:20:25AM +0300, Max Filippov wrote: Hi Fengguang, On Fri, Jul 22, 2016 at 3:44 PM, Fengguang Wu wrote: On Fri, Jul 22, 2016 at 06:32:28PM +0800, kbuild test robot wrote: FYI, the error/warning still remains. tree:

Re: [kbuild-all] arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 'atomctl' for 'wsr' instruction

Hi Max, On Tue, Jul 26, 2016 at 02:20:25AM +0300, Max Filippov wrote: Hi Fengguang, On Fri, Jul 22, 2016 at 3:44 PM, Fengguang Wu wrote: On Fri, Jul 22, 2016 at 06:32:28PM +0800, kbuild test robot wrote: FYI, the error/warning still remains. tree:

Re: [PATCH] caif-hsi: Remove deprecated create_singlethread_workqueue

From: Bhaktipriya Shridhar Date: Mon, 25 Jul 2016 18:40:57 +0530 > alloc_workqueue replaces deprecated create_singlethread_workqueue(). > > A dedicated workqueue has been used since the workitems are being used > on a packet tx/rx path. Hence, WQ_MEM_RECLAIM has been

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: > All, > > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: >> To date, all callers of randomize_range() have set the length to 0, and >> check for a zero return value. For the current callers, the only way

Re: [PATCH] caif-hsi: Remove deprecated create_singlethread_workqueue

From: Bhaktipriya Shridhar Date: Mon, 25 Jul 2016 18:40:57 +0530 > alloc_workqueue replaces deprecated create_singlethread_workqueue(). > > A dedicated workqueue has been used since the workitems are being used > on a packet tx/rx path. Hence, WQ_MEM_RECLAIM has been set to guarantee > forward

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 8:30 PM, Jason Cooper wrote: > All, > > On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: >> To date, all callers of randomize_range() have set the length to 0, and >> check for a zero return value. For the current callers, the only way >> to get zero returned

Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 26 Jul 2016 03:09:16 + > BTW, during the past month, at least 7 other people also reviewed > the patch and gave me quite a few good comments, which have > been addressed. Correction: Several people gave coding style and simple corrections to

Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

From: Dexuan Cui Date: Tue, 26 Jul 2016 03:09:16 + > BTW, during the past month, at least 7 other people also reviewed > the patch and gave me quite a few good comments, which have > been addressed. Correction: Several people gave coding style and simple corrections to your patch. Very few

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Christian Lamparter wrote: > > As for carl9170: I'm not sure what the driver or firmware can do about > this at this time. You can try to disable the hardware crypto by setting > nohwcrypt via the module option. However, this might not do anything at all. The nohwcrypt parameter didn't make any

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Christian Lamparter wrote: > > As for carl9170: I'm not sure what the driver or firmware can do about > this at this time. You can try to disable the hardware crypto by setting > nohwcrypt via the module option. However, this might not do anything at all. The nohwcrypt parameter didn't make any

[PATCH 1/2] powerpc: mpc85xx_mds: Select PHYLIB only if NETDEVICES is enabled

PHYLIB depends on NETDEVICES, so to avoid unmet dependencies warning from Kconfig it needs to be selected conditionally. Also add checks if PHYLIB is built-in to avoid undefined references to PHYLIB's symbols. Signed-off-by: Andrey Smirnov ---

[PATCH 1/2] powerpc: mpc85xx_mds: Select PHYLIB only if NETDEVICES is enabled

PHYLIB depends on NETDEVICES, so to avoid unmet dependencies warning from Kconfig it needs to be selected conditionally. Also add checks if PHYLIB is built-in to avoid undefined references to PHYLIB's symbols. Signed-off-by: Andrey Smirnov --- arch/powerpc/platforms/85xx/Kconfig | 2 +-

[PATCH 2/2] powerpc: e8248e: Select PHYLIB only if NETDEVICES is enabled

Select PHYLIB only if NETDEVICES is enabled and MDIO_BITBANG only if PHYLIB is present to avoid warnings from Kconfig. To prevent undefined references during linking register MDIO driver only if CONFIG_MDIO_BITBANG is enabled. Signed-off-by: Andrey Smirnov ---

[PATCH 2/2] powerpc: e8248e: Select PHYLIB only if NETDEVICES is enabled

Select PHYLIB only if NETDEVICES is enabled and MDIO_BITBANG only if PHYLIB is present to avoid warnings from Kconfig. To prevent undefined references during linking register MDIO driver only if CONFIG_MDIO_BITBANG is enabled. Signed-off-by: Andrey Smirnov ---

[PATCH 2/3] powerpc: Call chained reset handlers during reset

Call out to all restart handlers that were added via register_restart_handler() API when restarting the machine. Signed-off-by: Andrey Smirnov --- arch/powerpc/kernel/setup-common.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

Convert fsl_rstcr_restart into a function to be registered with register_reset_handler() API and introduce fls_rstcr_restart_register() function that can be added as an initcall that would do aforementioned registration. Signed-off-by: Andrey Smirnov ---

[PATCH 2/3] powerpc: Call chained reset handlers during reset

Call out to all restart handlers that were added via register_restart_handler() API when restarting the machine. Signed-off-by: Andrey Smirnov --- arch/powerpc/kernel/setup-common.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/kernel/setup-common.c

[PATCH 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

Convert fsl_rstcr_restart into a function to be registered with register_reset_handler() API and introduce fls_rstcr_restart_register() function that can be added as an initcall that would do aforementioned registration. Signed-off-by: Andrey Smirnov ---

[PATCH 1/3] powerpc: Factor out common code in setup-common.c

Factor out a small bit of common code in machine_restart(), machine_power_off() and machine_halt(). Signed-off-by: Andrey Smirnov --- arch/powerpc/kernel/setup-common.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git

[PATCH 1/3] powerpc: Factor out common code in setup-common.c

Factor out a small bit of common code in machine_restart(), machine_power_off() and machine_halt(). Signed-off-by: Andrey Smirnov --- arch/powerpc/kernel/setup-common.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Mon, 25 Jul 2016 19:44:50 -0500 > >> User namespaces have enabled unprivileged users access to a lot more >> data structures and so to catch programs that go crazy we need a lot >> more limits. I

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Mon, 25 Jul 2016 19:44:50 -0500 > >> User namespaces have enabled unprivileged users access to a lot more >> data structures and so to catch programs that go crazy we need a lot >> more limits. I believe some of

[PATCH 3/3] mm/duet: framework code

The Duet framework code: - bittree.c: red-black bitmap tree that keeps track of items of interest - debug.c: functions used to print information used to debug Duet - hash.c: implementation of the global hash table where page events are stored for all tasks - hook.c: the function invoked by the

[PATCH 1/3] mm: support for duet hooks

Adds the Duet hooks in the page cache. In filemap.c, two hooks are added at the time of addition and removal of a page descriptor. In page-flags.h, two more hooks are added to track page dirtying and flushing. The hooks are inactive while Duet is offline. Signed-off-by: George Amvrosiadis

[PATCH 3/3] mm/duet: framework code

The Duet framework code: - bittree.c: red-black bitmap tree that keeps track of items of interest - debug.c: functions used to print information used to debug Duet - hash.c: implementation of the global hash table where page events are stored for all tasks - hook.c: the function invoked by the

[PATCH 1/3] mm: support for duet hooks

Adds the Duet hooks in the page cache. In filemap.c, two hooks are added at the time of addition and removal of a page descriptor. In page-flags.h, two more hooks are added to track page dirtying and flushing. The hooks are inactive while Duet is offline. Signed-off-by: George Amvrosiadis ---

[PATCH 2/3] mm/duet: syscall wiring

Usual syscall wiring for the four Duet syscalls. Signed-off-by: George Amvrosiadis --- arch/x86/entry/syscalls/syscall_32.tbl | 4 arch/x86/entry/syscalls/syscall_64.tbl | 4 include/linux/syscalls.h | 8 include/uapi/asm-generic/unistd.h

[PATCH 0/3] new feature: monitoring page cache events

I'm attaching a patch set implementing a mechanism we call Duet, which allows applications to monitor events at the page cache level: page additions, removals, dirtying, and flushing. Using such events, applications can identify and prioritize processing of cached data, thereby reducing their I/O

[PATCH 2/3] mm/duet: syscall wiring

Usual syscall wiring for the four Duet syscalls. Signed-off-by: George Amvrosiadis --- arch/x86/entry/syscalls/syscall_32.tbl | 4 arch/x86/entry/syscalls/syscall_64.tbl | 4 include/linux/syscalls.h | 8 include/uapi/asm-generic/unistd.h | 12

[PATCH 0/3] new feature: monitoring page cache events

I'm attaching a patch set implementing a mechanism we call Duet, which allows applications to monitor events at the page cache level: page additions, removals, dirtying, and flushing. Using such events, applications can identify and prioritize processing of cached data, thereby reducing their I/O

Re: [PATCH v2 3/3] x86/apic: Improved the setting of interrupt mode for bsp

Wei Jiangang writes: > If we specify the 'notsc' parameter for the dump-capture kernel, > and then trigger a crash(panic) by using "ALT-SysRq-c" or > "echo c > /proc/sysrq-trigger", the dump-capture kernel will > hang in calibrate_delay_converge() and wait for jiffies

Re: [PATCH v2 3/3] x86/apic: Improved the setting of interrupt mode for bsp

Wei Jiangang writes: > If we specify the 'notsc' parameter for the dump-capture kernel, > and then trigger a crash(panic) by using "ALT-SysRq-c" or > "echo c > /proc/sysrq-trigger", the dump-capture kernel will > hang in calibrate_delay_converge() and wait for jiffies changes. > serial log as

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/smp.c between commit: 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") from the tip tree and commit: ad5475f9faf5 ("x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op") from

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/smp.c between commit: 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") from the tip tree and commit: ad5475f9faf5 ("x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op") from

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/enlighten.c between commit: 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") from the tip tree and commit: 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") from the xen-tip

linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: arch/x86/xen/enlighten.c between commit: 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") from the tip tree and commit: 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") from the xen-tip

Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent

在 2016年07月26日 07:20, Andrew Morton 写道: On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang wrote: [Problem] cpuid <-> nodeid mapping is firstly established at boot time. And workqueue caches the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time. When

Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent

在 2016年07月26日 07:20, Andrew Morton 写道: On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang wrote: [Problem] cpuid <-> nodeid mapping is firstly established at boot time. And workqueue caches the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time. When doing node online/offline,

[e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Greetings, This BUG message can be found in recent kernels as well as v4.4 and linux-stable. It happens when running modprobe netconsole netconsole=@/,$port@$server/ [ 39.937534] 22 Jul 13:30:40 ntpdate[440]: step time server 192.168.1.1 offset -673.833841 sec [ 39.943285]

[e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Greetings, This BUG message can be found in recent kernels as well as v4.4 and linux-stable. It happens when running modprobe netconsole netconsole=@/,$port@$server/ [ 39.937534] 22 Jul 13:30:40 ntpdate[440]: step time server 192.168.1.1 offset -673.833841 sec [ 39.943285]

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On 2016年07月22日 14:26, Masashi Honma wrote: > On 2016年07月14日 05:07, Yaniv Machani wrote: >> + >> +/* if channel width is 20MHz - configure HT capab accordingly*/ >> +if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) { >> +cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40; >> +

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On 2016年07月22日 14:26, Masashi Honma wrote: > On 2016年07月14日 05:07, Yaniv Machani wrote: >> + >> +/* if channel width is 20MHz - configure HT capab accordingly*/ >> +if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) { >> +cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40; >> +

Re: [RFC patch 1/6] random: Simplify API for random address requests

All, On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: > To date, all callers of randomize_range() have set the length to 0, and > check for a zero return value. For the current callers, the only way > to get zero returned is if end <= start. Since they are all adding a > constant

Re: [RFC patch 1/6] random: Simplify API for random address requests

All, On Tue, Jul 26, 2016 at 03:01:55AM +, Jason Cooper wrote: > To date, all callers of randomize_range() have set the length to 0, and > check for a zero return value. For the current callers, the only way > to get zero returned is if end <= start. Since they are all adding a > constant

Re: [PATCH] iio: adc: rockchip_saradc: Explicitly disable ADC on probe

On 07/25/2016 07:51 PM, Caesar Wang wrote: Hi Guenter, Thanks for fixing it. On 2016年07月26日 03:39, Guenter Roeck wrote: If the ADC is read for the first time, the caller gets a timeout error, and the kernel log shows read channel() error: -110 The ADC may be enabled on boot, and needs to be

Re: [PATCH] iio: adc: rockchip_saradc: Explicitly disable ADC on probe

On 07/25/2016 07:51 PM, Caesar Wang wrote: Hi Guenter, Thanks for fixing it. On 2016年07月26日 03:39, Guenter Roeck wrote: If the ADC is read for the first time, the caller gets a timeout error, and the kernel log shows read channel() error: -110 The ADC may be enabled on boot, and needs to be

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

You must specify a mask for each L3 cache. So you can achieve your 80/80 split either with one rdtgroup that has an 80% mask on each of the sockets and using affinity to make one VM run only on CPUs on one socket and the second VM on the other. Or separate rdtgroups for each VM that give them

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

You must specify a mask for each L3 cache. So you can achieve your 80/80 split either with one rdtgroup that has an 80% mask on each of the sockets and using affinity to make one VM run only on CPUs on one socket and the second VM on the other. Or separate rdtgroups for each VM that give them

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > > From: Dexuan Cui > Date: Sat, 23 Jul 2016 01:35:51 + > > > +static struct sock *hvsock_create(struct net *net, struct socket *sock, > > + gfp_t priority, unsigned short type) > > +{ > > +

RE: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: David Miller [mailto:da...@davemloft.net] > > From: Dexuan Cui > Date: Sat, 23 Jul 2016 01:35:51 + > > > +static struct sock *hvsock_create(struct net *net, struct socket *sock, > > + gfp_t priority, unsigned short type) > > +{ > > + struct hvsock_sock

Re: [PATCH -next] drm/hisilicon: Fix error handling of ade_power_up()

On 19 July 2016 at 19:30, Wei Yongjun wrote: > From: Wei Yongjun > > Fix the reset_control_deassert() fail and clk_prepare_enable() fail > error handling of ade_power_up(). > > Signed-off-by: Wei Yongjun Applied,

Re: [PATCH -next] drm/hisilicon: Fix error handling of ade_power_up()

On 19 July 2016 at 19:30, Wei Yongjun wrote: > From: Wei Yongjun > > Fix the reset_control_deassert() fail and clk_prepare_enable() fail > error handling of ade_power_up(). > > Signed-off-by: Wei Yongjun Applied, thanks. -xinliang > --- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10

[RFC patch 6/6] unicore32: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 6/6] unicore32: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 2/6] x86: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 4/6] arm64: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 4/6] arm64: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 2/6] x86: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 3/6] ARM: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 5/6] tile: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 5/6] tile: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 3/6] ARM: Use simpler API for random address requests

Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Signed-off-by:

[RFC patch 1/6] random: Simplify API for random address requests

To date, all callers of randomize_range() have set the length to 0, and check for a zero return value. For the current callers, the only way to get zero returned is if end <= start. Since they are all adding a constant to the start address, this is unnecessary. We can remove a bunch of needless

[RFC patch 1/6] random: Simplify API for random address requests

To date, all callers of randomize_range() have set the length to 0, and check for a zero return value. For the current callers, the only way to get zero returned is if end <= start. Since they are all adding a constant to the start address, this is unnecessary. We can remove a bunch of needless

  1   2   3   4   5   6   7   8   9   10   >