Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Fri, 9 Jun 2017, Andrey Konovalov wrote: > On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov > wrote: > > Hi, > > > > I'm getting some hangs while fuzzing the kernel with syzkaller. > > > > Possibly it happens during the execution of the following syzkaller program: > >

Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Fri, 9 Jun 2017, Andrey Konovalov wrote: > On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov > wrote: > > Hi, > > > > I'm getting some hangs while fuzzing the kernel with syzkaller. > > > > Possibly it happens during the execution of the following syzkaller program: > > > >

[PATCH] [media] tuner-core: Remove unused #define PREFIX

Commit 680d87c0a9e3 ("[media] tuner-core: use pr_foo, instead of internal printk macros") removed the use of PREFIX, remove the #define Signed-off-by: Joe Perches --- drivers/media/v4l2-core/tuner-core.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH] [media] tuner-core: Remove unused #define PREFIX

Commit 680d87c0a9e3 ("[media] tuner-core: use pr_foo, instead of internal printk macros") removed the use of PREFIX, remove the #define Signed-off-by: Joe Perches --- drivers/media/v4l2-core/tuner-core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/v4l2-core/tuner-core.c

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 09 Jun 2017 20:53:53 +0200 Paul Bolle wrote: > On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > > I'm sure it works, but it just adds one more way of doing the same > > thing. I thought that was what perl was always criticized for, and why > > people usually

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 09 Jun 2017 20:53:53 +0200 Paul Bolle wrote: > On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > > I'm sure it works, but it just adds one more way of doing the same > > thing. I thought that was what perl was always criticized for, and why > > people usually prefer python.

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On 06/09/2017 02:38 PM, Josh Poimboeuf wrote: > On Thu, Jun 01, 2017 at 02:25:26PM -0400, Joe Lawrence wrote: >> [ ... snip ... ] >> @@ -99,6 +130,12 @@ static int livepatch_init(void) >> >> static void livepatch_exit(void) >> { >> +struct task_ctr *nd, *tmp; >> + >> +

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On 06/09/2017 02:38 PM, Josh Poimboeuf wrote: > On Thu, Jun 01, 2017 at 02:25:26PM -0400, Joe Lawrence wrote: >> [ ... snip ... ] >> @@ -99,6 +130,12 @@ static int livepatch_init(void) >> >> static void livepatch_exit(void) >> { >> +struct task_ctr *nd, *tmp; >> + >> +

Re: [PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis

On Sat, Jun 10, 2017 at 12:25 AM, srishti sharma wrote: > Fixed alignment so that it matched open paranthesis . > > Signed-off-by: srishti sharma > --- > drivers/staging/ks7010/ks_hostif.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis

On Sat, Jun 10, 2017 at 12:25 AM, srishti sharma wrote: > Fixed alignment so that it matched open paranthesis . > > Signed-off-by: srishti sharma > --- > drivers/staging/ks7010/ks_hostif.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/9/2017 1:43 PM, Boris Ostrovsky wrote: On 06/09/2017 02:36 PM, Tom Lendacky wrote: On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/9/2017 1:43 PM, Boris Ostrovsky wrote: On 06/09/2017 02:36 PM, Tom Lendacky wrote: On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

[adding parisc list] On Fri, 2017-06-09 at 13:13 +0200, Peter Zijlstra wrote: > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: > > > The spinlock based atomics should be SC, that is, none of them > > appear to > > place extra barriers in atomic_cmpxchg() or any of the other SC >

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

[adding parisc list] On Fri, 2017-06-09 at 13:13 +0200, Peter Zijlstra wrote: > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: > > > The spinlock based atomics should be SC, that is, none of them > > appear to > > place extra barriers in atomic_cmpxchg() or any of the other SC >

Re: [PATCH] arm64: ftrace: fix building without CONFIG_MODULES

On Fri, Jun 9, 2017 at 1:38 PM, Will Deacon wrote: > Hi Arnd, > > On Fri, Jun 09, 2017 at 12:27:06PM +0200, Arnd Bergmann wrote: >> When CONFIG_MODULES is disabled, we cannot dereference a module pointer: >> >> arch/arm64/kernel/ftrace.c: In function 'ftrace_make_call': >>

Re: [PATCH] arm64: ftrace: fix building without CONFIG_MODULES

On Fri, Jun 9, 2017 at 1:38 PM, Will Deacon wrote: > Hi Arnd, > > On Fri, Jun 09, 2017 at 12:27:06PM +0200, Arnd Bergmann wrote: >> When CONFIG_MODULES is disabled, we cannot dereference a module pointer: >> >> arch/arm64/kernel/ftrace.c: In function 'ftrace_make_call': >>

Re: [RFC v4 00/20] Speculative page faults

On Fri, Jun 09, 2017 at 04:20:49PM +0200, Laurent Dufour wrote: > This is a port on kernel 4.12 of the work done by Peter Zijlstra to > handle page fault without holding the mm semaphore. > >

Re: [RFC v4 00/20] Speculative page faults

On Fri, Jun 09, 2017 at 04:20:49PM +0200, Laurent Dufour wrote: > This is a port on kernel 4.12 of the work done by Peter Zijlstra to > handle page fault without holding the mm semaphore. > >

Re: [PATCH 2/4] Protectable Memory Allocator

On 06/07/2017 05:35 AM, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain only data that will not need further

Re: [PATCH 2/4] Protectable Memory Allocator

On 06/07/2017 05:35 AM, Igor Stoppa wrote: > The MMU available in many systems running Linux can often provide R/O > protection to the memory pages it handles. > > However, the MMU-based protection works efficiently only when said pages > contain only data that will not need further

Re: [PATCH] ARM: at91: fix at91_suspend_entering_slow_clock link error

On Fri, Jun 9, 2017 at 1:44 PM, Alexandre Belloni wrote: > Hi, > > On 09/06/2017 at 12:18:02 +0200, Arnd Bergmann wrote: >> When CONFIG_ARCH_AT91 is enabled, but none of the specific SoC support >> is in use, some at91 specific drivers fail to link: >> >>

Re: [PATCH] ARM: at91: fix at91_suspend_entering_slow_clock link error

On Fri, Jun 9, 2017 at 1:44 PM, Alexandre Belloni wrote: > Hi, > > On 09/06/2017 at 12:18:02 +0200, Arnd Bergmann wrote: >> When CONFIG_ARCH_AT91 is enabled, but none of the specific SoC support >> is in use, some at91 specific drivers fail to link: >> >> drivers/tty/serial/atmel_serial.o: In

[PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis

Fixed alignment so that it matched open paranthesis . Signed-off-by: srishti sharma --- drivers/staging/ks7010/ks_hostif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ks7010/ks_hostif.c b/drivers/staging/ks7010/ks_hostif.c

[PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis

Fixed alignment so that it matched open paranthesis . Signed-off-by: srishti sharma --- drivers/staging/ks7010/ks_hostif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ks7010/ks_hostif.c b/drivers/staging/ks7010/ks_hostif.c index 697347b..e3c11be

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized for, and why > people usually prefer python. Don't get me wrong, I prefer oysters over > snakes. But I just

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized for, and why > people usually prefer python. Don't get me wrong, I prefer oysters over > snakes. But I just

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

On Fri, Jun 09, 2017 at 10:28:50AM -0700, Vineet Gupta wrote: > On 06/09/2017 04:13 AM, Peter Zijlstra wrote: > > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: > > > > > The spinlock based atomics should be SC, that is, none of them appear to > > > place extra barriers in

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

On Fri, Jun 09, 2017 at 10:28:50AM -0700, Vineet Gupta wrote: > On 06/09/2017 04:13 AM, Peter Zijlstra wrote: > > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote: > > > > > The spinlock based atomics should be SC, that is, none of them appear to > > > place extra barriers in

[PATCH] sched/core: idle_task_exit() shouldn't use switch_mm_irqs_off()

idle_task_exit() can be called with IRQs on x86 on and therefore should use switch_mm(), not switch_mm_irqs_off(). This doesn't seem to cause any problems right now, but it will confuse my upcoming TLB flush changes. Nonetheless, I think it should be backported because it's trivial. There won't

[PATCH] sched/core: idle_task_exit() shouldn't use switch_mm_irqs_off()

idle_task_exit() can be called with IRQs on x86 on and therefore should use switch_mm(), not switch_mm_irqs_off(). This doesn't seem to cause any problems right now, but it will confuse my upcoming TLB flush changes. Nonetheless, I think it should be backported because it's trivial. There won't

Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote: > On 6/8/2017 1:05 AM, Andy Lutomirski wrote: >> >> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky >> wrote: >>> >>> The cr3 register entry can contain the SME encryption bit that indicates >>>

Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky wrote: > On 6/8/2017 1:05 AM, Andy Lutomirski wrote: >> >> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky >> wrote: >>> >>> The cr3 register entry can contain the SME encryption bit that indicates >>> the PGD is encrypted. The encryption bit should

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 06/09/2017 02:36 PM, Tom Lendacky wrote: > On 6/8/2017 5:01 PM, Andrew Cooper wrote: >> On 08/06/2017 22:17, Boris Ostrovsky wrote: >>> On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>> What may be needed is making sure X86_FEATURE_SME is not

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 06/09/2017 02:36 PM, Tom Lendacky wrote: > On 6/8/2017 5:01 PM, Andrew Cooper wrote: >> On 08/06/2017 22:17, Boris Ostrovsky wrote: >>> On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>> What may be needed is making sure X86_FEATURE_SME is not

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Fri, Jun 09, 2017 at 03:45:54PM +0100, Will Deacon wrote: > On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > > Commit: > > > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > > visible before page table updates") > > > > added

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Fri, Jun 09, 2017 at 03:45:54PM +0100, Will Deacon wrote: > On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > > Commit: > > > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > > visible before page table updates") > > > > added

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, Jun 9, 2017 at 9:32 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 21:23:52 +0300 > Andy Shevchenko wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, Jun 9, 2017 at 9:32 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 21:23:52 +0300 > Andy Shevchenko wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized for, and why > people usually prefer python. Don't

Re: [PATCH 0/4] ARM64: dts: meson-gx: Add HDMI and CVBS nodes for selected boards

Neil Armstrong writes: > Add the CVBS and HDMI nodes for the following boards : > - Wetek Play2 > - Khadas VIM > - Amlogic P230 Reference board > - Amlogic P212 Reference board Applied to v4.13/dt64. Thanks, Kevin

Re: [PATCH 0/4] ARM64: dts: meson-gx: Add HDMI and CVBS nodes for selected boards

Neil Armstrong writes: > Add the CVBS and HDMI nodes for the following boards : > - Wetek Play2 > - Khadas VIM > - Amlogic P230 Reference board > - Amlogic P212 Reference board Applied to v4.13/dt64. Thanks, Kevin

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On Thu, Jun 01, 2017 at 02:25:26PM -0400, Joe Lawrence wrote: > #include > +#include > static int livepatch_cmdline_proc_show(struct seq_file *m, void *v) > { > + struct task_ctr *nd; > + > + nd = klp_shadow_get(current, "task_ctr"); > + if (!nd) { > + nd =

Re: [PATCH 3/3] livepatch: add shadow variable sample program

On Thu, Jun 01, 2017 at 02:25:26PM -0400, Joe Lawrence wrote: > #include > +#include > static int livepatch_cmdline_proc_show(struct seq_file *m, void *v) > { > + struct task_ctr *nd; > + > + nd = klp_shadow_get(current, "task_ctr"); > + if (!nd) { > + nd =

[PATCH v3] acpi: configfs: Unload SSDT on configfs entry removal

Call directly into acpica to load a table to obtain its index on return. We choose the direct call of acpica internal functions to avoid having to modify its API which is used outside of Linux as well. Use that index to unload the table again when the corresponding directory in configfs gets

[PATCH v3] acpi: configfs: Unload SSDT on configfs entry removal

Call directly into acpica to load a table to obtain its index on return. We choose the direct call of acpica internal functions to avoid having to modify its API which is used outside of Linux as well. Use that index to unload the table again when the corresponding directory in configfs gets

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making sure X86_FEATURE_SME is not set for PV guests. And that may be something that Xen will

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/8/2017 5:01 PM, Andrew Cooper wrote: On 08/06/2017 22:17, Boris Ostrovsky wrote: On 06/08/2017 05:02 PM, Tom Lendacky wrote: On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: What may be needed is making sure X86_FEATURE_SME is not set for PV guests. And that may be something that Xen will

[PATCH v6 03/10] gpio: exar: Allocate resources on behalf of the platform device

Do not allocate resources on behalf of the parent device but on our own. Otherwise, cleanup does not properly work if gpio-exar is removed but not the parent device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij

[PATCH v6 03/10] gpio: exar: Allocate resources on behalf of the platform device

Do not allocate resources on behalf of the parent device but on our own. Otherwise, cleanup does not properly work if gpio-exar is removed but not the parent device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c | 4 ++-- 1 file

[PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

This makes the gpio-exar driver usable, which was prevented by a number of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar driver and, indirectly, to gpio-exar as well. It's a cross-subsystem series, so I'm also cross-posting to the serial and gpio lists. Changes in v6: -

[PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

This makes the gpio-exar driver usable, which was prevented by a number of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar driver and, indirectly, to gpio-exar as well. It's a cross-subsystem series, so I'm also cross-posting to the serial and gpio lists. Changes in v6: -

[PATCH v6 06/10] gpio-exar/8250-exar: Rearrange gpiochip parenthood

Set the parent of the exar gpiochip to its platform device, like other gpiochips are doing it. In order to keep the relationship discoverable for ACPI systems, set the platform device companion to the PCI device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko

[PATCH v6 09/10] gpio-exar/8250-exar: Make set of exported GPIOs configurable

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the rest is required to operate the UART. To allow modeling this case, expand the platform device data structure to specify a (consecutive) pin subset for exporting by the gpio-exar driver. Signed-off-by: Jan Kiszka

[PATCH v6 06/10] gpio-exar/8250-exar: Rearrange gpiochip parenthood

Set the parent of the exar gpiochip to its platform device, like other gpiochips are doing it. In order to keep the relationship discoverable for ACPI systems, set the platform device companion to the PCI device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij

[PATCH v6 09/10] gpio-exar/8250-exar: Make set of exported GPIOs configurable

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the rest is required to operate the UART. To allow modeling this case, expand the platform device data structure to specify a (consecutive) pin subset for exporting by the gpio-exar driver. Signed-off-by: Jan Kiszka Reviewed-by:

[PATCH v6 10/10] serial: exar: Add support for IOT2040 device

This implements the setup of RS232 and the switch-over to RS485 or RS422 for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic to switch between the different modes. The external logic is controlled via MPIO pins of the EXAR controller. Only pin 10 can be exported as GPIO on the

[PATCH v6 02/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

This fixes reloading of the GPIO driver for the same platform device instance as created by the exar UART driver: First of all, the driver sets drvdata to its own value during probing and does not restore the original value on exit. But this won't help anyway as the core clears drvdata after the

[PATCH v6 10/10] serial: exar: Add support for IOT2040 device

This implements the setup of RS232 and the switch-over to RS485 or RS422 for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic to switch between the different modes. The external logic is controlled via MPIO pins of the EXAR controller. Only pin 10 can be exported as GPIO on the

[PATCH v6 02/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

This fixes reloading of the GPIO driver for the same platform device instance as created by the exar UART driver: First of all, the driver sets drvdata to its own value during probing and does not restore the original value on exit. But this won't help anyway as the core clears drvdata after the

[PATCH v6 08/10] platform: Accept const properties

Aligns us with device_add_properties, the function we call. Signed-off-by: Jan Kiszka --- drivers/base/platform.c | 2 +- include/linux/platform_device.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c

Re: [PATCH 1/3] livepatch: introduce shadow variable API

On Fri, Jun 09, 2017 at 11:36:27AM -0400, Joe Lawrence wrote: > On 06/08/2017 12:49 PM, Josh Poimboeuf wrote: > > On Thu, Jun 01, 2017 at 02:25:24PM -0400, Joe Lawrence wrote: > >> Add three exported API for livepatch modules: > >> > >> void *klp_shadow_attach(void *obj, char *var, gfp_t gfp,

[PATCH v6 08/10] platform: Accept const properties

Aligns us with device_add_properties, the function we call. Signed-off-by: Jan Kiszka --- drivers/base/platform.c | 2 +- include/linux/platform_device.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index

Re: [PATCH 1/3] livepatch: introduce shadow variable API

On Fri, Jun 09, 2017 at 11:36:27AM -0400, Joe Lawrence wrote: > On 06/08/2017 12:49 PM, Josh Poimboeuf wrote: > > On Thu, Jun 01, 2017 at 02:25:24PM -0400, Joe Lawrence wrote: > >> Add three exported API for livepatch modules: > >> > >> void *klp_shadow_attach(void *obj, char *var, gfp_t gfp,

[PATCH v6 07/10] serial: exar: Factor out platform hooks

This prepares the addition of IOT2040 platform support by preparing the needed setup and rs485_config hooks. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko --- drivers/tty/serial/8250/8250_exar.c | 32 +++-

[PATCH v6 07/10] serial: exar: Factor out platform hooks

This prepares the addition of IOT2040 platform support by preparing the needed setup and rs485_config hooks. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko --- drivers/tty/serial/8250/8250_exar.c | 32 +++- 1 file changed, 27 insertions(+), 5 deletions(-)

[PATCH v6 04/10] gpio: exar: Fix iomap request

The UART driver already maps the resource for us. Trying to do this here only fails and leaves us with a non-working device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij ---

[PATCH v6 05/10] gpio: exar: Fix reading of directions and values

First, the logic for translating a register bit to the return code of exar_get_direction and exar_get_value were wrong. And second, there was a flip regarding the register bank in exar_get_direction. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko

[PATCH v6 04/10] gpio: exar: Fix iomap request

The UART driver already maps the resource for us. Trying to do this here only fails and leaves us with a non-working device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij --- drivers/gpio/gpio-exar.c | 10 +++--- 1 file changed, 3 insertions(+), 7

[PATCH v6 05/10] gpio: exar: Fix reading of directions and values

First, the logic for translating a register bit to the return code of exar_get_direction and exar_get_value were wrong. And second, there was a flip regarding the register bank in exar_get_direction. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij ---

[PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards

Commtech adapters need the MPIOs for internal purposes, and the gpio-exar driver already refused to pick them up. But there is actually no point in even creating the underlying platform device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko

[PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards

Commtech adapters need the MPIOs for internal purposes, and the gpio-exar driver already refused to pick them up. But there is actually no point in even creating the underlying platform device. Signed-off-by: Jan Kiszka Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij ---

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 9 Jun 2017 21:23:52 +0300 Andy Shevchenko wrote: > On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > > On Fri, 9 Jun 2017 15:27:36 +0200 > > Vitaly Kuznetsov wrote: > > > >> +#if IS_ENABLED(CONFIG_HYPERV)

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 9 Jun 2017 21:23:52 +0300 Andy Shevchenko wrote: > On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > > On Fri, 9 Jun 2017 15:27:36 +0200 > > Vitaly Kuznetsov wrote: > > > >> +#if IS_ENABLED(CONFIG_HYPERV) > > > > Hmm, this is new to me. I know you can use IS_ENABLED()

[tip:efi/urgent] efi: Fix boot panic because of invalid BGRT image address

Commit-ID: 792ef14df5c585c19b2831673a077504a09e5203 Gitweb: http://git.kernel.org/tip/792ef14df5c585c19b2831673a077504a09e5203 Author: Dave Young AuthorDate: Fri, 9 Jun 2017 08:45:58 + Committer: Ingo Molnar CommitDate: Fri, 9 Jun 2017 14:50:11

[tip:efi/urgent] efi: Fix boot panic because of invalid BGRT image address

Commit-ID: 792ef14df5c585c19b2831673a077504a09e5203 Gitweb: http://git.kernel.org/tip/792ef14df5c585c19b2831673a077504a09e5203 Author: Dave Young AuthorDate: Fri, 9 Jun 2017 08:45:58 + Committer: Ingo Molnar CommitDate: Fri, 9 Jun 2017 14:50:11 +0200 efi: Fix boot panic because of

Re: [PATCH] ARM64: defconfig: enable meson SPICC as module

Neil Armstrong writes: > This patch enable the SPI Communications Controller driver as module for the > Amlogic platform. > > Signed-off-by: Neil Armstrong Applied to v4.13/defconfig, Kevin

Re: [PATCH] ARM64: defconfig: enable meson SPICC as module

Neil Armstrong writes: > This patch enable the SPI Communications Controller driver as module for the > Amlogic platform. > > Signed-off-by: Neil Armstrong Applied to v4.13/defconfig, Kevin

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 15:27:36 +0200 > Vitaly Kuznetsov wrote: >> +#if IS_ENABLED(CONFIG_HYPERV) > > Hmm, this is new to me. I know you can use IS_ENABLED() inside C code, > but I've never seen it

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 15:27:36 +0200 > Vitaly Kuznetsov wrote: >> +#if IS_ENABLED(CONFIG_HYPERV) > > Hmm, this is new to me. I know you can use IS_ENABLED() inside C code, > but I've never seen it used for preprocessor directives. This

Re: [PATCH] ASoC: Intel: byt-max98090 Fix GPIOs lookup

On Fri, Jun 9, 2017 at 7:50 PM, Dmitry Torokhov wrote: > From: Nicolas Porcel > > Commit 9c3c9bc9cc98 ("gpiolib: tighten up ACPI legacy gpio lookups") > changed the way fallback to _CRS-defined GPIOs is executed by requiring > drivers use

[PATCH V2 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

From: Kan Liang The NMI watchdog uses either the fixed cycles or a generic cycles counter. This causes a lot of conflicts with users of the PMU who want to run a full group including the cycles fixed counter, for example the --topdown support recently added to perf stat. The

[PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

From: Kan Liang The dominant motivation is to make it possible to switch cycles NMI watchdog to ref_cycles on x86 platform. The new NMI watchdog could - Free widely used precious cycles fixed counter. For example, topdown code needs the cycles fixed counter in group

Re: [PATCH] ASoC: Intel: byt-max98090 Fix GPIOs lookup

On Fri, Jun 9, 2017 at 7:50 PM, Dmitry Torokhov wrote: > From: Nicolas Porcel > > Commit 9c3c9bc9cc98 ("gpiolib: tighten up ACPI legacy gpio lookups") > changed the way fallback to _CRS-defined GPIOs is executed by requiring > drivers use common connection ID for all GPIOs fetched from _CRS.

[PATCH V2 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

From: Kan Liang The NMI watchdog uses either the fixed cycles or a generic cycles counter. This causes a lot of conflicts with users of the PMU who want to run a full group including the cycles fixed counter, for example the --topdown support recently added to perf stat. The code needs to fall

[PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

From: Kan Liang The dominant motivation is to make it possible to switch cycles NMI watchdog to ref_cycles on x86 platform. The new NMI watchdog could - Free widely used precious cycles fixed counter. For example, topdown code needs the cycles fixed counter in group counting. Otherwise,

Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

On 06/08/17 22:52, Nicholas A. Bellinger wrote: > Because qla2xxx doesn't reuse tags, it's not a problem since it's the > only consumer of TARGET_SCF_LOOKUP_LUN_FROM_TAG. Hello Nic, Can you clarify this? Since all target drivers and also the target core use a finite number of bits to represent

Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK

On 06/08/17 22:52, Nicholas A. Bellinger wrote: > Because qla2xxx doesn't reuse tags, it's not a problem since it's the > only consumer of TARGET_SCF_LOOKUP_LUN_FROM_TAG. Hello Nic, Can you clarify this? Since all target drivers and also the target core use a finite number of bits to represent

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On 06/09/17 02:24, Peter Zijlstra wrote: > > --- /dev/null 2017-05-05 13:16:22.636212333 +0200 > +++ b/Documentation/atomic_t.txt 2017-06-09 11:05:31.501599153 +0200 > @@ -0,0 +1,147 @@ > + > +The one detail to this is that atomic_set() should be observable to the RmW > +ops. That is: > + >

Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document

On 06/09/17 02:24, Peter Zijlstra wrote: > > --- /dev/null 2017-05-05 13:16:22.636212333 +0200 > +++ b/Documentation/atomic_t.txt 2017-06-09 11:05:31.501599153 +0200 > @@ -0,0 +1,147 @@ > + > +The one detail to this is that atomic_set() should be observable to the RmW > +ops. That is: > + >

[ANNOUNCE] 3.2.89-rt127

Dear RT Folks, I'm pleased to announce the 3.2.89-rt127 stable release. This release is just an update to the new stable 3.2.89 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.2.89-rt127

Dear RT Folks, I'm pleased to announce the 3.2.89-rt127 stable release. This release is just an update to the new stable 3.2.89 version and no RT specific changes have been made. You can get this release via the git tree at:

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

On Sat, Jun 10, 2017 at 03:01:47AM +1000, Aleksa Sarai wrote: > The feature this patch references has currently only been accepted into > tty-testing, but Greg told me to kick this down to man-pages. As a > result, I can't reference upstream commit id's because the code isn't in > Linus' tree yet

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

On Sat, Jun 10, 2017 at 03:01:47AM +1000, Aleksa Sarai wrote: > The feature this patch references has currently only been accepted into > tty-testing, but Greg told me to kick this down to man-pages. As a > result, I can't reference upstream commit id's because the code isn't in > Linus' tree yet

Re: [PATCH 0/2] arm64: fix crash when reading /proc/kcore

On 06/08/2017 12:41 PM, Ard Biesheuvel wrote: > This is a follow-up to patches from zhonjiang [0] and myself [1] that aim > to solve a problem in the kcore code, which gets confused by the presence > of block mappings in the vmalloc region. > > While fixing the crash is quite straight forward

Re: [PATCH 0/2] arm64: fix crash when reading /proc/kcore

On 06/08/2017 12:41 PM, Ard Biesheuvel wrote: > This is a follow-up to patches from zhonjiang [0] and myself [1] that aim > to solve a problem in the kcore code, which gets confused by the presence > of block mappings in the vmalloc region. > > While fixing the crash is quite straight forward

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 9 Jun 2017 15:27:36 +0200 Vitaly Kuznetsov wrote: > Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). > Tracing is done the same way we do xen_mmu_flush_tlb_others(). > > Signed-off-by: Vitaly Kuznetsov > --- >

Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

On Fri, 9 Jun 2017 15:27:36 +0200 Vitaly Kuznetsov wrote: > Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others(). > Tracing is done the same way we do xen_mmu_flush_tlb_others(). > > Signed-off-by: Vitaly Kuznetsov > --- > MAINTAINERS | 1 + >

Re: [PATCH tip/core/rcu 0/88] Commits for 4.13

On Fri, Jun 09, 2017 at 10:57:04AM -0700, Paul E. McKenney wrote: > On Fri, Jun 09, 2017 at 01:33:31PM -0400, Steven Rostedt wrote: > > On Fri, 9 Jun 2017 10:20:38 -0700 > > "Paul E. McKenney" wrote: > > > > > > > But enough fantasizing about possible futures. Any

Re: [PATCH tip/core/rcu 0/88] Commits for 4.13

On Fri, Jun 09, 2017 at 10:57:04AM -0700, Paul E. McKenney wrote: > On Fri, Jun 09, 2017 at 01:33:31PM -0400, Steven Rostedt wrote: > > On Fri, 9 Jun 2017 10:20:38 -0700 > > "Paul E. McKenney" wrote: > > > > > > > But enough fantasizing about possible futures. Any thoughts on what > > > could

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