This is a note to let you know that I've just added the patch titled
dt-bindings: clockgen: Add compatible string for LS1012A
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:
dt-bindings-clockgen-add-compatible-string-for-ls1012a.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: Harninder Rai <harninder.rai(a)nxp.com>
Date: Wed, 9 Nov 2016 23:40:53 +0530
Subject: dt-bindings: clockgen: Add compatible string for LS1012A
From: Harninder Rai <harninder.rai(a)nxp.com>
[ Upstream commit 73447f68d7b2bc1df870da88b0e21d2bc1afc025 ]
Signed-off-by: Harninder Rai <harninder.rai(a)nxp.com>
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya(a)nxp.com>
Acked-by: Rob Herring <robh(a)kernel.org>
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>
---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -31,6 +31,7 @@ Required properties:
* "fsl,t4240-clockgen"
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
+ * "fsl,ls1012a-clockgen"
* "fsl,ls1021a-clockgen"
Chassis-version clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
Patches currently in stable-queue which might be from harninder.rai(a)nxp.com are
queue-4.9/dt-bindings-clockgen-add-compatible-string-for-ls1012a.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: Add vendor prefix for LEGO
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:
dt-bindings-add-vendor-prefix-for-lego.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: David Lechner <david(a)lechnology.com>
Date: Fri, 13 Jan 2017 13:03:39 -0600
Subject: dt-bindings: Add vendor prefix for LEGO
From: David Lechner <david(a)lechnology.com>
[ Upstream commit 7dcc31e2e68a386a29070384b51683ece80982bf ]
Add a vendor prefix for LEGO Systems A/S
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -154,6 +154,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
+lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-4.9/dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/dt-bindings-add-vendor-prefix-for-lego.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
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:
dt-bindings-add-lego-mindstorms-ev3-compatible-specification.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: David Lechner <david(a)lechnology.com>
Date: Fri, 13 Jan 2017 13:03:40 -0600
Subject: dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
From: David Lechner <david(a)lechnology.com>
[ Upstream commit 21078ab174c99885ca83a5c32db0d33b1617745e ]
This adds the board level device tree specification for LEGO MINDSTORMS EV3
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++
1 file changed, 4 insertions(+)
--- a/Documentation/devicetree/bindings/arm/davinci.txt
+++ b/Documentation/devicetree/bindings/arm/davinci.txt
@@ -13,6 +13,10 @@ EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
+LEGO MINDSTORMS EV3 (AM1808 based)
+Required root node properties:
+ - compatible = "lego,ev3", "ti,da850";
+
Generic DaVinci Boards
----------------------
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-4.9/dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/dt-bindings-add-vendor-prefix-for-lego.patch
This is a note to let you know that I've just added the patch titled
drm: mali-dp: fix Lx_CONTROL register fields clobber
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:
drm-mali-dp-fix-lx_control-register-fields-clobber.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: Mihail Atanassov <mihail.atanassov(a)arm.com>
Date: Fri, 23 Dec 2016 09:57:20 +0000
Subject: drm: mali-dp: fix Lx_CONTROL register fields clobber
From: Mihail Atanassov <mihail.atanassov(a)arm.com>
[ Upstream commit c7ffa59cf03c38b91d6ef01e42c1b52fd7a4f285 ]
When updating the rotation fields, one of the assignments zeroes out the
rest of the register fields, which include settings for chroma siting,
inverse gamma, AMBA AXI caching, and alpha blending.
Signed-off-by: Mihail Atanassov <mihail.atanassov(a)arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/arm/malidp_planes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -182,7 +182,8 @@ static void malidp_de_plane_update(struc
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
- val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << LAYER_ROT_OFFSET;
+ val |= ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
+ LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
val |= LAYER_H_FLIP;
if (plane->state->rotation & DRM_REFLECT_Y)
Patches currently in stable-queue which might be from mihail.atanassov(a)arm.com are
queue-4.9/drm-mali-dp-fix-lx_control-register-fields-clobber.patch
This is a note to let you know that I've just added the patch titled
drm: drm_minor_register(): Clean up debugfs on failure
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:
drm-drm_minor_register-clean-up-debugfs-on-failure.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: Noralf Trønnes <noralf(a)tronnes.org>
Date: Thu, 26 Jan 2017 23:56:04 +0100
Subject: drm: drm_minor_register(): Clean up debugfs on failure
From: Noralf Trønnes <noralf(a)tronnes.org>
[ Upstream commit a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ]
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -218,7 +218,7 @@ static int drm_minor_register(struct drm
ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
if (ret) {
DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
- return ret;
+ goto err_debugfs;
}
ret = device_add(minor->kdev);
Patches currently in stable-queue which might be from noralf(a)tronnes.org are
queue-4.9/drm-drm_minor_register-clean-up-debugfs-on-failure.patch
This is a note to let you know that I've just added the patch titled
cxl: Force psl data-cache flush during device shutdown
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:
cxl-force-psl-data-cache-flush-during-device-shutdown.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: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Date: Wed, 4 Jan 2017 11:48:52 +0530
Subject: cxl: Force psl data-cache flush during device shutdown
From: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
[ Upstream commit d7b1946c7925a270062b2e0718aa57b42ba619c0 ]
This change adds a force psl data cache flush during device shutdown
callback. This should reduce a possibility of psl holding a dirty
cache line while the CAPP is being reinitialized, which may result in
a UE [load/store] machine check error.
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/cxl/pci.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1620,6 +1620,9 @@ static void cxl_pci_remove_adapter(struc
cxl_sysfs_adapter_remove(adapter);
cxl_debugfs_adapter_remove(adapter);
+ /* Flush adapter datacache as its about to be removed */
+ cxl_data_cache_flush(adapter);
+
cxl_deconfigure_adapter(adapter);
device_unregister(&adapter->dev);
Patches currently in stable-queue which might be from vaibhav(a)linux.vnet.ibm.com are
queue-4.9/cxl-force-psl-data-cache-flush-during-device-shutdown.patch
This is a note to let you know that I've just added the patch titled
crypto: vmx - disable preemption to enable vsx in aes_ctr.c
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:
crypto-vmx-disable-preemption-to-enable-vsx-in-aes_ctr.c.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: Li Zhong <zhong(a)linux.vnet.ibm.com>
Date: Fri, 20 Jan 2017 16:35:33 +0800
Subject: crypto: vmx - disable preemption to enable vsx in aes_ctr.c
From: Li Zhong <zhong(a)linux.vnet.ibm.com>
[ Upstream commit 7dede913fc2ab9c0d3bff3a49e26fa9e858b0c13 ]
Some preemptible check warnings were reported from enable_kernel_vsx(). This
patch disables preemption in aes_ctr.c before enabling vsx, and they are now
consistent with other files in the same directory.
Signed-off-by: Li Zhong <zhong(a)linux.vnet.ibm.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>
---
drivers/crypto/vmx/aes_ctr.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -80,11 +80,13 @@ static int p8_aes_ctr_setkey(struct cryp
int ret;
struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
return ret;
@@ -99,11 +101,13 @@ static void p8_aes_ctr_final(struct p8_a
u8 *dst = walk->dst.virt.addr;
unsigned int nbytes = walk->nbytes;
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
aes_p8_encrypt(ctrblk, keystream, &ctx->enc_key);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbytes);
@@ -132,6 +136,7 @@ static int p8_aes_ctr_crypt(struct blkci
blkcipher_walk_init(&walk, dst, src, nbytes);
ret = blkcipher_walk_virt_block(desc, &walk, AES_BLOCK_SIZE);
while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr,
@@ -143,6 +148,7 @@ static int p8_aes_ctr_crypt(struct blkci
walk.iv);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
/* We need to update IV mostly for last bytes/round */
inc = (nbytes & AES_BLOCK_MASK) / AES_BLOCK_SIZE;
Patches currently in stable-queue which might be from zhong(a)linux.vnet.ibm.com are
queue-4.9/crypto-vmx-disable-preemption-to-enable-vsx-in-aes_ctr.c.patch
queue-4.9/kvm-ppc-book-3s-xics-correct-the-real-mode-icp-rejecting-counter.patch
This is a note to let you know that I've just added the patch titled
clk: samsung: exynos5433: Add IDs for PHYCLK_MIPIDPHY0_* clocks
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:
clk-samsung-exynos5433-add-ids-for-phyclk_mipidphy0_-clocks.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: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Thu, 26 Jan 2017 13:37:52 +0100
Subject: clk: samsung: exynos5433: Add IDs for PHYCLK_MIPIDPHY0_* clocks
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
[ Upstream commit 5ccb58968bf7f46dbd128df88f71838a5a9750b8 ]
Add missing identifiers for phyclk_mipidphy0_bitclkdiv8_phy and
phyclk_mipidphy0_rxclkesc0_phy clocks. Access to those clocks is needed
to setup initial clock configuration for display subsystem in device tree
in order to avoid dependency on the configuration left by the bootloader.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Acked-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Acked-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/samsung/clk-exynos5433.c | 6 ++++--
include/dt-bindings/clock/exynos5433.h | 5 ++++-
2 files changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -2559,8 +2559,10 @@ static const struct samsung_fixed_rate_c
FRATE(0, "phyclk_mipidphy1_bitclkdiv8_phy", NULL, 0, 188000000),
FRATE(0, "phyclk_mipidphy1_rxclkesc0_phy", NULL, 0, 100000000),
/* PHY clocks from MIPI_DPHY0 */
- FRATE(0, "phyclk_mipidphy0_bitclkdiv8_phy", NULL, 0, 188000000),
- FRATE(0, "phyclk_mipidphy0_rxclkesc0_phy", NULL, 0, 100000000),
+ FRATE(CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8_PHY, "phyclk_mipidphy0_bitclkdiv8_phy",
+ NULL, 0, 188000000),
+ FRATE(CLK_PHYCLK_MIPIDPHY0_RXCLKESC0_PHY, "phyclk_mipidphy0_rxclkesc0_phy",
+ NULL, 0, 100000000),
/* PHY clocks from HDMI_PHY */
FRATE(CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY, "phyclk_hdmiphy_tmds_clko_phy",
NULL, 0, 300000000),
--- a/include/dt-bindings/clock/exynos5433.h
+++ b/include/dt-bindings/clock/exynos5433.h
@@ -771,7 +771,10 @@
#define CLK_PCLK_DECON 113
-#define DISP_NR_CLK 114
+#define CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8_PHY 114
+#define CLK_PHYCLK_MIPIDPHY0_RXCLKESC0_PHY 115
+
+#define DISP_NR_CLK 116
/* CMU_AUD */
#define CLK_MOUT_AUD_PLL_USER 1
Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are
queue-4.9/clk-samsung-exynos5433-add-ids-for-phyclk_mipidphy0_-clocks.patch
This is a note to let you know that I've just added the patch titled
clk: mvebu: adjust AP806 CPU clock frequencies to production chip
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:
clk-mvebu-adjust-ap806-cpu-clock-frequencies-to-production-chip.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: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Date: Thu, 22 Dec 2016 13:08:14 +0100
Subject: clk: mvebu: adjust AP806 CPU clock frequencies to production chip
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
[ Upstream commit 0c70ffc5f300e7c3a1a76ca0530860574afc890b ]
This commit adjusts the list of possible "Sample At Reset" values that
define the CPU clock frequency of the AP806 (part of Marvell Armada
7K/8K) to the values that have been validated with the production
chip. Earlier values were preliminary.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/mvebu/ap806-system-controller.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
--- a/drivers/clk/mvebu/ap806-system-controller.c
+++ b/drivers/clk/mvebu/ap806-system-controller.c
@@ -55,21 +55,39 @@ static int ap806_syscon_clk_probe(struct
freq_mode = reg & AP806_SAR_CLKFREQ_MODE_MASK;
switch (freq_mode) {
- case 0x0 ... 0x5:
+ case 0x0:
+ case 0x1:
cpuclk_freq = 2000;
break;
- case 0x6 ... 0xB:
+ case 0x6:
+ case 0x7:
cpuclk_freq = 1800;
break;
- case 0xC ... 0x11:
+ case 0x4:
+ case 0xB:
+ case 0xD:
cpuclk_freq = 1600;
break;
- case 0x12 ... 0x16:
+ case 0x1a:
cpuclk_freq = 1400;
break;
- case 0x17 ... 0x19:
+ case 0x14:
+ case 0x17:
cpuclk_freq = 1300;
break;
+ case 0x19:
+ cpuclk_freq = 1200;
+ break;
+ case 0x13:
+ case 0x1d:
+ cpuclk_freq = 1000;
+ break;
+ case 0x1c:
+ cpuclk_freq = 800;
+ break;
+ case 0x1b:
+ cpuclk_freq = 600;
+ break;
default:
dev_err(&pdev->dev, "invalid SAR value\n");
return -EINVAL;
Patches currently in stable-queue which might be from thomas.petazzoni(a)free-electrons.com are
queue-4.9/clk-mvebu-adjust-ap806-cpu-clock-frequencies-to-production-chip.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: setup wiphy bands after registering it first
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:
brcmfmac-setup-wiphy-bands-after-registering-it-first.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: Rafał Miłecki <rafal(a)milecki.pl>
Date: Sat, 7 Jan 2017 21:36:05 +0100
Subject: brcmfmac: setup wiphy bands after registering it first
From: Rafał Miłecki <rafal(a)milecki.pl>
[ Upstream commit ab99063f873749b3c3b1e5d44038559883465e74 ]
During bands setup we disable all channels that firmware doesn't support
in the current regulatory setup. If we do this before wiphy_register
it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
to the orig_flags which is supposed to be persistent. We don't want this
as regulatory change may result in enabling some channels. We shouldn't
mess with orig_flags then (by changing them or ignoring them) so it's
better to just take care of their proper values.
This patch cleanups code a bit (by taking orig_flags more seriously) and
allows further improvements like disabling really unavailable channels.
We will need that e.g. if some frequencies should be disabled for good
due to hardware setup (design).
Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel(a)broadcom.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6572,8 +6572,7 @@ static int brcmf_setup_wiphy(struct wiph
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
- err = brcmf_setup_wiphybands(wiphy);
- return err;
+ return 0;
}
static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
@@ -6938,6 +6937,12 @@ struct brcmf_cfg80211_info *brcmf_cfg802
goto priv_out;
}
+ err = brcmf_setup_wiphybands(wiphy);
+ if (err) {
+ brcmf_err("Setting wiphy bands failed (%d)\n", err);
+ goto wiphy_unreg_out;
+ }
+
/* If cfg80211 didn't disable 40MHz HT CAP in wiphy_register(),
* setup 40MHz in 2GHz band and enable OBSS scanning.
*/
Patches currently in stable-queue which might be from rafal(a)milecki.pl are
queue-4.9/brcmfmac-setup-wiphy-bands-after-registering-it-first.patch
This is a note to let you know that I've just added the patch titled
ASoC: sunxi: Add bindings for sun8i to SPDIF
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:
asoc-sunxi-add-bindings-for-sun8i-to-spdif.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: Marcus Cooper <codekipper(a)gmail.com>
Date: Thu, 19 Jan 2017 20:52:57 +0100
Subject: ASoC: sunxi: Add bindings for sun8i to SPDIF
From: Marcus Cooper <codekipper(a)gmail.com>
[ Upstream commit cb5c978f9a56c459d5f13901efcfe44b97c4182d ]
The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the
transmit fifo is at a different address.
Signed-off-by: Marcus Cooper <codekipper(a)gmail.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 1 +
1 file changed, 1 insertion(+)
--- a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible : should be one of the following:
- "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
- "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC
+ - "allwinner,sun8i-h3-spdif": for the Allwinner H3 SoC
- reg : Offset and length of the register set for the device.
Patches currently in stable-queue which might be from codekipper(a)gmail.com are
queue-4.9/asoc-sunxi-add-bindings-for-sun8i-to-spdif.patch
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
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
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
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
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
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
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
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
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
On Wed, Nov 08, 2017 at 11:11:11PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 10:48:14PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote:
>
>> >expose problems if we start using it. If you look at the history of the
>> >driver there's some quirks were added later on for example, and I didn't
>> >check the DMA controller drivers or anything and obviously can't see any
>> >out of tree code users may have.
>
>> I'm considering these commits to be on the safer side because they're
>> much older than the ones Greg usually grabs. There were no upstream
>> fixes to this commit for 10 months now, and given the code changes
>> upstream in that subsystem, this patch seemed to be safe to backport.
>
>Like I say I'm seeing some potentially relevant variant handling added
>later and you also have to consider the DMA drivers it might be used
>with (imx-dma looks safe but perhaps there's other things, never mind
>out of tree code). It just doesn't feel good.
>
>We have also had problems in the past with SPI performance enhancements
>exposing exising problems elsewhere though not so much with this sort of
>area so I'm less worried about that.
Sure, I'll drop it. Thanks!
--
Thanks,
Sasha
On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 09:39:11PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >This seems like an optimization not a bug fix...
>
>> Hm, is it? I read it as "DMA is not being used at all even though we
>> thought we're using it".
>
>Yes, that's how I read it too.
>
>> Yes, the impact is "just" performance, but doesn't it result in quite
>> a significat impact?
>
>Only about double according to the initial commit adding DMA support
>which is frankly a bit disappointing although yeah, it's a big win. My
>worry is that if there's a problem with DMA on some device for which a
>fix wasn't backported (or where we're using a fallback) this could
>expose problems if we start using it. If you look at the history of the
>driver there's some quirks were added later on for example, and I didn't
>check the DMA controller drivers or anything and obviously can't see any
>out of tree code users may have.
>
>*Probably* it doesn't break anything but since it's not fixing anything
>and the risk is data corruption I'd be much more comfortable with a more
>thorough risk analysis.
I'm considering these commits to be on the safer side because they're
much older than the ones Greg usually grabs. There were no upstream
fixes to this commit for 10 months now, and given the code changes
upstream in that subsystem, this patch seemed to be safe to backport.
--
Thanks,
Sasha
On Wed, Nov 08, 2017 at 08:57:52PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> From: Jiada Wang <jiada_wang(a)mentor.com>
>>
>> [ Upstream commit 66459c5a50a787c474b734b586328f7111ab6df0 ]
>>
>> Previously DMA watermark level is configured to fifosize/2,
>> DMA mode can be used only when transfer length can be divided
>> by 'watermark level * bpw', which makes DMA mode not pratical.
>>
>> This patch adjusts watermark level to largest number (no bigger
>> than fifosize/2) which can divide 'tranfer length / bpw' for
>> each transfer.
>
>This seems like an optimization not a bug fix...
Hm, is it? I read it as "DMA is not being used at all even though we
thought we're using it".
Yes, the impact is "just" performance, but doesn't it result in quite
a significat impact?
--
Thanks,
Sasha
Since its introduction, the codec had an inversion of the left and right
channels. It turned out to be pretty simple as it appears that the codec
doesn't have the same polarity on the LRCK signal than the I2S block.
Fix this by inverting our bit value for the LRCK inversion.
Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
---
sound/soc/sunxi/sun8i-codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 522546e6b153..c8dcb1502d74 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -200,7 +200,7 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV),
- value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
+ !value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
/* DAI format */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
--
2.14.3
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ]
extcon-palmas must be child of palmas and expects parent's
drvdata to be valid. Check for non NULL parent drvdata and
fail if it is NULL. Not doing so will result in a NULL
pointer dereference later in the probe() parent drvdata
is NULL (e.g. misplaced extcon-palmas node in device tree).
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/extcon/extcon-palmas.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 230e1220ce48..1cee9f4909db 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -150,6 +150,11 @@ static int palmas_usb_probe(struct platform_device *pdev)
struct palmas_usb *palmas_usb;
int status;
+ if (!palmas) {
+ dev_err(&pdev->dev, "failed to get valid parent\n");
+ return -EINVAL;
+ }
+
palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
--
2.11.0
Eric Biggers <ebiggers3(a)gmail.com> wrote:
> On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
> largest permitted inputs (16384 bits), the kernel spends 10+ seconds
> doing modular exponentiation in mpi_powm() without rescheduling. If all
> threads do it, it locks up the system. Moreover, it can cause
> rcu_sched-stall warnings.
Do you want this to go in immediately, or I should I push it to James for the
next merge window?
David
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?
>
> That said, as far as vc4, this patch is
>
> Acked-by: Eric Anholt <eric(a)anholt.net>
Ta.
--
Ville Syrjälä
Intel OTC
The current code had the condition backward when checking if the codec
should be running in slave or master mode.
Fix it, and make the comment a bit more readable.
Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
---
sound/soc/sunxi/sun8i-codec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index abfb710df7cb..038107baf414 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -170,11 +170,11 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
/* clock masters */
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
- case SND_SOC_DAIFMT_CBS_CFS: /* DAI Slave */
- value = 0x0; /* Codec Master */
+ case SND_SOC_DAIFMT_CBS_CFS: /* Codec slave, DAI master */
+ value = 0x1;
break;
- case SND_SOC_DAIFMT_CBM_CFM: /* DAI Master */
- value = 0x1; /* Codec Slave */
+ case SND_SOC_DAIFMT_CBM_CFM: /* Codec Master, DAI slave */
+ value = 0x0;
break;
default:
return -EINVAL;
--
2.14.3
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.
What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.
This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...
v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
be done before all planes might get disabled.
Cc: stable(a)vger.kernel.org
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes(a)intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: Oscar Mateo <oscar.mateo(a)intel.com>
Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com>
Reported-by: Mark Janes <mark.a.janes(a)intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++--
drivers/gpu/drm/i915/intel_pm.c | 44 +++++++++++++++---------------------
2 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 737de251d0f8..8174392acc18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3676,6 +3676,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
intel_modeset_init_hw(dev);
+ intel_init_clock_gating(dev_priv);
spin_lock_irq(&dev_priv->irq_lock);
if (dev_priv->display.hpd_irq_setup)
@@ -14365,8 +14366,6 @@ void intel_modeset_init_hw(struct drm_device *dev)
intel_update_cdclk(dev_priv);
intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw;
-
- intel_init_clock_gating(dev_priv);
}
/*
@@ -15079,6 +15078,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
struct intel_encoder *encoder;
int i;
+ if (IS_HASWELL(dev_priv)) {
+ /*
+ * WaRsPkgCStateDisplayPMReq:hsw
+ * System hang if this isn't done before disabling all planes!
+ */
+ I915_WRITE(CHICKEN_PAR1_1,
+ I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
+ }
+
intel_modeset_readout_hw_state(dev);
/* HW state is read out, now we need to sanitize this mess. */
@@ -15176,6 +15184,8 @@ void intel_modeset_gem_init(struct drm_device *dev)
intel_init_gt_powersave(dev_priv);
+ intel_init_clock_gating(dev_priv);
+
intel_setup_overlay(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 07118c0b69d3..b712ee30a06c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5754,12 +5754,30 @@ void vlv_wm_sanitize(struct drm_i915_private *dev_priv)
mutex_unlock(&dev_priv->wm.wm_mutex);
}
+/*
+ * FIXME should probably kill this and improve
+ * the real watermark readout/sanitation instead
+ */
+static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN);
+ I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN);
+ I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN);
+
+ /*
+ * Don't touch WM1S_LP_EN here.
+ * Doing so could cause underruns.
+ */
+}
+
void ilk_wm_get_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct ilk_wm_values *hw = &dev_priv->wm.hw;
struct drm_crtc *crtc;
+ ilk_init_lp_watermarks(dev_priv);
+
for_each_crtc(dev, crtc)
ilk_pipe_wm_get_hw_state(crtc);
@@ -8213,18 +8231,6 @@ static void g4x_disable_trickle_feed(struct drm_i915_private *dev_priv)
}
}
-static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv)
-{
- I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN);
- I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN);
- I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN);
-
- /*
- * Don't touch WM1S_LP_EN here.
- * Doing so could cause underruns.
- */
-}
-
static void ilk_init_clock_gating(struct drm_i915_private *dev_priv)
{
uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
@@ -8258,8 +8264,6 @@ static void ilk_init_clock_gating(struct drm_i915_private *dev_priv)
(I915_READ(DISP_ARB_CTL) |
DISP_FBC_WM_DIS));
- ilk_init_lp_watermarks(dev_priv);
-
/*
* Based on the document from hardware guys the following bits
* should be set unconditionally in order to enable FBC.
@@ -8372,8 +8376,6 @@ static void gen6_init_clock_gating(struct drm_i915_private *dev_priv)
I915_WRITE(GEN6_GT_MODE,
_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
- ilk_init_lp_watermarks(dev_priv);
-
I915_WRITE(CACHE_MODE_0,
_MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
@@ -8600,8 +8602,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv)
I915_GTT_PAGE_SIZE_2M);
enum pipe pipe;
- ilk_init_lp_watermarks(dev_priv);
-
/* WaSwitchSolVfFArbitrationPriority:bdw */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
@@ -8652,8 +8652,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv)
static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
{
- ilk_init_lp_watermarks(dev_priv);
-
/* L3 caching of data atomics doesn't work -- disable it. */
I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
I915_WRITE(HSW_ROW_CHICKEN3,
@@ -8697,10 +8695,6 @@ static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
/* WaSwitchSolVfFArbitrationPriority:hsw */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
- /* WaRsPkgCStateDisplayPMReq:hsw */
- I915_WRITE(CHICKEN_PAR1_1,
- I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
-
lpt_init_clock_gating(dev_priv);
}
@@ -8708,8 +8702,6 @@ static void ivb_init_clock_gating(struct drm_i915_private *dev_priv)
{
uint32_t snpcr;
- ilk_init_lp_watermarks(dev_priv);
-
I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
/* WaDisableEarlyCull:ivb */
--
2.13.6
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.
Cc: stable(a)vger.kernel.org
Cc: Jani Nikula <jani.nikula(a)intel.com>
Cc: Eric Anholt <eric(a)anholt.net>
Cc: Neil Kownacki <njkkow(a)gmail.com>
Reported-by: Neil Kownacki <njkkow(a)gmail.com>
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/drm_edid.c | 12 ++++++++++--
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
include/drm/drm_edid.h | 3 ++-
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..8567890f47a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4838,7 +4838,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable)
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink)
{
/*
* CEA-861:
@@ -4862,8 +4863,15 @@ drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
* YQ-field to match the RGB Quantization Range being transmitted
* (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
* set YQ=1) and the Sink shall ignore the YQ-field."
+ *
+ * Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused
+ * by non-zero YQ when receiving RGB. There doesn't seem to be any
+ * good way to tell which version of CEA-861 the sink supports, so
+ * we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based
+ * on on CEA-861-F.
*/
- if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
+ if (!is_hdmi2_sink ||
+ rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
frame->ycc_quantization_range =
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
else
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index fa1c793a21ef..2b23d3662eec 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -487,7 +487,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- intel_hdmi->rgb_quant_range_selectable);
+ intel_hdmi->rgb_quant_range_selectable,
+ is_hdmi2_sink);
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, &frame);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9a9a6b4acccf..d645df0c6d15 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -423,7 +423,8 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- vc4_encoder->rgb_range_selectable);
+ vc4_encoder->rgb_range_selectable,
+ false);
vc4_hdmi_write_infoframe(encoder, &frame);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 9e4e23524840..58ffb68efdc5 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -361,7 +361,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable);
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink);
/**
* drm_eld_mnl - Get ELD monitor name length in bytes.
--
2.13.6
There was a typo in the new version of put_tv32() that caused an unguarded
access of a user space pointer, and failed to return the correct result in
gettimeofday(), wait4(), usleep_thread() and old_adjtimex().
This fixes it to give the correct behavior again.
Cc: stable(a)vger.kernel.org
Fixes: 1cc6c4635e9f ("osf_sys.c: switch handling of timeval32/itimerval32 to copy_{to,from}_user()")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
v2: fix incorrect changelog description
---
arch/alpha/kernel/osf_sys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index ce3a675c0c4b..75a5c35a2067 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -964,8 +964,8 @@ static inline long
put_tv32(struct timeval32 __user *o, struct timeval *i)
{
return copy_to_user(o, &(struct timeval32){
- .tv_sec = o->tv_sec,
- .tv_usec = o->tv_usec},
+ .tv_sec = i->tv_sec,
+ .tv_usec = i->tv_usec},
sizeof(struct timeval32));
}
--
2.9.0
'cached_raw_freq' is used to get the next frequency quickly but should
always be in sync with sg_policy->next_freq. There is a case where it is
not and in such cases it should be reset to avoid switching to incorrect
frequencies.
Consider this case for example:
- policy->cur is 1.2 GHz (Max)
- New request comes for 780 MHz and we store that in cached_raw_freq.
- Based on 780 MHz, we calculate the effective frequency as 800 MHz.
- We then see the CPU wasn't idle recently and choose to keep the next
freq as 1.2 GHz.
- Now we have cached_raw_freq is 780 MHz and sg_policy->next_freq is 1.2
GHz.
- Now if the utilization doesn't change in then next request, then the
next target frequency will still be 780 MHz and it will match with
cached_raw_freq. But we will choose 1.2 GHz instead of 800 MHz here.
Change-Id: I71bd31a1b59d27c26c0b4885301e4ba6155c2c51
Cc: <stable(a)vger.kernel.org> # 4.12
Fixes: b7eaf1aab9f8 ("cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely")
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
kernel/sched/cpufreq_schedutil.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index ba0da243fdd8..2f52ec0f1539 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -282,8 +282,12 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
* Do not reduce the frequency if the CPU has not been idle
* recently, as the reduction is likely to be premature then.
*/
- if (busy && next_f < sg_policy->next_freq)
+ if (busy && next_f < sg_policy->next_freq) {
next_f = sg_policy->next_freq;
+
+ /* Reset cached freq as next_freq has changed */
+ sg_policy->cached_raw_freq = 0;
+ }
}
sugov_update_commit(sg_policy, time, next_f);
}
--
2.15.0.rc1.236.g92ea95045093
On Wed, Nov 8, 2017 at 12:06 AM, Rafael J. Wysocki <rjw(a)rjwysocki.net> wrote:
> On Tuesday, November 7, 2017 11:47:54 PM CET Rafael J. Wysocki wrote:
>> On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala
>> <ville.syrjala(a)linux.intel.com> wrote:
>> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>> >
>> > acpi_remove_pm_notifier() ends up calling flush_workqueue() while
>> > holding acpi_pm_notifier_lock, and that same lock is taken by
>> > by the work via acpi_pm_notify_handler(). This can deadlock.
>>
>> OK, good catch!
>>
>> [cut]
>>
>> >
>> > Cc: stable(a)vger.kernel.org
>> > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
>> > Cc: Len Brown <lenb(a)kernel.org>
>> > Cc: Peter Zijlstra <peterz(a)infradead.org>
>> > Cc: Tejun Heo <tj(a)kernel.org>
>> > Cc: Ingo Molnar <mingo(a)kernel.org>
>> > Fixes: c072530f391e ("ACPI / PM: Revork the handling of ACPI device wakeup notifications")
>> > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>> > ---
>> > drivers/acpi/device_pm.c | 21 ++++++++++++---------
>> > 1 file changed, 12 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
>> > index fbcc73f7a099..18af71057b44 100644
>> > --- a/drivers/acpi/device_pm.c
>> > +++ b/drivers/acpi/device_pm.c
>> > @@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable);
>> >
>> > #ifdef CONFIG_PM
>> > static DEFINE_MUTEX(acpi_pm_notifier_lock);
>> > +static DEFINE_MUTEX(acpi_pm_notifier_install_lock);
>> >
>> > void acpi_pm_wakeup_event(struct device *dev)
>> > {
>> > @@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev,
>> > if (!dev && !func)
>> > return AE_BAD_PARAMETER;
>> >
>> > - mutex_lock(&acpi_pm_notifier_lock);
>> > + mutex_lock(&acpi_pm_notifier_install_lock);
>> >
>> > if (adev->wakeup.flags.notifier_present)
>> > goto out;
>> >
>> > - adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
>> > - adev->wakeup.context.dev = dev;
>> > - adev->wakeup.context.func = func;
>> > -
>>
>> But this doesn't look good to me.
>>
>> notifier_present should be checked under acpi_pm_notifier_lock.
>>
>> Actually, acpi_install_notify_handler() itself need not be called
>> under the lock, because it does sufficient checks of its own.
>>
>> So say you do
>>
>> mutex_lock(&acpi_pm_notifier_lock);
>>
>> if (adev->wakeup.context.dev)
>> goto out;
>>
>> adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
>> adev->wakeup.context.dev = dev;
>> adev->wakeup.context.func = func;
>>
>> mutex_unlock(&acpi_pm_notifier_lock);
>>
>> > status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY,
>> > acpi_pm_notify_handler, NULL);
>> > if (ACPI_FAILURE(status))
>> > goto out;
>> >
>> > + mutex_lock(&acpi_pm_notifier_lock);
>>
>> And here you just set notifier_present under acpi_pm_notifier_lock.
>>
>> > + adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
>> > + adev->wakeup.context.dev = dev;
>> > + adev->wakeup.context.func = func;
>> > adev->wakeup.flags.notifier_present = true;
>> > + mutex_unlock(&acpi_pm_notifier_lock);
>> >
>> > out:
>> > - mutex_unlock(&acpi_pm_notifier_lock);
>> > + mutex_unlock(&acpi_pm_notifier_install_lock);
>> > return status;
>> > }
>>
>> Then on removal you can clear notifier_present first and drop the lock
>> around the acpi_remove_notify_handler() call and nothing bad will
>> happen.
>>
>> If you call acpi_add_pm_notifier() twice in parallel, the first
>> instance will set context.dev and the second one will see it set and
>> bail out. The first instance will then do the rest.
>>
>> If you call acpi_remove_pm_notifier() twice in a row, the first
>> instance will see notifier_present set and will clear it, so the
>> second one will see notifier_present unset and it will bail out.
>>
>> Now, if you call acpi_remove_pm_notifier() in parallel with
>> acpi_add_pm_notifier(), either the former will see notifier_present
>> unset and bail out, or the latter will see context.dev unset and bail
>> out.
>>
>> It doesn't look like the outer lock is needed, or have I missed anything?
>
> So something like the below (totally untested) should work too, shouldn't it?
There is a problem if a device is removed while acpi_add_pm_notifier()
is still in progress, in which case with my patch the
acpi_remove_pm_notifier() called from the removal path may bail out
prematurely (that doesn't seem likely to happen, but still I don't see
why it cannot happen), so I'll just use your patch. :-)
Thanks,
Rafael
Arnd Bergmann <arnd(a)arndb.de> wrote:
> We set rtlhal->last_suspend_sec to an uninitialized stack variable,
> but unfortunately gcc never warned about this, I only found it
> while working on another patch. I opened a gcc bug for this.
>
> Presumably the value of rtlhal->last_suspend_sec is not all that
> important, but it does get used, so we probably want the
> patch backported to stable kernels.
>
> Cc: stable(a)vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
> Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net>
3 patches applied to wireless-drivers-next.git, thanks.
3f2a162fab15 rtlwifi: fix uninitialized rtlhal->last_suspend_sec time
3c92d5517af8 rtlwifi: use ktime_get_real_seconds() for suspend time
ac978dc79a91 rtlwifi: drop unused ppsc->last_wakeup_time
--
https://patchwork.kernel.org/patch/10043505/https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc…
On Tue, Nov 7, 2017 at 11:47 PM, Rafael J. Wysocki <rafael(a)kernel.org> wrote:
> On Tue, Nov 7, 2017 at 10:08 PM, Ville Syrjala
> <ville.syrjala(a)linux.intel.com> wrote:
>> From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>>
>> acpi_remove_pm_notifier() ends up calling flush_workqueue() while
>> holding acpi_pm_notifier_lock, and that same lock is taken by
>> by the work via acpi_pm_notify_handler(). This can deadlock.
>
> OK, good catch!
>
> [cut]
>
>>
>> Cc: stable(a)vger.kernel.org
>> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
>> Cc: Len Brown <lenb(a)kernel.org>
>> Cc: Peter Zijlstra <peterz(a)infradead.org>
>> Cc: Tejun Heo <tj(a)kernel.org>
>> Cc: Ingo Molnar <mingo(a)kernel.org>
>> Fixes: c072530f391e ("ACPI / PM: Revork the handling of ACPI device wakeup notifications")
>> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>> ---
>> drivers/acpi/device_pm.c | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
>> index fbcc73f7a099..18af71057b44 100644
>> --- a/drivers/acpi/device_pm.c
>> +++ b/drivers/acpi/device_pm.c
>> @@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable);
>>
>> #ifdef CONFIG_PM
>> static DEFINE_MUTEX(acpi_pm_notifier_lock);
>> +static DEFINE_MUTEX(acpi_pm_notifier_install_lock);
>>
>> void acpi_pm_wakeup_event(struct device *dev)
>> {
>> @@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev,
>> if (!dev && !func)
>> return AE_BAD_PARAMETER;
>>
>> - mutex_lock(&acpi_pm_notifier_lock);
>> + mutex_lock(&acpi_pm_notifier_install_lock);
>>
>> if (adev->wakeup.flags.notifier_present)
>> goto out;
>>
>> - adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
>> - adev->wakeup.context.dev = dev;
>> - adev->wakeup.context.func = func;
>> -
>
> But this doesn't look good to me.
>
> notifier_present should be checked under acpi_pm_notifier_lock.
Well, not really, so the above is OK.
However, I still would prefer to avoid adding the outer lock.
Thanks,
Rafael
On 11/03/2017 11:56 PM, James Smart wrote:
> In test cases where an instance of the driver is detached and
> reattached, the driver will crash on reattachment. There is a
> compound if statement that will skip over the bar setup if
> the pci_resource_start call is not successful. The driver
> erroneously returns success to its bar setup in this scenario
> even though the bars aren't properly configured.
>
> Rework the offending code segment for proper initialization steps.
> If the pci_resource_start call fails, -ENOMEM is now returned.
>
> Sample stack:
>
> rport-5:0-10: blocked FC remote port time out: removing rport
> BUG: unable to handle kernel NULL pointer dereference at (null)
> ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
> ...
> ... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
> Call Trace:
> ... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc]
> ... ? __alloc_pages_nodemask+0x176/0x420
> ... ? __kmalloc+0x2e/0x230
> ... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc]
> ... ? mempool_alloc+0x69/0x170
> ... ? dma_generic_alloc_coherent+0x8f/0x140
> ... lpfc_sli_issue_mbox+0xf/0x20 [lpfc]
> ... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc]
> ... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc]
> ... lpfc_pci_probe_one+0x445/0x16f0 [lpfc]
> ... local_pci_probe+0x45/0xa0
> ... work_for_cpu_fn+0x14/0x20
> ... process_one_work+0x17a/0x440
>
> Cc: <stable(a)vger.kernel.org> # 4.12+
> Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
> Signed-off-by: James Smart <james.smart(a)broadcom.com>
> ---
> drivers/scsi/lpfc/lpfc_init.c | 84 ++++++++++++++++++++++++++-----------------
> 1 file changed, 51 insertions(+), 33 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare(a)suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
On Tue, Nov 07, 2017 at 04:55:36PM -0600, Tom Gall wrote:
>
> > On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.4.97 release.
> > There are 40 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Nov 8 09:44:42 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.97-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm. As per usual HiKey results held separate because it’s platform support is out of tree.
Thanks for letting me know, but howcome you all are not testing 4.13
releases?
thanks,
greg k-h
On Tue, Nov 07, 2017 at 04:49:07PM -0600, Tom Gall wrote:
>
> > On Nov 6, 2017, at 3:43 AM, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.9.61 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Nov 8 09:12:36 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.61-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from the Linaro test farm. Nothing out of the ordinary this time around.
You still need a '\n', or a decent editor/email client :)
Thanks for the test reports.
greg k-h