--- /dev/null
+From 87889f1b7ea40d2544b49c62092e6ef2792dced7 Mon Sep 17 00:00:00 2001
+From: Andrey Konovalov <andrey.konovalov@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:15 +0100
+Subject: media: qcom: camss: Fix csid-gen2 for test pattern generator
+
+From: Andrey Konovalov <andrey.konovalov@linaro.org>
+
+commit 87889f1b7ea40d2544b49c62092e6ef2792dced7 upstream.
+
+In the current driver csid Test Pattern Generator (TPG) doesn't work.
+This change:
+- fixes writing frame width and height values into CSID_TPG_DT_n_CFG_0
+- fixes the shift by one between test_pattern control value and the
+ actual pattern.
+- drops fixed VC of 0x0a which testing showed prohibited some test
+ patterns in the CSID to produce output.
+So that TPG starts working, but with the below limitations:
+- only test_pattern=9 works as it should
+- test_pattern=8 and test_pattern=7 produce black frame (all zeroes)
+- the rest of test_pattern's don't work (yavta doesn't get the data)
+- regardless of the CFA pattern set by 'media-ctl -V' the actual pixel
+ order is always the same (RGGB for any RAW8 or RAW10P format in
+ 4608x2592 resolution).
+
+Tested with:
+
+RAW10P format, VC0:
+ media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4608x2592 field:none]'
+ media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4608x2592 field:none]'
+ media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
+ v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9
+ yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video0
+
+RAW10P format, VC1:
+ media-ctl -V '"msm_csid0":2[fmt:SRGGB10/4608x2592 field:none]'
+ media-ctl -V '"msm_vfe0_rdi1":0[fmt:SRGGB10/4608x2592 field:none]'
+ media-ctl -l '"msm_csid0":2->"msm_vfe0_rdi1":0[1]'
+ v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=9
+ yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 4608x2592 /dev/video1
+
+RAW8 format, VC0:
+ media-ctl --reset
+ media-ctl -V '"msm_csid0":0[fmt:SRGGB8/4608x2592 field:none]'
+ media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB8/4608x2592 field:none]'
+ media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
+ yavta -B capture-mplane --capture=3 -n 3 -f SRGGB8 -s 4608x2592 /dev/video0
+
+Fixes: eebe6d00e9bf ("media: camss: Add support for CSID hardware version Titan 170")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-csid-gen2.c | 9 +++------
+ 1 file changed, 3 insertions(+), 6 deletions(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c
++++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c
+@@ -355,9 +355,6 @@ static void __csid_configure_stream(stru
+ u8 dt_id = vc;
+
+ if (tg->enabled) {
+- /* Config Test Generator */
+- vc = 0xa;
+-
+ /* configure one DT, infinite frames */
+ val = vc << TPG_VC_CFG0_VC_NUM;
+ val |= INTELEAVING_MODE_ONE_SHOT << TPG_VC_CFG0_LINE_INTERLEAVING_MODE;
+@@ -370,14 +367,14 @@ static void __csid_configure_stream(stru
+
+ writel_relaxed(0x12345678, csid->base + CSID_TPG_LFSR_SEED);
+
+- val = input_format->height & 0x1fff << TPG_DT_n_CFG_0_FRAME_HEIGHT;
+- val |= input_format->width & 0x1fff << TPG_DT_n_CFG_0_FRAME_WIDTH;
++ val = (input_format->height & 0x1fff) << TPG_DT_n_CFG_0_FRAME_HEIGHT;
++ val |= (input_format->width & 0x1fff) << TPG_DT_n_CFG_0_FRAME_WIDTH;
+ writel_relaxed(val, csid->base + CSID_TPG_DT_n_CFG_0(0));
+
+ val = format->data_type << TPG_DT_n_CFG_1_DATA_TYPE;
+ writel_relaxed(val, csid->base + CSID_TPG_DT_n_CFG_1(0));
+
+- val = tg->mode << TPG_DT_n_CFG_2_PAYLOAD_MODE;
++ val = (tg->mode - 1) << TPG_DT_n_CFG_2_PAYLOAD_MODE;
+ val |= 0xBE << TPG_DT_n_CFG_2_USER_SPECIFIED_PAYLOAD;
+ val |= format->decode_format << TPG_DT_n_CFG_2_ENCODE_FORMAT;
+ writel_relaxed(val, csid->base + CSID_TPG_DT_n_CFG_2(0));
--- /dev/null
+From d8f7e1a60d01739a1d78db2b08603089c6cf7c8e Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:13 +0100
+Subject: media: qcom: camss: Fix invalid clock enable bit disjunction
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit d8f7e1a60d01739a1d78db2b08603089c6cf7c8e upstream.
+
+define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
+
+disjunction for gen2 ? BIT(7) : is a nop we are setting the same bit
+either way.
+
+Fixes: 4abb21309fda ("media: camss: csiphy: Move to hardcode CSI Clock Lane number")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
++++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+@@ -476,7 +476,7 @@ static void csiphy_lanes_enable(struct c
+
+ settle_cnt = csiphy_settle_cnt_calc(link_freq, csiphy->timer_clk_rate);
+
+- val = is_gen2 ? BIT(7) : CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
++ val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE;
+ for (i = 0; i < c->num_data; i++)
+ val |= BIT(c->data[i].pos * 2);
+
--- /dev/null
+From b6e1bdca463a932c1ac02caa7d3e14bf39288e0c Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:12 +0100
+Subject: media: qcom: camss: Fix missing vfe_lite clocks check
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit b6e1bdca463a932c1ac02caa7d3e14bf39288e0c upstream.
+
+check_clock doesn't account for vfe_lite which means that vfe_lite will
+never get validated by this routine. Add the clock name to the expected set
+to remediate.
+
+Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-vfe.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-vfe.c
++++ b/drivers/media/platform/qcom/camss/camss-vfe.c
+@@ -535,7 +535,8 @@ static int vfe_check_clock_rates(struct
+ struct camss_clock *clock = &vfe->clock[i];
+
+ if (!strcmp(clock->name, "vfe0") ||
+- !strcmp(clock->name, "vfe1")) {
++ !strcmp(clock->name, "vfe1") ||
++ !strcmp(clock->name, "vfe_lite")) {
+ u64 min_rate = 0;
+ unsigned long rate;
+
--- /dev/null
+From 7405116519ad70b8c7340359bfac8db8279e7ce4 Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:06 +0100
+Subject: media: qcom: camss: Fix pm_domain_on sequence in probe
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit 7405116519ad70b8c7340359bfac8db8279e7ce4 upstream.
+
+We need to make sure camss_configure_pd() happens before
+camss_register_entities() as the vfe_get() path relies on the pointer
+provided by camss_configure_pd().
+
+Fix the ordering sequence in probe to ensure the pointers vfe_get() demands
+are present by the time camss_register_entities() runs.
+
+In order to facilitate backporting to stable kernels I've moved the
+configure_pd() call pretty early on the probe() function so that
+irrespective of the existence of the old error handling jump labels this
+patch should still apply to -next circa Aug 2023 to v5.13 inclusive.
+
+Fixes: 2f6f8af67203 ("media: camss: Refactor VFE power domain toggling")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/media/platform/qcom/camss/camss.c
++++ b/drivers/media/platform/qcom/camss/camss.c
+@@ -1619,6 +1619,12 @@ static int camss_probe(struct platform_d
+ if (ret < 0)
+ goto err_cleanup;
+
++ ret = camss_configure_pd(camss);
++ if (ret < 0) {
++ dev_err(dev, "Failed to configure power domains: %d\n", ret);
++ goto err_cleanup;
++ }
++
+ ret = camss_init_subdevices(camss);
+ if (ret < 0)
+ goto err_cleanup;
+@@ -1678,12 +1684,6 @@ static int camss_probe(struct platform_d
+ }
+ }
+
+- ret = camss_configure_pd(camss);
+- if (ret < 0) {
+- dev_err(dev, "Failed to configure power domains: %d\n", ret);
+- return ret;
+- }
+-
+ pm_runtime_enable(dev);
+
+ return 0;
--- /dev/null
+From e655d1ae9703286cef7fda8675cad62f649dc183 Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:14 +0100
+Subject: media: qcom: camss: Fix set CSI2_RX_CFG1_VC_MODE when VC is greater than 3
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit e655d1ae9703286cef7fda8675cad62f649dc183 upstream.
+
+VC_MODE = 0 implies a two bit VC address.
+VC_MODE = 1 is required for VCs with a larger address than two bits.
+
+Fixes: eebe6d00e9bf ("media: camss: Add support for CSID hardware version Titan 170")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-csid-gen2.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c
++++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c
+@@ -449,6 +449,8 @@ static void __csid_configure_stream(stru
+ writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = 1 << CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
++ if (vc > 3)
++ val |= 1 << CSI2_RX_CFG1_VC_MODE;
+ val |= 1 << CSI2_RX_CFG1_MISR_EN;
+ writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG1);
+
--- /dev/null
+From 3143ad282fc08bf995ee73e32a9e40c527bf265d Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:10 +0100
+Subject: media: qcom: camss: Fix VFE-17x vfe_disable_output()
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit 3143ad282fc08bf995ee73e32a9e40c527bf265d upstream.
+
+There are two problems with the current vfe_disable_output() routine.
+
+Firstly we rightly use a spinlock to protect output->gen2.active_num
+everywhere except for in the IDLE timeout path of vfe_disable_output().
+Even if that is not racy "in practice" somehow it is by happenstance not
+by design.
+
+Secondly we do not get consistent behaviour from this routine. On
+sc8280xp 50% of the time I get "VFE idle timeout - resetting". In this
+case the subsequent capture will succeed. The other 50% of the time, we
+don't hit the idle timeout, never do the VFE reset and subsequent
+captures stall indefinitely.
+
+Rewrite the vfe_disable_output() routine to
+
+- Quiesce write masters with vfe_wm_stop()
+- Set active_num = 0
+
+remembering to hold the spinlock when we do so followed by
+
+- Reset the VFE
+
+Testing on sc8280xp and sdm845 shows this to be a valid fix.
+
+Fixes: 7319cdf189bb ("media: camss: Add support for VFE hardware version Titan 170")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-vfe-170.c | 22 +++-------------------
+ 1 file changed, 3 insertions(+), 19 deletions(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-vfe-170.c
++++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c
+@@ -7,7 +7,6 @@
+ * Copyright (C) 2020-2021 Linaro Ltd.
+ */
+
+-#include <linux/delay.h>
+ #include <linux/interrupt.h>
+ #include <linux/io.h>
+ #include <linux/iopoll.h>
+@@ -494,35 +493,20 @@ static int vfe_enable_output(struct vfe_
+ return 0;
+ }
+
+-static int vfe_disable_output(struct vfe_line *line)
++static void vfe_disable_output(struct vfe_line *line)
+ {
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output = &line->output;
+ unsigned long flags;
+ unsigned int i;
+- bool done;
+- int timeout = 0;
+-
+- do {
+- spin_lock_irqsave(&vfe->output_lock, flags);
+- done = !output->gen2.active_num;
+- spin_unlock_irqrestore(&vfe->output_lock, flags);
+- usleep_range(10000, 20000);
+-
+- if (timeout++ == 100) {
+- dev_err(vfe->camss->dev, "VFE idle timeout - resetting\n");
+- vfe_reset(vfe);
+- output->gen2.active_num = 0;
+- return 0;
+- }
+- } while (!done);
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+ for (i = 0; i < output->wm_num; i++)
+ vfe_wm_stop(vfe, output->wm_idx[i]);
++ output->gen2.active_num = 0;
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+- return 0;
++ vfe_reset(vfe);
+ }
+
+ /*
--- /dev/null
+From 7f24d291350426d40b36dfbe6b3090617cdfd37a Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:11 +0100
+Subject: media: qcom: camss: Fix VFE-480 vfe_disable_output()
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit 7f24d291350426d40b36dfbe6b3090617cdfd37a upstream.
+
+vfe-480 is copied from vfe-17x and has the same racy idle timeout bug as in
+17x.
+
+Fix the vfe_disable_output() logic to no longer be racy and to conform
+to the 17x way of quiescing and then resetting the VFE.
+
+Fixes: 4edc8eae715c ("media: camss: Add initial support for VFE hardware version Titan 480")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-vfe-480.c | 22 +++-------------------
+ 1 file changed, 3 insertions(+), 19 deletions(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-vfe-480.c
++++ b/drivers/media/platform/qcom/camss/camss-vfe-480.c
+@@ -8,7 +8,6 @@
+ * Copyright (C) 2021 Jonathan Marek
+ */
+
+-#include <linux/delay.h>
+ #include <linux/interrupt.h>
+ #include <linux/io.h>
+ #include <linux/iopoll.h>
+@@ -328,35 +327,20 @@ static int vfe_enable_output(struct vfe_
+ return 0;
+ }
+
+-static int vfe_disable_output(struct vfe_line *line)
++static void vfe_disable_output(struct vfe_line *line)
+ {
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output = &line->output;
+ unsigned long flags;
+ unsigned int i;
+- bool done;
+- int timeout = 0;
+-
+- do {
+- spin_lock_irqsave(&vfe->output_lock, flags);
+- done = !output->gen2.active_num;
+- spin_unlock_irqrestore(&vfe->output_lock, flags);
+- usleep_range(10000, 20000);
+-
+- if (timeout++ == 100) {
+- dev_err(vfe->camss->dev, "VFE idle timeout - resetting\n");
+- vfe_reset(vfe);
+- output->gen2.active_num = 0;
+- return 0;
+- }
+- } while (!done);
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+ for (i = 0; i < output->wm_num; i++)
+ vfe_wm_stop(vfe, output->wm_idx[i]);
++ output->gen2.active_num = 0;
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+- return 0;
++ vfe_reset(vfe);
+ }
+
+ /*
--- /dev/null
+From 26bda3da00c3edef727a6acb00ed2eb4b22f8723 Mon Sep 17 00:00:00 2001
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Date: Wed, 30 Aug 2023 16:16:09 +0100
+Subject: media: qcom: camss: Fix vfe_get() error jump
+
+From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+commit 26bda3da00c3edef727a6acb00ed2eb4b22f8723 upstream.
+
+Right now it is possible to do a vfe_get() with the internal reference
+count at 1. If vfe_check_clock_rates() returns non-zero then we will
+leave the reference count as-is and
+
+run:
+- pm_runtime_put_sync()
+- vfe->ops->pm_domain_off()
+
+skip:
+- camss_disable_clocks()
+
+Subsequent vfe_put() calls will when the ref-count is non-zero
+unconditionally run:
+
+- pm_runtime_put_sync()
+- vfe->ops->pm_domain_off()
+- camss_disable_clocks()
+
+vfe_get() should not attempt to roll-back on error when the ref-count is
+non-zero as the upper layers will still do their own vfe_put() operations.
+
+vfe_put() will drop the reference count and do the necessary power
+domain release, the cleanup jumps in vfe_get() should only be run when
+the ref-count is zero.
+
+[ 50.095796] CPU: 7 PID: 3075 Comm: cam Not tainted 6.3.2+ #80
+[ 50.095798] Hardware name: LENOVO 21BXCTO1WW/21BXCTO1WW, BIOS N3HET82W (1.54 ) 05/26/2023
+[ 50.095799] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[ 50.095802] pc : refcount_warn_saturate+0xf4/0x148
+[ 50.095804] lr : refcount_warn_saturate+0xf4/0x148
+[ 50.095805] sp : ffff80000c7cb8b0
+[ 50.095806] x29: ffff80000c7cb8b0 x28: ffff16ecc0e3fc10 x27: 0000000000000000
+[ 50.095810] x26: 0000000000000000 x25: 0000000000020802 x24: 0000000000000000
+[ 50.095813] x23: ffff16ecc7360640 x22: 00000000ffffffff x21: 0000000000000005
+[ 50.095815] x20: ffff16ed175f4400 x19: ffffb4d9852942a8 x18: ffffffffffffffff
+[ 50.095818] x17: ffffb4d9852d4a48 x16: ffffb4d983da5db8 x15: ffff80000c7cb320
+[ 50.095821] x14: 0000000000000001 x13: 2e656572662d7265 x12: 7466612d65737520
+[ 50.095823] x11: 00000000ffffefff x10: ffffb4d9850cebf0 x9 : ffffb4d9835cf954
+[ 50.095826] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8
+[ 50.095829] x5 : ffff16f813fe3d08 x4 : 0000000000000000 x3 : ffff621e8f4d2000
+[ 50.095832] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff16ed32119040
+[ 50.095835] Call trace:
+[ 50.095836] refcount_warn_saturate+0xf4/0x148
+[ 50.095838] device_link_put_kref+0x84/0xc8
+[ 50.095843] device_link_del+0x38/0x58
+[ 50.095846] vfe_pm_domain_off+0x3c/0x50 [qcom_camss]
+[ 50.095860] vfe_put+0x114/0x140 [qcom_camss]
+[ 50.095869] csid_set_power+0x2c8/0x408 [qcom_camss]
+[ 50.095878] pipeline_pm_power_one+0x164/0x170 [videodev]
+[ 50.095896] pipeline_pm_power+0xc4/0x110 [videodev]
+[ 50.095909] v4l2_pipeline_pm_use+0x5c/0xa0 [videodev]
+[ 50.095923] v4l2_pipeline_pm_get+0x1c/0x30 [videodev]
+[ 50.095937] video_open+0x7c/0x100 [qcom_camss]
+[ 50.095945] v4l2_open+0x84/0x130 [videodev]
+[ 50.095960] chrdev_open+0xc8/0x250
+[ 50.095964] do_dentry_open+0x1bc/0x498
+[ 50.095966] vfs_open+0x34/0x40
+[ 50.095968] path_openat+0xb44/0xf20
+[ 50.095971] do_filp_open+0xa4/0x160
+[ 50.095974] do_sys_openat2+0xc8/0x188
+[ 50.095975] __arm64_sys_openat+0x6c/0xb8
+[ 50.095977] invoke_syscall+0x50/0x128
+[ 50.095982] el0_svc_common.constprop.0+0x4c/0x100
+[ 50.095985] do_el0_svc+0x40/0xa8
+[ 50.095988] el0_svc+0x2c/0x88
+[ 50.095991] el0t_64_sync_handler+0xf4/0x120
+[ 50.095994] el0t_64_sync+0x190/0x198
+[ 50.095996] ---[ end trace 0000000000000000 ]---
+
+Fixes: 779096916dae ("media: camss: vfe: Fix runtime PM imbalance on error")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/platform/qcom/camss/camss-vfe.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/platform/qcom/camss/camss-vfe.c
++++ b/drivers/media/platform/qcom/camss/camss-vfe.c
+@@ -611,7 +611,7 @@ int vfe_get(struct vfe_device *vfe)
+ } else {
+ ret = vfe_check_clock_rates(vfe);
+ if (ret < 0)
+- goto error_pm_runtime_get;
++ goto error_pm_domain;
+ }
+ vfe->power_count++;
+
--- /dev/null
+From a48d5bdc877b85201e42cef9c2fdf5378164c23a Mon Sep 17 00:00:00 2001
+From: Stefan Roesch <shr@devkernel.io>
+Date: Mon, 6 Nov 2023 10:19:18 -0800
+Subject: mm: fix for negative counter: nr_file_hugepages
+
+From: Stefan Roesch <shr@devkernel.io>
+
+commit a48d5bdc877b85201e42cef9c2fdf5378164c23a upstream.
+
+While qualifiying the 6.4 release, the following warning was detected in
+messages:
+
+vmstat_refresh: nr_file_hugepages -15664
+
+The warning is caused by the incorrect updating of the NR_FILE_THPS
+counter in the function split_huge_page_to_list. The if case is checking
+for folio_test_swapbacked, but the else case is missing the check for
+folio_test_pmd_mappable. The other functions that manipulate the counter
+like __filemap_add_folio and filemap_unaccount_folio have the
+corresponding check.
+
+I have a test case, which reproduces the problem. It can be found here:
+ https://github.com/sroeschus/testcase/blob/main/vmstat_refresh/madv.c
+
+The test case reproduces on an XFS filesystem. Running the same test
+case on a BTRFS filesystem does not reproduce the problem.
+
+AFAIK version 6.1 until 6.6 are affected by this problem.
+
+[akpm@linux-foundation.org: whitespace fix]
+[shr@devkernel.io: test for folio_test_pmd_mappable()]
+ Link: https://lkml.kernel.org/r/20231108171517.2436103-1-shr@devkernel.io
+Link: https://lkml.kernel.org/r/20231106181918.1091043-1-shr@devkernel.io
+Signed-off-by: Stefan Roesch <shr@devkernel.io>
+Co-debugged-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Yang Shi <shy828301@gmail.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/huge_memory.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -2737,13 +2737,15 @@ int split_huge_page_to_list(struct page
+ int nr = folio_nr_pages(folio);
+
+ xas_split(&xas, folio, folio_order(folio));
+- if (folio_test_swapbacked(folio)) {
+- __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS,
+- -nr);
+- } else {
+- __lruvec_stat_mod_folio(folio, NR_FILE_THPS,
+- -nr);
+- filemap_nr_thps_dec(mapping);
++ if (folio_test_pmd_mappable(folio)) {
++ if (folio_test_swapbacked(folio)) {
++ __lruvec_stat_mod_folio(folio,
++ NR_SHMEM_THPS, -nr);
++ } else {
++ __lruvec_stat_mod_folio(folio,
++ NR_FILE_THPS, -nr);
++ filemap_nr_thps_dec(mapping);
++ }
+ }
+ }
+
--- /dev/null
+From 24948e3b7b12e0031a6edb4f49bbb9fb2ad1e4e9 Mon Sep 17 00:00:00 2001
+From: Roman Gushchin <roman.gushchin@linux.dev>
+Date: Tue, 7 Nov 2023 09:18:02 -0800
+Subject: mm: kmem: drop __GFP_NOFAIL when allocating objcg vectors
+
+From: Roman Gushchin <roman.gushchin@linux.dev>
+
+commit 24948e3b7b12e0031a6edb4f49bbb9fb2ad1e4e9 upstream.
+
+Objcg vectors attached to slab pages to store slab object ownership
+information are allocated using gfp flags for the original slab
+allocation. Depending on slab page order and the size of slab objects,
+objcg vector can take several pages.
+
+If the original allocation was done with the __GFP_NOFAIL flag, it
+triggered a warning in the page allocation code. Indeed, order > 1 pages
+should not been allocated with the __GFP_NOFAIL flag.
+
+Fix this by simply dropping the __GFP_NOFAIL flag when allocating the
+objcg vector. It effectively allows to skip the accounting of a single
+slab object under a heavy memory pressure.
+
+An alternative would be to implement the mechanism to fallback to order-0
+allocations for accounting metadata, which is also not perfect because it
+will increase performance penalty and memory footprint of the kernel
+memory accounting under memory pressure.
+
+Link: https://lkml.kernel.org/r/ZUp8ZFGxwmCx4ZFr@P9FQF9L96D.corp.robot.car
+Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
+Reported-by: Christoph Lameter <cl@linux.com>
+Closes: https://lkml.kernel.org/r/6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org
+Acked-by: Shakeel Butt <shakeelb@google.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memcontrol.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -2864,7 +2864,8 @@ static void commit_charge(struct folio *
+ * Moreover, it should not come from DMA buffer and is not readily
+ * reclaimable. So those GFP bits should be masked off.
+ */
+-#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | __GFP_ACCOUNT)
++#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | \
++ __GFP_ACCOUNT | __GFP_NOFAIL)
+
+ /*
+ * mod_objcg_mlstate() may be called with irq enabled, so
--- /dev/null
+From 015c9cbcf0ad709079117d27c2094a46e0eadcdb Mon Sep 17 00:00:00 2001
+From: Victor Shih <victor.shih@genesyslogic.com.tw>
+Date: Tue, 7 Nov 2023 17:57:40 +0800
+Subject: mmc: sdhci-pci-gli: GL9750: Mask the replay timer timeout of AER
+
+From: Victor Shih <victor.shih@genesyslogic.com.tw>
+
+commit 015c9cbcf0ad709079117d27c2094a46e0eadcdb upstream.
+
+Due to a flaw in the hardware design, the GL9750 replay timer frequently
+times out when ASPM is enabled. As a result, the warning messages will
+often appear in the system log when the system accesses the GL9750
+PCI config. Therefore, the replay timer timeout must be masked.
+
+Fixes: d7133797e9e1 ("mmc: sdhci-pci-gli: A workaround to allow GL9750 to enter ASPM L1.2")
+Signed-off-by: Victor Shih <victor.shih@genesyslogic.com.tw>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Acked-by: Kai-Heng Feng <kai.heng.geng@canonical.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231107095741.8832-2-victorshihgli@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-gli.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-gli.c
++++ b/drivers/mmc/host/sdhci-pci-gli.c
+@@ -28,6 +28,9 @@
+ #define PCI_GLI_9750_PM_CTRL 0xFC
+ #define PCI_GLI_9750_PM_STATE GENMASK(1, 0)
+
++#define PCI_GLI_9750_CORRERR_MASK 0x214
++#define PCI_GLI_9750_CORRERR_MASK_REPLAY_TIMER_TIMEOUT BIT(12)
++
+ #define SDHCI_GLI_9750_CFG2 0x848
+ #define SDHCI_GLI_9750_CFG2_L1DLY GENMASK(28, 24)
+ #define GLI_9750_CFG2_L1DLY_VALUE 0x1F
+@@ -564,6 +567,11 @@ static void gl9750_hw_setting(struct sdh
+ value &= ~PCI_GLI_9750_PM_STATE;
+ pci_write_config_dword(pdev, PCI_GLI_9750_PM_CTRL, value);
+
++ /* mask the replay timer timeout of AER */
++ pci_read_config_dword(pdev, PCI_GLI_9750_CORRERR_MASK, &value);
++ value |= PCI_GLI_9750_CORRERR_MASK_REPLAY_TIMER_TIMEOUT;
++ pci_write_config_dword(pdev, PCI_GLI_9750_CORRERR_MASK, value);
++
+ gl9750_wt_off(host);
+ }
+
--- /dev/null
+From 8df220b29282e8b450ea57be62e1eccd4996837c Mon Sep 17 00:00:00 2001
+From: Geliang Tang <geliang.tang@suse.com>
+Date: Tue, 14 Nov 2023 00:16:15 +0100
+Subject: mptcp: add validity check for sending RM_ADDR
+
+From: Geliang Tang <geliang.tang@suse.com>
+
+commit 8df220b29282e8b450ea57be62e1eccd4996837c upstream.
+
+This patch adds the validity check for sending RM_ADDRs for userspace PM
+in mptcp_pm_remove_addrs(), only send a RM_ADDR when the address is in the
+anno_list or conn_list.
+
+Fixes: 8b1c94da1e48 ("mptcp: only send RM_ADDR in nl_cmd_remove")
+Cc: stable@vger.kernel.org
+Signed-off-by: Geliang Tang <geliang.tang@suse.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-3-7b9cd6a7b7f4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/pm_netlink.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/pm_netlink.c
++++ b/net/mptcp/pm_netlink.c
+@@ -1538,8 +1538,9 @@ void mptcp_pm_remove_addrs(struct mptcp_
+ struct mptcp_pm_addr_entry *entry;
+
+ list_for_each_entry(entry, rm_list, list) {
+- remove_anno_list_by_saddr(msk, &entry->addr);
+- if (alist.nr < MPTCP_RM_IDS_MAX)
++ if ((remove_anno_list_by_saddr(msk, &entry->addr) ||
++ lookup_subflow_by_saddr(&msk->conn_list, &entry->addr)) &&
++ alist.nr < MPTCP_RM_IDS_MAX)
+ alist.ids[alist.nr++] = entry->addr.id;
+ }
+
--- /dev/null
+From 9fce92f050f448a0d1ddd9083ef967d9930f1e52 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 14 Nov 2023 00:16:13 +0100
+Subject: mptcp: deal with large GSO size
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit 9fce92f050f448a0d1ddd9083ef967d9930f1e52 upstream.
+
+After the blamed commit below, the TCP sockets (and the MPTCP subflows)
+can build egress packets larger than 64K. That exceeds the maximum DSS
+data size, the length being misrepresent on the wire and the stream being
+corrupted, as later observed on the receiver:
+
+ WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0
+ CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
+ netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
+ RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705
+ RSP: 0018:ffffc90000006e80 EFLAGS: 00010246
+ RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000
+ netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
+ RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908
+ RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a
+ R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908
+ R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29
+ FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
+ PKRU: 55555554
+ Call Trace:
+ <IRQ>
+ mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819
+ subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409
+ tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151
+ tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098
+ tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483
+ tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749
+ ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438
+ ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483
+ ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304
+ __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532
+ process_backlog+0x353/0x660 net/core/dev.c:5974
+ __napi_poll+0xc6/0x5a0 net/core/dev.c:6536
+ net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603
+ __do_softirq+0x184/0x524 kernel/softirq.c:553
+ do_softirq+0xdd/0x130 kernel/softirq.c:454
+
+Address the issue explicitly bounding the maximum GSO size to what MPTCP
+actually allows.
+
+Reported-by: Christoph Paasch <cpaasch@apple.com>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/450
+Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536")
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-1-7b9cd6a7b7f4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -1231,6 +1231,8 @@ static void mptcp_update_infinite_map(st
+ mptcp_do_fallback(ssk);
+ }
+
++#define MPTCP_MAX_GSO_SIZE (GSO_LEGACY_MAX_SIZE - (MAX_TCP_HEADER + 1))
++
+ static int mptcp_sendmsg_frag(struct sock *sk, struct sock *ssk,
+ struct mptcp_data_frag *dfrag,
+ struct mptcp_sendmsg_info *info)
+@@ -1257,6 +1259,8 @@ static int mptcp_sendmsg_frag(struct soc
+ return -EAGAIN;
+
+ /* compute send limit */
++ if (unlikely(ssk->sk_gso_max_size > MPTCP_MAX_GSO_SIZE))
++ ssk->sk_gso_max_size = MPTCP_MAX_GSO_SIZE;
+ info->mss_now = tcp_send_mss(ssk, &info->size_goal, info->flags);
+ copy = info->size_goal;
+
--- /dev/null
+From 7679d34f97b7a09fd565f5729f79fd61b7c55329 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 14 Nov 2023 00:16:16 +0100
+Subject: mptcp: fix setsockopt(IP_TOS) subflow locking
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit 7679d34f97b7a09fd565f5729f79fd61b7c55329 upstream.
+
+The MPTCP implementation of the IP_TOS socket option uses the lockless
+variant of the TOS manipulation helper and does not hold such lock at
+the helper invocation time.
+
+Add the required locking.
+
+Fixes: ffcacff87cd6 ("mptcp: Support for IP_TOS for MPTCP setsockopt()")
+Cc: stable@vger.kernel.org
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/457
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-4-7b9cd6a7b7f4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/sockopt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mptcp/sockopt.c
++++ b/net/mptcp/sockopt.c
+@@ -737,8 +737,11 @@ static int mptcp_setsockopt_v4_set_tos(s
+ val = inet_sk(sk)->tos;
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
++ bool slow;
+
++ slow = lock_sock_fast(ssk);
+ __ip_sock_set_tos(ssk, val);
++ unlock_sock_fast(ssk, slow);
+ }
+ release_sock(sk);
+
--- /dev/null
+From 0ab0c45d8aaea5192328bfa6989673aceafc767c Mon Sep 17 00:00:00 2001
+From: ChunHao Lin <hau@realtek.com>
+Date: Fri, 10 Nov 2023 01:33:59 +0800
+Subject: r8169: add handling DASH when DASH is disabled
+
+From: ChunHao Lin <hau@realtek.com>
+
+commit 0ab0c45d8aaea5192328bfa6989673aceafc767c upstream.
+
+For devices that support DASH, even DASH is disabled, there may still
+exist a default firmware that will influence device behavior.
+So driver needs to handle DASH for devices that support DASH, no
+matter the DASH status is.
+
+This patch also prepares for "fix network lost after resume on DASH
+systems".
+
+Fixes: ee7a1beb9759 ("r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled")
+Cc: stable@vger.kernel.org
+Signed-off-by: ChunHao Lin <hau@realtek.com>
+Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
+Link: https://lore.kernel.org/r/20231109173400.4573-2-hau@realtek.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169_main.c | 36 ++++++++++++++++++++----------
+ 1 file changed, 25 insertions(+), 11 deletions(-)
+
+--- a/drivers/net/ethernet/realtek/r8169_main.c
++++ b/drivers/net/ethernet/realtek/r8169_main.c
+@@ -624,6 +624,7 @@ struct rtl8169_private {
+
+ unsigned supports_gmii:1;
+ unsigned aspm_manageable:1;
++ unsigned dash_enabled:1;
+ dma_addr_t counters_phys_addr;
+ struct rtl8169_counters *counters;
+ struct rtl8169_tc_offsets tc_offset;
+@@ -1253,14 +1254,26 @@ static bool r8168ep_check_dash(struct rt
+ return r8168ep_ocp_read(tp, 0x128) & BIT(0);
+ }
+
+-static enum rtl_dash_type rtl_check_dash(struct rtl8169_private *tp)
++static bool rtl_dash_is_enabled(struct rtl8169_private *tp)
++{
++ switch (tp->dash_type) {
++ case RTL_DASH_DP:
++ return r8168dp_check_dash(tp);
++ case RTL_DASH_EP:
++ return r8168ep_check_dash(tp);
++ default:
++ return false;
++ }
++}
++
++static enum rtl_dash_type rtl_get_dash_type(struct rtl8169_private *tp)
+ {
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+- return r8168dp_check_dash(tp) ? RTL_DASH_DP : RTL_DASH_NONE;
++ return RTL_DASH_DP;
+ case RTL_GIGA_MAC_VER_51 ... RTL_GIGA_MAC_VER_53:
+- return r8168ep_check_dash(tp) ? RTL_DASH_EP : RTL_DASH_NONE;
++ return RTL_DASH_EP;
+ default:
+ return RTL_DASH_NONE;
+ }
+@@ -1453,7 +1466,7 @@ static void __rtl8169_set_wol(struct rtl
+
+ device_set_wakeup_enable(tp_to_dev(tp), wolopts);
+
+- if (tp->dash_type == RTL_DASH_NONE) {
++ if (!tp->dash_enabled) {
+ rtl_set_d3_pll_down(tp, !wolopts);
+ tp->dev->wol_enabled = wolopts ? 1 : 0;
+ }
+@@ -2512,7 +2525,7 @@ static void rtl_wol_enable_rx(struct rtl
+
+ static void rtl_prepare_power_down(struct rtl8169_private *tp)
+ {
+- if (tp->dash_type != RTL_DASH_NONE)
++ if (tp->dash_enabled)
+ return;
+
+ if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
+@@ -4875,7 +4888,7 @@ static int rtl8169_runtime_idle(struct d
+ {
+ struct rtl8169_private *tp = dev_get_drvdata(device);
+
+- if (tp->dash_type != RTL_DASH_NONE)
++ if (tp->dash_enabled)
+ return -EBUSY;
+
+ if (!netif_running(tp->dev) || !netif_carrier_ok(tp->dev))
+@@ -4901,8 +4914,7 @@ static void rtl_shutdown(struct pci_dev
+ /* Restore original MAC address */
+ rtl_rar_set(tp, tp->dev->perm_addr);
+
+- if (system_state == SYSTEM_POWER_OFF &&
+- tp->dash_type == RTL_DASH_NONE) {
++ if (system_state == SYSTEM_POWER_OFF && !tp->dash_enabled) {
+ pci_wake_from_d3(pdev, tp->saved_wolopts);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
+@@ -5260,7 +5272,8 @@ static int rtl_init_one(struct pci_dev *
+ rc = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1);
+ tp->aspm_manageable = !rc;
+
+- tp->dash_type = rtl_check_dash(tp);
++ tp->dash_type = rtl_get_dash_type(tp);
++ tp->dash_enabled = rtl_dash_is_enabled(tp);
+
+ tp->cp_cmd = RTL_R16(tp, CPlusCmd) & CPCMD_MASK;
+
+@@ -5331,7 +5344,7 @@ static int rtl_init_one(struct pci_dev *
+ /* configure chip for default features */
+ rtl8169_set_features(dev, dev->features);
+
+- if (tp->dash_type == RTL_DASH_NONE) {
++ if (!tp->dash_enabled) {
+ rtl_set_d3_pll_down(tp, true);
+ } else {
+ rtl_set_d3_pll_down(tp, false);
+@@ -5371,7 +5384,8 @@ static int rtl_init_one(struct pci_dev *
+ "ok" : "ko");
+
+ if (tp->dash_type != RTL_DASH_NONE) {
+- netdev_info(dev, "DASH enabled\n");
++ netdev_info(dev, "DASH %s\n",
++ tp->dash_enabled ? "enabled" : "disabled");
+ rtl8168_driver_start(tp);
+ }
+
--- /dev/null
+From 868c3b95afef4883bfb66c9397482da6840b5baf Mon Sep 17 00:00:00 2001
+From: ChunHao Lin <hau@realtek.com>
+Date: Fri, 10 Nov 2023 01:34:00 +0800
+Subject: r8169: fix network lost after resume on DASH systems
+
+From: ChunHao Lin <hau@realtek.com>
+
+commit 868c3b95afef4883bfb66c9397482da6840b5baf upstream.
+
+Device that support DASH may be reseted or powered off during suspend.
+So driver needs to handle DASH during system suspend and resume. Or
+DASH firmware will influence device behavior and causes network lost.
+
+Fixes: b646d90053f8 ("r8169: magic.")
+Cc: stable@vger.kernel.org
+Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
+Signed-off-by: ChunHao Lin <hau@realtek.com>
+Link: https://lore.kernel.org/r/20231109173400.4573-3-hau@realtek.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169_main.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/net/ethernet/realtek/r8169_main.c
++++ b/drivers/net/ethernet/realtek/r8169_main.c
+@@ -4648,10 +4648,16 @@ static void rtl8169_down(struct rtl8169_
+ rtl8169_cleanup(tp);
+ rtl_disable_exit_l1(tp);
+ rtl_prepare_power_down(tp);
++
++ if (tp->dash_type != RTL_DASH_NONE)
++ rtl8168_driver_stop(tp);
+ }
+
+ static void rtl8169_up(struct rtl8169_private *tp)
+ {
++ if (tp->dash_type != RTL_DASH_NONE)
++ rtl8168_driver_start(tp);
++
+ pci_set_master(tp->pci_dev);
+ phy_init_hw(tp->phydev);
+ phy_resume(tp->phydev);
--- /dev/null
+From 7cefbe5e1dacc7236caa77e9d072423f21422fe2 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 14 Nov 2023 00:16:17 +0100
+Subject: selftests: mptcp: fix fastclose with csum failure
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit 7cefbe5e1dacc7236caa77e9d072423f21422fe2 upstream.
+
+Running the mp_join selftest manually with the following command line:
+
+ ./mptcp_join.sh -z -C
+
+leads to some failures:
+
+ 002 fastclose server test
+ # ...
+ rtx [fail] got 1 MP_RST[s] TX expected 0
+ # ...
+ rstrx [fail] got 1 MP_RST[s] RX expected 0
+
+The problem is really in the wrong expectations for the RST checks
+implied by the csum validation. Note that the same check is repeated
+explicitly in the same test-case, with the correct expectation and
+pass successfully.
+
+Address the issue explicitly setting the correct expectation for
+the failing checks.
+
+Reported-by: Xiumei Mu <xmu@redhat.com>
+Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases")
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20231114-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-v1-5-7b9cd6a7b7f4@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/mptcp/mptcp_join.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
++++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
+@@ -3237,7 +3237,7 @@ fastclose_tests()
+ if reset_check_counter "fastclose server test" "MPTcpExtMPFastcloseRx"; then
+ test_linkfail=1024 fastclose=server \
+ run_tests $ns1 $ns2 10.0.1.1
+- chk_join_nr 0 0 0
++ chk_join_nr 0 0 0 0 0 0 1
+ chk_fclose_nr 1 1 invert
+ chk_rst_nr 1 1
+ fi
riscv-correct-pt_level-name-via-pgtable_l5-4_enabled.patch
riscv-kprobes-allow-writing-to-x0.patch
mmc-sdhci-pci-gli-a-workaround-to-allow-gl9750-to-enter-aspm-l1.2.patch
+mm-fix-for-negative-counter-nr_file_hugepages.patch
+mm-kmem-drop-__gfp_nofail-when-allocating-objcg-vectors.patch
+mptcp-deal-with-large-gso-size.patch
+mptcp-add-validity-check-for-sending-rm_addr.patch
+mptcp-fix-setsockopt-ip_tos-subflow-locking.patch
+selftests-mptcp-fix-fastclose-with-csum-failure.patch
+r8169-fix-network-lost-after-resume-on-dash-systems.patch
+r8169-add-handling-dash-when-dash-is-disabled.patch
+mmc-sdhci-pci-gli-gl9750-mask-the-replay-timer-timeout-of-aer.patch
+media-qcom-camss-fix-pm_domain_on-sequence-in-probe.patch
+media-qcom-camss-fix-vfe_get-error-jump.patch
+media-qcom-camss-fix-vfe-17x-vfe_disable_output.patch
+media-qcom-camss-fix-vfe-480-vfe_disable_output.patch
+media-qcom-camss-fix-missing-vfe_lite-clocks-check.patch
+media-qcom-camss-fix-set-csi2_rx_cfg1_vc_mode-when-vc-is-greater-than-3.patch
+media-qcom-camss-fix-invalid-clock-enable-bit-disjunction.patch
+media-qcom-camss-fix-csid-gen2-for-test-pattern-generator.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
