Re: [PATCH 0/7] Support for automatic checkpatch running in the kernel

On Thu, 2017-11-16 at 14:57 -0800, Kees Cook wrote: > On Thu, Nov 16, 2017 at 9:01 AM, Knut Omang wrote: > > The most important checkpatch feature added is the --ignore-cfg feature, > > which > > takes a file argument and parses that file according to this minimal > >

Re: [PATCH 0/7] Support for automatic checkpatch running in the kernel

On Thu, 2017-11-16 at 14:57 -0800, Kees Cook wrote: > On Thu, Nov 16, 2017 at 9:01 AM, Knut Omang wrote: > > The most important checkpatch feature added is the --ignore-cfg feature, > > which > > takes a file argument and parses that file according to this minimal > > language: > > > >#

Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao wrote: > Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs > without "-o size=XXX". > When we mount tmpfs in a container(i.e. docker), it is also > totalram_pages / 2 regardless of the memory limit on this

Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao wrote: > Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs > without "-o size=XXX". > When we mount tmpfs in a container(i.e. docker), it is also > totalram_pages / 2 regardless of the memory limit on this container. > That may

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

On Thu, Nov 16, 2017 at 05:29:35PM +, Srinivas Kandagatla wrote: > thanks for the comments. > > > On 16/11/17 16:42, Vinod Koul wrote: > >On Wed, Nov 15, 2017 at 02:10:34PM +, srinivas.kandaga...@linaro.org > >wrote: > > > >>+static void slim_dev_release(struct device *dev) > >>+{ > >>+

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

On Thu, Nov 16, 2017 at 05:29:35PM +, Srinivas Kandagatla wrote: > thanks for the comments. > > > On 16/11/17 16:42, Vinod Koul wrote: > >On Wed, Nov 15, 2017 at 02:10:34PM +, srinivas.kandaga...@linaro.org > >wrote: > > > >>+static void slim_dev_release(struct device *dev) > >>+{ > >>+

Re: HiKey boot hangs with Linus' HEAD due to coresight dts changes?

On Thu, Nov 16, 2017 at 08:15:15PM -0800, John Stultz wrote: > On Thu, Nov 16, 2017 at 6:06 PM, Leo Yan wrote: > > Hi John, > > > > On Thu, Nov 16, 2017 at 05:58:54PM -0800, John Stultz wrote: > >> On Thu, Nov 16, 2017 at 5:54 PM, John Stultz > >>

Re: HiKey boot hangs with Linus' HEAD due to coresight dts changes?

On Thu, Nov 16, 2017 at 08:15:15PM -0800, John Stultz wrote: > On Thu, Nov 16, 2017 at 6:06 PM, Leo Yan wrote: > > Hi John, > > > > On Thu, Nov 16, 2017 at 05:58:54PM -0800, John Stultz wrote: > >> On Thu, Nov 16, 2017 at 5:54 PM, John Stultz > >> wrote: > >> > Testing with Linus' HEAD today on

[PATCH V10 4/4] libsas: Align sata_device's rps_resp on a cacheline

The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate with an SATA device behind a SAS

linux-next: Tree for Nov 17

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171116: The vfs tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 3321 2505 files changed, 198683 insertions(+), 31988

[PATCH V10 4/4] libsas: Align sata_device's rps_resp on a cacheline

The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate with an SATA device behind a SAS

linux-next: Tree for Nov 17

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171116: The vfs tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 3321 2505 files changed, 198683 insertions(+), 31988

[PATCH V10 2/4] MIPS: Implement dma_map_ops::get_cache_alignment()

Currently, MIPS is an architecture which support coherent & noncoherent devices co-exist. So implement get_cache_alignment() function pointer in 'struct dma_map_ops' to return different dma alignments. Signed-off-by: Huacai Chen --- arch/mips/cavium-octeon/dma-octeon.c

[PATCH V10 3/4] scsi: Align block queue to dma_get_cache_alignment()

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to ARCH_DMA_MINALIGN. Otherwise, If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no

[PATCH V10 2/4] MIPS: Implement dma_map_ops::get_cache_alignment()

Currently, MIPS is an architecture which support coherent & noncoherent devices co-exist. So implement get_cache_alignment() function pointer in 'struct dma_map_ops' to return different dma alignments. Signed-off-by: Huacai Chen --- arch/mips/cavium-octeon/dma-octeon.c| 3 ++-

[PATCH V10 3/4] scsi: Align block queue to dma_get_cache_alignment()

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to ARCH_DMA_MINALIGN. Otherwise, If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 02:54P, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 10:50:36 AM CET WANG Chao wrote: > > On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > > > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > > > On 11/15/17 at 02:13P, Rafael J. Wysocki wrote: > > >

[PATCH V10 1/4] dma-mapping: Rework dma_get_cache_alignment()

Make dma_get_cache_alignment() to accept a 'dev' argument. As a result, it can return different alignments due to different devices' I/O cache coherency. Currently, ARM/ARM64 and MIPS support coherent & noncoherent devices co-exist. This may be extended in the future, so add a new function

Re: [PATCH] x86 / CPU: Always show current CPU frequency in /proc/cpuinfo

On 11/16/17 at 02:54P, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 10:50:36 AM CET WANG Chao wrote: > > On 11/16/17 at 01:24P, Rafael J. Wysocki wrote: > > > On Wednesday, November 15, 2017 10:33:47 AM CET WANG Chao wrote: > > > > On 11/15/17 at 02:13P, Rafael J. Wysocki wrote: > > >

[PATCH V10 1/4] dma-mapping: Rework dma_get_cache_alignment()

Make dma_get_cache_alignment() to accept a 'dev' argument. As a result, it can return different alignments due to different devices' I/O cache coherency. Currently, ARM/ARM64 and MIPS support coherent & noncoherent devices co-exist. This may be extended in the future, so add a new function

Re: [RFC PATCH] blk-throttle: add burst allowance.

On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> Allows configuration additional bytes or ios before a throttle is >> triggered. >> >> This allows implementation of a bucket style rate-limit/throttle on a

Re: [RFC PATCH] blk-throttle: add burst allowance.

On Thu, Nov 16, 2017 at 8:50 AM, Shaohua Li wrote: > On Tue, Nov 14, 2017 at 03:10:22PM -0800, Khazhismel Kumykov wrote: >> Allows configuration additional bytes or ios before a throttle is >> triggered. >> >> This allows implementation of a bucket style rate-limit/throttle on a >> block device.

Re: HiKey boot hangs with Linus' HEAD due to coresight dts changes?

On Thu, Nov 16, 2017 at 6:06 PM, Leo Yan wrote: > Hi John, > > On Thu, Nov 16, 2017 at 05:58:54PM -0800, John Stultz wrote: >> On Thu, Nov 16, 2017 at 5:54 PM, John Stultz wrote: >> > Testing with Linus' HEAD today on the HiKey board, I started seeing

Re: HiKey boot hangs with Linus' HEAD due to coresight dts changes?

On Thu, Nov 16, 2017 at 6:06 PM, Leo Yan wrote: > Hi John, > > On Thu, Nov 16, 2017 at 05:58:54PM -0800, John Stultz wrote: >> On Thu, Nov 16, 2017 at 5:54 PM, John Stultz wrote: >> > Testing with Linus' HEAD today on the HiKey board, I started seeing boot >> > hangs: >> > ... >> > >> > [

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

On Fri, Nov 17, 2017 at 01:16:36PM +1030, Joel Stanley wrote: > Looks like this was mistakenly added to the tree as part of > commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). > > Signed-off-by: Joel Stanley Acked-by: Michael S. Tsirkin > --- >

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

On Fri, Nov 17, 2017 at 01:16:36PM +1030, Joel Stanley wrote: > Looks like this was mistakenly added to the tree as part of > commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). > > Signed-off-by: Joel Stanley Acked-by: Michael S. Tsirkin > --- > drivers/net/virtio_net. | 0 > 1 file

[PATCH v2] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

The Dell SMBIOS WMI interface will fail for some more complex calls unless a WMI hotfix has been included. Most platforms have this fix available in a maintenance BIOS release. In the case the driver is loaded on a platform without this fix, disable the userspace interface. A hotfix indicator

[PATCH v2] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

The Dell SMBIOS WMI interface will fail for some more complex calls unless a WMI hotfix has been included. Most platforms have this fix available in a maintenance BIOS release. In the case the driver is loaded on a platform without this fix, disable the userspace interface. A hotfix indicator

Re: [PATCH] regulator: tps65218: Add NULL test for devm_kzalloc call

On Fri, 2017-11-17 at 11:58 +0800, Axel Lin wrote: > 2017-11-16 19:23 GMT+08:00 Keerthy : > > > > > > On Monday 13 November 2017 06:22 PM, Axel Lin wrote: > > > Signed-off-by: Axel Lin > > > > One line commit message would be better than blank commit

Re: [PATCH] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

>Is this "hotfix" the same thing as "having the latest firmware >installed" ? >If so, making that clear in the dev_warn messages would be more useful >to the person reading the log. Yes, I'll modify and re-send.

Re: [PATCH] regulator: tps65218: Add NULL test for devm_kzalloc call

On Fri, 2017-11-17 at 11:58 +0800, Axel Lin wrote: > 2017-11-16 19:23 GMT+08:00 Keerthy : > > > > > > On Monday 13 November 2017 06:22 PM, Axel Lin wrote: > > > Signed-off-by: Axel Lin > > > > One line commit message would be better than blank commit message. > > It's just too trivial and

Re: [PATCH] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

>Is this "hotfix" the same thing as "having the latest firmware >installed" ? >If so, making that clear in the dev_warn messages would be more useful >to the person reading the log. Yes, I'll modify and re-send.

Re: [PATCH 2/2] ASoC: fsl_asrc: constify some arrays

On Thu, Nov 16, 2017 at 08:25:47AM -0800, Joe Perches wrote: > Using const reduces data. > > $ size sound/soc/fsl/fsl_asrc.o* >text data bss dec hex filename > 21691 5872 192 277556c6b sound/soc/fsl/fsl_asrc.o.new > 21435 6128 192

Re: [PATCH 2/2] ASoC: fsl_asrc: constify some arrays

On Thu, Nov 16, 2017 at 08:25:47AM -0800, Joe Perches wrote: > Using const reduces data. > > $ size sound/soc/fsl/fsl_asrc.o* >text data bss dec hex filename > 21691 5872 192 277556c6b sound/soc/fsl/fsl_asrc.o.new > 21435 6128 192

[git pull] drm amdgpu-dc merge

Hi Linus, This is the pull request for the AMD DC (display code) layer which is a requirement to program the display engines on the new Vega and Raven based GPUs. It also contains support for all amdgpu supported GPUs (CIK, VI, Polaris), which you have to enable. It is also a kms atomic

[git pull] drm amdgpu-dc merge

Hi Linus, This is the pull request for the AMD DC (display code) layer which is a requirement to program the display engines on the new Vega and Raven based GPUs. It also contains support for all amdgpu supported GPUs (CIK, VI, Polaris), which you have to enable. It is also a kms atomic

Re: [PATCH] regulator: tps65218: Add NULL test for devm_kzalloc call

2017-11-16 19:23 GMT+08:00 Keerthy : > > > On Monday 13 November 2017 06:22 PM, Axel Lin wrote: >> Signed-off-by: Axel Lin > > One line commit message would be better than blank commit message. It's just too trivial and checkpatch does not complain.

Re: [PATCH] regulator: tps65218: Add NULL test for devm_kzalloc call

2017-11-16 19:23 GMT+08:00 Keerthy : > > > On Monday 13 November 2017 06:22 PM, Axel Lin wrote: >> Signed-off-by: Axel Lin > > One line commit message would be better than blank commit message. It's just too trivial and checkpatch does not complain.

Re: [PATCH v7 02/13] dt-bindings: Add SLIMbus bindings

On Thu, Nov 16, 2017 at 01:40:13PM +, Srinivas Kandagatla wrote: > Thanks for the review comments. > > On 16/11/17 13:09, Vinod Koul wrote: > >On Wed, Nov 15, 2017 at 02:10:32PM +, srinivas.kandaga...@linaro.org > >wrote: > >>From: Sagar Dharia > > > >>+ >

Re: linux-next: build warning after merge of the akpm-current tree

Hi all, On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell wrote: > > On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann wrote: > > > > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko wrote: > > > On Mon 13-11-17 16:42:06, Stephen

Re: [PATCH v7 02/13] dt-bindings: Add SLIMbus bindings

On Thu, Nov 16, 2017 at 01:40:13PM +, Srinivas Kandagatla wrote: > Thanks for the review comments. > > On 16/11/17 13:09, Vinod Koul wrote: > >On Wed, Nov 15, 2017 at 02:10:32PM +, srinivas.kandaga...@linaro.org > >wrote: > >>From: Sagar Dharia > > > >>+ > >>+Child nodes: > >>+Every

Re: linux-next: build warning after merge of the akpm-current tree

Hi all, On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell wrote: > > On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann wrote: > > > > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko wrote: > > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote: > > >> > > >> After merging the

Re: [PATCH v2 02/14] soundwire: Add SoundWire bus type

On Thu, Nov 16, 2017 at 05:24:37PM +, Mark Brown wrote: > On Thu, Nov 16, 2017 at 10:32:21PM +0530, Vinod Koul wrote: > > On Thu, Nov 16, 2017 at 04:05:17PM +, Srinivas Kandagatla wrote: > > > > >+static const struct sdw_device_id * > > > >+sdw_get_device_id(struct sdw_slave *slave,

Re: [PATCH v2 02/14] soundwire: Add SoundWire bus type

On Thu, Nov 16, 2017 at 05:24:37PM +, Mark Brown wrote: > On Thu, Nov 16, 2017 at 10:32:21PM +0530, Vinod Koul wrote: > > On Thu, Nov 16, 2017 at 04:05:17PM +, Srinivas Kandagatla wrote: > > > > >+static const struct sdw_device_id * > > > >+sdw_get_device_id(struct sdw_slave *slave,

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On Fri, Sep 8, 2017 at 1:43 PM, Dan Williams wrote: > On Thu, Sep 7, 2017 at 6:59 PM, Bob Liu wrote: >> On 2017/9/8 1:27, Jerome Glisse wrote: > [..] >>> No this are 2 orthogonal thing, they do not conflict with each others quite >>> the contrary.

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On Fri, Sep 8, 2017 at 1:43 PM, Dan Williams wrote: > On Thu, Sep 7, 2017 at 6:59 PM, Bob Liu wrote: >> On 2017/9/8 1:27, Jerome Glisse wrote: > [..] >>> No this are 2 orthogonal thing, they do not conflict with each others quite >>> the contrary. HMM (the CDM part is no different) is a set of

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

How about add file_write_and_wait_range in __write_node_page as following: if (atomic && !test_opt(sbi, NOBARRIER)) { file_write_and_wait_range(file, 0, LLONG_MAX); fio.op_flags |= REQ_PREFLUSH | REQ_FUA; } The all the GCed data will be flushed to non-volatile before last node write

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

How about add file_write_and_wait_range in __write_node_page as following: if (atomic && !test_opt(sbi, NOBARRIER)) { file_write_and_wait_range(file, 0, LLONG_MAX); fio.op_flags |= REQ_PREFLUSH | REQ_FUA; } The all the GCed data will be flushed to non-volatile before last node write

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 11:04, Yunlong Song wrote: > The atomic commit will trigger: > -f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true) > -file_write_and_wait_range(file, 0, LLONG_MAX) > -fsync_node_pages > -__write_node_page > -REQ_PREFLUSH | REQ_FUA > >

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 11:04, Yunlong Song wrote: > The atomic commit will trigger: > -f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true) > -file_write_and_wait_range(file, 0, LLONG_MAX) > -fsync_node_pages > -__write_node_page > -REQ_PREFLUSH | REQ_FUA > >

[PATCH] mm/shmem: set default tmpfs size according to memcg limit

Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs without "-o size=XXX". When we mount tmpfs in a container(i.e. docker), it is also totalram_pages / 2 regardless of the memory limit on this container. That may easily cause OOM if tmpfs occupied too much memory when swap is

[PATCH] mm/shmem: set default tmpfs size according to memcg limit

Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs without "-o size=XXX". When we mount tmpfs in a container(i.e. docker), it is also totalram_pages / 2 regardless of the memory limit on this container. That may easily cause OOM if tmpfs occupied too much memory when swap is

[git pull] vfs.git cramfs series

Nicolas Pitre cramfs work. The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.cramfs for you to fetch

[git pull] vfs.git cramfs series

Nicolas Pitre cramfs work. The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.cramfs for you to fetch

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

The atomic commit will trigger: -f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true) -file_write_and_wait_range(file, 0, LLONG_MAX) -fsync_node_pages -__write_node_page -REQ_PREFLUSH | REQ_FUA So data is flushed to non-volatile before last node write

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

The atomic commit will trigger: -f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true) -file_write_and_wait_range(file, 0, LLONG_MAX) -fsync_node_pages -__write_node_page -REQ_PREFLUSH | REQ_FUA So data is flushed to non-volatile before last node write

[git pull] vfs.git work.misc

Assorted stuff, really no common topic here. The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you

[git pull] vfs.git work.misc

Assorted stuff, really no common topic here. The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you

[git pull] vfs.git get_user_pages_fast() conversion

A bunch of places switched to get_user_pages_fast(). The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git

[git pull] vfs.git get_user_pages_fast() conversion

A bunch of places switched to get_user_pages_fast(). The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

On 2017年11月17日 10:46, Joel Stanley wrote: Looks like this was mistakenly added to the tree as part of commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). Signed-off-by: Joel Stanley --- drivers/net/virtio_net. | 0 1 file changed, 0 insertions(+), 0 deletions(-)

Re: [PATCH] virto_net: remove empty file 'virtio_net.'

On 2017年11月17日 10:46, Joel Stanley wrote: Looks like this was mistakenly added to the tree as part of commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). Signed-off-by: Joel Stanley --- drivers/net/virtio_net. | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On 2017-11-17 01:50, Paolo Bonzini wrote: On 16/11/2017 15:28, Quan Xu wrote: vcpu->srcu_idx = srcu_read_lock(>srcu); + kvm_load_guest_fpu(vcpu); + for (;;) { if (kvm_vcpu_running(vcpu)) { r = vcpu_enter_guest(vcpu); <<   as Rik

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On 2017-11-17 01:50, Paolo Bonzini wrote: On 16/11/2017 15:28, Quan Xu wrote: vcpu->srcu_idx = srcu_read_lock(>srcu); + kvm_load_guest_fpu(vcpu); + for (;;) { if (kvm_vcpu_running(vcpu)) { r = vcpu_enter_guest(vcpu); <<   as Rik

Re: [PATCH v7 2/3] arm: dts: add Nuvoton NPCM750 device tree

Sorry for the delay. I thought all of the comments were straightforward, but there are a couple which need some further discussion. On Fri, Oct 20, 2017 at 12:45 PM, Rob Herring wrote: > On Thu, Oct 19, 2017 at 5:50 PM, Brendan Higgins > wrote: >>

Re: [PATCH v7 2/3] arm: dts: add Nuvoton NPCM750 device tree

Sorry for the delay. I thought all of the comments were straightforward, but there are a couple which need some further discussion. On Fri, Oct 20, 2017 at 12:45 PM, Rob Herring wrote: > On Thu, Oct 19, 2017 at 5:50 PM, Brendan Higgins > wrote: >> Add a common device tree for all Nuvoton

[git pull] vfs.git iov_iter

* bio_{map,copy}_user_iov() series; those are cleanups - fixes from the same pile went into mainline (and stable) in late September. * fs/iomap.c iov_iter-related fixes * new primitive - iov_iter_for_each_range(); apply a function to kernel-mapped segments of an iov_iter.

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 8:58, Yunlong Song wrote: > Is there any problem if just deleting the judgement condition in this patch? IIRC, dirty node comes from data segment GC can be writebacked & flushed during atomic commit, but related data will still be in inner bio cache, after later SPOR, data would be

[git pull] vfs.git iov_iter

* bio_{map,copy}_user_iov() series; those are cleanups - fixes from the same pile went into mainline (and stable) in late September. * fs/iomap.c iov_iter-related fixes * new primitive - iov_iter_for_each_range(); apply a function to kernel-mapped segments of an iov_iter.

Re: [PATCH] f2fs: let f2fs also gc atomic file to avoid loop gc

On 2017/11/17 8:58, Yunlong Song wrote: > Is there any problem if just deleting the judgement condition in this patch? IIRC, dirty node comes from data segment GC can be writebacked & flushed during atomic commit, but related data will still be in inner bio cache, after later SPOR, data would be

[PATCH] virto_net: remove empty file 'virtio_net.'

Looks like this was mistakenly added to the tree as part of commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). Signed-off-by: Joel Stanley --- drivers/net/virtio_net. | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 drivers/net/virtio_net. diff

[PATCH] virto_net: remove empty file 'virtio_net.'

Looks like this was mistakenly added to the tree as part of commit 186b3c998c50 ("virtio-net: support XDP_REDIRECT"). Signed-off-by: Joel Stanley --- drivers/net/virtio_net. | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 drivers/net/virtio_net. diff --git

Re: [PATCH v4] dma-debug: fix incorrect pfn calculation

On Fri, 17 Nov 2017 09:23:18 +0800 Miles Chen wrote: > On Thu, 2017-11-16 at 16:13 -0800, Andrew Morton wrote: > > On Fri, 17 Nov 2017 06:56:12 +0800 wrote: > > > > > From: Miles Chen > > > > > > dma-debug reports the

Re: [PATCH v4] dma-debug: fix incorrect pfn calculation

On Fri, 17 Nov 2017 09:23:18 +0800 Miles Chen wrote: > On Thu, 2017-11-16 at 16:13 -0800, Andrew Morton wrote: > > On Fri, 17 Nov 2017 06:56:12 +0800 wrote: > > > > > From: Miles Chen > > > > > > dma-debug reports the following warning: > > > > > > [name:panic&]WARNING: CPU: 3 PID: 298 at

Re: [PATCH] of: Document exactly what of_find_node_by_name() puts

On 11/10, Randy Dunlap wrote: > On 11/10/2017 05:45 PM, Stephen Boyd wrote: > > It isn't clear if this function of_node_put()s the 'from' > > argument, or the node it finds in the search. Clearly indicate > > which variable is touched. > > > > Signed-off-by: Stephen Boyd >

Re: [PATCH] of: Document exactly what of_find_node_by_name() puts

On 11/10, Randy Dunlap wrote: > On 11/10/2017 05:45 PM, Stephen Boyd wrote: > > It isn't clear if this function of_node_put()s the 'from' > > argument, or the node it finds in the search. Clearly indicate > > which variable is touched. > > > > Signed-off-by: Stephen Boyd > > --- > >

Re: [PATCH] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On 11/14, Stephen Boyd wrote: > On 11/10, Catalin Marinas wrote: > > On Wed, Nov 08, 2017 at 11:00:29AM -0800, Stephen Boyd wrote: > > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > > we need to do the same workaround on Kryo CPUs. The MIDR is > > > slightly more complicated

Re: [PATCH] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On 11/14, Stephen Boyd wrote: > On 11/10, Catalin Marinas wrote: > > On Wed, Nov 08, 2017 at 11:00:29AM -0800, Stephen Boyd wrote: > > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > > we need to do the same workaround on Kryo CPUs. The MIDR is > > > slightly more complicated

[git pull] vfs.git compat and uaccess

{get,put}_compat_sigset() series + assorted compat ioctl stuff + more set_fs() elimination + a few more timespec64 conversions + several removals of pointless access_ok() in places where it was followed only by non-__ variants of primitives. One conflict (in

[git pull] vfs.git compat and uaccess

{get,put}_compat_sigset() series + assorted compat ioctl stuff + more set_fs() elimination + a few more timespec64 conversions + several removals of pointless access_ok() in places where it was followed only by non-__ variants of primitives. One conflict (in

Re: [PATCH] llist: Put parentheses around parameters of llist_for_each_entry_safe()

On Tue, Sep 26, 2017 at 03:54:51PM +0900, Byungchul Park wrote: > It would be somewhat safer to put parentheses around parameters of > a macro with parameters. Put it. Hello Ingo and Peter, Even though Huang said this change is unnecessary, I'm curious about what you think about this fix. As

Re: [PATCH] llist: Put parentheses around parameters of llist_for_each_entry_safe()

On Tue, Sep 26, 2017 at 03:54:51PM +0900, Byungchul Park wrote: > It would be somewhat safer to put parentheses around parameters of > a macro with parameters. Put it. Hello Ingo and Peter, Even though Huang said this change is unnecessary, I'm curious about what you think about this fix. As

[lkp-robot] [lib/rbtree] c21f87074d: WARNING:at_kernel/events/core.c:#perf_swevent_add

FYI, we noticed the following commit (built with gcc-6): commit: c21f87074dc24c9e5a13dc63918b2d30891d190f ("lib/rbtree-test: lower default params") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -smp 2

[lkp-robot] [lib/rbtree] c21f87074d: WARNING:at_kernel/events/core.c:#perf_swevent_add

FYI, we noticed the following commit (built with gcc-6): commit: c21f87074dc24c9e5a13dc63918b2d30891d190f ("lib/rbtree-test: lower default params") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -smp 2

Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Thursday, November 16, 2017 4:42 PM, Dan Murphy wrote: > > Jacek > > On 11/16/2017 02:14 PM, Jacek Anaszewski wrote: > > Hi Dan and Pavel, > > > > On 11/15/2017 11:23 PM, Pavel Machek wrote: > >> Hi! > >> > Shouldn't the driver be targeted for backlight subsystem then? > >

Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Thursday, November 16, 2017 4:42 PM, Dan Murphy wrote: > > Jacek > > On 11/16/2017 02:14 PM, Jacek Anaszewski wrote: > > Hi Dan and Pavel, > > > > On 11/15/2017 11:23 PM, Pavel Machek wrote: > >> Hi! > >> > Shouldn't the driver be targeted for backlight subsystem then? > >

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Any comments for this patch series? Thanks, Kan > > From: Kan Liang > > There are two free running counters for client IMC uncore. The custom > event_init() function hardcode their index to 'UNCORE_PMC_IDX_FIXED' and > 'UNCORE_PMC_IDX_FIXED + 1'. To support

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Any comments for this patch series? Thanks, Kan > > From: Kan Liang > > There are two free running counters for client IMC uncore. The custom > event_init() function hardcode their index to 'UNCORE_PMC_IDX_FIXED' and > 'UNCORE_PMC_IDX_FIXED + 1'. To support the

Re: [PATCH RESEND v10 00/10] Application Data Integrity feature introduced by SPARC M7

> On Nov 16, 2017, at 6:38 AM, Khalid Aziz wrote: > > Changelog v10: > > - Patch 1/10: Updated si_codes definitions for SEGV to match 4.14 > - Patch 2/10: No changes > - Patch 3/10: Updated copyright > - Patch 4/10: No changes > - Patch

Re: [PATCH RESEND v10 00/10] Application Data Integrity feature introduced by SPARC M7

> On Nov 16, 2017, at 6:38 AM, Khalid Aziz wrote: > > Changelog v10: > > - Patch 1/10: Updated si_codes definitions for SEGV to match 4.14 > - Patch 2/10: No changes > - Patch 3/10: Updated copyright > - Patch 4/10: No changes > - Patch 5/10: No changes > -

Re: [PATCH] drivers: base: cacheinfo: support DT overrides for cache type

On 2017/11/16 23:23, Sudeep Holla wrote: > > > On 16/11/17 12:58, Tan Xiaojun wrote: >> Since commit dfea747d2aba ("drivers: base: cacheinfo: support DT >> overrides for cache properties"), we can set the correct cacheinfo >> via DT. But the cache type can't be set in the same way. >> >> I found

Re: [PATCH] drivers: base: cacheinfo: support DT overrides for cache type

On 2017/11/16 23:23, Sudeep Holla wrote: > > > On 16/11/17 12:58, Tan Xiaojun wrote: >> Since commit dfea747d2aba ("drivers: base: cacheinfo: support DT >> overrides for cache properties"), we can set the correct cacheinfo >> via DT. But the cache type can't be set in the same way. >> >> I found

Re: [PATCH] quota: be aware of error from dquot_initialize

On 2017/11/14 17:24, Jan Kara wrote: > On Tue 14-11-17 11:43:49, Chao Yu wrote: >> On 2017/11/13 17:18, Jan Kara wrote: >>> On Mon 13-11-17 11:31:48, Chao Yu wrote: Commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()") missed to handle error from dquot_initialize in

Re: [PATCH] quota: be aware of error from dquot_initialize

On 2017/11/14 17:24, Jan Kara wrote: > On Tue 14-11-17 11:43:49, Chao Yu wrote: >> On 2017/11/13 17:18, Jan Kara wrote: >>> On Mon 13-11-17 11:31:48, Chao Yu wrote: Commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()") missed to handle error from dquot_initialize in

[PATCH 2/2 v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

From: Kuninori Morimoto SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The

[PATCH 1/2 v3] dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clearing

From: Kuninori Morimoto DMAC reads data from source device, and buffered it until transferable size for sink device. Because of this behavior, DMAC is including buffered data . Now, CHCR DE bit is controlling DMA transfer enable/disable. If DE bit was cleared

[PATCH 2/2 v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue

From: Kuninori Morimoto SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The relationship is like below.

[PATCH 1/2 v3] dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clearing

From: Kuninori Morimoto DMAC reads data from source device, and buffered it until transferable size for sink device. Because of this behavior, DMAC is including buffered data . Now, CHCR DE bit is controlling DMA transfer enable/disable. If DE bit was cleared during data transferring, or

[PATCH 0/2 v3] dmaengine: rcar-dmac: use TCRB instead of TCR

Hi Vinod Cc Geert, Laurent These are v3 of dmaengine fixup for Renesas SoC. Main diffs are fixup typo Kuninori Morimoto (2): dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clearing dmaengine: rcar-dmac: use TCRB instead of TCR for residue drivers/dma/sh/rcar-dmac.c | 44

[PATCH 0/2 v3] dmaengine: rcar-dmac: use TCRB instead of TCR

Hi Vinod Cc Geert, Laurent These are v3 of dmaengine fixup for Renesas SoC. Main diffs are fixup typo Kuninori Morimoto (2): dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clearing dmaengine: rcar-dmac: use TCRB instead of TCR for residue drivers/dma/sh/rcar-dmac.c | 44

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