[PATCH v2 3/4] platform/x86: intel_telemetry: Improve S0ix logs

Suspend with shallow wakes is not a useful parameter since the phenomena does not exist on deployed devices and is only a parameter of use during device power-on phase. The field always reads zero. Additionally there are other easier methods to detect it, e.g., if the S0ix counter increments by

[PATCH v2 3/4] platform/x86: intel_telemetry: Improve S0ix logs

Suspend with shallow wakes is not a useful parameter since the phenomena does not exist on deployed devices and is only a parameter of use during device power-on phase. The field always reads zero. Additionally there are other easier methods to detect it, e.g., if the S0ix counter increments by

[PATCH v3 2/4] platform/x86: intel_telemetry: Fix suspend stats

Suspend stats are not reported consistently due to a limitation in the PMC firmware. This limitation causes a delay in updating the s0ix counters and residencies in the telemetry log upon s0ix exit. As a consequence, reading these counters from the suspend-exit notifier may result in zero read.

[PATCH v1 1/4] platform/x86: intel_pmc_ipc: Add read64 API

Add intel_pmc_gcr_read64() API for reading from 64-bit GCR registers. This API will be called from intel_telemetry. Update description of intel_pmc_gcr_read(). Signed-off-by: Souvik Kumar Chakravarty --- arch/x86/include/asm/intel_pmc_ipc.h | 6 ++

[PATCH v3 2/4] platform/x86: intel_telemetry: Fix suspend stats

Suspend stats are not reported consistently due to a limitation in the PMC firmware. This limitation causes a delay in updating the s0ix counters and residencies in the telemetry log upon s0ix exit. As a consequence, reading these counters from the suspend-exit notifier may result in zero read.

[PATCH v1 1/4] platform/x86: intel_pmc_ipc: Add read64 API

Add intel_pmc_gcr_read64() API for reading from 64-bit GCR registers. This API will be called from intel_telemetry. Update description of intel_pmc_gcr_read(). Signed-off-by: Souvik Kumar Chakravarty --- arch/x86/include/asm/intel_pmc_ipc.h | 6 ++ drivers/platform/x86/intel_pmc_ipc.c | 33

[PATCH v2 4/4] platform/x86: intel_telemetry: Remove redundancies

This patch removes unnecessary header files and newlines. It also fixes some alignment issues. Signed-off-by: Souvik Kumar Chakravarty --- drivers/platform/x86/intel_telemetry_debugfs.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) Changes

[PATCH v2 4/4] platform/x86: intel_telemetry: Remove redundancies

This patch removes unnecessary header files and newlines. It also fixes some alignment issues. Signed-off-by: Souvik Kumar Chakravarty --- drivers/platform/x86/intel_telemetry_debugfs.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) Changes since v1: * Consolidated

[PATCH v3 0/4] platform/x86: intel_telemetry: Fix logs and formatting

This patchset fixes https://bugzilla.kernel.org/show_bug.cgi?id=197833, and other issues related to telemetry counters. It also cleans up formatting and removes redundant code. It is rebased on top of the TESTING branch. Changes since v2: * Changes in GCR read API name and adding back static

[PATCH v3 0/4] platform/x86: intel_telemetry: Fix logs and formatting

This patchset fixes https://bugzilla.kernel.org/show_bug.cgi?id=197833, and other issues related to telemetry counters. It also cleans up formatting and removes redundant code. It is rebased on top of the TESTING branch. Changes since v2: * Changes in GCR read API name and adding back static

[PATCH v2 1/2] s390/virtio: remove the old KVM virtio headers

commit 7fb2b2d51 ("s390/virtio: remove the old KVM virtio transport") dropped the transport support. We don't need to keep the header around. Cc: Thomas Huth Cc: Cornelia Huck Cc: Halil Pasic Cc: Heiko Carstens

[PATCH v2 2/2] s390/virtio: add BSD license to virtio-ccw

The original intent of the virtio header relicensing from 2008 was to make sure anyone can implement compatible devices/drivers. The virtio-ccw was omitted by mistake. We have an ack from the only contributor as well as the maintainer from IBM, so it's not too late to fix that. Make it

[PATCH v2 1/2] s390/virtio: remove the old KVM virtio headers

commit 7fb2b2d51 ("s390/virtio: remove the old KVM virtio transport") dropped the transport support. We don't need to keep the header around. Cc: Thomas Huth Cc: Cornelia Huck Cc: Halil Pasic Cc: Heiko Carstens Cc: Martin Schwidefsky Signed-off-by: Michael S. Tsirkin ---

[PATCH v2 2/2] s390/virtio: add BSD license to virtio-ccw

The original intent of the virtio header relicensing from 2008 was to make sure anyone can implement compatible devices/drivers. The virtio-ccw was omitted by mistake. We have an ack from the only contributor as well as the maintainer from IBM, so it's not too late to fix that. Make it

Re: [PATCH] net-sysfs: export gso_max_size attribute

On Wed, 22 Nov 2017 16:30:41 -0800 Solio Sarabia wrote: > The netdevice gso_max_size is exposed to allow users fine-control on > systems with multiple NICs with different GSO buffer sizes, and where > the virtual devices like bridge and veth, need to be aware of the GSO

Re: [PATCH] net-sysfs: export gso_max_size attribute

On Wed, 22 Nov 2017 16:30:41 -0800 Solio Sarabia wrote: > The netdevice gso_max_size is exposed to allow users fine-control on > systems with multiple NICs with different GSO buffer sizes, and where > the virtual devices like bridge and veth, need to be aware of the GSO > size of the underlying

Re: [PATCH] frv: fix build failure

Hi Sudip, On Thu, 2017-11-23 at 23:01 +, Sudip Mukherjee wrote: > Hi Alexey, > > On Thu, Nov 23, 2017 at 05:17:19PM +, Alexey Brodkin wrote: > > > > Hi Sudip, > > > > On Tue, 2017-11-21 at 22:10 +, Sudip Mukherjee wrote: > > > > > > The frv defconfig build is failing with the

Re: [PATCH] frv: fix build failure

Hi Sudip, On Thu, 2017-11-23 at 23:01 +, Sudip Mukherjee wrote: > Hi Alexey, > > On Thu, Nov 23, 2017 at 05:17:19PM +, Alexey Brodkin wrote: > > > > Hi Sudip, > > > > On Tue, 2017-11-21 at 22:10 +, Sudip Mukherjee wrote: > > > > > > The frv defconfig build is failing with the

Re: [PATCH] crypto: arm64/aes - do not call crypto_unregister_skcipher twice on error

On Wed, Nov 22, 2017 at 08:55:14AM +, Ard Biesheuvel wrote: > > Would this also fix it? Looks good. Could you resubmit with a sign-off? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH] crypto: arm64/aes - do not call crypto_unregister_skcipher twice on error

On Wed, Nov 22, 2017 at 08:55:14AM +, Ard Biesheuvel wrote: > > Would this also fix it? Looks good. Could you resubmit with a sign-off? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/3] scsi: arcmsr: Add driver module parameter msi_enable

Hello Dan, On Thu, 2017-11-23 at 13:44 +0300, Dan Carpenter wrote: > On Thu, Nov 23, 2017 at 09:27:19AM +0800, Ching Huang wrote: > > From: Ching Huang > > > > Add module parameter msi_enable to has a chance to disable msi interrupt if > > it does not work properly. > >

Re: [PATCH 1/3] scsi: arcmsr: Add driver module parameter msi_enable

Hello Dan, On Thu, 2017-11-23 at 13:44 +0300, Dan Carpenter wrote: > On Thu, Nov 23, 2017 at 09:27:19AM +0800, Ching Huang wrote: > > From: Ching Huang > > > > Add module parameter msi_enable to has a chance to disable msi interrupt if > > it does not work properly. > > > > Signed-off-by:

[PATCH v3 01/19] x86/asm/64: Allocate and enable the SYSENTER stack

This will simplify future changes that want scratch variables early in the SYSENTER handler -- they'll be able to spill registers to the stack. It also lets us get rid of a SWAPGS_UNSAFE_STACK user. This does not depend on CONFIG_IA32_EMULATION because we'll want the stack space even without

[PATCH v3 01/19] x86/asm/64: Allocate and enable the SYSENTER stack

This will simplify future changes that want scratch variables early in the SYSENTER handler -- they'll be able to spill registers to the stack. It also lets us get rid of a SWAPGS_UNSAFE_STACK user. This does not depend on CONFIG_IA32_EMULATION because we'll want the stack space even without

[PATCH v3 03/19] x86/gdt: Put per-cpu GDT remaps in ascending order

We currently have CPU 0's GDT at the top of the GDT range and higher-numbered CPUs at lower addresses. This happens because the fixmap is upside down (index 0 is the top of the fixmap). Flip it so that GDTs are in ascending order by virtual address. This will simplify a future patch that will

[PATCH v3 03/19] x86/gdt: Put per-cpu GDT remaps in ascending order

We currently have CPU 0's GDT at the top of the GDT range and higher-numbered CPUs at lower addresses. This happens because the fixmap is upside down (index 0 is the top of the fixmap). Flip it so that GDTs are in ascending order by virtual address. This will simplify a future patch that will

[PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

The cpu_entry_area will contain stacks. Make sure that KASAN has appropriate shadow mappings for them. Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-...@googlegroups.com Signed-off-by: Andy Lutomirski

[PATCH v3 02/19] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

get_stack_info() doesn't currently know about the SYSENTER stack, so unwinding will fail if we entered the kernel on the SYSENTER stack and haven't fully switched off. Teach get_stack_info() about the SYSENTER stack. With future patches applied that run part of the entry code on the SYSENTER

[PATCH v3 05/19] x86/kasan/64: Teach KASAN about the cpu_entry_area

The cpu_entry_area will contain stacks. Make sure that KASAN has appropriate shadow mappings for them. Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-...@googlegroups.com Signed-off-by: Andy Lutomirski --- arch/x86/mm/kasan_init_64.c | 13 - 1 file

[PATCH v3 02/19] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

get_stack_info() doesn't currently know about the SYSENTER stack, so unwinding will fail if we entered the kernel on the SYSENTER stack and haven't fully switched off. Teach get_stack_info() about the SYSENTER stack. With future patches applied that run part of the entry code on the SYSENTER

[PATCH v3 07/19] x86/dumpstack: Handle stack overflow on all stacks

We currently special-case stack overflow on the task stack. We're going to start putting special stacks in the fixmap with a custom layout, so they'll have guard pages, too. Teach the unwinder to be able to unwind an overflow of any of the stacks. Reviewed-by: Borislav Petkov

[PATCH v3 07/19] x86/dumpstack: Handle stack overflow on all stacks

We currently special-case stack overflow on the task stack. We're going to start putting special stacks in the fixmap with a custom layout, so they'll have guard pages, too. Teach the unwinder to be able to unwind an overflow of any of the stacks. Reviewed-by: Borislav Petkov Signed-off-by:

[PATCH v3 10/19] x86/asm/64: Separate cpu_current_top_of_stack from TSS.sp0

On 64-bit kernels, we used to assume that TSS.sp0 was the current top of stack. With the addition of an entry trampoline, this will no longer be the case. Store the current top of stack in TSS.sp1, which is otherwise unused but shares the same cacheline. Reviewed-by: Thomas Gleixner

[PATCH v3 10/19] x86/asm/64: Separate cpu_current_top_of_stack from TSS.sp0

On 64-bit kernels, we used to assume that TSS.sp0 was the current top of stack. With the addition of an entry trampoline, this will no longer be the case. Store the current top of stack in TSS.sp1, which is otherwise unused but shares the same cacheline. Reviewed-by: Thomas Gleixner

[PATCH v3 09/19] x86/asm: Remap the TSS into the cpu entry area

This has a secondary purpose: it puts the entry stack into a region with a well-controlled layout. A subsequent patch will take advantage of this to streamline the SYSCALL entry code to be able to find it more easily. Reviewed-by: Thomas Gleixner Signed-off-by: Andy

[PATCH v3 09/19] x86/asm: Remap the TSS into the cpu entry area

This has a secondary purpose: it puts the entry stack into a region with a well-controlled layout. A subsequent patch will take advantage of this to streamline the SYSCALL entry code to be able to find it more easily. Reviewed-by: Thomas Gleixner Signed-off-by: Andy Lutomirski ---

[PATCH v3 08/19] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

SYSENTER_stack should have reliable overflow detection, which means that it needs to be at the bottom of a page, not the top. Move it to the beginning of struct tss_struct and page-align it. Also add an assertion to make sure that the fixed hardware TSS doesn't cross a page boundary.

[PATCH v3 08/19] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

SYSENTER_stack should have reliable overflow detection, which means that it needs to be at the bottom of a page, not the top. Move it to the beginning of struct tss_struct and page-align it. Also add an assertion to make sure that the fixed hardware TSS doesn't cross a page boundary.

[PATCH v3 14/19] x86/entry/64: Create a percpu SYSCALL entry trampoline

Handling SYSCALL is tricky: the SYSCALL handler is entered with every single register (except FLAGS), including RSP, live. It somehow needs to set RSP to point to a valid stack, which means it needs to save the user RSP somewhere and find its own stack pointer. The canonical way to do this is

[PATCH v3 14/19] x86/entry/64: Create a percpu SYSCALL entry trampoline

Handling SYSCALL is tricky: the SYSCALL handler is entered with every single register (except FLAGS), including RSP, live. It somehow needs to set RSP to point to a valid stack, which means it needs to save the user RSP somewhere and find its own stack pointer. The canonical way to do this is

[PATCH v3 16/19] x86/irq/64: In the stack overflow warning, print the offending IP

In case something goes wrong with unwind (not unlikely in case of overflow), print the offending IP where we detected the overflow. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/irq_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v3 16/19] x86/irq/64: In the stack overflow warning, print the offending IP

In case something goes wrong with unwind (not unlikely in case of overflow), print the offending IP where we detected the overflow. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/irq_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/irq_64.c

[PATCH v3 13/19] x86/asm/64: Return to userspace from the trampoline stack

By itself, this is useless. It gives us the ability to run some final code before exit that cannnot run on the kernel stack. This could include a CR3 switch a la KAISER or some kernel stack erasing, for example. (Or even weird things like *changing* which kernel stack gets used as an

[PATCH v3 13/19] x86/asm/64: Return to userspace from the trampoline stack

By itself, this is useless. It gives us the ability to run some final code before exit that cannnot run on the kernel stack. This could include a CR3 switch a la KAISER or some kernel stack erasing, for example. (Or even weird things like *changing* which kernel stack gets used as an

[PATCH v3 18/19] x86/entry/64: Remove the SYSENTER stack canary

Now that the SYSENTER stack has a guard page, there's no need for a canary to detect overflow after the fact. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 1 - arch/x86/kernel/dumpstack.c | 3 +-- arch/x86/kernel/process.c| 1 -

[PATCH v3 18/19] x86/entry/64: Remove the SYSENTER stack canary

Now that the SYSENTER stack has a guard page, there's no need for a canary to detect overflow after the fact. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 1 - arch/x86/kernel/dumpstack.c | 3 +-- arch/x86/kernel/process.c| 1 - arch/x86/kernel/traps.c

[PATCH v3 15/19] x86/irq: Remove an old outdated comment about context tracking races

That race has been fixed and code cleaned up for a while now. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/irq.c | 12 1 file changed, 12 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 49cfd9fe7589..68e1867cca80 100644 ---

[PATCH v3 12/19] x86/asm/64: Use a percpu trampoline stack for IDT entries

Historically, IDT entries from usermode have always gone directly to the running task's kernel stack. Rearrange it so that we enter on a percpu trampoline stack and then manually switch to the task's stack. This touches a couple of extra cachelines, but it gives us a chance to run some code

[PATCH v3 12/19] x86/asm/64: Use a percpu trampoline stack for IDT entries

Historically, IDT entries from usermode have always gone directly to the running task's kernel stack. Rearrange it so that we enter on a percpu trampoline stack and then manually switch to the task's stack. This touches a couple of extra cachelines, but it gives us a chance to run some code

[PATCH v3 15/19] x86/irq: Remove an old outdated comment about context tracking races

That race has been fixed and code cleaned up for a while now. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/irq.c | 12 1 file changed, 12 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 49cfd9fe7589..68e1867cca80 100644 ---

[PATCH v3 17/19] x86/entry/64: Move the IST stacks into cpu_entry_area

The IST stacks are needed when an IST exception occurs and are accessed before any kernel code at all runs. Move them into cpu_entry_area. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/fixmap.h | 10 ++ arch/x86/kernel/cpu/common.c | 40

[PATCH v3 11/19] x86/espfix/64: Stop assuming that pt_regs is on the entry stack

When we start using an entry trampoline, a #GP from userspace will be delivered on the entry stack, not on the task stack. Fix the espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than assuming that pt_regs + 1 == SP0. This won't change anything without an entry stack, but it will

[PATCH v3 17/19] x86/entry/64: Move the IST stacks into cpu_entry_area

The IST stacks are needed when an IST exception occurs and are accessed before any kernel code at all runs. Move them into cpu_entry_area. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/fixmap.h | 10 ++ arch/x86/kernel/cpu/common.c | 40

[PATCH v3 11/19] x86/espfix/64: Stop assuming that pt_regs is on the entry stack

When we start using an entry trampoline, a #GP from userspace will be delivered on the entry stack, not on the task stack. Fix the espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than assuming that pt_regs + 1 == SP0. This won't change anything without an entry stack, but it will

[PATCH v3 04/19] x86/fixmap: Generalize the GDT fixmap mechanism

Currently, the GDT is an ad-hoc array of pages, one per CPU, in the fixmap. Generalize it to be an array of a new struct cpu_entry_area so that we can cleanly add new things to it. Reviewed-by: Thomas Gleixner Signed-off-by: Andy Lutomirski ---

[PATCH v3 00/19] Entry stack switching

This sets up stack switching, including for SYSCALL. I think it's in decent shape. I'm fiddling with a patch to make the TSS remap read-only on 64-bit. Known issues: - I think we're going to want a way to turn the stack switching on and off either at boot time or at runtime. It should be

[PATCH v3 19/19] x86/entry: Clean up SYSENTER_stack code

The existing code was a mess, mainly because C arrays are nasty. Turn SYSENTER_stack into a struct, add a helper to find it, and do all the obvious cleanups this enables. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S| 4 ++-- arch/x86/entry/entry_64.S

[PATCH v3 00/19] Entry stack switching

This sets up stack switching, including for SYSCALL. I think it's in decent shape. I'm fiddling with a patch to make the TSS remap read-only on 64-bit. Known issues: - I think we're going to want a way to turn the stack switching on and off either at boot time or at runtime. It should be

[PATCH v3 19/19] x86/entry: Clean up SYSENTER_stack code

The existing code was a mess, mainly because C arrays are nasty. Turn SYSENTER_stack into a struct, add a helper to find it, and do all the obvious cleanups this enables. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S| 4 ++-- arch/x86/entry/entry_64.S| 2 +-

[PATCH v3 04/19] x86/fixmap: Generalize the GDT fixmap mechanism

Currently, the GDT is an ad-hoc array of pages, one per CPU, in the fixmap. Generalize it to be an array of a new struct cpu_entry_area so that we can cleanly add new things to it. Reviewed-by: Thomas Gleixner Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 9 +

[PATCH v3 06/19] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

A future patch will move SYSENTER_stack to the beginning of cpu_tss to help detect overflow. Before this can happen, fix several code paths that hardcode assumptions about the old layout Reviewed-by: Borislav Petkov Reviewed-by: Thomas Gleixner Signed-off-by:

[PATCH v3 06/19] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

A future patch will move SYSENTER_stack to the beginning of cpu_tss to help detect overflow. Before this can happen, fix several code paths that hardcode assumptions about the old layout Reviewed-by: Borislav Petkov Reviewed-by: Thomas Gleixner Signed-off-by: Andy Lutomirski ---

Re: XArray documentation

On Nov 23, 2017, at 6:16 PM, Matthew Wilcox wrote: > > Here's the current state of the documentation for the XArray. Suggestions > for improvement gratefully received. > > == > XArray > == > > Overview > > > The XArray is an array of ULONG_MAX entries.

Re: XArray documentation

On Nov 23, 2017, at 6:16 PM, Matthew Wilcox wrote: > > Here's the current state of the documentation for the XArray. Suggestions > for improvement gratefully received. > > == > XArray > == > > Overview > > > The XArray is an array of ULONG_MAX entries. Each entry can be

Re: [PATCH v8 4/5] crash: export paddr_vmcoreinfo_note()

On Thu, Nov 23, 2017 at 06:36:57AM -0800, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 03:02:05PM +0100, Marc-André Lureau wrote: > > The following patch is going to use the symbol from the fw_cfg module, > > to call the function and write the note location details in the > > vmcoreinfo

Re: [PATCH v8 4/5] crash: export paddr_vmcoreinfo_note()

On Thu, Nov 23, 2017 at 06:36:57AM -0800, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 03:02:05PM +0100, Marc-André Lureau wrote: > > The following patch is going to use the symbol from the fw_cfg module, > > to call the function and write the note location details in the > > vmcoreinfo

Re: [PATCH v2 10/18] x86/asm: Remap the TSS into the cpu entry area

On Thu, Nov 23, 2017 at 6:40 PM, Andy Lutomirski wrote: > On Thu, Nov 23, 2017 at 12:37 PM, Borislav Petkov wrote: >> On Thu, Nov 23, 2017 at 12:15:14PM -0800, Andy Lutomirski wrote: >>> >> diff --git a/arch/x86/kernel/asm-offsets.c >>> >>

Re: [PATCH v2 10/18] x86/asm: Remap the TSS into the cpu entry area

On Thu, Nov 23, 2017 at 6:40 PM, Andy Lutomirski wrote: > On Thu, Nov 23, 2017 at 12:37 PM, Borislav Petkov wrote: >> On Thu, Nov 23, 2017 at 12:15:14PM -0800, Andy Lutomirski wrote: >>> >> diff --git a/arch/x86/kernel/asm-offsets.c >>> >> b/arch/x86/kernel/asm-offsets.c >>> >> index

Re: [PATCH v2 13/18] x86/asm/64: Use a percpu trampoline stack for IDT entries

On Thu, Nov 23, 2017 at 3:44 PM, Thomas Gleixner wrote: > On Tue, 21 Nov 2017, Andy Lutomirski wrote: >> The asm isn't exactly beautiful, > > Delightful euphemism :) > >> but I think that fully refactoring >> it can wait. > >> @@ -560,6 +560,14 @@ END(irq_entries_start) >>

Re: [PATCH v2 13/18] x86/asm/64: Use a percpu trampoline stack for IDT entries

On Thu, Nov 23, 2017 at 3:44 PM, Thomas Gleixner wrote: > On Tue, 21 Nov 2017, Andy Lutomirski wrote: >> The asm isn't exactly beautiful, > > Delightful euphemism :) > >> but I think that fully refactoring >> it can wait. > >> @@ -560,6 +560,14 @@ END(irq_entries_start) >> .macro interrupt

RE: [PATCH 1/3] dt-bindings: Add vendor prefix for Allo.com

Acked-by : sudeep -Original Message- From: Andreas Färber [mailto:afaer...@suse.de] Sent: Tuesday, November 14, 2017 11:31 PM To: linux-arm-ker...@lists.infradead.org Cc: Thomas Liau ; Jeff Chen ;

RE: [PATCH 1/3] dt-bindings: Add vendor prefix for Allo.com

Acked-by : sudeep -Original Message- From: Andreas Färber [mailto:afaer...@suse.de] Sent: Tuesday, November 14, 2017 11:31 PM To: linux-arm-ker...@lists.infradead.org Cc: Thomas Liau ; Jeff Chen ; 张东风 ; 刘炜 ; 张天益 ; 梅利 ; Ioan B ; Sudeep Kumar ; linux-kernel@vger.kernel.org; Andreas

RE: [PATCH 2/3] dt-bindings: arm: actions: Add Sparky

Acked-by : sudeep -Original Message- From: Andreas Färber [mailto:afaer...@suse.de] Sent: Tuesday, November 14, 2017 11:31 PM To: linux-arm-ker...@lists.infradead.org Cc: Thomas Liau ; Jeff Chen ;

RE: [PATCH 2/3] dt-bindings: arm: actions: Add Sparky

Acked-by : sudeep -Original Message- From: Andreas Färber [mailto:afaer...@suse.de] Sent: Tuesday, November 14, 2017 11:31 PM To: linux-arm-ker...@lists.infradead.org Cc: Thomas Liau ; Jeff Chen ; 张东风 ; 刘炜 ; 张天益 ; 梅利 ; Ioan B ; Sudeep Kumar ; linux-kernel@vger.kernel.org; Andreas

[git pull] drm for 4.15 part 2 (updated)

Hi Linus, This is an incremental pull on top of yesterdays, it contains all of that, Summary from first pull: This is just some bits and pieces for the second half of the merge window, 1. Remove the MSM dt-bindings file Rob managed to push in the previous pull. 2. Add a property/edid quirk to

[git pull] drm for 4.15 part 2 (updated)

Hi Linus, This is an incremental pull on top of yesterdays, it contains all of that, Summary from first pull: This is just some bits and pieces for the second half of the merge window, 1. Remove the MSM dt-bindings file Rob managed to push in the previous pull. 2. Add a property/edid quirk to

Re: [GIT PULL] Second batch of KVM changes for Linux 4.15

On Mon, Nov 20, 2017 at 2:06 PM, Paolo Bonzini wrote: > > I am not including the host side of AMD SEV, because it wouldn't have gotten > enough time in linux-next even with a "regular-length" merge window. It > will be in 4.16. So I pulled it, but then checked, None of

Re: [GIT PULL] Second batch of KVM changes for Linux 4.15

On Mon, Nov 20, 2017 at 2:06 PM, Paolo Bonzini wrote: > > I am not including the host side of AMD SEV, because it wouldn't have gotten > enough time in linux-next even with a "regular-length" merge window. It > will be in 4.16. So I pulled it, but then checked, None of this was in linux-next

Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock

> On 23 Nov 2017, at 5:24 PM, Greg KH wrote: > > On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote: >> >> What I want to do here is to finding this connection: >> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <-> >> ASMedia XHCI controller (PCI ID:

Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock

> On 23 Nov 2017, at 5:24 PM, Greg KH wrote: > > On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote: >> >> What I want to do here is to finding this connection: >> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <-> >> ASMedia XHCI controller (PCI ID: 1b21:1142). >> >> Is there a

Re: [GIT PULL] UBI/UBIFS updates for 4.15-rc1

On Thu, Nov 23, 2017 at 4:37 AM, Richard Weinberger wrote: > > git://git.infradead.org/linux-ubifs.git tags/upstream-4.15-rc1 Similarly to the arch/um case, none of this seems to have been in linux-next, and is sent late in the merge window, so I'm skipping it.

Re: [GIT PULL] UBI/UBIFS updates for 4.15-rc1

On Thu, Nov 23, 2017 at 4:37 AM, Richard Weinberger wrote: > > git://git.infradead.org/linux-ubifs.git tags/upstream-4.15-rc1 Similarly to the arch/um case, none of this seems to have been in linux-next, and is sent late in the merge window, so I'm skipping it. Linus

Re: [GIT PULL] UML updates for 4.15-rc1

On Thu, Nov 23, 2017 at 4:36 AM, Richard Weinberger wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.15-rc1 I asked people to send me their pull requests early before I was traveling, and this second week I'm only taking fixes, or things that were

Re: [GIT PULL] UML updates for 4.15-rc1

On Thu, Nov 23, 2017 at 4:36 AM, Richard Weinberger wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.15-rc1 I asked people to send me their pull requests early before I was traveling, and this second week I'm only taking fixes, or things that were in linux-next.

Re: [PATCH 0/3] scsi: arcmsr: add driver module parameter - msi_enable, msix_enable

On Thu, 2017-11-23 at 04:57 -0800, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 09:22:03AM +0800, Ching Huang wrote: > > From: Ching Huang > > > > Hi all, > > > > The following patches apply to Martin's 4.16/scsi-queue. > > > > Patch 1: Add module parameter

Re: [PATCH 0/3] scsi: arcmsr: add driver module parameter - msi_enable, msix_enable

On Thu, 2017-11-23 at 04:57 -0800, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 09:22:03AM +0800, Ching Huang wrote: > > From: Ching Huang > > > > Hi all, > > > > The following patches apply to Martin's 4.16/scsi-queue. > > > > Patch 1: Add module parameter msi_enable to has a chance to

Re: [PATCH 2/3] scsi: arcmsr: Add driver module parameter msix_enable

On Thu, 2017-11-23 at 14:43 +0300, Dan Carpenter wrote: > On Thu, Nov 23, 2017 at 09:31:14AM +0800, Ching Huang wrote: > > @@ -829,12 +833,15 @@ arcmsr_request_irq(struct pci_dev *pdev, > > unsigned long flags; > > int nvec, i; > > > > + if (msix_enable == 0) > > + goto

Re: [PATCH 2/3] scsi: arcmsr: Add driver module parameter msix_enable

On Thu, 2017-11-23 at 14:43 +0300, Dan Carpenter wrote: > On Thu, Nov 23, 2017 at 09:31:14AM +0800, Ching Huang wrote: > > @@ -829,12 +833,15 @@ arcmsr_request_irq(struct pci_dev *pdev, > > unsigned long flags; > > int nvec, i; > > > > + if (msix_enable == 0) > > + goto

Re: [PATCH 1/3] lockdep: Apply crossrelease to PG_locked locks

On Thu, Nov 16, 2017 at 02:07:46PM +0100, Michal Hocko wrote: > On Thu 16-11-17 21:48:05, Byungchul Park wrote: > > On 11/16/2017 9:02 PM, Michal Hocko wrote: > > > for each struct page. So you are doubling the size. Who is going to > > > enable this config option? You are moving this to page_ext

Re: [PATCH 1/3] lockdep: Apply crossrelease to PG_locked locks

On Thu, Nov 16, 2017 at 02:07:46PM +0100, Michal Hocko wrote: > On Thu 16-11-17 21:48:05, Byungchul Park wrote: > > On 11/16/2017 9:02 PM, Michal Hocko wrote: > > > for each struct page. So you are doubling the size. Who is going to > > > enable this config option? You are moving this to page_ext

[tip:WIP.x86/mm 37/50] arch/x86/events/intel/ds.c:296:2: note: in expansion of macro 'if'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/mm head: 7d2da250f83856bbf697d58a3c10c5673e8146bc commit: 93e8b1bed0d21ad5a5bf0e1151a9163a72f89072 [37/50] x86/mm/kaiser: Map virtually-addressed performance monitoring buffers config: i386-randconfig-x019-201747

[tip:WIP.x86/mm 37/50] arch/x86/events/intel/ds.c:296:2: note: in expansion of macro 'if'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/mm head: 7d2da250f83856bbf697d58a3c10c5673e8146bc commit: 93e8b1bed0d21ad5a5bf0e1151a9163a72f89072 [37/50] x86/mm/kaiser: Map virtually-addressed performance monitoring buffers config: i386-randconfig-x019-201747

RE: [PATCH v2 2/4] platform/x86: intel_telemetry: Fix suspend stats

On Fri, November 24, 2017 at 2:55 AM, Andy Shevchenko wrote: > On Tue, Nov 21, 2017 at 4:36 PM, Souvik Kumar Chakravarty > wrote: > > Suspend stats are not reported consistently due to a limitation in the > > PMC firmware. This

RE: [PATCH v2 2/4] platform/x86: intel_telemetry: Fix suspend stats

On Fri, November 24, 2017 at 2:55 AM, Andy Shevchenko wrote: > On Tue, Nov 21, 2017 at 4:36 PM, Souvik Kumar Chakravarty > wrote: > > Suspend stats are not reported consistently due to a limitation in the > > PMC firmware. This limitation causes a delay in updating the s0ix > > counters and

[PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver

From: Jacob Chen This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver. The phy driver is kind of independent compare to the other parts, but i'd like to keep it in rkisp1 driver, unless people want to generalize it Signed-off-by: Jacob Chen

[PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver

From: Jacob Chen This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver. The phy driver is kind of independent compare to the other parts, but i'd like to keep it in rkisp1 driver, unless people want to generalize it Signed-off-by: Jacob Chen Signed-off-by: Shunqian Zheng

linux-next: Tree for Nov 24

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 20171123: The drm tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 766 849 files changed, 17680 insertions(+), 8497 deletions

linux-next: Tree for Nov 24

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 20171123: The drm tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 766 849 files changed, 17680 insertions(+), 8497 deletions

Re: [PATCH v2 10/18] x86/asm: Remap the TSS into the cpu entry area

On Thu, Nov 23, 2017 at 12:37 PM, Borislav Petkov wrote: > On Thu, Nov 23, 2017 at 12:15:14PM -0800, Andy Lutomirski wrote: >> >> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c >> >> index b275863128eb..55858b277cf6 100644 >> >> ---

Re: [PATCH v2 10/18] x86/asm: Remap the TSS into the cpu entry area

On Thu, Nov 23, 2017 at 12:37 PM, Borislav Petkov wrote: > On Thu, Nov 23, 2017 at 12:15:14PM -0800, Andy Lutomirski wrote: >> >> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c >> >> index b275863128eb..55858b277cf6 100644 >> >> --- a/arch/x86/kernel/asm-offsets.c >>

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