- Linux-stable-mirror - lists.linaro.org

Re: [Linux-stable-mirror] [v2] cpufreq: powernv: Fix the frequency read by /proc/cpuinfo

by Michael Ellerman

On Fri, 2017-10-13 at 04:36:41 UTC, Shriya wrote: > The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which > returns the last frequency requested by the kernel, but may not > reflect the actual frequency the processor is running at. > This patch makes a call to cpufreq_get() instead which returns the > current frequency reported by the hardware. > > Fixes : commit fb5153d05a7d ("powerpc: powernv: Implement > ppc_md.get_proc_freq()") > Cc: stable(a)vger.kernel.org > > Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/cd77b5ce208c153260ed7882d8910f cheers

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] watchdog: indydog: Add dependency on SGI_HAS_INDYDOG

by Matt Redfearn

Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") enabled building the Indy watchdog driver when COMPILE_TEST is enabled. However, the driver makes reference to symbols that are only defined for certain platforms are selected in the config. These platforms select SGI_HAS_INDYDOG. Without this, link time errors result, for example when building a MIPS allyesconfig. drivers/watchdog/indydog.o: In function `indydog_write': indydog.c:(.text+0x18): undefined reference to `sgimc' indydog.c:(.text+0x1c): undefined reference to `sgimc' drivers/watchdog/indydog.o: In function `indydog_start': indydog.c:(.text+0x54): undefined reference to `sgimc' indydog.c:(.text+0x58): undefined reference to `sgimc' drivers/watchdog/indydog.o: In function `indydog_stop': indydog.c:(.text+0xa4): undefined reference to `sgimc' drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined references to `sgimc' follow make: *** [Makefile:1005: vmlinux] Error 1 Fix this by ensuring that CONFIG_INDIDOG can only be selected when the necessary dependent platform symbols are built in. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com> Cc: <stable(a)vger.kernel.org> # 4.11 + --- drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index ca200d1f310a..d96e2e7544fc 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1451,7 +1451,7 @@ config RC32434_WDT config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST) + depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG) help Hardware driver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second -- 2.7.4

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 4.13 00/33] 4.13.13-stable review

by Greg Kroah-Hartman

On Mon, Nov 13, 2017 at 02:02:12PM -0800, kernelci.org bot wrote: > stable-rc/linux-4.13.y boot: 127 boots: 10 failed, 116 passed with 1 conflict (v4.13.12-34-g109b28ca1340) > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.13.y/kernel/v4.1… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.13.y/kernel/v4.13.12-34… > > Tree: stable-rc > Branch: linux-4.13.y > Git Describe: v4.13.12-34-g109b28ca1340 > Git Commit: 109b28ca1340961002d4bede168f07823451b8e4 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 51 unique boards, 17 SoC families, 18 builds out of 188 > > Boot Regressions Detected: > > arm: > > at91_dt_defconfig: > at91rm9200ek_rootfs:nfs: > lab-free-electrons: new failure (last pass: v4.13.12) > > exynos_defconfig: > exynos4412-odroidx2_rootfs:nfs: > lab-collabora: failing since 4 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) > exynos5250-snow_rootfs:nfs: > lab-collabora: failing since 4 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) Thanks for these "failing since..." markings, that makes me feel better that I didn't break anything on my end :) greg k-h

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] brcmfmac: remove setting IBSS mode when stopping AP

by Philipp Rosenberger

Hi, commit 9029679f66d976f8c720eb03c4898274803c9923 upstream. the patch "brcmfmac: remove setting IBSS mode when stopping AP" fixes a recurring warning[1] when we run our wifi in AP mode after we stopped an AP on the same card. We are using the 4.9 stable tree. But every kernel < 4.13 and >= 3.9 is affected by this problem. Best regards Philipp [1] The warning message with backtrace: [ 517.577475] brcmfmac: brcmf_update_bss_info: wl dtim_assoc failed (-23) [ 517.584567] ------------[ cut here ]------------ [ 517.594906] WARNING: CPU: 0 PID: 963 at /home/ilu/src/linux/net/wireless/sme.c:738 __cfg80211_connect_result+0x2dc/0x400 [cfg80211] [ 517.610126] Modules linked in: brcmfmac brcmutil cfg80211 [ 517.615752] CPU: 0 PID: 963 Comm: kworker/u2:2 Tainted: G W 4.9.56-sde-00010-g3b9115e #18 [ 517.627723] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 517.634647] Workqueue: cfg80211 cfg80211_event_work [cfg80211] [ 517.642070] [<c010f270>] (unwind_backtrace) from [<c010c4f0>] (show_stack+0x10/0x14) [ 517.652696] [<c010c4f0>] (show_stack) from [<c011cab4>] (__warn+0xe8/0x100) [ 517.661193] [<c011cab4>] (__warn) from [<c011cb7c>] (warn_slowpath_null+0x20/0x28) [ 517.670507] [<c011cb7c>] (warn_slowpath_null) from [<bf02f6a4>] (__cfg80211_connect_result+0x2dc/0x400 [cfg80211]) [ 517.682888] [<bf02f6a4>] (__cfg80211_connect_result [cfg80211]) from [<bf00564c>] (cfg80211_process_wdev_events+0x178/0x1f8 [cfg80211]) [ 517.696985] [<bf00564c>] (cfg80211_process_wdev_events [cfg80211]) from [<bf0056f8>] (cfg80211_process_rdev_events+0x2c/0x60 [cfg80211]) [ 517.711110] [<bf0056f8>] (cfg80211_process_rdev_events [cfg80211]) from [<bf00027c>] (cfg80211_event_work+0x14/0x1c [cfg80211]) [ 517.724539] [<bf00027c>] (cfg80211_event_work [cfg80211]) from [<c01358cc>] (process_one_work+0x12c/0x518) [ 517.735875] [<c01358cc>] (process_one_work) from [<c0135cf0>] (worker_thread+0x38/0x5d8) [ 517.745234] [<c0135cf0>] (worker_thread) from [<c013b32c>] (kthread+0xf0/0x108) [ 517.754090] [<c013b32c>] (kthread) from [<c0108498>] (ret_from_fork+0x14/0x3c) [ 517.762967] ---[ end trace f68728a0d3053b54 ]--- [ 517.770431] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

by Rabin Vincent

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal pending, arm64's do_page_fault() > > > > implementation returns 0. The intent is that we'll return to the > > > > faulting userspace instruction, delivering the signal on the way. > > > > > > > > However, if we take a fatal signal during fixing up a uaccess, this > > > > results in a return to the faulting kernel instruction, which will be > > > > instantly retried, resulting in the same fault being taken forever. As > > > > the task never reaches userspace, the signal is not delivered, and the > > > > task is left unkillable. While the task is stuck in this state, it can > > > > inhibit the forward progress of the system. > > > > > > > > To avoid this, we must ensure that when a fatal signal is pending, we > > > > apply any necessary fixup for a faulting kernel instruction. Thus we > > > > will return to an error path, and it is up to that code to make forward > > > > progress towards delivering the fatal signal. > > > > > > > > Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> > > > > Reviewed-by: Steve Capper <steve.capper(a)arm.com> > > > > Tested-by: Steve Capper <steve.capper(a)arm.com> > > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com> > > > > Cc: James Morse <james.morse(a)arm.com> > > > > Cc: Laura Abbott <labbott(a)redhat.com> > > > > Cc: Will Deacon <will.deacon(a)arm.com> > > > > Cc: stable(a)vger.kernel.org > > > > --- > > > > arch/arm64/mm/fault.c | 5 ++++- > > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > > > index 37b95df..3952d5e 100644 > > > > --- a/arch/arm64/mm/fault.c > > > > +++ b/arch/arm64/mm/fault.c > > > > @@ -397,8 +397,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, > > > > * signal first. We do not need to release the mmap_sem because it > > > > * would already be released in __lock_page_or_retry in mm/filemap.c. > > > > */ > > > > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) > > > > + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) { > > > > + if (!user_mode(regs)) > > > > + goto no_context; > > > > return 0; > > > > + } > > > > > > This will need rebasing at -rc1 (take a look at current HEAD). > > > > > > Also, I think it introduces a weird corner case where we take a page fault > > > when writing the signal frame to the user stack to deliver a SIGSEGV. If > > > we end up with VM_FAULT_RETRY and somebody has sent a SIGKILL to the task, > > > then we'll fail setup_sigframe and force an un-handleable SIGSEGV instead > > > of SIGKILL. > > > > > > The end result (task is killed) is the same, but the fatal signal is wrong. > > > > That doesn't seem to be the case, testing on v4.13-rc5. > > > > I used sigaltstack() to use the userfaultfd region as signal stack, > > registerd a SIGSEGV handler, and dereferenced NULL. The task locks up, > > but when killed with a SIGINT or SIGKILL, the exit status reflects that > > signal, rather than the SIGSEGV. > > > > If I move the SIGINT handler onto the userfaultfd-monitored stack, then > > delivering SIGINT hangs, but can be killed with SIGKILL, and the exit > > status reflects that SIGKILL. > > > > As you say, it does look like we'd try to set up a deferred SIGSEGV for > > the failed signal delivery. > > > > I haven't yet figured out exactly how that works; I'll keep digging. > > The SEGV makes it all the way into do_group_exit, but then signal_group_exit > is set and the exit_code is overridden with SIGKILL at the last minute (see > complete_signal). Unfortunately, this last minute is too late for print-fatal-signals. With print-fatal-signals enabled, this patch leads to misleading "potentially unexpected fatal signal 11" warnings if a process is SIGKILL'd at the right time. I've seen it without userfaultfd, but it's easiest reproduced by patching Mark's original test code [1] with the following patch and simply running "pkill -WINCH foo; pkill -KILL foo". This results in: foo: potentially unexpected fatal signal 11. CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3 task: b3534780 task.stack: b4b7c000 PC is at 0x76effb60 LR is at 0x4227f4 pc : [<76effb60>] lr : [<004227f4>] psr: 600b0010 sp : 7eaf7bb4 ip : 00000000 fp : 00000000 r10: 00000001 r9 : 00000003 r8 : 76fcd000 r7 : 0000001d r6 : 76fd0cf0 r5 : 7eaf7c08 r4 : 00000000 r3 : 00000000 r2 : 00000000 r1 : 7eaf7a88 r0 : fffffffc Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user Control: 10c5387d Table: 3357404a DAC: 00000055 CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3 [<801113f0>] (unwind_backtrace) from [<8010cfb0>] (show_stack+0x18/0x1c) [<8010cfb0>] (show_stack) from [<8039725c>] (dump_stack+0x84/0x98) [<8039725c>] (dump_stack) from [<8012f448>] (get_signal+0x384/0x684) [<8012f448>] (get_signal) from [<8010c2ec>] (do_signal+0xcc/0x470) [<8010c2ec>] (do_signal) from [<8010c868>] (do_work_pending+0xb8/0xc8) [<8010c868>] (do_work_pending) from [<801086d4>] (slow_work_pending+0xc/0x20) This is ARM and I haven't tested ARM64, but the same problem even exists on x86. --- foo.c.orig 2017-11-13 23:45:47.802167284 +0100 +++ foo.c 2017-11-14 07:16:13.906363466 +0100 @@ -6,6 +6,11 @@ #include <sys/syscall.h> #include <sys/vfs.h> #include <unistd.h> +#include <signal.h> + +static void handler(int sig) +{ +} int main(int argc, char *argv[]) { @@ -47,13 +52,17 @@ if (ret < 0) return errno; + sigaltstack(&(stack_t){.ss_sp = mem, .ss_size = pagesz}, NULL); + sigaction(SIGWINCH, &(struct sigaction){ .sa_handler = handler, .sa_flags = SA_ONSTACK, }, NULL); + /* * Force an arbitrary uaccess to memory monitored by the userfaultfd. * This will block, but when a SIGKILL is sent, will consume all * available CPU time without being killed, and may inhibit forward * progress of the system. */ - ret = fstatfs(0, (struct statfs *)mem); + // ret = fstatfs(0, (struct statfs *)mem); + pause(); return 0; } [1] https://lkml.kernel.org/r/1499782590-31366-1-git-send-email-mark.rutland@ar…

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] drm/i915: Fix vblank timestamp/frame counter jumps on gen2

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Previously I was under the impression that the scanline counter reads 0 when the pipe is off. Turns out that's not correct, and instead the scanline counter simply stops when the pipe stops, and it retains it's last value until the pipe starts up again, at which point the scanline counter jumps to vblank start. These jumps can cause the timestamp to jump backwards by one frame. Since we use the timestamps to guesstimage also the frame counter value on gen2, that would cause the frame counter to also jump backwards, which leads to a massice difference from the previous value. The end result is that flips/vblank events don't appear to complete as they're stuck waiting for the frame counter to catch up to that massive difference. Fix the problem properly by actually making sure the scanline counter has started to move before we assume that it's safe to enable vblank processing. Cc: stable(a)vger.kernel.org Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0ebf3f283b87..810b1147a0ac 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv, return crtc->config->cpu_transcoder; } -static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) +static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, + enum pipe pipe, bool stopped) { i915_reg_t reg = PIPEDSL(pipe); u32 line1, line2; @@ -1013,7 +1014,7 @@ static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) msleep(5); line2 = I915_READ(reg) & line_mask; - return line1 == line2; + return (line1 == line2) == stopped; } /* @@ -1048,11 +1049,21 @@ static void intel_wait_for_pipe_off(struct intel_crtc *crtc) WARN(1, "pipe_off wait timed out\n"); } else { /* Wait for the display line to settle */ - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100)) WARN(1, "pipe_off wait timed out\n"); } } +static void intel_wait_for_pipe_on(struct intel_crtc *crtc) +{ + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + + /* Wait for the display line to start moving */ + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, false), 100)) + WARN(1, "pipe_on wait timed out\n"); +} + /* Only for pre-ILK configs */ void assert_pll(struct drm_i915_private *dev_priv, enum pipe pipe, bool state) @@ -1935,15 +1946,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc) POSTING_READ(reg); /* - * Until the pipe starts DSL will read as 0, which would cause - * an apparent vblank timestamp jump, which messes up also the - * frame count when it's derived from the timestamps. So let's - * wait for the pipe to start properly before we call - * drm_crtc_vblank_on() + * Until the pipe starts DSL can give a bogus value, which cause + * an apparent vblank timestamp jump when the DSL resets to its + * proper value, which messes up also the frame count when it's + * derived from the timestamps. So let's wait for the pipe to + * start properly before we call drm_crtc_vblank_on() */ - if (dev->max_vblank_count == 0 && - wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50)) - DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe)); + if (dev->max_vblank_count == 0) + intel_wait_for_pipe_on(crtc); } /** @@ -14707,7 +14717,7 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe) I915_WRITE(PIPECONF(pipe), 0); POSTING_READ(PIPECONF(pipe)); - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100)) DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe)); I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS); -- 2.13.6

7 years, 6 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH 4.4 34/46] crypto: xts - Add ECB dependency

by Ben Hutchings

On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me > know. > > ------------------ > > From: Milan Broz <gmazyland(a)gmail.com> > > > [ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ] > > Since the > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40 > crypto: xts - Convert to skcipher That commit went into 4.10, and not any stable branches. So this fix doesn't appear to be appropriate for the older branches it was applied to. Ben. > the XTS mode is based on ECB, so the mode must select > ECB otherwise it can fail to initialize. > > Signed-off-by: Milan Broz <gmazyland(a)gmail.com> > Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> > Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > crypto/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -343,6 +343,7 @@ config CRYPTO_XTS > select CRYPTO_BLKCIPHER > select CRYPTO_MANAGER > select CRYPTO_GF128MUL > + select CRYPTO_ECB > help > XTS: IEEE1619/D16 narrow block cipher use with aes-xts- > plain, > key size 256, 384 or 512 bits. This implementation > currently > > > -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 6 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH 4.4 41/46] uapi: fix linux/rds.h userspace compilation errors

by Ben Hutchings

On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: "Dmitry V. Levin" <ldv(a)altlinux.org> > > > [ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ] > > Consistently use types from linux/types.h to fix the following > linux/rds.h userspace compilation errors: [...] > --- a/include/uapi/linux/rds.h > +++ b/include/uapi/linux/rds.h > @@ -35,6 +35,7 @@ > #define _LINUX_RDS_H > > #include <linux/types.h> > +#include <linux/socket.h> /* For __kernel_sockaddr_storage. */ > > #define RDS_IB_ABI_VERSION 0x301 > > @@ -223,7 +224,7 @@ struct rds_get_mr_args { > }; > > struct rds_get_mr_for_dest_args { > - struct sockaddr_storage dest_addr; > + struct __kernel_sockaddr_storage dest_addr; > struct rds_iovec vec; > uint64_t cookie_addr; > uint64_t flags; This is a valid fix but not the one that the commit message and upstream commit hash refer to. This diff matches: commit 1786dbf3702e33ce3afd2d3dbe630bd04b1d2e58 Author: Dmitry V. Levin <ldv(a)altlinux.org> Date: Thu Feb 16 18:05:45 2017 +0300 uapi: fix linux/rds.h userspace compilation error which has almost the same subject line. Maybe you should cherry-pick commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 for real as well (in all branches). Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH] arm64: dts: marvell: mark the cp110 crypto engine as dma coherent

by Antoine Tenart

commit ec0aef9881d18aa781268ec9cba8eba5b202f5b4 upstream. The crypto engines found on the cp110 master and slave are dma coherent. This patch adds the relevant property to their dt nodes. Cc: stable(a)vger.kernel.org # v4.12+ Fixes: 973020fd9498 ("arm64: marvell: dts: add crypto engine description for 7k/8k") Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com> Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> --- Hi, This patch did not apply to the 4.12-stable tree. Since the original patch made it to Linus tree, this is a version which applies nicely to the 4.12-stable tree. Thanks, Antoine arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 1 + arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi index b4bc42ece754..4e81130ae84a 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi @@ -240,6 +240,7 @@ interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", "eip"; clocks = <&cpm_syscon0 1 26>; + dma-coherent; status = "disabled"; }; }; diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi index 6e2058847ddc..b987565107f3 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi @@ -230,6 +230,7 @@ interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", "eip"; clocks = <&cps_syscon0 1 26>; + dma-coherent; status = "disabled"; }; }; -- 2.14.3

7 years, 6 months

2
3
0 0

[Linux-stable-mirror] v4.14 build: 0 failures 0 warnings (v4.14)

by Build bot for Mark Brown

Tree/Branch: v4.14 Git describe: v4.14 Commit: bebc6082da Linux 4.14 Build Time: 97 min 53 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror