October 2023 - Linux-stable-mirror

[PATCH 2/5] mfd: qcom-spmi-pmic: fix revid implementation

by Johan Hovold

The Qualcomm SPMI PMIC revid implementation is broken in multiple ways. First, it assumes that just because the sibling base device has been registered that means that it is also bound to a driver, which may not be the case (e.g. due to probe deferral or asynchronous probe). This could trigger a NULL-pointer dereference when attempting to access the driver data of the unbound device. Second, it accesses driver data of a sibling device directly and without any locking, which means that the driver data may be freed while it is being accessed (e.g. on driver unbind). Third, it leaks a struct device reference to the sibling device which is looked up using the spmi_device_from_of() every time a function (child) device is calling the revid function (e.g. on probe). Fix this mess by reimplementing the revid lookup so that it is done only at probe of the PMIC device; the base device fetches the revid info from the hardware, while any secondary SPMI device fetches the information from the base device and caches it so that it can be accessed safely from its children. If the base device has not been probed yet then probe of a secondary device is deferred. Fixes: e9c11c6e3a0e ("mfd: qcom-spmi-pmic: expose the PMIC revid information to clients") Cc: stable(a)vger.kernel.org # 6.0 Cc: Caleb Connolly <caleb.connolly(a)linaro.org> Cc: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/mfd/qcom-spmi-pmic.c | 69 +++++++++++++++++++++++++++--------- 1 file changed, 53 insertions(+), 16 deletions(-) diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c index 47738f7e492c..8e449cff5cec 100644 --- a/drivers/mfd/qcom-spmi-pmic.c +++ b/drivers/mfd/qcom-spmi-pmic.c @@ -30,6 +30,8 @@ struct qcom_spmi_dev { struct qcom_spmi_pmic pmic; }; +static DEFINE_MUTEX(pmic_spmi_revid_lock); + #define N_USIDS(n) ((void *)n) static const struct of_device_id pmic_spmi_id_table[] = { @@ -76,24 +78,21 @@ static const struct of_device_id pmic_spmi_id_table[] = { * * This only supports PMICs with 1 or 2 USIDs. */ -static struct spmi_device *qcom_pmic_get_base_usid(struct device *dev) +static struct spmi_device *qcom_pmic_get_base_usid(struct spmi_device *sdev, struct qcom_spmi_dev *ctx) { - struct spmi_device *sdev; - struct qcom_spmi_dev *ctx; struct device_node *spmi_bus; struct device_node *child; int function_parent_usid, ret; u32 pmic_addr; - sdev = to_spmi_device(dev); - ctx = dev_get_drvdata(&sdev->dev); - /* * Quick return if the function device is already in the base * USID. This will always be hit for PMICs with only 1 USID. */ - if (sdev->usid % ctx->num_usids == 0) + if (sdev->usid % ctx->num_usids == 0) { + get_device(&sdev->dev); return sdev; + } function_parent_usid = sdev->usid; @@ -118,10 +117,8 @@ static struct spmi_device *qcom_pmic_get_base_usid(struct device *dev) sdev = spmi_device_from_of(child); if (!sdev) { /* - * If the base USID for this PMIC hasn't probed yet - * but the secondary USID has, then we need to defer - * the function driver so that it will attempt to - * probe again when the base USID is ready. + * If the base USID for this PMIC hasn't been + * registered yet then we need to defer. */ sdev = ERR_PTR(-EPROBE_DEFER); } @@ -135,6 +132,35 @@ static struct spmi_device *qcom_pmic_get_base_usid(struct device *dev) return sdev; } +static int pmic_spmi_get_base_revid(struct spmi_device *sdev, struct qcom_spmi_dev *ctx) +{ + struct qcom_spmi_dev *base_ctx; + struct spmi_device *base; + int ret = 0; + + base = qcom_pmic_get_base_usid(sdev, ctx); + if (IS_ERR(base)) + return PTR_ERR(base); + + /* + * Copy revid info from base device if it has probed and is still + * bound to its driver. + */ + mutex_lock(&pmic_spmi_revid_lock); + base_ctx = spmi_device_get_drvdata(base); + if (!base_ctx) { + ret = -EPROBE_DEFER; + goto out_unlock; + } + memcpy(&ctx->pmic, &base_ctx->pmic, sizeof(ctx->pmic)); +out_unlock: + mutex_unlock(&pmic_spmi_revid_lock); + + put_device(&base->dev); + + return ret; +} + static int pmic_spmi_load_revid(struct regmap *map, struct device *dev, struct qcom_spmi_pmic *pmic) { @@ -210,11 +236,7 @@ const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev) if (!of_match_device(pmic_spmi_id_table, dev->parent)) return ERR_PTR(-EINVAL); - sdev = qcom_pmic_get_base_usid(dev->parent); - - if (IS_ERR(sdev)) - return ERR_CAST(sdev); - + sdev = to_spmi_device(dev->parent); spmi = dev_get_drvdata(&sdev->dev); return &spmi->pmic; @@ -249,16 +271,31 @@ static int pmic_spmi_probe(struct spmi_device *sdev) ret = pmic_spmi_load_revid(regmap, &sdev->dev, &ctx->pmic); if (ret < 0) return ret; + } else { + ret = pmic_spmi_get_base_revid(sdev, ctx); + if (ret) + return ret; } + + mutex_lock(&pmic_spmi_revid_lock); spmi_device_set_drvdata(sdev, ctx); + mutex_unlock(&pmic_spmi_revid_lock); return devm_of_platform_populate(&sdev->dev); } +static void pmic_spmi_remove(struct spmi_device *sdev) +{ + mutex_lock(&pmic_spmi_revid_lock); + spmi_device_set_drvdata(sdev, NULL); + mutex_unlock(&pmic_spmi_revid_lock); +} + MODULE_DEVICE_TABLE(of, pmic_spmi_id_table); static struct spmi_driver pmic_spmi_driver = { .probe = pmic_spmi_probe, + .remove = pmic_spmi_remove, .driver = { .name = "pmic-spmi", .of_match_table = pmic_spmi_id_table, -- 2.41.0

9 months, 3 weeks

1
0
0 0

[PATCH 1/5] mfd: qcom-spmi-pmic: fix reference leaks in revid helper

by Johan Hovold

The Qualcomm SPMI PMIC revid implementation is broken in multiple ways. First, it totally ignores struct device_node reference counting and leaks references to the parent bus node as well as each child it iterates over using an open-coded for_each_child_of_node(). Second, it leaks references to each spmi device on the bus that it iterates over by failing to drop the reference taken by the spmi_device_from_of() helper. Fix the struct device_node leaks by reimplementing the lookup using for_each_child_of_node() and adding the missing reference count decrements. Fix the sibling struct device leaks by dropping the unnecessary lookups of devices with the wrong USID. Note that this still leaves one struct device reference leak in case a base device is found but it is not the parent of the device used for the lookup. This will be addressed in a follow-on patch. Fixes: e9c11c6e3a0e ("mfd: qcom-spmi-pmic: expose the PMIC revid information to clients") Cc: stable(a)vger.kernel.org # 6.0 Cc: Caleb Connolly <caleb.connolly(a)linaro.org> Cc: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/mfd/qcom-spmi-pmic.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c index 7e2cd79d17eb..47738f7e492c 100644 --- a/drivers/mfd/qcom-spmi-pmic.c +++ b/drivers/mfd/qcom-spmi-pmic.c @@ -81,7 +81,7 @@ static struct spmi_device *qcom_pmic_get_base_usid(struct device *dev) struct spmi_device *sdev; struct qcom_spmi_dev *ctx; struct device_node *spmi_bus; - struct device_node *other_usid = NULL; + struct device_node *child; int function_parent_usid, ret; u32 pmic_addr; @@ -105,28 +105,34 @@ static struct spmi_device *qcom_pmic_get_base_usid(struct device *dev) * device for USID 2. */ spmi_bus = of_get_parent(sdev->dev.of_node); - do { - other_usid = of_get_next_child(spmi_bus, other_usid); - - ret = of_property_read_u32_index(other_usid, "reg", 0, &pmic_addr); - if (ret) - return ERR_PTR(ret); + sdev = ERR_PTR(-ENODATA); + for_each_child_of_node(spmi_bus, child) { + ret = of_property_read_u32_index(child, "reg", 0, &pmic_addr); + if (ret) { + of_node_put(child); + sdev = ERR_PTR(ret); + break; + } - sdev = spmi_device_from_of(other_usid); if (pmic_addr == function_parent_usid - (ctx->num_usids - 1)) { - if (!sdev) + sdev = spmi_device_from_of(child); + if (!sdev) { /* * If the base USID for this PMIC hasn't probed yet * but the secondary USID has, then we need to defer * the function driver so that it will attempt to * probe again when the base USID is ready. */ - return ERR_PTR(-EPROBE_DEFER); - return sdev; + sdev = ERR_PTR(-EPROBE_DEFER); + } + of_node_put(child); + break; } - } while (other_usid->sibling); + } + + of_node_put(spmi_bus); - return ERR_PTR(-ENODATA); + return sdev; } static int pmic_spmi_load_revid(struct regmap *map, struct device *dev, -- 2.41.0

9 months, 3 weeks

1
0
0 0

[PATCH 6.5] ASoC: cs35l56: Call pm_runtime_dont_use_autosuspend()

by Richard Fitzgerald

commit ec03804552e9a723569e14d2512f36a8e70dc640 upstream Driver remove() must call pm_runtime_dont_use_autosuspend(). Drivers that call pm_runtime_use_autosuspend() must disable it in driver remove(). Unfortunately until recently this was only mentioned in 1 line in a 900+ line document so most people hadn't noticed this. It has only recently been added to the kerneldoc of pm_runtime_use_autosuspend(). Backport note: This is the same change as the upstream commit but the cs35l56->base.dev argument in the upstream code is cs35l56->dev in older releases. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20230908101716.2658582-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Please apply to 6.5. --- sound/soc/codecs/cs35l56.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/cs35l56.c b/sound/soc/codecs/cs35l56.c index fd06b9f9d496..7e241908b5f1 100644 --- a/sound/soc/codecs/cs35l56.c +++ b/sound/soc/codecs/cs35l56.c @@ -1594,6 +1594,7 @@ void cs35l56_remove(struct cs35l56_private *cs35l56) flush_workqueue(cs35l56->dsp_wq); destroy_workqueue(cs35l56->dsp_wq); + pm_runtime_dont_use_autosuspend(cs35l56->dev); pm_runtime_suspend(cs35l56->dev); pm_runtime_disable(cs35l56->dev); -- 2.30.2

9 months, 3 weeks

2
1
0 0

Re: [PATCH 0/5] MediaTek: Update MAINTAINERS and dts fixes for v6.7

by AngeloGioacchino Del Regno

Il 03/10/23 14:45, Sasha Levin ha scritto: > On Tue, Oct 03, 2023 at 01:13:42PM +0200, AngeloGioacchino Del Regno wrote: >> Hello SoC maintainers, >> >> As suggested by Arnd in [1], I am sending an update to the MAINTAINERS >> file, adding myself to the MediaTek SoC maintainers, and some urgent >> bugfixes for MediaTek devicetrees. > > Just curious: if it's urgent, and there are patches cc'ed to stable, why > wait for 6.7 rather than one of the 6.6 -rc cycles? > I may have misunderstood what Arnd said - in that case, I'm sorry. As for the fixes, I would be happier if those could land in v6.6-rcX. Regards, Angelo

9 months, 3 weeks

1
0
0 0

Re: [PATCH 5.10] btrfs: fix region size in count_bitmap_extents

by Анастасия Любимова

03/10/23 15:39, Anastasia Belova пишет: > > 14/09/23 12:45, Anastasia Belova пишет: >> count_bitmap_extents was deleted in version 5.11, but >> there is possible mistake in versions 5.6-5.10. >> >> Region size should be calculated by subtracting >> the end from the beginning. > Do I understand correctly that bytes should decrease and > (rs - re) is always negative and should be replaced by (re - rs)? >> Found by Linux Verification Center (linuxtesting.org) with SVACE. >> >> Fixes: dfb79ddb130e ("btrfs: track discardable extents for async discard") >> Signed-off-by: Anastasia Belova<abelova(a)astralinux.ru> >> --- >> fs/btrfs/free-space-cache.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c >> index 4989c60b1df9..a34e266a0969 100644 >> --- a/fs/btrfs/free-space-cache.c >> +++ b/fs/btrfs/free-space-cache.c >> @@ -1930,7 +1930,7 @@ static int count_bitmap_extents(struct btrfs_free_space_ctl *ctl, >> >> bitmap_for_each_set_region(bitmap_info->bitmap, rs, re, 0, >> BITS_PER_BITMAP) { >> - bytes -= (rs - re) * ctl->unit; >> + bytes -= (re - rs) * ctl->unit; >> count++; >> >> if (!bytes) > Anastasia Sorry for sending html accidentally

9 months, 3 weeks

1
0
0 0

[PATCH 0/5] MediaTek: Update MAINTAINERS and dts fixes for v6.7

by AngeloGioacchino Del Regno

Hello SoC maintainers, As suggested by Arnd in [1], I am sending an update to the MAINTAINERS file, adding myself to the MediaTek SoC maintainers, and some urgent bugfixes for MediaTek devicetrees. mt6358 PMIC - Bogus property dropped mt7622/mt7986a - Fix dtbs_check for t-phy nodes mt8195: - Fix early boot failure when DSU PMU enabled - Fix memory layout for demo board Regards, Angelo --- AngeloGioacchino Del Regno (1): MAINTAINERS: Add Angelo as MediaTek SoC co-maintainer Eugen Hristev (1): arm64: dts: mediatek: fix t-phy unit name Macpaul Lin (2): arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions Nícolas F. R. A. Prado (1): arm64: dts: mediatek: mt8195: Set DSU PMU status to fail MAINTAINERS | 2 +- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 2 +- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 2 +- arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 39 ++++++++++++++++++++++------ arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 + 5 files changed, 35 insertions(+), 11 deletions(-) --- base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d change-id: 20231003-mediatek-fixes-v6-7-341b5cfdc07a Best regards, -- AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

9 months, 3 weeks

1
3
0 0

[PATCH 5.10 0/4] cgroup: Fix suspicious rcu_dereference_check() warning

by ovidiu.panait＠windriver.com

From: Ovidiu Panait <ovidiu.panait(a)windriver.com> When booting the 5.10-stable kernel on the zcu102 board with CONFIG_PROVE_RCU=y, the following warning is present: ============================= WARNING: suspicious RCU usage 5.10.194-yocto-standard #1 Not tainted ----------------------------- include/linux/cgroup.h:495 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 9 locks held by kworker/2:2/106: #0: ffffff8800048948 ((wq_completion)events){..}-{0:0}, at: process_one_work+0x1f8/0x634 #1: ffffffc014c4bda8 (deferred_probe_work){..}-{0:0}, at: process_one_work+0x1f8/0x634 #2: ffffff880005d9a0 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x1c0 #3: ffffffc011c70cb0 (cpu_hotplug_lock){++++}-{0:0}, at: cpus_read_lock+0x18/0x24 #4: ffffff8800b10928 (subsys mutex#5){..}-{3:3}, at: subsys_interface_register+0x58/0x120 #5: ffffff8805e78c00 (&policy->rwsem){..}-{3:3}, at: cpufreq_online+0x590/0x960 #6: ffffffc012a9e770 (cpuset_mutex){..}-{3:3}, at: cpuset_lock+0x24/0x30 #7: ffffff880567bd80 (&p->pi_lock){..}-{2:2}, at: task_rq_lock+0x44/0xf0 #8: ffffff887aff50d8 (&rq->lock){..}-{2:2}, at: task_rq_lock+0x5c/0xf0 stack backtrace: CPU: 2 PID: 106 Comm: kworker/2:2 Not tainted 5.10.194-yocto-standard #1 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x1a4 show_stack+0x20/0x2c dump_stack+0xf0/0x13c lockdep_rcu_suspicious+0xe4/0xf8 inc_dl_tasks_cs+0xb8/0xbc switched_to_dl+0x38/0x280 __sched_setscheduler+0x204/0x860 sched_setattr_nocheck+0x20/0x30 sugov_init+0x1b8/0x380 cpufreq_init_governor.part.0+0x60/0xe0 cpufreq_set_policy+0x1d0/0x33c cpufreq_online+0x35c/0x960 cpufreq_add_dev+0x8c/0xa0 subsys_interface_register+0x10c/0x120 cpufreq_register_driver+0x148/0x2a4 dt_cpufreq_probe+0x288/0x3d0 platform_drv_probe+0x5c/0xb0 really_probe+0xe0/0x4ac driver_probe_device+0x60/0xf4 __device_attach_driver+0xc0/0x12c bus_for_each_drv+0x80/0xe0 __device_attach+0xb0/0x1c0 device_initial_probe+0x1c/0x30 bus_probe_device+0xa8/0xb0 deferred_probe_work_func+0x94/0xd0 process_one_work+0x2b8/0x634 worker_thread+0x7c/0x474 kthread+0x154/0x160 ret_from_fork+0x10/0x34 The warning was introduced in v5.10.193 by commit: 5ac05ce56843 "(sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets)" This issue was also reported for 5.15 here: https://lore.kernel.org/lkml/CA+G9fYv9xTu4bKJGy=e=KZSG5pZ+tJAmfZr=0dbuKNs=9… Backport commit f2aa197e4794 ("cgroup: Fix suspicious rcu_dereference_check() usage warning") and its dependencies to get rid of this warning. Andrey Ryabinin (1): sched/cpuacct: Fix user/system in shown cpuacct.usage* Chengming Zhou (3): sched/cpuacct: Fix charge percpu cpuusage sched/cpuacct: Optimize away RCU read lock cgroup: Fix suspicious rcu_dereference_check() usage warning include/linux/cgroup.h | 3 +- kernel/sched/cpuacct.c | 84 +++++++++++++++++------------------------- 2 files changed, 35 insertions(+), 52 deletions(-) -- 2.31.1

9 months, 3 weeks

2
5
0 0

[PATCH 1/4] megaraid_sas: Increase register read retry rount from 3 to 30 for selected registers

by Chandrakanth patil

In BMC environments with concurrent access to multiple registers, certain registers occasionally yield a value of 0 even after 3 retries due to hardware errata. As a fix, we have extended the retry count from 3 to 30. The same errata applies to the mpt3sas driver, and a similar patch has been accepted. Please find more details in the mpt3sas patch reference link. Link: https://lore.kernel.org/r/20230829090020.5417-2-ranjan.kumar@broadcom.com Fixes: 272652fcbf1a ("scsi: megaraid_sas: add retry logic in megasas_readl") Cc: stable(a)vger.kernel.org Signed-off-by: Chandrakanth patil <chandrakanth.patil(a)broadcom.com> Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index e1aa667dae66..3d4f13da1ae8 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -263,13 +263,13 @@ u32 megasas_readl(struct megasas_instance *instance, * Fusion registers could intermittently return all zeroes. * This behavior is transient in nature and subsequent reads will * return valid value. As a workaround in driver, retry readl for - * upto three times until a non-zero value is read. + * up to thirty times until a non-zero value is read. */ if (instance->adapter_type == AERO_SERIES) { do { ret_val = readl(addr); i++; - } while (ret_val == 0 && i < 3); + } while (ret_val == 0 && i < 30); return ret_val; } else { return readl(addr); -- 2.39.3

9 months, 3 weeks

1
0
0 0

[PATCH net,v2, 1/3] net: mana: Fix TX CQE error handling

by Haiyang Zhang

For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging. Cc: stable(a)vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 4a16ebff3d1d..5cdcf7561b38 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -1317,19 +1317,23 @@ static void mana_poll_tx_cq(struct mana_cq *cq) case CQE_TX_VPORT_IDX_OUT_OF_RANGE: case CQE_TX_VPORT_DISABLED: case CQE_TX_VLAN_TAGGING_VIOLATION: - WARN_ONCE(1, "TX: CQE error %d: ignored.\n", - cqe_oob->cqe_hdr.cqe_type); + if (net_ratelimit()) + netdev_err(ndev, "TX: CQE error %d\n", + cqe_oob->cqe_hdr.cqe_type); + apc->eth_stats.tx_cqe_err++; break; default: - /* If the CQE type is unexpected, log an error, assert, - * and go through the error path. + /* If the CQE type is unknown, log an error, + * and still free the SKB, update tail, etc. */ - WARN_ONCE(1, "TX: Unexpected CQE type %d: HW BUG?\n", - cqe_oob->cqe_hdr.cqe_type); + if (net_ratelimit()) + netdev_err(ndev, "TX: unknown CQE type %d\n", + cqe_oob->cqe_hdr.cqe_type); + apc->eth_stats.tx_cqe_unknown_type++; - return; + break; } if (WARN_ON_ONCE(txq->gdma_txq_id != completions[i].wq_num)) -- 2.25.1

9 months, 3 weeks

2
1
0 0

[PATCH net,v2, 2/3] net: mana: Fix the tso_bytes calculation

by Haiyang Zhang

sizeof(struct hop_jumbo_hdr) is not part of tso_bytes, so remove the subtraction from header size. Cc: stable(a)vger.kernel.org Fixes: bd7fc6e1957c ("net: mana: Add new MANA VF performance counters for easier troubleshooting") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 5cdcf7561b38..86e724c3eb89 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -264,8 +264,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev) ihs = skb_transport_offset(skb) + sizeof(struct udphdr); } else { ihs = skb_tcp_all_headers(skb); - if (ipv6_has_hopopt_jumbo(skb)) - ihs -= sizeof(struct hop_jumbo_hdr); } u64_stats_update_begin(&tx_stats->syncp); -- 2.25.1

9 months, 3 weeks

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023