This is a note to let you know that I've just added the patch titled
arm64: kernel: restrict /dev/mem read() calls to linear region
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Fri, 19 May 2017 16:42:00 +0100
Subject: arm64: kernel: restrict /dev/mem read() calls to linear region
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[ Upstream commit 1151f838cb626005f4d69bf675dacaaa5ea909d6 ]
When running lscpu on an AArch64 system that has SMBIOS version 2.0
tables, it will segfault in the following way:
Unable to handle kernel paging request at virtual address ffff8000bfff0000
pgd = ffff8000f9615000
[ffff8000bfff0000] *pgd=0000000000000000
Internal error: Oops: 96000007 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
task: ffff8000fa78e800 task.stack: ffff8000f9780000
PC is at __arch_copy_to_user+0x90/0x220
LR is at read_mem+0xcc/0x140
This is caused by the fact that lspci issues a read() on /dev/mem at the
offset where it expects to find the SMBIOS structure array. However, this
region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
and so it is omitted from the linear mapping.
So let's restrict /dev/mem read/write access to those areas that are
covered by the linear region.
Reported-by: Alexander Graf <agraf(a)suse.de>
Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/mmap.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -18,6 +18,7 @@
#include <linux/elf.h>
#include <linux/fs.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/export.h>
@@ -102,12 +103,18 @@ void arch_pick_mmap_layout(struct mm_str
*/
int valid_phys_addr_range(phys_addr_t addr, size_t size)
{
- if (addr < PHYS_OFFSET)
- return 0;
- if (addr + size > __pa(high_memory - 1) + 1)
- return 0;
-
- return 1;
+ /*
+ * Check whether addr is covered by a memory region without the
+ * MEMBLOCK_NOMAP attribute, and whether that region covers the
+ * entire range. In theory, this could lead to false negatives
+ * if the range is covered by distinct but adjacent memory regions
+ * that only differ in other attributes. However, few of such
+ * attributes have been defined, and it is debatable whether it
+ * follows that /dev/mem read() calls should be able traverse
+ * such boundaries.
+ */
+ return memblock_is_region_memory(addr, size) &&
+ memblock_is_map_memory(addr);
}
/*
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.9/x86-efi-disable-runtime-services-on-kexec-kernel-if-booted-with-efi-old_map.patch
queue-4.9/arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch
This is a note to let you know that I've just added the patch titled
ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Timmy Li <lixiaoping3(a)huawei.com>
Date: Mon, 22 May 2017 16:48:28 +0100
Subject: ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path
From: Timmy Li <lixiaoping3(a)huawei.com>
[ Upstream commit 717902cc93118119a6fce7765da6cf2786987418 ]
Commit 093d24a20442 ("arm64: PCI: Manage controller-specific data on
per-controller basis") added code to allocate ACPI PCI root_ops
dynamically on a per host bridge basis but failed to update the
corresponding memory allocation failure path in pci_acpi_scan_root()
leading to a potential memory leakage.
Fix it by adding the required kfree call.
Fixes: 093d24a20442 ("arm64: PCI: Manage controller-specific data on per-controller basis")
Reviewed-by: Tomasz Nowicki <tn(a)semihalf.com>
Signed-off-by: Timmy Li <lixiaoping3(a)huawei.com>
[lorenzo.pieralisi(a)arm.com: refactored code, rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
CC: Will Deacon <will.deacon(a)arm.com>
CC: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -175,8 +175,10 @@ struct pci_bus *pci_acpi_scan_root(struc
return NULL;
root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
- if (!root_ops)
+ if (!root_ops) {
+ kfree(ri);
return NULL;
+ }
ri->cfg = pci_acpi_setup_ecam_mapping(root);
if (!ri->cfg) {
Patches currently in stable-queue which might be from lixiaoping3(a)huawei.com are
queue-4.9/arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch
This is a note to let you know that I've just added the patch titled
arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Wed, 5 Apr 2017 11:14:05 +0100
Subject: arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage
From: Will Deacon <will.deacon(a)arm.com>
[ Upstream commit 5f16a046f8e144c294ef98cd29d9458b5f8273e5 ]
FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg
field as a shift value, potentially leading to a left shift value that
is negative or with an absolute value that is significantly larger then
the size of the type. UBSAN chokes with:
================================================================================
UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13
shift exponent -1 is negative
CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11
Hardware name: linux,dummy-virt (DT)
Call trace:
[<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73
[<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline]
[<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52
[<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164
[<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421
[<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline]
[<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline]
[<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231
[<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline]
[<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249
[<ffff200008084770>] el0_svc_naked+0x24/0x28
================================================================================
syz-executor1 uses obsolete (PF_INET,SOCK_PACKET)
sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT
This patch attempts to fix some of this by:
* Making encoded_op an unsigned type, so we can shift it left even if
the top bit is set.
* Casting to signed prior to shifting right when extracting oparg
and cmparg
* Consider only the bottom 5 bits of oparg when using it as a left-shift
value.
Whilst I think this catches all of the issues, I'd much prefer to remove
this stuff, as I think it's unused and the bugs are copy-pasted between
a bunch of architectures.
Reviewed-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/futex.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -51,16 +51,16 @@
: "memory")
static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
+futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
{
int op = (encoded_op >> 28) & 7;
int cmp = (encoded_op >> 24) & 15;
- int oparg = (encoded_op << 8) >> 20;
- int cmparg = (encoded_op << 20) >> 20;
+ int oparg = (int)(encoded_op << 8) >> 20;
+ int cmparg = (int)(encoded_op << 20) >> 20;
int oldval = 0, ret, tmp;
if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
- oparg = 1 << oparg;
+ oparg = 1U << (oparg & 0x1f);
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.9/perf-callchain-force-user_ds-when-invoking-perf_callchain_user.patch
queue-4.9/arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch
queue-4.9/arm64-perf-ignore-exclude_hv-when-kernel-is-running-in-hyp.patch
queue-4.9/arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch
queue-4.9/arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch
This is a note to let you know that I've just added the patch titled
ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Leonard Crestez <leonard.crestez(a)nxp.com>
Date: Tue, 6 Jun 2017 20:50:42 +0300
Subject: ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull
From: Leonard Crestez <leonard.crestez(a)nxp.com>
[ Upstream commit b3ea575770c7eeb259c77b6861cd14d00eb309df ]
Support for imx6ull is already present but it's based on
of_machine_is_compatible("fsl,imx6ull") checks. Add it to the MXC_CPU_*
enumeration as well.
This also fixes /sys/devices/soc0/soc_id reading "Unknown".
Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-imx/cpu.c | 3 +++
arch/arm/mach-imx/mxc.h | 6 ++++++
2 files changed, 9 insertions(+)
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -131,6 +131,9 @@ struct device * __init imx_soc_device_in
case MXC_CPU_IMX6UL:
soc_id = "i.MX6UL";
break;
+ case MXC_CPU_IMX6ULL:
+ soc_id = "i.MX6ULL";
+ break;
case MXC_CPU_IMX7D:
soc_id = "i.MX7D";
break;
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -39,6 +39,7 @@
#define MXC_CPU_IMX6SX 0x62
#define MXC_CPU_IMX6Q 0x63
#define MXC_CPU_IMX6UL 0x64
+#define MXC_CPU_IMX6ULL 0x65
#define MXC_CPU_IMX7D 0x72
#define IMX_DDR_TYPE_LPDDR2 1
@@ -73,6 +74,11 @@ static inline bool cpu_is_imx6ul(void)
return __mxc_cpu_type == MXC_CPU_IMX6UL;
}
+static inline bool cpu_is_imx6ull(void)
+{
+ return __mxc_cpu_type == MXC_CPU_IMX6ULL;
+}
+
static inline bool cpu_is_imx6q(void)
{
return __mxc_cpu_type == MXC_CPU_IMX6Q;
Patches currently in stable-queue which might be from leonard.crestez(a)nxp.com are
queue-4.9/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
queue-4.9/net-phy-micrel-restore-led_mode-and-clk_sel-on-resume.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: qcom: ipq4019: fix i2c_0 node
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-qcom-ipq4019-fix-i2c_0-node.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Christian Lamparter <chunkeey(a)googlemail.com>
Date: Tue, 2 May 2017 21:19:24 +0200
Subject: ARM: dts: qcom: ipq4019: fix i2c_0 node
From: Christian Lamparter <chunkeey(a)googlemail.com>
[ Upstream commit 650df439cfb96c303328935559b2d06127a5a0b0 ]
This patch fixes two typos in the i2c_0 node for the ipq4019.
The reg property length is just 0x600. The core clock is
GCC_BLSP1_QUP1_I2C_APPS_CLK. GCC_BLSP1_QUP2_I2C_APPS_CLK is
used by the second i2c.
Fixes: e76b4284b520ba3 ("qcom: ipq4019: add i2c node to ipq4019 SoC and DK01 device tree")
Signed-off-by: Christian Lamparter <chunkeey(a)googlemail.com>
Signed-off-by: Andy Gross <andy.gross(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -154,10 +154,10 @@
i2c_0: i2c@78b7000 {
compatible = "qcom,i2c-qup-v2.2.1";
- reg = <0x78b7000 0x6000>;
+ reg = <0x78b7000 0x600>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
- <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+ <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>;
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
Patches currently in stable-queue which might be from chunkeey(a)googlemail.com are
queue-4.9/net-emac-fix-reset-timeout-with-ar8035-phy.patch
queue-4.9/arm-dts-qcom-ipq4019-fix-i2c_0-node.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: rockchip: fix rk322x i2s1 pinctrl error
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-rockchip-fix-rk322x-i2s1-pinctrl-error.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Sugar Zhang <sugar.zhang(a)rock-chips.com>
Date: Wed, 17 May 2017 17:52:24 +0800
Subject: ARM: dts: rockchip: fix rk322x i2s1 pinctrl error
From: Sugar Zhang <sugar.zhang(a)rock-chips.com>
[ Upstream commit 9d420e9b4140f8938ad6aa0d29e2428a2af6122b ]
Refer to Chapter 5.3.2 of rk3229 TRM, we can see that GPIO1A[2,4,5]
using RK_FUNC_2 not RK_FUNC_1. This patch fixes it.
Signed-off-by: Sugar Zhang <sugar.zhang(a)rock-chips.com>
Signed-off-by: Frank Wang <frank.wang(a)rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/rk322x.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -617,9 +617,9 @@
<0 12 RK_FUNC_1 &pcfg_pull_none>,
<0 13 RK_FUNC_1 &pcfg_pull_none>,
<0 14 RK_FUNC_1 &pcfg_pull_none>,
- <1 2 RK_FUNC_1 &pcfg_pull_none>,
- <1 4 RK_FUNC_1 &pcfg_pull_none>,
- <1 5 RK_FUNC_1 &pcfg_pull_none>;
+ <1 2 RK_FUNC_2 &pcfg_pull_none>,
+ <1 4 RK_FUNC_2 &pcfg_pull_none>,
+ <1 5 RK_FUNC_2 &pcfg_pull_none>;
};
};
Patches currently in stable-queue which might be from sugar.zhang(a)rock-chips.com are
queue-4.9/arm-dts-rockchip-fix-rk322x-i2s1-pinctrl-error.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx53-qsrb: Pulldown PMIC IRQ pin
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Wed, 12 Apr 2017 18:31:18 -0300
Subject: ARM: dts: imx53-qsrb: Pulldown PMIC IRQ pin
From: Fabio Estevam <fabio.estevam(a)nxp.com>
[ Upstream commit 2fe4bff3516924a37e083e3211364abe59db1161 ]
Currently the following errors are seen:
[ 14.015056] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.321093] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.411681] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.456281] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 30.527106] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 36.596900] mc13xxx 0-0008: Failed to read IRQ status: -6
Also when reading the interrupts via 'cat /proc/interrupts' the
PMIC GPIO interrupt counter does not stop increasing.
The reason for the storm of interrupts is that the PUS field of
register IOMUXC_SW_PAD_CTL_PAD_CSI0_DAT5 is currently configured as:
10 : 100k pullup
and the PMIC interrupt is being registered as IRQ_TYPE_LEVEL_HIGH type,
which is the correct type as per the MC34708 datasheet.
Use the default power on value for the IOMUX, which sets PUS field as:
00: 360k pull down
This prevents the spurious PMIC interrupts from happening.
Commit e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level")
correctly described the irq type as IRQ_TYPE_LEVEL_HIGH, but
missed to update the IOMUX of the PMIC GPIO as pull down.
Fixes: e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level")
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx53-qsrb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/imx53-qsrb.dts
+++ b/arch/arm/boot/dts/imx53-qsrb.dts
@@ -23,7 +23,7 @@
imx53-qsrb {
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX53_PAD_CSI0_DAT5__GPIO5_23 0x1e4 /* IRQ */
+ MX53_PAD_CSI0_DAT5__GPIO5_23 0x1c4 /* IRQ */
>;
};
};
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.9/arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
queue-4.9/net-fec-add-a-fec_enet_clear_ethtool_stats-stub-for-config_m5272.patch
queue-4.9/arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
queue-4.9/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Date: Thu, 16 Nov 2017 13:15:26 +0100
Subject: ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
[ Upstream commit d5c7b4d5ac2237a6da7ced3adfe6b8bf769f8cc6 ]
Commit a22950c888e3 (mmc: sdhci-of-esdhc: add quirk
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for ls1021a) added logic to the driver to
enable the broken timeout val quirk for ls1021a, but did not add the
corresponding compatible string to the device tree, so it didn't really
have any effect. Fix that.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -146,7 +146,7 @@
};
esdhc: esdhc@1560000 {
- compatible = "fsl,esdhc";
+ compatible = "fsl,ls1021a-esdhc", "fsl,esdhc";
reg = <0x0 0x1560000 0x0 0x10000>;
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <0>;
Patches currently in stable-queue which might be from rasmus.villemoes(a)prevas.dk are
queue-4.9/arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx6qdl-wandboard: Fix audio channel swap
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Sun, 14 May 2017 11:50:50 -0300
Subject: ARM: dts: imx6qdl-wandboard: Fix audio channel swap
From: Fabio Estevam <fabio.estevam(a)nxp.com>
[ Upstream commit 79935915300c5eb88a0e94fa9148a7505c14a02a ]
When running a stress playback/stop loop test on a mx6wandboard channel
swaps can be noticed randomly.
Increasing the SGTL5000 LRCLK pad strength to its maximum value fixes
the issue, so add the 'lrclk-strength' property to avoid the audio
channel swaps.
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -88,6 +88,7 @@
clocks = <&clks IMX6QDL_CLK_CKO>;
VDDA-supply = <®_2p5v>;
VDDIO-supply = <®_3p3v>;
+ lrclk-strength = <3>;
};
};
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.9/arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
queue-4.9/net-fec-add-a-fec_enet_clear_ethtool_stats-stub-for-config_m5272.patch
queue-4.9/arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
queue-4.9/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: armadillo800eva: Split LCD mux and gpio
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-armadillo800eva-split-lcd-mux-and-gpio.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Apr 9 17:09:24 CEST 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Thu, 1 Jun 2017 12:27:00 +0200
Subject: ARM: dts: armadillo800eva: Split LCD mux and gpio
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 13132b3f44d3600983aceb7e9920b8ebb55a7cf8 ]
Configuration of the lcd0 pinmux group and GPIO hog for the external
GPIO mux are done using a single device node, causing the "output-high"
property to be applied to both. This will fail for the pinmux group,
but doesn't cause any harm, as the failure is ignored silently.
However, after "pinctrl: sh-pfc: propagate errors on group config", the
failure will become fatal, leading to a broken display:
sh-pfc e6050000.pin-controller: pin_config_group_set op failed for group 102
sh-pfc e6050000.pin-controller: Error applying setting, reverse things back
sh-pfc e6050000.pin-controller: failed to select default state
Move the GPIO hog to its own node to fix this.
Fixes: ffd2f9a5afb730b9 ("ARM: shmobile: armadillo800eva dts: Add pinctrl and gpio-hog for lcdc0")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -266,7 +266,9 @@
lcd0_pins: lcd0 {
groups = "lcd0_data24_0", "lcd0_lclk_1", "lcd0_sync";
function = "lcd0";
+ };
+ lcd0_mux {
/* DBGMD/LCDC0/FSIA MUX */
gpio-hog;
gpios = <176 0>;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/acpi-ec-fix-debugfs_create_-usage.patch
queue-4.9/serial-sh-sci-fix-race-condition-causing-garbage-during-shutdown.patch
queue-4.9/clk-renesas-rcar-gen2-fix-pll0-on-r-car-v2h-and-e2.patch
queue-4.9/sh_eth-use-platform-device-for-printing-before-register_netdev.patch
queue-4.9/arm-dts-armadillo800eva-split-lcd-mux-and-gpio.patch