[PATCH] Input: uinput - allow for max == min during input_absinfo validation

These values are inclusive, so a range of 1 requires min == max. Signed-off-by: Peter Hutterer --- drivers/input/misc/uinput.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 96a887f33698..eb14ddf69346 100644

[PATCH] Input: uinput - allow for max == min during input_absinfo validation

These values are inclusive, so a range of 1 requires min == max. Signed-off-by: Peter Hutterer --- drivers/input/misc/uinput.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 96a887f33698..eb14ddf69346 100644

[PATCH] ASoC: qcom: Fix a uninitialized warning.

Fix the following compile warning: drivers/soc/qcom/cmd-db.c:194:38: warning: ‘ent.addr’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ret < 0 ? 0 : le32_to_cpu(ent.addr); drivers/soc/qcom/cmd-db.c:247:38: warning: ‘ent.len’ may be used uninitialized in this

[PATCH] ASoC: qcom: Fix a uninitialized warning.

Fix the following compile warning: drivers/soc/qcom/cmd-db.c:194:38: warning: ‘ent.addr’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ret < 0 ? 0 : le32_to_cpu(ent.addr); drivers/soc/qcom/cmd-db.c:247:38: warning: ‘ent.len’ may be used uninitialized in this

[PATCH] x86/speculation: Use AMD specific retpoline for inline asm on AMD

Lfence is preferred than general retpoline on AMD, add this option in C / inline asm just as the ASM code does. For x86_64, it still help to have minimal retpoline for kernel even if gcc doesn't support it, change the inline asm for x86 so that it could also be used by x86_64. Add

[PATCH] x86/speculation: Use AMD specific retpoline for inline asm on AMD

Lfence is preferred than general retpoline on AMD, add this option in C / inline asm just as the ASM code does. For x86_64, it still help to have minimal retpoline for kernel even if gcc doesn't support it, change the inline asm for x86 so that it could also be used by x86_64. Add

linux-next: Tree for Sep 18

Hi all, Changes since 20180913: New tree: csky Dropped trees: xarray, ida (temporarily) I still disabled building some samples in the vfs tree. The net-next tree gained conflicts against the net and jc_docs trees. The drm-misc tree gained a conflict against the drm tree. The staging tree

linux-next: Tree for Sep 18

Hi all, Changes since 20180913: New tree: csky Dropped trees: xarray, ida (temporarily) I still disabled building some samples in the vfs tree. The net-next tree gained conflicts against the net and jc_docs trees. The drm-misc tree gained a conflict against the drm tree. The staging tree

Re: linux-next: build failure after merge of the tty tree

On Tue, Sep 11, 2018 at 11:43 AM Lee Jones wrote: > On Tue, 11 Sep 2018, Nicolas Ferre wrote: > > Actually it is due to the missing of as Stephen > > suggested. It is due to the patch ac3167257b9f ("headers: separate > > linux/mod_devicetable.h from linux/platform_device.h") merged in

Re: linux-next: build failure after merge of the tty tree

On Tue, Sep 11, 2018 at 11:43 AM Lee Jones wrote: > On Tue, 11 Sep 2018, Nicolas Ferre wrote: > > Actually it is due to the missing of as Stephen > > suggested. It is due to the patch ac3167257b9f ("headers: separate > > linux/mod_devicetable.h from linux/platform_device.h") merged in

Re: [RFC/PATCH 0/5] Support children for legacy device properties

On Mon, Sep 17, 2018 at 9:18 PM Dmitry Torokhov wrote: > > The generic device properties APIs are very helpful as they allow abstracting > away details of the platform (whether it is ACPI, device tree, or legacy board > file), so that individual driver does not need separate code paths to support

Re: [RFC/PATCH 0/5] Support children for legacy device properties

On Mon, Sep 17, 2018 at 9:18 PM Dmitry Torokhov wrote: > > The generic device properties APIs are very helpful as they allow abstracting > away details of the platform (whether it is ACPI, device tree, or legacy board > file), so that individual driver does not need separate code paths to support

Re: [PATCH 0/4] power: supply: MAX17040: Add IRQ for low level and alert SOC changes

Hi Krzysztof and Sebastian, please forgive me for the delay in working with this patch. I've been having some personal issues these months, but leaving the excuses I still intend to send a v2 for this. Thanks Krzysztof for review and tips I'll work on it. Best Regards, Matheus Castello On

Re: [PATCH 0/4] power: supply: MAX17040: Add IRQ for low level and alert SOC changes

Hi Krzysztof and Sebastian, please forgive me for the delay in working with this patch. I've been having some personal issues these months, but leaving the excuses I still intend to send a v2 for this. Thanks Krzysztof for review and tips I'll work on it. Best Regards, Matheus Castello On

Re: [PATCH 1/3] um: fix parallel building with O= option

Hi Kees, 2018-09-16 3:47 GMT+09:00 Kees Cook : > On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada > wrote: >> Randy Dunlap reports UML occasionally fails to build with -j and >> O= options. > > With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um > > $ make -j8 ARCH=um

Re: [PATCH 1/3] um: fix parallel building with O= option

Hi Kees, 2018-09-16 3:47 GMT+09:00 Kees Cook : > On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada > wrote: >> Randy Dunlap reports UML occasionally fails to build with -j and >> O= options. > > With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um > > $ make -j8 ARCH=um

[PATCH] samples: disable CONFIG_SAMPLES for UML

Some samples require headers installation, so commit 3fca1700c4c3 ("kbuild: make samples really depend on headers_install") added such dependency in the top Makefile. However, UML fails to build with CONFIG_SAMPLES=y because UML does not support headers_install. Fixes: 3fca1700c4c3 ("kbuild:

[PATCH] samples: disable CONFIG_SAMPLES for UML

Some samples require headers installation, so commit 3fca1700c4c3 ("kbuild: make samples really depend on headers_install") added such dependency in the top Makefile. However, UML fails to build with CONFIG_SAMPLES=y because UML does not support headers_install. Fixes: 3fca1700c4c3 ("kbuild:

Re: [PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

On 09/18/18 at 10:48am, Lianbo Jiang wrote: > e820 reserved ranges is useful in kdump kernel, we have added this in > kexec-tools code. > > One reason is PCI mmconf (extended mode) requires reserved region > otherwise it falls back to legacy mode. > > When AMD SME kdump support, it needs to map

Re: [PATCH 2/2] Compiler Attributes: naked can be shared

On 13.09.2018 16:59, Miguel Ojeda wrote: > The naked attribute is supported by at least gcc >= 4.6 (for ARM, > which is the only current user), gcc >= 8 (for x86), clang >= 3.1 > and icc >= 13. See https://godbolt.org/z/350Dyc > > Therefore, move it out of compiler-gcc.h so that the definition >

Re: [PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

On 09/18/18 at 10:48am, Lianbo Jiang wrote: > e820 reserved ranges is useful in kdump kernel, we have added this in > kexec-tools code. > > One reason is PCI mmconf (extended mode) requires reserved region > otherwise it falls back to legacy mode. > > When AMD SME kdump support, it needs to map

Re: [PATCH 2/2] Compiler Attributes: naked can be shared

On 13.09.2018 16:59, Miguel Ojeda wrote: > The naked attribute is supported by at least gcc >= 4.6 (for ARM, > which is the only current user), gcc >= 8 (for x86), clang >= 3.1 > and icc >= 13. See https://godbolt.org/z/350Dyc > > Therefore, move it out of compiler-gcc.h so that the definition >

[PATCH V2 7/13] KVM: Add flush_link and parent_pte in the struct kvm_mmu_page

PV EPT tlb flush function will accept a list of flush ranges and use struct kvm_mmu_page as the list entry. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index

[PATCH V2 9/13] KVM/MMU: Replace tlb flush function with range list flush function

This patch is to use range list flush function in the mmu_sync_children(), kvm_mmu_commit_zap_page() and FNAME(sync_page)(). Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 26 +++--- arch/x86/kvm/paging_tmpl.h | 5 - 2 files changed, 27 insertions(+), 4

[PATCH V2 9/13] KVM/MMU: Replace tlb flush function with range list flush function

This patch is to use range list flush function in the mmu_sync_children(), kvm_mmu_commit_zap_page() and FNAME(sync_page)(). Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 26 +++--- arch/x86/kvm/paging_tmpl.h | 5 - 2 files changed, 27 insertions(+), 4

[PATCH V2 7/13] KVM: Add flush_link and parent_pte in the struct kvm_mmu_page

PV EPT tlb flush function will accept a list of flush ranges and use struct kvm_mmu_page as the list entry. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index

[PATCH V2 12/13] KVM/VMX: Change hv flush logic when ept tables are mismatched.

If ept table pointers are mismatched, flushing tlb for each vcpus via hv flush interface still helps to reduce vmexits which are triggered by IPI and INEPT emulation. Signed-off-by: Lan Tianyu --- arch/x86/kvm/vmx.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff

[PATCH V2 8/13] KVM: Add spte's point in the struct kvm_mmu_page

It's necessary to check whether mmu page is last or large page when add mmu page into flush list. "spte" is needed for such check and so add spte point in the struct kvm_mmu_page. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/mmu.c | 5 +

[PATCH V2 13/13] KVM/VMX: Add hv tlb range flush support

This patch is to register tlb_remote_flush_with_range callback with hv tlb range flush interface. Signed-off-by: Lan Tianyu --- Change since v1: Pass flush range with new hyper-v tlb flush struct rather than KVM tlb flush struct. --- arch/x86/kvm/vmx.c | 58

[PATCH V2 12/13] KVM/VMX: Change hv flush logic when ept tables are mismatched.

If ept table pointers are mismatched, flushing tlb for each vcpus via hv flush interface still helps to reduce vmexits which are triggered by IPI and INEPT emulation. Signed-off-by: Lan Tianyu --- arch/x86/kvm/vmx.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff

[PATCH V2 8/13] KVM: Add spte's point in the struct kvm_mmu_page

It's necessary to check whether mmu page is last or large page when add mmu page into flush list. "spte" is needed for such check and so add spte point in the struct kvm_mmu_page. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/mmu.c | 5 +

[PATCH V2 13/13] KVM/VMX: Add hv tlb range flush support

This patch is to register tlb_remote_flush_with_range callback with hv tlb range flush interface. Signed-off-by: Lan Tianyu --- Change since v1: Pass flush range with new hyper-v tlb flush struct rather than KVM tlb flush struct. --- arch/x86/kvm/vmx.c | 58

[PATCH V2 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()

This patch is to trace log in the hyperv_nested_flush_ guest_mapping_range(). Signed-off-by: Lan Tianyu --- arch/x86/hyperv/nested.c| 1 + arch/x86/include/asm/trace/hyperv.h | 14 ++ 2 files changed, 15 insertions(+) diff --git a/arch/x86/hyperv/nested.c

[PATCH V2 11/13] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()

This patch is to trace log in the hyperv_nested_flush_ guest_mapping_range(). Signed-off-by: Lan Tianyu --- arch/x86/hyperv/nested.c| 1 + arch/x86/include/asm/trace/hyperv.h | 14 ++ 2 files changed, 15 insertions(+) diff --git a/arch/x86/hyperv/nested.c

[PATCH V2 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()

This patch is to flush tlb directly in the kvm_handle_hva_range() when range flush is available. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 822e170881a4..dfd2a0710417 100644 ---

Re: [PATCH v2 2/2] soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()

Quoting Jordan Crouse (2018-09-17 14:14:14) > On Mon, Sep 17, 2018 at 01:40:07PM -0700, Stephen Boyd wrote: > > + vals = cmd_db_read_aux_data(id, ); > > /* > >* The data comes back as an array of unsigned shorts so adjust the > >* count accordingly > >*/ > > -

[PATCH V2 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb with specified ranges. This patch is to add the hypercall support. Signed-off-by: Lan Tianyu --- Change since v1: Add hyperv tlb flush struct to avoid use kvm tlb flush struct in the hyperv file. ---

[PATCH V2 4/13] KVM/MMU: Flush tlb directly in the kvm_handle_hva_range()

This patch is to flush tlb directly in the kvm_handle_hva_range() when range flush is available. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 822e170881a4..dfd2a0710417 100644 ---

Re: [PATCH v2 2/2] soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()

Quoting Jordan Crouse (2018-09-17 14:14:14) > On Mon, Sep 17, 2018 at 01:40:07PM -0700, Stephen Boyd wrote: > > + vals = cmd_db_read_aux_data(id, ); > > /* > >* The data comes back as an array of unsigned shorts so adjust the > >* count accordingly > >*/ > > -

[PATCH V2 10/13] x86/hyper-v: Add HvFlushGuestAddressList hypercall support

Hyper-V provides HvFlushGuestAddressList() hypercall to flush EPT tlb with specified ranges. This patch is to add the hypercall support. Signed-off-by: Lan Tianyu --- Change since v1: Add hyperv tlb flush struct to avoid use kvm tlb flush struct in the hyperv file. ---

[PATCH V2 6/13] KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()

kvm_mmu_zap_collapsible_spte() returns flush request to the slot_handle_leaf() and the latter does flush on demand. When range flush is available, make kvm_mmu_zap_collapsible_spte() to flush tlb with range directly to avoid returning range back to slot_handle_leaf(). Signed-off-by: Lan Tianyu

[PATCH V2 6/13] KVM/MMU: Flush tlb directly in kvm_mmu_zap_collapsible_spte()

kvm_mmu_zap_collapsible_spte() returns flush request to the slot_handle_leaf() and the latter does flush on demand. When range flush is available, make kvm_mmu_zap_collapsible_spte() to flush tlb with range directly to avoid returning range back to slot_handle_leaf(). Signed-off-by: Lan Tianyu

[PATCH V2 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops

Add flush range call back in the kvm_x86_ops and platform can use it to register its associated function. The parameter "kvm_tlb_range" accepts a single range and flush list which contains a list of ranges. Signed-off-by: Lan Tianyu --- Change since v1: Change "end_gfn" to "pages" to

[PATCH V2 2/13] KVM/MMU: Add tlb flush with range helper function

This patch is to add wrapper functions for tlb_remote_flush_with_range callback. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 48 1 file changed, 48 insertions(+) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index

[PATCH V2 5/13] KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()

Originally, flush tlb is done by slot_handle_level_range(). This patch is to flush tlb directly in the kvm_zap_gfn_range() when range flush is available. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git

[PATCH V2 00/13] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM

For nested memory virtualization, Hyper-v doesn't set write-protect L1 hypervisor EPT page directory and page table node to track changes while it relies on guest to tell it changes via HvFlushGuestAddressLlist hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush EPT page table

[PATCH V2 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.

This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_ remote_tlbs_with_address() in some functions without logic change. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 33 ++--- arch/x86/kvm/paging_tmpl.h | 3 ++- 2 files changed, 24

[PATCH V2 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops

Add flush range call back in the kvm_x86_ops and platform can use it to register its associated function. The parameter "kvm_tlb_range" accepts a single range and flush list which contains a list of ranges. Signed-off-by: Lan Tianyu --- Change since v1: Change "end_gfn" to "pages" to

[PATCH V2 2/13] KVM/MMU: Add tlb flush with range helper function

This patch is to add wrapper functions for tlb_remote_flush_with_range callback. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 48 1 file changed, 48 insertions(+) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index

[PATCH V2 5/13] KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()

Originally, flush tlb is done by slot_handle_level_range(). This patch is to flush tlb directly in the kvm_zap_gfn_range() when range flush is available. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git

[PATCH V2 00/13] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM

For nested memory virtualization, Hyper-v doesn't set write-protect L1 hypervisor EPT page directory and page table node to track changes while it relies on guest to tell it changes via HvFlushGuestAddressLlist hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush EPT page table

[PATCH V2 3/13] KVM: Replace old tlb flush function with new one to flush a specified range.

This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_ remote_tlbs_with_address() in some functions without logic change. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 33 ++--- arch/x86/kvm/paging_tmpl.h | 3 ++- 2 files changed, 24

Re: [PATCH 1/2] Compiler Attributes: naked was fixed in gcc 4.6

On 13.09.2018 16:59, Miguel Ojeda wrote: > Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone > and noinline on __naked functions") added noinline and noclone > as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0. > > Since now the minimum gcc supported version is 4.6, > we

Re: [PATCH 1/2] Compiler Attributes: naked was fixed in gcc 4.6

On 13.09.2018 16:59, Miguel Ojeda wrote: > Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone > and noinline on __naked functions") added noinline and noclone > as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0. > > Since now the minimum gcc supported version is 4.6, > we

linux-next: manual merge of the staging tree with the at91 tree

Hi all, Today's linux-next merge of the staging tree got a conflict in: MAINTAINERS between commit: 5ae2f1f30197 ("MAINTAINERS: move former ATMEL entries to proper MICROCHIP locatioat91n") from the at91 tree and commit: 010de20412fc ("MAINTAINERS: Add entry for mcp3911 ADC driver")

linux-next: manual merge of the staging tree with the at91 tree

Hi all, Today's linux-next merge of the staging tree got a conflict in: MAINTAINERS between commit: 5ae2f1f30197 ("MAINTAINERS: move former ATMEL entries to proper MICROCHIP locatioat91n") from the at91 tree and commit: 010de20412fc ("MAINTAINERS: Add entry for mcp3911 ADC driver")

Re: [PATCH] kbuild: allow to use GCC toolchain not in Clang search path

On 17.09.2018 20:06, Masahiro Yamada wrote: > Hi Stefan, > > 2018-09-18 11:31 GMT+09:00 Stefan Agner : >> When using a GCC cross toolchain which is not in a compiled in >> Clang search path, Clang reverts to the system assembler and >> linker. This leads to assembler or linker errors, depending

Re: [PATCH] kbuild: allow to use GCC toolchain not in Clang search path

On 17.09.2018 20:06, Masahiro Yamada wrote: > Hi Stefan, > > 2018-09-18 11:31 GMT+09:00 Stefan Agner : >> When using a GCC cross toolchain which is not in a compiled in >> Clang search path, Clang reverts to the system assembler and >> linker. This leads to assembler or linker errors, depending

Re: [PATCH] kbuild: allow to use GCC toolchain not in Clang search path

Hi Stefan, 2018-09-18 11:31 GMT+09:00 Stefan Agner : > When using a GCC cross toolchain which is not in a compiled in > Clang search path, Clang reverts to the system assembler and > linker. This leads to assembler or linker errors, depending on > which tool is first used for a given

Re: [PATCH] kbuild: allow to use GCC toolchain not in Clang search path

Hi Stefan, 2018-09-18 11:31 GMT+09:00 Stefan Agner : > When using a GCC cross toolchain which is not in a compiled in > Clang search path, Clang reverts to the system assembler and > linker. This leads to assembler or linker errors, depending on > which tool is first used for a given

RE: [PATCH v2] fanotify reports the thread id of the event trigger

On Mon, Sep 17, 2018 11:51 PM Amir Goldstein wrote: >On Mon, Sep 17, 2018 at 6:05 PM nixiaoming wrote: >> >> In order to identify which thread triggered the event in the >> multi-threaded program, add the FAN_EVENT_INFO_TID tag in fanotify_init > >According to code and man page this is a 'flag'

RE: [PATCH v2] fanotify reports the thread id of the event trigger

On Mon, Sep 17, 2018 11:51 PM Amir Goldstein wrote: >On Mon, Sep 17, 2018 at 6:05 PM nixiaoming wrote: >> >> In order to identify which thread triggered the event in the >> multi-threaded program, add the FAN_EVENT_INFO_TID tag in fanotify_init > >According to code and man page this is a 'flag'

Re: [PATCH v2 7/8] KVM: PMU: support to save/restore the guest lbr stack on vCPU switching

> > From: Like Xu > > > > This patch adds support to KVM to save/restore the lbr stack on vCPU > > context switching. > > > > When the guest sets the ACTIVE bit of MSR_KVM_PV_LBR_CTRL, a perf event > > is created on the host for the related vCPU. This perf event ensures the > > LBR stack to be

Re: [PATCH v2 7/8] KVM: PMU: support to save/restore the guest lbr stack on vCPU switching

> > From: Like Xu > > > > This patch adds support to KVM to save/restore the lbr stack on vCPU > > context switching. > > > > When the guest sets the ACTIVE bit of MSR_KVM_PV_LBR_CTRL, a perf event > > is created on the host for the related vCPU. This perf event ensures the > > LBR stack to be

Re: [PATCH] xfs: remove duplicated include from alloc.c

On Tue, Sep 18, 2018 at 10:07:34AM +0800, YueHaibing wrote: > Remove duplicated include xfs_alloc.h > > Signed-off-by: YueHaibing Looks ok, Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/scrub/alloc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/xfs/scrub/alloc.c

Re: [PATCH] xfs: remove duplicated include from alloc.c

On Tue, Sep 18, 2018 at 10:07:34AM +0800, YueHaibing wrote: > Remove duplicated include xfs_alloc.h > > Signed-off-by: YueHaibing Looks ok, Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/scrub/alloc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fs/xfs/scrub/alloc.c

[PATCH 0/2] x86/kexec_file: add reserved e820 ranges to the kdump kernel e820 table

E820 reserved ranges is useful in kdump kernel, we have added this in kexec-tools code. One reason is PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. Furthermore, when AMD SME kdump support, it needs to map dmi table area as unencrypted. For normal

[PATCH 1/2] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

kdump use walk_iomem_res_desc to iterate io resources then add matched desc to e820 table for 2nd kernel. But IORES_DESC_NONE resource type includes several different e820 types, we need add exact e820 type to 2nd kernel e820 table thus need an extra checking in memmap_entry_callback to match the

[PATCH 0/2] x86/kexec_file: add reserved e820 ranges to the kdump kernel e820 table

E820 reserved ranges is useful in kdump kernel, we have added this in kexec-tools code. One reason is PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. Furthermore, when AMD SME kdump support, it needs to map dmi table area as unencrypted. For normal

[PATCH 1/2] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

kdump use walk_iomem_res_desc to iterate io resources then add matched desc to e820 table for 2nd kernel. But IORES_DESC_NONE resource type includes several different e820 types, we need add exact e820 type to 2nd kernel e820 table thus need an extra checking in memmap_entry_callback to match the

[PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

e820 reserved ranges is useful in kdump kernel, we have added this in kexec-tools code. One reason is PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. When AMD SME kdump support, it needs to map dmi table area as unencrypted. For normal boot these

[PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

e820 reserved ranges is useful in kdump kernel, we have added this in kexec-tools code. One reason is PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. When AMD SME kdump support, it needs to map dmi table area as unencrypted. For normal boot these

[PATCH] kbuild: allow to use GCC toolchain not in Clang search path

When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching

[PATCH] kbuild: allow to use GCC toolchain not in Clang search path

When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching

Re: [RFC 1/3] dt-bindings: Correct RISC-V's timebase-frequency

On 9/17/18 7:20 AM, Christoph Hellwig wrote: On Fri, Sep 14, 2018 at 02:54:54PM -0700, Atish Patra wrote: From: Palmer Dabbelt Someone must have read the device tree specification incorrectly, because we were putting timebase-frequency in the wrong place. This corrects the issue, moving it

Re: [RFC 1/3] dt-bindings: Correct RISC-V's timebase-frequency

On 9/17/18 7:20 AM, Christoph Hellwig wrote: On Fri, Sep 14, 2018 at 02:54:54PM -0700, Atish Patra wrote: From: Palmer Dabbelt Someone must have read the device tree specification incorrectly, because we were putting timebase-frequency in the wrong place. This corrects the issue, moving it

Re: [RFC 2/3] RISC-V:Support per-hart timebase-frequency

On 9/17/18 7:23 AM, Christoph Hellwig wrote: On Fri, Sep 14, 2018 at 02:54:55PM -0700, Atish Patra wrote: Follow the updated DT specs and read the timebase-frequency from the boot cpu. Keep the old DT reading as well for backward compatibility. This patch is rework of old patch from Palmer.

Re: [RFC 2/3] RISC-V:Support per-hart timebase-frequency

On 9/17/18 7:23 AM, Christoph Hellwig wrote: On Fri, Sep 14, 2018 at 02:54:55PM -0700, Atish Patra wrote: Follow the updated DT specs and read the timebase-frequency from the boot cpu. Keep the old DT reading as well for backward compatibility. This patch is rework of old patch from Palmer.

[PATCH -next] fs/iomap.c: remove duplicated include

Remove duplicated include linux/swap.h Signed-off-by: YueHaibing --- fs/iomap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/iomap.c b/fs/iomap.c index 9fb78e5..a5613e5 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -30,7 +30,6 @@ #include #include #include -#include #include

[PATCH -next] fs/iomap.c: remove duplicated include

Remove duplicated include linux/swap.h Signed-off-by: YueHaibing --- fs/iomap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/iomap.c b/fs/iomap.c index 9fb78e5..a5613e5 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -30,7 +30,6 @@ #include #include #include -#include #include

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f ahh, guys? ah... i'm going to try *really* hard to follow the advice that's listed here ok? http://www.pndc.com/documents/_PDF%20Text-PNDC%20WORKS.pdf it's a little challenging

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f ahh, guys? ah... i'm going to try *really* hard to follow the advice that's listed here ok? http://www.pndc.com/documents/_PDF%20Text-PNDC%20WORKS.pdf it's a little challenging

[PATCH] xfs: remove duplicated include from alloc.c

Remove duplicated include xfs_alloc.h Signed-off-by: YueHaibing --- fs/xfs/scrub/alloc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/scrub/alloc.c b/fs/xfs/scrub/alloc.c index 036b5c7..376bcb5 100644 --- a/fs/xfs/scrub/alloc.c +++ b/fs/xfs/scrub/alloc.c @@ -17,7 +17,6 @@ #include

[PATCH] xfs: remove duplicated include from alloc.c

Remove duplicated include xfs_alloc.h Signed-off-by: YueHaibing --- fs/xfs/scrub/alloc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/xfs/scrub/alloc.c b/fs/xfs/scrub/alloc.c index 036b5c7..376bcb5 100644 --- a/fs/xfs/scrub/alloc.c +++ b/fs/xfs/scrub/alloc.c @@ -17,7 +17,6 @@ #include

Re: [PATCH 2/2] iio: light: bh1750: Add device tree support

On Sun, Sep 16, 2018 at 10:45:26AM +0100, Jonathan Cameron wrote: > On Sat, 15 Sep 2018 13:42:14 -0400 > ryang wrote: > > > Add device tree support for ROHM BH1750 series ambient light sensors. > > > > Signed-off-by: ryang > Just to check, how is it picking up on the enum value which is

Re: [PATCH v2] kcm: remove any offset before parsing messages

David Miller wrote on Mon, Sep 17, 2018: > From: Dominique Martinet > Date: Wed, 12 Sep 2018 07:36:42 +0200 > > > Dominique Martinet wrote on Tue, Sep 11, 2018: > >> Hmm, while trying to benchmark this, I sometimes got hangs in > >> kcm_wait_data() for the last packet somehow? > >> The sender

Re: [PATCH 2/2] iio: light: bh1750: Add device tree support

On Sun, Sep 16, 2018 at 10:45:26AM +0100, Jonathan Cameron wrote: > On Sat, 15 Sep 2018 13:42:14 -0400 > ryang wrote: > > > Add device tree support for ROHM BH1750 series ambient light sensors. > > > > Signed-off-by: ryang > Just to check, how is it picking up on the enum value which is

Re: [PATCH v2] kcm: remove any offset before parsing messages

David Miller wrote on Mon, Sep 17, 2018: > From: Dominique Martinet > Date: Wed, 12 Sep 2018 07:36:42 +0200 > > > Dominique Martinet wrote on Tue, Sep 11, 2018: > >> Hmm, while trying to benchmark this, I sometimes got hangs in > >> kcm_wait_data() for the last packet somehow? > >> The sender

linux-next: build warning after merge of the device-mapper tree

Hi all, After merging the device-mapper tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/md/dm-mpath.c: In function 'parse_path': drivers/md/dm-mpath.c:891:24: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]

linux-next: build warning after merge of the device-mapper tree

Hi all, After merging the device-mapper tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/md/dm-mpath.c: In function 'parse_path': drivers/md/dm-mpath.c:891:24: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

On 2018-09-17 23:09, Michael Woods wrote: The Code of Conflict was perfectly fine. Whomever convinced you to add the Code of Conduct was convincing you to give control over to a social justice initiative that has no interest in the kernel's core function or reason for existence. Hi Michael,

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

On 2018-09-17 23:09, Michael Woods wrote: The Code of Conflict was perfectly fine. Whomever convinced you to add the Code of Conduct was convincing you to give control over to a social justice initiative that has no interest in the kernel's core function or reason for existence. Hi Michael,

Re: [PATCH] i2c: aspeed: Acknowledge most interrupts early in interrupt handler

On Mon, Sep 17, 2018 at 6:11 PM Joel Stanley wrote: > > On Fri, 14 Sep 2018 at 13:00, Guenter Roeck wrote: > > > > Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events > > properly") moved interrupt acknowledgment to the end of the interrupt > > handler. In part this was

Re: [PATCH] i2c: aspeed: Acknowledge most interrupts early in interrupt handler

On Mon, Sep 17, 2018 at 6:11 PM Joel Stanley wrote: > > On Fri, 14 Sep 2018 at 13:00, Guenter Roeck wrote: > > > > Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events > > properly") moved interrupt acknowledgment to the end of the interrupt > > handler. In part this was

RE: [PATCH] ARM: dts: imx6ull: update vdd_soc voltage for 900MHz operating point

Hi, Stefan Anson Huang Best Regards! > -Original Message- > From: Anson Huang > Sent: Wednesday, September 12, 2018 4:30 PM > To: Stefan Wahren ; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam > ; robh...@kernel.org; mark.rutl...@arm.com; >

RE: [PATCH] ARM: dts: imx6ull: update vdd_soc voltage for 900MHz operating point

Hi, Stefan Anson Huang Best Regards! > -Original Message- > From: Anson Huang > Sent: Wednesday, September 12, 2018 4:30 PM > To: Stefan Wahren ; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam > ; robh...@kernel.org; mark.rutl...@arm.com; >

Re: [PATCH] i2c: aspeed: Acknowledge most interrupts early in interrupt handler

On Fri, 14 Sep 2018 at 13:00, Guenter Roeck wrote: > > Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events > properly") moved interrupt acknowledgment to the end of the interrupt > handler. In part this was done because the AST2500 datasheet says: > > I2CD10 Interrupt

Re: [PATCH] i2c: aspeed: Acknowledge most interrupts early in interrupt handler

On Fri, 14 Sep 2018 at 13:00, Guenter Roeck wrote: > > Commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events > properly") moved interrupt acknowledgment to the end of the interrupt > handler. In part this was done because the AST2500 datasheet says: > > I2CD10 Interrupt

Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering

On 09/17/2018 05:45 PM, Kees Cook wrote: > On Mon, Sep 17, 2018 at 5:24 PM, Casey Schaufler > wrote: >> On 9/17/2018 5:00 PM, Kees Cook wrote: >>> The legacy per-LSM >>> enable/disable ordering is the same, but ordering between >>> lsm.enable/disable and the per-LSM options is NOT ordered. i.e.

Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering

On 09/17/2018 05:45 PM, Kees Cook wrote: > On Mon, Sep 17, 2018 at 5:24 PM, Casey Schaufler > wrote: >> On 9/17/2018 5:00 PM, Kees Cook wrote: >>> The legacy per-LSM >>> enable/disable ordering is the same, but ordering between >>> lsm.enable/disable and the per-LSM options is NOT ordered. i.e.

  1   2   3   4   5   6   7   8   9   10   >