Re: [PATCH v2] mmap.2: document new MAP_FIXED_SAFE flag

On Thu 30-11-17 10:31:12, John Hubbard wrote: > On 11/30/2017 12:24 AM, Michal Hocko wrote: > > Updated version based on feedback from John. > > --- > > From ade1eba229b558431581448e7d7838f0e1fe2c49 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Wed, 29 Nov 2017

Re: [PATCH v2] mmap.2: document new MAP_FIXED_SAFE flag

On Thu 30-11-17 10:31:12, John Hubbard wrote: > On 11/30/2017 12:24 AM, Michal Hocko wrote: > > Updated version based on feedback from John. > > --- > > From ade1eba229b558431581448e7d7838f0e1fe2c49 Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Wed, 29 Nov 2017 15:32:08 +0100 > >

Re: [PATCH v2] watchdog: stm32: Fix copyright

On Thu, Nov 30, 2017 at 09:48:04AM +0100, Benjamin Gaignard wrote: > Uniformize STMicroelectronics copyrights header > Add SPDX identifier > > Signed-off-by: Benjamin Gaignard > Acked-by: Alexandre TORGUE > CC: Yannick Fertre

Re: [PATCH v2] watchdog: stm32: Fix copyright

On Thu, Nov 30, 2017 at 09:48:04AM +0100, Benjamin Gaignard wrote: > Uniformize STMicroelectronics copyrights header > Add SPDX identifier > > Signed-off-by: Benjamin Gaignard > Acked-by: Alexandre TORGUE > CC: Yannick Fertre Reviewed-by: Guenter Roeck > --- > drivers/watchdog/stm32_iwdg.c

Re: [patches] Re: [PATCH 08/10] RISC-V: Set __ARCH_WANT_RENAMEAT to pick up generic version

On Thu, 30 Nov 2017 10:30:32 PST (-0800), Christoph Hellwig wrote: On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote: In file included from ../lib/audit.c:8:0: ../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat' undeclared here (not in a function); did you mean

[PATCH v2] ipc, mqueue: lazy call kern_mount_data in new namespaces

kern_mount_data is a relatively expensive operation when creating a new IPC namespace, so delay the mount until its first usage when not creating the the global namespace. This is a net saving for new IPC namespaces that don't use mq_open(). In this case there won't be any kern_mount_data() cost

Re: [patches] Re: [PATCH 08/10] RISC-V: Set __ARCH_WANT_RENAMEAT to pick up generic version

On Thu, 30 Nov 2017 10:30:32 PST (-0800), Christoph Hellwig wrote: On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote: In file included from ../lib/audit.c:8:0: ../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat' undeclared here (not in a function); did you mean

[PATCH v2] ipc, mqueue: lazy call kern_mount_data in new namespaces

kern_mount_data is a relatively expensive operation when creating a new IPC namespace, so delay the mount until its first usage when not creating the the global namespace. This is a net saving for new IPC namespaces that don't use mq_open(). In this case there won't be any kern_mount_data() cost

Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()

On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote: > On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote: > > > > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote: > > > > > > > > > > > Yes.  You still shall not play nasty games with file > > > > descriptors.

Re: [PATCH v6 09/11] fs/pipe.c: export create_pipe_files() and replace_fd()

On Thu, 2017-11-30 at 18:43 +0200, Jarkko Sakkinen wrote: > On Wed, Nov 29, 2017 at 03:13:57PM -0800, Christoph Hellwig wrote: > > > > On Tue, Nov 28, 2017 at 11:57:53PM +0200, Jarkko Sakkinen wrote: > > > > > > > > > > > Yes.  You still shall not play nasty games with file > > > > descriptors.

RE: [PATCH v6 0/2] Fix corner cases with disabling CLKRUN in tpm_tis

>-Original Message- >From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] >Sent: Thursday, November 30, 2017 8:35 AM >To: Shaikh, Azhar >Cc: jguntho...@obsidianresearch.com; peterhu...@gmx.de; linux-security- >mod...@vger.kernel.org;

RE: [PATCH v6 0/2] Fix corner cases with disabling CLKRUN in tpm_tis

>-Original Message- >From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] >Sent: Thursday, November 30, 2017 8:35 AM >To: Shaikh, Azhar >Cc: jguntho...@obsidianresearch.com; peterhu...@gmx.de; linux-security- >mod...@vger.kernel.org; linux-kernel@vger.kernel.org; tpmdd-

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

Hi, 2017-11-30 12:27 GMT+01:00 Daniel Thompson : > > > On 30/11/17 00:44, Doug Anderson wrote: >> >> Hi, >> >> On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra >> wrote: >>> >>> When you want to change the brightness using a PWM

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

Hi, 2017-11-30 12:27 GMT+01:00 Daniel Thompson : > > > On 30/11/17 00:44, Doug Anderson wrote: >> >> Hi, >> >> On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra >> wrote: >>> >>> When you want to change the brightness using a PWM signal, one thing you >>> need to consider is how human

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

[ adding linux-rdma ] On Thu, Nov 30, 2017 at 10:17 AM, Michal Hocko wrote: > > On Thu 30-11-17 10:03:26, Dan Williams wrote: > > On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > > > > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > > > On Thu,

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

[ adding linux-rdma ] On Thu, Nov 30, 2017 at 10:17 AM, Michal Hocko wrote: > > On Thu 30-11-17 10:03:26, Dan Williams wrote: > > On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > > > > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko

Re: [PATCH v2] mmap.2: document new MAP_FIXED_SAFE flag

On 11/30/2017 12:24 AM, Michal Hocko wrote: > Updated version based on feedback from John. > --- > From ade1eba229b558431581448e7d7838f0e1fe2c49 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Wed, 29 Nov 2017 15:32:08 +0100 > Subject: [PATCH] mmap.2: document new

Re: [PATCH v2] mmap.2: document new MAP_FIXED_SAFE flag

On 11/30/2017 12:24 AM, Michal Hocko wrote: > Updated version based on feedback from John. > --- > From ade1eba229b558431581448e7d7838f0e1fe2c49 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Wed, 29 Nov 2017 15:32:08 +0100 > Subject: [PATCH] mmap.2: document new MAP_FIXED_SAFE flag > >

[PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by sparse Signed-off-by: Andrii Vladyka diff --git a/drivers/staging/lustre/lustre/lov/lov_object.c b/drivers/staging/lustre/lustre/lov/lov_object.c index 105b707..897cf2c 100644 ---

[PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by sparse Signed-off-by: Andrii Vladyka diff --git a/drivers/staging/lustre/lustre/lov/lov_object.c b/drivers/staging/lustre/lustre/lov/lov_object.c index 105b707..897cf2c 100644 ---

Re: [PATCH 08/10] RISC-V: Set __ARCH_WANT_RENAMEAT to pick up generic version

On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote: > In file included from ../lib/audit.c:8:0: > ../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat' > undeclared here (not in a function); did you mean '__NR_renameat2'? I think the audit code should be fixed

Re: [PATCH 08/10] RISC-V: Set __ARCH_WANT_RENAMEAT to pick up generic version

On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote: > In file included from ../lib/audit.c:8:0: > ../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat' > undeclared here (not in a function); did you mean '__NR_renameat2'? I think the audit code should be fixed

Re: [PATCH v2 11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables

Hi Will, On Thu, Nov 30, 2017 at 04:39:39PM +, Will Deacon wrote: > diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h > index 4052ec39e8db..8119b49be98d 100644 > --- a/arch/arm64/include/asm/fixmap.h > +++ b/arch/arm64/include/asm/fixmap.h > @@ -58,6 +58,10 @@

Re: [PATCH v2 11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables

Hi Will, On Thu, Nov 30, 2017 at 04:39:39PM +, Will Deacon wrote: > diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h > index 4052ec39e8db..8119b49be98d 100644 > --- a/arch/arm64/include/asm/fixmap.h > +++ b/arch/arm64/include/asm/fixmap.h > @@ -58,6 +58,10 @@

[PATCH net-next v2] vmxnet3: increase default rx ring sizes

There are several reasons for increasing the receive ring sizes: 1. The original ring size of 256 was chosen about 10 years ago when vmxnet3 was first created. At that time, 10Gbps Ethernet was not prevalent and servers were dominated by 1Gbps Ethernet. Now 10Gbps is common place, and higher

[PATCH net-next v2] vmxnet3: increase default rx ring sizes

There are several reasons for increasing the receive ring sizes: 1. The original ring size of 256 was chosen about 10 years ago when vmxnet3 was first created. At that time, 10Gbps Ethernet was not prevalent and servers were dominated by 1Gbps Ethernet. Now 10Gbps is common place, and higher

Re: [PATCH] vfio/iommu_type1: report the IOMMU aperture info

On Thu, 30 Nov 2017 16:11:35 +0100 Pierre Morel wrote: > On 30/11/2017 15:08, Alex Williamson wrote: > > On Thu, 30 Nov 2017 12:34:38 +0100 > > Pierre Morel wrote: > > > >> When userland VFIO defines a new IOMMU for a guest it may > >>

Re: [PATCH] vfio/iommu_type1: report the IOMMU aperture info

On Thu, 30 Nov 2017 16:11:35 +0100 Pierre Morel wrote: > On 30/11/2017 15:08, Alex Williamson wrote: > > On Thu, 30 Nov 2017 12:34:38 +0100 > > Pierre Morel wrote: > > > >> When userland VFIO defines a new IOMMU for a guest it may > >> want to specify to the guest the physical limits of > >>

Re: [PATCH/RFC] Re: 'perf test BPF' failing, libbpf regression wrt "basic API for BPF obj name"

On Thu, Nov 30, 2017 at 01:53:58PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 30, 2017 at 12:01:10AM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Nov 29, 2017 at 02:31:36PM -0800, Martin KaFai Lau escreveu: > > > On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo

Re: [PATCH/RFC] Re: 'perf test BPF' failing, libbpf regression wrt "basic API for BPF obj name"

On Thu, Nov 30, 2017 at 01:53:58PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 30, 2017 at 12:01:10AM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Nov 29, 2017 at 02:31:36PM -0800, Martin KaFai Lau escreveu: > > > On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo

Re: [patches] [PATCH 00/10] RISC-V: Fixes for clean allmodconfig build

On Wed, 29 Nov 2017 17:55:11 PST (-0800), Olof Johansson wrote: Here's a short series of patches that produces a working allmodconfig. Would be nice to see them go in so we can add build coverage. I was just about to send a pull request when these came in last night, so it's good timing :).

Re: [patches] [PATCH 06/10] RISC-V: Provide stub of setup_profiling_timer()

On Wed, 29 Nov 2017 17:55:17 PST (-0800), Olof Johansson wrote: Fixes the following on allmodconfig build: profile.c:(.text+0x3e4): undefined reference to `setup_profiling_timer' Signed-off-by: Olof Johansson --- arch/riscv/kernel/smp.c | 8 1 file changed, 8

Re: [patches] [PATCH 00/10] RISC-V: Fixes for clean allmodconfig build

On Wed, 29 Nov 2017 17:55:11 PST (-0800), Olof Johansson wrote: Here's a short series of patches that produces a working allmodconfig. Would be nice to see them go in so we can add build coverage. I was just about to send a pull request when these came in last night, so it's good timing :).

Re: [patches] [PATCH 06/10] RISC-V: Provide stub of setup_profiling_timer()

On Wed, 29 Nov 2017 17:55:17 PST (-0800), Olof Johansson wrote: Fixes the following on allmodconfig build: profile.c:(.text+0x3e4): undefined reference to `setup_profiling_timer' Signed-off-by: Olof Johansson --- arch/riscv/kernel/smp.c | 8 1 file changed, 8 insertions(+) diff

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 11/29/2017 6:44 AM, Paolo Bonzini wrote: I actually like this patch, except that I'd get the e820 memory map from fw_cfg (see the first part of https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820 inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the second

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 11/29/2017 6:44 AM, Paolo Bonzini wrote: I actually like this patch, except that I'd get the e820 memory map from fw_cfg (see the first part of https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820 inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the second

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

From: Joe Perches Date: Thu, 30 Nov 2017 10:18:24 -0800 > _Nobody_ reads everything on lkml. True, in fact I don't read lkml at all. That wasn't the point I was trying to make.

[PATCH 2/3] net: macb: Added some queue statistics

Added statistics per queue: - qX_rx_packets - qX_rx_bytes - qX_rx_dropped - qX_tx_packets - qX_tx_bytes - qX_tx_dropped Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 31 +- drivers/net/ethernet/cadence/macb_main.c | 37

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

From: Joe Perches Date: Thu, 30 Nov 2017 10:18:24 -0800 > _Nobody_ reads everything on lkml. True, in fact I don't read lkml at all. That wasn't the point I was trying to make.

[PATCH 2/3] net: macb: Added some queue statistics

Added statistics per queue: - qX_rx_packets - qX_rx_bytes - qX_rx_dropped - qX_tx_packets - qX_tx_bytes - qX_tx_dropped Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 31 +- drivers/net/ethernet/cadence/macb_main.c | 37

[PATCH 3/3] net: macb: Added support for RX filtering

This patch allows filtering received packets to different hardware queues (aka ntuple). Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 109 ++ drivers/net/ethernet/cadence/macb_main.c | 336 ++- 2 files

[PATCH 3/3] net: macb: Added support for RX filtering

This patch allows filtering received packets to different hardware queues (aka ntuple). Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 109 ++ drivers/net/ethernet/cadence/macb_main.c | 336 ++- 2 files changed, 444 insertions(+),

[PATCH 1/3] net: macb: Added support for many RX queues

To be able for packet reception on different RX queues some configuration has to be performed. This patch checks how many hardware queue does GEM support and initializes them. Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 26 ++-

[PATCH 1/3] net: macb: Added support for many RX queues

To be able for packet reception on different RX queues some configuration has to be performed. This patch checks how many hardware queue does GEM support and initializes them. Signed-off-by: Rafal Ozieblo --- drivers/net/ethernet/cadence/macb.h | 26 ++-

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Thu, 2017-11-30 at 13:13 -0500, David Miller wrote: > From: Joe Perches > Date: Thu, 30 Nov 2017 10:06:51 -0800 > > > Excuse is probably the wrong word here David. > > Rationale maybe... > > I guess you turn a blind eye to the hundreds of the rxrpc patches > David has

[PATCH 0/3] Receive packets filtering for macb driver

This patch series adds support for receive packets filtering for Cadence GEM driver. Packets can be redirect to different hardware queues based on source IP, destination IP, source port or destination port. To enable filtering, support for RX queueing was added as well. Rafal Ozieblo (3): net:

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Thu, 2017-11-30 at 13:13 -0500, David Miller wrote: > From: Joe Perches > Date: Thu, 30 Nov 2017 10:06:51 -0800 > > > Excuse is probably the wrong word here David. > > Rationale maybe... > > I guess you turn a blind eye to the hundreds of the rxrpc patches > David has posted here over the

[PATCH 0/3] Receive packets filtering for macb driver

This patch series adds support for receive packets filtering for Cadence GEM driver. Packets can be redirect to different hardware queues based on source IP, destination IP, source port or destination port. To enable filtering, support for RX queueing was added as well. Rafal Ozieblo (3): net:

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

On Thu 30-11-17 10:03:26, Dan Williams wrote: > On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote: > > > > On Wed 29-11-17 10:05:35, Dan

Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller

On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote: [...] > >> For linux-next, I applied this series on top of Kishon's patch > >> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent") > >> otherwise dma_alloc_coherent() fails when called by

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

On Thu 30-11-17 10:03:26, Dan Williams wrote: > On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote: > > > > On Wed 29-11-17 10:05:35, Dan Williams wrote: > > > >> Until there is a

Re: [PATCH 0/5] PCI: Add support to the Cadence PCIe controller

On Thu, Nov 30, 2017 at 12:43:20PM +0530, Kishon Vijay Abraham I wrote: [...] > >> For linux-next, I applied this series on top of Kishon's patch > >> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent") > >> otherwise dma_alloc_coherent() fails when called by

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

From: Joe Perches Date: Thu, 30 Nov 2017 10:06:51 -0800 > Excuse is probably the wrong word here David. > Rationale maybe... I guess you turn a blind eye to the hundreds of the rxrpc patches David has posted here over the past few months That's all I'm saying. If you see

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

From: Joe Perches Date: Thu, 30 Nov 2017 10:06:51 -0800 > Excuse is probably the wrong word here David. > Rationale maybe... I guess you turn a blind eye to the hundreds of the rxrpc patches David has posted here over the past few months That's all I'm saying. If you see reality is

[PATCH] hwmon: (max31785) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH] hwmon: (max31785) Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [pcpu] BUG: KASAN: use-after-scope in pcpu_setup_first_chunk+0x1e3b/0x29e2

On Thu, Nov 30, 2017 at 1:59 AM, Dmitry Vyukov wrote: > On Wed, Nov 29, 2017 at 6:54 PM, Dennis Zhou wrote: >> Hi everyone, >> >> I spent a bit of time learning more about this problem as Fengguang was >> able to determine the root commit

Re: [pcpu] BUG: KASAN: use-after-scope in pcpu_setup_first_chunk+0x1e3b/0x29e2

On Thu, Nov 30, 2017 at 1:59 AM, Dmitry Vyukov wrote: > On Wed, Nov 29, 2017 at 6:54 PM, Dennis Zhou wrote: >> Hi everyone, >> >> I spent a bit of time learning more about this problem as Fengguang was >> able to determine the root commit f7dd2507893cc3. I reproduced the bug >> in userspace to

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

Thomas Gleixner writes: > On Tue, 31 Oct 2017, mikel...@exchange.microsoft.com wrote: > > diff --git a/arch/x86/include/uapi/asm/hyperv.h > > b/arch/x86/include/uapi/asm/hyperv.h > > index f65d125..408cf3e 100644 > > --- a/arch/x86/include/uapi/asm/hyperv.h > > +++

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

Thomas Gleixner writes: > On Tue, 31 Oct 2017, mikel...@exchange.microsoft.com wrote: > > diff --git a/arch/x86/include/uapi/asm/hyperv.h > > b/arch/x86/include/uapi/asm/hyperv.h > > index f65d125..408cf3e 100644 > > --- a/arch/x86/include/uapi/asm/hyperv.h > > +++

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

Vitaly Kuznetsov writes: > Vitaly Kuznetsov writes: > > > mikel...@exchange.microsoft.com writes: > > > >> From: Michael Kelley > >> > >> The 2016 version of Hyper-V offers the option to operate the guest VM > >> per-vcpu

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

Vitaly Kuznetsov writes: > Vitaly Kuznetsov writes: > > > mikel...@exchange.microsoft.com writes: > > > >> From: Michael Kelley > >> > >> The 2016 version of Hyper-V offers the option to operate the guest VM > >> per-vcpu stimer's in Direct Mode, which means the timer interupts on > >> its

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Thu, 2017-11-30 at 12:31 -0500, David Miller wrote: > From: Joe Perches > Date: Thu, 30 Nov 2017 08:21:14 -0800 > > > When enabled, the current debug logging does not have a KERN_. > > Add KERN_DEBUG to the logging macros. > > > > Miscellanea: > > > > o Remove #define

Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Thu, 2017-11-30 at 12:31 -0500, David Miller wrote: > From: Joe Perches > Date: Thu, 30 Nov 2017 08:21:14 -0800 > > > When enabled, the current debug logging does not have a KERN_. > > Add KERN_DEBUG to the logging macros. > > > > Miscellanea: > > > > o Remove #define redundancy and neaten

[PATCH 1/2] KVM: x86: fix APIC page invalidation

Implementation of the unpinned APIC page didn't update the VMCS address cache when invalidation was done through range mmu notifiers. This became a problem when the page notifier was removed. Re-introduce the arch-specific helper and call it from ...range_start. Fixes: 38b9917350cb ("kvm: vmx:

[PATCH 2/2] TESTING! KVM: x86: add invalidate_range mmu notifier

Does roughly what kvm_mmu_notifier_invalidate_page did before. I am not certain why this would be needed. It might mean that we have another bug with start/end or just that I missed something. Please try just [1/2] first and apply this one only if [1/2] still bugs, thanks! ---

[PATCH 1/2] KVM: x86: fix APIC page invalidation

Implementation of the unpinned APIC page didn't update the VMCS address cache when invalidation was done through range mmu notifiers. This became a problem when the page notifier was removed. Re-introduce the arch-specific helper and call it from ...range_start. Fixes: 38b9917350cb ("kvm: vmx:

[PATCH 2/2] TESTING! KVM: x86: add invalidate_range mmu notifier

Does roughly what kvm_mmu_notifier_invalidate_page did before. I am not certain why this would be needed. It might mean that we have another bug with start/end or just that I missed something. Please try just [1/2] first and apply this one only if [1/2] still bugs, thanks! ---

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote: > > > On Wed 29-11-17 10:05:35, Dan Williams wrote: > > >> Until there is a solution to the

Re: [PATCH v3 1/4] mm: introduce get_user_pages_longterm

On Thu, Nov 30, 2017 at 9:42 AM, Michal Hocko wrote: > > On Thu 30-11-17 08:39:51, Dan Williams wrote: > > On Thu, Nov 30, 2017 at 1:53 AM, Michal Hocko wrote: > > > On Wed 29-11-17 10:05:35, Dan Williams wrote: > > >> Until there is a solution to the dma-to-dax vs truncate problem it is > > >>

Re: [PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()

From: Florian Fainelli Date: Thu, 30 Nov 2017 09:55:35 -0800 > Utilize the much more capable b53_get_tag_protocol() which takes care of > all Broadcom switches specifics to resolve which port can have Broadcom > tags enabled or not. > > Signed-off-by: Florian Fainelli

Re: [PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()

From: Florian Fainelli Date: Thu, 30 Nov 2017 09:55:35 -0800 > Utilize the much more capable b53_get_tag_protocol() which takes care of > all Broadcom switches specifics to resolve which port can have Broadcom > tags enabled or not. > > Signed-off-by: Florian Fainelli Applied, thanks Florian.

[PATCH net-next 1/2] net: dsa: introduce dsa_towards_port helper

Add a new helper returning the local port used to reach an arbitrary switch port in the fabric. Its only user at the moment is the dsa_upstream_port helper, which returns the local port reaching the dedicated CPU port, but it will be used in cross-chip FDB operations. Signed-off-by: Vivien

[PATCH net-next 1/2] net: dsa: introduce dsa_towards_port helper

Add a new helper returning the local port used to reach an arbitrary switch port in the fabric. Its only user at the moment is the dsa_upstream_port helper, which returns the local port reaching the dedicated CPU port, but it will be used in cross-chip FDB operations. Signed-off-by: Vivien

[PATCH net-next 0/2] net: dsa: cross-chip FDB support

DSA can have interconnected switches. For instance, the ZII Dev Rev B board described in arch/arm/boot/dts/vf610-zii-dev-rev-b.dts has a switch fabric composed of 3 switch devices like this: lan4 lan6 CPU (eth1)| lan5 | lan7

[PATCH net-next 0/2] net: dsa: cross-chip FDB support

DSA can have interconnected switches. For instance, the ZII Dev Rev B board described in arch/arm/boot/dts/vf610-zii-dev-rev-b.dts has a switch fabric composed of 3 switch devices like this: lan4 lan6 CPU (eth1)| lan5 | lan7

Re: Unlock-lock questions and the Linux Kernel Memory Model

On Thu, 30 Nov 2017, Paul E. McKenney wrote: > > > Will, are there plans to bring this sort of thing before the standards > > > committee? > > > > We discussed it, but rejected it mainly because of concerns that there could > > be RmW operations that don't necessarily have an order-inducing

Re: Unlock-lock questions and the Linux Kernel Memory Model

On Thu, 30 Nov 2017, Paul E. McKenney wrote: > > > Will, are there plans to bring this sort of thing before the standards > > > committee? > > > > We discussed it, but rejected it mainly because of concerns that there could > > be RmW operations that don't necessarily have an order-inducing

[PATCH net-next 2/2] net: dsa: support cross-chip FDB operations

When a MAC address is added to or removed from a switch port in the fabric, the target switch must program its port and adjacent switches must program their local DSA port used to reach the target switch. For this purpose, use the dsa_towards_port() helper to identify the local switch port which

[PATCH net-next 2/2] net: dsa: support cross-chip FDB operations

When a MAC address is added to or removed from a switch port in the fabric, the target switch must program its port and adjacent switches must program their local DSA port used to reach the target switch. For this purpose, use the dsa_towards_port() helper to identify the local switch port which

[PATCH] ASoC: tfa9879: Export OF device ID as module alias

The I2C core always reports a MODALIAS of the form i2c: even if the device was registered via OF, this means that exporting the OF device ID table device aliases in the module is not needed. But in order to change how the core reports modaliases to user-space, it's better to export it. Before

[PATCH] ASoC: tfa9879: Export OF device ID as module alias

The I2C core always reports a MODALIAS of the form i2c: even if the device was registered via OF, this means that exporting the OF device ID table device aliases in the module is not needed. But in order to change how the core reports modaliases to user-space, it's better to export it. Before

[PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()

Utilize the much more capable b53_get_tag_protocol() which takes care of all Broadcom switches specifics to resolve which port can have Broadcom tags enabled or not. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 4 ++--

[PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()

Utilize the much more capable b53_get_tag_protocol() which takes care of all Broadcom switches specifics to resolve which port can have Broadcom tags enabled or not. Signed-off-by: Florian Fainelli --- drivers/net/dsa/b53/b53_common.c | 4 ++-- drivers/net/dsa/b53/b53_priv.h | 1 +

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Thu, Nov 30, 2017 at 04:53:06PM +, David Laight wrote: > From: Salvatore Mesoraca > > if a program tries to open a file, in a sticky directory, > > with the O_CREAT flag and without the O_EXCL, it probably has a bug. > > This feature allows to detect and potentially block programs that > >

Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

On Thu, Nov 30, 2017 at 04:53:06PM +, David Laight wrote: > From: Salvatore Mesoraca > > if a program tries to open a file, in a sticky directory, > > with the O_CREAT flag and without the O_EXCL, it probably has a bug. > > This feature allows to detect and potentially block programs that > >

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

On Freitag, 10. November 2017 00:34:53 CET Bastien Nocera wrote: > On Thu, 2017-11-09 at 23:44 +0100, Stefan Brüns wrote: > > The key has the same use as the SW_ROTATE_LOCK, but is used on > > devices > > where the state is not tracked by the hardware but has to be handled > > in software. > >

Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE

On Freitag, 10. November 2017 00:34:53 CET Bastien Nocera wrote: > On Thu, 2017-11-09 at 23:44 +0100, Stefan Brüns wrote: > > The key has the same use as the SW_ROTATE_LOCK, but is used on > > devices > > where the state is not tracked by the hardware but has to be handled > > in software. > >

Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

On Wed, Nov 29, 2017 at 04:30:33PM -0800, Nick Desaulniers wrote: > Rather than: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > if CONFIG_ARM64_ERRATUM_843419 == '': > ... > > could this be: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > else > ... > > ? Sure. I'll clean this up

Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

On Wed, Nov 29, 2017 at 04:30:33PM -0800, Nick Desaulniers wrote: > Rather than: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > if CONFIG_ARM64_ERRATUM_843419 == '': > ... > > could this be: > > if CONFIG_ARM64_ERRATUM_843419 == y: > ... > else > ... > > ? Sure. I'll clean this up

[PATCH v8 03/13] slimbus: Add SLIMbus bus type

From: Sagar Dharia SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus

[PATCH v8 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla Thanks for everyone who reviewed v7 patchset, here is v8 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a

[PATCH v8 03/13] slimbus: Add SLIMbus bus type

From: Sagar Dharia SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus uses

[PATCH v8 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla Thanks for everyone who reviewed v7 patchset, here is v8 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is

[PATCH v8 01/13] Documentation: Add SLIMbus summary

From: Sagar Dharia SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. The

[PATCH v8 01/13] Documentation: Add SLIMbus summary

From: Sagar Dharia SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. The summary of SLIMbus and API is

[PATCH v8 04/13] slimbus: core: Add slim controllers support

From: Sagar Dharia This patch adds support to slim controllers in the slim core, including some utility functions invoked by the controller and slim device drivers. Signed-off-by: Srinivas Kandagatla --- drivers/slimbus/core.c| 306

[PATCH v8 04/13] slimbus: core: Add slim controllers support

From: Sagar Dharia This patch adds support to slim controllers in the slim core, including some utility functions invoked by the controller and slim device drivers. Signed-off-by: Srinivas Kandagatla --- drivers/slimbus/core.c| 306 ++

Re: [PATCH 5/7] arm64: keep .altinstructions and .altinstr_replacement

On Thu, Nov 30, 2017 at 11:58:27AM +1000, Nicholas Piggin wrote: > So yes please if it's not too much trouble, could you remove > the "gold" name from the generic patch and put it at the front > of the series with this arm64 patch. Sure, I'll do this in v2. > Possibly then you could also do a

[PATCH v8 06/13] slimbus: Add messaging APIs to slimbus framework

From: Sagar Dharia SLIMbus devices use value-element, and information elements to control device parameters (e.g. value element is used to represent gain for codec, information element is used to represent interrupt status for codec when codec interrupt fires). Messaging

<    5   6   7   8   9   10   11   12   13   14   >