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

[Linux-stable-mirror] Patch "arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA 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-dma-mapping-only-swizzle-dma-ops-for-iommu_domain_dma.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 Thu Nov 9 09:48:01 CET 2017 From: Will Deacon <will.deacon(a)arm.com> Date: Fri, 6 Jan 2017 10:49:12 +0000 Subject: arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA From: Will Deacon <will.deacon(a)arm.com> [ Upstream commit 4a8d8a14c0d08c2437cb80c05e88f6cc1ca3fb2c ] The arm64 DMA-mapping implementation sets the DMA ops to the IOMMU DMA ops if we detect that an IOMMU is present for the master and the DMA ranges are valid. In the case when the IOMMU domain for the device is not of type IOMMU_DOMAIN_DMA, then we have no business swizzling the ops, since we're not in control of the underlying address space. This patch leaves the DMA ops alone for masters attached to non-DMA IOMMU domains. 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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/mm/dma-mapping.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -836,14 +836,21 @@ static bool do_iommu_attach(struct devic * then the IOMMU core will have already configured a group for this * device, and allocated the default domain for that group. */ - if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) { - pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n", - dev_name(dev)); - return false; + if (!domain) + goto out_err; + + if (domain->type == IOMMU_DOMAIN_DMA) { + if (iommu_dma_init_domain(domain, dma_base, size, dev)) + goto out_err; + + dev->archdata.dma_ops = &iommu_dma_ops; } - dev->archdata.dma_ops = &iommu_dma_ops; return true; +out_err: + pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n", + dev_name(dev)); + return false; } static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops, Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.9/iommu-arm-smmu-v3-clear-prior-settings-when-updating-stes.patch queue-4.9/arm64-dma-mapping-only-swizzle-dma-ops-for-iommu_domain_dma.patch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 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-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.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 Thu Nov 9 09:48:01 CET 2017 From: Tony Lindgren <tony(a)atomide.com> Date: Fri, 20 Jan 2017 12:13:19 -0800 Subject: ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ] We have more than four uarts on some SoCs and that can cause noise with errors while booting. Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,7 @@ CONFIG_SERIO=m CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=6 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.9/arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: dts: STiH410-family: fix wrong parent clock frequency" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: STiH410-family: fix wrong parent clock frequency 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-stih410-family-fix-wrong-parent-clock-frequency.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 Thu Nov 9 09:48:01 CET 2017 From: Patrice Chotard <patrice.chotard(a)st.com> Date: Fri, 6 Jan 2017 14:30:21 +0100 Subject: ARM: dts: STiH410-family: fix wrong parent clock frequency From: Patrice Chotard <patrice.chotard(a)st.com> [ Upstream commit b9ec866d223f38eb0bf2a7c836e10031ee17f7af ] The clock parent was lower than child clock which is not correct. In some use case, it leads to division by zero. Signed-off-by: Gabriel Fernandez <gabriel.fernandez(a)st.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/stih410.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/stih410.dtsi +++ b/arch/arm/boot/dts/stih410.dtsi @@ -131,7 +131,7 @@ <&clk_s_d2_quadfs 0>; assigned-clock-rates = <297000000>, - <108000000>, + <297000000>, <0>, <400000000>, <400000000>; Patches currently in stable-queue which might be from patrice.chotard(a)st.com are queue-4.9/arm-dts-stih410-family-fix-wrong-parent-clock-frequency.patch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: dts: imx53-qsb-common: fix FEC pinmux config" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: imx53-qsb-common: fix FEC pinmux config 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-qsb-common-fix-fec-pinmux-config.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 Thu Nov 9 09:48:01 CET 2017 From: Patrick Bruenn <p.bruenn(a)beckhoff.com> Date: Wed, 25 Jan 2017 06:25:48 +0100 Subject: ARM: dts: imx53-qsb-common: fix FEC pinmux config From: Patrick Bruenn <p.bruenn(a)beckhoff.com> [ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ] The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us. But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too. Signed-off-by: Patrick Bruenn <p.bruenn(a)beckhoff.com> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi @@ -215,16 +215,16 @@ pinctrl_fec: fecgrp { fsl,pins = < - MX53_PAD_FEC_MDC__FEC_MDC 0x80000000 - MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000 - MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000 - MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000 - MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000 - MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000 - MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000 - MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000 - MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000 - MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000 + MX53_PAD_FEC_MDC__FEC_MDC 0x4 + MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc + MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180 + MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180 + MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180 + MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180 + MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180 + MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4 + MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4 + MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4 >; }; Patches currently in stable-queue which might be from p.bruenn(a)beckhoff.com are queue-4.9/arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] Patch "apparmor: fix undefined reference to `aa_g_hash_policy'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled apparmor: fix undefined reference to `aa_g_hash_policy' 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: apparmor-fix-undefined-reference-to-aa_g_hash_policy.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 Thu Nov 9 09:48:01 CET 2017 From: John Johansen <john.johansen(a)canonical.com> Date: Mon, 16 Jan 2017 13:21:27 -0800 Subject: apparmor: fix undefined reference to `aa_g_hash_policy' From: John Johansen <john.johansen(a)canonical.com> [ Upstream commit 3ccb76c5dfe0d25c1d0168d5b726d0b43d19a485 ] The kernel build bot turned up a bad config combination when CONFIG_SECURITY_APPARMOR is y and CONFIG_SECURITY_APPARMOR_HASH is n, resulting in the build error security/built-in.o: In function `aa_unpack': (.text+0x841e2): undefined reference to `aa_g_hash_policy' Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -671,9 +671,9 @@ enum profile_mode aa_g_profile_mode = AP module_param_call(mode, param_set_mode, param_get_mode, &aa_g_profile_mode, S_IRUSR | S_IWUSR); -#ifdef CONFIG_SECURITY_APPARMOR_HASH /* whether policy verification hashing is enabled */ bool aa_g_hash_policy = IS_ENABLED(CONFIG_SECURITY_APPARMOR_HASH_DEFAULT); +#ifdef CONFIG_SECURITY_APPARMOR_HASH module_param_named(hash_policy, aa_g_hash_policy, aabool, S_IRUSR | S_IWUSR); #endif Patches currently in stable-queue which might be from john.johansen(a)canonical.com are queue-4.9/apparmor-fix-undefined-reference-to-aa_g_hash_policy.patch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] adv7604: Initialize drive strength to default when using DT" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] adv7604: Initialize drive strength to default when using DT 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: adv7604-initialize-drive-strength-to-default-when-using-dt.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 Thu Nov 9 09:48:01 CET 2017 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 29 Nov 2016 09:23:48 -0200 Subject: [media] adv7604: Initialize drive strength to default when using DT From: Lars-Peter Clausen <lars(a)metafoo.de> [ Upstream commit da8892d410db224d9a24104529794e6e37e0c100 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/i2c/adv7604.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -3118,6 +3118,9 @@ static int adv76xx_parse_dt(struct adv76 state->pdata.blank_data = 1; state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0; state->pdata.bus_order = ADV7604_BUS_ORDER_RGB; + state->pdata.dr_str_data = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_clk = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_sync = ADV76XX_DR_STR_MEDIUM_HIGH; return 0; } Patches currently in stable-queue which might be from lars(a)metafoo.de are queue-4.9/adv7604-initialize-drive-strength-to-default-when-using-dt.patch

6 years, 12 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Daniel Vetter

On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote: > Ville Syrjälä <ville.syrjala(a)linux.intel.com> writes: > > > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > >> Ville Syrjala <ville.syrjala(a)linux.intel.com> writes: > >> > >> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > >> > > >> > Apparently some sinks look at the YQ bits even when receiving RGB, > >> > and they get somehow confused when they see a non-zero YQ value. > >> > So we can't just blindly follow CEA-861-F and set YQ to match the > >> > RGB range. > >> > > >> > Unfortunately there is no good way to tell whether the sink > >> > designer claims to have read CEA-861-F. The CEA extension block > >> > revision number has generally been stuck at 3 since forever, > >> > and even a very recently manufactured sink might be based on > >> > an old design so the manufacturing date doesn't seem like > >> > something we can use. In lieu of better information let's > >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is > >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. > >> > > >> > The alternative would of course be to always set YQ=0. And if > >> > we ever encounter a HDMI 2.0+ sink with this bug that's what > >> > we'll probably have to do. > >> > >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4 > >> source? > > > > As long as you stick to < 340 MHz modes you shouldn't have to do > > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features. > > > > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up > > to bridges/encoders to filter out most things that aren't supported? > > I had a patch for that at > https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run > into trouble with 4k monitors. Ack on the clock limiting patch, silly that it's stuck. No idea about CEC, better for Hans/Boris I guess. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] [PATCH] ALSA: hda - fix headset mic problem for Dell machines with alc274

by Hui Wang

Confirmed with Kailang of Realtek, the pin 0x19 is for Headset Mic, and the pin 0x1a is for Headphone Mic, he suggested to apply ALC269_FIXUP_DELL1_MIC_NO_PRESENCE to fix this problem. And we verified applying this FIXUP can fix this problem. Cc: <stable(a)vger.kernel.org> Cc: Kailang Yang <kailang(a)realtek.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9b77d43..db1a376 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6568,6 +6568,11 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { {0x14, 0x90170110}, {0x1b, 0x90a70130}, {0x21, 0x03211020}), + SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x13, 0xb8a61140}, + {0x16, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, {0x14, 0x90170110}, -- 2.7.4

6 years, 12 months

2
1
0 0

[Linux-stable-mirror] [PATCH 2/2] ARM: mm: dump: check hardware RO bit for LPAE

by Philip Derrin

When CONFIG_ARM_LPAE is set, the PMD dump relies on the software read-only bit to determine whether a page is writable. This concealed a bug which left the kernel text section writable (AP2=0) while marked read-only in the software bit. In a kernel with the AP2 bug, the dump looks like this: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M ro x SHD 0xc0600000-0xc0800000 2M ro NX SHD 0xc0800000-0xc4800000 64M RW NX SHD The fix is to check that the software and hardware bits are both set before displaying "ro". The dump then shows the true perms: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M RW x SHD 0xc0600000-0xc0800000 2M RW NX SHD 0xc0800000-0xc4800000 64M RW NX SHD Fixes: ded947798469 ("ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE") Signed-off-by: Philip Derrin <philip(a)cog.systems> Tested-by: Neil Dick <neil(a)cog.systems> Cc: stable(a)vger.kernel.org --- arch/arm/mm/dump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c index 35ff45470dbf..fc3b44028cfb 100644 --- a/arch/arm/mm/dump.c +++ b/arch/arm/mm/dump.c @@ -129,8 +129,8 @@ static const struct prot_bits section_bits[] = { .val = PMD_SECT_USER, .set = "USR", }, { - .mask = L_PMD_SECT_RDONLY, - .val = L_PMD_SECT_RDONLY, + .mask = L_PMD_SECT_RDONLY | PMD_SECT_AP2, + .val = L_PMD_SECT_RDONLY | PMD_SECT_AP2, .set = "ro", .clear = "RW", #elif __LINUX_ARM_ARCH__ >= 6 -- 2.15.0

6 years, 12 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] ARM: mm: make STRICT_KERNEL_RWX effective for LPAE

by Philip Derrin

Currently, for ARM kernels with CONFIG_ARM_LPAE and CONFIG_STRICT_KERNEL_RWX enabled, the 2MiB pages mapping the kernel code and rodata are writable. They are marked read-only in a software bit (L_PMD_SECT_RDONLY) but the hardware read-only bit is not set (PMD_SECT_AP2). For user mappings, the logic that propagates the software bit to the hardware bit is in set_pmd_at(); but for the kernel, section_update() writes the PMDs directly, skipping this logic. The fix is to set PMD_SECT_AP2 for read-only sections in section_update(), at the same time as L_PMD_SECT_RDONLY. Fixes: 1e3479225acb ("ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error") Signed-off-by: Philip Derrin <philip(a)cog.systems> Reported-by: Neil Dick <neil(a)cog.systems> Tested-by: Neil Dick <neil(a)cog.systems> Tested-by: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org --- arch/arm/mm/init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index ad80548325fe..0f6d1537f330 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -639,8 +639,8 @@ static struct section_perm ro_perms[] = { .start = (unsigned long)_stext, .end = (unsigned long)__init_begin, #ifdef CONFIG_ARM_LPAE - .mask = ~L_PMD_SECT_RDONLY, - .prot = L_PMD_SECT_RDONLY, + .mask = ~(L_PMD_SECT_RDONLY | PMD_SECT_AP2), + .prot = L_PMD_SECT_RDONLY | PMD_SECT_AP2, #else .mask = ~(PMD_SECT_APX | PMD_SECT_AP_WRITE), .prot = PMD_SECT_APX | PMD_SECT_AP_WRITE, -- 2.15.0

6 years, 12 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror