[PATCH 5.10 419/663] coresight: etm4x: Skip accessing TRCPDCR in save/restore
From: Suzuki K Poulose
[ Upstream commit df81b43802f43c0954a55e5d513e8750a1ab4d31 ]
When the ETM is affected by Qualcomm errata, modifying the
TRCPDCR could cause the system hang. Even though this is
taken care of during enable/disable ETM, the ETM state
save/restore could still access the TRCPDCR. Make sure
we skip the access during the save/restore.
Found by code inspection.
Link: https://lore.kernel.org/r/20210110224850.1880240-3-suzuki.poul...@arm.com
Fixes: 02510a5aa78d ("coresight: etm4x: Add support to skip trace unit power
up")
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Sai Prakash Ranjan
Cc: Tingwei Zhang
Tested-by: Sai Prakash Ranjan
Reviewed-by: Sai Prakash Ranjan
Signed-off-by: Suzuki K Poulose
Signed-off-by: Mathieu Poirier
Link:
https://lore.kernel.org/r/20210201181351.1475223-5-mathieu.poir...@linaro.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 95b54b0a36252..8be6fddbf 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1254,7 +1254,8 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
state->trcclaimset = readl(drvdata->base + TRCCLAIMCLR);
- state->trcpdcr = readl(drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up)
+ state->trcpdcr = readl(drvdata->base + TRCPDCR);
/* wait for TRCSTATR.IDLE to go up */
if (coresight_timeout(drvdata->base, TRCSTATR, TRCSTATR_IDLE_BIT, 1)) {
@@ -1272,9 +1273,9 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
* potentially save power on systems that respect the TRCPDCR_PU
* despite requesting software to save/restore state.
*/
- writel_relaxed((state->trcpdcr & ~TRCPDCR_PU),
- drvdata->base + TRCPDCR);
-
+ if (!drvdata->skip_power_up)
+ writel_relaxed((state->trcpdcr & ~TRCPDCR_PU),
+ drvdata->base + TRCPDCR);
out:
CS_LOCK(drvdata->base);
return ret;
@@ -1368,7 +1369,8 @@ static void etm4_cpu_restore(struct etmv4_drvdata
*drvdata)
writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
- writel_relaxed(state->trcpdcr, drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up)
+ writel_relaxed(state->trcpdcr, drvdata->base + TRCPDCR);
drvdata->state_needs_restore = false;
--
2.27.0
[PATCH 5.10 287/663] RDMA/rtrs-srv: Release lock before call into close_sess
From: Jack Wang
[ Upstream commit 99f0c3807973359bba8f37d9198eea59fe38c32a ]
In this error case, we don't need hold mutex to call close_sess.
Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link:
https://lore.kernel.org/r/20201217141915.56989-4-jinpu.w...@cloud.ionos.com
Signed-off-by: Jack Wang
Tested-by: Lutz Pogrell
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index ffc6fbb4baa5e..cc47a039e67d3 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1878,8 +1878,8 @@ reject_w_econnreset:
return rtrs_rdma_do_reject(cm_id, -ECONNRESET);
close_and_return_err:
- close_sess(sess);
mutex_unlock(>paths_mutex);
+ close_sess(sess);
return err;
}
--
2.27.0
[PATCH 5.10 045/663] arm64: dts: allwinner: H6: properly connect USB PHY to port 0
From: Andre Przywara
[ Upstream commit da2fb8457f71138d455cba82edec0d34f858e506 ]
In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
don't actually use it.
To avoid those issues, let's add this PHY link to the H6 .dtsi file.
After all PHY port 0 *is* connected to HCI0, so we should describe
it as this.
This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).
Fixes: eabb3d424b6d ("arm64: dts: allwinner: h6: add USB2-related device nodes")
Signed-off-by: Andre Przywara
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Link: https://lore.kernel.org/r/20210113152630.28810-3-andre.przyw...@arm.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 28c77d6872f64..0361f5f467093 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -667,6 +667,8 @@
< CLK_USB_OHCI0>;
resets = < RST_BUS_OHCI0>,
< RST_BUS_EHCI0>;
+ phys = < 0>;
+ phy-names = "usb";
status = "disabled";
};
@@ -677,6 +679,8 @@
clocks = < CLK_BUS_OHCI0>,
< CLK_USB_OHCI0>;
resets = < RST_BUS_OHCI0>;
+ phys = < 0>;
+ phy-names = "usb";
status = "disabled";
};
--
2.27.0
[PATCH 5.10 403/663] pwm: rockchip: Eliminate potential race condition when probing
From: Simon South
[ Upstream commit d21ba5d6217bd5a6a696678385906ed1994b380b ]
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running
PWMs") introduced a potential race condition in rockchip_pwm_probe(): A
consumer could enable an inactive PWM, or disable a running one, between
rockchip_pwm_probe() registering the device via pwmchip_add() and checking
whether it is enabled (to determine whether it was started by a
bootloader). This could result in a device's PWM clock being either enabled
once more than necessary, potentially causing it to continue running when
no longer needed, or disabled once more than necessary, producing a warning
from the kernel.
Eliminate these possibilities by modifying rockchip_pwm_probe() so it
checks whether a device is enabled before registering it rather than after.
Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs")
Reported-by: Trent Piepho
Signed-off-by: Simon South
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/pwm/pwm-rockchip.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index ede027fbf2bb4..3b8da7b0091b1 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -289,6 +289,7 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
struct rockchip_pwm_chip *pc;
struct resource *r;
u32 enable_conf, ctrl;
+ bool enabled;
int ret, count;
id = of_match_device(rockchip_pwm_dt_ids, >dev);
@@ -351,6 +352,10 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
pc->chip.of_pwm_n_cells = 3;
}
+ enable_conf = pc->data->enable_conf;
+ ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
+ enabled = (ctrl & enable_conf) == enable_conf;
+
ret = pwmchip_add(>chip);
if (ret < 0) {
dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
@@ -358,9 +363,7 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
}
/* Keep the PWM clk enabled if the PWM appears to be up and running. */
- enable_conf = pc->data->enable_conf;
- ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
- if ((ctrl & enable_conf) != enable_conf)
+ if (!enabled)
clk_disable(pc->clk);
clk_disable(pc->pclk);
--
2.27.0
[PATCH 5.10 223/663] ASoC: rt5682: Fix panic in rt5682_jack_detect_handler happening during system shutdown
From: Sathyanarayana Nujella
[ Upstream commit 45a2702ce10993eda7a5b12690294782d565519c ]
During Coldboot stress tests, system encountered the following panic.
Panic logs depicts rt5682_i2c_shutdown() happened first and then later
jack detect handler workqueue function triggered.
This situation causes panic as rt5682_i2c_shutdown() resets codec.
Fix this panic by cancelling all jack detection delayed work.
Panic log:
[ 20.936124] sof_pci_shutdown
[ 20.940248] snd_sof_device_shutdown
[ 20.945023] snd_sof_shutdown
[ 21.126849] rt5682_i2c_shutdown
[ 21.286053] rt5682_jack_detect_handler
[ 21.291235] BUG: kernel NULL pointer dereference, address: 037c
[ 21.299302] #PF: supervisor read access in kernel mode
[ 21.305254] #PF: error_code(0x) - not-present page
[ 21.311218] PGD 0 P4D 0
[ 21.314155] Oops: [#1] PREEMPT SMP NOPTI
[ 21.319206] CPU: 2 PID: 123 Comm: kworker/2:3 Tainted: G U
5.4.68 #10
[ 21.333687] ACPI: Preparing to enter system sleep state S5
[ 21.337669] Workqueue: events_power_efficient rt5682_jack_detect_handler
[snd_soc_rt5682]
[ 21.337671] RIP: 0010:rt5682_jack_detect_handler+0x6c/0x279 [snd_soc_rt5682]
Fixes: a50067d4f3c1d ('ASoC: rt5682: split i2c driver into separate module')
Signed-off-by: Jairaj Arava
Signed-off-by: Sathyanarayana Nujella
Reviewed-by: Pierre-Louis Bossart
Reviewed-by: Shuming Fan
Signed-off-by: Ranjani Sridharan
Link:
https://lore.kernel.org/r/20210205171428.2344210-1-ranjani.sridha...@linux.intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/rt5682-i2c.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
index 6b4e0eb30c89a..7e652843c57d9 100644
--- a/sound/soc/codecs/rt5682-i2c.c
+++ b/sound/soc/codecs/rt5682-i2c.c
@@ -268,6 +268,9 @@ static void rt5682_i2c_shutdown(struct i2c_client *client)
{
struct rt5682_priv *rt5682 = i2c_get_clientdata(client);
+ cancel_delayed_work_sync(>jack_detect_work);
+ cancel_delayed_work_sync(>jd_check_work);
+
rt5682_reset(rt5682);
}
--
2.27.0
[PATCH 5.10 409/663] drm/msm/dsi: Correct io_start for MSM8994 (20nm PHY)
From: Konrad Dybcio
[ Upstream commit 33a7808ce1aea6e2edc1af25db25928137940c02 ]
The previous registers were *almost* correct, but instead of
PHYs, they were pointing at DSI PLLs, resulting in the PHY id
autodetection failing miserably.
Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94")
Signed-off-by: Konrad Dybcio
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
index 1afb7c579dbbb..eca86bf448f74 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
@@ -139,7 +139,7 @@ const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs = {
.disable = dsi_20nm_phy_disable,
.init = msm_dsi_phy_init_common,
},
- .io_start = { 0xfd998300, 0xfd9a0300 },
+ .io_start = { 0xfd998500, 0xfd9a0500 },
.num_dsi_phy = 2,
};
--
2.27.0
[PATCH 5.10 417/663] ext4: fix potential htree index checksum corruption
From: Theodore Ts'o
[ Upstream commit b5776e7524afbd4569978ff790864755c438bba7 ]
In the case where we need to do an interior node split, and
immediately afterwards, we are unable to allocate a new directory leaf
block due to ENOSPC, the directory index checksum's will not be filled
in correctly (and indeed, will not be correctly journalled).
This looks like a bug that was introduced when we added largedir
support. The original code doesn't make any sense (and should have
been caught in code review), but it was hidden because most of the
time, the index node checksum will be set by do_split(). But if
do_split bails out due to ENOSPC, then ext4_handle_dirty_dx_node()
won't get called, and so the directory index checksum field will not
get set, leading to:
EXT4-fs error (device sdb): dx_probe:858: inode #6635543: block 4022: comm
nfsd: Directory index failed checksum
Google-Bug-Id: 176345532
Fixes: e08ac99fa2a2 ("ext4: add largedir feature")
Cc: Artem Blagodarenko
Signed-off-by: Theodore Ts'o
Signed-off-by: Sasha Levin
---
fs/ext4/namei.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index df0886e08a772..14783f7dcbe98 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2410,11 +2410,10 @@ again:
(frame - 1)->bh);
if (err)
goto journal_error;
- if (restart) {
- err = ext4_handle_dirty_dx_node(handle, dir,
- frame->bh);
+ err = ext4_handle_dirty_dx_node(handle, dir,
+ frame->bh);
+ if (err)
goto journal_error;
- }
} else {
struct dx_root *dxroot;
memcpy((char *) entries2, (char *) entries,
--
2.27.0
[PATCH 5.10 141/663] drm/fb-helper: Add missed unlocks in setcmap_legacy()
From: Chuhong Yuan
[ Upstream commit 0a260e731d6c4c17547ac275a2cde888a9eb4a3d ]
setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
add the missed unlocks with goto to fix it.
Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic
and legacy paths")
Signed-off-by: Chuhong Yuan
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201203144248.418281-1-hsleste...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_fb_helper.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1543d9d109705..8033467db4bee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -923,11 +923,15 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct
fb_info *info)
drm_modeset_lock_all(fb_helper->dev);
drm_client_for_each_modeset(modeset, _helper->client) {
crtc = modeset->crtc;
- if (!crtc->funcs->gamma_set || !crtc->gamma_size)
- return -EINVAL;
+ if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
+ ret = -EINVAL;
+ goto out;
+ }
- if (cmap->start + cmap->len > crtc->gamma_size)
- return -EINVAL;
+ if (cmap->start + cmap->len > crtc->gamma_size) {
+ ret = -EINVAL;
+ goto out;
+ }
r = crtc->gamma_store;
g = r + crtc->gamma_size;
@@ -940,8 +944,9 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct
fb_info *info)
ret = crtc->funcs->gamma_set(crtc, r, g, b,
crtc->gamma_size, NULL);
if (ret)
- return ret;
+ goto out;
}
+out:
drm_modeset_unlock_all(fb_helper->dev);
return ret;
--
2.27.0
[PATCH 5.10 293/663] RDMA/rtrs-srv: Init wr_cnt as 1
From: Jack Wang
[ Upstream commit 6f5d1b3016d650f351e65c645a5eee5394547dd0 ]
Fix up wr_avail accounting. if wr_cnt is 0, then we do SIGNAL for first
wr, in completion we add queue_depth back, which is not right in the
sense of tracking for available wr.
So fix it by init wr_cnt to 1.
Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link:
https://lore.kernel.org/r/20201217141915.56989-19-jinpu.w...@cloud.ionos.com
Signed-off-by: Jack Wang
Signed-off-by: Gioh Kim
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index aac710764b44f..f3f4b640b0970 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1620,7 +1620,7 @@ static int create_con(struct rtrs_srv_sess *sess,
con->c.cm_id = cm_id;
con->c.sess = >s;
con->c.cid = cid;
- atomic_set(>wr_cnt, 0);
+ atomic_set(>wr_cnt, 1);
if (con->c.cid == 0) {
/*
--
2.27.0
[PATCH 5.10 143/663] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
From: Maxime Ripard
[ Upstream commit 320e84dc6111ecc1c957e2b186d4d2bafee6bde2 ]
Commit 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within
limits") was intended to compute the pixel rate to make sure we remain
within the boundaries of what the hardware can provide.
However, unlike what mode_valid was checking for, we forgot to take
into account the clock doubling flag that can be set for modes. Let's
honor that flag if it's there.
Acked-by: Thomas Zimmermann
Reported-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-4-max...@cerno.tech
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index eaba98e15de46..db06f52de9d91 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -791,6 +791,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
pixel_rate = mode->clock * 1000;
}
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate = pixel_rate * 2;
+
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
--
2.27.0
[PATCH 5.10 258/663] HSI: Fix PM usage counter unbalance in ssi_hw_init
From: Zhang Qilong
[ Upstream commit aa57e77b3d28f0df07149d88c47bc0f3aa77330b ]
pm_runtime_get_sync will increment pm usage counter
even it failed. Forgetting to putting operation will
result in reference leak here. We fix it by replacing
it with pm_runtime_resume_and_get to keep usage counter
balanced.
Fixes: b209e047bc743 ("HSI: Introduce OMAP SSI driver")
Signed-off-by: Zhang Qilong
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
---
drivers/hsi/controllers/omap_ssi_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hsi/controllers/omap_ssi_core.c
b/drivers/hsi/controllers/omap_ssi_core.c
index 7596dc1646484..44a3f5660c109 100644
--- a/drivers/hsi/controllers/omap_ssi_core.c
+++ b/drivers/hsi/controllers/omap_ssi_core.c
@@ -424,7 +424,7 @@ static int ssi_hw_init(struct hsi_controller *ssi)
struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
int err;
- err = pm_runtime_get_sync(ssi->device.parent);
+ err = pm_runtime_resume_and_get(ssi->device.parent);
if (err < 0) {
dev_err(>device, "runtime PM failed %d\n", err);
return err;
--
2.27.0
[PATCH 4.19 031/247] ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
From: Krzysztof Kozlowski
[ Upstream commit 1ac8893c4fa3d4a34915dc5cdab568a39db5086c ]
The Samsung PMIC datasheets describe the interrupt line as active low
with a requirement of acknowledge from the CPU. The falling edge
interrupt will mostly work but it's not correct.
Fixes: 1fed2252713e ("ARM: dts: fix pinctrl for s2mps11-irq on
exynos5420-arndale-octa")
Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
Link: https://lore.kernel.org/r/20201210212903.216728-5-k...@kernel.org
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index a370857beac0d..fbaca74cbaea4 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -84,7 +84,7 @@
reg = <0x66>;
interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_irq>;
--
2.27.0
[PATCH 5.10 333/663] ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores
From: Vladimir Murzin
[ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ]
It was observed that decompressor running on hardware implementing ARM v8.2
Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest,
would stuck just after:
Uncompressing Linux... done, booting the kernel.
The reason is that it clears nTLSMD bit when disabling caches:
nTLSMD, bit [3]
When ARMv8.2-LSMAOC is implemented:
No Trap Load Multiple and Store Multiple to
Device-nGRE/Device-nGnRE/Device-nGnRnE memory.
0b0 All memory accesses by A32 and T32 Load Multiple and Store
Multiple at EL1 or EL0 that are marked at stage 1 as
Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and
generate a stage 1 Alignment fault.
0b1 All memory accesses by A32 and T32 Load Multiple and Store
Multiple at EL1 or EL0 that are marked at stage 1 as
Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped.
This bit is permitted to be cached in a TLB.
This field resets to 1.
Otherwise:
Reserved, RES1
So as effect we start getting traps we are not quite ready for.
Looking into history it seems that mask used for SCTLR clear came from
the similar code for ARMv4, where bit[3] is the enable/disable bit for
the write buffer. That not applicable to ARMv7 and onwards, so retire
that bit from the masks.
Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add
uncompressing code for the new CPU Id format")
Signed-off-by: Vladimir Murzin
Signed-off-by: Russell King
Signed-off-by: Sasha Levin
---
arch/arm/boot/compressed/head.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 3a392983ac079..a0de09f994d88 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -1175,9 +1175,9 @@ __armv4_mmu_cache_off:
__armv7_mmu_cache_off:
mrc p15, 0, r0, c1, c0
#ifdef CONFIG_MMU
- bic r0, r0, #0x000d
+ bic r0, r0, #0x0005
#else
- bic r0, r0, #0x000c
+ bic r0, r0, #0x0004
#endif
mcr p15, 0, r0, c1, c0 @ turn MMU and cache off
mov r0, #0
--
2.27.0
[PATCH 5.10 521/663] drm/panel: kd35t133: allow using non-continuous dsi clock
From: Heiko Stuebner
commit d922d58fedcd98ba625e89b625a98e222b090b10 upstream.
The panel is able to work when dsi clock is non-continuous, thus
the system power consumption can be reduced using such feature.
Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.
Also the flag actually becomes necessary after
commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous
HS clock")
and without it the panel only emits stripes instead of output.
Fixes: c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous
HS clock")
Cc: sta...@vger.kernel.org # 5.10+
Signed-off-by: Heiko Stuebner
Tested-by: Ezequiel Garcia
Reviewed-by: Christopher Morgan
Link:
https://patchwork.freedesktop.org/patch/msgid/20210206135020.1991820-1-he...@sntech.de
Signed-off-by: Maarten Lankhorst
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -265,7 +265,8 @@ static int kd35t133_probe(struct mipi_ds
dsi->lanes = 1;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS;
drm_panel_init(>panel, >dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
Re: [PATCH 5.10 000/663] 5.10.20-rc1 review
On 2021-03-01 17:04, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.20 release. Since this is a big update I gave it a try on my two older SandyBridge server/desktop systems and a Lenovo AMD Ryzen7 laptop. Good news: all three still humming along nicely. Thanks! -h
[PATCH 5.10 663/663] net_sched: fix RTNL deadlock again caused by request_module()
From: Cong Wang
commit d349f997686887906b1183b5be96933c5452362a upstream.
tcf_action_init_1() loads tc action modules automatically with
request_module() after parsing the tc action names, and it drops RTNL
lock and re-holds it before and after request_module(). This causes a
lot of troubles, as discovered by syzbot, because we can be in the
middle of batch initializations when we create an array of tc actions.
One of the problem is deadlock:
CPU 0 CPU 1
rtnl_lock();
for (...) {
tcf_action_init_1();
-> rtnl_unlock();
-> request_module();
rtnl_lock();
for (...) {
tcf_action_init_1();
-> tcf_idr_check_alloc();
// Insert one action into idr,
// but it is not committed until
// tcf_idr_insert_many(), then drop
// the RTNL lock in the _next_
// iteration
-> rtnl_unlock();
-> rtnl_lock();
-> a_o->init();
-> tcf_idr_check_alloc();
// Now waiting for the same index
// to be committed
-> request_module();
-> rtnl_lock()
// Now waiting for RTNL lock
}
rtnl_unlock();
}
rtnl_unlock();
This is not easy to solve, we can move the request_module() before
this loop and pre-load all the modules we need for this netlink
message and then do the rest initializations. So the loop breaks down
to two now:
for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) {
struct tc_action_ops *a_o;
a_o = tc_action_load_ops(name, tb[i]...);
ops[i - 1] = a_o;
}
for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) {
act = tcf_action_init_1(ops[i - 1]...);
}
Although this looks serious, it only has been reported by syzbot, so it
seems hard to trigger this by humans. And given the size of this patch,
I'd suggest to make it to net-next and not to backport to stable.
This patch has been tested by syzbot and tested with tdc.py by me.
Fixes: 0fedc63fadf0 ("net_sched: commit action insertions together")
Reported-and-tested-by: syzbot+82752bc5331601cf4...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+b3b63b6bff456bd95...@syzkaller.appspotmail.com
Reported-by: syzbot+ba67b12b1ca729912...@syzkaller.appspotmail.com
Cc: Jiri Pirko
Signed-off-by: Cong Wang
Tested-by: Jamal Hadi Salim
Acked-by: Jamal Hadi Salim
Link: https://lore.kernel.org/r/20210117005657.14810-1-xiyou.wangc...@gmail.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Greg Kroah-Hartman
---
include/net/act_api.h |5 +-
net/sched/act_api.c | 104 +++---
net/sched/cls_api.c | 11 -
3 files changed, 79 insertions(+), 41 deletions(-)
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -187,10 +187,13 @@ int tcf_action_init(struct net *net, str
struct nlattr *est, char *name, int ovr, int bind,
struct tc_action *actions[], size_t *attr_size,
bool rtnl_held, struct netlink_ext_ack *extack);
+struct tc_action_ops *tc_action_load_ops(char *name, struct nlattr *nla,
+bool rtnl_held,
+struct netlink_ext_ack *extack);
struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
struct nlattr *nla, struct nlattr *est,
char *name, int ovr, int bind,
- bool rtnl_held,
+ struct tc_action_ops *ops, bool rtnl_held,
struct netlink_ext_ack *extack);
int tcf_action_dump(struct sk_buff *skb, struct tc_action *actions[], int bind,
int ref, bool terse);
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -908,19 +908,13 @@ void tcf_idr_insert_many(struct tc_actio
}
}
-struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
- struct nlattr *nla, struct nlattr *est,
- char *name, int ovr, int bind,
- bool rtnl_held,
- struct netlink_ext_ack *extack)
+struct tc_action_ops *tc_action_load_ops(char *name, struct nlattr *nla,
+bool rtnl_held,
+struct netlink_ext_ack *extack)
{
- struct nla_bitfield32 flags = { 0, 0 };
- u8 hw_stats = TCA_ACT_HW_STATS_ANY;
-
[PATCH 5.10 446/663] ice: Account for port VLAN in VF max packet size calculation
From: Brett Creeley
[ Upstream commit a6aa7c8f998f4afddd73410aa043dad38162ce9e ]
Currently if an AVF driver doesn't account for the possibility of a
port VLAN when determining its max packet size then packets at MTU will
be dropped. It is not the VF driver's responsibility to account for a
port VLAN so fix this. To fix this, do the following:
1. Add a function that determines the max packet size a VF is allowed by
using the port's max packet size and whether the VF is in a port
VLAN. If a port VLAN is configured then a VF's max packet size will
always be the port's max packet size minus VLAN_HLEN. Otherwise it
will be the port's max packet size.
2. Use this function to verify the max packet size from the VF.
3. If there is a port VLAN configured then add 4 bytes (VLAN_HLEN) to
the VF's max packet size configuration.
Also, the VIRTCHNL_OP_GET_VF_RESOURCES message provides the capability
to communicate a VF's max packet size. Use the new function for this
purpose.
Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
Signed-off-by: Brett Creeley
Tested-by: Tony Brelinski
Signed-off-by: Tony Nguyen
Signed-off-by: Sasha Levin
---
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index ec7f6c64132ee..b3161c5def465 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -1878,6 +1878,29 @@ static int ice_vc_get_ver_msg(struct ice_vf *vf, u8 *msg)
sizeof(struct virtchnl_version_info));
}
+/**
+ * ice_vc_get_max_frame_size - get max frame size allowed for VF
+ * @vf: VF used to determine max frame size
+ *
+ * Max frame size is determined based on the current port's max frame size and
+ * whether a port VLAN is configured on this VF. The VF is not aware whether
+ * it's in a port VLAN so the PF needs to account for this in max frame size
+ * checks and sending the max frame size to the VF.
+ */
+static u16 ice_vc_get_max_frame_size(struct ice_vf *vf)
+{
+ struct ice_vsi *vsi = vf->pf->vsi[vf->lan_vsi_idx];
+ struct ice_port_info *pi = vsi->port_info;
+ u16 max_frame_size;
+
+ max_frame_size = pi->phy.link_info.max_frame_size;
+
+ if (vf->port_vlan_info)
+ max_frame_size -= VLAN_HLEN;
+
+ return max_frame_size;
+}
+
/**
* ice_vc_get_vf_res_msg
* @vf: pointer to the VF info
@@ -1960,6 +1983,7 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8
*msg)
vfres->max_vectors = pf->num_msix_per_vf;
vfres->rss_key_size = ICE_VSIQF_HKEY_ARRAY_SIZE;
vfres->rss_lut_size = ICE_VSIQF_HLUT_ARRAY_SIZE;
+ vfres->max_mtu = ice_vc_get_max_frame_size(vf);
vfres->vsi_res[0].vsi_id = vf->lan_vsi_num;
vfres->vsi_res[0].vsi_type = VIRTCHNL_VSI_SRIOV;
@@ -2952,6 +2976,8 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
/* copy Rx queue info from VF into VSI */
if (qpi->rxq.ring_len > 0) {
+ u16 max_frame_size = ice_vc_get_max_frame_size(vf);
+
num_rxq++;
vsi->rx_rings[i]->dma = qpi->rxq.dma_ring_addr;
vsi->rx_rings[i]->count = qpi->rxq.ring_len;
@@ -2964,7 +2990,7 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
}
vsi->rx_buf_len = qpi->rxq.databuffer_size;
vsi->rx_rings[i]->rx_buf_len = vsi->rx_buf_len;
- if (qpi->rxq.max_pkt_size >= (16 * 1024) ||
+ if (qpi->rxq.max_pkt_size > max_frame_size ||
qpi->rxq.max_pkt_size < 64) {
v_ret = VIRTCHNL_STATUS_ERR_PARAM;
goto error_param;
@@ -2972,6 +2998,11 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
}
vsi->max_frame = qpi->rxq.max_pkt_size;
+ /* add space for the port VLAN since the VF driver is not
+* expected to account for it in the MTU calculation
+*/
+ if (vf->port_vlan_info)
+ vsi->max_frame += VLAN_HLEN;
}
/* VF can request to configure less than allocated queues or default
--
2.27.0
[PATCH 5.10 180/663] MIPS: Compare __SYNC_loongson3_war against 0
From: Nathan Chancellor
[ Upstream commit 8790ccf8daf1a8c53b6cb8ce0c9a109274bd3fa8 ]
When building with clang when CONFIG_CPU_LOONGSON3_WORKAROUNDS is
enabled:
In file included from lib/errseq.c:4:
In file included from ./include/linux/atomic.h:7:
./arch/mips/include/asm/atomic.h:52:1: warning: converting the result of
'<<' to a boolean always evaluates to true
[-Wtautological-constant-compare]
ATOMIC_OPS(atomic64, s64)
^
./arch/mips/include/asm/atomic.h:40:9: note: expanded from macro
'ATOMIC_OPS'
return cmpxchg(>counter, o, n);
^
./arch/mips/include/asm/cmpxchg.h:194:7: note: expanded from macro
'cmpxchg'
if (!__SYNC_loongson3_war)
^
./arch/mips/include/asm/sync.h:147:34: note: expanded from macro
'__SYNC_loongson3_war'
# define __SYNC_loongson3_war (1 << 31)
^
While it is not wrong that the result of this shift is always true in a
boolean context, it is not a problem here. Regardless, the warning is
really noisy so rather than making the shift a boolean implicitly, use
it in an equality comparison so the shift is used as an integer value.
Fixes: 4d1dbfe6cbec ("MIPS: atomic: Emit Loongson3 sync workarounds within asm")
Fixes: a91f2a1dba44 ("MIPS: cmpxchg: Omit redundant barriers for Loongson3")
Reported-by: kernel test robot
Signed-off-by: Nathan Chancellor
Acked-by: Nick Desaulniers
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
---
arch/mips/include/asm/atomic.h | 2 +-
arch/mips/include/asm/cmpxchg.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
index f904084fcb1fd..27ad767915390 100644
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -248,7 +248,7 @@ static __inline__ int pfx##_sub_if_positive(type i, pfx##_t
* v)\
* bltz that can branch to code outside of the LL/SC loop. As \
* such, we don't need to emit another barrier here.\
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__after_atomic(); \
\
return result; \
diff --git a/arch/mips/include/asm/cmpxchg.h b/arch/mips/include/asm/cmpxchg.h
index 5b0b3a6777ea5..ed8f3f3c4304a 100644
--- a/arch/mips/include/asm/cmpxchg.h
+++ b/arch/mips/include/asm/cmpxchg.h
@@ -99,7 +99,7 @@ unsigned long __xchg(volatile void *ptr, unsigned long x, int
size)
* contains a completion barrier prior to the LL, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__before_llsc(); \
\
__res = (__typeof__(*(ptr)))\
@@ -191,7 +191,7 @@ unsigned long __cmpxchg(volatile void *ptr, unsigned long
old,
* contains a completion barrier prior to the LL, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__before_llsc(); \
\
__res = cmpxchg_local((ptr), (old), (new)); \
@@ -201,7 +201,7 @@ unsigned long __cmpxchg(volatile void *ptr, unsigned long
old,
* contains a completion barrier after the SC, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_llsc_mb(); \
\
__res; \
--
2.27.0
[PATCH 5.11 179/775] crypto: arm64/aes-ce - really hide slower algos when faster ones are enabled
From: Ard Biesheuvel
[ Upstream commit 15deb4333cd6d4e1e3216582e4c531ec40a6b060 ]
Commit 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if
faster driver is enabled") intended to hide modes from the plain NEON
driver that are also implemented by the faster bit sliced NEON one if
both are enabled. However, the defined() CPP function does not detect
if the bit sliced NEON driver is enabled as a module. So instead, let's
use IS_ENABLED() here.
Fixes: 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if ...")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
---
arch/arm64/crypto/aes-glue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 34b8a89197be3..cafb5b96be0e6 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -55,7 +55,7 @@ MODULE_DESCRIPTION("AES-ECB/CBC/CTR/XTS using ARMv8 Crypto
Extensions");
#define aes_mac_update neon_aes_mac_update
MODULE_DESCRIPTION("AES-ECB/CBC/CTR/XTS using ARMv8 NEON");
#endif
-#if defined(USE_V8_CRYPTO_EXTENSIONS) || !defined(CONFIG_CRYPTO_AES_ARM64_BS)
+#if defined(USE_V8_CRYPTO_EXTENSIONS) ||
!IS_ENABLED(CONFIG_CRYPTO_AES_ARM64_BS)
MODULE_ALIAS_CRYPTO("ecb(aes)");
MODULE_ALIAS_CRYPTO("cbc(aes)");
MODULE_ALIAS_CRYPTO("ctr(aes)");
@@ -650,7 +650,7 @@ static int __maybe_unused xts_decrypt(struct
skcipher_request *req)
}
static struct skcipher_alg aes_algs[] = { {
-#if defined(USE_V8_CRYPTO_EXTENSIONS) || !defined(CONFIG_CRYPTO_AES_ARM64_BS)
+#if defined(USE_V8_CRYPTO_EXTENSIONS) ||
!IS_ENABLED(CONFIG_CRYPTO_AES_ARM64_BS)
.base = {
.cra_name = "__ecb(aes)",
.cra_driver_name= "__ecb-aes-" MODE,
--
2.27.0
[PATCH 5.10 176/663] media: imx7: csi: Fix regression for parallel cameras on i.MX6UL
From: Fabio Estevam
[ Upstream commit 9bac67214fbf4b5f23463f7742ccf69bfe684cbd ]
Commit 86e02d07871c ("media: imx5/6/7: csi: Mark a bound video mux as
a CSI mux") made an incorrect assumption that for imx7-media-csi,
the bound subdev must always be a CSI mux. On i.MX6UL/i.MX6ULL there
is no CSI mux at all, so do not return an error when the entity is not a
video mux and assign the IMX_MEDIA_GRP_ID_CSI_MUX group id only when
appropriate.
This is the same approach as done in imx-media-csi.c and it fixes the
csi probe regression on i.MX6UL.
Tested on a imx6ull-evk board.
Fixes: 86e02d07871c ("media: imx5/6/7: csi: Mark a bound video mux as a CSI
mux")
Signed-off-by: Fabio Estevam
Signed-off-by: Rui Miguel Silva
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/imx/imx7-media-csi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/imx/imx7-media-csi.c
b/drivers/staging/media/imx/imx7-media-csi.c
index a3f3df9017046..31e36168f9d0f 100644
--- a/drivers/staging/media/imx/imx7-media-csi.c
+++ b/drivers/staging/media/imx/imx7-media-csi.c
@@ -1164,12 +1164,12 @@ static int imx7_csi_notify_bound(struct
v4l2_async_notifier *notifier,
struct imx7_csi *csi = imx7_csi_notifier_to_dev(notifier);
struct media_pad *sink = >sd.entity.pads[IMX7_CSI_PAD_SINK];
- /* The bound subdev must always be the CSI mux */
- if (WARN_ON(sd->entity.function != MEDIA_ENT_F_VID_MUX))
- return -ENXIO;
-
- /* Mark it as such via its group id */
- sd->grp_id = IMX_MEDIA_GRP_ID_CSI_MUX;
+ /*
+* If the subdev is a video mux, it must be one of the CSI
+* muxes. Mark it as such via its group id.
+*/
+ if (sd->entity.function == MEDIA_ENT_F_VID_MUX)
+ sd->grp_id = IMX_MEDIA_GRP_ID_CSI_MUX;
return v4l2_create_fwnode_links_to_pad(sd, sink);
}
--
2.27.0
[PATCH 5.10 522/663] drm/rockchip: Require the YTR modifier for AFBC
From: Alyssa Rosenzweig
commit 5f94e3571459abb626077aedb65d71264c2a58c0 upstream.
The AFBC decoder used in the Rockchip VOP assumes the use of the
YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
buffers, which covers the RGBA8 and RGB565 formats supported in
vop_convert_afbc_format. Use of YTR is signaled with the
AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As
such, a producer would have to generate buffers that do not use YTR,
which the VOP would erroneously decode as YTR, leading to severe visual
corruption.
The upstream AFBC support was developed against a captured frame, which
failed to exercise modifier support. Prior to bring-up of AFBC in Mesa
(in the Panfrost driver), no open userspace respected modifier
reporting. As such, this change is not expected to affect broken
userspaces.
Tested on RK3399 with Panfrost and Weston.
Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
Cc: sta...@vger.kernel.org
Signed-off-by: Alyssa Rosenzweig
Acked-by: Daniel Stone
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/20200811202631.3603-1-alyssa.rosenzw...@collabora.com
Signed-off-by: Maarten Lankhorst
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 11 +++
1 file changed, 11 insertions(+)
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -17,9 +17,20 @@
#define NUM_YUV2YUV_COEFFICIENTS 12
+/* AFBC supports a number of configurable modes. Relevant to us is block size
+ * (16x16 or 32x8), storage modifiers (SPARSE, SPLIT), and the YUV-like
+ * colourspace transform (YTR). 16x16 SPARSE mode is always used. SPLIT mode
+ * could be enabled via the hreg_block_split register, but is not currently
+ * handled. The colourspace transform is implicitly always assumed by the
+ * decoder, so consumers must use this transform as well.
+ *
+ * Failure to match modifiers will cause errors displaying AFBC buffers
+ * produced by conformant AFBC producers, including Mesa.
+ */
#define ROCKCHIP_AFBC_MOD \
DRM_FORMAT_MOD_ARM_AFBC( \
AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE \
+ | AFBC_FORMAT_MOD_YTR \
)
enum vop_data_format {
[PATCH 5.10 378/663] RDMA/rtrs-srv: Fix stack-out-of-bounds
From: Jack Wang
[ Upstream commit e6daa8f61d8def10f0619fe51b4c794f69598e4f ]
BUG: KASAN: stack-out-of-bounds in _mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib]
Read of size 4 at addr 8880d5a7f980 by task kworker/0:1H/565
CPU: 0 PID: 565 Comm: kworker/0:1H Tainted: G O 5.4.84-storage
#5.4.84-1+feature+linux+5.4.y+dbg+20201216.1319+b6b887b~deb10
Hardware name: Supermicro H8QG6/H8QG6, BIOS 3.00 09/04/2012
Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
Call Trace:
dump_stack+0x96/0xe0
print_address_description.constprop.4+0x1f/0x300
? irq_work_claim+0x2e/0x50
__kasan_report.cold.8+0x78/0x92
? _mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib]
kasan_report+0x10/0x20
_mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib]
? check_chain_key+0x1d7/0x2e0
? _mlx4_ib_post_recv+0x630/0x630 [mlx4_ib]
? lockdep_hardirqs_on+0x1a8/0x290
? stack_depot_save+0x218/0x56e
? do_profile_hits.isra.6.cold.13+0x1d/0x1d
? check_chain_key+0x1d7/0x2e0
? save_stack+0x4d/0x80
? save_stack+0x19/0x80
? __kasan_slab_free+0x125/0x170
? kfree+0xe7/0x3b0
rdma_write_sg+0x5b0/0x950 [rtrs_server]
The problem is when we send imm_wr, the type should be ib_rdma_wr, so hw
driver like mlx4 can do rdma_wr(wr), so fix it by use the ib_rdma_wr as
type for imm_wr.
Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link:
https://lore.kernel.org/r/20210212134525.103456-2-jinpu.w...@cloud.ionos.com
Signed-off-by: Jack Wang
Reviewed-by: Gioh Kim
Reviewed-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 64 +-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index f3f4b640b0970..75e1e89e09b38 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -232,7 +232,8 @@ static int rdma_write_sg(struct rtrs_srv_op *id)
dma_addr_t dma_addr = sess->dma_addr[id->msg_id];
struct rtrs_srv_mr *srv_mr;
struct rtrs_srv *srv = sess->srv;
- struct ib_send_wr inv_wr, imm_wr;
+ struct ib_send_wr inv_wr;
+ struct ib_rdma_wr imm_wr;
struct ib_rdma_wr *wr = NULL;
enum ib_send_flags flags;
size_t sg_cnt;
@@ -284,15 +285,15 @@ static int rdma_write_sg(struct rtrs_srv_op *id)
if (need_inval && always_invalidate) {
wr->wr.next =
rwr.wr.next = _wr;
- inv_wr.next = _wr;
+ inv_wr.next = _wr.wr;
} else if (always_invalidate) {
wr->wr.next =
- rwr.wr.next = _wr;
+ rwr.wr.next = _wr.wr;
} else if (need_inval) {
wr->wr.next = _wr;
- inv_wr.next = _wr;
+ inv_wr.next = _wr.wr;
} else {
- wr->wr.next = _wr;
+ wr->wr.next = _wr.wr;
}
/*
* From time to time we have to post signaled sends,
@@ -310,7 +311,7 @@ static int rdma_write_sg(struct rtrs_srv_op *id)
inv_wr.ex.invalidate_rkey = rkey;
}
- imm_wr.next = NULL;
+ imm_wr.wr.next = NULL;
if (always_invalidate) {
struct rtrs_msg_rkey_rsp *msg;
@@ -331,22 +332,22 @@ static int rdma_write_sg(struct rtrs_srv_op *id)
list.addr = srv_mr->iu->dma_addr;
list.length = sizeof(*msg);
list.lkey = sess->s.dev->ib_pd->local_dma_lkey;
- imm_wr.sg_list =
- imm_wr.num_sge = 1;
- imm_wr.opcode = IB_WR_SEND_WITH_IMM;
+ imm_wr.wr.sg_list =
+ imm_wr.wr.num_sge = 1;
+ imm_wr.wr.opcode = IB_WR_SEND_WITH_IMM;
ib_dma_sync_single_for_device(sess->s.dev->ib_dev,
srv_mr->iu->dma_addr,
srv_mr->iu->size, DMA_TO_DEVICE);
} else {
- imm_wr.sg_list = NULL;
- imm_wr.num_sge = 0;
- imm_wr.opcode = IB_WR_RDMA_WRITE_WITH_IMM;
+ imm_wr.wr.sg_list = NULL;
+ imm_wr.wr.num_sge = 0;
+ imm_wr.wr.opcode = IB_WR_RDMA_WRITE_WITH_IMM;
}
- imm_wr.send_flags = flags;
- imm_wr.ex.imm_data = cpu_to_be32(rtrs_to_io_rsp_imm(id->msg_id,
+ imm_wr.wr.send_flags = flags;
+ imm_wr.wr.ex.imm_data = cpu_to_be32(rtrs_to_io_rsp_imm(id->msg_id,
0, need_inval));
- imm_wr.wr_cqe = _comp_cqe;
+ imm_wr.wr.wr_cqe = _comp_cqe;
ib_dma_sync_single_for_device(sess->s.dev->ib_dev, dma_addr,
offset, DMA_BIDIRECTIONAL);
@@ -373,7 +374,8 @@ static int send_io_resp_imm(struct rtrs_srv_con *con,
struct rtrs_srv_op *id,
{
struct rtrs_sess *s =
[PATCH 5.11 201/775] media: em28xx: Fix use-after-free in em28xx_alloc_urbs
From: Dinghao Liu
[ Upstream commit a26efd1961a18b91ae4cd2e433adbcf865b40fa3 ]
When kzalloc() fails, em28xx_uninit_usb_xfer() will free
usb_bufs->buf and set it to NULL. Thus the later access
to usb_bufs->buf[i] will lead to null pointer dereference.
Also the kfree(usb_bufs->buf) after that is redundant.
Fixes: d571b592c6206 ("media: em28xx: don't use coherent buffer for DMA
transfers")
Signed-off-by: Dinghao Liu
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/usb/em28xx/em28xx-core.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index e6088b5d1b805..3daa64bb1e1d9 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -956,14 +956,10 @@ int em28xx_alloc_urbs(struct em28xx *dev, enum
em28xx_mode mode, int xfer_bulk,
usb_bufs->buf[i] = kzalloc(sb_size, GFP_KERNEL);
if (!usb_bufs->buf[i]) {
- em28xx_uninit_usb_xfer(dev, mode);
-
for (i--; i >= 0; i--)
kfree(usb_bufs->buf[i]);
- kfree(usb_bufs->buf);
- usb_bufs->buf = NULL;
-
+ em28xx_uninit_usb_xfer(dev, mode);
return -ENOMEM;
}
--
2.27.0
[PATCH 5.10 603/663] nvmem: qcom-spmi-sdam: Fix uninitialized pdev pointer
From: Subbaraman Narayanamurthy
commit e2057ee29973b9741d43d3f475a6b02fb46a0e61 upstream.
"sdam->pdev" is uninitialized and it is used to print error logs.
Fix it. Since device pointer can be used from sdam_config, use it
directly thereby removing pdev pointer.
Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Subbaraman Narayanamurthy
Signed-off-by: Srinivas Kandagatla
Link:
https://lore.kernel.org/r/20210205100853.32372-3-srinivas.kandaga...@linaro.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvmem/qcom-spmi-sdam.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/nvmem/qcom-spmi-sdam.c
+++ b/drivers/nvmem/qcom-spmi-sdam.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2017, 2020 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2017, 2020-2021, The Linux Foundation. All rights reserved.
*/
#include
@@ -18,7 +18,6 @@
#define SDAM_PBS_TRIG_CLR 0xE6
struct sdam_chip {
- struct platform_device *pdev;
struct regmap *regmap;
struct nvmem_config sdam_config;
unsigned intbase;
@@ -65,7 +64,7 @@ static int sdam_read(void *priv, unsigne
size_t bytes)
{
struct sdam_chip *sdam = priv;
- struct device *dev = >pdev->dev;
+ struct device *dev = sdam->sdam_config.dev;
int rc;
if (!sdam_is_valid(sdam, offset, bytes)) {
@@ -86,7 +85,7 @@ static int sdam_write(void *priv, unsign
size_t bytes)
{
struct sdam_chip *sdam = priv;
- struct device *dev = >pdev->dev;
+ struct device *dev = sdam->sdam_config.dev;
int rc;
if (!sdam_is_valid(sdam, offset, bytes)) {
[PATCH 5.10 093/663] iwlwifi: pnvm: set the PNVM again if it was already loaded
From: Luca Coelho
[ Upstream commit 4a81598f0f39cffbf1c29c4a184063d513661c4a ]
When the interface goes up, we have already loaded the PNVM during
init, so we don't load it anymore. But we still need to set the PNVM
values in the context so that the FW can load it again.
Call set_pnvm when the PNVM is already loaded and change the
trans_pcie implementation to accept a second call to set_pnvm when we
have already allocated and, in this case, only set the values without
allocating again.
Signed-off-by: Luca Coelho
Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file")
Signed-off-by: Luca Coelho
Link:
https://lore.kernel.org/r/iwlwifi.20210210172142.622546a3566f.I659a8b9aa944d213c4ba446e142d74f3f6db9c64@changeid
Signed-off-by: Luca Coelho
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 7 ++-
.../intel/iwlwifi/pcie/ctxt-info-gen3.c | 21 +++
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
b/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
index 895a907acdf0f..1e16f83b402b8 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
@@ -227,6 +227,7 @@ int iwl_pnvm_load(struct iwl_trans *trans,
struct iwl_notification_wait pnvm_wait;
static const u16 ntf_cmds[] = { WIDE_ID(REGULATORY_AND_NVM_GROUP,
PNVM_INIT_COMPLETE_NTFY) };
+ int ret;
/* if the SKU_ID is empty, there's nothing to do */
if (!trans->sku_id[0] && !trans->sku_id[1] && !trans->sku_id[2])
@@ -236,7 +237,6 @@ int iwl_pnvm_load(struct iwl_trans *trans,
if (!trans->pnvm_loaded) {
const struct firmware *pnvm;
char pnvm_name[64];
- int ret;
/*
* The prefix unfortunately includes a hyphen at the end, so
@@ -264,6 +264,11 @@ int iwl_pnvm_load(struct iwl_trans *trans,
release_firmware(pnvm);
}
+ } else {
+ /* if we already loaded, we need to set it again */
+ ret = iwl_trans_set_pnvm(trans, NULL, 0);
+ if (ret)
+ return ret;
}
iwl_init_notification_wait(notif_wait, _wait,
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
index 2d43899fbdd7a..81ef4fc8d7831 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c
@@ -345,17 +345,20 @@ int iwl_trans_pcie_ctx_info_gen3_set_pnvm(struct
iwl_trans *trans,
if (trans->trans_cfg->device_family < IWL_DEVICE_FAMILY_AX210)
return 0;
- ret = iwl_pcie_ctxt_info_alloc_dma(trans, data, len,
- _pcie->pnvm_dram);
- if (ret < 0) {
- IWL_DEBUG_FW(trans, "Failed to allocate PNVM DMA %d.\n",
-ret);
- return ret;
+ /* only allocate the DRAM if not allocated yet */
+ if (!trans->pnvm_loaded) {
+ if (WARN_ON(prph_sc_ctrl->pnvm_cfg.pnvm_size))
+ return -EBUSY;
+
+ ret = iwl_pcie_ctxt_info_alloc_dma(trans, data, len,
+ _pcie->pnvm_dram);
+ if (ret < 0) {
+ IWL_DEBUG_FW(trans, "Failed to allocate PNVM DMA %d.\n",
+ret);
+ return ret;
+ }
}
- if (WARN_ON(prph_sc_ctrl->pnvm_cfg.pnvm_size))
- return -EBUSY;
-
prph_sc_ctrl->pnvm_cfg.pnvm_base_addr =
cpu_to_le64(trans_pcie->pnvm_dram.physical);
prph_sc_ctrl->pnvm_cfg.pnvm_size =
--
2.27.0
[PATCH 5.11 096/775] iwlwifi: pnvm: increment the pointer before checking the TLV
From: Luca Coelho
[ Upstream commit ff11a8ee2d2d0f78514ac9b42fb50c525ca695c7 ]
If the SKU_ID doesn't match, we don't increment the pointer and keep
checking the same TLV over and over again.
We need to increment the pointer in all situtations, namely if the TLV
is not a SKU_ID, if the SKU_ID matched or if the SKU_ID didn't match.
So we can increment the pointer already before checking for these
conditions to solve the problem.
Signed-off-by: Luca Coelho
Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file")
Signed-off-by: Luca Coelho
Link:
https://lore.kernel.org/r/iwlwifi.20210210172142.de94d366f3ff.I9a5a54906cf0f4ec8af981d6066bfd771152ffb9@changeid
Signed-off-by: Luca Coelho
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
b/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
index 1e16f83b402b8..37ce4fe136c5e 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c
@@ -198,14 +198,14 @@ static int iwl_pnvm_parse(struct iwl_trans *trans, const
u8 *data,
le32_to_cpu(sku_id->data[1]),
le32_to_cpu(sku_id->data[2]));
+ data += sizeof(*tlv) + ALIGN(tlv_len, 4);
+ len -= ALIGN(tlv_len, 4);
+
if (trans->sku_id[0] == le32_to_cpu(sku_id->data[0]) &&
trans->sku_id[1] == le32_to_cpu(sku_id->data[1]) &&
trans->sku_id[2] == le32_to_cpu(sku_id->data[2])) {
int ret;
- data += sizeof(*tlv) + ALIGN(tlv_len, 4);
- len -= ALIGN(tlv_len, 4);
-
ret = iwl_pnvm_handle_section(trans, data, len);
if (!ret)
return 0;
--
2.27.0
[PATCH 5.11 091/775] iwlwifi: mvm: send stored PPAG command instead of local
From: Luca Coelho
[ Upstream commit 659844d391826bfc5c8b4d9a06869ed51d859c76 ]
Some change conflicts apparently cause a confusion between a local
variable being used to send the PPAG command and the introduction of a
union for this command. Most parts of the local command were never
copied from the stored data, so the FW was getting garbage in the
tables instead of getting valid values.
Fix this by completely removing the local and using only the union
that we have stored in fwrt.
Signed-off-by: Luca Coelho
Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2")
Signed-off-by: Luca Coelho
Link:
https://lore.kernel.org/r/iwlwifi.20210210135352.d090e0301023.I7d57f4d7da9a3297734c51cf988199323c76916d@changeid
Signed-off-by: Luca Coelho
Signed-off-by: Sasha Levin
---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 4d527409428d3..045765fa67bea 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -990,7 +990,6 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm)
{
u8 cmd_ver;
int i, j, ret, num_sub_bands, cmd_size;
- union iwl_ppag_table_cmd ppag_table;
s8 *gain;
if (!fw_has_capa(>fw->ucode_capa, IWL_UCODE_TLV_CAPA_SET_PPAG)) {
@@ -1003,15 +1002,13 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm)
return 0;
}
- ppag_table.v1.enabled = mvm->fwrt.ppag_table.v1.enabled;
-
cmd_ver = iwl_fw_lookup_cmd_ver(mvm->fw, PHY_OPS_GROUP,
PER_PLATFORM_ANT_GAIN_CMD,
IWL_FW_CMD_VER_UNKNOWN);
if (cmd_ver == 1) {
num_sub_bands = IWL_NUM_SUB_BANDS;
gain = mvm->fwrt.ppag_table.v1.gain[0];
- cmd_size = sizeof(ppag_table.v1);
+ cmd_size = sizeof(mvm->fwrt.ppag_table.v1);
if (mvm->fwrt.ppag_ver == 2) {
IWL_DEBUG_RADIO(mvm,
"PPAG table is v2 but FW supports v1,
sending truncated table\n");
@@ -1019,7 +1016,7 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm)
} else if (cmd_ver == 2) {
num_sub_bands = IWL_NUM_SUB_BANDS_V2;
gain = mvm->fwrt.ppag_table.v2.gain[0];
- cmd_size = sizeof(ppag_table.v2);
+ cmd_size = sizeof(mvm->fwrt.ppag_table.v2);
if (mvm->fwrt.ppag_ver == 1) {
IWL_DEBUG_RADIO(mvm,
"PPAG table is v1 but FW supports v2,
sending padded table\n");
@@ -1039,7 +1036,7 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm)
IWL_DEBUG_RADIO(mvm, "Sending PER_PLATFORM_ANT_GAIN_CMD\n");
ret = iwl_mvm_send_cmd_pdu(mvm, WIDE_ID(PHY_OPS_GROUP,
PER_PLATFORM_ANT_GAIN_CMD),
- 0, cmd_size, _table);
+ 0, cmd_size, >fwrt.ppag_table);
if (ret < 0)
IWL_ERR(mvm, "failed to send PER_PLATFORM_ANT_GAIN_CMD (%d)\n",
ret);
--
2.27.0
[PATCH 5.11 130/775] ibmvnic: serialize access to work queue on remove
From: Sukadev Bhattiprolu
[ Upstream commit 4a41c421f3676fdeea91733cf434dcf319c4c351 ]
The work queue is used to queue reset requests like CHANGE-PARAM or
FAILOVER resets for the worker thread. When the adapter is being removed
the adapter state is set to VNIC_REMOVING and the work queue is flushed
so no new work is added. However the check for adapter being removed is
racy in that the adapter can go into REMOVING state just after we check
and we might end up adding work just as it is being flushed (or after).
The ->rwi_lock is already being used to serialize queue/dequeue work.
Extend its usage ensure there is no race when scheduling/flushing work.
Fixes: 6954a9e4192b ("ibmvnic: Flush existing work items before device removal")
Signed-off-by: Sukadev Bhattiprolu
Cc:Uwe Kleine-König
Cc:Saeed Mahameed
Reviewed-by: Dany Madden
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/ibm/ibmvnic.c | 27 ---
drivers/net/ethernet/ibm/ibmvnic.h | 5 -
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index cd201f89ce6c0..13ae7eee7ef5f 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2395,6 +2395,8 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
unsigned long flags;
int ret;
+ spin_lock_irqsave(>rwi_lock, flags);
+
/*
* If failover is pending don't schedule any other reset.
* Instead let the failover complete. If there is already a
@@ -2415,14 +2417,11 @@ static int ibmvnic_reset(struct ibmvnic_adapter
*adapter,
goto err;
}
- spin_lock_irqsave(>rwi_lock, flags);
-
list_for_each(entry, >rwi_list) {
tmp = list_entry(entry, struct ibmvnic_rwi, list);
if (tmp->reset_reason == reason) {
netdev_dbg(netdev, "Skipping matching reset,
reason=%d\n",
reason);
- spin_unlock_irqrestore(>rwi_lock, flags);
ret = EBUSY;
goto err;
}
@@ -2430,8 +2429,6 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
rwi = kzalloc(sizeof(*rwi), GFP_ATOMIC);
if (!rwi) {
- spin_unlock_irqrestore(>rwi_lock, flags);
- ibmvnic_close(netdev);
ret = ENOMEM;
goto err;
}
@@ -2444,12 +2441,17 @@ static int ibmvnic_reset(struct ibmvnic_adapter
*adapter,
}
rwi->reset_reason = reason;
list_add_tail(>list, >rwi_list);
- spin_unlock_irqrestore(>rwi_lock, flags);
netdev_dbg(adapter->netdev, "Scheduling reset (reason %d)\n", reason);
schedule_work(>ibmvnic_reset);
- return 0;
+ ret = 0;
err:
+ /* ibmvnic_close() below can block, so drop the lock first */
+ spin_unlock_irqrestore(>rwi_lock, flags);
+
+ if (ret == ENOMEM)
+ ibmvnic_close(netdev);
+
return -ret;
}
@@ -5467,7 +5469,18 @@ static int ibmvnic_remove(struct vio_dev *dev)
unsigned long flags;
spin_lock_irqsave(>state_lock, flags);
+
+ /* If ibmvnic_reset() is scheduling a reset, wait for it to
+* finish. Then, set the state to REMOVING to prevent it from
+* scheduling any more work and to have reset functions ignore
+* any resets that have already been scheduled. Drop the lock
+* after setting state, so __ibmvnic_reset() which is called
+* from the flush_work() below, can make progress.
+*/
+ spin_lock_irqsave(>rwi_lock, flags);
adapter->state = VNIC_REMOVING;
+ spin_unlock_irqrestore(>rwi_lock, flags);
+
spin_unlock_irqrestore(>state_lock, flags);
flush_work(>ibmvnic_reset);
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h
b/drivers/net/ethernet/ibm/ibmvnic.h
index c09c3f6bba9f2..3cccbba703658 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -1081,6 +1081,7 @@ struct ibmvnic_adapter {
struct tasklet_struct tasklet;
enum vnic_state state;
enum ibmvnic_reset_reason reset_reason;
+ /* when taking both state and rwi locks, take state lock first */
spinlock_t rwi_lock;
struct list_head rwi_list;
struct work_struct ibmvnic_reset;
@@ -1097,6 +1098,8 @@ struct ibmvnic_adapter {
struct ibmvnic_tunables desired;
struct ibmvnic_tunables fallback;
- /* Used for serializatin of state field */
+ /* Used for serialization of state field. When taking both state
+* and rwi locks, take state lock first.
+*/
spinlock_t state_lock;
};
--
2.27.0
[PATCH 5.10 439/663] Take mmap lock in cacheflush syscall
From: Jann Horn
[ Upstream commit c26958cb5a0d9053d1358258827638773f3d36ed ]
We need to take the mmap lock around find_vma() and subsequent use of the
VMA. Otherwise, we can race with concurrent operations like munmap(), which
can lead to use-after-free accesses to freed VMAs.
Fixes: 1000197d8013 ("nios2: System calls handling")
Signed-off-by: Jann Horn
Signed-off-by: Ley Foon Tan
Signed-off-by: Sasha Levin
---
arch/nios2/kernel/sys_nios2.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/nios2/kernel/sys_nios2.c b/arch/nios2/kernel/sys_nios2.c
index cd390ec4f88bf..b1ca856999521 100644
--- a/arch/nios2/kernel/sys_nios2.c
+++ b/arch/nios2/kernel/sys_nios2.c
@@ -22,6 +22,7 @@ asmlinkage int sys_cacheflush(unsigned long addr, unsigned
long len,
unsigned int op)
{
struct vm_area_struct *vma;
+ struct mm_struct *mm = current->mm;
if (len == 0)
return 0;
@@ -34,16 +35,22 @@ asmlinkage int sys_cacheflush(unsigned long addr, unsigned
long len,
if (addr + len < addr)
return -EFAULT;
+ if (mmap_read_lock_killable(mm))
+ return -EINTR;
+
/*
* Verify that the specified address region actually belongs
* to this process.
*/
- vma = find_vma(current->mm, addr);
- if (vma == NULL || addr < vma->vm_start || addr + len > vma->vm_end)
+ vma = find_vma(mm, addr);
+ if (vma == NULL || addr < vma->vm_start || addr + len > vma->vm_end) {
+ mmap_read_unlock(mm);
return -EFAULT;
+ }
flush_cache_range(vma, addr, addr + len);
+ mmap_read_unlock(mm);
return 0;
}
--
2.27.0
memory leak in edge_startup
Hello, syzbot found the following issue on: HEAD commit:29c395c7 Merge tag 'x86-entry-2021-02-24' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10d694dad0 kernel config: https://syzkaller.appspot.com/x/.config?x=66b7497b2c5acd67 dashboard link: https://syzkaller.appspot.com/bug?extid=59f777bdcbdd7eea5305 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=162940dad0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1650737ad0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+59f777bdcbdd7eea5...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x88810dc5a800 (size 2048): comm "kworker/1:3", pid 4818, jiffies 4294960503 (age 15.050s) hex dump (first 32 bytes): 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<153c6b11>] kmalloc include/linux/slab.h:554 [inline] [<153c6b11>] kzalloc include/linux/slab.h:684 [inline] [<153c6b11>] edge_startup+0x3f/0x11f0 drivers/usb/serial/io_edgeport.c:2833 [<7c25fa28>] usb_serial_probe.cold+0x6ab/0xb84 drivers/usb/serial/usb-serial.c:1027 [<50250e6f>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<36a9ab90>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<9356c1ed>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [ ] __device_attach+0x122/0x250 drivers/base/dd.c:914 [ ] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<5ea173b6>] device_add+0x5d5/0xc40 drivers/base/core.c:3242 [<3faa2805>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<99ff1454>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [ ] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [ ] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<36a9ab90>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 BUG: memory leak unreferenced object 0x888110c17540 (size 192): comm "kworker/1:3", pid 4818, jiffies 4294960524 (age 14.840s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 75 c1 10 81 88 ff ff Xu.. backtrace: [<3178be4d>] kmalloc include/linux/slab.h:559 [inline] [<3178be4d>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<06a81376>] edge_startup+0xd20/0x11f0 drivers/usb/serial/io_edgeport.c:2926 [<7c25fa28>] usb_serial_probe.cold+0x6ab/0xb84 drivers/usb/serial/usb-serial.c:1027 [<50250e6f>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [ ] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<36a9ab90>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<9356c1ed>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [ ] __device_attach+0x122/0x250 drivers/base/dd.c:914 [ ] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<5ea173b6>] device_add+0x5d5/0xc40 drivers/base/core.c:3242 [<3faa2805>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164 [<99ff1454>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [ ] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [ ] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<36a9ab90>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 BUG: memory leak unreferenced object 0x888110c17240 (size 192): comm "kworker/1:3", pid 4818, jiffies 4294960524 (age 14.840s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 72 c1 10 81 88 ff ff Xr.. backtrace: [<3178be4d>] kmalloc include/linux/slab.h:559 [inline] [<3178be4d>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<4f167a1a>] edge_startup+0xebf/0x11f0 drivers/usb/serial/io_edgeport.c:2963 [<7c25fa28>] usb_serial_probe.cold+0x6ab/0xb84 drivers/usb/serial/usb-serial.c:1027 [<50250e6f>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [ ] really_probe+0x159/0x4a0 drivers/base/dd.c:554 [<36a9ab90>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
[PATCH 5.10 012/663] bfq: Avoid false bfq queue merging
From: Jan Kara
commit 41e76c85660c022c6bf5713bfb6c21e64a487cec upstream.
bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it
makes sense to merge current bfq queue with the in-service queue.
However if the in-service queue is freshly scheduled and didn't dispatch
any requests yet, bfqd->in_serv_last_pos is stale and contains value
from the previously scheduled bfq queue which can thus result in a bogus
decision that the two queues should be merged. This bug can be observed
for example with the following fio jobfile:
[global]
direct=0
ioengine=sync
invalidate=1
size=1g
rw=read
[reader]
numjobs=4
directory=/mnt
where the 4 processes will end up in the one shared bfq queue although
they do IO to physically very distant files (for some reason I was able to
observe this only with slice_idle=1ms setting).
Fix the problem by invalidating bfqd->in_serv_last_pos when switching
in-service queue.
Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging")
CC: sta...@vger.kernel.org
Signed-off-by: Jan Kara
Acked-by: Paolo Valente
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
block/bfq-iosched.c |1 +
1 file changed, 1 insertion(+)
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2937,6 +2937,7 @@ static void __bfq_set_in_service_queue(s
}
bfqd->in_service_queue = bfqq;
+ bfqd->in_serv_last_pos = 0;
}
/*
[PATCH 5.11 262/775] ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A32
From: Pierre-Louis Bossart
[ Upstream commit 45c92ec32b43c6cb42341ebf07577eefed9d87ec ]
We missed adding the TGL_HDMI quirk which is very much needed to
expose the 4 display pipelines and will be required on TGL topologies.
Fixes: 488cdbd8931fe ('ASoC: Intel: sof_sdw: add quirk for new TigerLake-SDCA
device')
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Link:
https://lore.kernel.org/r/20210204203312.27112-4-pierre-louis.boss...@linux.intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/intel/boards/sof_sdw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index 29b6bba3d4257..afdc336ec9bf5 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -54,7 +54,8 @@ static const struct dmi_system_id sof_sdw_quirk_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0A32")
},
- .driver_data = (void *)(SOF_RT711_JD_SRC_JD2 |
+ .driver_data = (void *)(SOF_SDW_TGL_HDMI |
+ SOF_RT711_JD_SRC_JD2 |
SOF_RT715_DAI_ID_FIX |
SOF_SDW_FOUR_SPK),
},
--
2.27.0
[PATCH 5.10 485/663] HID: wacom: Ignore attempts to overwrite the touch_max value from HID
From: Jason Gerecke
commit 88f38846bfb1a452a3d47e38aeab20a4ceb74294 upstream.
The `wacom_feature_mapping` function is careful to only set the the
touch_max value a single time, but this care does not extend to the
`wacom_wac_finger_event` function. In particular, if a device sends
multiple HID_DG_CONTACTMAX items in a single feature report, the
driver will end up retaining the value of last item.
The HID descriptor for the Cintiq Companion 2 does exactly this. It
incorrectly sets a "Report Count" of 2, which will cause the driver
to process two HID_DG_CONTACTCOUNT items. The first item has the actual
count, while the second item should have been declared as a constant
zero. The constant zero is the value the driver ends up using, however,
since it is the last HID_DG_CONTACTCOUNT in the report.
Report ID (16),
Usage (Contact Count Maximum), ; Contact count maximum (55h, static value)
Report Count (2),
Logical Maximum (10),
Feature (Variable),
To address this, we add a check that the touch_max is not already set
within the `wacom_wac_finger_event` function that processes the
HID_DG_TOUCHMAX item. We emit a warning if the value is set and ignore
the updated value.
This could potentially cause problems if there is a tablet which has
a similar issue but requires the last item to be used. This is unlikely,
however, since it would have to have a different non-zero value for
HID_DG_CONTACTMAX earlier in the same report, which makes no sense
except in the case of a firmware bug. Note that cases where the
HID_DG_CONTACTMAX items are in different reports is already handled
(and similarly ignored) by `wacom_feature_mapping` as mentioned above.
Link: https://github.com/linuxwacom/input-wacom/issues/223
Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any
feature report")
Signed-off-by: Jason Gerecke
CC: sta...@vger.kernel.org
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/wacom_wac.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -2600,7 +2600,12 @@ static void wacom_wac_finger_event(struc
wacom_wac->is_invalid_bt_frame = !value;
return;
case HID_DG_CONTACTMAX:
- features->touch_max = value;
+ if (!features->touch_max) {
+ features->touch_max = value;
+ } else {
+ hid_warn(hdev, "%s: ignoring attempt to overwrite
non-zero touch_max "
+"%d -> %d\n", __func__, features->touch_max,
value);
+ }
return;
}
[PATCH 5.11 342/775] RDMA/rtrs-srv: Jump to dereg_mr label if allocate iu fails
From: Guoqing Jiang
[ Upstream commit f77c4839ee8f4612dcb6601602329096030bd813 ]
The rtrs_iu_free is called in rtrs_iu_alloc if memory is limited, so we
don't need to free the same iu again.
Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link:
https://lore.kernel.org/r/20201217141915.56989-7-jinpu.w...@cloud.ionos.com
Signed-off-by: Guoqing Jiang
Reviewed-by: Gioh Kim
Signed-off-by: Jack Wang
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 341661f42add0..92a216ddd9fd3 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -651,7 +651,7 @@ static int map_cont_bufs(struct rtrs_srv_sess *sess)
if (!srv_mr->iu) {
err = -ENOMEM;
rtrs_err(ss, "rtrs_iu_alloc(), err: %d\n", err);
- goto free_iu;
+ goto dereg_mr;
}
}
/* Eventually dma addr for each chunk can be cached */
@@ -667,7 +667,6 @@ err:
srv_mr = >mrs[mri];
sgt = _mr->sgt;
mr = srv_mr->mr;
-free_iu:
rtrs_iu_free(srv_mr->iu, sess->s.dev->ib_dev, 1);
dereg_mr:
ib_dereg_mr(mr);
--
2.27.0
[PATCH 5.10 647/663] dm writecache: fix writing beyond end of underlying device when shrinking
From: Mikulas Patocka
commit 4134455f2aafdfeab50cabb4cccb35e916034b93 upstream.
Do not attempt to write any data beyond the end of the underlying data
device while shrinking it.
The DM writecache device must be suspended when the underlying data
device is shrunk.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-writecache.c | 18 ++
1 file changed, 18 insertions(+)
--- a/drivers/md/dm-writecache.c
+++ b/drivers/md/dm-writecache.c
@@ -148,6 +148,7 @@ struct dm_writecache {
size_t metadata_sectors;
size_t n_blocks;
uint64_t seq_count;
+ sector_t data_device_sectors;
void *block_start;
struct wc_entry *entries;
unsigned block_size;
@@ -977,6 +978,8 @@ static void writecache_resume(struct dm_
wc_lock(wc);
+ wc->data_device_sectors = i_size_read(wc->dev->bdev->bd_inode) >>
SECTOR_SHIFT;
+
if (WC_MODE_PMEM(wc)) {
persistent_memory_invalidate_cache(wc->memory_map,
wc->memory_map_size);
} else {
@@ -1646,6 +1649,10 @@ static bool wc_add_block(struct writebac
void *address = memory_data(wc, e);
persistent_memory_flush_cache(address, block_size);
+
+ if (unlikely(bio_end_sector(>bio) >= wc->data_device_sectors))
+ return true;
+
return bio_add_page(>bio, persistent_memory_page(address),
block_size, persistent_memory_page_offset(address))
!= 0;
}
@@ -1717,6 +1724,9 @@ static void __writecache_writeback_pmem(
if (writecache_has_error(wc)) {
bio->bi_status = BLK_STS_IOERR;
bio_endio(bio);
+ } else if (unlikely(!bio_sectors(bio))) {
+ bio->bi_status = BLK_STS_OK;
+ bio_endio(bio);
} else {
submit_bio(bio);
}
@@ -1760,6 +1770,14 @@ static void __writecache_writeback_ssd(s
e = f;
}
+ if (unlikely(to.sector + to.count > wc->data_device_sectors)) {
+ if (to.sector >= wc->data_device_sectors) {
+ writecache_copy_endio(0, 0, c);
+ continue;
+ }
+ from.count = to.count = wc->data_device_sectors -
to.sector;
+ }
+
dm_kcopyd_copy(wc->dm_kcopyd, , 1, , 0,
writecache_copy_endio, c);
__writeback_throttle(wc, wbl);
[PATCH 5.11 007/775] scsi: qla2xxx: Fix mailbox Ch erroneous error
From: Quinn Tran
commit 044c218b04503858ca4e17f61899c8baa0ae9ba1 upstream.
Mailbox Ch/dump ram extend expects mb register 10 to be set. If not
set/clear, firmware can pick up garbage from previous invocation of this
mailbox. Example: mctp dump can set mb10. On subsequent flash read which
use mailbox cmd Ch, mb10 can retain previous value.
Link: https://lore.kernel.org/r/20210111093134.1206-6-njav...@marvell.com
Cc: sta...@vger.kernel.org
Reviewed-by: Himanshu Madhani
Signed-off-by: Quinn Tran
Signed-off-by: Nilesh Javali
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/qla2xxx/qla_dbg.c |1 +
drivers/scsi/qla2xxx/qla_mbx.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -202,6 +202,7 @@ qla24xx_dump_ram(struct qla_hw_data *ha,
wrt_reg_word(>mailbox0, MBC_DUMP_RISC_RAM_EXTENDED);
wrt_reg_word(>mailbox1, LSW(addr));
wrt_reg_word(>mailbox8, MSW(addr));
+ wrt_reg_word(>mailbox10, 0);
wrt_reg_word(>mailbox2, MSW(LSD(dump_dma)));
wrt_reg_word(>mailbox3, LSW(LSD(dump_dma)));
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -4276,7 +4276,8 @@ qla2x00_dump_ram(scsi_qla_host_t *vha, d
if (MSW(addr) || IS_FWI2_CAPABLE(vha->hw)) {
mcp->mb[0] = MBC_DUMP_RISC_RAM_EXTENDED;
mcp->mb[8] = MSW(addr);
- mcp->out_mb = MBX_8|MBX_0;
+ mcp->mb[10] = 0;
+ mcp->out_mb = MBX_10|MBX_8|MBX_0;
} else {
mcp->mb[0] = MBC_DUMP_RISC_RAM;
mcp->out_mb = MBX_0;
[PATCH 5.10 492/663] usb: musb: Fix runtime PM race in musb_queue_resume_work
From: Paul Cercueil
commit 0eaa1a3714db34a59ce121de5733c3909c529463 upstream.
musb_queue_resume_work() would call the provided callback if the runtime
PM status was 'active'. Otherwise, it would enqueue the request if the
hardware was still suspended (musb->is_runtime_suspended is true).
This causes a race with the runtime PM handlers, as it is possible to be
in the case where the runtime PM status is not yet 'active', but the
hardware has been awaken (PM resume function has been called).
When hitting the race, the resume work was not enqueued, which probably
triggered other bugs further down the stack. For instance, a telnet
connection on Ingenic SoCs would result in a 50/50 chance of a
segmentation fault somewhere in the musb code.
Rework the code so that either we call the callback directly if
(musb->is_runtime_suspended == 0), or enqueue the query otherwise.
Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid
context for hdrc glue")
Cc: sta...@vger.kernel.org # v4.9+
Tested-by: Tony Lindgren
Reviewed-by: Tony Lindgren
Signed-off-by: Paul Cercueil
Link: https://lore.kernel.org/r/20210123142502.16980-1-p...@crapouillou.net
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/musb/musb_core.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2240,32 +2240,35 @@ int musb_queue_resume_work(struct musb *
{
struct musb_pending_work *w;
unsigned long flags;
+ bool is_suspended;
int error;
if (WARN_ON(!callback))
return -EINVAL;
- if (pm_runtime_active(musb->controller))
- return callback(musb, data);
+ spin_lock_irqsave(>list_lock, flags);
+ is_suspended = musb->is_runtime_suspended;
- w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
- if (!w)
- return -ENOMEM;
+ if (is_suspended) {
+ w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
+ if (!w) {
+ error = -ENOMEM;
+ goto out_unlock;
+ }
+
+ w->callback = callback;
+ w->data = data;
- w->callback = callback;
- w->data = data;
- spin_lock_irqsave(>list_lock, flags);
- if (musb->is_runtime_suspended) {
list_add_tail(>node, >pending_list);
error = 0;
- } else {
- dev_err(musb->controller, "could not add resume work %p\n",
- callback);
- devm_kfree(musb->controller, w);
- error = -EINPROGRESS;
}
+
+out_unlock:
spin_unlock_irqrestore(>list_lock, flags);
+ if (!is_suspended)
+ error = callback(musb, data);
+
return error;
}
EXPORT_SYMBOL_GPL(musb_queue_resume_work);
[PATCH 5.10 600/663] mm/vmscan: restore zone_reclaim_mode ABI
From: Dave Hansen
commit 519983645a9f2ec339cabfa0c6ef7b09be985dd0 upstream.
I went to go add a new RECLAIM_* mode for the zone_reclaim_mode sysctl.
Like a good kernel developer, I also went to go update the
documentation. I noticed that the bits in the documentation didn't
match the bits in the #defines.
The VM never explicitly checks the RECLAIM_ZONE bit. The bit is,
however implicitly checked when checking 'node_reclaim_mode==0'. The
RECLAIM_ZONE #define was removed in a cleanup. That, by itself is fine.
But, when the bit was removed (bit 0) the _other_ bit locations also got
changed. That's not OK because the bit values are documented to mean
one specific thing. Users surely do not expect the meaning to change
from kernel to kernel.
The end result is that if someone had a script that did:
sysctl vm.zone_reclaim_mode=1
it would have gone from enabling node reclaim for clean unmapped pages
to writing out pages during node reclaim after the commit in question.
That's not great.
Put the bits back the way they were and add a comment so something like
this is a bit harder to do again. Update the documentation to make it
clear that the first bit is ignored.
Link: https://lkml.kernel.org/r/20210219172555.ff0cd...@viggo.jf.intel.com
Signed-off-by: Dave Hansen
Fixes: 648b5cf368e0 ("mm/vmscan: remove unused RECLAIM_OFF/RECLAIM_ZONE")
Reviewed-by: Ben Widawsky
Reviewed-by: Oscar Salvador
Acked-by: David Rientjes
Acked-by: Christoph Lameter
Cc: Alex Shi
Cc: Daniel Wagner
Cc: "Tobin C. Harding"
Cc: Christoph Lameter
Cc: Andrew Morton
Cc: Huang Ying
Cc: Dan Williams
Cc: Qian Cai
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
Documentation/admin-guide/sysctl/vm.rst | 10 +-
mm/vmscan.c |9 +++--
2 files changed, 12 insertions(+), 7 deletions(-)
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -978,11 +978,11 @@ that benefit from having their data cach
left disabled as the caching effect is likely to be more important than
data locality.
-zone_reclaim may be enabled if it's known that the workload is partitioned
-such that each partition fits within a NUMA node and that accessing remote
-memory would cause a measurable performance reduction. The page allocator
-will then reclaim easily reusable pages (those page cache pages that are
-currently not used) before allocating off node pages.
+Consider enabling one or more zone_reclaim mode bits if it's known that the
+workload is partitioned such that each partition fits within a NUMA node
+and that accessing remote memory would cause a measurable performance
+reduction. The page allocator will take additional actions before
+allocating off node pages.
Allowing zone reclaim to write out pages stops processes that are
writing large amounts of data from dirtying pages on other nodes. Zone
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4084,8 +4084,13 @@ module_init(kswapd_init)
*/
int node_reclaim_mode __read_mostly;
-#define RECLAIM_WRITE (1<<0) /* Writeout pages during reclaim */
-#define RECLAIM_UNMAP (1<<1) /* Unmap pages during reclaim */
+/*
+ * These bit locations are exposed in the vm.zone_reclaim_mode sysctl
+ * ABI. New bits are OK, but existing bits can never change.
+ */
+#define RECLAIM_ZONE (1<<0) /* Run shrink_inactive_list on the zone */
+#define RECLAIM_WRITE (1<<1) /* Writeout pages during reclaim */
+#define RECLAIM_UNMAP (1<<2) /* Unmap pages during reclaim */
/*
* Priority for NODE_RECLAIM. This determines the fraction of pages
[PATCH 5.10 111/663] net/mlx5: Disable devlink reload for lag devices
From: Shay Drory
[ Upstream commit edac23c2b3d3ac64cfcd351087295893671adbf5 ]
Devlink reload can't be allowed on lag devices since reloading one lag
device will cause traffic on the bond to get stucked.
Users who wish to reload a lag device, need to remove the device from
the bond, and only then reload it.
Fixes: 4383cfcc65e7 ("net/mlx5: Add devlink reload")
Signed-off-by: Shay Drory
Reviewed-by: Moshe Shemesh
Signed-off-by: Saeed Mahameed
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
index 0450ab5f5f756..bf5cf022e279d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
@@ -137,6 +137,11 @@ static int mlx5_devlink_reload_down(struct devlink
*devlink, bool netns_change,
{
struct mlx5_core_dev *dev = devlink_priv(devlink);
+ if (mlx5_lag_is_active(dev)) {
+ NL_SET_ERR_MSG_MOD(extack, "reload is unsupported in Lag
mode\n");
+ return -EOPNOTSUPP;
+ }
+
switch (action) {
case DEVLINK_RELOAD_ACTION_DRIVER_REINIT:
mlx5_unload_one(dev, false);
--
2.27.0
[PATCH 5.10 511/663] bcache: Move journal work to new flush wq
From: Kai Krakow
commit afe78ab46f638ecdf80a35b122ffc92c20d9ae5d upstream.
This is potentially long running and not latency sensitive, let's get
it out of the way of other latency sensitive events.
As observed in the previous commit, the `system_wq` comes easily
congested by bcache, and this fixes a few more stalls I was observing
every once in a while.
Let's not make this `WQ_MEM_RECLAIM` as it showed to reduce performance
of boot and file system operations in my tests. Also, without
`WQ_MEM_RECLAIM`, I no longer see desktop stalls. This matches the
previous behavior as `system_wq` also does no memory reclaim:
> // workqueue.c:
> system_wq = alloc_workqueue("events", 0, 0);
Cc: Coly Li
Cc: sta...@vger.kernel.org # 5.4+
Signed-off-by: Kai Krakow
Signed-off-by: Coly Li
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/bcache/bcache.h |1 +
drivers/md/bcache/journal.c |4 ++--
drivers/md/bcache/super.c | 16
3 files changed, 19 insertions(+), 2 deletions(-)
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -1001,6 +1001,7 @@ void bch_write_bdev_super(struct cached_
extern struct workqueue_struct *bcache_wq;
extern struct workqueue_struct *bch_journal_wq;
+extern struct workqueue_struct *bch_flush_wq;
extern struct mutex bch_register_lock;
extern struct list_head bch_cache_sets;
--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -932,8 +932,8 @@ atomic_t *bch_journal(struct cache_set *
journal_try_write(c);
} else if (!w->dirty) {
w->dirty = true;
- schedule_delayed_work(>journal.work,
- msecs_to_jiffies(c->journal_delay_ms));
+ queue_delayed_work(bch_flush_wq, >journal.work,
+ msecs_to_jiffies(c->journal_delay_ms));
spin_unlock(>journal.lock);
} else {
spin_unlock(>journal.lock);
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -49,6 +49,7 @@ static int bcache_major;
static DEFINE_IDA(bcache_device_idx);
static wait_queue_head_t unregister_wait;
struct workqueue_struct *bcache_wq;
+struct workqueue_struct *bch_flush_wq;
struct workqueue_struct *bch_journal_wq;
@@ -2833,6 +2834,8 @@ static void bcache_exit(void)
destroy_workqueue(bcache_wq);
if (bch_journal_wq)
destroy_workqueue(bch_journal_wq);
+ if (bch_flush_wq)
+ destroy_workqueue(bch_flush_wq);
bch_btree_exit();
if (bcache_major)
@@ -2896,6 +2899,19 @@ static int __init bcache_init(void)
if (!bcache_wq)
goto err;
+ /*
+* Let's not make this `WQ_MEM_RECLAIM` for the following reasons:
+*
+* 1. It used `system_wq` before which also does no memory reclaim.
+* 2. With `WQ_MEM_RECLAIM` desktop stalls, increased boot times, and
+*reduced throughput can be observed.
+*
+* We still want to user our own queue to not congest the `system_wq`.
+*/
+ bch_flush_wq = alloc_workqueue("bch_flush", 0, 0);
+ if (!bch_flush_wq)
+ goto err;
+
bch_journal_wq = alloc_workqueue("bch_journal", WQ_MEM_RECLAIM, 0);
if (!bch_journal_wq)
goto err;
[PATCH 5.10 273/663] clk: renesas: r8a779a0: Fix parent of CBFUSA clock
From: Geert Uytterhoeven
[ Upstream commit 80d3e07ec509c5098d44e4f1416cc9f133fd436f ]
According to Figure 8.1.1 ("Block Diagram of CPG (R-Car V3U-AD)") in the
R-Car V3U Series User's Manual Rev. 0.5, the parent of the CBFUSA clock
is EXTAL.
Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Yoshihiro Shimoda
Tested-by: Wolfram Sang
Link: https://lore.kernel.org/r/20201019120614.22149-3-geert+rene...@glider.be
Signed-off-by: Sasha Levin
---
drivers/clk/renesas/r8a779a0-cpg-mssr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r8a779a0-cpg-mssr.c
b/drivers/clk/renesas/r8a779a0-cpg-mssr.c
index 48c260f09b2d7..4ee2706c9c6a0 100644
--- a/drivers/clk/renesas/r8a779a0-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a779a0-cpg-mssr.c
@@ -136,7 +136,7 @@ static const struct cpg_core_clk r8a779a0_core_clks[]
__initconst = {
DEF_FIXED("icu",R8A779A0_CLK_ICU, CLK_PLL5_DIV4, 2, 1),
DEF_FIXED("icud2", R8A779A0_CLK_ICUD2, CLK_PLL5_DIV4, 4, 1),
DEF_FIXED("vcbus", R8A779A0_CLK_VCBUS, CLK_PLL5_DIV4, 1, 1),
- DEF_FIXED("cbfusa", R8A779A0_CLK_CBFUSA,CLK_MAIN, 2, 1),
+ DEF_FIXED("cbfusa", R8A779A0_CLK_CBFUSA,CLK_EXTAL, 2, 1),
DEF_DIV6P1("mso", R8A779A0_CLK_MSO, CLK_PLL5_DIV4, 0x87c),
DEF_DIV6P1("canfd", R8A779A0_CLK_CANFD, CLK_PLL5_DIV4, 0x878),
--
2.27.0
[PATCH 5.11 129/775] ibmvnic: skip send_request_unmap for timeout reset
From: Lijun Pan
[ Upstream commit 7d3a7b9ea59ddb223aec59b45fa1713c633aaed4 ]
Timeout reset will trigger the VIOS to unmap it automatically,
similarly as FAILVOER and MOBILITY events. If we unmap it
in the linux side, we will see errors like
"3003: Error 4 in REQUEST_UNMAP_RSP".
So, don't call send_request_unmap for timeout reset.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/ibm/ibmvnic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index f6402a20ba320..cd201f89ce6c0 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -247,8 +247,13 @@ static void free_long_term_buff(struct ibmvnic_adapter
*adapter,
if (!ltb->buff)
return;
+ /* VIOS automatically unmaps the long term buffer at remote
+* end for the following resets:
+* FAILOVER, MOBILITY, TIMEOUT.
+*/
if (adapter->reset_reason != VNIC_RESET_FAILOVER &&
- adapter->reset_reason != VNIC_RESET_MOBILITY)
+ adapter->reset_reason != VNIC_RESET_MOBILITY &&
+ adapter->reset_reason != VNIC_RESET_TIMEOUT)
send_request_unmap(adapter, ltb->map_id);
dma_free_coherent(dev, ltb->size, ltb->buff, ltb->addr);
}
--
2.27.0
[PATCH 5.11 070/775] arm64: dts: renesas: beacon: Fix EEPROM compatible value
From: Geert Uytterhoeven
[ Upstream commit 74477936a828a7c91a61ba7e625b7ce2299c8c98 ]
"make dtbs_check" fails with:
arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dt.yaml: eeprom@50:
compatible: 'oneOf' conditional failed, one must be fixed:
'microchip,at24c64' does not match
'^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$'
Fix this by dropping the bogus "at" prefix.
Fixes: a1d8a344f1ca0709 ("arm64: dts: renesas: Introduce
r8a774a1-beacon-rzg2m-kit")
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20210128110136.2293490-1-geert+rene...@glider.be
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index b93219a95afcd..ea937a926c0e3 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -148,7 +148,7 @@
};
eeprom@50 {
- compatible = "microchip,at24c64", "atmel,24c64";
+ compatible = "microchip,24c64", "atmel,24c64";
pagesize = <32>;
read-only; /* Manufacturing EEPROM programmed at factory */
reg = <0x50>;
--
2.27.0
[PATCH 5.10 576/663] entry/kvm: Explicitly flush pending rcuog wakeup before last rescheduling point
From: Frederic Weisbecker
commit 4ae7dc97f726ea95c58ac58af71cc034ad22d7de upstream.
Following the idle loop model, cleanly check for pending rcuog wakeup
before the last rescheduling point upon resuming to guest mode. This
way we can avoid to do it from rcu_user_enter() with the last resort
self-IPI hack that enforces rescheduling.
Suggested-by: Peter Zijlstra
Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20210131230548.32970-6-frede...@kernel.org
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kvm/x86.c|1 +
include/linux/entry-kvm.h | 14 ++
kernel/rcu/tree.c | 44 ++--
kernel/rcu/tree_plugin.h |1 +
4 files changed, 50 insertions(+), 10 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1776,6 +1776,7 @@ EXPORT_SYMBOL_GPL(kvm_emulate_wrmsr);
bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu)
{
+ xfer_to_guest_mode_prepare();
return vcpu->mode == EXITING_GUEST_MODE || kvm_request_pending(vcpu) ||
xfer_to_guest_mode_work_pending();
}
--- a/include/linux/entry-kvm.h
+++ b/include/linux/entry-kvm.h
@@ -47,6 +47,20 @@ static inline int arch_xfer_to_guest_mod
int xfer_to_guest_mode_handle_work(struct kvm_vcpu *vcpu);
/**
+ * xfer_to_guest_mode_prepare - Perform last minute preparation work that
+ * need to be handled while IRQs are disabled
+ * upon entering to guest.
+ *
+ * Has to be invoked with interrupts disabled before the last call
+ * to xfer_to_guest_mode_work_pending().
+ */
+static inline void xfer_to_guest_mode_prepare(void)
+{
+ lockdep_assert_irqs_disabled();
+ rcu_nocb_flush_deferred_wakeup();
+}
+
+/**
* __xfer_to_guest_mode_work_pending - Check if work is pending
*
* Returns: True if work pending, False otherwise.
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -670,9 +670,10 @@ EXPORT_SYMBOL_GPL(rcu_idle_enter);
#ifdef CONFIG_NO_HZ_FULL
+#if !defined(CONFIG_GENERIC_ENTRY) || !defined(CONFIG_KVM_XFER_TO_GUEST_WORK)
/*
* An empty function that will trigger a reschedule on
- * IRQ tail once IRQs get re-enabled on userspace resume.
+ * IRQ tail once IRQs get re-enabled on userspace/guest resume.
*/
static void late_wakeup_func(struct irq_work *work)
{
@@ -681,6 +682,37 @@ static void late_wakeup_func(struct irq_
static DEFINE_PER_CPU(struct irq_work, late_wakeup_work) =
IRQ_WORK_INIT(late_wakeup_func);
+/*
+ * If either:
+ *
+ * 1) the task is about to enter in guest mode and $ARCH doesn't support KVM
generic work
+ * 2) the task is about to enter in user mode and $ARCH doesn't support
generic entry.
+ *
+ * In these cases the late RCU wake ups aren't supported in the resched loops
and our
+ * last resort is to fire a local irq_work that will trigger a reschedule once
IRQs
+ * get re-enabled again.
+ */
+noinstr static void rcu_irq_work_resched(void)
+{
+ struct rcu_data *rdp = this_cpu_ptr(_data);
+
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY) && !(current->flags & PF_VCPU))
+ return;
+
+ if (IS_ENABLED(CONFIG_KVM_XFER_TO_GUEST_WORK) && (current->flags &
PF_VCPU))
+ return;
+
+ instrumentation_begin();
+ if (do_nocb_deferred_wakeup(rdp) && need_resched()) {
+ irq_work_queue(this_cpu_ptr(_wakeup_work));
+ }
+ instrumentation_end();
+}
+
+#else
+static inline void rcu_irq_work_resched(void) { }
+#endif
+
/**
* rcu_user_enter - inform RCU that we are resuming userspace.
*
@@ -694,8 +726,6 @@ static DEFINE_PER_CPU(struct irq_work, l
*/
noinstr void rcu_user_enter(void)
{
- struct rcu_data *rdp = this_cpu_ptr(_data);
-
lockdep_assert_irqs_disabled();
/*
@@ -703,13 +733,7 @@ noinstr void rcu_user_enter(void)
* rescheduling opportunity in the entry code. Trigger a self IPI
* that will fire and reschedule once we resume in user/guest mode.
*/
- instrumentation_begin();
- if (!IS_ENABLED(CONFIG_GENERIC_ENTRY) || (current->flags & PF_VCPU)) {
- if (do_nocb_deferred_wakeup(rdp) && need_resched())
- irq_work_queue(this_cpu_ptr(_wakeup_work));
- }
- instrumentation_end();
-
+ rcu_irq_work_resched();
rcu_eqs_enter(true);
}
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2197,6 +2197,7 @@ void rcu_nocb_flush_deferred_wakeup(void
{
do_nocb_deferred_wakeup(this_cpu_ptr(_data));
}
+EXPORT_SYMBOL_GPL(rcu_nocb_flush_deferred_wakeup);
void __init rcu_init_nohz(void)
{
[PATCH 5.10 410/663] drm/msm/mdp5: Fix wait-for-commit for cmd panels
From: Iskren Chernev
[ Upstream commit 68e4f01fddb4ead80e8c7084db489307f22c9cbb ]
Before the offending commit in msm_atomic_commit_tail wait_flush was
called once per frame, after the commit was submitted. After it
wait_flush is also called at the beginning to ensure previous
potentially async commits are done.
For cmd panels the source of wait_flush is a ping-pong irq notifying
a completion. The completion needs to be notified with complete_all so
multiple waiting parties (new async committers) can proceed.
Signed-off-by: Iskren Chernev
Suggested-by: Rob Clark
Fixes: 2d99ced787e3d ("drm/msm: async commit support")
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index c39dad151bb6d..7d7668998501a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -1176,7 +1176,7 @@ static void mdp5_crtc_pp_done_irq(struct mdp_irq *irq,
uint32_t irqstatus)
struct mdp5_crtc *mdp5_crtc = container_of(irq, struct mdp5_crtc,
pp_done);
- complete(_crtc->pp_completion);
+ complete_all(_crtc->pp_completion);
}
static void mdp5_crtc_wait_for_pp_done(struct drm_crtc *crtc)
--
2.27.0
[PATCH 5.11 255/775] f2fs: fix a wrong condition in __submit_bio
From: Dehe Gu
[ Upstream commit 39f71b7e40e21805d6b15fc7750bdd9cab6a5010 ]
We should use !F2FS_IO_ALIGNED() to check and submit_io directly.
Fixes: 8223ecc456d0 ("f2fs: fix to add missing F2FS_IO_ALIGNED() condition")
Reviewed-by: Chao Yu
Signed-off-by: Dehe Gu
Signed-off-by: Ge Qiu
Signed-off-by: Jaegeuk Kim
Signed-off-by: Sasha Levin
---
fs/f2fs/data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index d72c99d9bd1f4..4d3ebf094f6d7 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -499,7 +499,7 @@ static inline void __submit_bio(struct f2fs_sb_info *sbi,
if (f2fs_lfs_mode(sbi) && current->plug)
blk_finish_plug(current->plug);
- if (F2FS_IO_ALIGNED(sbi))
+ if (!F2FS_IO_ALIGNED(sbi))
goto submit_io;
start = bio->bi_iter.bi_size >> F2FS_BLKSIZE_BITS;
--
2.27.0
[PATCH 5.10 282/663] power: supply: cpcap-battery: Fix missing power_supply_put()
From: Tony Lindgren
[ Upstream commit 97456a24acb41b74ab6910f40fb8f09b206fd3b5 ]
Fix missing power_supply_put().
Cc: Arthur Demchenkov
Cc: Carl Philipp Klemm
Cc: Merlijn Wajer
Cc: Pavel Machek
Fixes: 8b0134cc14b9 ("power: supply: cpcap-battery: Fix handling of lowered
charger voltage")
Signed-off-by: Tony Lindgren
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
---
drivers/power/supply/cpcap-battery.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/cpcap-battery.c
b/drivers/power/supply/cpcap-battery.c
index 7a974b5bd9dd1..cebc5c8fda1b5 100644
--- a/drivers/power/supply/cpcap-battery.c
+++ b/drivers/power/supply/cpcap-battery.c
@@ -561,17 +561,21 @@ static int cpcap_battery_update_charger(struct
cpcap_battery_ddata *ddata,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
);
if (error)
- return error;
+ goto out_put;
/* Allow charger const voltage lower than battery const voltage */
if (const_charge_voltage > prop.intval)
- return 0;
+ goto out_put;
val.intval = const_charge_voltage;
- return power_supply_set_property(charger,
+ error = power_supply_set_property(charger,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
);
+out_put:
+ power_supply_put(charger);
+
+ return error;
}
static int cpcap_battery_set_property(struct power_supply *psy,
--
2.27.0
[PATCH 5.11 188/775] drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if condition
From: Chenyang Li
[ Upstream commit 956e20eb0fbb206e5e795539db5469db099715c8 ]
Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H".
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Reviewed-by: Guchun Chen
Reviewed-by: Paul Menzel
Signed-off-by: Chenyang Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 6752d8b131188..ce8dc995c10cf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -21,7 +21,7 @@
*
*/
-#if !defined(_AMDGPU_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#if !defined(_AMDGPU_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
#define _AMDGPU_TRACE_H_
#include
--
2.27.0
[PATCH 5.11 324/775] dmaengine: fsldma: Fix a resource leak in the remove function
From: Christophe JAILLET
[ Upstream commit cbc0ad004c03ad7971726a5db3ec84dba3dcb857 ]
A 'irq_dispose_mapping()' call is missing in the remove function.
Add it.
This is needed to undo the 'irq_of_parse_and_map() call from the probe
function and already part of the error handling path of the probe function.
It was added in the probe function only in commit d3f620b2c4fe ("fsldma:
simplify IRQ probing and handling")
Fixes: 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as
a module")
Signed-off-by: Christophe JAILLET
Link:
https://lore.kernel.org/r/20201212160516.92515-1-christophe.jail...@wanadoo.fr
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
---
drivers/dma/fsldma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 0feb323bae1e3..554f70a0c18c0 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1314,6 +1314,7 @@ static int fsldma_of_remove(struct platform_device *op)
if (fdev->chan[i])
fsl_dma_chan_remove(fdev->chan[i]);
}
+ irq_dispose_mapping(fdev->irq);
iounmap(fdev->regs);
kfree(fdev);
--
2.27.0
[PATCH 5.10 504/663] ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup
From: Takashi Iwai
commit c3bb2b521944ffbbc8c24b849f81977a9915fb5e upstream.
HP Spectre x360 14 model (PCI SSID 103c:87f7) seems requiring a unique
setup for its external amp: the GPIO0 needs to be toggled on and off
shortly at each device initialization via runtime PM.
This patch implements that workaround as well as the model option
string, so that users with other devices may try the same workaround
more easily.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210633
Cc:
Link: https://lore.kernel.org/r/20210215082540.4520-1-ti...@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c | 29 +
1 file changed, 29 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4291,6 +4291,28 @@ static void alc280_fixup_hp_gpio4(struct
}
}
+/* HP Spectre x360 14 model needs a unique workaround for enabling the amp;
+ * it needs to toggle the GPIO0 once on and off at each time (bko#210633)
+ */
+static void alc245_fixup_hp_x360_amp(struct hda_codec *codec,
+const struct hda_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+
+ switch (action) {
+ case HDA_FIXUP_ACT_PRE_PROBE:
+ spec->gpio_mask |= 0x01;
+ spec->gpio_dir |= 0x01;
+ break;
+ case HDA_FIXUP_ACT_INIT:
+ /* need to toggle GPIO to enable the amp */
+ alc_update_gpio_data(codec, 0x01, true);
+ msleep(100);
+ alc_update_gpio_data(codec, 0x01, false);
+ break;
+ }
+}
+
static void alc_update_coef_led(struct hda_codec *codec,
struct alc_coef_led *led,
bool polarity, bool on)
@@ -6277,6 +6299,7 @@ enum {
ALC280_FIXUP_HP_DOCK_PINS,
ALC269_FIXUP_HP_DOCK_GPIO_MIC1_LED,
ALC280_FIXUP_HP_9480M,
+ ALC245_FIXUP_HP_X360_AMP,
ALC288_FIXUP_DELL_HEADSET_MODE,
ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC288_FIXUP_DELL_XPS_13,
@@ -6982,6 +7005,10 @@ static const struct hda_fixup alc269_fix
.type = HDA_FIXUP_FUNC,
.v.func = alc280_fixup_hp_9480m,
},
+ [ALC245_FIXUP_HP_X360_AMP] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc245_fixup_hp_x360_amp,
+ },
[ALC288_FIXUP_DELL_HEADSET_MODE] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_headset_mode_dell_alc288,
@@ -7996,6 +8023,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87f4, "HP", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87f5, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f7, "HP Spectre x360 14",
ALC245_FIXUP_HP_X360_AMP),
SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300),
SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE",
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
@@ -8368,6 +8396,7 @@ static const struct hda_model_fixup alc2
{.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name =
"alc298-samsung-headphone"},
{.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name =
"alc255-xiaomi-headset"},
{.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"},
+ {.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"},
{}
};
#define ALC225_STANDARD_PINS \
[PATCH 5.10 125/663] ibmvnic: add memory barrier to protect long term buffer
From: Lijun Pan
[ Upstream commit 42557dab78edc8235aba5b441f2eb35f725a0ede ]
dma_rmb() barrier is added to load the long term buffer before copying
it to socket buffer; and dma_wmb() barrier is added to update the
long term buffer before it being accessed by VIOS (virtual i/o server).
Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
Signed-off-by: Lijun Pan
Acked-by: Thomas Falcon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/ibm/ibmvnic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index d789c3cb7f87b..d6cd131625525 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1592,6 +1592,9 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb,
struct net_device *netdev)
skb_copy_from_linear_data(skb, dst, skb->len);
}
+ /* post changes to long_term_buff *dst before VIOS accessing it */
+ dma_wmb();
+
tx_pool->consumer_index =
(tx_pool->consumer_index + 1) % tx_pool->num_buffers;
@@ -2432,6 +2435,8 @@ restart_poll:
offset = be16_to_cpu(next->rx_comp.off_frame_data);
flags = next->rx_comp.flags;
skb = rx_buff->skb;
+ /* load long_term_buff before copying to skb */
+ dma_rmb();
skb_copy_to_linear_data(skb, rx_buff->data + offset,
length);
--
2.27.0
[PATCH 5.10 086/663] soc: aspeed: snoop: Add clock control logic
From: Jae Hyun Yoo
[ Upstream commit 3f94cf15583be554df7aaa651b8ff8e1b68fbe51 ]
If LPC SNOOP driver is registered ahead of lpc-ctrl module, LPC
SNOOP block will be enabled without heart beating of LCLK until
lpc-ctrl enables the LCLK. This issue causes improper handling on
host interrupts when the host sends interrupt in that time frame.
Then kernel eventually forcibly disables the interrupt with
dumping stack and printing a 'nobody cared this irq' message out.
To prevent this issue, all LPC sub-nodes should enable LCLK
individually so this patch adds clock control logic into the LPC
SNOOP driver.
Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
Signed-off-by: Jae Hyun Yoo
Signed-off-by: Vernon Mauery
Signed-off-by: John Wang
Reviewed-by: Joel Stanley
Link:
https://lore.kernel.org/r/20201208091748.1920-1-wangzhiqiang...@bytedance.com
Signed-off-by: Joel Stanley
Signed-off-by: Sasha Levin
---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 30 ---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c
b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index f3d8d53ab84de..dbe5325a324d5 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -67,6 +68,7 @@ struct aspeed_lpc_snoop_channel {
struct aspeed_lpc_snoop {
struct regmap *regmap;
int irq;
+ struct clk *clk;
struct aspeed_lpc_snoop_channel chan[NUM_SNOOP_CHANNELS];
};
@@ -282,22 +284,42 @@ static int aspeed_lpc_snoop_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ lpc_snoop->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(lpc_snoop->clk)) {
+ rc = PTR_ERR(lpc_snoop->clk);
+ if (rc != -EPROBE_DEFER)
+ dev_err(dev, "couldn't get clock\n");
+ return rc;
+ }
+ rc = clk_prepare_enable(lpc_snoop->clk);
+ if (rc) {
+ dev_err(dev, "couldn't enable clock\n");
+ return rc;
+ }
+
rc = aspeed_lpc_snoop_config_irq(lpc_snoop, pdev);
if (rc)
- return rc;
+ goto err;
rc = aspeed_lpc_enable_snoop(lpc_snoop, dev, 0, port);
if (rc)
- return rc;
+ goto err;
/* Configuration of 2nd snoop channel port is optional */
if (of_property_read_u32_index(dev->of_node, "snoop-ports",
1, ) == 0) {
rc = aspeed_lpc_enable_snoop(lpc_snoop, dev, 1, port);
- if (rc)
+ if (rc) {
aspeed_lpc_disable_snoop(lpc_snoop, 0);
+ goto err;
+ }
}
+ return 0;
+
+err:
+ clk_disable_unprepare(lpc_snoop->clk);
+
return rc;
}
@@ -309,6 +331,8 @@ static int aspeed_lpc_snoop_remove(struct platform_device
*pdev)
aspeed_lpc_disable_snoop(lpc_snoop, 0);
aspeed_lpc_disable_snoop(lpc_snoop, 1);
+ clk_disable_unprepare(lpc_snoop->clk);
+
return 0;
}
--
2.27.0
[PATCH 5.10 482/663] ACPI: configfs: add missing check after configfs_register_default_group()
From: Qinglang Miao
commit 67e40054de86aae520ddc2a072d7f6951812a14f upstream.
A list_add corruption is reported by Hulk Robot like this:
==
list_add corruption.
Call Trace:
link_obj+0xc0/0x1c0
link_group+0x21/0x140
configfs_register_subsystem+0xdb/0x380
acpi_configfs_init+0x25/0x1000 [acpi_configfs]
do_one_initcall+0x149/0x820
do_init_module+0x1ef/0x720
load_module+0x35c8/0x4380
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80
It's because of the missing check after configfs_register_default_group,
where configfs_unregister_subsystem should be called once failure.
Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs")
Reported-by: Hulk Robot
Suggested-by: Hanjun Guo
Signed-off-by: Qinglang Miao
Cc: 4.10+ # 4.10+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/acpi_configfs.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -268,7 +268,12 @@ static int __init acpi_configfs_init(voi
acpi_table_group = configfs_register_default_group(root, "table",
_tables_type);
- return PTR_ERR_OR_ZERO(acpi_table_group);
+ if (IS_ERR(acpi_table_group)) {
+ configfs_unregister_subsystem(_configfs);
+ return PTR_ERR(acpi_table_group);
+ }
+
+ return 0;
}
module_init(acpi_configfs_init);
[PATCH 5.10 370/663] spi: Skip zero-length transfers in spi_transfer_one_message()
From: Nicolas Saenz Julienne
[ Upstream commit b306320322c9cfaa465bc2c7367acf6072b1ac0e ]
With the introduction of 26751de25d25 ("spi: bcm2835: Micro-optimise
FIFO loops") it has become apparent that some users might initiate
zero-length SPI transfers. A fact the micro-optimization omitted, and
which turned out to cause crashes[1].
Instead of changing the micro-optimization itself, use a bigger hammer
and skip zero-length transfers altogether for drivers using the default
transfer_one_message() implementation.
Reported-by: Phil Elwell
Fixes: 26751de25d25 ("spi: bcm2835: Micro-optimise FIFO loops")
Signed-off-by: Nicolas Saenz Julienne
[1] https://github.com/raspberrypi/linux/issues/4100
Link: https://lore.kernel.org/r/20210211180820.25757-1-nsaenzjulie...@suse.de
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 7694e1ae5b0b2..4257a2d368f71 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1259,7 +1259,7 @@ static int spi_transfer_one_message(struct spi_controller
*ctlr,
ptp_read_system_prets(xfer->ptp_sts);
}
- if (xfer->tx_buf || xfer->rx_buf) {
+ if ((xfer->tx_buf || xfer->rx_buf) && xfer->len) {
reinit_completion(>xfer_completion);
fallback_pio:
--
2.27.0
[PATCH 5.11 181/775] media: allegro: Fix use after free on error
From: Dan Carpenter
[ Upstream commit ce814ad4bb52bfc7c0472e6da0aa742ab88f4361 ]
The "channel" is added to the "dev->channels" but then if
v4l2_m2m_ctx_init() fails then we free "channel" but it's still on the
list so it could lead to a use after free. Let's not add it to the
list until after v4l2_m2m_ctx_init() succeeds.
Fixes: cc62c74749a3 ("media: allegro: add missed checks in allegro_open()")
Signed-off-by: Dan Carpenter
Reviewed-by: Michael Tretter
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/allegro-dvt/allegro-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c
b/drivers/staging/media/allegro-dvt/allegro-core.c
index 9f718f43282bc..640451134072b 100644
--- a/drivers/staging/media/allegro-dvt/allegro-core.c
+++ b/drivers/staging/media/allegro-dvt/allegro-core.c
@@ -2483,8 +2483,6 @@ static int allegro_open(struct file *file)
INIT_LIST_HEAD(>buffers_reference);
INIT_LIST_HEAD(>buffers_intermediate);
- list_add(>list, >channels);
-
channel->fh.m2m_ctx = v4l2_m2m_ctx_init(dev->m2m_dev, channel,
allegro_queue_init);
@@ -2493,6 +2491,7 @@ static int allegro_open(struct file *file)
goto error;
}
+ list_add(>list, >channels);
file->private_data = >fh;
v4l2_fh_add(>fh);
--
2.27.0
[PATCH 5.11 141/775] arm64: dts: broadcom: bcm4908: use proper NAND binding
From: Rafał Miłecki
[ Upstream commit 56098be85d19cd56b59d7b3854ea035cc8cb9e95 ]
BCM4908 has controller that needs different IRQ handling just like the
BCM63138. Describe it properly.
On Linux this change fixes:
brcmstb_nand ff801800.nand: timeout waiting for command 0x9
brcmstb_nand ff801800.nand: intfc status d000
Signed-off-by: Rafał Miłecki
Signed-off-by: Florian Fainelli
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
b/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
index f873dc44ce9ca..55d9b56ac749d 100644
--- a/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
@@ -164,7 +164,7 @@
nand@1800 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ compatible = "brcm,nand-bcm63138",
"brcm,brcmnand-v7.1", "brcm,brcmnand";
reg = <0x1800 0x600>, <0x2000 0x10>;
reg-names = "nand", "nand-int-base";
interrupts = ;
--
2.27.0
[PATCH 5.11 339/775] RDMA/rtrs-srv: Release lock before call into close_sess
From: Jack Wang
[ Upstream commit 99f0c3807973359bba8f37d9198eea59fe38c32a ]
In this error case, we don't need hold mutex to call close_sess.
Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality")
Link:
https://lore.kernel.org/r/20201217141915.56989-4-jinpu.w...@cloud.ionos.com
Signed-off-by: Jack Wang
Tested-by: Lutz Pogrell
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index ed4628f032bb6..341661f42add0 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -1863,8 +1863,8 @@ reject_w_econnreset:
return rtrs_rdma_do_reject(cm_id, -ECONNRESET);
close_and_return_err:
- close_sess(sess);
mutex_unlock(>paths_mutex);
+ close_sess(sess);
return err;
}
--
2.27.0
[PATCH 5.11 347/775] RDMA/rtrs: Fix KASAN: stack-out-of-bounds bug
From: Jack Wang
[ Upstream commit 7fbc3c373eefc291ff96d48496106c106b7f81c6 ]
When KASAN is enabled, we notice warning below:
[ 483.436975]
==
[ 483.437234] BUG: KASAN: stack-out-of-bounds in
_mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.437430] Read of size 4 at addr 88a195fd7d30 by task kworker/1:3/6954
[ 483.437731] CPU: 1 PID: 6954 Comm: kworker/1:3 Kdump: loaded Tainted: G
O 5.4.82-pserver
#5.4.82-1+feature+linux+5.4.y+dbg+20201210.1532+987e7a6~deb10
[ 483.437976] Hardware name: Supermicro Super Server/X11DDW-L, BIOS 3.3
02/21/2020
[ 483.438168] Workqueue: rtrs_server_wq hb_work [rtrs_core]
[ 483.438323] Call Trace:
[ 483.438486] dump_stack+0x96/0xe0
[ 483.438646] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.438802] print_address_description.constprop.6+0x1b/0x220
[ 483.438966] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.439133] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.439285] __kasan_report.cold.9+0x1a/0x32
[ 483.439444] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.439597] kasan_report+0x10/0x20
[ 483.439752] _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib]
[ 483.439910] ? update_sd_lb_stats+0xfb1/0xfc0
[ 483.440073] ? set_reg_wr+0x520/0x520 [mlx5_ib]
[ 483.440222] ? update_group_capacity+0x340/0x340
[ 483.440377] ? find_busiest_group+0x314/0x870
[ 483.440526] ? update_sd_lb_stats+0xfc0/0xfc0
[ 483.440683] ? __bitmap_and+0x6f/0x100
[ 483.440832] ? __lock_acquire+0xa2/0x2150
[ 483.440979] ? __lock_acquire+0xa2/0x2150
[ 483.441128] ? __lock_acquire+0xa2/0x2150
[ 483.441279] ? debug_lockdep_rcu_enabled+0x23/0x60
[ 483.441430] ? lock_downgrade+0x390/0x390
[ 483.441582] ? __lock_acquire+0xa2/0x2150
[ 483.441729] ? __lock_acquire+0xa2/0x2150
[ 483.441876] ? newidle_balance+0x425/0x8f0
[ 483.442024] ? __lock_acquire+0xa2/0x2150
[ 483.442172] ? debug_lockdep_rcu_enabled+0x23/0x60
[ 483.442330] hb_work+0x15d/0x1d0 [rtrs_core]
[ 483.442479] ? schedule_hb+0x50/0x50 [rtrs_core]
[ 483.442627] ? lock_downgrade+0x390/0x390
[ 483.442781] ? process_one_work+0x40d/0xa50
[ 483.442931] process_one_work+0x4ee/0xa50
[ 483.443082] ? pwq_dec_nr_in_flight+0x110/0x110
[ 483.443231] ? do_raw_spin_lock+0x119/0x1d0
[ 483.443383] worker_thread+0x65/0x5c0
[ 483.443532] ? process_one_work+0xa50/0xa50
[ 483.451839] kthread+0x1e2/0x200
[ 483.451983] ? kthread_create_on_node+0xc0/0xc0
[ 483.452139] ret_from_fork+0x3a/0x50
The problem is we use wrong type when send wr, hw driver expect the type
of IB_WR_RDMA_WRITE_WITH_IMM wr should be ib_rdma_wr, and doing
container_of to access member. The fix is simple use ib_rdma_wr instread
of ib_send_wr.
Fixes: c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and
server modules")
Link:
https://lore.kernel.org/r/20201217141915.56989-20-jinpu.w...@cloud.ionos.com
Signed-off-by: Jack Wang
Reviewed-by: Gioh Kim
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/rtrs/rtrs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs.c
b/drivers/infiniband/ulp/rtrs/rtrs.c
index df52427f17106..da4ff764dd3f0 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs.c
@@ -182,16 +182,16 @@ int rtrs_post_rdma_write_imm_empty(struct rtrs_con *con,
struct ib_cqe *cqe,
u32 imm_data, enum ib_send_flags flags,
struct ib_send_wr *head)
{
- struct ib_send_wr wr;
+ struct ib_rdma_wr wr;
- wr = (struct ib_send_wr) {
- .wr_cqe = cqe,
- .send_flags = flags,
- .opcode = IB_WR_RDMA_WRITE_WITH_IMM,
- .ex.imm_data= cpu_to_be32(imm_data),
+ wr = (struct ib_rdma_wr) {
+ .wr.wr_cqe = cqe,
+ .wr.send_flags = flags,
+ .wr.opcode = IB_WR_RDMA_WRITE_WITH_IMM,
+ .wr.ex.imm_data = cpu_to_be32(imm_data),
};
- return rtrs_post_send(con->qp, head, );
+ return rtrs_post_send(con->qp, head, );
}
EXPORT_SYMBOL_GPL(rtrs_post_rdma_write_imm_empty);
--
2.27.0
[PATCH 5.11 336/775] fdt: Properly handle "no-map" field in the memory region
From: KarimAllah Ahmed
[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]
Mark the memory region with NOMAP flag instead of completely removing it
from the memory blocks. That makes the FDT handling consistent with the EFI
memory map handling.
Cc: Rob Herring
Cc: Frank Rowand
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Quentin Perret
Link: https://lore.kernel.org/r/20210115114544.1830068-2-qper...@google.com
Signed-off-by: Rob Herring
Signed-off-by: Sasha Levin
---
drivers/of/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index feb0f2d67fc5f..427b534d60d2d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1147,7 +1147,7 @@ int __init __weak
early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
if (nomap)
- return memblock_remove(base, size);
+ return memblock_mark_nomap(base, size);
return memblock_reserve(base, size);
}
--
2.27.0
[PATCH 5.11 379/775] auxdisplay: Fix duplicate CHARLCD config symbol
From: Geert Uytterhoeven
[ Upstream commit b45616445a6e346daf8a173a0c51413aec067ebb ]
A second CHARLCD config symbol was added instead of moving the existing
one. Fix this by removing the old one.
Fixes: 718e05ed92ecac0d ("auxdisplay: Introduce hd44780_common.[ch]")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Miguel Ojeda
Signed-off-by: Sasha Levin
---
drivers/auxdisplay/Kconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index a2b59b84bb881..1509cb74705a3 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -507,6 +507,3 @@ config PANEL
depends on PARPORT
select AUXDISPLAY
select PARPORT_PANEL
-
-config CHARLCD
- tristate "Character LCD core support" if COMPILE_TEST
--
2.27.0
[PATCH 5.11 191/775] drm/virtio: make sure context is created in gem open
From: Chia-I Wu
[ Upstream commit 8aeef9d4f48917ce85710949b079548974b4a638 ]
The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is
the first ioctl on the drm_file.
Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the
first 3D ioctl")
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
Signed-off-by: Chia-I Wu
Link:
http://patchwork.freedesktop.org/patch/msgid/20210107210726.269584-1-olva...@gmail.com
Reviewed-by: Gurchetan Singh
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index c30c75ee83fce..8502400b2f9c9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -39,9 +39,6 @@ static int virtio_gpu_gem_create(struct drm_file *file,
int ret;
u32 handle;
- if (vgdev->has_virgl_3d)
- virtio_gpu_create_context(dev, file);
-
ret = virtio_gpu_object_create(vgdev, params, , NULL);
if (ret < 0)
return ret;
@@ -119,6 +116,11 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
if (!vgdev->has_virgl_3d)
goto out_notify;
+ /* the context might still be missing when the first ioctl is
+* DRM_IOCTL_MODE_CREATE_DUMB or DRM_IOCTL_PRIME_FD_TO_HANDLE
+*/
+ virtio_gpu_create_context(obj->dev, file);
+
objs = virtio_gpu_array_alloc(1);
if (!objs)
return -ENOMEM;
--
2.27.0
[PATCH 5.11 032/775] ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
From: Krzysztof Kozlowski
[ Upstream commit 77e6a5467cb8657cf8b5e610a30a4c502085e4f9 ]
The Samsung PMIC datasheets describe the interrupt line as active low
with a requirement of acknowledge from the CPU. Without specifying the
interrupt type in Devicetree, kernel might apply some fixed
configuration, not necessarily working for this hardware.
Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree")
Signed-off-by: Krzysztof Kozlowski
Link: https://lore.kernel.org/r/20201210212903.216728-4-k...@kernel.org
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/exynos5250-spring.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 9d2baea62d0d7..fba1462b19dfd 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -109,7 +109,7 @@
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_NONE>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_irq _dvs _ds>;
wakeup-source;
--
2.27.0
[PATCH 5.4 298/340] mtd: spi-nor: core: Add erase size check for erase command initialization
From: Takahiro Kuwano
commit 58fa22f68fcaff20ce4d08a6adffa64f65ccd37d upstream.
Even if erase type is same as previous region, erase size can be different
if the previous region is overlaid region. Since 'region->size' is assigned
to 'cmd->size' for overlaid region, comparing 'erase->size' and 'cmd->size'
can detect previous overlaid region.
Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR
flash memories")
Cc: sta...@vger.kernel.org
Signed-off-by: Takahiro Kuwano
[ta: Add Fixes tag and Cc to stable]
Signed-off-by: Tudor Ambarus
Link:
https://lore.kernel.org/r/13d47e8d8991b8a7fd8cc7b9e2a5319c56df35cc.1601612872.git.takahiro.kuw...@infineon.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/spi-nor/spi-nor.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1153,6 +1153,7 @@ static int spi_nor_init_erase_cmd_list(s
goto destroy_erase_cmd_list;
if (prev_erase != erase ||
+ erase->size != cmd->size ||
region->offset & SNOR_OVERLAID_REGION) {
cmd = spi_nor_init_erase_cmd(region, erase);
if (IS_ERR(cmd)) {
[PATCH 5.11 038/775] Bluetooth: hci_qca: Fix memleak in qca_controller_memdump
From: Dinghao Liu
[ Upstream commit 71f8e707557b9bc25dc90a59a752528d4e7c1cbf ]
When __le32_to_cpu() fails, qca_memdump should be freed
just like when vmalloc() fails.
Fixes: d841502c79e3f ("Bluetooth: hci_qca: Collect controller memory dump
during SSR")
Signed-off-by: Dinghao Liu
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
---
drivers/bluetooth/hci_qca.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4a963682c7021..5dbcb7c42b805 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1024,7 +1024,9 @@ static void qca_controller_memdump(struct work_struct
*work)
dump_size = __le32_to_cpu(dump->dump_size);
if (!(dump_size)) {
bt_dev_err(hu->hdev, "Rx invalid memdump size");
+ kfree(qca_memdump);
kfree_skb(skb);
+ qca->qca_memdump = NULL;
mutex_unlock(>hci_memdump_lock);
return;
}
--
2.27.0
[PATCH 5.10 406/663] PCI: Align checking of syscall user config accessors
From: Heiner Kallweit
[ Upstream commit ef9e4005cbaf022c6251263aa27836acccaef65d ]
After 34e3207205ef ("PCI: handle positive error codes"),
pci_user_read_config_*() and pci_user_write_config_*() return 0 or negative
errno values, not PCIBIOS_* values like PCIBIOS_SUCCESSFUL or
PCIBIOS_BAD_REGISTER_NUMBER.
Remove comparisons with PCIBIOS_SUCCESSFUL and check only for non-zero. It
happens that PCIBIOS_SUCCESSFUL is zero, so this is not a functional
change, but it aligns this code with the user accessors.
[bhelgaas: commit log]
Fixes: 34e3207205ef ("PCI: handle positive error codes")
Link: https://lore.kernel.org/r/f1220314-e518-1e18-bf94-8e6f8c703...@gmail.com
Signed-off-by: Heiner Kallweit
Signed-off-by: Bjorn Helgaas
Signed-off-by: Sasha Levin
---
drivers/pci/syscall.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index 31e39558d49d8..8b003c890b87b 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -20,7 +20,7 @@ SYSCALL_DEFINE5(pciconfig_read, unsigned long, bus, unsigned
long, dfn,
u16 word;
u32 dword;
long err;
- long cfg_ret;
+ int cfg_ret;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -46,7 +46,7 @@ SYSCALL_DEFINE5(pciconfig_read, unsigned long, bus, unsigned
long, dfn,
}
err = -EIO;
- if (cfg_ret != PCIBIOS_SUCCESSFUL)
+ if (cfg_ret)
goto error;
switch (len) {
@@ -105,7 +105,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus,
unsigned long, dfn,
if (err)
break;
err = pci_user_write_config_byte(dev, off, byte);
- if (err != PCIBIOS_SUCCESSFUL)
+ if (err)
err = -EIO;
break;
@@ -114,7 +114,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus,
unsigned long, dfn,
if (err)
break;
err = pci_user_write_config_word(dev, off, word);
- if (err != PCIBIOS_SUCCESSFUL)
+ if (err)
err = -EIO;
break;
@@ -123,7 +123,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus,
unsigned long, dfn,
if (err)
break;
err = pci_user_write_config_dword(dev, off, dword);
- if (err != PCIBIOS_SUCCESSFUL)
+ if (err)
err = -EIO;
break;
--
2.27.0
[PATCH 5.11 199/775] media: camss: missing error code in msm_video_register()
From: Dan Carpenter
[ Upstream commit 9c67ed2ab299123872be14a3dc2ea44ce7e4538b ]
This error path returns success but it should return -EINVAL.
Fixes: cba3819d1e93 ("media: camss: Format configuration per hardware version")
Signed-off-by: Dan Carpenter
Reviewed-by: Robert Foss
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/qcom/camss/camss-video.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/qcom/camss/camss-video.c
b/drivers/media/platform/qcom/camss/camss-video.c
index 2fa3214775d58..97cea7c4d7697 100644
--- a/drivers/media/platform/qcom/camss/camss-video.c
+++ b/drivers/media/platform/qcom/camss/camss-video.c
@@ -961,6 +961,7 @@ int msm_video_register(struct camss_video *video, struct
v4l2_device *v4l2_dev,
video->nformats = ARRAY_SIZE(formats_rdi_8x96);
}
} else {
+ ret = -EINVAL;
goto error_video_register;
}
--
2.27.0
[PATCH 5.11 256/775] ASoC: qcom: Fix typo error in HDMI regmap config callbacks
From: Srinivasa Rao Mandadapu
[ Upstream commit e681b1a6d706b4e54c3847bb822531b4660234f3 ]
Had a typo in lpass platform driver that resulted in crash
during suspend/resume with an HDMI dongle connected.
The regmap read/write/volatile regesters validation callbacks in lpass-cpu
were using MI2S rdma_channels count instead of hdmi_rdma_channels.
This typo error causing to read registers from the regmap beyond the length
of the mapping created by ioremap().
This fix avoids the need for reducing number hdmi_rdma_channels,
which is done in
commit 7dfe20ee92f6 ("ASoC: qcom: Fix number of HDMI RDMA channels on sc7180").
So reverting the same.
Fixes: 7cb37b7bd0d3c ("ASoC: qcom: Add support for lpass hdmi driver")
Signed-off-by: Srinivasa Rao Mandadapu
Link: https://lore.kernel.org/r/20210202062727.22469-1-sriva...@codeaurora.org
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/qcom/lpass-cpu.c| 8
sound/soc/qcom/lpass-sc7180.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 73ca24c0a08b7..8e5415c9234f1 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -594,7 +594,7 @@ static bool lpass_hdmi_regmap_writeable(struct device *dev,
unsigned int reg)
return true;
}
- for (i = 0; i < v->rdma_channels; ++i) {
+ for (i = 0; i < v->hdmi_rdma_channels; ++i) {
if (reg == LPAIF_HDMI_RDMACTL_REG(v, i))
return true;
if (reg == LPAIF_HDMI_RDMABASE_REG(v, i))
@@ -640,7 +640,7 @@ static bool lpass_hdmi_regmap_readable(struct device *dev,
unsigned int reg)
if (reg == LPASS_HDMITX_APP_IRQSTAT_REG(v))
return true;
- for (i = 0; i < v->rdma_channels; ++i) {
+ for (i = 0; i < v->hdmi_rdma_channels; ++i) {
if (reg == LPAIF_HDMI_RDMACTL_REG(v, i))
return true;
if (reg == LPAIF_HDMI_RDMABASE_REG(v, i))
@@ -667,7 +667,7 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev,
unsigned int reg)
if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v))
return true;
- for (i = 0; i < v->rdma_channels; ++i) {
+ for (i = 0; i < v->hdmi_rdma_channels; ++i) {
if (reg == LPAIF_HDMI_RDMACURR_REG(v, i))
return true;
}
@@ -817,7 +817,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
platform_device *pdev)
}
lpass_hdmi_regmap_config.max_register =
LPAIF_HDMI_RDMAPER_REG(variant,
- variant->hdmi_rdma_channels);
+ variant->hdmi_rdma_channels - 1);
drvdata->hdmiif_map = devm_regmap_init_mmio(dev,
drvdata->hdmiif,
_hdmi_regmap_config);
if (IS_ERR(drvdata->hdmiif_map)) {
diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index 735c9dac28f26..8c168d3c589e9 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -171,7 +171,7 @@ static struct lpass_variant sc7180_data = {
.rdma_channels = 5,
.hdmi_rdma_reg_base = 0x64000,
.hdmi_rdma_reg_stride = 0x1000,
- .hdmi_rdma_channels = 3,
+ .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride = 0x1000,
--
2.27.0
[PATCH 5.11 045/775] firmware: arm_scmi: Fix call site of scmi_notification_exit
From: Cristian Marussi
[ Upstream commit a90b6543bf062d65292b2c76f1630507d1c9d8ec ]
Call scmi_notification_exit() only when SCMI platform driver instance has
been really successfully removed.
Link: https://lore.kernel.org/r/20210112191326.29091-1-cristian.maru...@arm.com
Fixes: 6b8a69131dc63 ("firmware: arm_scmi: Enable notification core")
Signed-off-by: Cristian Marussi
[sudeep.holla: Move the call outside the list mutex locking]
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
---
drivers/firmware/arm_scmi/driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index 5392e1fc6b4ef..cacdf1589b101 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -848,8 +848,6 @@ static int scmi_remove(struct platform_device *pdev)
struct scmi_info *info = platform_get_drvdata(pdev);
struct idr *idr = >tx_idr;
- scmi_notification_exit(>handle);
-
mutex_lock(_list_mutex);
if (info->users)
ret = -EBUSY;
@@ -860,6 +858,8 @@ static int scmi_remove(struct platform_device *pdev)
if (ret)
return ret;
+ scmi_notification_exit(>handle);
+
/* Safe to free channels since no more users */
ret = idr_for_each(idr, info->desc->ops->chan_free, idr);
idr_destroy(>tx_idr);
--
2.27.0
[PATCH 5.10 160/663] media: i2c: ov5670: Fix PIXEL_RATE minimum value
From: Jacopo Mondi
[ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ]
The driver currently reports a single supported value for
V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0,
which is very risky, as userspace might accidentally use it as divider
when calculating the time duration of a line.
Fix this by using as minimum the only supported value when registering
the control.
Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support")
Signed-off-by: Jacopo Mondi
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/i2c/ov5670.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
index f26252e35e08d..04d3f14902017 100644
--- a/drivers/media/i2c/ov5670.c
+++ b/drivers/media/i2c/ov5670.c
@@ -2084,7 +2084,8 @@ static int ov5670_init_controls(struct ov5670 *ov5670)
/* By default, V4L2_CID_PIXEL_RATE is read only */
ov5670->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops,
- V4L2_CID_PIXEL_RATE, 0,
+ V4L2_CID_PIXEL_RATE,
+ link_freq_configs[0].pixel_rate,
link_freq_configs[0].pixel_rate,
1,
link_freq_configs[0].pixel_rate);
--
2.27.0
[PATCH 5.11 013/775] bfq: Avoid false bfq queue merging
From: Jan Kara
commit 41e76c85660c022c6bf5713bfb6c21e64a487cec upstream.
bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it
makes sense to merge current bfq queue with the in-service queue.
However if the in-service queue is freshly scheduled and didn't dispatch
any requests yet, bfqd->in_serv_last_pos is stale and contains value
from the previously scheduled bfq queue which can thus result in a bogus
decision that the two queues should be merged. This bug can be observed
for example with the following fio jobfile:
[global]
direct=0
ioengine=sync
invalidate=1
size=1g
rw=read
[reader]
numjobs=4
directory=/mnt
where the 4 processes will end up in the one shared bfq queue although
they do IO to physically very distant files (for some reason I was able to
observe this only with slice_idle=1ms setting).
Fix the problem by invalidating bfqd->in_serv_last_pos when switching
in-service queue.
Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging")
CC: sta...@vger.kernel.org
Signed-off-by: Jan Kara
Acked-by: Paolo Valente
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
block/bfq-iosched.c |1 +
1 file changed, 1 insertion(+)
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2937,6 +2937,7 @@ static void __bfq_set_in_service_queue(s
}
bfqd->in_service_queue = bfqq;
+ bfqd->in_serv_last_pos = 0;
}
/*
[PATCH 5.4 300/340] fs/affs: release old buffer head on error path
From: Pan Bian
commit 70779b897395b330ba5a47bed84f94178da599f9 upstream.
The reference count of the old buffer head should be decremented on path
that fails to get the new buffer head.
Fixes: 6b4657667ba0 ("fs/affs: add rename exchange")
CC: sta...@vger.kernel.org # 4.14+
Signed-off-by: Pan Bian
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
---
fs/affs/namei.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/affs/namei.c
+++ b/fs/affs/namei.c
@@ -460,8 +460,10 @@ affs_xrename(struct inode *old_dir, stru
return -EIO;
bh_new = affs_bread(sb, d_inode(new_dentry)->i_ino);
- if (!bh_new)
+ if (!bh_new) {
+ affs_brelse(bh_old);
return -EIO;
+ }
/* Remove old header from its parent directory. */
affs_lock_dir(old_dir);
[PATCH 5.10 578/663] arm64: Extend workaround for erratum 1024718 to all versions of Cortex-A55
From: Suzuki K Poulose
commit c0b15c25d25171db4b70cc0b7dbc1130ee94017d upstream.
The erratum 1024718 affects Cortex-A55 r0p0 to r2p0. However
we apply the work around for r0p0 - r1p0. Unfortunately this
won't be fixed for the future revisions for the CPU. Thus
extend the work around for all versions of A55, to cover
for r2p0 and any future revisions.
Cc: sta...@vger.kernel.org
Cc: Catalin Marinas
Cc: Will Deacon
Cc: James Morse
Cc: Kunihiko Hayashi
Signed-off-by: Suzuki K Poulose
Link: https://lore.kernel.org/r/20210203230057.3961239-1-suzuki.poul...@arm.com
[will: Update Kconfig help text]
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/Kconfig |2 +-
arch/arm64/kernel/cpufeature.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -520,7 +520,7 @@ config ARM64_ERRATUM_1024718
help
This option adds a workaround for ARM Cortex-A55 Erratum 1024718.
- Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
+ Affected Cortex-A55 cores (all revisions) could cause incorrect
update of the hardware dirty bit when the DBM/AP bits are updated
without a break-before-make. The workaround is to disable the usage
of hardware DBM locally on the affected cores. CPUs not affected by
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1457,7 +1457,7 @@ static bool cpu_has_broken_dbm(void)
/* List of CPUs which have broken DBM support. */
static const struct midr_range cpus[] = {
#ifdef CONFIG_ARM64_ERRATUM_1024718
- MIDR_RANGE(MIDR_CORTEX_A55, 0, 0, 1, 0), // A55 r0p0 -r1p0
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A55),
/* Kryo4xx Silver (rdpe => r1p0) */
MIDR_REV(MIDR_QCOM_KRYO_4XX_SILVER, 0xd, 0xe),
#endif
[PATCH 5.10 264/663] regulator: qcom-rpmh-regulator: add pm8009-1 chip revision
From: Dmitry Baryshkov
[ Upstream commit 951384cabc5dfb09251d440dbc26058eba86f97e ]
PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.
Signed-off-by: Dmitry Baryshkov
Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
Reviewed-by: Vinod Koul
Link:
https://lore.kernel.org/r/20201231122348.637917-4-dmitry.barysh...@linaro.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/regulator/qcom-rpmh-regulator.c | 26 +
1 file changed, 26 insertions(+)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c
b/drivers/regulator/qcom-rpmh-regulator.c
index a22c4b5f64f7e..ba838c4cf2b8b 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -732,6 +732,15 @@ static const struct rpmh_vreg_hw_data pmic5_hfsmps515 = {
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
};
+static const struct rpmh_vreg_hw_data pmic5_hfsmps515_1 = {
+ .regulator_type = VRM,
+ .ops = _regulator_vrm_ops,
+ .voltage_range = REGULATOR_LINEAR_RANGE(90, 0, 4, 16000),
+ .n_voltages = 5,
+ .pmic_mode_map = pmic_mode_map_pmic5_smps,
+ .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
+};
+
static const struct rpmh_vreg_hw_data pmic5_bob = {
.regulator_type = VRM,
.ops = _regulator_vrm_bypass_ops,
@@ -878,6 +887,19 @@ static const struct rpmh_vreg_init_data pm8009_vreg_data[]
= {
{},
};
+static const struct rpmh_vreg_init_data pm8009_1_vreg_data[] = {
+ RPMH_VREG("smps1", "smp%s1", _hfsmps510, "vdd-s1"),
+ RPMH_VREG("smps2", "smp%s2", _hfsmps515_1, "vdd-s2"),
+ RPMH_VREG("ldo1", "ldo%s1", _nldo, "vdd-l1"),
+ RPMH_VREG("ldo2", "ldo%s2", _nldo, "vdd-l2"),
+ RPMH_VREG("ldo3", "ldo%s3", _nldo, "vdd-l3"),
+ RPMH_VREG("ldo4", "ldo%s4", _nldo, "vdd-l4"),
+ RPMH_VREG("ldo5", "ldo%s5", _pldo, "vdd-l5-l6"),
+ RPMH_VREG("ldo6", "ldo%s6", _pldo, "vdd-l5-l6"),
+ RPMH_VREG("ldo7", "ldo%s6", _pldo_lv, "vdd-l7"),
+ {},
+};
+
static const struct rpmh_vreg_init_data pm6150_vreg_data[] = {
RPMH_VREG("smps1", "smp%s1", _ftsmps510, "vdd-s1"),
RPMH_VREG("smps2", "smp%s2", _ftsmps510, "vdd-s2"),
@@ -976,6 +998,10 @@ static const struct of_device_id __maybe_unused
rpmh_regulator_match_table[] = {
.compatible = "qcom,pm8009-rpmh-regulators",
.data = pm8009_vreg_data,
},
+ {
+ .compatible = "qcom,pm8009-1-rpmh-regulators",
+ .data = pm8009_1_vreg_data,
+ },
{
.compatible = "qcom,pm8150-rpmh-regulators",
.data = pm8150_vreg_data,
--
2.27.0
[PATCH 5.11 087/775] ath11k: fix a locking bug in ath11k_mac_op_start()
From: Dan Carpenter
[ Upstream commit c202e2ebe1dc454ad54fd0018c023ec553d47284 ]
This error path leads to a Smatch warning:
drivers/net/wireless/ath/ath11k/mac.c:4269 ath11k_mac_op_start()
error: double unlocked '>conf_mutex' (orig line 4251)
We're not holding the lock when we do the "goto err;" so it leads to a
double unlock. The fix is to hold the lock for a little longer.
Fixes: c83c500b55b6 ("ath11k: enable idle power save mode")
Signed-off-by: Dan Carpenter
[kv...@codeaurora.org: move also rcu_assign_pointer() call]
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/YBk4GoeE+yc0wlJH@mwanda
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/ath11k/mac.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index c1608f64ea95d..7d799fe6fbd89 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -4248,11 +4248,6 @@ static int ath11k_mac_op_start(struct ieee80211_hw *hw)
/* Configure the hash seed for hash based reo dest ring selection */
ath11k_wmi_pdev_lro_cfg(ar, ar->pdev->pdev_id);
- mutex_unlock(>conf_mutex);
-
- rcu_assign_pointer(ab->pdevs_active[ar->pdev_idx],
- >pdevs[ar->pdev_idx]);
-
/* allow device to enter IMPS */
if (ab->hw_params.idle_ps) {
ret = ath11k_wmi_pdev_set_param(ar,
WMI_PDEV_PARAM_IDLE_PS_CONFIG,
@@ -4262,6 +4257,12 @@ static int ath11k_mac_op_start(struct ieee80211_hw *hw)
goto err;
}
}
+
+ mutex_unlock(>conf_mutex);
+
+ rcu_assign_pointer(ab->pdevs_active[ar->pdev_idx],
+ >pdevs[ar->pdev_idx]);
+
return 0;
err:
--
2.27.0
[PATCH 5.10 300/663] spi: imx: Dont print error on -EPROBEDEFER
From: Guido Günther
[ Upstream commit 8346633f2c87713a1852d802305e03555e9a9fce ]
This avoids
[0.962538] spi_imx 3082.spi: bitbang start failed with -517
durig driver probe.
Fixes: 8197f489f4c4 ("spi: imx: Fix failure path leak on GPIO request error
correctly")
Signed-off-by: Guido Günther
Reviewed-by: Fabio Estevam
Link:
https://lore.kernel.org/r/0f51ab42e7c7a3452f2f8652794d81584303ea0d.1610987414.git@sigxcpu.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
drivers/spi/spi-imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8df5e973404f0..831a38920fa98 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1713,7 +1713,7 @@ static int spi_imx_probe(struct platform_device *pdev)
master->dev.of_node = pdev->dev.of_node;
ret = spi_bitbang_start(_imx->bitbang);
if (ret) {
- dev_err(>dev, "bitbang start failed with %d\n", ret);
+ dev_err_probe(>dev, ret, "bitbang start failed\n");
goto out_bitbang_start;
}
--
2.27.0
[PATCH 5.10 077/663] arm64: dts: meson: fix broken wifi node for Khadas VIM3L
From: Artem Lapkin
[ Upstream commit 39be8f441f78908e97ff913571e10ec03387a63a ]
move _emmc_a ... from /* */ commented area, because cant load wifi fw
without sd-uhs-sdr50 option on VIM3L
[ 11.686590] brcmfmac: brcmf_chip_cores_check: CPU core not detected
[ 11.696382] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[ 11.706240] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[ 11.715890] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
[ 13.718424] brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not
supported
Signed-off-by: Artem Lapkin
Fixes: f1bb924e8f5b ("arm64: dts: meson: fix mmc0 tuning error on Khadas VIM3")
Reviewed-by: Neil Armstrong
Signed-off-by: Kevin Hilman
Link: https://lore.kernel.org/r/20210129085041.1408540-1-...@khadas.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
index 4b517ca720597..06de0b1ce7267 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
@@ -89,13 +89,12 @@
status = "okay";
};
-_emmc_a {
- sd-uhs-sdr50;
-};
-
{
phys = <_phy0>, <_phy1>;
phy-names = "usb2-phy0", "usb2-phy1";
};
*/
+_emmc_a {
+ sd-uhs-sdr50;
+};
--
2.27.0
[PATCH 5.10 424/663] soundwire: export sdw_write/read_no_pm functions
From: Bard Liao
[ Upstream commit 167790abb90fa073d8341ee0e408ccad3d2109cd ]
sdw_write_no_pm and sdw_read_no_pm are useful when we want to do IO
without touching PM.
Fixes: 0231453bc08f ('soundwire: bus: add clock stop helpers')
Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of read/write
functions')
Signed-off-by: Bard Liao
Link:
https://lore.kernel.org/r/20210122070634.12825-5-yung-chuan.l...@linux.intel.com
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
---
drivers/soundwire/bus.c | 7 ---
include/linux/soundwire/sdw.h | 2 ++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 944a4222b2f9d..3c05ef105c073 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -405,10 +405,11 @@ sdw_nwrite_no_pm(struct sdw_slave *slave, u32 addr,
size_t count, u8 *val)
return sdw_transfer(slave->bus, );
}
-static int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value)
+int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value)
{
return sdw_nwrite_no_pm(slave, addr, 1, );
}
+EXPORT_SYMBOL(sdw_write_no_pm);
static int
sdw_bread_no_pm(struct sdw_bus *bus, u16 dev_num, u32 addr)
@@ -476,8 +477,7 @@ int sdw_bwrite_no_pm_unlocked(struct sdw_bus *bus, u16
dev_num, u32 addr, u8 val
}
EXPORT_SYMBOL(sdw_bwrite_no_pm_unlocked);
-static int
-sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
+int sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
{
u8 buf;
int ret;
@@ -488,6 +488,7 @@ sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
else
return buf;
}
+EXPORT_SYMBOL(sdw_read_no_pm);
static int sdw_update_no_pm(struct sdw_slave *slave, u32 addr, u8 mask, u8 val)
{
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index 41cc1192f9aab..57cda3a3a9d95 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -1001,6 +1001,8 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus);
int sdw_read(struct sdw_slave *slave, u32 addr);
int sdw_write(struct sdw_slave *slave, u32 addr, u8 value);
+int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value);
+int sdw_read_no_pm(struct sdw_slave *slave, u32 addr);
int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
int sdw_nwrite(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
--
2.27.0
[PATCH 5.11 292/775] ima: Free IMA measurement buffer after kexec syscall
From: Lakshmi Ramasubramanian
[ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ]
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. This buffer is not freed before
completing the kexec system call resulting in memory leak.
Add ima_buffer field in "struct kimage" to store the virtual address
of the buffer allocated for the IMA measurement list.
Free the memory allocated for the IMA measurement list in
kimage_file_post_load_cleanup() function.
Signed-off-by: Lakshmi Ramasubramanian
Suggested-by: Tyler Hicks
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Tyler Hicks
Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin
---
include/linux/kexec.h | 5 +
kernel/kexec_file.c| 5 +
security/integrity/ima/ima_kexec.c | 2 ++
3 files changed, 12 insertions(+)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 9e93bef529680..5f61389f5f361 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -300,6 +300,11 @@ struct kimage {
/* Information for loading purgatory */
struct purgatory_info purgatory_info;
#endif
+
+#ifdef CONFIG_IMA_KEXEC
+ /* Virtual address of IMA measurement buffer for kexec syscall */
+ void *ima_buffer;
+#endif
};
/* kexec interface functions */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b02086d704923..5c3447cf7ad58 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -166,6 +166,11 @@ void kimage_file_post_load_cleanup(struct kimage *image)
vfree(pi->sechdrs);
pi->sechdrs = NULL;
+#ifdef CONFIG_IMA_KEXEC
+ vfree(image->ima_buffer);
+ image->ima_buffer = NULL;
+#endif /* CONFIG_IMA_KEXEC */
+
/* See if architecture has anything to cleanup post load */
arch_kimage_file_post_load_cleanup(image);
diff --git a/security/integrity/ima/ima_kexec.c
b/security/integrity/ima/ima_kexec.c
index 206ddcaa5c67a..e29bea3dd4ccd 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -129,6 +129,8 @@ void ima_add_kexec_buffer(struct kimage *image)
return;
}
+ image->ima_buffer = kexec_buffer;
+
pr_debug("kexec measurement buffer for the loaded kernel at 0x%lx.\n",
kbuf.mem);
}
--
2.27.0
[PATCH 5.10 585/663] watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ
From: Sai Prakash Ranjan
commit a4f3407c41605d14f09e490045d0609990cd5d94 upstream.
As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
of watchdog control register is wakeup interrupt enable bit and
not related to bark interrupt at all, BIT(0) is used for that.
So remove incorrect usage of this bit when supporting bark irq for
pre-timeout notification. Currently with this bit set and bark
interrupt specified, pre-timeout notification and/or watchdog
reset/bite does not occur.
Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the bark irq is
available")
Cc: sta...@vger.kernel.org
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Guenter Roeck
Reviewed-by: Stephen Boyd
Link:
https://lore.kernel.org/r/20210126150241.10009-1-saiprakash.ran...@codeaurora.org
Signed-off-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/watchdog/qcom-wdt.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
--- a/drivers/watchdog/qcom-wdt.c
+++ b/drivers/watchdog/qcom-wdt.c
@@ -22,7 +22,6 @@ enum wdt_reg {
};
#define QCOM_WDT_ENABLEBIT(0)
-#define QCOM_WDT_ENABLE_IRQBIT(1)
static const u32 reg_offset_data_apcs_tmr[] = {
[WDT_RST] = 0x38,
@@ -63,16 +62,6 @@ struct qcom_wdt *to_qcom_wdt(struct watc
return container_of(wdd, struct qcom_wdt, wdd);
}
-static inline int qcom_get_enable(struct watchdog_device *wdd)
-{
- int enable = QCOM_WDT_ENABLE;
-
- if (wdd->pretimeout)
- enable |= QCOM_WDT_ENABLE_IRQ;
-
- return enable;
-}
-
static irqreturn_t qcom_wdt_isr(int irq, void *arg)
{
struct watchdog_device *wdd = arg;
@@ -91,7 +80,7 @@ static int qcom_wdt_start(struct watchdo
writel(1, wdt_addr(wdt, WDT_RST));
writel(bark * wdt->rate, wdt_addr(wdt, WDT_BARK_TIME));
writel(wdd->timeout * wdt->rate, wdt_addr(wdt, WDT_BITE_TIME));
- writel(qcom_get_enable(wdd), wdt_addr(wdt, WDT_EN));
+ writel(QCOM_WDT_ENABLE, wdt_addr(wdt, WDT_EN));
return 0;
}
[PATCH 5.11 009/775] w1: w1_therm: Fix conversion result for negative temperatures
From: Ivan Zaentsev
commit 2f6055c26f1913763eabc66c7c27d0693561e966 upstream.
DS18B20 device driver returns an incorrect value for negative temperatures
due to a missing sign-extension in w1_DS18B20_convert_temp().
Fix by using s16 temperature value when converting to int.
Fixes: 9ace0b4dab1c (w1: w1_therm: Add support for GXCAS GX20MH01 device.)
Cc: stable
Reported-by: Paweł Marciniak
Signed-off-by: Ivan Zaentsev
Link:
https://lore.kernel.org/r/20210121093021.224764-1-ivan.zaent...@wirenboard.ru
Signed-off-by: Greg Kroah-Hartman
---
drivers/w1/slaves/w1_therm.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -667,28 +667,24 @@ static inline int w1_DS18B20_get_resolut
*/
static inline int w1_DS18B20_convert_temp(u8 rom[9])
{
- int t;
- u32 bv;
+ u16 bv;
+ s16 t;
+
+ /* Signed 16-bit value to unsigned, cpu order */
+ bv = le16_to_cpup((__le16 *)rom);
/* Config register bit R2 = 1 - GX20MH01 in 13 or 14 bit resolution
mode */
if (rom[4] & 0x80) {
- /* Signed 16-bit value to unsigned, cpu order */
- bv = le16_to_cpup((__le16 *)rom);
-
/* Insert two temperature bits from config register */
/* Avoid arithmetic shift of signed value */
bv = (bv << 2) | (rom[4] & 3);
-
- t = (int) sign_extend32(bv, 17); /* Degrees, lowest bit is 2^-6
*/
- return (t*1000)/64; /* Millidegrees */
+ t = (s16) bv; /* Degrees, lowest bit is 2^-6 */
+ return (int)t * 1000 / 64; /* Sign-extend to int;
millidegrees */
}
-
- t = (int)le16_to_cpup((__le16 *)rom);
- return t*1000/16;
+ t = (s16)bv;/* Degrees, lowest bit is 2^-4 */
+ return (int)t * 1000 / 16; /* Sign-extend to int; millidegrees */
}
-
-
/**
* w1_DS18S20_convert_temp() - temperature computation for DS18S20
* @rom: data read from device RAM (8 data bytes + 1 CRC byte)
[PATCH 5.10 408/663] drm/msm: Fix MSM_INFO_GET_IOVA with carveout
From: Iskren Chernev
[ Upstream commit 6cefa31e810404dafdfcdb94874146cea11626c2 ]
The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
!= NULL, because aspace is NULL when using vram carveout.
Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
instances")
Signed-off-by: Iskren Chernev
Tested-by: Alexey Minnekhanov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d556c353e5aea..3d0adfa6736a5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device *dev,
struct drm_file *file, struct drm_gem_object *obj,
uint64_t *iova)
{
+ struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx = file->driver_priv;
- if (!ctx->aspace)
+ if (!priv->gpu)
return -EINVAL;
/*
--
2.27.0
[PATCH 5.11 269/775] btrfs: fix double accounting of ordered extent for subpage case in btrfs_invalidapge
From: Qu Wenruo
[ Upstream commit 951c80f83d61bd4b21794c8aba829c3c1a45c2d0 ]
Commit dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could
span across a page") make btrfs_invalidapage() to search all ordered
extents.
The offending code looks like this:
again:
start = page_start;
ordered = btrfs_lookup_ordered_range(inode, start, page_end - start +
1);
if (ordred) {
end = min(page_end,
ordered->file_offset + ordered->num_bytes - 1);
/* Do the cleanup */
start = end + 1;
if (start < page_end)
goto again;
}
The behavior is indeed necessary for the incoming subpage support, but
when it iterates through all the ordered extents, it also resets the
search range @start.
This means, for the following cases, we can double account the ordered
extents, causing its bytes_left underflow:
Page offset
0 16K 32K
|<--- OE 1 --->|<--- OE 2 >|
As the first iteration will find ordered extent (OE) 1, which doesn't
cover the full page, thus after cleanup code, we need to retry again.
But again label will reset start to page_start, and we got OE 1 again,
which causes double accounting on OE 1, and cause OE 1's byte_left to
underflow.
This problem can only happen for subpage case, as for regular sectorsize
== PAGE_SIZE case, we will always find a OE ends at or after page end,
thus no way to trigger the problem.
Move the again label after start = page_start. There will be more
comprehensive rework to convert the open coded loop to a proper while
loop for subpage support.
Fixes: dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could span
across a page")
Reviewed-by: Filipe Manana
Signed-off-by: Qu Wenruo
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a8e0a6b038d3e..ad34c5a09befc 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8186,8 +8186,9 @@ static void btrfs_invalidatepage(struct page *page,
unsigned int offset,
if (!inode_evicting)
lock_extent_bits(tree, page_start, page_end, _state);
-again:
+
start = page_start;
+again:
ordered = btrfs_lookup_ordered_range(inode, start, page_end - start +
1);
if (ordered) {
found_ordered = true;
--
2.27.0
[PATCH 5.10 366/663] selftests/ftrace: Update synthetic event syntax errors
From: Tom Zanussi
[ Upstream commit b5734e997e1117afb479ffda500e36fa91aea3e8 ]
Some of the synthetic event errors and positions have changed in the
code - update those and add several more tests.
Also add a runtime check to ensure that the kernel supports dynamic
strings in synthetic events, which these tests require.
Link:
https://lkml.kernel.org/r/51402656433455baead34f068c6e9466b64df9c0.1612208610.git.zanu...@kernel.org
Fixes: 81ff92a93d95 (selftests/ftrace: Add test case for synthetic event syntax
errors)
Reported-by: Masami Hiramatsu
Signed-off-by: Tom Zanussi
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
---
.../trigger-synthetic_event_syntax_errors.tc | 35 ++-
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git
a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
index ada594fe16cb3..955e3ceea44b5 100644
---
a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
+++
b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
@@ -1,19 +1,38 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: event trigger - test synthetic_events syntax parser errors
-# requires: synthetic_events error_log
+# requires: synthetic_events error_log "char name[]' >>
synthetic_events":README
check_error() { # command-with-error-pos-by-^
ftrace_errlog_check 'synthetic_events' "$1" 'synthetic_events'
}
+check_dyn_error() { # command-with-error-pos-by-^
+ftrace_errlog_check 'synthetic_events' "$1" 'dynamic_events'
+}
+
check_error 'myevent ^chr arg' # INVALID_TYPE
-check_error 'myevent ^char str[];; int v' # INVALID_TYPE
-check_error 'myevent char ^str]; int v'# INVALID_NAME
-check_error 'myevent char ^str;[]' # INVALID_NAME
-check_error 'myevent ^char str[; int v'# INVALID_TYPE
-check_error '^mye;vent char str[]' # BAD_NAME
-check_error 'myevent char str[]; ^int' # INVALID_FIELD
-check_error '^myevent' # INCOMPLETE_CMD
+check_error 'myevent ^unsigned arg'# INCOMPLETE_TYPE
+
+check_error 'myevent char ^str]; int v'# BAD_NAME
+check_error '^mye-vent char str[]' # BAD_NAME
+check_error 'myevent char ^st-r[]' # BAD_NAME
+
+check_error 'myevent char str;^[]' # INVALID_FIELD
+check_error 'myevent char str; ^int' # INVALID_FIELD
+
+check_error 'myevent char ^str[; int v'# INVALID_ARRAY_SPEC
+check_error 'myevent char ^str[kdjdk]' # INVALID_ARRAY_SPEC
+check_error 'myevent char ^str[257]' # INVALID_ARRAY_SPEC
+
+check_error '^mye;vent char str[]' # INVALID_CMD
+check_error '^myevent ; char str[]'# INVALID_CMD
+check_error '^myevent; char str[]' # INVALID_CMD
+check_error '^myevent ;char str[]' # INVALID_CMD
+check_error '^; char str[]'# INVALID_CMD
+check_error '^;myevent char str[]' # INVALID_CMD
+check_error '^myevent' # INVALID_CMD
+
+check_dyn_error '^s:junk/myevent char str['# INVALID_DYN_CMD
exit 0
--
2.27.0
[PATCH 4.19 067/247] ibmvnic: skip send_request_unmap for timeout reset
From: Lijun Pan
[ Upstream commit 7d3a7b9ea59ddb223aec59b45fa1713c633aaed4 ]
Timeout reset will trigger the VIOS to unmap it automatically,
similarly as FAILVOER and MOBILITY events. If we unmap it
in the linux side, we will see errors like
"3003: Error 4 in REQUEST_UNMAP_RSP".
So, don't call send_request_unmap for timeout reset.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Lijun Pan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/ibm/ibmvnic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index 788d944b3b51b..0c7c0206b1be5 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -212,8 +212,13 @@ static void free_long_term_buff(struct ibmvnic_adapter
*adapter,
if (!ltb->buff)
return;
+ /* VIOS automatically unmaps the long term buffer at remote
+* end for the following resets:
+* FAILOVER, MOBILITY, TIMEOUT.
+*/
if (adapter->reset_reason != VNIC_RESET_FAILOVER &&
- adapter->reset_reason != VNIC_RESET_MOBILITY)
+ adapter->reset_reason != VNIC_RESET_MOBILITY &&
+ adapter->reset_reason != VNIC_RESET_TIMEOUT)
send_request_unmap(adapter, ltb->map_id);
dma_free_coherent(dev, ltb->size, ltb->buff, ltb->addr);
}
--
2.27.0
[PATCH 5.10 340/663] IB/cm: Avoid a loop when device has 255 ports
From: Parav Pandit
[ Upstream commit 131be26750379592f0dd6244b2a90bbb504a10bb ]
When RDMA device has 255 ports, loop iterator i overflows. Due to which
cm_add_one() port iterator loops infinitely. Use core provided port
iterator to avoid the infinite loop.
Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Link: https://lore.kernel.org/r/20210127150010.1876121-9-l...@kernel.org
Signed-off-by: Mark Bloch
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/cm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 5afd142fe8c78..8e578f73a074c 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -4332,7 +4332,7 @@ static int cm_add_one(struct ib_device *ib_device)
unsigned long flags;
int ret;
int count = 0;
- u8 i;
+ unsigned int i;
cm_dev = kzalloc(struct_size(cm_dev, port, ib_device->phys_port_cnt),
GFP_KERNEL);
@@ -4344,7 +4344,7 @@ static int cm_add_one(struct ib_device *ib_device)
cm_dev->going_down = 0;
set_bit(IB_MGMT_METHOD_SEND, reg_req.method_mask);
- for (i = 1; i <= ib_device->phys_port_cnt; i++) {
+ rdma_for_each_port (ib_device, i) {
if (!rdma_cap_ib_cm(ib_device, i))
continue;
@@ -4430,7 +4430,7 @@ static void cm_remove_one(struct ib_device *ib_device,
void *client_data)
.clr_port_cap_mask = IB_PORT_CM_SUP
};
unsigned long flags;
- int i;
+ unsigned int i;
write_lock_irqsave(_lock, flags);
list_del(_dev->list);
@@ -4440,7 +4440,7 @@ static void cm_remove_one(struct ib_device *ib_device,
void *client_data)
cm_dev->going_down = 1;
spin_unlock_irq();
- for (i = 1; i <= ib_device->phys_port_cnt; i++) {
+ rdma_for_each_port (ib_device, i) {
if (!rdma_cap_ib_cm(ib_device, i))
continue;
--
2.27.0
[PATCH 5.10 335/663] i2c: i2c-qcom-geni: Add shutdown callback for i2c
From: Roja Rani Yarubandi
[ Upstream commit e0371298ddc51761be257698554ea507ac8bf831 ]
If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.
So, implement shutdown callback to i2c driver to stop on-going transfer
and unmap DMA mappings during system "reboot" or "shutdown".
Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI
I2C controller")
Signed-off-by: Roja Rani Yarubandi
Reviewed-by: Akash Asthana
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
---
drivers/i2c/busses/i2c-qcom-geni.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 4a6dd05d6dbf9..221cba687fe02 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -375,6 +375,32 @@ static void geni_i2c_tx_msg_cleanup(struct geni_i2c_dev
*gi2c,
}
}
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
+{
+ int ret;
+ u32 geni_status;
+ struct i2c_msg *cur;
+
+ /* Resume device, as runtime suspend can happen anytime during transfer
*/
+ ret = pm_runtime_get_sync(gi2c->se.dev);
+ if (ret < 0) {
+ dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret);
+ return;
+ }
+
+ geni_status = readl_relaxed(gi2c->se.base + SE_GENI_STATUS);
+ if (geni_status & M_GENI_CMD_ACTIVE) {
+ cur = gi2c->cur;
+ geni_i2c_abort_xfer(gi2c);
+ if (cur->flags & I2C_M_RD)
+ geni_i2c_rx_msg_cleanup(gi2c, cur);
+ else
+ geni_i2c_tx_msg_cleanup(gi2c, cur);
+ }
+
+ pm_runtime_put_sync_suspend(gi2c->se.dev);
+}
+
static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
u32 m_param)
{
@@ -654,6 +680,13 @@ static int geni_i2c_remove(struct platform_device *pdev)
return 0;
}
+static void geni_i2c_shutdown(struct platform_device *pdev)
+{
+ struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
+
+ geni_i2c_stop_xfer(gi2c);
+}
+
static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
{
int ret;
@@ -718,6 +751,7 @@ MODULE_DEVICE_TABLE(of, geni_i2c_dt_match);
static struct platform_driver geni_i2c_driver = {
.probe = geni_i2c_probe,
.remove = geni_i2c_remove,
+ .shutdown = geni_i2c_shutdown,
.driver = {
.name = "geni_i2c",
.pm = _i2c_pm_ops,
--
2.27.0
[PATCH 5.11 306/775] HSI: Fix PM usage counter unbalance in ssi_hw_init
From: Zhang Qilong
[ Upstream commit aa57e77b3d28f0df07149d88c47bc0f3aa77330b ]
pm_runtime_get_sync will increment pm usage counter
even it failed. Forgetting to putting operation will
result in reference leak here. We fix it by replacing
it with pm_runtime_resume_and_get to keep usage counter
balanced.
Fixes: b209e047bc743 ("HSI: Introduce OMAP SSI driver")
Signed-off-by: Zhang Qilong
Signed-off-by: Sebastian Reichel
Signed-off-by: Sasha Levin
---
drivers/hsi/controllers/omap_ssi_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hsi/controllers/omap_ssi_core.c
b/drivers/hsi/controllers/omap_ssi_core.c
index 7596dc1646484..44a3f5660c109 100644
--- a/drivers/hsi/controllers/omap_ssi_core.c
+++ b/drivers/hsi/controllers/omap_ssi_core.c
@@ -424,7 +424,7 @@ static int ssi_hw_init(struct hsi_controller *ssi)
struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
int err;
- err = pm_runtime_get_sync(ssi->device.parent);
+ err = pm_runtime_resume_and_get(ssi->device.parent);
if (err < 0) {
dev_err(>device, "runtime PM failed %d\n", err);
return err;
--
2.27.0
[PATCH 5.10 595/663] x86: fix seq_file iteration for pat/memtype.c
From: NeilBrown
commit 3d2fc4c082448e9c05792f9b2a11c1d5db408b85 upstream.
The memtype seq_file iterator allocates a buffer in the ->start and ->next
functions and frees it in the ->show function. The preferred handling for
such resources is to free them in the subsequent ->next or ->stop function
call.
Since Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration
code and interface") there is no guarantee that ->show will be called
after ->next, so this function can now leak memory.
So move the freeing of the buffer to ->next and ->stop.
Link:
https://lkml.kernel.org/r/161248539022.21478.13874455485854739066.stgit@noble1
Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and
interface")
Signed-off-by: NeilBrown
Cc: Xin Long
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: "David S. Miller"
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Marcelo Ricardo Leitner
Cc: Neil Horman
Cc: Peter Zijlstra
Cc: Vlad Yasevich
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/pat/memtype.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -1164,12 +1164,14 @@ static void *memtype_seq_start(struct se
static void *memtype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
+ kfree(v);
++*pos;
return memtype_get_idx(*pos);
}
static void memtype_seq_stop(struct seq_file *seq, void *v)
{
+ kfree(v);
}
static int memtype_seq_show(struct seq_file *seq, void *v)
@@ -1181,8 +1183,6 @@ static int memtype_seq_show(struct seq_f
entry_print->end,
cattr_name(entry_print->type));
- kfree(entry_print);
-
return 0;
}
[PATCH 5.10 284/663] fdt: Properly handle "no-map" field in the memory region
From: KarimAllah Ahmed
[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]
Mark the memory region with NOMAP flag instead of completely removing it
from the memory blocks. That makes the FDT handling consistent with the EFI
memory map handling.
Cc: Rob Herring
Cc: Frank Rowand
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Quentin Perret
Link: https://lore.kernel.org/r/20210115114544.1830068-2-qper...@google.com
Signed-off-by: Rob Herring
Signed-off-by: Sasha Levin
---
drivers/of/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4602e467ca8b9..e4d4a1e7ef7e2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1150,7 +1150,7 @@ int __init __weak
early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
if (nomap)
- return memblock_remove(base, size);
+ return memblock_mark_nomap(base, size);
return memblock_reserve(base, size);
}
--
2.27.0
[PATCH 5.10 651/663] dm era: Fix bitset memory leaks
From: Nikos Tsironis
commit 904e6b266619c2da5c58b5dce14ae30629e39645 upstream.
Deallocate the memory allocated for the in-core bitsets when destroying
the target and in error paths.
Fixes: eec40579d84873 ("dm: add era target")
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Nikos Tsironis
Reviewed-by: Ming-Hung Tsai
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-era-target.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/md/dm-era-target.c
+++ b/drivers/md/dm-era-target.c
@@ -47,6 +47,7 @@ struct writeset {
static void writeset_free(struct writeset *ws)
{
vfree(ws->bits);
+ ws->bits = NULL;
}
static int setup_on_disk_bitset(struct dm_disk_bitset *info,
@@ -811,6 +812,8 @@ static struct era_metadata *metadata_ope
static void metadata_close(struct era_metadata *md)
{
+ writeset_free(>writesets[0]);
+ writeset_free(>writesets[1]);
destroy_persistent_data_objects(md);
kfree(md);
}
@@ -848,6 +851,7 @@ static int metadata_resize(struct era_me
r = writeset_alloc(>writesets[1], *new_size);
if (r) {
DMERR("%s: writeset_alloc failed for writeset 1", __func__);
+ writeset_free(>writesets[0]);
return r;
}
@@ -858,6 +862,8 @@ static int metadata_resize(struct era_me
, >era_array_root);
if (r) {
DMERR("%s: dm_array_resize failed", __func__);
+ writeset_free(>writesets[0]);
+ writeset_free(>writesets[1]);
return r;
}
[PATCH 5.4 332/340] gtp: use icmp_ndo_send helper
From: Jason A. Donenfeld
commit e0fce6f945a26d4e953a147fe7ca11410322c9fe upstream.
Because gtp is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.
Signed-off-by: Jason A. Donenfeld
Cc: Harald Welte
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/gtp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -546,8 +546,8 @@ static int gtp_build_skb_ip4(struct sk_b
mtu < ntohs(iph->tot_len)) {
netdev_dbg(dev, "packet too big, fragmentation needed\n");
memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
- htonl(mtu));
+ icmp_ndo_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
+ htonl(mtu));
goto err_rt;
}
[PATCH 5.10 239/663] io_uring: fix possible deadlock in io_uring_poll
From: Hao Xu
[ Upstream commit ed670c3f90a67d9e16ab6d8893be6f072d79cd4c ]
Abaci reported follow issue:
[ 30.615891] ==
[ 30.616648] WARNING: possible circular locking dependency detected
[ 30.617423] 5.11.0-rc3-next-20210115 #1 Not tainted
[ 30.618035] --
[ 30.618914] a.out/1128 is trying to acquire lock:
[ 30.619520] 88810b063868 (>mtx){+.+.}-{3:3}, at:
__ep_eventpoll_poll+0x9f/0x220
[ 30.620505]
[ 30.620505] but task is already holding lock:
[ 30.621218] 88810e952be8 (>uring_lock){+.+.}-{3:3}, at:
__x64_sys_io_uring_enter+0x3f0/0x5b0
[ 30.622349]
[ 30.622349] which lock already depends on the new lock.
[ 30.622349]
[ 30.623289]
[ 30.623289] the existing dependency chain (in reverse order) is:
[ 30.624243]
[ 30.624243] -> #1 (>uring_lock){+.+.}-{3:3}:
[ 30.625263]lock_acquire+0x2c7/0x390
[ 30.625868]__mutex_lock+0xae/0x9f0
[ 30.626451]io_cqring_overflow_flush.part.95+0x6d/0x70
[ 30.627278]io_uring_poll+0xcb/0xd0
[ 30.627890]ep_item_poll.isra.14+0x4e/0x90
[ 30.628531]do_epoll_ctl+0xb7e/0x1120
[ 30.629122]__x64_sys_epoll_ctl+0x70/0xb0
[ 30.629770]do_syscall_64+0x2d/0x40
[ 30.630332]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.631187]
[ 30.631187] -> #0 (>mtx){+.+.}-{3:3}:
[ 30.631985]check_prevs_add+0x226/0xb00
[ 30.632584]__lock_acquire+0x1237/0x13a0
[ 30.633207]lock_acquire+0x2c7/0x390
[ 30.633740]__mutex_lock+0xae/0x9f0
[ 30.634258]__ep_eventpoll_poll+0x9f/0x220
[ 30.634879]__io_arm_poll_handler+0xbf/0x220
[ 30.635462]io_issue_sqe+0xa6b/0x13e0
[ 30.635982]__io_queue_sqe+0x10b/0x550
[ 30.636648]io_queue_sqe+0x235/0x470
[ 30.637281]io_submit_sqes+0xcce/0xf10
[ 30.637839]__x64_sys_io_uring_enter+0x3fb/0x5b0
[ 30.638465]do_syscall_64+0x2d/0x40
[ 30.638999]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.639643]
[ 30.639643] other info that might help us debug this:
[ 30.639643]
[ 30.640618] Possible unsafe locking scenario:
[ 30.640618]
[ 30.641402]CPU0CPU1
[ 30.641938]
[ 30.642664] lock(>uring_lock);
[ 30.643425]lock(>mtx);
[ 30.644498]lock(>uring_lock);
[ 30.645668] lock(>mtx);
[ 30.646321]
[ 30.646321] *** DEADLOCK ***
[ 30.646321]
[ 30.647642] 1 lock held by a.out/1128:
[ 30.648424] #0: 88810e952be8 (>uring_lock){+.+.}-{3:3}, at:
__x64_sys_io_uring_enter+0x3f0/0x5b0
[ 30.649954]
[ 30.649954] stack backtrace:
[ 30.650592] CPU: 1 PID: 1128 Comm: a.out Not tainted
5.11.0-rc3-next-20210115 #1
[ 30.651554] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 30.652290] Call Trace:
[ 30.652688] dump_stack+0xac/0xe3
[ 30.653164] check_noncircular+0x11e/0x130
[ 30.653747] ? check_prevs_add+0x226/0xb00
[ 30.654303] check_prevs_add+0x226/0xb00
[ 30.654845] ? add_lock_to_list.constprop.49+0xac/0x1d0
[ 30.655564] __lock_acquire+0x1237/0x13a0
[ 30.656262] lock_acquire+0x2c7/0x390
[ 30.656788] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.657379] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.658014] __mutex_lock+0xae/0x9f0
[ 30.658524] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.659112] ? mark_held_locks+0x5a/0x80
[ 30.659648] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.660229] ? _raw_spin_unlock_irqrestore+0x2d/0x40
[ 30.660885] ? trace_hardirqs_on+0x46/0x110
[ 30.661471] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.662102] ? __ep_eventpoll_poll+0x9f/0x220
[ 30.662696] __ep_eventpoll_poll+0x9f/0x220
[ 30.663273] ? __ep_eventpoll_poll+0x220/0x220
[ 30.663875] __io_arm_poll_handler+0xbf/0x220
[ 30.664463] io_issue_sqe+0xa6b/0x13e0
[ 30.664984] ? __lock_acquire+0x782/0x13a0
[ 30.665544] ? __io_queue_proc.isra.88+0x180/0x180
[ 30.666170] ? __io_queue_sqe+0x10b/0x550
[ 30.666725] __io_queue_sqe+0x10b/0x550
[ 30.667252] ? __fget_files+0x131/0x260
[ 30.667791] ? io_req_prep+0xd8/0x1090
[ 30.668316] ? io_queue_sqe+0x235/0x470
[ 30.668868] io_queue_sqe+0x235/0x470
[ 30.669398] io_submit_sqes+0xcce/0xf10
[ 30.669931] ? xa_load+0xe4/0x1c0
[ 30.670425] __x64_sys_io_uring_enter+0x3fb/0x5b0
[ 30.671051] ? lockdep_hardirqs_on_prepare+0xde/0x180
[ 30.671719] ? syscall_enter_from_user_mode+0x2b/0x80
[ 30.672380] do_syscall_64+0x2d/0x40
[ 30.672901] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.673503] RIP: 0033:0x7fd89c813239
[ 30.673962] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0
ff ff 73 01 c3 48 8b 0d 27 ec 2c 00 f7 d8 64 89 01 48
[ 30.675920] RSP: 002b:7ffc65a7c628 EFLAGS: 0217 ORIG_RAX:
[PATCH 5.10 532/663] btrfs: do not warn if we cant find the reloc root when looking up backref
From: Josef Bacik
commit f78743fbdae1bb31bc9c9233c3590a5048782381 upstream.
The backref code is looking for a reloc_root that corresponds to the
given fs root. However any number of things could have gone wrong while
initializing that reloc_root, like ENOMEM while trying to allocate the
root itself, or EIO while trying to write the root item. This would
result in no corresponding reloc_root being in the reloc root cache, and
thus would return NULL when we do the find_reloc_root() call.
Because of this we do not want to WARN_ON(). This presumably was meant
to catch developer errors, cases where we messed up adding the reloc
root. However we can easily hit this case with error injection, and
thus should not do a WARN_ON().
CC: sta...@vger.kernel.org # 5.10+
Reported-by: Zygo Blaxell
Signed-off-by: Josef Bacik
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/backref.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -2624,7 +2624,7 @@ static int handle_direct_tree_backref(st
/* Only reloc backref cache cares about a specific root */
if (cache->is_reloc) {
root = find_reloc_root(cache->fs_info, cur->bytenr);
- if (WARN_ON(!root))
+ if (!root)
return -ENOENT;
cur->root = root;
} else {
[PATCH 5.10 107/663] net/mlx5e: kTLS, Use refcounts to free kTLS RX priv context
From: Maxim Mikityanskiy
[ Upstream commit b850bbff965129c34f50962638c0a66c82563536 ]
wait_for_resync is unreliable - if it timeouts, priv_rx will be freed
anyway. However, mlx5e_ktls_handle_get_psv_completion will be called
sooner or later, leading to use-after-free. For example, it can happen
if a CQ error happened, and ICOSQ stopped, but later on the queues are
destroyed, and ICOSQ is flushed with mlx5e_free_icosq_descs.
This patch converts the lifecycle of priv_rx to fully refcount-based, so
that the struct won't be freed before the refcount goes to zero.
Fixes: 0419d8c9d8f8 ("net/mlx5e: kTLS, Add kTLS RX resync support")
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: Tariq Toukan
Signed-off-by: Saeed Mahameed
Signed-off-by: Sasha Levin
---
.../mellanox/mlx5/core/en_accel/ktls_rx.c | 64 +--
1 file changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index 0f13b661f7f98..d06532d0baa43 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
@@ -57,6 +57,20 @@ struct mlx5e_ktls_offload_context_rx {
struct mlx5e_ktls_rx_resync_ctx resync;
};
+static bool mlx5e_ktls_priv_rx_put(struct mlx5e_ktls_offload_context_rx
*priv_rx)
+{
+ if (!refcount_dec_and_test(_rx->resync.refcnt))
+ return false;
+
+ kfree(priv_rx);
+ return true;
+}
+
+static void mlx5e_ktls_priv_rx_get(struct mlx5e_ktls_offload_context_rx
*priv_rx)
+{
+ refcount_inc(_rx->resync.refcnt);
+}
+
static int mlx5e_ktls_create_tir(struct mlx5_core_dev *mdev, u32 *tirn, u32
rqtn)
{
int err, inlen;
@@ -326,7 +340,7 @@ static void resync_handle_work(struct work_struct *work)
priv_rx = container_of(resync, struct mlx5e_ktls_offload_context_rx,
resync);
if (unlikely(test_bit(MLX5E_PRIV_RX_FLAG_DELETING, priv_rx->flags))) {
- refcount_dec(>refcnt);
+ mlx5e_ktls_priv_rx_put(priv_rx);
return;
}
@@ -334,7 +348,7 @@ static void resync_handle_work(struct work_struct *work)
sq = >async_icosq;
if (resync_post_get_progress_params(sq, priv_rx))
- refcount_dec(>refcnt);
+ mlx5e_ktls_priv_rx_put(priv_rx);
}
static void resync_init(struct mlx5e_ktls_rx_resync_ctx *resync,
@@ -377,7 +391,11 @@ unlock:
return err;
}
-/* Function is called with elevated refcount, it decreases it. */
+/* Function can be called with the refcount being either elevated or not.
+ * It decreases the refcount and may free the kTLS priv context.
+ * Refcount is not elevated only if tls_dev_del has been called, but GET_PSV
was
+ * already in flight.
+ */
void mlx5e_ktls_handle_get_psv_completion(struct mlx5e_icosq_wqe_info *wi,
struct mlx5e_icosq *sq)
{
@@ -410,7 +428,7 @@ void mlx5e_ktls_handle_get_psv_completion(struct
mlx5e_icosq_wqe_info *wi,
tls_offload_rx_resync_async_request_end(priv_rx->sk,
cpu_to_be32(hw_seq));
priv_rx->stats->tls_resync_req_end++;
out:
- refcount_dec(>refcnt);
+ mlx5e_ktls_priv_rx_put(priv_rx);
dma_unmap_single(dev, buf->dma_addr, PROGRESS_PARAMS_PADDED_SIZE,
DMA_FROM_DEVICE);
kfree(buf);
}
@@ -431,9 +449,9 @@ static bool resync_queue_get_psv(struct sock *sk)
return false;
resync = _rx->resync;
- refcount_inc(>refcnt);
+ mlx5e_ktls_priv_rx_get(priv_rx);
if (unlikely(!queue_work(resync->priv->tls->rx_wq, >work)))
- refcount_dec(>refcnt);
+ mlx5e_ktls_priv_rx_put(priv_rx);
return true;
}
@@ -625,31 +643,6 @@ err_create_key:
return err;
}
-/* Elevated refcount on the resync object means there are
- * outstanding operations (uncompleted GET_PSV WQEs) that
- * will read the resync / priv_rx objects once completed.
- * Wait for them to avoid use-after-free.
- */
-static void wait_for_resync(struct net_device *netdev,
- struct mlx5e_ktls_rx_resync_ctx *resync)
-{
-#define MLX5E_KTLS_RX_RESYNC_TIMEOUT 2 /* msecs */
- unsigned long exp_time = jiffies +
msecs_to_jiffies(MLX5E_KTLS_RX_RESYNC_TIMEOUT);
- unsigned int refcnt;
-
- do {
- refcnt = refcount_read(>refcnt);
- if (refcnt == 1)
- return;
-
- msleep(20);
- } while (time_before(jiffies, exp_time));
-
- netdev_warn(netdev,
- "Failed waiting for kTLS RX resync refcnt to be released
(%u).\n",
- refcnt);
-}
-
void mlx5e_ktls_del_rx(struct net_device *netdev, struct tls_context *tls_ctx)
{
struct mlx5e_ktls_offload_context_rx *priv_rx;
@@ -671,8 +664,7 @@ void mlx5e_ktls_del_rx(struct net_device *netdev, struct
tls_context *tls_ctx)
[PATCH 5.10 463/663] NFSv4: Fixes for nfs4_bitmask_adjust()
From: Trond Myklebust
[ Upstream commit 45901a231723a5a513ff08477983f3a274a6a910 ]
We don't want to ask for the ACL in a WRITE reply, since we don't have
a preallocated buffer.
Instead of checking NFS_INO_INVALID_ACCESS, which is really about
managing the access cache, we should look at the value of
NFS_INO_INVALID_OTHER. Also ensure we assign the mode, owner and
owner_group flags to the correct bit mask.
Finally, fix up the check for NFS_INO_INVALID_CTIME to retrieve the
ctime, and add a check for NFS_INO_INVALID_CHANGE.
Fixes: 76bd5c016ef4 ("NFSv4: make cache consistency bitmask dynamic")
Signed-off-by: Trond Myklebust
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
---
fs/nfs/nfs4proc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 0cd5b127f3bb9..a811d42ffbd11 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5433,15 +5433,16 @@ static void nfs4_bitmask_adjust(__u32 *bitmask, struct
inode *inode,
if (cache_validity & NFS_INO_INVALID_ATIME)
bitmask[1] |= FATTR4_WORD1_TIME_ACCESS;
- if (cache_validity & NFS_INO_INVALID_ACCESS)
- bitmask[0] |= FATTR4_WORD1_MODE | FATTR4_WORD1_OWNER |
- FATTR4_WORD1_OWNER_GROUP;
- if (cache_validity & NFS_INO_INVALID_ACL)
- bitmask[0] |= FATTR4_WORD0_ACL;
- if (cache_validity & NFS_INO_INVALID_LABEL)
+ if (cache_validity & NFS_INO_INVALID_OTHER)
+ bitmask[1] |= FATTR4_WORD1_MODE | FATTR4_WORD1_OWNER |
+ FATTR4_WORD1_OWNER_GROUP |
+ FATTR4_WORD1_NUMLINKS;
+ if (label && label->len && cache_validity & NFS_INO_INVALID_LABEL)
bitmask[2] |= FATTR4_WORD2_SECURITY_LABEL;
- if (cache_validity & NFS_INO_INVALID_CTIME)
+ if (cache_validity & NFS_INO_INVALID_CHANGE)
bitmask[0] |= FATTR4_WORD0_CHANGE;
+ if (cache_validity & NFS_INO_INVALID_CTIME)
+ bitmask[1] |= FATTR4_WORD1_TIME_METADATA;
if (cache_validity & NFS_INO_INVALID_MTIME)
bitmask[1] |= FATTR4_WORD1_TIME_MODIFY;
if (cache_validity & NFS_INO_INVALID_SIZE)
--
2.27.0
[PATCH 5.10 067/663] x86/MSR: Filter MSR writes through X86_IOC_WRMSR_REGS ioctl too
From: Misono Tomohiro
[ Upstream commit 02a16aa13574c8526beadfc9ae8cc9b66315fa2d ]
Commit
a7e1f67ed29f ("x86/msr: Filter MSR writes")
introduced a module parameter to disable writing to the MSR device file
and tainted the kernel upon writing. As MSR registers can be written by
the X86_IOC_WRMSR_REGS ioctl too, the same filtering and tainting should
be applied to the ioctl as well.
[ bp: Massage commit message and space out statements. ]
Fixes: a7e1f67ed29f ("x86/msr: Filter MSR writes")
Signed-off-by: Misono Tomohiro
Signed-off-by: Borislav Petkov
Link:
https://lkml.kernel.org/r/20210127122456.13939-1-misono.tomoh...@jp.fujitsu.com
Signed-off-by: Sasha Levin
---
arch/x86/kernel/msr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index c0d4098106589..79f900ffde4c5 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -184,6 +184,13 @@ static long msr_ioctl(struct file *file, unsigned int ioc,
unsigned long arg)
err = security_locked_down(LOCKDOWN_MSR);
if (err)
break;
+
+ err = filter_write(regs[1]);
+ if (err)
+ return err;
+
+ add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
--
2.27.0
[PATCH 5.11 034/775] ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family
From: Krzysztof Kozlowski
[ Upstream commit 3e7d9a583a24f7582c6bc29a0d4d624feedbc2f9 ]
The Samsung PMIC datasheets describe the interrupt line as active low
with a requirement of acknowledge from the CPU. The falling edge
interrupt will mostly work but it's not correct.
Fixes: aac4e0615341 ("ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC")
Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
Link: https://lore.kernel.org/r/20201210212903.216728-6-k...@kernel.org
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index d0df560eb0db1..6d690b1db0994 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -509,7 +509,7 @@
samsung,s2mps11-acokb-ground;
interrupt-parent = <>;
- interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_irq>;
--
2.27.0
[PATCH 5.10 592/663] mtd: spi-nor: hisi-sfc: Put child node np on error path
From: Pan Bian
commit fe6653460ee7a7dbe0cd5fd322992af862ce5ab0 upstream.
Put the child node np when it fails to get or register device.
Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller
driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Pan Bian
[ta: Add Fixes tag and Cc stable]
Signed-off-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2...@163.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/spi-nor/controllers/hisi-sfc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/mtd/spi-nor/controllers/hisi-sfc.c
+++ b/drivers/mtd/spi-nor/controllers/hisi-sfc.c
@@ -399,8 +399,10 @@ static int hisi_spi_nor_register_all(str
for_each_available_child_of_node(dev->of_node, np) {
ret = hisi_spi_nor_register(np, host);
- if (ret)
+ if (ret) {
+ of_node_put(np);
goto fail;
+ }
if (host->num_chip == HIFMC_MAX_CHIP_NUM) {
dev_warn(dev, "Flash device number exceeds the maximum
chipselect number\n");
[PATCH 5.11 075/775] opp: Correct debug message in _opp_add_static_v2()
From: Dmitry Osipenko
[ Upstream commit d7b9d9b31a3e55dcc9b5c289abfafe31efa5b5c4 ]
The debug message always prints rate=0 instead of a proper value, fix it.
Fixes: 6c591eec67cb ("OPP: Add helpers for reading the binding properties")
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Tested-by: Matt Merhar
Signed-off-by: Dmitry Osipenko
[ Viresh: Added Fixes tag ]
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/opp/of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 03cb387236c4c..d0c0336be39b4 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -755,7 +755,6 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
opp_table *opp_table,
struct device *dev, struct device_node *np)
{
struct dev_pm_opp *new_opp;
- u64 rate = 0;
u32 val;
int ret;
bool rate_not_available = false;
@@ -772,7 +771,8 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
opp_table *opp_table,
/* Check if the OPP supports hardware's hierarchy of versions or not */
if (!_opp_is_supported(dev, opp_table, np)) {
- dev_dbg(dev, "OPP not supported by hardware: %llu\n", rate);
+ dev_dbg(dev, "OPP not supported by hardware: %lu\n",
+ new_opp->rate);
goto free_opp;
}
--
2.27.0
[PATCH 5.10 254/663] irqchip/imx: IMX_INTMUX should not default to y, unconditionally
From: Geert Uytterhoeven
[ Upstream commit a890caeb2ba40ca183969230e204ab144f258357 ]
Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, restrict the automatic enabling of IMX_INTMUX to ARCH_MXC,
and ask the user in case of compile-testing.
Fixes: 66968d7dfc3f5451 ("irqchip: Add COMPILE_TEST support for IMX_INTMUX")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210208145605.422943-1-geert+rene...@glider.be
Signed-off-by: Sasha Levin
---
drivers/irqchip/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 2aa79c32ee228..6156a065681bc 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -464,7 +464,8 @@ config IMX_IRQSTEER
Support for the i.MX IRQSTEER interrupt multiplexer/remapper.
config IMX_INTMUX
- def_bool y if ARCH_MXC || COMPILE_TEST
+ bool "i.MX INTMUX support" if COMPILE_TEST
+ default y if ARCH_MXC
select IRQ_DOMAIN
help
Support for the i.MX INTMUX interrupt multiplexer.
--
2.27.0
