Re: KAISER: kexec triggers a warning

On Fri, Dec 01, 2017 at 04:37:13PM +0100, Borislav Petkov wrote: > On Fri, Dec 01, 2017 at 07:31:36AM -0800, Dave Hansen wrote: > > The only question is whether we want to preserve _some_ kind of warning > > there, or just axe it entirely. > > Right, my fear would be if we keep it, then we'd have

Re: KAISER: kexec triggers a warning

On Fri, Dec 01, 2017 at 04:37:13PM +0100, Borislav Petkov wrote: > On Fri, Dec 01, 2017 at 07:31:36AM -0800, Dave Hansen wrote: > > The only question is whether we want to preserve _some_ kind of warning > > there, or just axe it entirely. > > Right, my fear would be if we keep it, then we'd have

Re: [PATCH v3 2/3] clk: meson-axg: add clock controller drivers

On 11/30, Yixun Lan wrote: > Hi Stephen > > On 11/30/17 03:34, Stephen Boyd wrote: > > On 11/28, Yixun Lan wrote: > >> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c > >> new file mode 100644 > >> index ..51c5b4062715 > >> --- /dev/null > >> +++

Re: [PATCH v3 2/3] clk: meson-axg: add clock controller drivers

On 11/30, Yixun Lan wrote: > Hi Stephen > > On 11/30/17 03:34, Stephen Boyd wrote: > > On 11/28, Yixun Lan wrote: > >> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c > >> new file mode 100644 > >> index ..51c5b4062715 > >> --- /dev/null > >> +++

Re: Null pointer 4.14.1-rt3

On 2017-12-01 11:03:15 [-0500], Steven Rostedt wrote: > On Fri, 1 Dec 2017 13:26:05 +0100 > Sebastian Andrzej Siewior wrote: > > > - disable RT_PUSH_IPI if booted on UP. After all there is not much > > benefit here, is there? > > This is what I would suggest. Maybe I'll

Re: Null pointer 4.14.1-rt3

On 2017-12-01 11:03:15 [-0500], Steven Rostedt wrote: > On Fri, 1 Dec 2017 13:26:05 +0100 > Sebastian Andrzej Siewior wrote: > > > - disable RT_PUSH_IPI if booted on UP. After all there is not much > > benefit here, is there? > > This is what I would suggest. Maybe I'll look at adding a

[PATCH 2/2] serial: stm32: fix name conflict with 8250

From: Ludovic Barre This patch replaces stm32 tty name ttyS by ttySTM to avoid a name conflict when Serial: 8250/16550 driver is activated. sysfs: cannot create duplicate filename '/class/tty/ttyS3' Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted

[PATCH 2/2] serial: stm32: fix name conflict with 8250

From: Ludovic Barre This patch replaces stm32 tty name ttyS by ttySTM to avoid a name conflict when Serial: 8250/16550 driver is activated. sysfs: cannot create duplicate filename '/class/tty/ttyS3' Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-12903-gb392521-dirty #1 []

[PATCH 1/2] serial: stm32: add default console

From: Ludovic Barre This patch adds by default the console support on stm32. Signed-off-by: Ludovic Barre --- drivers/tty/serial/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig

[PATCH 1/2] serial: stm32: add default console

From: Ludovic Barre This patch adds by default the console support on stm32. Signed-off-by: Ludovic Barre --- drivers/tty/serial/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index b788fee..969e598 100644 ---

[PATCH 0/2] serial: stm32: fix name conflict

From: Ludovic Barre This patch series: -fix name conflict, when both driver 8250/stm32-usart are activated. Replace stm32 tty name "ttyS" by "ttySTM". -by default add stm32 console when SERIAL_STM32 is selected. Ludovic Barre (2): serial: stm32: add default console

[PATCH 0/2] serial: stm32: fix name conflict

From: Ludovic Barre This patch series: -fix name conflict, when both driver 8250/stm32-usart are activated. Replace stm32 tty name "ttyS" by "ttySTM". -by default add stm32 console when SERIAL_STM32 is selected. Ludovic Barre (2): serial: stm32: add default console serial: stm32: fix name

Re: [PATCH v5 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Jacek On 11/30/2017 03:38 PM, Jacek Anaszewski wrote: > Dan, > > Thanks for addressing my remarks. LED class device name > composition stills needs some tweaking, though. > > Please refer below to the piece of code in question. > > On 11/30/2017 08:22 PM, Dan Murphy wrote: >> Introducing the

Re: [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC

On 11/30, Yixun Lan wrote: > Hi Stephen > > On 11/30/17 03:35, Stephen Boyd wrote: > > On 11/28, Yixun Lan wrote: > >> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi > >> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi > >> index b932a784b02a..36a2e98338a8 100644 > >> ---

Re: [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC

On 11/30, Yixun Lan wrote: > Hi Stephen > > On 11/30/17 03:35, Stephen Boyd wrote: > > On 11/28, Yixun Lan wrote: > >> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi > >> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi > >> index b932a784b02a..36a2e98338a8 100644 > >> ---

Re: [PATCH v5 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Jacek On 11/30/2017 03:38 PM, Jacek Anaszewski wrote: > Dan, > > Thanks for addressing my remarks. LED class device name > composition stills needs some tweaking, though. > > Please refer below to the piece of code in question. > > On 11/30/2017 08:22 PM, Dan Murphy wrote: >> Introducing the

Re: [GIT PULL] hash addresses printed with %p

On Fri, Dec 1, 2017 at 7:34 AM, Greg Kroah-Hartman wrote: > And isn't there a specific %p modifier you should use for a kernel > pointer. I've lost the thread here for what should, or should not, be > done for kernel pointers these days based on the long email

Re: [GIT PULL] hash addresses printed with %p

On Fri, Dec 1, 2017 at 7:34 AM, Greg Kroah-Hartman wrote: > And isn't there a specific %p modifier you should use for a kernel > pointer. I've lost the thread here for what should, or should not, be > done for kernel pointers these days based on the long email discussion. Current

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

On Fri, Dec 01, 2017 at 08:29:53AM -0800, Dan Williams wrote: > > And maybe we should think about moving the rlimit accounting into this > > new function too someday? > > DAX pages are not accounted in any rlimit because they are statically > allocated reserved memory regions. I mean, unrelated

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

On Fri, Dec 01, 2017 at 08:29:53AM -0800, Dan Williams wrote: > > And maybe we should think about moving the rlimit accounting into this > > new function too someday? > > DAX pages are not accounted in any rlimit because they are statically > allocated reserved memory regions. I mean, unrelated

Re: [PATCH] scsi: ipr: fix incorrect indentation of assignment statement

On 12/01/2017 07:33 AM, Colin King wrote: > From: Colin Ian King > > Remove one extraneous level of indentation on an assignment statement. > > Signed-off-by: Colin Ian King > --- > drivers/scsi/ipr.c | 4 ++-- > 1 file changed, 2

Re: [PATCH] scsi: ipr: fix incorrect indentation of assignment statement

On 12/01/2017 07:33 AM, Colin King wrote: > From: Colin Ian King > > Remove one extraneous level of indentation on an assignment statement. > > Signed-off-by: Colin Ian King > --- > drivers/scsi/ipr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: WARNING in binder_send_failed_reply

On Fri, Dec 1, 2017 at 5:27 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > b0a84f19a5161418d4360cd57603e94ed489915e > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler:

Re: WARNING in binder_send_failed_reply

On Fri, Dec 1, 2017 at 5:27 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > b0a84f19a5161418d4360cd57603e94ed489915e > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

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

On Fri, Dec 1, 2017 at 8:02 AM, Jason Gunthorpe wrote: > > On Fri, Dec 01, 2017 at 11:12:18AM +0100, Michal Hocko wrote: > > On Thu 30-11-17 12:01:17, Jason Gunthorpe wrote: > > > On Thu, Nov 30, 2017 at 10:32:42AM -0800, Dan Williams wrote: > > > > > Who and how many LRU pages can

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

On Fri, Dec 1, 2017 at 8:02 AM, Jason Gunthorpe wrote: > > On Fri, Dec 01, 2017 at 11:12:18AM +0100, Michal Hocko wrote: > > On Thu 30-11-17 12:01:17, Jason Gunthorpe wrote: > > > On Thu, Nov 30, 2017 at 10:32:42AM -0800, Dan Williams wrote: > > > > > Who and how many LRU pages can pin that way

Re: [PATCH 1/1] at24: Fix I²C device selection for runtime PM

2017-12-01 16:35 GMT+01:00 Sakari Ailus : > Hi Sven, > > On Fri, Dec 01, 2017 at 10:20:41AM -0500, Sven Van Asbroeck wrote: >> Thank you, it fixes the issue on the multi-address eeprom that I have access >> to. >> >> Tested-by: Sven Van Asbroeck on a 24AA16/24LC16B

Re: [PATCH 1/1] at24: Fix I²C device selection for runtime PM

2017-12-01 16:35 GMT+01:00 Sakari Ailus : > Hi Sven, > > On Fri, Dec 01, 2017 at 10:20:41AM -0500, Sven Van Asbroeck wrote: >> Thank you, it fixes the issue on the multi-address eeprom that I have access >> to. >> >> Tested-by: Sven Van Asbroeck on a 24AA16/24LC16B >> >> One very minor remark:

Re: [PATCH v2 18/18] perf: arm_spe: Disallow userspace profiling when arm_kernel_unmapped_at_el0()

On 11/30, Will Deacon wrote: > When running with the kernel unmapped whilst at EL0, the virtually-addressed > SPE buffer is also unmapped, which can lead to buffer faults if userspace > profiling is enabled. > > This patch prohibits SPE profiling of userspace when > arm_kernel_unmapped_at_el0().

Re: [PATCH v2 18/18] perf: arm_spe: Disallow userspace profiling when arm_kernel_unmapped_at_el0()

On 11/30, Will Deacon wrote: > When running with the kernel unmapped whilst at EL0, the virtually-addressed > SPE buffer is also unmapped, which can lead to buffer faults if userspace > profiling is enabled. > > This patch prohibits SPE profiling of userspace when > arm_kernel_unmapped_at_el0().

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

On Fri, Dec 01, 2017 at 08:17:04AM -0800, Daniel Lustig wrote: > On 12/1/2017 7:32 AM, Alan Stern wrote: > > On Fri, 1 Dec 2017, Boqun Feng wrote: > >>> But even on a non-other-multicopy-atomic system, there has to be some > >>> synchronization between the memory controller and P1's CPU.

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

On Fri, Dec 01, 2017 at 08:17:04AM -0800, Daniel Lustig wrote: > On 12/1/2017 7:32 AM, Alan Stern wrote: > > On Fri, 1 Dec 2017, Boqun Feng wrote: > >>> But even on a non-other-multicopy-atomic system, there has to be some > >>> synchronization between the memory controller and P1's CPU.

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

On Fri, 1 Dec 2017 10:38:07 +0100 Pierre Morel wrote: > On 30/11/2017 19:30, Alex Williamson wrote: > > On Thu, 30 Nov 2017 16:11:35 +0100 > > Pierre Morel wrote: > > > >> On 30/11/2017 15:08, Alex Williamson wrote: > >>> On Thu, 30 Nov

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

On Fri, 1 Dec 2017 10:38:07 +0100 Pierre Morel wrote: > On 30/11/2017 19:30, Alex Williamson wrote: > > On Thu, 30 Nov 2017 16:11:35 +0100 > > Pierre Morel wrote: > > > >> On 30/11/2017 15:08, Alex Williamson wrote: > >>> On Thu, 30 Nov 2017 12:34:38 +0100 > >>> Pierre Morel wrote: > >>>

Re: [PATCH v2] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky wrote: > Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make > them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses > eflags using 'pushfq' instruction when testing for IF bit. On PV Xen >

Re: [PATCH v2] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky wrote: > Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make > them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses > eflags using 'pushfq' instruction when testing for IF bit. On PV Xen > guests looking at IF flag

Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller

On Fri, Dec 01, 2017 at 11:37:49AM +0100, Cyrille Pitchen wrote: > Hi Bjorn, > > Le 28/11/2017 à 21:41, Bjorn Helgaas a écrit : > > On Thu, Nov 23, 2017 at 04:01:48PM +0100, Cyrille Pitchen wrote: > >> This patch adds support to the Cadence PCIe controller in host mode. > >> > >> Signed-off-by:

Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller

On Fri, Dec 01, 2017 at 11:37:49AM +0100, Cyrille Pitchen wrote: > Hi Bjorn, > > Le 28/11/2017 à 21:41, Bjorn Helgaas a écrit : > > On Thu, Nov 23, 2017 at 04:01:48PM +0100, Cyrille Pitchen wrote: > >> This patch adds support to the Cadence PCIe controller in host mode. > >> > >> Signed-off-by:

Re: Essential get_user fix missing from 3.10 aarch64

Hi Jason, On Fri, Dec 01, 2017 at 04:57:26PM +0100, Jason A. Donenfeld wrote: > Not sure if there's ever going to be another stable 3.10 release, but > if so, this would be an important one to backport. Thanks for the heads up but unfortunately there's not going to be any more 3.10, it's been

Re: Essential get_user fix missing from 3.10 aarch64

Hi Jason, On Fri, Dec 01, 2017 at 04:57:26PM +0100, Jason A. Donenfeld wrote: > Not sure if there's ever going to be another stable 3.10 release, but > if so, this would be an important one to backport. Thanks for the heads up but unfortunately there's not going to be any more 3.10, it's been

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

On 12/1/2017 7:32 AM, Alan Stern wrote: > On Fri, 1 Dec 2017, Boqun Feng wrote: >>> But even on a non-other-multicopy-atomic system, there has to be some >>> synchronization between the memory controller and P1's CPU. Otherwise, >>> how could the system guarantee that P1's smp_load_acquire

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

On 12/1/2017 7:32 AM, Alan Stern wrote: > On Fri, 1 Dec 2017, Boqun Feng wrote: >>> But even on a non-other-multicopy-atomic system, there has to be some >>> synchronization between the memory controller and P1's CPU. Otherwise, >>> how could the system guarantee that P1's smp_load_acquire

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

On 11/30/2017 8:46 AM, Jan Beulich wrote: On 30.11.17 at 15:15, wrote: On 11/30/2017 2:27 AM, Jan Beulich wrote: On 29.11.17 at 18:38, wrote: In the case of bus or slot reset, our goal is to reset connected PCIe fabric/card/endpoint. The

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

On 11/30/2017 8:46 AM, Jan Beulich wrote: On 30.11.17 at 15:15, wrote: On 11/30/2017 2:27 AM, Jan Beulich wrote: On 29.11.17 at 18:38, wrote: In the case of bus or slot reset, our goal is to reset connected PCIe fabric/card/endpoint. The connected card/endpoint can be multi-function

Re: [PATCH RFC 0/6] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

On 01/12/2017 14:13, Vitaly Kuznetsov wrote: > Currently, KVM passes PVCLOCK_TSC_STABLE_BIT to its guests when running in > so called 'masterclock' mode and this is only possible when the clocksource > on the host is TSC. When running nested on Hyper-V we're using a different > clocksource in L1

Re: [PATCH RFC 0/6] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

On 01/12/2017 14:13, Vitaly Kuznetsov wrote: > Currently, KVM passes PVCLOCK_TSC_STABLE_BIT to its guests when running in > so called 'masterclock' mode and this is only possible when the clocksource > on the host is TSC. When running nested on Hyper-V we're using a different > clocksource in L1

Re: Null pointer 4.14.1-rt3

On Fri, 1 Dec 2017 13:26:05 +0100 Sebastian Andrzej Siewior wrote: > - disable RT_PUSH_IPI if booted on UP. After all there is not much > benefit here, is there? This is what I would suggest. Maybe I'll look at adding a patch. -- Steve

Re: Null pointer 4.14.1-rt3

On Fri, 1 Dec 2017 13:26:05 +0100 Sebastian Andrzej Siewior wrote: > - disable RT_PUSH_IPI if booted on UP. After all there is not much > benefit here, is there? This is what I would suggest. Maybe I'll look at adding a patch. -- Steve

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

On Fri, Dec 01, 2017 at 11:12:18AM +0100, Michal Hocko wrote: > On Thu 30-11-17 12:01:17, Jason Gunthorpe wrote: > > On Thu, Nov 30, 2017 at 10:32:42AM -0800, Dan Williams wrote: > > > > Who and how many LRU pages can pin that way and how do you prevent nasty > > > > users to DoS systems this way?

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

On Fri, Dec 01, 2017 at 11:12:18AM +0100, Michal Hocko wrote: > On Thu 30-11-17 12:01:17, Jason Gunthorpe wrote: > > On Thu, Nov 30, 2017 at 10:32:42AM -0800, Dan Williams wrote: > > > > Who and how many LRU pages can pin that way and how do you prevent nasty > > > > users to DoS systems this way?

[PATCH RT 08/15] net: take the tcp_sk_lock lock with BH disabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Lockdep may complain about an unsafe locking scenario: | CPU0CPU1 | |

[PATCH RT 04/15] posixtimer: init timer only with CONFIG_POSIX_TIMERS enabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior In v4.11 it is possible to disable the posix timers and so we must not attempt to initialize the task_struct on RT with

[PATCH RT 08/15] net: take the tcp_sk_lock lock with BH disabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Lockdep may complain about an unsafe locking scenario: | CPU0CPU1 | | lock((tcp_sk_lock).lock); |

[PATCH RT 04/15] posixtimer: init timer only with CONFIG_POSIX_TIMERS enabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior In v4.11 it is possible to disable the posix timers and so we must not attempt to initialize the task_struct on RT with !POSIX_TIMERS. This patch does so.

[PATCH RT 01/15] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" The commit "memcontrol: Prevent scheduling while atomic in cgroup code" fixed this issue: refill_stock()

[PATCH RT 01/15] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" The commit "memcontrol: Prevent scheduling while atomic in cgroup code" fixed this issue: refill_stock() get_cpu_var()

[PATCH RT 06/15] PM / CPU: replace raw_notifier with atomic_notifier (fixup)

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The original patch changed betwen its posting and what finally went into Rafael's tree so here is the delta. Signed-off-by:

[PATCH RT 06/15] PM / CPU: replace raw_notifier with atomic_notifier (fixup)

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The original patch changed betwen its posting and what finally went into Rafael's tree so here is the delta. Signed-off-by: Sebastian Andrzej Siewior ---

[PATCH RT 05/15] cpu_pm: replace raw_notifier to atomic_notifier

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Alex Shi This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due

[PATCH RT 05/15] cpu_pm: replace raw_notifier to atomic_notifier

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Alex Shi This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due to a 'scheduling while

[PATCH RT 10/15] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer

[PATCH RT 10/15] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer raising softirq

[PATCH v2 2/4] 44x/fsp2: interrupt handling setup

* clear out any possible plb6 errors * board interrupt handling setup within l2 reg set * fsp2 parity error setup All those points are needed for correct interrupt handling on board level including error handling report. Reviewed-by: Alistair Popple Signed-off-by: Ivan

[PATCH v2 2/4] 44x/fsp2: interrupt handling setup

* clear out any possible plb6 errors * board interrupt handling setup within l2 reg set * fsp2 parity error setup All those points are needed for correct interrupt handling on board level including error handling report. Reviewed-by: Alistair Popple Signed-off-by: Ivan Mikhaylov ---

[PATCH v2 3/4] 44x/fsp2: tvsense workaround for dd1

TVSENSE(temperature and voltage sensors) reset is blocked (clock gated) by the POR default of the TVS sleep config bit. As a consequence, TVSENSE will provide erratic sensor values, which may result in spurious (parity) errors recorded in the CMU FIR and leading to erroneous interrupt requests

[PATCH v2 3/4] 44x/fsp2: tvsense workaround for dd1

TVSENSE(temperature and voltage sensors) reset is blocked (clock gated) by the POR default of the TVS sleep config bit. As a consequence, TVSENSE will provide erratic sensor values, which may result in spurious (parity) errors recorded in the CMU FIR and leading to erroneous interrupt requests

[PATCH v2 4/4] 44x/fsp2: add irq error handlers

add irq error handlers for cmu, plb, opb, mcue, conf with debug information output in case of problems. Signed-off-by: Ivan Mikhaylov --- arch/powerpc/platforms/44x/fsp2.c | 205 - 1 files changed, 204 insertions(+), 1 deletions(-) diff

[PATCH v2 4/4] 44x/fsp2: add irq error handlers

add irq error handlers for cmu, plb, opb, mcue, conf with debug information output in case of problems. Signed-off-by: Ivan Mikhaylov --- arch/powerpc/platforms/44x/fsp2.c | 205 - 1 files changed, 204 insertions(+), 1 deletions(-) diff --git

[PATCH v2 1/4] 44x/fsp2: add fsp2 headers

add cmu, plbX, l2, ddr3/4, crcs register definitions. add mfcmu, mtcmu functions for indirect access to cmu. add mtl2, mfl2 same for l2 cache core reg set. Signed-off-by: Ivan Mikhaylov --- arch/powerpc/platforms/44x/fsp2.h | 272 + 1 files

[PATCH RT 07/15] kernel/hrtimer: migrate deferred timer on CPU down

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior hrtimers, which were deferred to the softirq context, and expire between softirq shutdown and hrtimer migration are dangling around.

[PATCH RT 07/15] kernel/hrtimer: migrate deferred timer on CPU down

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior hrtimers, which were deferred to the softirq context, and expire between softirq shutdown and hrtimer migration are dangling around. If the CPU goes back up

[PATCH v2 1/4] 44x/fsp2: add fsp2 headers

add cmu, plbX, l2, ddr3/4, crcs register definitions. add mfcmu, mtcmu functions for indirect access to cmu. add mtl2, mfl2 same for l2 cache core reg set. Signed-off-by: Ivan Mikhaylov --- arch/powerpc/platforms/44x/fsp2.h | 272 + 1 files changed, 272

[PATCH RT 09/15] kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior We must not wake any process (and thus acquire the pi->lock) while holding the hrtimer's base lock. This does not happen usually

[PATCH RT 09/15] kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior We must not wake any process (and thus acquire the pi->lock) while holding the hrtimer's base lock. This does not happen usually because the

[PATCH RT 00/15] Linux

Re: [PATCH v2 16/19] ASoC: tlv320aic31xx: Add short circuit detection support

On Fri, Dec 01, 2017 at 09:32:12AM -0600, Andrew F. Davis wrote: > On 12/01/2017 07:39 AM, Mark Brown wrote: > > Is the interrupt only available on GPIO1? > Some devices can route this to GPIO2 IIRC. > I'm not sure how that would be supported, I think we would need to add > interrupt names to

[PATCH RT 00/15] Linux

Re: [PATCH v2 16/19] ASoC: tlv320aic31xx: Add short circuit detection support

On Fri, Dec 01, 2017 at 09:32:12AM -0600, Andrew F. Davis wrote: > On 12/01/2017 07:39 AM, Mark Brown wrote: > > Is the interrupt only available on GPIO1? > Some devices can route this to GPIO2 IIRC. > I'm not sure how that would be supported, I think we would need to add > interrupt names to

[PATCH RT 13/15] rt/locking: allow recursive local_trylock()

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior required for following networking patch which does recursive try-lock. While at it, add the !RT version of it because it did not yet

[PATCH RT 13/15] rt/locking: allow recursive local_trylock()

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior required for following networking patch which does recursive try-lock. While at it, add the !RT version of it because it did not yet exist. Cc:

Essential get_user fix missing from 3.10 aarch64

Hi stable/arm/Willy, 1f65c13efef69b6dc908e588f91a133641d8475c is an important commit, because it involves evaluation of pointers from userspace. I'm running into issues with RNDADDTOENTCNT reading bogus values, because p is incremented twice as much as it should in this random.c block:

Essential get_user fix missing from 3.10 aarch64

Hi stable/arm/Willy, 1f65c13efef69b6dc908e588f91a133641d8475c is an important commit, because it involves evaluation of pointers from userspace. I'm running into issues with RNDADDTOENTCNT reading bogus values, because p is incremented twice as much as it should in this random.c block:

[PATCH RT 02/15] Revert "fs: jbd2: pull your plug when waiting for space"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior This reverts commit "fs: jbd2: pull your plug when waiting for space". This was a duct-tape fix which shouldn't be needed since

[PATCH RT 02/15] Revert "fs: jbd2: pull your plug when waiting for space"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior This reverts commit "fs: jbd2: pull your plug when waiting for space". This was a duct-tape fix which shouldn't be needed since commit "locking/rt-mutex:

Re: [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

On Fri, Dec 01, 2017 at 01:17:34PM +0530, Sagar Arun Kamble wrote: > There is no real need for the users of timecounters to define cyclecounter > and timecounter variables separately. Since timecounter will always be > based on cyclecounter, have cyclecounter struct as member of timecounter >

Re: [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

On Fri, Dec 01, 2017 at 01:17:34PM +0530, Sagar Arun Kamble wrote: > There is no real need for the users of timecounters to define cyclecounter > and timecounter variables separately. Since timecounter will always be > based on cyclecounter, have cyclecounter struct as member of timecounter >

[PATCH RT 01/15] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" The commit "memcontrol: Prevent scheduling while atomic in cgroup code" fixed this issue: refill_stock()

Re: [PATCH v2 15/19] ASoC: tlv320aic31xx: Reset registers during power up

On Fri, Dec 01, 2017 at 09:04:41AM -0600, Andrew F. Davis wrote: > On 12/01/2017 07:37 AM, Mark Brown wrote: > > On Wed, Nov 29, 2017 at 03:32:56PM -0600, Andrew F. Davis wrote: > >> + } else { > >> + ret = regmap_write(aic31xx->regmap, AIC31XX_RESET, 1); > >> + if (ret < 0) >

[PATCH RT 01/15] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" The commit "memcontrol: Prevent scheduling while atomic in cgroup code" fixed this issue: refill_stock() get_cpu_var()

Re: [PATCH v2 15/19] ASoC: tlv320aic31xx: Reset registers during power up

On Fri, Dec 01, 2017 at 09:04:41AM -0600, Andrew F. Davis wrote: > On 12/01/2017 07:37 AM, Mark Brown wrote: > > On Wed, Nov 29, 2017 at 03:32:56PM -0600, Andrew F. Davis wrote: > >> + } else { > >> + ret = regmap_write(aic31xx->regmap, AIC31XX_RESET, 1); > >> + if (ret < 0) >

Re: [PATCH v2 14/19] ASoC: tlv320aic31xx: Remove regulator notification handling

On Fri, Dec 01, 2017 at 09:01:19AM -0600, Andrew F. Davis wrote: > Looking into the call sites, at least in this case the only time this > notification will be called, outside the normal enable/disable paths > (which do the same thing here: turn on regmap cache only mode and mark > it dirty),

Re: [PATCH v2 14/19] ASoC: tlv320aic31xx: Remove regulator notification handling

On Fri, Dec 01, 2017 at 09:01:19AM -0600, Andrew F. Davis wrote: > Looking into the call sites, at least in this case the only time this > notification will be called, outside the normal enable/disable paths > (which do the same thing here: turn on regmap cache only mode and mark > it dirty),

[PATCH RT 15/15] Linux 4.9.65-rt57-rc1

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 00/15] Linux 4.9.65-rt57-rc1

[ Sorry for the duplicate, I tried to cancel sending, but quilt decided to send anyway :-p ] Dear RT Folks, This is the RT stable review cycle of patch 4.9.65-rt57-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org

[PATCH RT 15/15] Linux 4.9.65-rt57-rc1

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (VMware)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index fdb0f880c7e9..c12fc9d17724

[PATCH RT 00/15] Linux 4.9.65-rt57-rc1

[ Sorry for the duplicate, I tried to cancel sending, but quilt decided to send anyway :-p ] Dear RT Folks, This is the RT stable review cycle of patch 4.9.65-rt57-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org

[PATCH RT 08/15] net: take the tcp_sk_lock lock with BH disabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Lockdep may complain about an unsafe locking scenario: | CPU0CPU1 | |

[PATCH RT 08/15] net: take the tcp_sk_lock lock with BH disabled

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Lockdep may complain about an unsafe locking scenario: | CPU0CPU1 | | lock((tcp_sk_lock).lock); |

[PATCH RT 10/15] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer

[PATCH RT 10/15] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.9.65-rt57-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer raising softirq

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