--- /dev/null
+From 640bf95b2c7c2981fb471acdafbd3e0458f8390d Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 20 May 2023 11:48:55 +0200
+Subject: 3c589_cs: Fix an error handling path in tc589_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 640bf95b2c7c2981fb471acdafbd3e0458f8390d upstream.
+
+Should tc589_config() fail, some resources need to be released as already
+done in the remove function.
+
+Fixes: 15b99ac17295 ("[PATCH] pcmcia: add return value to _config() functions")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Simon Horman <simon.horman@corigine.com>
+Link: https://lore.kernel.org/r/d8593ae867b24c79063646e36f9b18b0790107cb.1684575975.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/3com/3c589_cs.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/3com/3c589_cs.c
++++ b/drivers/net/ethernet/3com/3c589_cs.c
+@@ -195,6 +195,7 @@ static int tc589_probe(struct pcmcia_dev
+ {
+ struct el3_private *lp;
+ struct net_device *dev;
++ int ret;
+
+ dev_dbg(&link->dev, "3c589_attach()\n");
+
+@@ -218,7 +219,15 @@ static int tc589_probe(struct pcmcia_dev
+
+ dev->ethtool_ops = &netdev_ethtool_ops;
+
+- return tc589_config(link);
++ ret = tc589_config(link);
++ if (ret)
++ goto err_free_netdev;
++
++ return 0;
++
++err_free_netdev:
++ free_netdev(dev);
++ return ret;
+ }
+
+ static void tc589_detach(struct pcmcia_device *link)
--- /dev/null
+From 04910d8cbfed65dad21c31723c6c1a8d9f990fb6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= <arinc.unal@arinc9.com>
+Date: Mon, 22 May 2023 13:57:43 +0300
+Subject: net: ethernet: mtk_eth_soc: fix QoS on DSA MAC on non MTK_NETSYS_V2 SoCs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arınç ÜNAL <arinc.unal@arinc9.com>
+
+commit 04910d8cbfed65dad21c31723c6c1a8d9f990fb6 upstream.
+
+The commit c6d96df9fa2c ("net: ethernet: mtk_eth_soc: drop generic vlan rx
+offload, only use DSA untagging") makes VLAN RX offloading to be only used
+on the SoCs without the MTK_NETSYS_V2 ability (which are not just MT7621
+and MT7622). The commit disables the proper handling of special tagged
+(DSA) frames, added with commit 87e3df4961f4 ("net-next: ethernet:
+mediatek: add CDM able to recognize the tag for DSA"), for non
+MTK_NETSYS_V2 SoCs when it finds a MAC that does not use DSA. So if the
+other MAC uses DSA, the CDMQ component transmits DSA tagged frames to the
+CPU improperly. This issue can be observed on frames with TCP, for example,
+a TCP speed test using iperf3 won't work.
+
+The commit disables the proper handling of special tagged (DSA) frames
+because it assumes that these SoCs don't use more than one MAC, which is
+wrong. Although I made Frank address this false assumption on the patch log
+when they sent the patch on behalf of Felix, the code still made changes
+with this assumption.
+
+Therefore, the proper handling of special tagged (DSA) frames must be kept
+enabled in all circumstances as it doesn't affect non DSA tagged frames.
+
+Hardware DSA untagging, introduced with the commit 2d7605a72906 ("net:
+ethernet: mtk_eth_soc: enable hardware DSA untagging"), and VLAN RX
+offloading are operations on the two CDM components of the frame engine,
+CDMP and CDMQ, which connect to Packet DMA (PDMA) and QoS DMA (QDMA) and
+are between the MACs and the CPU. These operations apply to all MACs of the
+SoC so if one MAC uses DSA and the other doesn't, the hardware DSA
+untagging operation will cause the CDMP component to transmit non DSA
+tagged frames to the CPU improperly.
+
+Since the VLAN RX offloading feature configuration was dropped, VLAN RX
+offloading can only be used along with hardware DSA untagging. So, for the
+case above, we need to disable both features and leave it to the CPU,
+therefore software, to untag the DSA and VLAN tags.
+
+So the correct way to handle this is:
+
+For all SoCs:
+
+Enable the proper handling of special tagged (DSA) frames
+(MTK_CDMQ_IG_CTRL).
+
+For non MTK_NETSYS_V2 SoCs:
+
+Enable hardware DSA untagging (MTK_CDMP_IG_CTRL).
+Enable VLAN RX offloading (MTK_CDMP_EG_CTRL).
+
+When a non MTK_NETSYS_V2 SoC MAC does not use DSA:
+
+Disable hardware DSA untagging (MTK_CDMP_IG_CTRL).
+Disable VLAN RX offloading (MTK_CDMP_EG_CTRL).
+
+Fixes: c6d96df9fa2c ("net: ethernet: mtk_eth_soc: drop generic vlan rx offload, only use DSA untagging")
+Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++------
+ 1 file changed, 2 insertions(+), 6 deletions(-)
+
+--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
++++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+@@ -3272,18 +3272,14 @@ static int mtk_open(struct net_device *d
+ eth->dsa_meta[i] = md_dst;
+ }
+ } else {
+- /* Hardware special tag parsing needs to be disabled if at least
+- * one MAC does not use DSA.
++ /* Hardware DSA untagging and VLAN RX offloading need to be
++ * disabled if at least one MAC does not use DSA.
+ */
+ u32 val = mtk_r32(eth, MTK_CDMP_IG_CTRL);
+
+ val &= ~MTK_CDMP_STAG_EN;
+ mtk_w32(eth, val, MTK_CDMP_IG_CTRL);
+
+- val = mtk_r32(eth, MTK_CDMQ_IG_CTRL);
+- val &= ~MTK_CDMQ_STAG_EN;
+- mtk_w32(eth, val, MTK_CDMQ_IG_CTRL);
+-
+ mtk_w32(eth, 0, MTK_CDMP_EG_CTRL);
+ }
+
--- /dev/null
+From 57fb54ab9f6945e204740b696bd4cee61ee04e5e Mon Sep 17 00:00:00 2001
+From: David Epping <david.epping@missinglinkelectronics.com>
+Date: Tue, 23 May 2023 17:31:05 +0200
+Subject: net: phy: mscc: add VSC8502 to MODULE_DEVICE_TABLE
+
+From: David Epping <david.epping@missinglinkelectronics.com>
+
+commit 57fb54ab9f6945e204740b696bd4cee61ee04e5e upstream.
+
+The mscc driver implements support for VSC8502, so its ID should be in
+the MODULE_DEVICE_TABLE for automatic loading.
+
+Signed-off-by: David Epping <david.epping@missinglinkelectronics.com>
+Fixes: d3169863310d ("net: phy: mscc: add support for VSC8502")
+Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/phy/mscc/mscc_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/phy/mscc/mscc_main.c
++++ b/drivers/net/phy/mscc/mscc_main.c
+@@ -2656,6 +2656,7 @@ static struct phy_driver vsc85xx_driver[
+ module_phy_driver(vsc85xx_driver);
+
+ static struct mdio_device_id __maybe_unused vsc85xx_tbl[] = {
++ { PHY_ID_VSC8502, 0xfffffff0, },
+ { PHY_ID_VSC8504, 0xfffffff0, },
+ { PHY_ID_VSC8514, 0xfffffff0, },
+ { PHY_ID_VSC8530, 0xfffffff0, },
--- /dev/null
+From 35112271672ae98f45df7875244a4e33aa215e31 Mon Sep 17 00:00:00 2001
+From: Wen Gu <guwen@linux.alibaba.com>
+Date: Thu, 18 May 2023 13:14:55 +0800
+Subject: net/smc: Reset connection when trying to use SMCRv2 fails.
+
+From: Wen Gu <guwen@linux.alibaba.com>
+
+commit 35112271672ae98f45df7875244a4e33aa215e31 upstream.
+
+We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It
+can be reproduced by:
+
+- smc_run nginx
+- smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port>
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000014
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0
+ Oops: 0000 [#1] PREEMPT SMP PTI
+ CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42
+ Workqueue: smc_hs_wq smc_listen_work [smc]
+ RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]
+ RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06
+ RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000
+ RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00
+ RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000
+ R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180
+ R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001
+ FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ <TASK>
+ ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]
+ ? smcr_buf_map_link+0x24b/0x290 [smc]
+ ? __smc_buf_create+0x4ee/0x9b0 [smc]
+ smc_clc_send_accept+0x4c/0xb0 [smc]
+ smc_listen_work+0x346/0x650 [smc]
+ ? __schedule+0x279/0x820
+ process_one_work+0x1e5/0x3f0
+ worker_thread+0x4d/0x2f0
+ ? __pfx_worker_thread+0x10/0x10
+ kthread+0xe5/0x120
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x2c/0x50
+ </TASK>
+
+During the CLC handshake, server sequentially tries available SMCRv2
+and SMCRv1 devices in smc_listen_work().
+
+If an SMCRv2 device is found. SMCv2 based link group and link will be
+assigned to the connection. Then assumed that some buffer assignment
+errors happen later in the CLC handshake, such as RMB registration
+failure, server will give up SMCRv2 and try SMCRv1 device instead. But
+the resources assigned to the connection won't be reset.
+
+When server tries SMCRv1 device, the connection creation process will
+be executed again. Since conn->lnk has been assigned when trying SMCRv2,
+it will not be set to the correct SMCRv1 link in
+smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to
+correct SMCRv1 link group but conn->lnk points to the SMCRv2 link
+mistakenly.
+
+Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]
+will be accessed. Since the link->link_idx is not correct, the related
+MR may not have been initialized, so crash happens.
+
+ | Try SMCRv2 device first
+ | |-> conn->lgr: assign existed SMCRv2 link group;
+ | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);
+ | |-> sndbuf & RMB creation fails, quit;
+ |
+ | Try SMCRv1 device then
+ | |-> conn->lgr: create SMCRv1 link group and assign;
+ | |-> conn->link: keep SMCRv2 link mistakenly;
+ | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0]
+ | initialized.
+ |
+ | Then smc_clc_send_confirm_accept() accesses
+ | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash.
+ v
+
+This patch tries to fix this by cleaning conn->lnk before assigning
+link. In addition, it is better to reset the connection and clean the
+resources assigned if trying SMCRv2 failed in buffer creation or
+registration.
+
+Fixes: e49300a6bf62 ("net/smc: add listen processing for SMC-Rv2")
+Link: https://lore.kernel.org/r/20220523055056.2078994-1-liuyacan@corp.netease.com/
+Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
+Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/smc/af_smc.c | 9 +++++++--
+ net/smc/smc_core.c | 1 +
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+--- a/net/smc/af_smc.c
++++ b/net/smc/af_smc.c
+@@ -2000,8 +2000,10 @@ static int smc_listen_rdma_init(struct s
+ return rc;
+
+ /* create send buffer and rmb */
+- if (smc_buf_create(new_smc, false))
++ if (smc_buf_create(new_smc, false)) {
++ smc_conn_abort(new_smc, ini->first_contact_local);
+ return SMC_CLC_DECL_MEM;
++ }
+
+ return 0;
+ }
+@@ -2217,8 +2219,11 @@ static void smc_find_rdma_v2_device_serv
+ smcr_version = ini->smcr_version;
+ ini->smcr_version = SMC_V2;
+ rc = smc_listen_rdma_init(new_smc, ini);
+- if (!rc)
++ if (!rc) {
+ rc = smc_listen_rdma_reg(new_smc, ini->first_contact_local);
++ if (rc)
++ smc_conn_abort(new_smc, ini->first_contact_local);
++ }
+ if (!rc)
+ return;
+ ini->smcr_version = smcr_version;
+--- a/net/smc/smc_core.c
++++ b/net/smc/smc_core.c
+@@ -127,6 +127,7 @@ static int smcr_lgr_conn_assign_link(str
+ int i, j;
+
+ /* do link balancing */
++ conn->lnk = NULL; /* reset conn->lnk first */
+ for (i = 0; i < SMC_LINKS_PER_LGR_MAX; i++) {
+ struct smc_link *lnk = &conn->lgr->lnk[i];
+
--- /dev/null
+From 368d3cb406cdd074d1df2ad9ec06d1bfcb664882 Mon Sep 17 00:00:00 2001
+From: Yunsheng Lin <linyunsheng@huawei.com>
+Date: Mon, 22 May 2023 11:17:14 +0800
+Subject: page_pool: fix inconsistency for page_pool_ring_[un]lock()
+
+From: Yunsheng Lin <linyunsheng@huawei.com>
+
+commit 368d3cb406cdd074d1df2ad9ec06d1bfcb664882 upstream.
+
+page_pool_ring_[un]lock() use in_softirq() to decide which
+spin lock variant to use, and when they are called in the
+context with in_softirq() being false, spin_lock_bh() is
+called in page_pool_ring_lock() while spin_unlock() is
+called in page_pool_ring_unlock(), because spin_lock_bh()
+has disabled the softirq in page_pool_ring_lock(), which
+causes inconsistency for spin lock pair calling.
+
+This patch fixes it by returning in_softirq state from
+page_pool_producer_lock(), and use it to decide which
+spin lock variant to use in page_pool_producer_unlock().
+
+As pool->ring has both producer and consumer lock, so
+rename it to page_pool_producer_[un]lock() to reflect
+the actual usage. Also move them to page_pool.c as they
+are only used there, and remove the 'inline' as the
+compiler may have better idea to do inlining or not.
+
+Fixes: 7886244736a4 ("net: page_pool: Add bulk support for ptr_ring")
+Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
+Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
+Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
+Link: https://lore.kernel.org/r/20230522031714.5089-1-linyunsheng@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/page_pool.h | 18 ------------------
+ net/core/page_pool.c | 28 ++++++++++++++++++++++++++--
+ 2 files changed, 26 insertions(+), 20 deletions(-)
+
+--- a/include/net/page_pool.h
++++ b/include/net/page_pool.h
+@@ -393,22 +393,4 @@ static inline void page_pool_nid_changed
+ page_pool_update_nid(pool, new_nid);
+ }
+
+-static inline void page_pool_ring_lock(struct page_pool *pool)
+- __acquires(&pool->ring.producer_lock)
+-{
+- if (in_softirq())
+- spin_lock(&pool->ring.producer_lock);
+- else
+- spin_lock_bh(&pool->ring.producer_lock);
+-}
+-
+-static inline void page_pool_ring_unlock(struct page_pool *pool)
+- __releases(&pool->ring.producer_lock)
+-{
+- if (in_softirq())
+- spin_unlock(&pool->ring.producer_lock);
+- else
+- spin_unlock_bh(&pool->ring.producer_lock);
+-}
+-
+ #endif /* _NET_PAGE_POOL_H */
+--- a/net/core/page_pool.c
++++ b/net/core/page_pool.c
+@@ -133,6 +133,29 @@ EXPORT_SYMBOL(page_pool_ethtool_stats_ge
+ #define recycle_stat_add(pool, __stat, val)
+ #endif
+
++static bool page_pool_producer_lock(struct page_pool *pool)
++ __acquires(&pool->ring.producer_lock)
++{
++ bool in_softirq = in_softirq();
++
++ if (in_softirq)
++ spin_lock(&pool->ring.producer_lock);
++ else
++ spin_lock_bh(&pool->ring.producer_lock);
++
++ return in_softirq;
++}
++
++static void page_pool_producer_unlock(struct page_pool *pool,
++ bool in_softirq)
++ __releases(&pool->ring.producer_lock)
++{
++ if (in_softirq)
++ spin_unlock(&pool->ring.producer_lock);
++ else
++ spin_unlock_bh(&pool->ring.producer_lock);
++}
++
+ static int page_pool_init(struct page_pool *pool,
+ const struct page_pool_params *params)
+ {
+@@ -615,6 +638,7 @@ void page_pool_put_page_bulk(struct page
+ int count)
+ {
+ int i, bulk_len = 0;
++ bool in_softirq;
+
+ for (i = 0; i < count; i++) {
+ struct page *page = virt_to_head_page(data[i]);
+@@ -633,7 +657,7 @@ void page_pool_put_page_bulk(struct page
+ return;
+
+ /* Bulk producer into ptr_ring page_pool cache */
+- page_pool_ring_lock(pool);
++ in_softirq = page_pool_producer_lock(pool);
+ for (i = 0; i < bulk_len; i++) {
+ if (__ptr_ring_produce(&pool->ring, data[i])) {
+ /* ring full */
+@@ -642,7 +666,7 @@ void page_pool_put_page_bulk(struct page
+ }
+ }
+ recycle_stat_add(pool, ring, i);
+- page_pool_ring_unlock(pool);
++ page_pool_producer_unlock(pool, in_softirq);
+
+ /* Hopefully all pages was return into ptr_ring */
+ if (likely(i == bulk_len))
--- /dev/null
+From a511637502b1caa135046d0f8fdabd55a31af8ef Mon Sep 17 00:00:00 2001
+From: Sen Chu <sen.chu@mediatek.com>
+Date: Thu, 18 May 2023 12:06:46 +0800
+Subject: regulator: mt6359: add read check for PMIC MT6359
+
+From: Sen Chu <sen.chu@mediatek.com>
+
+commit a511637502b1caa135046d0f8fdabd55a31af8ef upstream.
+
+Add hardware version read check for PMIC MT6359
+
+Signed-off-by: Sen Chu <sen.chu@mediatek.com
+Fixes: 4cfc96547512 ("regulator: mt6359: Add support for MT6359P regulator")
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com
+Link: https://lore.kernel.org/r/20230518040646.8730-1-sen.chu@mediatek.com
+Signed-off-by: Mark Brown <broonie@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/regulator/mt6359-regulator.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/regulator/mt6359-regulator.c
++++ b/drivers/regulator/mt6359-regulator.c
+@@ -951,9 +951,12 @@ static int mt6359_regulator_probe(struct
+ struct regulator_config config = {};
+ struct regulator_dev *rdev;
+ struct mt6359_regulator_info *mt6359_info;
+- int i, hw_ver;
++ int i, hw_ver, ret;
++
++ ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
++ if (ret)
++ return ret;
+
+- regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
+ if (hw_ver >= MT6359P_CHIP_VER)
+ mt6359_info = mt6359p_regulators;
+ else
net-mlx5-devcom-serialize-devcom-registration.patch
arm64-dts-imx8mn-var-som-fix-phy-detection-bug-by-adding-deassert-delay.patch
firmware-arm_ffa-set-reserved-mbz-fields-to-zero-in-the-memory-descriptors.patch
+regulator-mt6359-add-read-check-for-pmic-mt6359.patch
+net-smc-reset-connection-when-trying-to-use-smcrv2-fails.patch
+3c589_cs-fix-an-error-handling-path-in-tc589_probe.patch
+page_pool-fix-inconsistency-for-page_pool_ring_lock.patch
+net-ethernet-mtk_eth_soc-fix-qos-on-dsa-mac-on-non-mtk_netsys_v2-socs.patch
+net-phy-mscc-add-vsc8502-to-module_device_table.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
